Universal Cloud Networking Flows: CIDR, Subnets & NAT Across AWS, Azure, and GCP 🌐

1. Universal Foundation: CIDR (Classless Inter-Domain Routing)

Before analyzing how AWS, Microsoft Azure, and Google Cloud Platform (GCP) route traffic internally, every cloud engineer must master CIDR (Classless Inter-Domain Routing). Developed to supersede the inflexible classful network addressing system (Classes A, B, and C), CIDR allows architects to allocate right-sized IP address blocks with zero address wastage.

At its operational core, CIDR relies on Variable-Length Subnet Masking (VLSM). This enables an enterprise to carve out micro-subnets suited for specific workloads—such as small /28 subnets for external load balancers or extensive /20 blocks for high-density Kubernetes pods.

CIDR Block Breakdown (192.168.1.0/24)

• 192.168.1.0: The base network address identifying the subnet boundary.
• /24: The prefix length indicating that the first 24 bits out of the 32-bit IPv4 address are dedicated to the Network ID, leaving 8 bits for host allocation.

IPv4 Total Length            : 32 bits (4 Octets / 4 Bytes)
Network Bits (First 24 bits) : 11000000.10101000.00000001
Host Bits (32 - 24 = 8 bits) : .00000000

Total Theoretical IPs        : 2^8 = 256 IP addresses
Standard Usable Hosts        : 256 - 2 = 254 usable IPs (Network .0 and Broadcast .255 reserved)
*Cloud Provider Reservations : AWS and Azure reserve 5 IPs per subnet; GCP reserves 4 IPs per subnet.

Benefits of CIDR in Modern Cloud Engineering

• Precision IP Provisioning: Prevents address exhaustion in large containerized environments.
• Route Summarization (Supernetting): Reduces border gateway routing table entries by aggregating multiple continuous subnets into single upstream declarations.
• Multi-Cloud Interconnectivity: Mitigates route poisoning and overlapping collisions when peering AWS VPCs, Azure VNets, and GCP networks with corporate on-premises datacenters.

2. Types of Network IPs: Public vs. Private (RFC 1918)

IP space within public clouds is bifurcated into two routing domains:

• Public IP Addresses: Globally unique IPv4 addresses routable over the public internet, assigned to edge devices like Internet Gateways, Application Load Balancers, and NAT Gateways.
• Private IP Addresses (RFC 1918): Non-routable addresses designated exclusively for internal VPC/VNet communications. Instances in private subnets require outbound Network Address Translation (NAT) or proxy gateways to reach external repositories and APIs.

🌐 IPv4 Address Class Ranges

Note: The 127.0.0.0/8 block (e.g., 127.0.0.1) is strictly reserved for local host Loopback testing.

🔒 RFC 1918 Private IPv4 Address Ranges

3. Cloud Networking Architecture: AWS & Azure (Regional) vs. GCP (Global)

While subnetting mathematics remain consistent, the topological boundary of a Virtual Network differs fundamentally between major cloud providers:

• AWS VPC & Azure VNet (Regional Scope): An AWS VPC or Azure VNet is bound to a single physical geographical region. To link workloads across multiple regions, architects must explicitly create and manage inter-region transit routing via VPC/VNet Peering, AWS Transit Gateway, or Azure Virtual WAN.
• Google Cloud VPC (Global Scope): A GCP VPC is a global software-defined network spanning all Google regions simultaneously. The VPC construct itself has no overarching CIDR block; instead, individual Subnets are Regional. Virtual machines deployed in separate regions inside the same VPC can communicate over Google's global fiber backbone privately out-of-the-box without peering gateways.

Multi-Cloud Virtual Network Comparison Matrix

4. Private Subnet to Internet Flow: How NAT Gateways Work

In production environments, backend compute nodes and databases must never hold direct public IP addresses. To facilitate outbound software patching, container pulling, or external API consumption, traffic is routed through a managed Network Address Translation (NAT) Gateway.

Architectural Comparison of Outbound NAT Flows

[1] AWS Outbound Flow (Public Subnet Proxy Model):
Private EC2 (10.0.2.15) 
  ──► Private Route Table (0.0.0.0/0 -> nat-gw-id) 
  ──► NAT Gateway (Placed in Public Subnet + Elastic IP attached) 
  ──► Public Route Table (0.0.0.0/0 -> igw-id) 
  ──► Internet Gateway (IGW) ──► Public Internet

[2] Azure Outbound Flow (Direct Subnet Attachment Model):
Private VM (10.1.1.10) 
  ──► Azure NAT Gateway (Directly associated with the Subnet + Standard Public IP attached) 
  ──► Azure Edge Fabric (No Public Subnet or manual User-Defined Routes required!)

[3] GCP Outbound Flow (Software-Defined Gateway Model):
Regional VM (10.2.0.5 - No External IP) 
  ──► Cloud NAT + Cloud Router (Kernel-level Software Defined + External Static IP) 
  ──► Default Internet Gateway Route ──► Public Internet

Deep Dive: AWS NAT Gateway & Elastic IP Rules

Implementing an AWS NAT Gateway involves strict architectural rules:

5. Multi-Cloud Production Pitfalls & Troubleshooting Guide

Operating hybrid or multi-cloud topologies introduces subtle routing and transport layer failure modes. Here are the three most frequent production bottlenecks and their remedies:

1. CIDR Overlap in Cloud Interconnects

When peering an AWS VPC with an Azure VNet or on-premises datacenter, IP spaces must never overlap. If both networks declare 10.0.0.0/16, routing engines cannot determine the next hop, causing dropped packets.

Remedy: If IP reallocation is impossible, implement Bidirectional NAT (Private NAT) using tools like AWS Private NAT Gateway, Azure Private Link, or an intermediate proxy pool to translate overlapping subnets into unique virtual IP ranges.

2. SNAT Port Exhaustion

A single public IP assigned to a NAT Gateway provides approximately 64,000 concurrent Source Network Address Translation (SNAT) ports. When thousands of container pods or lambda functions open high-frequency microservice connections concurrently to the same external IP, SNAT ports deplete, resulting in connection timeouts.

Remedy: In Azure and GCP, associate multiple public IP addresses (up to 16 in Azure) to the NAT Gateway to scale total port capacity. In AWS, deploy secondary private NATs or use VPC Interface Endpoints (AWS PrivateLink) to keep internal AWS API calls completely off the NAT Gateway.

3. MTU / MSS Clamping Mismatches (Packet Fragmentation)

Standard Ethernet frames use an MTU of 1500 bytes. However, when traffic traverses an encrypted IPSec VPN tunnel between AWS and Azure, tunnel headers (ESP and UDP encapsulation) consume additional bytes. If the Maximum Transmission Unit (MTU) remains at 1500, oversized packets get fragmented or silently dropped if the Don't Fragment (DF) flag is set.

Remedy: Configure MSS (Maximum Segment Size) Clamping to 1360 or 1380 bytes on your transit gateway or border firewalls, ensuring TCP sessions dynamically negotiate segment sizes that fit inside the encrypted tunnel overhead without fragmentation.