Cloud networking is where mental models transfer worst after identity, because the three providers made genuinely different structural choices — and where the largest avoidable costs hide, because most of them are internal traffic nobody thinks of as network spend.

Each provider gives you a private network of your own inside its cloud. AWS and Google call it a VPC, a Virtual Private Cloud; Azure calls it a VNet, a Virtual Network.

Two of those rows break people's assumptions on arrival.

A subnet is not always zonal. Engineers from the cloud where a subnet lives in exactly one availability zone plan one subnet per zone per tier, arrive on another cloud, and cannot find the equivalent. There isn't one — zone redundancy there is a property of the resource, not of the subnet. Carrying the old pattern over produces an address plan that is three times more complicated than it needs to be.

And GCP's network is global. A single VPC spans every region, which means the multi-region transit problem that dominates network design on the other two frequently does not exist at all. Architects arriving from elsewhere build a hub-and-spoke topology to solve a problem the platform has already solved.

• Peering is non-transitive on all four. A peered to B and B peered to C does not give A a path to C. Every provider sells a hub product to fix that — AWS Transit Gateway, Azure Virtual WAN, GCP Network Connectivity Center, OCI Dynamic Routing Gateway — and on three of them a hub is a router with a meter on it: an hourly charge per attachment plus a per-gigabyte processing charge. OCI charges neither, and Oracle markets that as a differentiator. GCP also waives the hourly charge on the first three VPN spokes and the first three Interconnect spokes, which is enough to make a small hub free. So check the meter before assuming one; this is the row where the four genuinely diverge.
• Overlapping address ranges block peering outright rather than half-working. This is why a single organisation-wide register of allocated ranges is worth more than any amount of clever routing later.
• Private access to managed services comes in two shapes. The expensive one puts a network interface with a private address in your subnet, and charges per endpoint per hour plus per gigabyte. The cheap one is a route table entry rather than an appliance — and AWS's gateway endpoints, for S3 and DynamoDB, are completely free.
• And on Azure, Private Link endpoints fail on DNS rather than routing almost every time. The endpoint exists, the route works, and the name still resolves to the public address because the private DNS zone was not linked. If you are debugging one, start there.

A private circuit is a dedicated physical connection between your own network and the cloud provider, arranged through a carrier at a colocation facility where the provider has a presence. You use one instead of a VPN across the internet for three reasons: predictable latency and bandwidth rather than best-effort, higher throughput than an IPsec tunnel will sustain, and often lower egress rates than internet transfer.

Three things surprise people. It takes weeks, not minutes, because a carrier has to provision a physical cross-connect — this is the one piece of cloud infrastructure that still moves at telco speed. It is a single point of failure unless you buy two, and two circuits through the same duct is one circuit with two invoices. And — the one that matters most for a compliance answer — it is not encrypted.

So the models are not the same shape. Azure bundles bandwidth into the circuit and sells reach as a tier; AWS sells a port and makes you compose reach from interface types. Neither is better, but a design that assumes one and is built on the other ends up with an unexpected bill or an unreachable region.

All six of AWS's India Direct Connect locations terminate in ap-south-1 (Mumbai) only — Equinix Mumbai (two), and STT facilities in Chennai, Delhi, Hyderabad and Kolkata. Note what that means: there is a physical Direct Connect location in Hyderabad, and it routes to the Mumbai region, not to the Hyderabad region sitting beside it. ap-south-2 has no native Direct Connect termination; you land in ap-south-1 and extend with a Direct Connect Gateway.

GCP is the contrasting case: both asia-south1 (Mumbai) and asia-south2 (Delhi) have local Dedicated Interconnect colocation facilities, so neither region depends on the other for private connectivity. Azure sits in between — six India peering locations across Mumbai, Chennai and Pune, with the peering location decoupled from the VNet region it ultimately reaches, the same pattern as a Direct Connect Gateway.

Two more India-specific gaps worth carrying, because they are the sort of thing a reference architecture will not warn you about: Azure's NAT Gateway does not offer the newer StandardV2 tier in West India; and Private Link support is per-service, not blanket — Microsoft Purview's Private Link lists Central India but not South or West India. “Available in India” is not a single fact, and the region a service is missing from is usually the one you picked for latency.

One category error to avoid: asking whether CloudFront, Route 53, Front Door or Cloud DNS is “available in ap-south-2” does not parse. Those are global and edge services, not region-deployed ones — Route 53's control plane lives in us-east-1 with data-plane points of presence everywhere. Regional availability is a question about regional services.

Every cloud has an L4 balancer, an L7 balancer, and a global edge product, and the selection logic from the networking book applies: L4 for throughput and protocol transparency, L7 for decisions about request content.

One capacity detail is worth knowing specifically because it inverts the usual advice. On AWS's Network Load Balancer, the capacity unit allows 800 new connections per second for plain TCP and only 50 per second when the balancer terminates TLS — a sixteenfold difference. So terminating TLS at the L4 balancer is dramatically more expensive per connection than people assume, and for workloads with many short-lived TLS connections — mobile clients, APIs without keep-alive — the supposedly cheaper L4 option can cost more than the L7 one doing the same job.

The Application Load Balancer charges a reduced byte allowance for Lambda targets, which is another 2.5× penalty that appears nowhere in the headline price. The general point: load balancer pricing is dimensional, and the dimension you are actually consuming is rarely the one you assumed. Read which dimension is binding before optimising the wrong one.

• Is the address plan registered organisation-wide? Overlaps block peering permanently and the fix afterwards is renumbering.
• Is object-storage traffic on a free endpoint or through a metered gateway?
• Is anything chatty spread across zones for no reason? Redundancy needs cross-zone; a cache talking to its own application does not.
• Are private endpoints resolving privately? Check the DNS, not the route.
• And is diversity physical? Two circuits from two providers through the same duct is one circuit with two invoices — which is the same lesson as the networking book and is repeated here because people keep buying it.