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

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

Before diving into how AWS, Azure, and Google Cloud route traffic, every cloud network relies on CIDR (Classless Inter-Domain Routing). CIDR is the universal method for allocating IP addresses and IP routing, developed to replace the older, wasteful class-based network addressing system (Class A, B, and C).

At its core, CIDR uses Variable-Length Subnet Masking (VLSM). Instead of fixed network sizes, CIDR allows a cloud virtual network to be divided into smaller, right-sized subnets.

CIDR Block Breakdown (192.168.1.0/24)

• 192.168.1.0: The network address or base IP address of the block.
• /24: The CIDR suffix (prefix length), indicating how many bits out of the 32-bit IPv4 address are locked for the Network ID.

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 Possible IPs           : 2^8 = 256 IP addresses
Standard Usable Hosts        : 256 - 2 = 254 usable IPs (Network .0 and Broadcast .255 reserved)
*Note: Cloud providers reserve additional IPs per subnet (AWS & Azure reserve 5 IPs; GCP reserves 4 IPs).

Benefits of CIDR in Cloud Environments

• Efficient IP Allocation: Cloud architects can carve out /24, /26, or /28 subnets matching exact microservice or Kubernetes node requirements.
• Reduced Routing Table Size: Route aggregation summarizes multiple smaller subnets into a single supernet route entry.
• Hierarchical Multi-Cloud Routing: Prevents overlapping IP ranges when connecting on-premises data centers to AWS, Azure, and GCP via VPN or Dedicated Interconnects.

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

Across all cloud providers, IP addresses are split into two scopes:

• Public IP Addresses: Globally unique, assigned by IANA/RIRs, and directly routable over the public internet (assigned to Internet Gateways, Load Balancers, and NAT Gateways).
• Private IP Addresses (RFC 1918): Reserved exclusively for internal virtual networks (VPCs/VNets). They are not routable on the public internet and require NAT (Network Address Translation) to reach external APIs or software repositories.

🌐 IPv4 Address Class Ranges

Note: 127.0.0.0/8 (typically 127.0.0.1) is reserved for host Loopback testing.

🔒 Private IPv4 Address Ranges (Used for Cloud VPCs & VNets)

Binary Representation: Network ID (1) vs. Host ID (0)

# 32 Bits Total -> 8 Bits = 1 Byte -> 32 / 8 = 4 Octets
Class A (N.H.H.H) : 11111111 . 00000000 . 00000000 . 00000000  (255.0.0.0)
Class B (N.N.H.H) : 11111111 . 11111111 . 00000000 . 00000000  (255.255.0.0)
Class C (N.N.N.H) : 11111111 . 11111111 . 11111111 . 00000000  (255.255.255.0)

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

While CIDR and Private IPs work the same everywhere, the logical boundary of a Virtual Network differs dramatically between AWS/Azure and Google Cloud:

• AWS & Microsoft Azure are Regional: A Virtual Network (AWS VPC or Azure VNet) lives inside a single Region. To connect resources across different regions, you must explicitly link separate networks using VPC/VNet Peering, AWS Transit Gateway, or Azure Virtual WAN.
• Google Cloud (GCP) is Global: A GCP VPC is a global, universal network spanning all regions across the world simultaneously. The VPC itself has no CIDR range; instead, each Subnet is Regional and holds its own CIDR range. VMs in different continents inside the same GCP VPC communicate privately by default over Google's backbone without peering!

🟠 AWS VPC (Regional)

• VPC Scope: Regional (e.g., ap-south-1)
• Subnet Scope: Zonal (Tied to 1 Availability Zone)
• Cross-Region Flow: Requires VPC Peering or Transit Gateway.

🔵 Azure VNet (Regional)

• VNet Scope: Regional (e.g., Central India)
• Subnet Scope: Regional (Spans all AZs in that Region)
• Cross-Region Flow: Requires Global VNet Peering or Virtual WAN.

🟢 GCP VPC (Global)

• VPC Scope: Global (Universal across all regions)
• Subnet Scope: Regional (Spans all Zones in a Region)
• Cross-Region Flow: Built-in! Subnets in US and India route privately out-of-the-box.

Multi-Cloud Virtual Network Comparison Matrix

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

Across all clouds, production databases and application servers are placed in Private Subnets (no public IPs assigned to VMs). To download OS patches or call external APIs without exposing the servers to inbound internet attacks, traffic flows out through a NAT (Network Address Translation) Gateway.

Visualizing the Outbound NAT Flow Across Clouds

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

[2] Azure Outbound Flow (Direct Subnet Attachment Model):
Private Subnet VM (10.1.1.10) 
  ──► Azure NAT Gateway (Directly attached to Private Subnet + Uses Standard Public IP) 
  ──► Azure Internet Backbone (No Public Subnet or manual Route Table required!)

[3] GCP Outbound Flow (Software-Defined Global VPC Model):
Regional Subnet VM (10.2.0.5 - No External IP) 
  ──► Cloud NAT + Cloud Router (Control-Plane Software Defined + External Static IP) 
  ──► Default Internet Gateway ──► Public Internet

Deep Dive: AWS NAT Gateway & Elastic IP Rules

Because AWS uses a strict subnet-routing model, setting up a NAT Gateway in AWS requires understanding seven critical rules:

💡 Critical Prerequisite: Elastic IP (EIP) Allocation Rules

In AWS, before creating a Public NAT Gateway, an Elastic IP (EIP) must be allocated, and the Private Subnet's Route Table must be edited to route 0.0.0.0/0 traffic to the NAT Gateway.

Crucially, in AWS an Elastic IP can only be associated with ONE resource at a time:

• An EC2 Instance
• An Elastic Network Interface (ENI)
• A NAT Gateway

Note: In Azure and GCP, a single NAT Gateway can have multiple Public IPs (up to 16 in Azure) attached simultaneously to scale out SNAT ports for heavy outbound workloads.