Cloud Networking — VPCs across AWS, GCP and Azure

A Virtual Private Cloud is your own isolated network inside a cloud provider. You define the IP address space, carve it into subnets, attach gateways, and control which traffic flows where. Everything you deploy — VMs, containers, databases, load balancers — lands in a VPC. Get your networking wrong and nothing else matters: your app either can't talk to what it needs, or it can talk to things it shouldn't.

The Core Concepts

A VPC (or VNet in Azure) is a logically isolated network you define with a CIDR block — say 10.0.0.0/16, giving you 65,536 IP addresses. You then divide that into subnets, each with a smaller CIDR range (10.0.1.0/24 = 256 addresses). Plan your CIDR ranges carefully upfront. Overlapping CIDRs between VPCs make peering impossible later, and re-IPing a production network is the kind of project nobody wants.

Subnets come in three flavors based on routing, not some magic property:

• Public subnets have a route to an Internet Gateway — instances here can get public IPs and accept inbound traffic. Your load balancers live here.
• Private subnets route outbound internet traffic through a NAT Gateway. Application servers, worker nodes, and internal services live here.
• Isolated subnets have no internet route at all. Databases, caches, and anything that has zero business talking to the internet go here.

Route tables control where traffic goes. Every VPC starts with a "local" route that allows all subnets within the VPC to talk to each other. You add routes for internet-bound traffic (via an Internet Gateway or NAT Gateway), peered VPCs, VPN connections, and so on.

Internet Gateway is free and gives public subnets bidirectional internet access. NAT Gateway lets private subnets make outbound connections without being reachable from the internet — and it's genuinely expensive. AWS charges per hour plus per GB processed. A busy NAT Gateway can easily cost more than the compute behind it. Always check this line item.

The Three-Tier Layout

The canonical architecture every cloud environment should start from:

• Public tier: Application Load Balancer, bastion hosts (if you still use them), NAT Gateways
• Private tier: Application servers, containers, worker nodes
• Isolated tier: RDS instances, ElastiCache, anything storing data

This layout means a compromised web server can't directly reach your database from the internet. Traffic must flow through the load balancer, to the app tier, and only then to the data tier via security group rules.

Security Groups vs NACLs

Security Groups are stateful firewalls attached to individual resources (EC2 instances, RDS instances, ENIs). If you allow inbound traffic on port 443, the return traffic is automatically allowed. They only support allow rules — there's no "deny" rule. To block something, you simply don't allow it.

Network ACLs (NACLs) are stateless firewalls attached to subnets. You must explicitly allow both inbound and outbound traffic. They support both allow and deny rules, and they're evaluated in order by rule number. NACLs are your coarse-grained guardrails; security groups are your fine-grained controls.

In practice, most teams rely heavily on security groups and barely touch NACLs beyond the defaults. But NACLs are useful when you need to explicitly block a known bad IP range at the subnet level.

AWS Implementation

AWS VPCs are regional — a VPC in us-east-1 is separate from one in eu-west-1. Subnets are scoped to a single Availability Zone. A typical production setup creates at least one subnet per tier per AZ (3 tiers x 3 AZs = 9 subnets minimum).

VPC: 10.0.0.0/16

Public:   10.0.1.0/24 (AZ-a), 10.0.2.0/24 (AZ-b), 10.0.3.0/24 (AZ-c)
Private:  10.0.11.0/24 (AZ-a), 10.0.12.0/24 (AZ-b), 10.0.13.0/24 (AZ-c)
Isolated: 10.0.21.0/24 (AZ-a), 10.0.22.0/24 (AZ-b), 10.0.23.0/24 (AZ-c)

VPC Endpoints (Gateway Endpoints for S3/DynamoDB, Interface Endpoints for everything else) let you reach AWS services without traversing the internet — saving NAT Gateway costs and improving security. Transit Gateway connects multiple VPCs and on-premises networks through a central hub rather than a mesh of peering connections.

GCP Implementation

GCP VPCs are global — a single VPC spans all regions, with subnets scoped to individual regions. This is architecturally simpler: you don't need peering to connect resources across regions within the same VPC. GCP also supports auto mode VPCs that create a subnet in every region automatically (convenient for dev, avoid it in production — you want control over your CIDR planning).

GCP's firewall rules are VPC-level and support both allow and deny — there's no separate NACL concept. Rules can target instances by network tag or service account, which is more flexible than AWS's security group model.

Private Service Connect is GCP's equivalent of VPC Endpoints — private access to Google APIs and services. Cloud Router handles dynamic routing for VPN and Interconnect connections using BGP.

Azure Implementation

Azure Virtual Networks (VNets) are regional, like AWS VPCs. Subnets are not tied to a specific availability zone — they span all AZs within the region. Security is handled by Network Security Groups (NSGs), which can be attached to either subnets or individual NICs and support both allow and deny rules.

Azure adds Application Security Groups (ASGs) that let you group VMs logically and write NSG rules referencing those groups instead of IP addresses — useful when IP addresses are dynamic.

Private Link provides private connectivity to Azure services and your own services hosted behind a Standard Load Balancer. Virtual WAN is Azure's hub-and-spoke networking service for connecting VNets, branches, and remote users.

Side-by-Side Comparison

Aspect	AWS	GCP	Azure
Network scope	VPC — regional	VPC — global	VNet — regional
Subnet scope	AZ-scoped	Regional	Span all AZs
Stateful firewall	Security Groups (allow only)	Firewall rules (allow + deny)	NSGs (allow + deny)
Stateless firewall	NACLs (allow + deny)	N/A — firewall rules are unified	N/A — NSGs handle both
Multi-VPC connectivity	Transit Gateway	Shared VPC / VPC Peering	Virtual WAN / VNet Peering
Private service access	VPC Endpoints	Private Service Connect	Private Link
Hybrid VPN	Site-to-Site VPN	Cloud VPN	VPN Gateway
Dedicated connection	Direct Connect	Cloud Interconnect	ExpressRoute

Connectivity and Hybrid Networking

VPC Peering connects two VPCs privately. It's simple but doesn't scale — it's not transitive (A peers with B, B peers with C, but A can't reach C through B). When you have more than a handful of VPCs, switch to Transit Gateway (AWS), Cloud Router (GCP), or Virtual WAN (Azure).

For hybrid connectivity to on-premises networks, you have two options: VPN (encrypted tunnel over the public internet, set up in minutes, variable latency) or dedicated connections (Direct Connect / Cloud Interconnect / ExpressRoute — private fiber from your datacenter to the provider, consistent latency, 1-3 month provisioning lead time, and a significant monthly cost).

Flow Logs capture metadata about network traffic (source, destination, port, action, bytes). Enable them. When something can't connect and you're staring at security group rules that look correct, flow logs tell you what's actually happening on the wire.

Common Failures

Overlapping CIDRs: you used 10.0.0.0/16 in three VPCs and now you can't peer any of them. Plan CIDR ranges across all VPCs upfront, even if you think you'll never connect them.

Database in a public subnet: an RDS instance with a public IP is one misconfigured security group away from being internet-accessible. Always use isolated subnets for data stores.

NAT Gateway cost surprise: a workload pulling container images, fetching secrets, and calling AWS APIs through a NAT Gateway can rack up hundreds per month in data processing charges. Use VPC Endpoints for high-volume AWS service calls.

Key Takeaways

• A VPC is your isolated network — plan CIDR blocks carefully upfront because overlapping ranges block future peering
• Use three subnet tiers (public, private, isolated) as your default architecture, with the tier defined by routing, not by a label
• Security Groups (stateful, per-resource, allow-only) do most of the work; NACLs are the coarse-grained backstop
• GCP's global VPC is fundamentally different from AWS/Azure's regional model — simpler connectivity, wider blast radius
• NAT Gateways are expensive — use VPC Endpoints for high-volume traffic to cloud services
• Enable flow logs from day one; they're the only way to debug "it should be able to connect but can't" problems

Next, we'll look at how load balancers distribute traffic across the resources sitting inside these networks.