Cloud Networking
Virtual Private Cloud (VPC)
A VPC is a logically isolated network within a cloud provider, giving full control over IP addressing, routing, and security.
VPC Architecture
┌─────────────────── VPC: 10.0.0.0/16 ───────────────────┐
│ │
│ ┌─── AZ-a ──────────────┐ ┌─── AZ-b ──────────────┐ │
│ │ │ │ │ │
│ │ Public: 10.0.1.0/24 │ │ Public: 10.0.3.0/24 │ │
│ │ ┌──────┐ ┌──────┐ │ │ ┌──────┐ ┌──────┐ │ │
│ │ │ Web │ │ NAT │ │ │ │ Web │ │ NAT │ │ │
│ │ └──────┘ └──────┘ │ │ └──────┘ └──────┘ │ │
│ │ │ │ │ │
│ │ Private: 10.0.2.0/24 │ │ Private: 10.0.4.0/24 │ │
│ │ ┌──────┐ ┌──────┐ │ │ ┌──────┐ ┌──────┐ │ │
│ │ │ App │ │ DB │ │ │ │ App │ │ DB │ │ │
│ │ └──────┘ └──────┘ │ │ └──────┘ └──────┘ │ │
│ └────────────────────────┘ └────────────────────────┘ │
│ │
│ ┌──────────────────┐ │
│ │ Internet Gateway │ │
│ └──────────────────┘ │
└──────────────────────────────────────────────────────────┘
Key VPC Components
| Component | Purpose |
|---|---|
| Internet Gateway | Enables internet access for public subnets |
| NAT Gateway | Allows private subnets outbound internet access |
| Route Table | Directs traffic between subnets and gateways |
| DHCP Options | Configures DNS and NTP for instances |
| VPC Endpoints | Private access to cloud services without internet |
Subnets
Public vs Private Subnets
Public subnet: Route table has a route to the Internet Gateway. Resources can receive public IPs.
Private subnet: No route to the Internet Gateway. Outbound internet through NAT Gateway only.
CIDR Planning
/16 = 65,536 IPs → VPC level
/20 = 4,096 IPs → Large subnet
/24 = 256 IPs → Standard subnet (251 usable in AWS)
/28 = 16 IPs → Small subnet (11 usable in AWS)
AWS reserves 5 IPs per subnet:
.0 = Network, .1 = VPC router, .2 = DNS, .3 = Reserved, .255 = Broadcast
Best practice: Plan CIDR ranges to avoid overlap when peering VPCs or connecting to on-premises.
Security Groups and NACLs
Security Groups (Stateful)
┌─── Security Group: web-sg ──────────────────┐
│ │
│ Inbound: │
│ TCP 443 from 0.0.0.0/0 (HTTPS) │
│ TCP 80 from 0.0.0.0/0 (HTTP) │
│ │
│ Outbound: │
│ All traffic to 0.0.0.0/0 (default) │
│ │
│ ✓ Stateful: return traffic auto-allowed │
│ ✓ Allow rules only (implicit deny) │
│ ✓ Applies at instance/ENI level │
└──────────────────────────────────────────────┘
Network ACLs (Stateless)
| Feature | Security Group | NACL |
|---|---|---|
| Level | Instance (ENI) | Subnet |
| Statefulness | Stateful | Stateless |
| Rules | Allow only | Allow and Deny |
| Rule evaluation | All rules evaluated | Numbered order, first match |
| Default | Deny all inbound | Allow all |
Use NACLs as a secondary defense layer; rely on Security Groups as the primary control.
Load Balancers
Application Load Balancer (ALB) - Layer 7
Client ──► ALB ──► Target Group A (path: /api/*)
──► Target Group B (path: /web/*)
──► Target Group C (host: api.example.com)
- Protocols: HTTP, HTTPS, gRPC, WebSocket
- Routing: Path-based, host-based, header-based, query string
- Features: SSL termination, sticky sessions, authentication (OIDC/Cognito)
- Targets: Instances, IPs, Lambda functions, containers
Network Load Balancer (NLB) - Layer 4
- Protocols: TCP, UDP, TLS
- Performance: Millions of requests per second, ultra-low latency
- Static IP: One per AZ, supports Elastic IPs
- Use cases: Gaming, IoT, TCP pass-through, non-HTTP protocols
- Preserves source IP without X-Forwarded-For headers
Gateway Load Balancer (GWLB) - Layer 3
- Deploys and scales third-party virtual appliances (firewalls, IDS/IPS)
- Uses GENEVE encapsulation for transparent traffic inspection
- Integrates with the VPC route table as a next-hop target
GCP and Azure Equivalents
| Function | AWS | GCP | Azure |
|---|---|---|---|
| HTTP(S) LB | ALB | External HTTP(S) LB | Application Gateway |
| TCP/UDP LB | NLB | Network LB | Azure Load Balancer |
| Internal LB | Internal ALB/NLB | Internal HTTP(S) LB | Internal LB |
| Global LB | Global Accelerator | Global External LB | Front Door |
DNS - Route 53 and Cloud DNS
Route 53 Features
- Hosted zones: Public (internet) and private (VPC-only) DNS
- Health checks: Monitor endpoint health, trigger failover
- Domain registration: Purchase and manage domains directly
Routing Policies
| Policy | Behavior | Use Case |
|---|---|---|
| Simple | Single resource | Basic resolution |
| Weighted | Distribute by percentage | A/B testing, blue-green |
| Latency-based | Nearest region by latency | Global apps |
| Failover | Primary/secondary with health check | Disaster recovery |
| Geolocation | Route by user's geography | Data sovereignty |
| Multivalue | Return multiple healthy IPs | Simple load distribution |
CDN - CloudFront and Equivalents
How CDNs Work
User ──► Edge Location (cache hit?) ──► Yes: Return cached content
└── No: Fetch from origin
├── S3 bucket
├── ALB
├── Custom origin
└── Cache + return
CloudFront Features
- Edge functions: CloudFront Functions (viewer events), Lambda@Edge (all events)
- Origin Access Control: Restrict S3 access to CloudFront only
- Field-level encryption: Encrypt specific POST fields at the edge
- Real-time logs: Stream access logs to Kinesis Data Streams
- Cache policies: Separate cache key configuration from origin request
Other CDNs
- GCP Cloud CDN: Integrated with External HTTP(S) Load Balancer
- Azure CDN / Front Door: Global routing with WAF integration
- Cloudflare: Provider-agnostic CDN with Workers edge compute
Hybrid Connectivity
VPN (Site-to-Site)
On-Premises ──── IPSec Tunnel ────► Virtual Private Gateway ──► VPC
│ │
Customer AWS-managed
Gateway endpoint
- Encrypted traffic over public internet
- Up to 1.25 Gbps per tunnel (AWS), dual tunnels for HA
- Quick to set up, cost-effective for moderate bandwidth
Direct Connect / Dedicated Interconnect
| Feature | AWS Direct Connect | GCP Interconnect | Azure ExpressRoute |
|---|---|---|---|
| Bandwidth | 1-100 Gbps | 10-200 Gbps | 1-100 Gbps |
| Latency | Consistent, low | Consistent, low | Consistent, low |
| Encryption | MACsec (optional) | MACsec (optional) | MACsec (optional) |
| Setup time | Weeks to months | Weeks to months | Weeks to months |
Use Direct Connect for high-throughput, latency-sensitive hybrid workloads.
Transit Gateway
Hub-and-Spoke Topology
┌─── VPC A ──────┐
│ │
VPN ─────┼── Transit GW ──┼── VPC B
│ │
DX ──────┼ ├── VPC C
│ │
└─── VPC D ──────┘
- Centralized routing between VPCs, VPNs, and Direct Connect
- Supports transitive peering (VPC A can reach VPC C through TGW)
- Route tables for network segmentation
- Inter-region peering for global transit networks
Without Transit Gateway, VPC peering is non-transitive and requires N*(N-1)/2 connections.
PrivateLink
Expose services privately without traversing the public internet.
Consumer VPC Provider VPC
┌──────────────┐ ┌──────────────┐
│ VPC Endpoint │◄── Private Link ───►│ Endpoint │
│ (ENI in your │ (AWS backbone) │ Service (NLB)│
│ subnet) │ │ │
└──────────────┘ └──────────────┘
- Interface VPC Endpoints: Access AWS services (S3, DynamoDB, SQS) privately
- Endpoint Services: Expose your own services to other VPCs/accounts
- Traffic stays on the AWS network, never touches the internet
- No need for VPC peering, NAT, or IGW
GCP Private Service Connect
- Similar to PrivateLink, consumer-initiated private connectivity
- Supports Google APIs and third-party managed services
- Uses forwarding rules rather than ENIs
Key Takeaways
- VPCs provide network isolation; segment with public/private subnets across AZs
- Security Groups (stateful, instance-level) are the primary access control mechanism
- ALBs handle HTTP routing; NLBs handle TCP/UDP with ultra-low latency
- Route 53 routing policies enable failover, latency-based, and geographic routing
- CDNs reduce latency by caching at edge locations near users
- Transit Gateway simplifies multi-VPC architectures with hub-and-spoke routing
- PrivateLink keeps service-to-service traffic on the provider backbone