Cloud Networking

What it is

A Virtual Private Cloud (VPC) is a logically isolated section of the cloud provider's network where you deploy resources with full control over IP address ranges, subnets, routing tables, and network gateways. AWS VPC, GCP VPC, and Azure Virtual Network all follow the same conceptual model. The canonical three-tier subnet structure separates network tiers by security zone: public subnets (internet-facing, hosts ALBs and NAT Gateways), private subnets (application layer, no direct internet access, egress through NAT), and isolated subnets (data layer, no internet egress, accessible only from the private tier). Each tier is replicated across all Availability Zones (typically 3) for redundancy.

CIDR planning is a critical upfront decision that is extremely difficult to change later. The VPC CIDR block (/16 is common, providing 65,536 addresses) must not overlap with on-premises networks (for Direct Connect/VPN connectivity) or with other VPCs that will be peered together. Reserve non-overlapping /16 blocks per environment (dev, staging, prod) and per region, drawing from RFC 1918 space (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Subnets are typically /24 (256 addresses, minus 5 reserved by AWS = 251 usable) per AZ per tier. A common pattern: VPC 10.0.0.0/16, public subnets 10.0.0.0/24, 10.0.1.0/24, 10.0.2.0/24 (one per AZ), private subnets 10.0.10.0/24, 10.0.11.0/24, 10.0.12.0/24, isolated subnets 10.0.20.0/24, 10.0.21.0/24, 10.0.22.0/24.

Why it exists

Network security in cloud environments relies on the principle of least-privilege network access. Placing a database in a public subnet (internet-accessible) is the single most common cause of cloud data breaches — the subnet strategy enforces that databases are physically unreachable from the internet even if security group rules are misconfigured. The three-tier model provides defence-in-depth: an attacker who compromises an internet-facing ALB cannot directly reach the database because there is no route from the public subnet to the isolated subnet in the routing tables, regardless of security group configuration.

Multi-VPC architectures are now standard: separate VPCs per environment (dev/staging/prod) prevent lateral movement, and separate VPCs per product team (in a multi-account structure) enforce blast radius isolation. Connecting these VPCs requires either VPC Peering (direct 1:1 connection, non-transitive — if A peers with B and B peers with C, A cannot reach C through B) or Transit Gateway (hub-spoke model, transitive routing, supports hundreds of VPCs, enables centralised packet inspection through firewall appliances). Transit Gateway is the correct choice for any organisation with more than 3–4 VPCs.

When to use

• Three-tier subnet structure: all production workloads — apply unconditionally; the cost is minimal, the security benefit is significant.
• Transit Gateway: organisations with multiple VPCs (5+), multi-account landing zones, or requirements for centralized egress inspection through a firewall appliance.
• PrivateLink: exposing a service to consumers (internal or external partner) without exposing it to the internet or requiring VPC peering for the consumer's VPC.
• Route 53 Latency Routing: global applications where users should automatically connect to the lowest-latency region endpoint.
• Route 53 Failover Routing: active-passive DR configurations where DNS should automatically redirect to a standby endpoint when the primary health check fails.

When not to use

• VPC Peering for large mesh networks: Peering 10 VPCs requires 45 peering connections (fully meshed); Transit Gateway handles this with 10 attachments and centralised routing — VPC peering does not scale beyond a small number of VPCs.
• CloudFront for internal APIs: CloudFront is designed for public internet content delivery; internal microservice-to-microservice traffic should use service mesh or internal ALBs, not CloudFront.
• Route 53 Geolocation for performance: Geolocation routing routes based on client's DNS resolver country, not latency; use Latency Routing for performance and Geolocation only for regulatory data residency requirements (EU users must reach EU endpoints).
• NAT Gateway in every subnet: NAT Gateways are AZ-scoped; a common mistake is deploying one NAT Gateway in a single AZ and routing all private subnets through it — if that AZ fails, all outbound internet access fails; deploy one NAT Gateway per AZ.

Typical architecture

Multi-AZ VPC Layout (AWS)
──────────────────────────────────────────────────────────
  Internet Gateway
        │
  ┌─────┴──────────────┐
  │   Public Subnet     │ (ALB, NAT Gateway, Bastion)
  │  10.0.0.0/24 (AZ-a)│
  │  10.0.1.0/24 (AZ-b)│
  │  10.0.2.0/24 (AZ-c)│
  └─────┬──────────────┘
  NAT Gateway (per AZ)
        │
  ┌─────┴──────────────┐
  │   Private Subnet    │ (ECS tasks, Lambda, EC2)
  │ 10.0.10.0/24 (AZ-a)│
  └─────┬──────────────┘
        │ no internet route
  ┌─────┴──────────────┐
  │  Isolated Subnet    │ (RDS, ElastiCache)
  │ 10.0.20.0/24 (AZ-a)│
  └────────────────────┘

Multi-VPC Hub-Spoke (Transit Gateway)
──────────────────────────────────────────────────────────
  VPC prod          VPC dev           VPC shared-services
      \                 |                   /
       ─────── Transit Gateway ────────────
                        │
               Centralised Egress VPC
                (AWS Network Firewall + NAT GW)
                        │
                  Internet

Route 53 DNS Failover
──────────────────────────────────────────────────────────
  api.example.com (ALIAS)
    → Primary record (us-east-1 ALB)
        Health check → ALB target groups
        If UNHEALTHY →
    → Secondary record (eu-west-1 ALB, FAILOVER policy)

Pros and cons

Implementation notes

Plan CIDR allocations in a IPAM (IP Address Management) system before provisioning VPCs. AWS VPC IP Address Manager (IPAM) provides a central registry of allocated CIDRs across accounts and regions, preventing overlaps. As a sizing guideline: allocate /16 VPCs, /18 per environment tier (public/private/isolated × 3 AZs = 6 subnets = 6 × /24 minimum); this leaves room within the /16 for future expansion. For NAT Gateway cost optimisation: use VPC Gateway Endpoints for S3 and DynamoDB (free, no data processing charge) and VPC Interface Endpoints for ECR, STS, SSM, and other frequently called AWS APIs — this eliminates NAT Gateway charges for all AWS API traffic from private subnets.

For Route 53 DNS failover: configure health checks at the load balancer layer (ALB target group level), and set EvaluateTargetHealth=true on Route 53 Alias records — this means Route 53 will only return the ALB's IP address if the ALB's target group has healthy targets. Set DNS TTL to 30–60 seconds for failover records to minimise propagation delay. For CloudFront distributions, configure Cache-Control: max-age headers at the origin to control CloudFront caching behaviour rather than relying on CloudFront default TTLs; use CloudFront Functions at the edge for request/response manipulation (add security headers, rewrite URLs) without Lambda@Edge cold starts.

Common failure modes

• Overlapping CIDR blocks: Two VPCs that need to be peered have overlapping CIDR ranges; VPC Peering rejects the connection and the only resolution is rebuilding one VPC; prevent by using IPAM.
• Single NAT Gateway: All private subnets in all AZs route through a single NAT Gateway in AZ-a; if AZ-a fails, all outbound internet access fails even for resources in AZ-b and AZ-c; deploy one NAT Gateway per AZ.
• Security group over-permissiveness: Security group rules created with 0.0.0.0/0 source on database ports during development and never restricted; enable AWS Config rule restricted-ssh and rds-instance-public-access-check as detective controls.
• Missing VPC Flow Logs: A security incident occurs but there are no VPC Flow Logs to reconstruct the network access pattern; enable Flow Logs at the VPC level to S3 with 90-day retention as a minimum baseline.
• Route 53 health check URL mismatch: Health check URL returns 200 even when the application is degraded (a shallow health check); configure health checks to hit a deep health endpoint that validates database connectivity.

Decision checklist

• Are all production VPCs using a three-tier subnet structure with databases in isolated subnets with no internet routing?
• Has CIDR allocation been planned in IPAM to prevent future overlapping conflicts across environments and regions?
• Is there one NAT Gateway deployed per Availability Zone to prevent AZ-failure cascading to outbound internet access?
• Are VPC Endpoints configured for S3, DynamoDB, and common AWS APIs to reduce NAT Gateway data processing costs?
• Are VPC Flow Logs enabled to S3 with appropriate retention for security investigation and compliance requirements?
• For multi-region applications, are Route 53 health checks configured with deep health endpoints and appropriate failover policies?

Example use cases

• SaaS platform global delivery: CloudFront distribution in front of S3 (static assets) and ALB (API); Route 53 latency routing directs users to the lowest-latency ALB across us-east-1, eu-west-1, ap-southeast-1; CloudFront cache hit rate of 85% reduces API origin calls and latency for cacheable responses.
• Multi-account enterprise network: 15 AWS accounts (dev, staging, prod per business unit) connected via Transit Gateway in a networking account; centralised egress through AWS Network Firewall with domain-based filtering; PrivateLink used to expose shared services (internal auth, data platform) to workload VPCs without IP routing complexity.
• Active-passive DR: Production in us-east-1 with Route 53 failover health check; Route 53 Alias record points to us-east-1 ALB with EvaluateTargetHealth=true; secondary record points to eu-west-1 warm standby; failover test confirmed 75-second DNS propagation time to all major resolver networks.

Related patterns

• Landing Zones — VPC design and Transit Gateway topology are core components of a landing zone network architecture.
• Disaster Recovery Patterns — Route 53 failover routing is the DNS layer for regional DR failover.
• Security Architecture — network segmentation and least-privilege network access are foundational security controls.

Further reading

• VPC Network ACLs — Amazon VPC User Guide
• Designing Hyperscale VPC Networks — AWS Blog
• Route 53 Routing Policies — Developer Guide