Prepare and test your skills
Prepare and test your skills
Manage Encryption, Routing, and Network Integration is the work of building private paths into a Virtual Private Cloud (VPC), exchanging routes over those paths, and making traffic visible to network security controls. In this design, Cross-Cloud Interconnect (opens in a new tab) provides the dedicated physical connection between Google Cloud and Amazon Web Services (AWS), Cloud Router manages Border Gateway Protocol (BGP) routing over logical attachments, and VPC firewall rules and hierarchical firewall policies enforce controls once traffic reaches the VPC network. Traffic flows from the VPC region through a VLAN attachment across the physical Interconnect to AWS routers, while BGP sessions exchange routes in both directions.
Cross-Cloud Interconnect is a dedicated physical connection between Google Cloud and AWS networks that Google provisions on behalf of the customer. The model is similar to Dedicated Interconnect because it does not require a partner provider, which is why ordering (opens in a new tab) uses --interconnect-type=DEDICATED. Google reserves ports and establishes the physical connection, while the customer completes tasks before and after provisioning. Each VLAN attachment represents a logical connection between a region in the VPC network and AWS resources.
Establishing the connection follows an ordered workflow where later steps depend on earlier reservations and authorizations:
High availability for Cross-Cloud Interconnect depends on ordering two connections, a primary connection and a redundant one, to satisfy the service level agreement (SLA). After each order, Google sends a confirmation email with instructions for the next step, including ordering AWS ports. The redundant connection uses the same remote location and Google Cloud location as the primary connection to provide a paired, resilient path.
Location selection uses two distinct names on every order. The remote location is the AWS location name used in Google Cloud ordering, while the Google Cloud location is the Cross-Cloud Interconnect facility location. The remote location name varies depending on whether you interact with AWS or Google Cloud, the Google Cloud console shows the remote location description next to the name to help choose correctly, and the Cloud Interconnect location display shows facility information rather than the location name alone. Capacity is selected at order time and determines the number of Link Aggregation Control Protocol (LACP) links:
The gcloud compute interconnects create command uses --link-type for capacity, such as LINK_TYPE_ETHERNET_10G_LR or LINK_TYPE_ETHERNET_100G_LR, and --requested-link-count for the number of LACP links. Valid link counts are 1 through 4 for 10-Gbps connections, and 1 or 2 for 100-Gbps and 400-Gbps connections. The command also requires --location for the Google Cloud edge availability zone, --remote-location for the remote location, and --noc-contact-email for the technical contact.
Routing integration with Cloud Router controls how VPC routes propagate and are advertised over private connectivity. For each VLAN attachment, Cloud Router configures a BGP peering session that connects the VPC network to the remote network. The AWS side configures a matching BGP peering session, so route advertisements flow in both directions between the VPC and AWS over the Interconnect.
This structure separates physical capacity from logical routing. The physical Interconnect provides ports and capacity, the VLAN attachment provides the logical connection from a specific VPC region, and the Cloud Router BGP session manages dynamic route exchange for that attachment. Creating a redundant set of VLAN attachments with BGP sessions on both primary and redundant connections preserves route propagation if one physical path fails.
Network security integration with intranode visibility (opens in a new tab) ensures that VPC firewall rules and hierarchical firewall policies consistently apply to Google Kubernetes Engine (GKE) Pod-to-Pod traffic. Intranode visibility configures networking on each GKE node so traffic sent from one Pod to another Pod is processed by the VPC network, even if both Pods are on the same node. When a Pod sends a packet to another Pod on the same node, the packet leaves the node, is processed by the Google Cloud network, and is then immediately sent back to the same node and forwarded to the destination Pod.
Because the VPC network processes these packets, it can apply firewall rules, routes, flow logs, and packet mirroring configurations to all Pod-to-Pod communication regardless of Pod placement. Intranode visibility provides three related capabilities:
Implementation depends on the cluster data plane. In GKE Dataplane V2 on GKE version 1.36.0-gke.3302000 or later, intranode visibility is eBPF-native and traffic redirection is processed in eBPF, bypassing the host network stack. In earlier GKE versions or non-GKE Dataplane V2 clusters, the netd DaemonSet manages packet redirection on the node. Intranode visibility has specific requirements and limitations: the cluster must be on GKE version 1.15 or later, it is not supported with Windows Server node pools, it applies only to traffic on the default network for clusters with multi-networking for Pods, and when using ip-masq-agent the custom nonMasqueradeCIDRs list must include the cluster's node and Pod IP ranges. Enabling intranode visibility on an existing cluster restarts components in the control plane and worker nodes and requires recreating nodes, which can disrupt running workloads.
Exam tip: Intranode visibility is disabled by default on Standard clusters and enabled by default on Autopilot clusters.
Configure and Secure VPN and Interconnect Implementations is the configuration of redundant physical connections and logical routing so a data center or remote cloud reaches a Google Cloud VPC network with encryption in transit. In this implementation, Cross-Cloud Interconnect (opens in a new tab) establishes a dedicated physical connection between Google Cloud and AWS networks without traversing the public internet, and Google provisions the physical connection on behalf of the customer. The customer completes location selection, ordering, letter of authorization (LOA) handling, VLAN attachment creation, and BGP peering to make the connection redundant, routable, and verifiable.
The redundant physical connection model requires two Cross-Cloud Interconnect connections, a primary connection and a redundant connection, to satisfy the service level agreement (SLA). Google reserves two ports in the specified facility after the order, sends a confirmation email for each port with instructions for ordering AWS ports, and begins establishing the connections only after receiving the AWS LOA. Traffic flows from the VPC network through the VLAN attachments across either physical path to the AWS router, so failure of one path leaves the redundant path to preserve connectivity.
The Cross-Cloud Interconnect provisioning workflow is an ordered sequence where Google and customer tasks interleave and later steps depend on earlier reservations and authorizations. Each VLAN attachment represents a logical connection between a region in the VPC network and AWS resources, and the Cloud Router BGP sessions on those attachments control route exchange between the two sides.
The required order is fixed:
Ordering Cross-Cloud Interconnect connections (opens in a new tab) defines the physical capacity, facility placement, and administrative contact for both paths. In the Google Cloud console, the flow goes from Physical connections to Set up physical connection to Cross-Cloud Interconnect connection to Order new Cross-Cloud Interconnect connection, where the customer selects Remote cloud provider, Remote location, Google Cloud location, and Capacity, then repeats the redundant connection in the same locations with a technical contact email and billing review. The redundant connection must use the same Remote location and Google Cloud location as the primary connection, and the remote location name used with Google Cloud differs in syntax from the similar name used with AWS.
Valid connection capacities include:
The equivalent gcloud compute interconnects create command uses --interconnect-type=DEDICATED because Cross-Cloud Interconnect, like Dedicated Interconnect, does not require a partner provider. The command also sets --link-type for capacity such as LINK_TYPE_ETHERNET_10G_LR or LINK_TYPE_ETHERNET_100G_LR, --requested-link-count for the number of LACP links, --location for one of the two edge availability zones such as fra-zone1-58, --remote-location for the remote location, and --noc-contact-email for the contact address.
Exam tip: Order both primary and redundant connections in the same Remote location and Google Cloud location; two connections are required to satisfy the Cross-Cloud Interconnect SLA.
VLAN attachments and Cloud Router BGP management turn reserved physical ports into routable private connectivity from a specific VPC region to AWS. The customer creates a redundant set of VLAN attachments in the VPC network, where each attachment binds a VPC region to the Interconnect connection, and then configures a BGP peering session on Cloud Router for each attachment while also creating the matching BGP session on AWS. Because route exchange flows from Cloud Router to each VLAN attachment peer and onward to the remote router, consistent autonomous system numbers, peer IP addresses, and advertised routes on both sides are required for dynamic routing to converge. When one attachment fails, dynamic routing fails over to the surviving attachment only if both sides were configured consistently.
Architect Hybrid Connectivity with High Availability and Redundancy is the design of redundant, encrypted paths between an on-premises data center and a VPC network so failure of any single link, device, or path does not interrupt traffic. Resilience comes from combining High-Availability Virtual Private Network (HA VPN) tunnels, multiple Cloud Interconnect (opens in a new tab) attachments, and dynamic routing with BGP. The choice between them balances throughput, service-level agreement (SLA), cost, and operational complexity against business continuity requirements.
High-Availability Virtual Private Network (HA VPN) is the IPsec VPN solution that securely connects a peer network to a VPC network through encrypted tunnels. When you create an HA VPN gateway, Google Cloud automatically assigns two external IP addresses, one for each gateway interface, with each address chosen from a unique pool to support high availability. Each interface supports multiple tunnels, and you can create multiple HA VPN gateways in the same region to add paths between the on-premises peer VPN gateway and the VPC network.
HA VPN supports only dynamic routing with BGP and supports active/active and active/passive routing options. The active/active option lets multiple tunnels carry traffic at the same time, which is required when traffic volume exceeds what a single VPN tunnel can support. Based on topology and configuration, HA VPN can provide 99.99% or 99.9% service availability, and HA VPN uses an external VPN gateway resource in Google Cloud to store information about the peer VPN gateway.
Exam tip: An HA VPN gateway configured with only one active interface and one external IP address provides no availability SLA.
Cloud Interconnect is the private-transport family that extends an on-premises network to VPC networks without traversing the public internet, with more deterministic performance and an SLA. The family includes Dedicated Interconnect for a direct physical connection, Partner Interconnect for connection through a supported service provider, and Cross-Cloud Interconnect for private connectivity between Google Cloud and another cloud provider. When choosing between Dedicated Interconnect and Partner Interconnect, evaluate connection location and required capacity.
Redundancy requires more than one attachment in more than one failure domain. A redundant setup uses two Dedicated Interconnect connections in a common colocation facility, with routes exchanged between Cloud Router and the remote gateway through a physical router. When using Partner Interconnect redundantly, Google offers 99.9% to 99.99% monthly SLAs depending on the chosen topology, while a single Partner Interconnect connection has no SLA. Cross-Cloud Interconnect offers high-availability options of 99.9% and 99.99% with line-rate performance as a managed service where Google handles cross-connects and routing equipment.
Encryption behavior differs between VPN and private transport. Cloud VPN encrypts traffic between environments with IPsec, where one VPN gateway encrypts and the other decrypts, and it cannot route traffic to the public internet. Cloud Interconnect by itself does not encrypt at the connectivity layer, so you must add either Media Access Control Security (MACsec) for Cloud Interconnect or HA VPN over Cloud Interconnect to encrypt traffic in transit at that layer.
HA VPN over Cloud Interconnect combines IPsec encryption from Cloud VPN with the increased capacity of Cloud Interconnect, and traffic using this combination never traverses the public internet. When deployed over Cloud Interconnect, HA VPN gateway interfaces can use regional internal IP addresses, but only for gateways associated with VLAN attachments. If you use Partner Interconnect to connect to third-party providers, you must add IPsec encryption to meet data security and compliance requirements, and you can also add service-layer encryption with Transport Layer Security (TLS).
Cloud Router (opens in a new tab) is the BGP-based service that provides dynamic routing for hybrid connectivity. Cloud Router exchanges routes with the on-premises router or remote cloud gateway over both HA VPN tunnels and Cloud Interconnect VLAN attachments, so traffic flows from the data center to the VPC network over the healthy path and fails over when a tunnel or attachment fails. Cloud Router is used together with Cloud VPN gateways and Cloud Interconnect, not as a standalone connection.
For complex environments, Network Connectivity Center (NCC) (opens in a new tab) acts as an orchestration framework that connects spoke resources to a central hub resource. Spoke resources include VPC networks, router appliances, and hybrid connections, while the hub manages connectivity and route exchange with the Cloud Router instance. NCC also enables integration of third-party network virtual appliances, and Network Intelligence Center provides a single console for network visibility, monitoring, and troubleshooting to maintain reliable communications.
Resilient design starts by assessing reliability requirements per application and weighing SLA, performance, security, cost, reliability, and bandwidth together rather than in isolation. The decision criteria interact because inter-environment links carry all hybrid application traffic:
The connectivity products divide by these trade-offs:
| Product | Throughput and use case | Cost and complexity |
|---|---|---|
| Cloud VPN (HA VPN) | Lower bandwidth; best for lower-cost, experimental, or smaller migrations; scales with active/active tunnels | Lower cost over public internet; no colocation hardware; traffic traverses public internet unless paired with Interconnect |
| Dedicated Interconnect | 10 Gbps or more per connection; enterprise-grade throughput with deterministic performance | Higher complexity because you host and maintain physical routers in a colocation facility; reserved for sustained high rates unless infrastructure already exists |
| Partner Interconnect | Normally less than 10 Gbps per connection; dedicated capacity through a service provider with 99.9%-99.99% SLA when redundant | Monthly per-attachment fee plus provider charges; lower egress rates than internet; no SLA on a single connection |
| Cross-Cloud Interconnect | Line-rate multicloud performance between Google Cloud and supported providers with 99.9% or 99.99% options | Lower total cost of ownership without managing remote routing equipment; helps optimize performance and may reduce outbound charges for qualifying high-volume, long-term traffic |
For long-term hybrid or multicloud setups with high outbound volumes, Cloud Interconnect or Cross-Cloud Interconnect optimizes performance and may reduce outbound data transfer charges when traffic meets pricing conditions.
Cloud Interconnect does not encrypt traffic by itself and requires either Media Access Control Security (MACsec) for Cloud Interconnect or High-Availability Virtual Private Network (HA VPN) over Cloud Interconnect for encryption in transit. HA VPN over Cloud Interconnect combines IPsec encryption from Cloud VPN with the increased capacity of Cloud Interconnect, and traffic using this combination never traverses the public internet.
Cross-Cloud Interconnect requires a primary connection and a redundant connection in the same Remote location and Google Cloud location to satisfy the service level agreement (SLA). Each VLAN attachment represents a logical connection between a region in the Virtual Private Cloud (VPC) network and AWS resources, and Cloud Router configures a Border Gateway Protocol (BGP) peering session for each attachment to exchange routes in both directions.
When you create an HA VPN gateway, Google Cloud automatically assigns two external IP addresses, one for each gateway interface, with each address chosen from a unique pool to support high availability. HA VPN supports only dynamic routing with BGP and supports active/active and active/passive routing options, and a gateway configured with only one active interface and one external IP address provides no availability SLA.
An enterprise organization is scaling hybrid connectivity between its on-premises data center and a Google Cloud Virtual Private Cloud (VPC) network. The current throughput requirements exceed the capacity of a single High Availability (HA) VPN gateway (250,000 packets per second per tunnel). The network security team must design an expanded VPN architecture that meets the following criteria:
Which architectural design should the team implement?
Last updated