From Physical to Virtual#

Cloud networking uses the same concepts as physical networking (subnets, routing, firewalls) but everything is software-defined and API-driven.

VPC (Virtual Private Cloud)#

An isolated virtual network within a cloud provider’s infrastructure:

flowchart TD
    subgraph VPC["VPC: 10.0.0.0/16"]
        subgraph AZa["Availability Zone A"]
            PubA["Public Subnet<br/>10.0.1.0/24"]
            PrivA["Private Subnet<br/>10.0.10.0/24"]
        end
        subgraph AZb["Availability Zone B"]
            PubB["Public Subnet<br/>10.0.2.0/24"]
            PrivB["Private Subnet<br/>10.0.11.0/24"]
        end
    end
    
    IGW["Internet Gateway"] --> PubA
    IGW --> PubB
    PubA --> NATGW["NAT Gateway"]
    NATGW --> PrivA
    NATGW --> PrivB
    Internet["Internet"] --> IGW

VPC Design Decisions#

Public vs Private Subnets#

Route Tables#

Every subnet has an associated route table:

Public Subnet Route Table:
  Destination     Target
  10.0.0.0/16     local           ← within VPC
  0.0.0.0/0       igw-abc123      ← internet via IGW

Private Subnet Route Table:
  Destination     Target
  10.0.0.0/16     local           ← within VPC
  0.0.0.0/0       nat-xyz789      ← internet via NAT (outbound only)

Security: Security Groups vs NACLs#

Typical Security Group Setup#

Web Server SG:
  Inbound:  TCP 443 from 0.0.0.0/0 (HTTPS)
  Inbound:  TCP 80 from 0.0.0.0/0 (HTTP)
  
App Server SG:
  Inbound:  TCP 8080 from Web-Server-SG (only from LB)
  
Database SG:
  Inbound:  TCP 5432 from App-Server-SG (only from app)

Key pattern: Reference security groups by ID, not CIDR — this way, rules adapt as instances scale.

VPC Connectivity#

VPC Peering#

Direct connection between two VPCs:

flowchart LR
    VPC_A["VPC A<br/>10.0.0.0/16"] <-->|"Peering<br/>(private, low-latency)"| VPC_B["VPC B<br/>172.16.0.0/16"]

• Non-transitive: A↔B and B↔C does NOT mean A↔C
• CIDRs must not overlap
• Can peer across accounts and regions

Transit Gateway#

Hub-and-spoke for connecting many VPCs:

flowchart TD
    TGW["Transit Gateway"]
    TGW --> VPC1["VPC 1 (10.0.0.0/16)"]
    TGW --> VPC2["VPC 2 (10.1.0.0/16)"]
    TGW --> VPC3["VPC 3 (10.2.0.0/16)"]
    TGW --> VPN["Site-to-Site VPN"]
    TGW --> DX["Direct Connect"]

• Transitive: all attached VPCs can communicate
• Centralized routing and security
• Scales to thousands of VPCs

When to Use What#

VPC Endpoints#

Access AWS services without traversing the internet:

Why Use Endpoints?#

• Security — traffic stays on AWS backbone (never touches internet)
• Performance — lower latency, no NAT Gateway bottleneck
• Cost — no NAT Gateway data processing charges for AWS API calls

DNS in VPCs#

Route 53 Resolver#

flowchart LR
    EC2["EC2 Instance"] -->|"DNS query"| R53["VPC DNS<br/>(10.0.0.2)"]
    R53 --> PHZ["Private Hosted Zone<br/>(internal.company.com)"]
    R53 --> Public["Public DNS<br/>(external domains)"]

• VPC DNS is always at VPC CIDR + 2 (e.g., 10.0.0.2)
• Private Hosted Zones resolve only within associated VPCs
• Resolver Endpoints forward DNS between VPC and on-premises

Network Architecture Patterns#

Three-Tier Architecture#

Internet → ALB (public subnet) → App (private subnet) → DB (private subnet)

Service Mesh#

Service A ←→ Sidecar Proxy ←→ Sidecar Proxy ←→ Service B
                    (mTLS, observability, routing)

Hub-and-Spoke#

Shared Services VPC (hub)
  ├── Workload VPC 1 (spoke)
  ├── Workload VPC 2 (spoke)
  └── On-premises (spoke via VPN/DX)

Key Takeaways#

1. VPC = your isolated network — design CIDR carefully (can’t change later)
2. Public subnets have IGW route; private subnets use NAT for outbound
3. Security Groups are stateful — prefer them over NACLs for instance-level control
4. Reference SGs by ID in rules — scales with auto-scaling groups
5. VPC Peering for few VPCs, Transit Gateway for many
6. VPC Endpoints save cost and improve security for AWS service access
7. Multi-AZ is the minimum for production — survive AZ failures