VPC Networking Guide: VPC, Subnets & Routing for Cloud Architects

The $2.3 Million Cloud Bill That Started With One Misconfigured Route Table

In 2023, a fintech startup scaling from zero to 200 engineers in 18 months discovered their monthly cloud bill was $2.3 million—40% above industry benchmarks. The culprit: a single misconfigured route table sending inter-VPC traffic through AWS Transit Gateway ($0.02/GB) instead of direct VPC Peering ($0.01/GB). The fix took four hours. The annual savings: $180,000.

This isn't an isolated case. According to Gartner's 2023 cloud waste analysis, organizations overpay by an average of 32% on networking costs due to suboptimal architecture. Yet cloud networking remains one of the most underinvested skill areas for engineering teams.

If you're running workloads on AWS, Azure, or Google Cloud Platform, understanding Virtual Private Cloud (VPC) design, subnet architecture, and routing logic isn't optional—it's foundational. Poor network architecture causes everything from surprise billing incidents to security vulnerabilities and performance bottlenecks that wake you up at 3 AM.

This guide covers everything you need to design, implement, and optimize cloud networking across all three major providers.

---

What Is a VPC? Core Cloud Networking Fundamentals

A Virtual Private Cloud is your network boundary in the cloud—a logically isolated section where you control IP addressing, routing, security, and connectivity. Think of it as your own private data center that exists purely as software-defined infrastructure.

When you provision a VPC, you're defining:

1. IP Address Space: An IPv4 range in CIDR notation (e.g., 10.0.0.0/16 allows 65,536 addresses)
2. IPv6 Support: Optional provider-assigned or custom ranges (available on all major platforms since 2020)
3. Availability Zone Distribution: Regional isolation for high availability
4. DNS Configuration: Domain naming, DHCP option sets, and namespace management

VPC Architecture Across Cloud Providers

Feature	AWS	Azure	GCP
Scope	Regional	Regional (VNets span single region)	Global (VPC networks span regions)
Default CIDR	172.31.0.0/16	10.0.0.0/8	10.128.0.0/9 (auto-assigned)
Max VPCs per Account	5 (soft limit, expandable)	1,000 per subscription	5 per project
Native IPv6	Yes (dual-stack)	Yes (dual-stack since 2020)	Yes (dual-stack since 2019)

AWS** organizes VPCs at the regional level. When you create a VPC in us-east-1, it's available across all Availability Zones in that region. You can peer VPCs across regions, but cross-region traffic costs more ($0.02/GB vs. $0.01/GB intra-region).

Azure uses Virtual Networks (VNets) as their VPC equivalent. Unlike AWS, Azure VNets span a single region, but you can connect them globally using Virtual WAN or Global VNet Peering (preview for most regions). Azure's address space must be larger than /16 and smaller than /8.

GCP takes a fundamentally different approach. VPC networks are global by default—no regional separation. This simplifies multi-region architecture but requires careful firewall rule planning since resources in any region can theoretically communicate without explicit routing configuration.

Why VPC Design Matters for Cost and Performance

A well-designed VPC architecture reduces latency by keeping traffic within the same Availability Zone or region. It also minimizes data transfer costs, which can represent 15-25% of total cloud spend for data-intensive applications.

---

Subnet Architecture: Designing for High Availability and Security

Subnets are subdivisions of your VPC's address space. They operate at the Availability Zone level (AWS and Azure) or as regional segments (GCP), and they determine which resources can communicate with each other and the outside world.

Public vs. Private vs. Isolated Subnets

Public Subnets: Resources get public IP addresses and can send/receive traffic directly to the internet via an Internet Gateway (AWS), Internet Gateway (GCP), or Azure's native internet routing. Use for: load balancers, bastion hosts, CDN origins.

Private Subnets: Resources have no direct internet access. Traffic destined for the internet routes through a NAT Gateway (AWS/Azure) or Cloud NAT (GCP). Use for: application servers, databases, backend services.

Isolated Subnets: No outbound or inbound connectivity except through specific VPN or VPC Peering connections. Use for: highly sensitive workloads, compliance-required network segmentation.

Recommended Subnet Architecture Pattern

For a production web application, deploy this structure across each Availability Zone:

VPC: 10.0.0.0/16
├── Public Subnet (DMZ): 10.0.1.0/24    → ALBs, NAT Gateways
├── Application Subnet: 10.0.2.0/24     → EC2/ECS/EKS workers
├── Database Subnet: 10.0.3.0/24        → RDS, ElastiCache
└── Shared Services Subnet: 10.0.4.0/24 → EFS, S3 VPC Endpoints

Step-by-Step: Creating a Production-Ready VPC on AWS

Step 1: Define Your CIDR Blocks

Plan your IP allocation before provisioning. Reserve space for future growth—typically 2-3x your current requirement. Avoid overlapping CIDRs if you're connecting multiple VPCs.

Step 2: Create the VPC

aws ec2 create-vpc --cidr-block 10.0.0.0/16 --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=production-vpc}]'

Step 3: Enable DNS Hostnames

aws ec2 modify-vpc-attribute --vpc-id vpc-xxxxx --enable-dns-hostnames "Value=true"

Step 4: Create Subnets Across AZs

aws ec2 create-subnet --vpc-id vpc-xxxxx --cidr-block 10.0.1.0/24 --availability-zone us-east-1a
aws ec2 create-subnet --vpc-id vpc-xxxxx --cidr-block 10.0.2.0/24 --availability-zone us-east-1b

Step 5: Configure Route Tables

Attach an Internet Gateway for public subnets. Route 0.0.0.0/0 to the IGW. For private subnets, route 0.0.0.0/0 to a NAT Gateway in the public subnet.

---

Routing Fundamentals: How Traffic Flows in Your Cloud Network

Route tables are the traffic directors of your VPC. Each subnet must be associated with a route table that specifies where traffic should go based on its destination IP.

Default Routing Behavior

• Local routes: Automatically created for VPC CIDR—traffic between subnets in the same VPC uses local routes at no cost.
• Internet routes: Traffic to 0.0.0.0/0 (all internet addresses) must have a specific next hop (IGW, NAT, egress gateway).
• VPN/VPC Peering: Traffic to specific CIDR blocks routes through the peering connection or VPN tunnel.

Common Routing Mistakes That Cause Bill Shock

1. All traffic through Transit Gateway: Send only traffic that needs centralized inspection or shared services through your TGW. Use direct VPC Peering for high-volume, same-region traffic.

2. Missing Local Routes: When peering VPCs, ensure both sides have routes for each other's CIDRs. AWS VPC Peering doesn't automatically propagate routes.

3. Cross-AZ Load Balancing Without Proper Health Checks: Traffic routed to unhealthy instances in other AZs adds unnecessary cross-AZ data transfer costs (currently $0.01/GB on AWS).

VPC Routing Options Compared

Routing Method	Best Use Case	Typical Latency	Cost Considerations
Direct VPC Peering	Same-region, high-bandwidth inter-VPC	~1-2ms	Flat $0.01/GB, no hourly fees
AWS Transit Gateway	Hub-and-spoke with >10 VPCs, central inspection	~2-5ms	$0.02/GB + hourly attachment fee
Azure Virtual WAN	Global enterprise with many branches	Variable	Per-hop pricing, bandwidth tiers
GCP Network Connectivity Center	Large-scale enterprise, hybrid	~3-10ms	Based on attachment and throughput

Designing Route Tables for Security

Route tables control reachability, but they're not security tools. Combine them with:

• Security Groups: Stateful, instance-level firewalls (AWS, GCP)
• Network ACLs (NACLs): Stateless, subnet-level controls (AWS)
• Azure Firewall / NSGs: Firewall-as-a-service with threat intelligence
• GCP Firewall Rules: Project-level, always-deny ingress default

---

VPC Connectivity: Connecting Your Cloud Resources Securely

Beyond internal routing, you'll need to connect VPCs to each other, to on-premises infrastructure, and to the internet.

VPC-to-VPC Connectivity Options

AWS VPC Peering: Direct connection between two VPCs. No transit gateway, no hourly fees, and lower per-GB costs. Limitation: transitive peering is not supported (A cannot route through B to reach C).

AWS Transit Gateway: Central hub for connecting many VPCs and VPN connections. Simplifies routing but adds cost and latency for simple architectures.

AWS PrivateLink: For accessing AWS services (S3, DynamoDB, SQS) or third-party SaaS applications without traversing the public internet. Essential for compliance requirements and reducing data exposure.

Connecting to On-Premises: VPN vs. Direct Connect

Factor	Site-to-Site VPN	AWS Direct Connect
Bandwidth	Up to 1.25 Gbps (multiple tunnels)	1 Gbps to 100 Gbps
Latency	Higher (internet path)	Consistent, lower (~1-2ms)
Cost Model	Hourly + data transfer	Hourly port fee + data transfer
Reliability	Dependent on ISP	99.99% SLA with proper configuration
Encryption	Encrypted tunnel	Optional MACsec at layer 2

For development and disaster recovery: VPN is cost-effective. For production workloads with consistent high throughput: Direct Connect pays for itself in predictable costs and reduced latency.

Implementing VPC Endpoints for Secure Service Access

Instead of routing traffic to AWS services through public internet, deploy VPC Endpoints (Gateway Endpoints for S3/DynamoDB, Interface Endpoints for everything else):

# Create Gateway Endpoint for S3
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-xxxxx \
  --service-name com.amazonaws.us-east-1.s3 \
  --route-table-ids rtb-xxxxx

This keeps traffic within AWS's network, eliminates internet egress costs, and reduces attack surface.

---

Advanced VPC Design Patterns for Modern Workloads

Hub-and-Spoke Architecture

Centralize security inspection (firewalls, IDS/IPS) and shared services in a hub VPC. All spoke VPCs route through the hub for north-south traffic while communicating directly for east-west traffic.

Benefits: Centralized control, reduced shadow IT, simplified compliance auditing.

Trade-offs: Added latency (10-30ms typical), higher data transfer costs, single point of inspection.

Multi-Region Active-Active Architecture

For global applications requiring sub-100ms latency and disaster recovery capabilities:

us-east-1 (Primary)          eu-west-1 (Secondary)
├── VPC: 10.0.0.0/16          ├── VPC: 10.1.0.0/16
├── RDS Multi-AZ              ├── RDS Read Replica (promotable)
└── Route 53 failover          └── S3 Cross-Region Replication

Use AWS Global Accelerator or Azure Traffic Manager for intelligent DNS-based failover across regions.

Security-First Architecture: Zero Trust in the Cloud

Modern VPC design assumes breach. Instead of trusting traffic inside your network:

1. Encrypt Everything: Use mTLS for service-to-service communication. AWS PrivateLink, Azure Private Link, and GCP Private Service Connect provide encrypted paths to managed services.

2. Microsegment with Security Groups: Create granular rules that allow only specific ports between specific IPs. Avoid 0.0.0.0/0 rules.

3. Log Everything: Enable VPC Flow Logs (AWS), NSG Flow Logs (Azure), or GCP Flow Logs. Send to S3/CloudWatch for analysis with tools like Splunk or Datadog.

---

FinOps: Optimizing VPC Costs

Cloud networking costs come from three primary sources: data transfer, NAT gateway usage, and gateway/transit attachments.

Cost Optimization Checklist

• Deploy NAT Gateways in private subnets only—never in public subnets with direct IGW access
• Use VPC Peering instead of Transit Gateway for 2-VPC architectures in the same region
• Enable S3 Transfer Acceleration only if egress costs outweigh the pricing premium
• Schedule NAT Gateway deletion during off-hours if your workloads are batch-oriented
• Use Savings Plans or Reserved Instances for predictable, high-volume data transfer
• Monitor with AWS Cost Explorer, Azure Cost Management, or GCP Billing Budgets with alerts

Hidden Costs to Watch

• Cross-AZ traffic: Every time data moves between Availability Zones, you're charged ($0.01/GB AWS). Design for AZ-affinity where possible.
• Inter-region transfers: $0.02-0.05/GB depending on source and destination. Minimize with caching and regional deployment.
• Elastic IP address idle fees: AWS charges $0.005/hour for unused EIPs. Release them promptly.

---

Conclusion: Building Networks That Scale Without Surprises

Cloud networking architecture determines your application's performance, security posture, and monthly bill. The startup story at the beginning of this guide isn't unusual—it's a pattern we see repeatedly across organizations of all sizes.

The fix for their $180,000 annual overspend wasn't a migration or a re-architecture. It was understanding how route tables, VPC peering, and data transfer pricing interact.

Your cloud network should be:

• Logical: Clean CIDR blocks that accommodate growth
• Secure: Defense in depth with security groups, NACLs, and encryption
• Cost-Efficient: Direct routing where possible, centralized inspection only where necessary
• Observable: Flow logs, metrics, and alerts that catch issues before they become incidents

The fundamentals of VPC design, subnet architecture, and routing logic apply whether you're running on AWS, Azure, or GCP. Master these concepts once, and you'll be able to design cloud networks that scale elegantly—without surprise billing at 3 AM.

---

Next Steps: Start with an audit of your current route tables and data transfer patterns. Tools like AWS Cost and Usage Report, Azure Cost Analysis, and GCP Billing Export can help identify optimization opportunities. For immediate impact, check your largest VPCs for Transit Gateway usage that could be replaced with direct peering.