Introduction to Cloud Interconnect
Cloud Interconnect is the family of physical-layer products that extend your on-premises or other-cloud network into Google Cloud VPCs with low latency, deterministic throughput, and private IP reachability — no traversal of the public internet. The PCNE exam treats Cloud Interconnect as the backbone of every serious hybrid design: when traffic volumes pass a few hundred Mbps, when latency must stay below 10 ms, when regulation forbids public transit, or when you need a stable BGP peering surface for thousands of on-prem subnets, Cloud Interconnect is the answer.
This note walks the full surface area: Dedicated Interconnect, Partner Interconnect (Layer 2 and Layer 3), Cross-Cloud Interconnect, VLAN attachments, Edge Availability Domains, the dual-EAD four-9s SLA topology, MACsec encryption, MTU tuning, the special BGP ASN 16550, and how Cloud Router stitches it all into a VPC. Read it once end to end, then use the FAQ as your last-mile drill before exam day.
白話文解釋（Plain English Explanation）
Before diving into colocation facilities and BGP fields, three analogies make the moving parts memorable. Cloud Interconnect touches three different worlds — the physical port you rent, the logical lane you carve out, and the redundancy pattern that earns the SLA — so three different metaphors work.
Think of Dedicated Interconnect as Leasing a Private Fibre to a Telco Exchange
Imagine your company has its own warehouse on the edge of town and Google has a freight depot inside a shared logistics park called a colocation facility. Dedicated Interconnect is the moment you sign a contract to physically pull a fibre between your cage and Google's cage inside that same building. The fibre is yours; nobody else's traffic touches it. You pay Google for the port (10 Gbps or 100 Gbps), you pay the colocation operator for cross-connect fees, and you pay your local circuit provider to extend that fibre back to your data centre. The reward is a private, deterministic pipe with no oversubscription. The cost is that you must already have, or be willing to lease, presence inside one of Google's ~140 supported colocation facilities worldwide.
Think of Partner Interconnect as Renting a Private Lane on a Highway Someone Else Built
Most enterprises do not have a rack in Equinix Frankfurt or KIX Tokyo. Partner Interconnect lets a service provider that already does — Equinix, Megaport, Console Connect, Chunghwa Telecom, NTT — sell you a slice of their connection to Google. The provider runs the heavy steel (Layer 1/2), and you order a VLAN attachment of any size from 50 Mbps up to 50 Gbps. The provider can deliver this in two flavours: Layer 2 (you still run BGP directly with Google's Cloud Router, the partner is just a wire) or Layer 3 (the partner terminates BGP themselves and you peer with the partner). Partner Interconnect is the right answer whenever you need less than 10 Gbps or when you cannot reach a Google colocation building yourself.
Think of Cross-Cloud Interconnect as a Permanent Bridge Between Two Cloud Cities
Cross-Cloud Interconnect (CCI) is a Dedicated Interconnect variant where Google does the colocation work for you against another hyperscaler — AWS Direct Connect, Azure ExpressRoute, OCI FastConnect, Alibaba Express Connect. Instead of you building two separate interconnects and stitching them together in your own DC, Google delivers a single 10 Gbps or 100 Gbps port that lands inside the target cloud's edge. You still get VLAN attachments and BGP just like a normal Dedicated Interconnect, but the "on-premises" side is in fact another public cloud. This collapses multi-cloud egress costs and removes the on-prem hop from your latency budget.
Core Concepts of Cloud Interconnect
The PCNE exam tests whether you can match a scenario to the right product variant and topology. The toolbox below covers about 90% of what shows up on the test.
A family of Google Cloud network products that connect an external network (on-premises, colocation, or another cloud) to a Google Cloud VPC over a private physical or partner-delivered circuit. Traffic uses RFC 1918 (or customer-owned public) addresses, never the public internet. The umbrella covers Dedicated Interconnect, Partner Interconnect, and Cross-Cloud Interconnect. https://cloud.google.com/network-connectivity/docs/interconnect/concepts/overview
Interconnect connection is the physical or partner-delivered circuit object. For Dedicated Interconnect it represents one or more 10/100 Gbps ports at a Google colocation facility. For Partner Interconnect it represents the partner's side of the link, identified by a pairing key your provider consumes.
VLAN attachment (interconnectAttachment) is the logical lane carved out of an interconnect. Each attachment binds to exactly one Cloud Router in exactly one VPC region and carries one BGP session. You buy capacity per attachment, not per port: a single 10 Gbps Dedicated Interconnect can carry many small VLAN attachments routed to different projects or different VPCs.
Cloud Router is the BGP speaker on the Google side. It learns routes from your on-prem device over the VLAN attachment, programs them into the VPC route table, and advertises subnets (or a custom set) back to your router. Without Cloud Router, an Interconnect is dark.
Edge Availability Domain (EAD) is the failure boundary inside a Google metro. Each metro has two EADs (often called availability-domain-1 and availability-domain-2), physically isolated power, optical gear, and Google Edge routers. Placing attachments in both EADs is what unlocks the 99.9% SLA; replicating that pair across two metros unlocks 99.99%.
BGP ASN 16550 is the public ASN Google reserves specifically for Partner Interconnect on the Google side of the BGP session. Dedicated Interconnect uses a regular private ASN you assign on Cloud Router; only Partner Interconnect forces 16550.
Dedicated Interconnect Architecture
Dedicated Interconnect is the right answer when sustained throughput exceeds 10 Gbps, when you require a fixed monthly cost without per-GB egress markups, or when compliance demands a circuit that no third party touches.
Ports and Capacity
Dedicated Interconnect ports come in two SKUs: 10 Gbps (single-mode fibre, 10GBASE-LR, 1310 nm) and 100 Gbps (100GBASE-LR4, also 1310 nm). You can bundle up to eight 10 Gbps ports under one Link Aggregation Group (LAG) using LACP, giving you 80 Gbps of usable bandwidth from a single logical interconnect, or two 100 Gbps ports for a 200 Gbps LAG. Google does not oversubscribe ports — every 10 Gbps is reserved capacity.
Colocation and Cross-Connect
You meet Google inside one of the supported colocation facilities listed at cloud.google.com/network-connectivity/docs/interconnect/concepts/choosing-colocation-facilities. You order the port via Cloud Console or gcloud compute interconnects create, Google returns a Letter of Authorisation (LOA-CFA), and you submit that to the colocation operator to provision the cross-connect between your cage and Google's cage. Lead time is typically 1–3 weeks.
Per-Attachment Capacity Tiers
Once the port is up, you carve out VLAN attachments. Dedicated Interconnect attachments come in tiers from 50 Mbps to 50 Gbps in fixed steps (50 Mbps, 100, 200, 300, 400, 500, 1G, 2G, 5G, 10G, 20G, 50G). A single 100 Gbps port can host up to ~16 50 Gbps attachments, but capacity is shared, so plan oversubscription with care.
Dedicated Interconnect bills two layers separately: a fixed port fee per 10G/100G interconnect (charged by Google) plus a per-VLAN-attachment fee that scales with attachment capacity. The colocation cross-connect and any local-loop circuit back to your data centre are billed by third parties and are not part of the Google invoice — surprise costs here trip up many TCO comparisons. https://cloud.google.com/network-connectivity/docs/interconnect/pricing
Partner Interconnect: Layer 2 vs Layer 3
Partner Interconnect is delivered by one of the supported service providers and comes in two encapsulation modes that have very different operational consequences.
Layer 2 Partner Interconnect
In Layer 2 mode the partner provides a transparent Ethernet circuit. Your on-premises router still runs BGP directly with Google's Cloud Router; the partner is just glass. You configure the VLAN ID, the BGP peering IP, and the MD5 auth key on your own gear. This mode preserves end-to-end BGP visibility, which is what most enterprises with mature network teams prefer.
Layer 3 Partner Interconnect
In Layer 3 mode the partner terminates BGP themselves. You hand the partner your routes; they handle BGP with Google internally. From your side it looks like a normal IP handoff to the partner. This is convenient for organisations without BGP expertise but you lose the ability to see Google's route advertisements directly — you trust the partner to translate.
Pairing Key Workflow
Either mode starts the same way: in Cloud Console you create the Partner VLAN attachment and Google returns a pairing key (a string like 7e51371e-72a3-40b5-bdb2-8b6c48c7e8e0/us-east1/zone1). You give this to your provider's portal; they bind their side of the circuit to your attachment. Once you activate the attachment back in Google, BGP comes up.
Capacity Tiers
Partner Interconnect attachments come in: 50, 100, 200, 300, 400, 500 Mbps, then 1, 2, 5, 10, 20, 50 Gbps. Unlike Dedicated, partners can deliver 50 Gbps attachments without you owning a 100 Gbps port — they aggregate across many customers.
If your throughput need is between 1 Gbps and 10 Gbps and you do not have rack presence in a Google colocation facility, Partner Interconnect Layer 2 is almost always the right answer: you keep direct BGP visibility while letting the partner solve the physical-layer problem. Reserve Dedicated Interconnect for the ≥10 Gbps sustained case where the colocation lease pays for itself. https://cloud.google.com/network-connectivity/docs/interconnect/concepts/partner-overview
Cross-Cloud Interconnect (CCI)
Cross-Cloud Interconnect is Google's productised answer to multi-cloud connectivity without forcing you to build your own meet-me hops.
How CCI Differs From DIY Multi-Cloud
Historically, a Google ↔ AWS link required a Dedicated Interconnect into your colocation, an AWS Direct Connect into the same colocation, and a customer router stitching the two together. CCI collapses that into a single Google-managed circuit: Google does the colocation work against the partner cloud's edge, and you receive a normal 10 Gbps or 100 Gbps port at one end.
Supported Target Clouds
CCI today supports AWS Direct Connect, Azure ExpressRoute, Oracle Cloud Infrastructure (OCI) FastConnect, and Alibaba Cloud Express Connect. Each target cloud still requires you to provision the corresponding object on its side (a Direct Connect Gateway on AWS, a Virtual Network Gateway on Azure, etc.).
VLAN Attachments on CCI
The Google side looks identical to a Dedicated Interconnect: you create VLAN attachments, attach them to a Cloud Router, and run BGP. The partner side runs the cloud-specific equivalent. Throughput is the same as Dedicated (10G/100G ports, 50 Mbps–50 Gbps attachments).
Latency Wins
Because the meet-me is inside a single Google-controlled facility next to the target cloud's edge, latency between two GCP and AWS regions typically drops 30-50% versus a DIY hairpin through an enterprise data centre, and you stop paying egress twice.
VLAN Attachments in Depth
The VLAN attachment is the unit of work for both billing and routing.
Attachment Fields
When you run gcloud compute interconnects attachments create my-attachment, the required arguments are: --region (the VPC region where Cloud Router lives), --router, --interconnect, --vlan (802.1Q tag, optional — Google can allocate one), --bandwidth (the capacity tier like BPS_10G), --admin-enabled, and for Partner: --edge-availability-domain. The attachment object then exposes Google-side fields like cloudRouterIpAddress, customerRouterIpAddress, and the pairingKey for Partner.
BGP Configuration on the Attachment
Each attachment hosts exactly one BGP session. You configure the peering on Cloud Router: peer-ip-address, peer-asn, advertised-route-priority (the BGP MED), and optionally advertise-mode custom with explicit prefix lists. Pre-shared MD5 keys are optional on Dedicated but recommended; some Partner Layer 2 providers require them.
IPv6 Support
Attachments can be created with --stack-type IPV4_IPV6 to dual-stack the BGP session. Both IPv4 and IPv6 prefixes are then exchanged on the same TCP session. IPv6-only attachments exist but require all linked subnets to be dual-stack or IPv6-only.
A VLAN attachment is bound to exactly one Cloud Router in one region, but a single Cloud Router can host many attachments. Plan one Cloud Router per VPC region per interconnect group; do not share a Cloud Router across unrelated trust domains because its BGP table is global to that router. https://cloud.google.com/network-connectivity/docs/router/concepts/overview
Edge Availability Domains and the Four-9s Topology
Edge Availability Domains (EADs) are the single most important concept for designing for SLA on Cloud Interconnect.
What an EAD Is
Inside every Google metro that hosts Interconnect (e.g. us-east1 has metros like Ashburn and Reston; asia-east1 has Changhua), Google operates two physically isolated edge zones — availability-domain-1 and availability-domain-2. Each EAD has its own optical line systems, edge routers, power feeds, and even fibre paths inside the building. A failure inside one EAD never propagates to the other.
The 99.9% Dual-EAD Topology
To earn the 99.9% SLA, you need at least one VLAN attachment in each of two different EADs within the same metro. The two attachments terminate on two different Google edge routers, and your on-prem must run BGP to both. ECMP load-balances traffic; if one EAD fails, BGP withdraws and traffic shifts to the surviving attachment within seconds.
The 99.99% Dual-Metro Topology
The four-9s SLA requires four VLAN attachments: a dual-EAD pair in metro A and a dual-EAD pair in metro B, with metros in different regions ideally. Your on-prem typically lands in two different data centres, each connecting to one metro. The four BGP sessions either all run active or you use AS path prepending to make metro B the standby.
Mapping EADs to Cloud Routers
Best practice: one Cloud Router per metro (not per EAD) in the four-9s pattern, with both EAD attachments terminating on the same Cloud Router. This gives unified BGP state per metro while keeping the physical failure domains separated.
The 99.99% SLA is per-metro-pair, not per-region. You cannot earn four-9s by putting two attachments in the same metro across two regions because both attachments still share the metro's failure domain. The requirement is explicitly two metros, each with two EADs. Misreading this is one of the most common exam traps. https://cloud.google.com/network-connectivity/docs/interconnect/concepts/sla
MACsec Encryption on Cloud Interconnect
By default, Dedicated and Partner Interconnect circuits are not encrypted — they ride private fibre but the bytes on the wire are plaintext. For regulated workloads (PCI DSS, HIPAA, GDPR-sensitive personal data), this matters.
MACsec on Dedicated Interconnect
MACsec (IEEE 802.1AE) is the link-layer encryption protocol Google supports natively on Dedicated Interconnect ports of 10 Gbps and 100 Gbps. When enabled, each Ethernet frame on the cross-connect is encrypted with AES-128-GCM or AES-256-GCM. Key exchange uses MKA (MACsec Key Agreement, IEEE 802.1X-2010) with a pre-shared CKN/CAK pair you upload via gcloud compute interconnects macsec commands.
What MACsec Does and Does Not Cover
MACsec covers the single hop between your router and Google's edge router on the cross-connect. It does not extend across the VLAN attachment into the VPC — once a frame is decrypted by Google's edge router, it travels the Google backbone in cleartext (though the backbone is itself encrypted at a different layer). Inside the VPC, traffic between VMs is encrypted at the network layer by Google.
MACsec vs HA VPN over Interconnect
The historic alternative for an encrypted on-prem-to-VPC link was HA VPN tunnels riding on top of an Interconnect (sometimes called HA VPN over Interconnect). MACsec replaces that pattern for Dedicated Interconnect: it is line-rate (no IPsec CPU overhead), supports the full attachment bandwidth, and avoids the MTU penalty of an IPsec header. HA VPN over Interconnect remains relevant if you specifically need IPsec compliance language or if you are on Partner Interconnect (MACsec is not available on Partner because the partner's circuit, not yours, sits between you and Google).
A common exam trap: candidates pick MACsec for a Partner Interconnect design. MACsec is only available on Dedicated Interconnect (and CCI), because it requires a direct cross-connect between your router and a Google edge router. For Partner Interconnect, the only Google-supported encryption pattern is HA VPN tunnels running over the attachment. https://cloud.google.com/network-connectivity/docs/interconnect/how-to/macsec/enabling-macsec
MTU Tuning: 1440, 1460, 1500, and 8896
MTU mismatch is the silent killer of hybrid networks. Cloud Interconnect attachments expose an explicit MTU setting, and you must match it consistently end-to-end.
Supported MTU Values
VLAN attachments support four MTU values: 1440, 1460, 1500, and 8896. The default is 1440 (chosen for backwards compatibility with VPCs that use the legacy default). You set it with --mtu on gcloud compute interconnects attachments create. The VPC the attachment connects into must use the same or higher MTU; you cannot point a 1500-MTU attachment at a 1460-MTU VPC.
When to Use Each Value
- 1440 — historic VPC default, safest interoperability with internet-bound traffic.
- 1460 — current Google Cloud VPC default; matches most modern cloud networks.
- 1500 — the standard Ethernet MTU on premises. Use this when you want zero fragmentation between on-prem and GCP.
- 8896 — jumbo frames. Use only on Dedicated Interconnect where both sides support jumbo, typically for high-throughput storage replication or HPC.
Path MTU Discovery and Don't-Fragment
If on-prem sends 1500-byte frames into a 1440-MTU attachment with the DF (don't fragment) bit set, the Google edge router returns ICMP Type 3 Code 4 ("fragmentation needed"). If your firewall drops that ICMP, PMTUD fails silently and TCP sessions stall on large payloads. The fix is either to match MTUs or to enable TCP MSS clamping on your CPE router.
Operational Verification
After creating an attachment, verify with gcloud compute interconnects attachments describe my-attachment --region=us-east1 --format='value(mtu)'. Cross-check against the VPC: gcloud compute networks describe my-vpc --format='value(mtu)'. Mismatches must be fixed before production cutover.
BGP Configuration: ASN 16550 and Cloud Router
BGP is the only routing protocol supported on Cloud Interconnect, and the ASN configuration differs between Dedicated and Partner.
ASN 16550 on Partner Interconnect
For Partner Interconnect, Google's Cloud Router always advertises BGP using public ASN 16550 — this is a Google-owned ASN reserved specifically for Partner peerings. Your Cloud Router's asn setting is ignored on Partner attachments; you set the peer ASN (the partner's ASN, or your own ASN if Layer 2) on the BGP session. Exam questions love this nuance.
Private ASNs on Dedicated Interconnect
For Dedicated and CCI attachments, you assign a private ASN to Cloud Router from the ranges 64512–65534 (16-bit) or 4200000000–4294967294 (32-bit). The on-prem side uses a different private ASN (or its own public one). 16550 is not used on Dedicated.
Route Advertisement Modes
Cloud Router supports two advertisement modes per BGP session: default (advertise all VPC subnets reachable to this Cloud Router) and custom (advertise an explicit prefix list, optionally including non-subnet ranges like aggregate routes for hub VPCs). The custom mode is mandatory if you use Network Connectivity Center hubs or HA VPN summary routes.
MED and AS Path Prepending
To steer traffic into a preferred metro under the four-9s topology, set --advertised-route-priority (which becomes the BGP MED, lower is preferred) on the standby metro's attachments to a higher value than the primary metro. AS path prepending on the on-prem side achieves the inverse — making one path look longer so Google's Cloud Router prefers the shorter one.
Cloud Router does not sit in the data path. It is a pure control-plane service running BGP and programming the VPC's route table. If Cloud Router goes offline, existing routes remain installed until the BGP hold timer (default 90 seconds) expires — traffic keeps flowing during brief Cloud Router outages, but new route changes cannot be learned. https://cloud.google.com/network-connectivity/docs/router/concepts/overview
Pricing, Egress, and Cost Optimisation
Cloud Interconnect changes the economics of egress dramatically and is one of the most common cost-optimisation levers on the exam.
What You Pay For
Three distinct charges: (1) the interconnect connection fee — a flat monthly charge per 10G or 100G port for Dedicated, or zero for Partner (your provider bills the port equivalent); (2) the VLAN attachment fee — a per-hour charge that scales with capacity tier; (3) Interconnect egress — a per-GB rate dramatically lower than internet egress, often around $0.02/GB versus $0.08–$0.23/GB for standard internet egress.
Ingress Is Free
Traffic flowing into Google Cloud over an Interconnect is free, just like internet ingress. The savings come from egress-heavy workloads: backup replication, BigQuery export to on-prem, big-data hydration.
When Cloud VPN Is Cheaper
Below roughly 3 TB/month sustained egress, the fixed cost of Interconnect attachments often loses to HA VPN, which has no fixed port fee and uses the same low-egress pricing once you exceed a free tier. The crossover varies by region and capacity tier but the heuristic is reliable for sizing.
Aggregating Across Projects
A single Dedicated Interconnect port lives in one project but VLAN attachments can be created in any project under the same organisation that has the right IAM. This means one organisation-owned "transit project" can host the physical port and amortise it across dozens of consuming projects, each with its own attachment and Cloud Router.
Operational Patterns and gcloud Cheat Sheet
Provisioning a Dedicated Interconnect End to End
# 1. Order the port (returns LOA-CFA)
gcloud compute interconnects create my-dedicated \
--customer-name="Acme Corp" \
--interconnect-type=DEDICATED \
--link-type=LINK_TYPE_ETHERNET_10G_LR \
--location=iad-zone1-1 \
--requested-link-count=1
# 2. After cross-connect is live, create Cloud Router
gcloud compute routers create my-router \
--network=my-vpc --region=us-east1 --asn=64512
# 3. Create VLAN attachment in EAD-1
gcloud compute interconnects attachments dedicated create attach-ead1 \
--region=us-east1 --router=my-router \
--interconnect=my-dedicated --vlan=100 \
--bandwidth=BPS_10G --mtu=1500 --admin-enabled
Provisioning a Partner Interconnect
# 1. Create the attachment and capture the pairing key
gcloud compute interconnects attachments partner create attach-partner \
--region=us-east1 --router=my-router \
--edge-availability-domain=availability-domain-1 \
--admin-enabled --description="Equinix Frankfurt"
# Returns: pairingKey = abcd1234.../us-east1/zone1
# 2. Give the pairing key to your partner; they activate their side
# 3. Re-run with --admin-enabled to bring up BGP
Daily Operations
Use gcloud compute interconnects attachments describe to check BGP state and bytes-per-second counters. Stackdriver/Cloud Monitoring exposes the interconnect.googleapis.com/network/attachment/sent_bytes_count and bgp/peer_route_count metrics for dashboards. Set alerts on bgp/peer_uptime to catch silent BGP flaps.
FAQs
Can I use Cloud Interconnect to reach Google public APIs like Cloud Storage?
Not through a VLAN attachment, which only reaches VPC resources. For Google public APIs over a private path you have three options: Private Google Access for on-premises hosts (uses an Interconnect plus a googleapis.com route to 199.36.153.4/30 or 199.36.153.8/30), Direct Peering (separate product, peers your ASN with Google for public APIs only — not recommended for new designs), or Private Service Connect endpoints placed in a VPC that the Interconnect reaches.
What is the difference between Dedicated Interconnect and Direct Peering?
Direct Peering is a legacy product where you peer your AS directly with Google's AS over a cross-connect to exchange routes for Google public services (Workspace, YouTube, public APIs). Direct Peering does not connect to a VPC. Dedicated Interconnect connects to a VPC over private IP and is the modern, recommended product for hybrid cloud. Google has been gently steering customers off Direct Peering for years.
How long does it take to provision a Dedicated Interconnect?
Google's port provisioning is typically a few business days after order. The bottleneck is almost always the colocation cross-connect (1–3 weeks at most facilities) and the local-loop circuit from the colocation back to your data centre (2–8 weeks depending on carrier and country). Plan 4–8 weeks total for a greenfield deployment.
Can I run Cloud Interconnect and HA VPN at the same time?
Yes, and it is a common pattern for migration: HA VPN provides immediate connectivity while you wait for the cross-connect, then both run in parallel with Cloud Router preferring the Interconnect via BGP MED. Once stable, you can either decommission the VPN or keep it as an encrypted failover (the HA-VPN-over-Interconnect pattern).
Does Interconnect support multicast?
No. Neither Dedicated nor Partner Interconnect carries IP multicast. If you have multicast applications, the standard pattern is to terminate multicast at the on-prem boundary, convert to unicast (PIM SSM tunnels or application-level fan-out), then send unicast over the Interconnect.
What happens if both EADs in a metro fail?
You lose all attachments in that metro simultaneously. If you only had the 99.9% topology (one metro, two EADs), connectivity is down until the metro recovers. This is precisely why the 99.99% topology requires a second metro: dual-metro is the failure boundary for the four-9s tier. Document recovery time objectives accordingly when choosing a tier.
Is there a minimum commit for Cloud Interconnect?
There is no contractual capacity commit, but the port fees are monthly and non-prorated below a month. For Partner Interconnect, your service provider may impose their own minimum-term contract (often 12 months). Always read the partner's MSA in parallel with Google's terms.