Cloud Compare / Networking compared
Networking compared
VPC networks, VPCs and VNets side by side: subnets, routing, NAT, peering, hybrid links, load balancers, DNS and private access in Google Cloud, AWS and Azure.
The three clouds build networks from the same ideas (private address space, subnets, routes, gateways, load balancers, DNS), but they draw the boundaries differently. The biggest difference: a Google Cloud VPC network is global, while AWS VPCs and Azure virtual networks are regional. Most other differences follow from that.
The guides behind each column: Google Cloud, AWS and Azure. For protection (firewalls, WAF, DDoS), see Network protection compared.
The private network
| Concept | Google Cloud | AWS | Azure |
|---|
| Private network | VPC network, global: one network spans every region | VPC, one region | Virtual network (VNet), one region |
| Subnet scope | One region, all its zones | One Availability Zone | One region, all its zones |
| Address space | Defined per subnet; add ranges any time | CIDR blocks on the VPC, subnets carved from them | Address spaces on the VNet, subnets carved from them |
| Ready-made network | default auto-mode network in each new project (turn off by org policy) | Default VPC in each region of each account | None |
| Container for the network | Project (or a Shared VPC host project) | Account | Subscription and resource group |
| Share one network with other teams | Shared VPC: service projects use the host project's subnets | VPC sharing through AWS RAM: other accounts use your subnets | Usually not shared: each team gets its own VNet, peered to a hub |
| Reserved addresses per subnet | 4 | 5 | 5 |
What it means in practice. In Google Cloud, a multi-region application can live in one network with one set of firewall rules, and VMs in different regions talk over internal IPs with no peering. In AWS and Azure, the same design needs a network per region, connected by peering or a transit service. In AWS, put a subnet in each Availability Zone you use; in Google Cloud and Azure, one subnet already covers every zone in its region.
Routing and internet access
| Concept | Google Cloud | AWS | Azure |
|---|
| Routes | Network-wide routes (system, custom static, dynamic, policy-based), optionally scoped by network tag | Route table per subnet | System routes plus a route table (UDR) per subnet |
| Dynamic routing (BGP) | Cloud Router | Virtual private gateway or Transit Gateway | VPN / ExpressRoute gateway; Azure Route Server |
| Inbound from the internet | External IP on the VM or load balancer | Internet gateway on the VPC, plus a public or Elastic IP | Public IP on the VM or load balancer |
| Outbound for private VMs | Cloud NAT (regional, software-defined, no appliance) | NAT gateway (per AZ) | NAT Gateway (per subnet); new VNets have no default outbound access |
| Outbound IPv6 only | Firewall rules on IPv6 | Egress-only internet gateway | NSG rules on IPv6 |
| Block all internet exposure centrally | Org policies (no external IPs) and hierarchical firewall policies | VPC Block Public Access; SCPs | Azure Policy (deny public IPs); private subnets |
Connecting networks
| Concept | Google Cloud | AWS | Azure |
|---|
| Peering two networks | VPC Network Peering | VPC peering (same or other region) | VNet peering (regional or global) |
| Transitive? | No | No | No (unless routed through a hub appliance or Virtual WAN) |
| Hub and spoke at scale | Network Connectivity Center | Transit Gateway; AWS Cloud WAN for global | Virtual WAN, or a hub VNet; Azure Virtual Network Manager for topologies |
| Site-to-site VPN | HA VPN (Cloud VPN) | Site-to-Site VPN | VPN Gateway |
| Private dedicated link | Cloud Interconnect (Dedicated or Partner) | Direct Connect | ExpressRoute |
| Cloud-to-cloud link | Cross-Cloud Interconnect (to AWS, Azure, Oracle, Alibaba) | Direct Connect through a partner or colocation provider | Via ExpressRoute partners |
Load balancing and delivery
| Need | Google Cloud | AWS | Azure |
|---|
| Global HTTP(S) entry point with one anycast IP | Global external Application Load Balancer | CloudFront in front of ALBs; Global Accelerator for one static anycast IP | Front Door |
| Regional HTTP(S) load balancer | Regional external / internal Application Load Balancer | Application Load Balancer | Application Gateway |
| Layer 4 (TCP/UDP) | Passthrough or proxy Network Load Balancer | Network Load Balancer | Azure Load Balancer |
| Insert third-party appliances | Internal passthrough NLB as next hop; Packet Mirroring | Gateway Load Balancer | Gateway Load Balancer |
| Global DNS-based balancing | Cloud DNS routing policies | Route 53 routing policies | Traffic Manager |
| CDN | Cloud CDN, Media CDN | CloudFront | Front Door (the classic Azure CDN offerings are being retired) |
| Where the WAF attaches | Cloud Armor on the load balancer's backend service | AWS WAF on CloudFront, ALB, API Gateway and others | Azure WAF on Front Door or Application Gateway |
DNS
| Concept | Google Cloud | AWS | Azure |
|---|
| Public zones | Cloud DNS public zones | Route 53 public hosted zones | Azure DNS zones |
| Private zones | Cloud DNS private zones, visible to chosen VPC networks | Route 53 private hosted zones, associated with VPCs | Private DNS zones, linked to VNets |
| Hybrid DNS with on-premises | Forwarding zones, DNS server policies (inbound forwarding) | Route 53 Resolver inbound and outbound endpoints | Azure DNS Private Resolver |
| Example zone used in these notes | gcp.ravindran.in | aws.ravindran.in | – |
Private access to cloud services
| Need | Google Cloud | AWS | Azure |
|---|
| Reach the provider's APIs without public IPs | Private Google Access (subnet setting, free) | Gateway endpoints (S3, DynamoDB, free) or interface endpoints | Service endpoints (free) or private endpoints |
| Give a service a private IP in your network | Private Service Connect endpoints; private services access for Cloud SQL and similar | Interface endpoints (PrivateLink) | Private endpoints (Private Link) |
| Publish your own service privately to other networks | Private Service Connect service attachment | PrivateLink endpoint service | Private Link service |
| DNS for private access | Automatic for PSC; private zones for Google APIs | Private DNS on the interface endpoint | Private DNS zones such as privatelink.blob.core.windows.net (the usual source of problems) |
Visibility and troubleshooting
| Need | Google Cloud | AWS | Azure |
|---|
| Flow records | VPC Flow Logs (per subnet or network) | VPC Flow Logs (VPC, subnet or interface) | Virtual network flow logs (NSG flow logs retire 30 Sep 2027) |
| "Why can't A reach B?" | Connectivity Tests | Reachability Analyzer | Network Watcher: IP flow verify, connection troubleshoot |
| Find unintended exposure | Firewall Insights; Security Command Center | Network Access Analyzer | Defender for Cloud network recommendations |
| Copy packets to a tool | Packet Mirroring | Traffic Mirroring | Network Watcher packet capture; virtual network TAP |
| Effective rules on one VM | gcloud compute instances network-interfaces get-effective-firewalls | Security groups on the interface (no single effective view with NACLs) | Get-AzEffectiveNetworkSecurityGroup |
Design tips that carry across
- Plan address space once, for every cloud and on-premises. Overlapping ranges are the one networking mistake that's really expensive to fix later. These notes use
10.10.0.0/16 (Azure), 10.20.0.0/16 (AWS) and 10.30.0.0/16 (Google Cloud) for that reason.
- Hub and spoke everywhere. Shared services (DNS, egress, inspection, hybrid links) in a hub; workloads in spokes. Shared VPC, Transit Gateway and Virtual WAN are each cloud's way of doing it.
- Private by default. No public IPs on servers, outbound through managed NAT, platform services through private endpoints. Each cloud has a policy to enforce it.
- Turn on flow logs and keep a connectivity-test habit. All three have a tool that answers "is it the firewall?" in a minute.
Compared as of October 2026. Service names, tiers and prices change; check the provider's documentation before deciding.