--- cuppy_hub: gcp cuppy_path: guides/parity/networking.md cuppy_section: docs cuppy_doc: CV2S-XTQW cuppy_doc_uuid: 4ab51ce0-6e2d-41ff-ba7a-54a7fb114203 cuppy_permalink: https://cuppy.io/gcp/d/CV2S-XTQW cuppy_version: 1 cuppy_updated: 2026-10-23T16:16:52.575Z cuppy_canonical: https://cuppy.io/gcp/docs/guides/parity/networking cuppy_mcp: https://cuppy.io/mcp cuppy_body_sha256: 3d0a81ee9bd85897c7e2685ab9d0e2ff986b167f22be4cdb630602efa86be28f # cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks. --- # 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. 2. **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. 3. **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. 2. **`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. 3. **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`. --- You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 91 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/gcp/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.