1. VPC CIDR Design

Careful CIDR planning prevents IP conflicts when VPCs peer, connect via Transit Gateway, or bridge to on-premises networks.


CIDR Planning Rules 1) VPCs that will peer or connect via Transit Gateway MUST have non-overlapping CIDRs. 2) Plan for growth: use /16 (65K IPs) for large VPCs, /20–/22 for smaller. 3) Reserve CIDRs for future VPCs and on-premises networks. 4) AWS minimum VPC CIDR = /28 (16 IPs), maximum = /16 (65,536 IPs). 5) You can add secondary CIDRs to existing VPCs (up to 5).

Subnet Design Best Practices

VPC CIDR Design Example (10.0.0.0/16):

  VPC: 10.0.0.0/16 (65,536 IPs)

  AZ-a:
    Public:  10.0.1.0/24  (251 usable IPs)
    Private: 10.0.10.0/24 (app tier)
    Private: 10.0.20.0/24 (DB tier)

  AZ-b:
    Public:  10.0.2.0/24
    Private: 10.0.11.0/24 (app tier)
    Private: 10.0.21.0/24 (DB tier)

  AZ-c:
    Public:  10.0.3.0/24
    Private: 10.0.12.0/24 (app tier)
    Private: 10.0.22.0/24 (DB tier)

  Reserved: 10.0.100.0/22 (future Lambda ENIs, endpoints)

  AWS reserves 5 IPs per subnet: .0 (network), .1 (VPC router),
  .2 (DNS), .3 (future), .255 (broadcast)
  1. 3-tier subnets: public (ALB, NAT GW), private app (EC2, ECS), private data (RDS, ElastiCache)
  2. Separate subnets per AZ (minimum 2 AZs for HA, ideally 3)
  3. Large subnets for Lambda: ENIs consume IPs rapidly in VPC-connected Lambda functions
  4. Use /19 or /20 per subnet if expecting many ENIs (Lambda, ECS)

2. VPC Connectivity Architecture


Connectivity Options Comparison

Peering vs Transit Gateway VPC Peering = point-to-point, lowest cost, lowest latency. Best for 2–3 VPC connections. Transit Gateway = hub-and-spoke, scales to thousands, transitive routing, centralized management. Best for 4+ VPCs, hybrid networking, complex routing. TGW has per-GB data processing charges; peering does not.

3. Transit Gateway Architecture

Transit Gateway Hub-and-Spoke:

                  On-Premises DC
                       |
                  VPN / Direct Connect
                       |
               Transit Gateway (hub)
           /      |       |       \
       VPC-A   VPC-B   VPC-C   VPC-D
       (Prod)  (Dev)   (Shared) (Security)

  Route Tables:
    Prod RT:   VPC-A → Shared, Security, On-Prem
    Dev RT:    VPC-B → Shared, On-Prem (NO access to Prod)
    Shared RT: VPC-C → All VPCs + On-Prem

  TGW Route Tables enable network segmentation.

Transit Gateway Key Features

  1. Route tables: segment traffic (prod can’t reach dev, all reach shared services)
  2. Multi-cast: supported on Transit Gateway (rare on exam)
  3. Cross-Region peering: connect TGWs across Regions for global routing
  4. Appliance mode: route traffic through inspection VPC (firewall appliance) via TGW
  5. RAM sharing: share TGW across accounts via AWS Resource Access Manager
  6. ECMP (Equal-Cost Multi-Path): aggregate VPN bandwidth (multiple tunnels)

4. Network Segmentation Patterns

5. Hybrid DNS


  1. Route 53 Resolver: DNS service for VPC. Resolves both public and private hosted zones.
  2. Resolver Inbound Endpoints: on-premises DNS queries → Route 53 Resolver (resolve AWS private zones from on-prem)
  3. Resolver Outbound Endpoints: Route 53 → on-premises DNS (resolve on-prem domains from AWS)
  4. Resolver Rules: forward specific domains to on-prem DNS. Share rules cross-account via RAM.
  5. Use for: hybrid environments where both AWS and on-prem need to resolve each other’s DNS
Hybrid DNS Architecture:

  On-Premises DNS          AWS VPC
  (corp.internal)          (Route 53 Resolver)
       |                        |
  Outbound Endpoint ──→ Resolve corp.internal on-prem
       |                        |
  Inbound Endpoint  ──→ Resolve aws. internal from on-prem

  Resolver Rule: *.corp.internal → forward to 10.0.0.2 (on-prem DNS)
Exam Tip Advanced VPC: "Connect many VPCs" = Transit Gateway (hub-and-spoke). "Connect 2 VPCs" = Peering (cheaper, simpler). "Segment traffic" = TGW Route Tables. "Inspect all traffic" = Inspection VPC + Network Firewall. "On-prem DNS resolution" = Route 53 Resolver Inbound/Outbound Endpoints. "No overlapping CIDRs" = required for peering/TGW. "Lambda ENIs" = large subnets needed.