Cloud Networking Services: AWS vs Azure vs Google Cloud
VPCs, DNS, load balancers, CDN, hybrid links and private endpoints: what each networking service does and how AWS, Azure and Google Cloud compare.
“It works from my machine but not from the VM” is almost always a networking problem: a route table, a security group, a DNS zone nobody linked, a private endpoint resolving to a public IP. Cloud networking feels familiar because it borrows the vocabulary of physical networks, but it behaves differently, and the three big providers differ from each other in a few important ways. This post walks through the building blocks, what each is for, and how AWS, Azure and Google Cloud implement them.
What cloud networking covers
Networking connects everything else. The category breaks down into a handful of jobs:
- Isolation. A private address space for your resources (VPC or VNet), split into subnets.
- Name resolution. Public and private DNS.
- Traffic distribution. Load balancers at layer 4 and layer 7, regional and global.
- Edge delivery. CDNs and global entry points close to users.
- Hybrid connectivity. VPNs and private circuits back to your data centre.
- Private access. Reaching managed services without crossing the internet.
Security controls (firewalls, WAF, DDoS protection) are covered in the security services post.
A typical production layout ties these together like this:
%%{init: {"themeVariables": {"fontSize": "14px"}, "flowchart": {"useMaxWidth": false, "nodeSpacing": 30, "rankSpacing": 40, "padding": 8, "wrappingWidth": 150}}}%%
flowchart TB
subgraph EDGE["Global edge"]
direction LR
U[Users] --> D[DNS] --> E[CDN / global<br/>edge + WAF]
end
subgraph REG["Region"]
direction LR
L[Regional load<br/>balancer] --> A[App subnet] --> P[Private endpoint<br/>to database]
O[On-premises] -.->|VPN or<br/>private circuit| A
end
EDGE --> REG
Virtual networks
A VPC (AWS, Google) or VNet (Azure) is your private network in the cloud. You choose an IP range, carve it into subnets, control routing, and decide what can reach the internet. Everything that needs a private IP (VMs, Kubernetes nodes, private endpoints, managed databases with VNet integration) lives in one.
The biggest conceptual difference is scope. AWS and Azure networks are regional, so multi-region designs need peering or a transit hub. Google’s VPC is global: one network spans every region, and only subnets are regional. That makes some multi-region architectures much simpler on Google Cloud. In exchange, you need to think carefully about firewall rules and routes that now apply everywhere.
Plan your IP ranges as if you’ll connect everything to everything eventually, because you will. Overlapping 10.0.0.0/16 networks in every account and subscription are the single most painful thing to fix later.
Amazon VPC Soon
A regional private network with subnets pinned to Availability Zones, route tables, internet and NAT gateways, security groups (stateful, per instance) and network ACLs (stateless, per subnet). Connect VPCs with peering or AWS Transit Gateway.
A regional private network whose subnets span all zones in the region. Network security groups filter traffic; user-defined routes steer it through firewalls. VNet peering and Azure Virtual WAN connect many VNets, typically in a hub-and-spoke layout.
Virtual Private Cloud (VPC) Soon
VPCs are global, and subnets are regional. One network can span every region with no peering, which simplifies multi-region designs. Firewall rules and policies apply by tag or service account; Shared VPC lets a host project serve many projects.
For larger estates, the hub-and-spoke architecture post walks through the common enterprise layout on Azure. The same ideas apply with Transit Gateway on AWS and Shared VPC or Network Connectivity Center on Google Cloud.
DNS
Every cloud offers managed authoritative DNS for public domains and private zones that resolve only inside your networks. Private DNS matters more than people expect: private endpoints, internal load balancers and hybrid name resolution all depend on it, and a missing zone link is behind a large share of “can’t connect” tickets.
For hybrid setups you also need conditional forwarding both ways, so on-premises servers can resolve cloud private zones and cloud workloads can resolve on-premises names. Each provider has a managed resolver for exactly this.
Amazon Route 53 Soon
Authoritative DNS with a 100% availability SLA, private hosted zones for VPCs, domain registration, health checks and routing policies (weighted, latency, geolocation, failover). Route 53 Resolver handles hybrid DNS forwarding.
Public and private DNS zones hosted on Azure’s anycast network, managed with ARM and RBAC. Azure DNS Private Resolver forwards between on-premises and Azure. Traffic Manager adds DNS-based global routing and failover.
Cloud DNS Soon
Managed authoritative DNS with a 100% SLA, public and private zones, DNSSEC, forwarding and peering zones for hybrid setups, and routing policies (geolocation, weighted round robin, failover).
Load balancing
Load balancers spread traffic across healthy backends and are the front door of most applications. Two axes matter: layer (L4 forwards TCP/UDP connections; L7 understands HTTP and can route by path, host or header, terminate TLS and rewrite requests) and scope (regional versus global anycast).
AWS splits this by product: ALB for HTTP, NLB for raw TCP and UDP. Azure has separate L4 and L7 products plus Front Door for global. Google’s Cloud Load Balancing is one family with many modes, and its global external Application Load Balancer, a single anycast IP fronting backends in many regions, is still something the others need two products to replicate.
Application Load Balancer (HTTP/HTTPS with path and host routing), Network Load Balancer (TCP/UDP, millions of requests per second, static IPs) and Gateway Load Balancer (for inline security appliances). All regional; combine with Global Accelerator or CloudFront for global entry.
Layer 4 load balancing for TCP and UDP, internal or public, zone-redundant on the Standard SKU. A cross-region tier adds a global anycast front end.
Regional layer 7 load balancer with TLS termination, URL-based routing, autoscaling and an optional Web Application Firewall. Application Gateway for Containers is the newer Kubernetes-native option for AKS.
Cloud Load Balancing Soon
A software-defined family on Google’s front end. The global external Application Load Balancer gives one anycast IP for backends in many regions. Regional, internal, proxy and passthrough Network Load Balancers cover everything else.
Health checks decide everything. A load balancer that checks
/on a page that renders fine while the database is down will keep sending traffic to broken instances. Point health checks at an endpoint that checks real dependencies, but keep it cheap.
CDN and global edge
A CDN caches content at edge locations close to users. That cuts latency, offloads your origin, and absorbs traffic spikes and some attacks. Modern “edge” products go further: TLS termination, WAF, bot protection and small compute functions running at the edge.
Amazon CloudFront Soon
CDN with hundreds of edge locations, origin shield, signed URLs and cookies, and edge compute through CloudFront Functions and Lambda@Edge. Integrates with AWS WAF and Shield, and data transfer from AWS origins to CloudFront is free.
Azure’s global layer 7 entry point combining CDN, global load balancing, TLS and WAF (Premium adds Private Link origins and bot protection). It replaces Azure CDN from Microsoft (classic), which retires in September 2027.
Cloud CDN Soon
Caching on Google’s edge, enabled as a feature of the global external Application Load Balancer. Supports signed URLs, cache modes, and Cloud Storage or any HTTP backend as an origin. Media CDN covers large-scale video streaming.
On Azure, Azure CDN from Microsoft (classic) retires on 30 September 2027 and Front Door (classic) on 31 March 2027. New work should go straight to Front Door Standard or Premium.
Hybrid connectivity
Most organisations don’t move everything to the cloud at once, so they need reliable connectivity back to on-premises. There are two options, and most production setups use both:
- Site-to-site VPN. IPsec over the internet. Quick to set up and cheap, but throughput and latency depend on the internet path.
- Private circuits. Direct Connect, ExpressRoute, Cloud Interconnect. Dedicated bandwidth with predictable latency, provisioned through a colocation facility or carrier. It takes weeks to order, not minutes.
The common pattern is a private circuit for primary traffic with a VPN as failover, and BGP handling the switch. Be aware that private circuits aren’t encrypted by default. If you need encryption in transit, run IPsec or MACsec over them.
AWS Direct Connect Soon
Dedicated private links (1 to 400 Gbps) from your data centre or colocation facility to AWS, or hosted connections through partners. Pair with Transit Gateway to reach many VPCs, and with a VPN for encryption or backup.
AWS Site-to-Site VPN Soon
Managed IPsec tunnels (two per connection for redundancy) over the internet to a virtual private gateway or Transit Gateway. Quick to set up, and the usual backup for Direct Connect.
Private connections to Microsoft’s network through a connectivity provider or ExpressRoute Direct (10/100 Gbps ports). Reaches Azure VNets and, with Microsoft peering, Microsoft 365. Global Reach links your on-premises sites through Microsoft’s backbone.
Site-to-site IPsec, point-to-site for remote users and VNet-to-VNet tunnels. Zone-redundant SKUs and active-active mode for resilience; commonly used as ExpressRoute failover.
Cloud Interconnect Soon
Dedicated Interconnect (10 or 100 Gbps circuits in colocation facilities) or Partner Interconnect through a service provider. Cross-Cloud Interconnect links directly to AWS, Azure or Oracle.
Cloud VPN Soon
HA VPN provides two IPsec interfaces with a 99.99% SLA and dynamic BGP routing through Cloud Router. A common first step before Interconnect.
Private access to managed services
By default, many managed services (storage, databases, key vaults) have public endpoints. Locking them down means giving them a private IP inside your network and turning off public access. All three providers support this, with slightly different models.
AWS PrivateLink
Interface VPC endpoints give AWS services and third-party SaaS a private IP inside your VPC, so traffic never crosses the internet. Gateway endpoints for S3 and DynamoDB are free.
Private endpoints map a specific PaaS resource (a storage account, SQL database, Key Vault) to a private IP in your VNet, with private DNS zones to resolve it. Service endpoints are the lighter, older alternative.
Private Service Connect
Private endpoints in your VPC for Google APIs, managed services and producer services published by other organisations. Private Google Access is the simpler option for VMs without external IPs.
On Azure, the difference between private endpoints and service endpoints trips a lot of people up. Both posts are worth a read.
Common pitfalls
- Overlapping CIDRs. Fixing them later means re-IPing workloads. Keep a central IP plan from day one.
- NAT gateway surprises. Private subnets reach the internet through NAT, which charges per GB. A chatty workload pulling container images or calling external APIs can quietly run up a big bill. Use VPC endpoints and private registries where you can.
- Private endpoint DNS. A private endpoint without the right private DNS zone linked resolves to the public IP, so traffic either fails or leaves your network.
- Cross-zone and cross-region transfer. Traffic between zones and regions isn’t free. Chatty microservices spread across zones can generate surprisingly large transfer charges.
- Asymmetric routing through firewalls. Forcing traffic through a hub firewall in one direction but not the other breaks stateful inspection. Model both directions when you add routes.
Conclusion
The building blocks are the same on every cloud: a private network, DNS, load balancers, an edge layer, hybrid links and private endpoints. The differences that matter are Google’s global VPC and global load balancer, and the product boundaries on AWS and Azure. Get the IP plan and DNS design right early and most networking problems never happen. Next step: draw your current network on one page (ranges, peerings, DNS zones, egress paths). If you can’t, that’s the first thing to fix. Every service side by side is in the Networking comparison.