Multi-region VPC routing, resilient subnetting, and scalable egress are design patterns that ensure a Google Cloud network can survive failures across zones and regions while providing robust outbound internet connectivity. The goal is to eliminate single points of failure by distributing resources and configuring dynamic routing, subnetting, and egress gateways across multiple regions. A Virtual Private Cloud (VPC) is a global resource, but its subnets and routing are configured regionally.
Multi-region VPC routing involves configuring dynamic routing across a global VPC so traffic can find healthy paths around outages. Cloud Router manages the exchange of routes between the VPC and on-premises networks or other VPCs via hybrid connections like Cloud VPN or Interconnect. For high availability, you configure dynamic routing in a global mode (BGP) across multiple regions. This setup ensures that if a region becomes unavailable, the routing tables in healthy regions automatically learn new paths, and traffic flows to available backends without manual intervention. The control plane for this routing is managed globally, but the actual path packets take depends on the health of regional resources and the underlying Google network.
Resilient subnetting is the practice of designing IP address allocations and subnetworks to support redundancy and isolation across failure domains. In Google Cloud, you create subnets within a VPC as regional resources. For resilience, you distribute critical workloads across multiple subnets in different zones within a region, and you replicate this pattern across multiple regions. This ensures a zone or subnet failure does not take down an entire application tier. When using services like Managed Instance Groups (MIGs), you configure them as regional resources, which automatically distribute VMs across zones. The VPC's global nature means firewall rules and routes apply consistently, but subnet placement determines the failure domain for the resources within it.
Scalable egress refers to designing fault-tolerant outbound internet connectivity for resources without public IP addresses, primarily using Cloud NAT. Cloud NAT provides outbound NAT for instances using private IPs by allocating ports on its external IP addresses. To prevent port exhaustion and ensure high availability, you configure Cloud NAT gateways to auto-scale across multiple IP addresses and distribute them across zones within a region. For multi-region resilience, you deploy independent Cloud NAT configurations in each region where private instances reside. Traffic flows from the private instance to the Cloud NAT gateway in its zone (or a healthy gateway in another zone if the local one fails), which then sources the traffic from one of its external IPs. This design allows the gateway to handle peak utilization by automatically adding more IPs and ports.
Load balancer failover policies, health checks, and elastic backend scaling are mechanisms used in Google Cloud to direct traffic dynamically, detect application failures, and automatically adjust compute resources to match demand. In a resilient architecture, Cloud Load Balancing distributes incoming user requests across backend targets, while health checks continuously verify the operational status of individual instances.
Load balancer resilience is determined by whether a deployment uses global, cross-region, or regional load balancing resources. A global external HTTP/S load balancer operates via a single Anycast IP address and routes traffic across multiple Google Cloud regions to the closest healthy backend, providing automated cross-region failover if an entire region fails. Regional load balancers operate within a single region and are resilient to zonal outages, but an outage of the entire region renders the regional load balancer unavailable.
To achieve failover when using regional load balancers across multiple regions, architectures deploy independent regional load balancers in each target region paired with Cloud DNS routing policies. Traffic originates from the client and resolves destination endpoints via Cloud DNS policies, such as geofenced or failover routing. In normal operations, traffic is directed to the primary regional load balancer. If the primary region fails, Cloud DNS updates routing responses to steer new requests to the load balancer in the secondary (failover) region. For architectures using a global load balancer, traffic failover occurs transparently across Google’s backbone network to the next nearest healthy regional backend without requiring DNS updates.
A health check is a configuration resource that probes backend virtual machines (VMs) or endpoints to determine whether they can successfully receive and process application traffic. Ingress firewall rules must explicitly allow traffic from Google Cloud health check probe IP ranges to backend instances, as well as traffic from the proxy-only subnet when proxy-based load balancers are deployed.
Health check probes drive two distinct reliability functions. Load balancer health checks are periodic probes sent by the load balancing layer to each backend instance. If a VM fails the check, the load balancer immediately stops forwarding new requests to that unresponsive VM. MIG autohealing is used by a managed instance group (MIG) with an application-based health check assigned to its autohealing policy. When an instance fails health checks according to configured thresholds, the MIG control plane initiates an automated repair process by recreating the degraded VM from the associated instance template.
Autoscaling is a capability of stateless Managed Instance Groups that dynamically adds or removes Compute Engine VM instances based on measured resource utilization or workload signals. As traffic volume rises, the autoscaler provisions new VMs according to the parameters in the group’s instance template, and it removes instances when traffic declines to optimize costs. Stateful MIGs maintain persistent disks and IP states across recreation events but do not support horizontal autoscaling.
Autoscaling behavior is governed by specific metrics configured on the instance group. Target CPU utilization scales the group up or down to maintain an average target percentage of vCPU consumption. HTTP load balancing utilization triggers instance creation when the average backend utilization reaches a defined threshold. Schedule-based autoscaling provisions instances ahead of known traffic spikes based on recurring calendar intervals.
A backend service directs traffic to groups of endpoints organized as either Managed Instance Groups or Network Endpoint Groups (NEGs). Regional MIGs distribute stateless VMs evenly across multiple availability zones within a single region, protecting applications from single-zone failures. To mitigate physical server failures within a zone, a spread placement policy can be applied to the MIG template, ensuring that VMs run on distinct physical host hardware.
When workloads extend beyond standard Compute Engine instances or outside Google Cloud, NEGs structure destination targets for load balancers. Zonal NEGs group IP addresses and ports for workloads running within Google Cloud zones, such as container endpoints in Google Kubernetes Engine (GKE). Hybrid connectivity NEGs define non-Google Cloud endpoints located on-premises or across other cloud providers reachable through Cloud Interconnect or Cloud VPN. Cross-region internal Application Load Balancers can distribute internal enterprise traffic across mixed backends, seamlessly routing requests between Google Cloud zonal NEGs and hybrid connectivity NEGs.
High-availability hybrid connectivity in Google Cloud involves designing network architectures that meet 99.9% or 99.99% availability SLAs through redundant interconnect configurations, automated failover mechanisms, and deterministic routing policies. The architecture must account for single-region and multi-region topologies, BGP routing behaviors, and the specific requirements of different interconnection services.
Cloud Interconnect designs require a minimum of two connection locations that reside in the same region but exist in different edge availability domains. These duplicate connections can be configured as either active/active or active/passive topologies. In active/active mode, Equal Cost Multi-Path (ECMP) routing aggregates the bandwidth of both paths and uses them simultaneously; Cloud Interconnect also supports Link Aggregation Control Protocol (LACP)-aggregated links for high bandwidth. Active/passive mode forces one link to remain as a ready standby, only taking on traffic if the active link fails. Cloud Router is instantiated across multiple zones within a region for higher resiliency. This single-region design can support a 99.9% availability SLA within a single metropolitan area.
To increase availability, networks can peer at multiple geographical areas by connecting in multiple regions. When networks connect across multiple regions, the availability SLA can increase to 99.99%. Beyond resiliency, the multi-regional routing design should accomplish flow symmetry and indicate the preferred network for inter-regional communications. Flow asymmetry can cause issues with stateful security functions. The preferred network for inter-regional communications can be specified using hot-potato and cold-potato routing: pair cold-potato routing in one domain with hot-potato routing in the peer domain. For the cold-potato domain, Google recommends using the Google Cloud network domain, which provides global VPC routing functionality.
Google Cloud VPC networks and Cloud Router both support global cross-region routing, while other cloud service providers might have regional VPCs and BGP scopes. Cloud Router automatically advertises routes with predetermined path preferences based on regional proximity, and this routing behavior depends on the configured dynamic routing mode of the VPC. Administrators might need to override these preferences to achieve the desired routing behavior. To automate deterministic failover between Dedicated Interconnect, Partner Interconnect, and HA VPN tunnels, network architects configure dynamic BGP routing policies using Multi-Exit Discriminators (MED) and AS-Path prepending to control path selection.
When designing inter-regional routing, your IP addressing plan should result in fewer aggregate prefixes for each region and domain combination to improve scalability without exceeding prefix limits on edge devices. For inter-domain routing, designs that use Cloud Interconnect must have the minimum two connection locations in the same region but different edge availability domains. An active/active design is recommended for intra-regional links; however, certain on-premises networking topologies combined with the use of stateful security functions can necessitate an active/passive design.
A global external HTTP/S load balancer uses a single Anycast IP and automatically routes traffic to the closest healthy backend across multiple regions, providing transparent cross-region failover. A regional load balancer operates within a single region and is resilient to zonal failures, but requires a separate architecture (like using Cloud DNS failover policies) to redirect traffic to a different region if the entire primary region fails.
Use an active/active design to aggregate bandwidth and use both links simultaneously for intra-regional connectivity, which is the recommended approach. Use an active/passive design only when your on-premises network topology or the use of stateful security functions (like firewalls) necessitates having one link as a standby that only carries traffic if the primary link fails.
Autoscaling dynamically adds or removes VM instances in a Managed Instance Group (MIG) based on load metrics like CPU utilization to match demand. Autohealing recreates individual VM instances that have failed application health checks, replacing unhealthy instances with new ones from the instance template to maintain a fixed group size. Autoscaling changes the number of instances, while autohealing maintains their health.
A Network Endpoint Group (NEG) allows a load balancer's backend service to direct traffic to endpoints that are not standard Compute Engine VMs. This includes zonal endpoints like Google Kubernetes Engine pods or hybrid endpoints located on-premises or in other clouds, which are reached via Cloud Interconnect or Cloud VPN tunnels.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts