Recommend a Connectivity Solution that Connects Azure Resources to the Internet — Lesson

A SaaS team in Amsterdam launches a global API serving customers across five continents. Their default architecture exposes each region's Application Gateway directly to the public internet with a regional public IP per region. Within just the first two weeks, three problems emerge: outbound calls from internal VMs hit SNAT-port exhaustion under load; the public-facing service receives a DDoS volumetric attack that floods the regional egress; remote operators struggle to access VMs without exposing RDP. The architect's response touches four services: deploy Azure Front Door Premium for global edge + WAF + DDoS, attach a NAT Gateway to the egress subnets to fix SNAT, enable Azure DDoS Protection Standard, and replace direct RDP with Azure Bastion. The site stabilises within a week; operators get secure single-sign-on access; the egress story becomes predictable and audit-friendly. This lesson is about deliberately designing internet-side connectivity — inbound and outbound — from day 1, so neither side becomes a silent bottleneck or an exposure surface waiting for an incident.

We will work through Azure's internet-connectivity story the way the AZ-305 exam expects you to: public IPs (Basic / Standard / zonal / zone-redundant), NAT Gateway for egress, Azure Front Door for global inbound, Azure Firewall for egress filtering, and Azure Bastion for secure admin access. Reference: the AZ-305 exam study guide, particularly Chapter 4 Skill 4.4 on network solutions.

Why This Matters

Internet connectivity is where Azure-native workloads meet the rest of the world and where most of the visible failure modes live. Misconfigured, it's the failure mode customers and partners see first and complain about loudest. The AZ-305 exam tests this LO heavily because the design decisions here — what kind of public IP, how outbound egress is structured, where the WAF sits, how admins connect — are foundational and surprisingly hard to change after the workload is live.

The career payoff is concrete: every public-facing service launch, every "our outbound calls fail intermittently" debugging session, every "how do we secure RDP to these VMs" question, every "the partner's firewall rejects our requests" investigation, and every public-IP migration project touches this LO. If you can match an internet requirement (inbound HTTP, inbound TCP, outbound from a VMSS, admin access, partner-allowlist egress IPs) to the right Azure service and configure DDoS / WAF / Firewall correctly, you will pass this slice of the exam and design internet edges like a senior architect.

Prerequisites

• Public vs private IPs. Can you describe the difference and Azure's address scopes? — Self-check: which type is used for an Internal Load Balancer frontend?
• SNAT (Source NAT). Are you familiar with the concept? — Self-check: how many SNAT ports does a default outbound flow use per destination?
• NSGs. Do you know how rules apply at NIC vs subnet level? — Self-check: what's evaluated first?
• DDoS basics. Can you describe volumetric vs protocol vs application-layer attacks? — Self-check: which layer does a WAF protect?
• Bastion concept. Have you seen Azure Bastion? — Self-check: what protocol does it use to reach client browsers?

If any of these feels shaky, pause and review the networking primer in Unit 1 and Unit 4 of the AZ-305 guide, plus LO-36 on API integration which adjoins this LO closely.

Learning Objectives

1. Analyse an internet-connectivity requirement (inbound or outbound, throughput, geography, security posture, partner-allowlist obligations) and translate it to the right Azure service.
2. Evaluate trade-offs between Public IP Basic vs Standard, zonal vs zone-redundant; NAT Gateway vs Load Balancer SNAT vs Firewall SNAT vs per-VM public IP for outbound flows.
3. Recommend an inbound architecture for global HTTP using Front Door + WAF + DDoS, layered with regional Application Gateway for VNet-bound backends.
4. Configure secure admin access using Azure Bastion (Basic / Standard / Premium) with hub-spoke topology and Entra-ID SSO.
5. Recognise anti-patterns — direct RDP exposure, Basic Public IP in production, default-LB SNAT for high-egress workloads, missing egress IP allowlisting for partners — and rewrite them.
6. Design egress filtering with Azure Firewall for compliance and threat-protection, combining Premium TLS inspection with NAT Gateway for predictable egress IPs.

Building Blocks

Public IP — A globally routable IPv4/IPv6 address Azure assigns to your resource. Formally, Microsoft.Network/publicIPAddresses with Basic (deprecated, retiring) or Standard SKU; can be regional, zonal (pinned), or zone-redundant. It matters because Basic SKU is being retired — production must be Standard.

Standard Public IP — Always-allocated, secure-by-default, supports availability zones. SLA 99.99%. The required SKU for new production work.

NAT Gateway — Outbound-only SNAT service that gives a subnet predictable egress public IPs and massive SNAT-port headroom (up to $\sim 64{,}000$ ports per attached IP). Formally, Microsoft.Network/natGateways. Attach to a subnet; all outbound flows from that subnet egress through the NAT Gateway's public IP. It matters because NAT Gateway is the supported way to fix SNAT exhaustion in production.

Azure Front Door — Global edge L7 service with AnyCast, caching, WAF, DDoS. Standard / Premium tiers. Already covered in LO-37 and LO-49; in this LO it's the inbound-internet front door.

Azure Firewall — Managed L3/L4/L7 stateful firewall. Standard / Premium / Basic tiers. Premium adds TLS inspection and IDPS. It matters for egress filtering, app-level rule enforcement, and centralised network audit.

Azure DDoS Protection — Always-on basic protection for every public endpoint; Network Protection (paid) adds custom mitigations, analytics, and SLA-backed protections. It matters because the basic free tier is fine for most workloads; Network Protection is for high-value public endpoints.

Azure Bastion — Browser-based secure RDP/SSH to VMs without exposing public IPs on those VMs. Formally, a managed service deployed into a subnet (AzureBastionSubnet); users connect via HTTPS to the Bastion endpoint, which proxies to the VM over the VNet. Tiers: Basic, Standard, Premium. It matters because Bastion replaces the legacy "expose RDP through NSG" anti-pattern.

Outbound default access (legacy) — Azure VMs without explicit outbound config historically got implicit outbound via a Microsoft-managed IP. This is being retired in September 2025. Workloads must have explicit outbound: NAT Gateway, Load Balancer with outbound rules, or Public IP per VM.

SNAT port exhaustion — Failure mode when outbound flows from many sources to the same destination exhaust the SNAT port pool. Symptoms: intermittent connection failures, "connection refused" / timeouts to specific destinations. NAT Gateway is the fix.

Deep Dive

1. Public IP — Basic retiring, Standard required

The exam tests recognising that Basic SKU is retired / retiring.

[!WARNING] Existing Basic public IPs need migration. Microsoft provides a migration tool / portal flow to upgrade Basic $\\to$ Standard with the same IP address.

2. Outbound architectures — fix SNAT before it bites

Outbound from Azure VMs has multiple paths. The exam tests recognising when each is right.

[!IMPORTANT] SNAT port exhaustion is the canonical "outbound calls fail under load" diagnosis. Attaching a NAT Gateway and giving it $2{-}4$ public IPs fixes nearly all cases for typical workloads.

3. Inbound — Public IP, Load Balancer, Application Gateway, Front Door

Inbound architectures stack. Each layer adds capabilities:

A typical production stack: Front Door for global edge, Application Gateway inside the regional VNet for L7 + private-backend, Standard LB for L4 distribution if needed.

4. Egress filtering — Azure Firewall

When the workload needs centralised egress control — allowlisting destinations, TLS inspection, IDPS — Azure Firewall is the canonical answer.

Place Azure Firewall in a hub VNet; force all egress through it via UDRs on spoke VNets. The exam tests this hub-spoke + Firewall pattern frequently.

5. DDoS Protection — Basic vs Network Protection

Every public endpoint gets DDoS Protection Basic for free — Microsoft's platform absorbs common attacks. Network Protection (formerly Standard) adds:

• Custom mitigation tuning per public IP.
• DDoS attack analytics and alerts.
• Cost protection (Microsoft credits scaling costs incurred during attack).
• Rapid-response engineering during active attacks.

[!TIP] For tier-1 public services, enable Network Protection on the VNet containing public IPs. The cost is per-VNet not per-IP, so consolidating public endpoints in one VNet is cost-efficient.

6. Azure Bastion — admin access without exposure

Azure Bastion provides browser-based RDP/SSH to VMs. The VMs themselves have no public IPs; users connect to the Bastion endpoint over HTTPS and Bastion proxies to the VM over the VNet.

[!IMPORTANT] Bastion replaces the legacy pattern of opening port 3389 (RDP) or 22 (SSH) on a VM's NSG. The Bastion pattern is the AZ-305-recommended way to manage admin access.

7. Hybrid concerns — Front Door + Application Gateway

When private backends need global low-latency, Front Door fronts the public endpoint while Application Gateway sits inside the VNet talking to private services. Front Door does not have a VNet integration option (other than Private Link origin); App Gateway handles the VNet side.

8. IPv6 — increasingly mainstream

Azure supports dual-stack IPv4/IPv6 on Standard Public IPs and Load Balancers. The exam tests recognising that IPv6 deployment is a real Azure-native option (especially for global services). Dual-stack avoids future-proofing concerns: clients on IPv6-only networks (some mobile carriers, some regulated tenancies) reach the service without NAT64 translation.

[!NOTE] For greenfield public-internet workloads, deploy dual-stack from day 1. Adding IPv6 later requires touching every layer of the network stack.

9. Outbound design patterns by workload shape

The right outbound design depends on the workload's egress profile.

[!TIP] Multi-IP NAT Gateways are the answer when a single egress IP can't supply enough SNAT ports per destination. Add IPs to a single NAT Gateway rather than spreading across multiple — it pools ports across IPs efficiently.

10. Combining DDoS, WAF, and L7 filtering

For tier-1 public endpoints, the defence-in-depth stack is:

Front Door's WAF (in Premium tier) and App Gateway's WAF cover similar ground; they differ in where they sit. Front Door is global edge ($AnyCast$); App Gateway is regional, inside the VNet, closer to backends. For most public services, Front Door's WAF at the edge is preferred because it filters attack traffic before it consumes regional capacity.

11. Cost considerations

Internet connectivity costs include several line items the exam can mine:

Outbound data egress dominates for high-volume workloads. The line "outbound to internet from Azure" is roughly $$0.05{-}0.087$/GB depending on volume tier. ExpressRoute Microsoft Peering can replace internet egress for traffic destined to Microsoft services (e.g., to a partner's Azure tenant in the same region).

Worked Examples

Easy — pick the egress fix

Problem. A team's 50 VMs in a subnet make outbound calls to a partner API. Under peak load, $\sim 5\%$ of requests fail with connection-refused. Recommend.

Solution. Attach an Azure NAT Gateway to the subnet with 2 Standard Public IPs. Provides $\sim 128{,}000$ SNAT ports — orders of magnitude more than the default outbound or LB SNAT. Failures stop.

Medium — global inbound architecture

Problem. A SaaS launches a global API. Customers in 5 regions. Recommend.

Solution. Layered: Front Door Premium (global AnyCast, WAF, DDoS, edge caching) $\to$ regional Application Gateway v$2$ with private backend pool $\to$ workload VMs / Container Apps. Standard Public IPs (zone-redundant) on Front Door egress; private endpoints from AppGW to backends.

Hard — secure admin + egress filtering

Problem. A regulated workload needs (a) no public IPs on VMs, (b) admin access via SSO, (c) all egress filtered with TLS inspection. Recommend.

Solution. Deploy Azure Bastion Premium for admin access via Entra ID SSO. Deploy Azure Firewall Premium in the hub VNet; configure UDRs on spoke subnets so all egress routes through the firewall; enable TLS inspection (Firewall Premium feature). VMs have no public IPs; outbound flows are inspected, logged, and policy-controlled.

12. Bastion deployment patterns

Three deployment patterns for Azure Bastion:

For enterprise estates with many spoke VNets, Hub Bastion is the canonical pattern: one Bastion deployment serves admin access across all peered spokes, reducing operational footprint.

[!IMPORTANT] The AzureBastionSubnet must be at least a /26 subnet (a $/27$ works for small deployments but limits Bastion scaling). The subnet name is exact — it must be named AzureBastionSubnet.

13. Front Door vs Application Gateway — boundary

The exam tests the boundary between these two L7 services. Brief reminders:

For most production stacks the two combine: Front Door at edge, AppGW inside the VNet. Choosing only one usually creates an architecture gap.

Visual Explanations

Figure 1 — Internet connectivity decision flow

Figure 2 — Hub-spoke egress topology

Figure 3 — Quick chooser

Figure 4 — End-to-end inbound + outbound topology

A complete production internet-connectivity stack typically combines several services. Inbound: clients hit a Front Door AnyCast endpoint that filters with WAF and absorbs DDoS at the edge; valid traffic reaches a regional Application Gateway over Private Link; AppGW routes to backends inside the VNet. Outbound: VMs in spoke VNets route through a hub VNet via UDRs; the hub contains Azure Firewall Premium (TLS inspection and IDPS) and a NAT Gateway that provides predictable egress IPs. Administrators connect via Azure Bastion deployed in the hub, reaching VMs in spokes through peering. Public IPs on Bastion and on the egress NAT are zone-redundant Standard SKU.

This stack is the AZ-305-canonical answer to "design our internet connectivity end-to-end". It's overkill for a single small workload; it's the right answer for any tier-1 production service.

Figure 5 — Region pair considerations

Public-facing global services should consider Azure region pairs for DR. Front Door, with its AnyCast network, naturally provides multi-region inbound. But the regional backends behind Front Door must themselves be deployed in $\ge 2$ regions for true regional fault tolerance — typically a primary region and its paired region. NAT Gateway egress IPs are per-region; partners that allowlist Azure egress IPs need to be informed of both the primary and secondary region's NAT public IPs.

[!TIP] When an external partner allowlists your egress IPs, attach a static, named Public IP to your NAT Gateway in every region and provide that list to the partner. Don't rely on dynamic IPs — they can change.

Common Mistakes

❌ Myth: "Basic Public IP works fine for now." ✅ Reality: Basic is retired (Sept 2025). Migrate to Standard before that date.

❌ Myth: "Default outbound is good enough." ✅ Reality: Default outbound is retiring. Production needs explicit egress: NAT Gateway, LB outbound rules, or per-VM public IP.

❌ Myth: "Expose RDP through an NSG rule — it's fine." ✅ Reality: Open RDP is the canonical brute-force target. Use Azure Bastion and remove public RDP / SSH entirely.

❌ Myth: "Front Door handles VNet integration." ✅ Reality: Front Door reaches backends over public IP or Private Link, not via direct VNet integration. Place an Application Gateway in the VNet if private routing is needed.

Practice Exercises

🟢 Exercise 1. A subnet's VMs hit SNAT exhaustion. Recommend.

▶✅ Solution

Attach NAT Gateway with $1{-}4$ Standard Public IPs.

🟡 Exercise 2. A global API needs WAF at the edge. Recommend.

▶✅ Solution

Front Door Premium (includes WAF + DDoS Protection).

🟡 Exercise 3. Admin access to 50 VMs without exposing RDP. Recommend.

▶✅ Solution

Azure Bastion Standard or Premium. Premium adds session recording.

🔴 Exercise 4. A regulated workload must inspect TLS traffic egressing to the internet. Recommend.

▶✅ Solution

Azure Firewall Premium with TLS inspection enabled. Place in hub VNet; UDR egress through it.

🔴 Exercise 5. A team has 200 Basic public IPs. The retirement deadline is approaching. Plan.

▶✅ Solution

Use the Microsoft-provided Basic-to-Standard migration tool (or portal). Schedule migrations in waves; verify each post-migration. Plan well before the retirement date to avoid forced upgrades.

🟢 Exercise 6. True or false: Front Door bypasses Azure DDoS Protection.

▶✅ Solution

False. Front Door has built-in DDoS protection at the edge; Premium tier extends WAF and bot management as well.

🟡 Exercise 7. Sketch Bicep for a Standard zone-redundant Public IP.

▶✅ Solution

bicepCopy

resource pip 'Microsoft.Network/publicIPAddresses@2024-03-01' = { name: 'pip-zr' location: location sku: { name: 'Standard' } zones: ['1','2','3'] properties: { publicIPAllocationMethod: 'Static' } }

Figure 6 — Outbound IPv4 exhaustion math worked through

A subnet with 200 VMs makes outbound connections to a single API. Each VM holds $\sim 50$ concurrent connections. Default outbound gives each VM $\sim 1{,}024$ SNAT ports to the destination aggregate via the shared LB — but in practice the per-VM-to-destination port pool is much smaller because of how port allocation works (~ 1 port per concurrent connection). $200 \times 50 = 10{,}000$$ concurrent connections, demanding 10{,}000$ ports to the same destination.

A NAT Gateway with 1 public IP gives \sim 64{,}000$`SNAT ports total to *all* destinations; that single IP comfortably handles`$\sim 64{,}000 concurrent connections regardless of destination distribution. With 2 public IPs the budget doubles. The math explains why NAT Gateway is the default for production: it converts the SNAT story from "fragile and shared" to "predictable and abundant".

Figure 7 — Public IP migration timeline

Microsoft retired the Basic public IP SKU in September 2025. Organisations that hadn't migrated by then experienced forced upgrades on a Microsoft-driven schedule, which can disrupt production. The recommended timeline:

Summary & Concept Map

• Standard Public IP is the only SKU for new production. Basic is retiring.
• Default outbound is retiring; use NAT Gateway, LB outbound rules, or per-VM IPs.
• NAT Gateway fixes SNAT port exhaustion — the canonical "intermittent outbound failures" diagnosis.
• Layered inbound: Front Door \\to App Gateway $\$\to$`LB`\$\to backends.
• Azure Bastion replaces direct RDP/SSH exposure.
• Azure Firewall Premium provides TLS inspection and IDPS for egress filtering.
• DDoS Network Protection is per-VNet — co-locate public IPs to optimise cost.