Cloud VPC Design: Public vs Private Subnets, NAT Gateways, and the Three-Tier Architecture

AWS, GCP, and Azure VPCs look different on the surface but follow the same network design principles

Every cloud application deployed to production runs inside a virtual network. The design of that network — which resources are in public subnets vs. private subnets, how traffic flows between tiers, whether there's a NAT gateway or VPN — determines both the security posture and the operational characteristics of the application.

The same patterns appear across AWS, GCP, and Azure, with different terminology. Understanding the patterns independently of the cloud provider makes the specific implementations much easier to learn.

The three-tier VPC pattern

The most common production VPC pattern separates resources into three tiers:

Public tier: resources that must be directly accessible from the internet — load balancers, bastion hosts, NAT gateways. Public subnets have a route to the internet via an Internet Gateway (AWS) or equivalent.

Application tier (private): web servers, API servers, application logic. No direct internet access — they receive traffic only from the load balancer in the public tier. Can initiate outbound connections via NAT gateway (AWS) or Cloud NAT (GCP).

Data tier (private): databases, caches, storage services. No inbound traffic except from the application tier. Outbound internet access often restricted or absent entirely.

Internet
    │
    ▼
[Internet Gateway]
    │
    ▼
[Public Subnet] → Load Balancer, Bastion Host, NAT Gateway
    │
    ▼
[Private Subnet - App Tier] → EC2, ECS, Lambda
    │
    ▼
[Private Subnet - Data Tier] → RDS, ElastiCache, Elasticsearch

Key VPC components by provider

AWS VPC

GCP VPC

GCP VPCs are global (span all regions) rather than regional, which changes some design decisions:

Azure Virtual Network

NAT Gateway: private outbound without public exposure

A common misconception: private subnet instances can't access the internet. They can — through a NAT Gateway.

The NAT Gateway sits in a public subnet. Private instances route their outbound internet traffic through it. The NAT Gateway translates the private IP to its own public Elastic IP (AWS) for the outbound connection.

What this achieves: private instances can pull software updates, call external APIs, download from S3/GCS (for on-premises scenarios), and send logs to external services — without exposing themselves to inbound internet connections.

Cost consideration: NAT Gateway isn't free. AWS charges ~$0.045/hour + data processing fees. For high-egress workloads, NAT Gateway costs can exceed compute costs. GCP Cloud NAT has similar pricing. Optimisations: use VPC endpoints/Private Google Access for cloud service traffic (bypasses NAT), batch external API calls.

VPC peering: connecting VPCs without internet

Two separate VPCs can communicate privately via VPC peering. Traffic doesn't traverse the internet — it stays within the cloud provider's network.

Use cases:

• Shared services: a logging or monitoring VPC peered to all application VPCs
• Microservices across accounts: each service in its own AWS account, peered for communication
• Development/production isolation with selective connectivity

Limitations:

• Non-transitive: if VPC A peers with VPC B, and VPC B peers with VPC C, A cannot reach C through B
• CIDR ranges must not overlap — plan address space to avoid conflicts

Common cloud network design mistakes

1. Flat network (everything in public subnets)

Placing all resources — web servers, databases, caches — in public subnets for simplicity. Convenience at the cost of all instances being directly internet-accessible. Mitigated by security groups but violates defence in depth.

2. Overlapping CIDR blocks

Using 10.0.0.0/8 for all VPCs. When peering becomes necessary, overlapping address spaces make peering impossible. Reserve non-overlapping CIDR blocks for each environment from the start.

3. Single availability zone deployment

Deploying everything in one AZ for simplicity. A single AZ failure takes down the entire application. Production workloads should span at least 2 AZs; 3 AZs provides better fault tolerance with only modest additional cost.

4. Security group sprawl

Creating a new security group for every resource rather than designing a layered model. Over time, security group rules become impossible to reason about. Define a model: web-tier-sg, app-tier-sg, data-tier-sg, management-sg — with explicit rules about which tier communicates with which.

How to use the Subnet Calculator on sadiqbd.com

For cloud VPC design:

1. Start with your total VPC CIDR — e.g., 10.0.0.0/16 (65,536 addresses)
2. Plan subnets per tier and AZ — if deploying across 3 AZs with 3 tiers: 9 subnets
3. Use the calculator to size each subnet — /24 per subnet (254 usable) for most tiers; /28 for NAT Gateways
4. Leave room for growth — don't use all available CIDR space; reserve ranges for future expansion

Frequently Asked Questions

Should every service have its own VPC? In AWS, a common pattern is one VPC per environment (dev, staging, production) and possibly per major application. One VPC per microservice is usually overkill unless strict blast radius containment is required. Start simpler and split when the need arises.

What's the difference between security groups and NACLs (AWS)? Security groups are stateful (return traffic is automatically allowed), applied at the instance level, and use allow-only rules. NACLs are stateless (return traffic needs an explicit allow rule), applied at the subnet level, and support both allow and deny rules. Most teams rely primarily on security groups; NACLs add an extra layer for specific subnet-level restrictions.

Is the Subnet Calculator free? Yes — completely free, no sign-up required.

Cloud VPC design is infrastructure-as-code — get the patterns right at the start, because refactoring network architecture in production is significantly more disruptive than getting it right initially.

Try the Subnet Calculator free at sadiqbd.com — calculate subnet sizes, host ranges, and address allocations for any CIDR block.