Networking parity

1. The names

Google Cloud	AWS	Azure
VPC network (global)	VPC (regional)	Virtual Network (regional)
subnet (regional)	subnet (zonal)	subnet (within the VNet's region)
firewall rules	security groups + network ACLs	network security groups, application security groups, Azure Firewall
Cloud Router	Transit Gateway, Direct Connect (per Google's table)	VPN Gateway, Route Server
Cloud VPN	AWS VPN	VPN Gateway, Virtual WAN
Cloud Interconnect	Direct Connect	ExpressRoute
Cloud Load Balancing	Elastic Load Balancing (ALB/NLB/GWLB)	Load Balancer, Application Gateway, Front Door, Traffic Manager
Cloud CDN	CloudFront	Azure CDN / Front Door
Cloud DNS	Route 53	Azure DNS, Private DNS, Traffic Manager
Cloud NAT	NAT Gateway	NAT Gateway
Private Service Connect	PrivateLink	Private Link
Cloud Armor	AWS WAF + Shield	WAF on Application Gateway / Front Door / CDN
VPC Flow Logs	VPC Flow Logs	virtual network flow logs
Network Intelligence Center	Reachability Analyzer etc.	Network Watcher

Note the Cloud Router row: Google's own table pairs it with Transit Gateway and Direct Connect, and Microsoft's with VPN Gateway. Both are partial — Cloud Router is a BGP control plane that appears in Interconnect, VPN and NAT designs. Do not read it as "the transit object"; Google Cloud mostly does not need one (§2).

2. The row that re-models the whole estimate

	Google Cloud	AWS	Azure
the network object	global	regional	regional
the subnet	regional	zonal	regional
traffic between two regions in one network	internal, by default	needs peering, Transit Gateway or Cloud WAN	needs peering or Virtual WAN
a transit object	usually not needed	Transit Gateway, commonly	Virtual WAN, commonly

So a per-region network inventory does not convert by arithmetic. Three practical rules:

1. Moving to Google Cloud: N regional VPCs/VNets usually become one VPC network with N subnets.

The Transit Gateway or Virtual WAN, its attachments, its route tables and its hourly charges disappear. That is often the largest single structural saving in a cloud-to-cloud move, and it is routinely missed because nobody costs the absence of an object.

1. Moving from Google Cloud: one network becomes N, plus a transit design that did not previously

exist. Budget the transit object, its attachments and its per-GB processing charge as new line items.

1. Peering non-transitivity is shared between Google Cloud and AWS, so a peering-based source design ports

as-is. A Transit-Gateway- or Virtual-WAN-based design does not — there is no equivalent object to port onto, and the answer is either the global VPC itself (§2.1) or Network Connectivity Center.

The second-order effect: IP address planning changes shape. A Google Cloud subnet is regional, so there is no per-zone subnet carve-up. An estate with three subnets per region per AZ collapses to one per region, and the address plan should be redone rather than translated. Avoid auto mode on anything you will connect — its ranges all come from 10.128.0.0/9 and collide with every other auto-mode network.

3. Load balancing does not line up one-to-one

Need	Google Cloud	AWS	Azure
global HTTP(S) front door	global external Application Load Balancer	CloudFront + ALB, or Global Accelerator	Front Door
regional HTTP(S)	regional external Application Load Balancer	ALB	Application Gateway
internal HTTP(S)	regional internal, or cross-region internal ALB	internal ALB	internal Application Gateway
TCP proxy with SSL offload	global/regional external proxy Network Load Balancer	NLB with TLS listener	Load Balancer + Application Gateway
non-TCP protocols, source IP preserved	passthrough Network Load Balancer (TCP, UDP, ESP, AH, GRE, SCTP, ICMP)	NLB (TCP/UDP)	Load Balancer
DNS-based traffic steering	—	Route 53	Traffic Manager

Three estimate-bearing facts:

1. Google Cloud has a single global anycast HTTP(S) balancer, where a global AWS front door is usually

two products (CloudFront plus a regional ALB) and Azure's is Front Door plus a regional gateway. Moving in, that is one fewer component and one fewer certificate story. Moving out, it is one more.

1. cross-region internal has no clean counterpart. An internal service reachable from several regions

behind one address is a Google Cloud primitive; on AWS and Azure it is a design.

1. Only Google Cloud's passthrough family carries SCTP, ESP, AH and GRE. A workload using those has one

family on Google Cloud and may have no managed option on a target cloud — check before promising a like-for-like move. And the classic balancers being global in Premium Tier and regional in Standard Tier is a trap with no analogue elsewhere.

4. Cloud NAT is not an appliance, and that is a line item

	Google Cloud	AWS	Azure
what it is	"a distributed, software-defined managed service" — no VM, no appliance	a NAT Gateway resource, per AZ	a NAT Gateway resource
where configured	on a Cloud Router, per region	per subnet/AZ	per subnet
redundancy	inherent	you deploy one per AZ for zone resilience	per zone
inbound	never: "established inbound response packets only"	never	never
extra	Private NAT for private-to-private translation	—	—

Moving to Google Cloud removes the NAT gateway resources, their per-zone duplication and their per-resource charge, leaving egress data as the dimension. Moving away adds all three back, plus a throughput ceiling. And Private NAT has no counterpart in either table read here — it is the answer to overlapping private ranges, which a merger-driven migration almost always has.

5. WAF rules: names port, rules do not

Cloud Armor pairs with AWS WAF + Shield and with Azure's WAF. The honest split:

• custom rules port with effort — different expression languages, explicit intent;
• preconfigured/managed rule sets do not port. Cloud Armor's are based on **OWASP ModSecurity CRS 4.22,

3.3 and 3.0**. Where the source platform's rules were also CRS-based, the CRS version is the common ground and the port is tractable. Where they were a vendor's proprietary managed rules, there is nothing to convert: budget a tuning cycle against real traffic, with a lead time, in every WAF migration.

• attachment coverage differs. A Cloud Armor policy attaches only to the balancer types in

reference/networking/cloud-armor.md §2. Choosing a balancer and then discovering the policy will not attach is a front-door rework — check it during design.

6. Pricing dimension (never a price)

	Google Cloud	AWS	Azure
egress to internet	per GB, by destination and by network service tier	per GB by Region	per GB by zone
inter-region	per GB	per GB	per GB
load balancing	forwarding rules and data processed	per LCU/hour and per hour	per hour plus capacity units
NAT	no appliance charge; data processed and addresses	per gateway-hour plus data processed	per gateway-hour plus data processed
transit between networks	mostly not applicable	Transit Gateway attachment-hours plus data	Virtual WAN hub plus data
private service access	endpoints, plus data	PrivateLink endpoint-hours plus data	Private Link endpoint-hours plus data

The two rows with no Google Cloud charge — a transit object and a NAT appliance — are the ones that move an estimate most, and they move it by not existing. Make them explicit lines with a zero rather than leaving them out, so the comparison is auditable.

7. What this guide cannot tell you

The egress bill. It is the largest and least predictable line in most cross-cloud migrations, it is charged by the source cloud during the move and by the target forever after, and no mapping table contains it. It is treated as a first-class line in guides/parity-and-migration-method.md.