As Azure transitions away from direct internet access for virtual machines, it’s essential to adapt and ensure our applications continue to communicate seamlessly with external resources. In this four-part series, we’ll explore robust solutions to maintain outbound internet connectivity for Azure VMs. Kicking off with Part 1, we’ll dive deep into implementing Azure NAT Gateway using both the Azure Portal and Bicep templates.

Understanding the Shift: Why NAT Gateway?

Direct internet access for Azure VMs is being deprecated, signaling a significant shift in how outbound connectivity is handled. The NAT Gateway offers a scalable, secure, and reliable method for managing outbound internet traffic for your virtual networks.

Key Benefits of NAT Gateway:

• Simplified Management: No need for complex user-defined routing or public IP assignments on individual VMs.
• Scalability: Supports high bandwidth scenarios, automatically scaling to meet demand.
• Consistent IP Addressing: Uses static public IP addresses or prefixes, ensuring predictable outbound IPs.
• Enhanced Security: Reduces exposure by eliminating the need for public IP addresses on VMs.

Architecting the Network Topology

Designing an effective network layout is crucial. Here’s an illustrative topology:

Key Components:

• Public IP Addresses or Prefixes: Assigns specific public IPs so your outbound connections use predictable and consistent IP addresses.
• Subnet Association: Connects to subnets, ensuring all resources within automatically use the NAT Gateway for outbound internet traffic.
• Idle Timeout Configuration: Manages TCP/UDP connection timeouts, configurable from 4 to 120 minutes to suit your application’s needs.

Design Considerations:

• Scalability and Performance: Ensure the NAT Gateway can handle your application’s outbound traffic demands without becoming a bottleneck.
• Zonal Redundancy and Availability: Deploy in appropriate availability zones to enhance resilience and reduce latency.
• Cost Implications: Monitor and estimate outbound data since charges are based on hourly usage and data processed.

Part 1: Implementing NAT Gateway

Let’s get hands-on and set up a NAT Gateway using both the Azure Portal and Bicep.

Scenario Overview

Imagine you have a virtual network with multiple VMs that need outbound internet access. We’ll:

1. Create a NAT Gateway.
2. Associate it with a subnet containing VMs.
3. Verify outbound connectivity.

Implementation Using the Azure Portal

Step 1: Create a Public IP Address

1. Navigate to Public IP Addresses:
   • In the Azure Portal, search for “Public IP addresses” and select it.
2. Create a New Public IP:
   • Click "+ Create".
   • Basics Tab:
     • Subscription: Select your subscription.
     • Resource Group: Choose an existing one or create new.
     • Name: Enter a name, e.g., myNATPublicIP.
     • Region: Choose the region of your VNet.
   • IP Version: IPv4.
   • SKU: Standard.
   • Assignment: Static.
   • Click “Review + Create”, then “Create”.

Step 2: Create the NAT Gateway

1. Navigate to NAT Gateways:
   • Search for “NAT gateways” and select it.
2. Create a New NAT Gateway:
   • Click "+ Create".
   • Basics Tab:
     • Subscription: Your subscription.
     • Resource Group: Same as above.
     • Name: myNATGateway.
     • Region: Same as your VNet.
   • Idle Timeout (Minutes): Default is fine unless you have specific needs.
3. Associate Public IP:
   • Public IP Addresses: Click “Add” and select myNATPublicIP.
4. Associate with Subnet:
   • Subnet Tab:
     • Click “Configure Subnets”.
     • Select the subnet where your VMs reside.
     • Click “OK”.
5. Review and Create:
   • Click “Review + Create”, ensure validation passes.
   • Click “Create”.

Step 3: Verify Outbound Connectivity

1. Connect to a VM in the Subnet:
   • Use Remote Desktop Protocol (RDP) or SSH.
2. Check Outbound IP Address:
   • Open a web browser and navigate to ifconfig.me or ident.me
   • Verify that the displayed IP matches myNATPublicIP.

Implementation Using Bicep

Now, let’s achieve the same using Bicep, Azure’s domain-specific language for deploying resources declaratively.

Step 1: Write the Bicep Template

Create a file named natGateway.bicep.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64

@description('Name of the NAT Gateway')
param natGatewayName string = 'myNATGateway'

@description('Name of the Public IP Address')
param publicIPName string = 'myNATPublicIP'

@description('Name of the Virtual Network')
param vnetName string = 'myVNet'

@description('Name of the Subnet to associate with NAT Gateway')
param subnetName string = 'mySubnet'

@description('Location of the resources')
param location string = resourceGroup().location

@description('Idle timeout in minutes')
param idleTimeout int = 4

// Create Public IP
resource publicIP 'Microsoft.Network/publicIPAddresses@2024-05-01' = {
  name: publicIPName
  location: location
  sku: {
    name: 'Standard'
  }
  properties: {
    publicIPAllocationMethod: 'Static'
    publicIPAddressVersion: 'IPv4'
  }
}

// Create NAT Gateway
resource natGateway 'Microsoft.Network/natGateways@2024-05-01' = {
  name: natGatewayName
  location: location
  sku: {
    name: 'Standard'
  }
  properties: {
    publicIpAddresses: [
      {
        id: publicIP.id
      }
    ]
    idleTimeoutInMinutes: idleTimeout
  }
}

// Reference existing VNet
resource vnet 'Microsoft.Network/virtualNetworks@2024-05-01' existing = {
  name: vnetName
}

// Update Subnet to Associate NAT Gateway
resource subnet 'Microsoft.Network/virtualNetworks/subnets@2024-05-01' = {
  parent: vnet
  name: subnetName
  properties: {
    addressPrefix: vnet.properties.addressSpace.addressPrefixes[0]
    natGateway: {
      id: natGateway.id
    }
  }
}

Step 2: Deploy the Bicep Template

1. Login to Azure:

   1

   az login

2. Set the Subscription Context:

   1	az account set --subscription 'YourSubscriptionID'

3. Deploy the Template:

   1 2 3 4 5 6 7

   az deployment group create \\ --resource-group 'YourResourceGroup' \\ --template-file natGateway.bicep \\ --parameters natGatewayName='myNATGateway' \\ publicIPName='myNATPublicIP' \\ vnetName='myVNet' \\ subnetName='mySubnet'

Step 3: Verify Deployment

Repeat the verification steps from the portal implementation to confirm that your VMs are using the NAT Gateway for outbound traffic.

Wrapping Up

Implementing a NAT Gateway is a vital step in adapting to the deprecation of direct internet access for Azure VMs. By using both the Azure Portal and Bicep, we’ve explored flexible methods to deploy and manage NAT Gateways, catering to different preferences and operational needs.

Key Takeaways:

• NAT Gateway Simplifies Outbound Connectivity: It streamlines internet access management for your VMs.
• Bicep Offers Infrastructure as Code Benefits: Enables repeatable, version-controlled deployments.

Learn More

• Explore Azure NAT Gateway Documentation for in-depth knowledge.
• Check out Bicep Learning Path to master infrastructure as code on Azure.
• Experiment with Azure’s Network Watcher to monitor and diagnose network issues.