This document describes how to use floating IP address implementation patternswhen migrating applications to Compute Engine from an on-premisesnetwork environment. This document is aimed at network engineers, systemadministrators, and operations engineers who are migrating applications toGoogle Cloud.

Also referred to as shared or virtual IP addresses, floating IP addresses areoften used to make on-premises network environments highly available. Usingfloating IP addresses, you can pass an IP address between multiple identicallyconfigured physical or virtual servers. This practice allows for failover or forupgrading production software. However, you can't directly implement floating IPaddresses in a Compute Engine environment without changing thearchitecture to one of the patterns described in this document.

TheGitHub repository that accompanies this document includes sample deployments for each pattern thatyou can automatically deploy usingTerraform.

Floating IP addresses in on-premises environments

Floating IP addresses are commonly used in on-premises environments. Example usecases are as follows:

• Highly available physical appliances, such as a set of firewalls orload balancers, often use floating IP addresses for failovers.
• Servers that require high availability typically use floating IPaddresses—for example, relational databases using a primary server and abackup server. A common example, Microsoft SQL Server, usesAlwaysOn Availability Groups.To learn how to implement these patterns on Google Cloud, seeConfiguring SQL Server AlwaysOn availability groups with synchronous commit.
• Linux environments that implement load balancers or reverse proxies usefloating IP addresses, likeIP Virtual Server (IPVS),HAProxy,andnginx.For detecting node failures and moving floating IP addresses betweeninstances, these environments use daemons such asHeartbeat,Pacemaker,orKeepalived.
• Highly available Windows Services withWindows Server Failover Clustering use floating IP addresses to ensure high availability. To implement WindowsServices using failover clustering on Google Cloud, seeRunning Windows Server Failover Clustering.

There are several ways to implement floating IP addresses in an on-premisesenvironment. Servers sharing floating IP addresses typically also share stateinformation through aheartbeat mechanism.This mechanism lets the servers communicate their health status to eachother; it also lets the secondary server take over the floating IP addressafter the primary server fails. This scheme is frequently implemented using theVirtual Router Redundancy Protocol,but you can also use other, similar mechanisms.

Once an IP address failover is initiated, the server taking over the floating IPaddress adds the address to its network interface. The server announces thistakeover to other devices using Layer 2 by sending agratuitous Address Resolution Protocol (ARP) frame.Alternatively, sometimes a routing protocol likeOpen Shortest Path First (OSPF),announces the IP address to the upstream Layer 3 router.

The following diagram shows a typical setup in an on-premises environment.

The preceding diagram shows how a primary server and a secondary serverconnected to the same switch exchange responsiveness information through a heartbeat mechanism. If the primary server fails, the secondary server sends agratuitous ARP frame to the switch to take over the floating IP address.

You use a slightly different setup with on-premises load-balancing solutions,such as Windows Network Load Balancing or a Linux Load Balancing with DirectServer response like IPVS. In these cases, the service also sends out gratuitousARP frames, but with the MAC address of another server as the gratuitous ARPsource. This action essentially spoofs the ARP frames and takes over the sourceIP address of another server.

This action is done to distribute the load for one IP address between differentservers. However, this kind of setup is out of scope for this document. Inalmost all cases when floating IP addresses are used for on-premises loadbalancing, migrating toCloud Load Balancing is preferred.

Challenges with migrating floating IP addresses to Compute Engine

Compute Engine uses a virtualized network stack in aVirtual Private Cloud (VPC) network, so typical implementation mechanisms don't work without changes inGoogle Cloud. For example, the VPC network handles ARP requests in thesoftware-defined network, and ignores gratuitous ARP frames. In addition, it'simpossible to directly modify the VPC network routing table with standardrouting protocols such as OSPF or Border Gateway Protocol (BGP). The typicalmechanisms for floating IP addresses rely on ARP requests being handled byswitching infrastructure or they rely on networks programmable by OSPF or BGP.Therefore, IP addresses don't failover using these mechanisms inGoogle Cloud. If you migrate a virtual machine (VM) image using anon-premises floating IP address, the floating IP address can't fail over withoutchanging the application.

You could use anoverlay network to create a configuration that enables full Layer 2 communication and IPtakeover through ARP requests. However, setting up an overlay network is complexand makes managing Compute Engine network resources difficult. Thatapproach is also out of scope for this document. Instead, this document describes patterns for implementing failover scenarios in a Compute Enginenetworking environment without creating overlay networks.

To implement highly available and reliable applications inCompute Engine, use horizontally scaling architectures. This type ofarchitecture minimizes the effect of a single node failure.

This document describes multiple patterns to migrate an existing applicationusing floating IP addresses from on-premises to Compute Engine,including the following:

• Patterns using load balancing:
  • Active-active load balancing
  • Load balancing with failover groups and application-exposed health checks
  • Load balancing with failover groups and heartbeat-exposed health checks
• Patterns using Google Cloud routes:
  • Using ECMP routes
  • Using different priority routes
  • Using a heartbeat mechanism to switch a route's next hop
• Pattern using autohealing:
  • Using an autohealing single instance

UsingAlias IP addresses that move between VM instances is discouraged as a failovermechanism because it doesn't meet high availability requirements. In certainfailure scenarios, like a zonal failure event, you might not be able to removean Alias IP address from an instance. Therefore, you might not be able to add itto another instance—making failover impossible.

Selecting a pattern for your use case

Depending on your requirements, one or more of the patterns described in thissolution might be useful to implement floating IP addresses in an on-premisesenvironment.

Consider the following factors when deciding what pattern best lets you use anapplication:

• Floating internal or floating external IP address: Mostapplications that require floating IP addresses use floating internal IPaddresses. Few applications use floating external IP addresses, becausetypically traffic to external applications should be load balanced.

  The table later in this section recommends patterns you can use for floatinginternal IP addresses and for floating external IP addresses. For use casesthat rely on floating internal IP addresses, any of these patterns might beviable for your needs. However, we recommend that use cases relying onfloating external IP addresses should be migrated to one of thepatterns using load balancing.

• Application protocols: If your VM only uses TCP and UDP, you canuse all of the patterns in the table. If it uses other protocols on top ofIPv4 to connect, only some patterns are appropriate.

• Active-active deployment compatibility: Some applications, whileusing floating IP addresses on-premises, can work in anactive-active deployment mode.This capability means they don't necessarily require failover from theprimary server to the secondary server. You have more choices of patterns tomove these kinds of applications to Compute Engine. Applicationsthat require only a single application server to receive traffic at any timearen't compatible with active-active deployment. You can only implementthese applications with some patterns in the following table.

• Failback behavior after primary VM recovers: When the originalprimary VM recovers after a failover, depending on the pattern used,traffic does one of two things. It either immediately moves back to theoriginal primary VM or it stays on the new primary VM until failback isinitiated manually or the new primary VM fails. In all cases, only newlyinitiated connections fail back. Existing connections stay at the newprimary VM until they are closed.

• Health check compatibility: If you can't check if yourapplication is responsive using Compute Enginehealth checks,without difficulty, you can't use some patterns described in the followingtable.

• Instance groups: Any pattern with health check compatibility isalso compatible withinstance groups. To automaticallyrecreate failed instances, you can use a managed instance group with autohealing.If your VMs keep state, you can use a stateful managedinstance group. If your VMs can't be recreated automatically or yourequire manual failover, use an unmanaged instance group and manuallyrecreate the VMs during failover.

• Existing heartbeat mechanisms: If the high availability setup foryour application already uses a heartbeat mechanism to trigger failover,like Heartbeat, Pacemaker, or Keepalived, you can use some patternsdescribed in the following table.

The following table lists pattern capabilities. Each pattern is describedin the following sections:

• Patterns using load balancing
• Patterns using Google Cloud routes
• Pattern using autohealing

Deciding which pattern to use for your use case might depend on multiplefactors. The following decision tree can help you narrow your choices to asuitable option.

The preceding diagram outlines the following steps:

1. Does a single autohealing instance provide good enough availability for your needs?
   1. If yes, seeUsing an autohealing single instance later in this document. Autohealing uses a mechanism in a VM instance group to automatically replace a faulty VM instance.
   2. If not, proceed to the next decision point.
2. Does your application need protocols on top of IPv4 other than TCP and UDP?
   1. If yes, proceed to the next decision point.
   2. If no, proceed to the next decision point.
3. Can your application work in active-active mode?
   1. If yes and it needs protocols on top of IPv4 other than TCP and UDP, seeUsing equal-cost multipath (ECMP) routes later in this document. ECMP routes distribute traffic among the next hops of all route candidates.
   2. If yes and it doesn't need protocols on top of IPv4 other than TCP and UDP, seeActive-active load balancing later in this document. Active-active load balancing uses your VMs as backends for an internal TCP/UDP load balancer.
   3. If not–in either case–proceed to the next decision point.
4. Can your application expose Google Cloud health checks?
   1. If yes and it doesn't need protocols on top of IPv4 other than TCP and UDP, seeLoad balancing with failover and application-exposed health checks later in this document. Load balancing with failover and application-exposed health checks uses your VMs as backends for an internal TCP/UDP load balancer. It also uses the Internal TCP/UDP Load Balancing IP address as a virtual IP address.
   2. If yes and it needs protocols on top of IPv4 other than TCP and UDP, seeUsing different priority routes later in this document. Using different priority routes helps ensure that traffic always flows to a primary instance unless that instance fails.
   3. If no and it needs protocols on top of IPv4 other than TCP and UDP, seeLoad balancing with failover and heartbeat-exposed health checks later in this document. In the load balancing with failover and heartbeat-exposed health checks pattern, health checks aren't exposed by the application itself but by a heartbeat mechanism running between both VMs.
   4. If no and it DOES NOT NEED protocols on top of IPv4 other than TCP and UDP, seeUsing a heartbeat mechanism to switch a route's next hop later in this document. Using a heartbeat mechanism to switch a route's next hop uses a single static route with the next-hop pointing to the primary VM instance.

Patterns using load balancing

Usually, you can migrate your application using floating IP addresses to anarchitecture in Google Cloud that usesCloud Load Balancing.You can use aninternal passthrough Network Load Balancer,as this option fits most use cases where the on-premises migrated service isonly exposed internally. This load-balancing option is used for all examples inthis section and in the sample deployments on GitHub. If you have clientsaccessing the floating IP address from otherregions, select theglobal access option.

If your application communicates using protocols on top of IPv4, other than TCPor UDP, you must choose a pattern that doesn't use load balancing. Thosepatterns are described later in this document.

If your application uses HTTP(S), you can use aninternal Application Load Balancer to implement the active-active pattern.

If the service you are trying to migrate is externally available, you canimplement all the patterns that are discussed in this section by usinganexternal passthrough Network Load Balancer.For active-active deployments, you can also use anexternal Application Load Balancer,aTCP proxy,oranSSL proxy if your application uses protocols and ports supported by those load balancingoptions.

Consider the following differences between on-premises floating-IP-address-basedimplementations and all load-balancing-based patterns:

• Failover time: Pairing Keepalived with gratuitous ARP in anon-premises environment might fail over an IP address in a few seconds. Inthe Compute Engine environment, the mean recovery time fromfailover depends on the parameters you set. In case the virtual machine(VM) instance or the VM instance service fails, the mean-time-to-failovertraffic depends on health check parameters such asCheck Interval andUnhealthy Threshold. With these parameters set to their default values,failover usually takes 15–20 seconds. You can reduce the time by decreasingthose parameter values.

  In Compute Engine, failovers within zones or between zonestake the same amount of time.

• Protocols and Ports: In an on-premises setup, the floating IPaddresses accept all traffic. Choose one of the following portspecifications in the internal forwarding rule for the internal passthrough Network Load Balancer:

  • Specify at least one port and up to five ports by number.
  • SpecifyALL to forward traffic on all ports for either TCP or UDP.
  • Usemultiple forwarding rules with the same IP address to forward a mix of TCP and UDP traffic or to use more than five portswith a single IP address:
    • Only TCP or UDP and 1—5 ports: Use one forwarding rule.
    • TCP and UDP and 1—5 ports: Use multiple forwarding rules.
    • 6 or more ports and TCP or UDP: Use multiple forwarding rules.

• Health checking: On-premises, you can check applicationresponsiveness on a machine in the following ways:

  • Receiving a signal from the other host specifying that it isstill responsive.
  • Monitoring if the application is still available through thechosen heartbeat mechanism (Keepalived, Pacemaker, or Heartbeat). InCompute Engine, thehealth check has to be accessible from outside the host through gRPC, HTTP, HTTP/2,HTTPS, TCP, or SSL. Theactive-active load balancing andload balancing with failover group and application exposed health checking patterns require that your application expose its health checks. Tomigrate services using an existing heartbeat mechanism, you can use theload balancing with failover groups and heartbeat-exposed health checks pattern.

Active-active load balancing

In the active-active load balancing pattern, your VMs are backends for aninternal passthrough Network Load Balancer. You use the internal passthrough Network Load Balancer IP address as avirtual IP address. Traffic is equally distributed between the two backendinstances. Traffic belonging to the same session goes to the same backendinstance as defined in thesession affinity settings.

Use the active-active load balancing pattern if your application only usesprotocols based on TCP and UDP and doesn't require failover between machines.Use the pattern in a scenario where applications can answer requests dependingon the content of the request itself. If there is a machine state that isn'tconstantly synchronized, don't use the pattern—for example, in a primary orsecondary database.

The following diagram shows an implementation of the active-active loadbalancing pattern:

The preceding diagram shows how an internal client accesses a service that runson two VMs through an internal passthrough Network Load Balancer. Both VMs are part of an instance group.

The active-active load balancing pattern requires your service to expose healthchecks using one of thesupported health check protocols to ensure that only responsive VMs receive traffic.

For a full sample implementation of this pattern, see theexample deployment with Terraform on GitHub.

Load balancing with failover and application-exposed health checks

Similar to the active-active pattern, the load balancing through failover andapplication-exposed health checks pattern uses your VMs as backends for aninternal passthrough Network Load Balancer. It also uses the internal passthrough Network Load Balancer IP address asa virtual IP address. To ensure that only one VM receives traffic at a time,this pattern appliesfailover for internal passthrough Network Load Balancers.

This pattern is recommended if your application only has TCP or UDP traffic, butdoesn't support an active-active deployment. When you apply this pattern, alltraffic flows to either the primary VM or the failover VM.

The following diagram shows an implementation of the load balancing withfailover and application-exposed health checks pattern:

The preceding diagram shows how an internal client accesses a service behind aninternal passthrough Network Load Balancer. Two VMs are in separate instance groups. One instance groupis set as a primary backend. The other instance group is set as a failoverbackend for an internal passthrough Network Load Balancer.

If the service on the primary VM becomes unresponsive, traffic switches over tothe failover instance group. Once the primary VM is responsive again, trafficautomatically switches back to the primary backend service.

For a full sample implementation of this pattern, see theexample deployment with Terraform on GitHub.

Load balancing with failover and heartbeat-exposed health checks

The load balancing with failover and heartbeat-exposed health checks pattern isthe same as the previous pattern. The difference is that health checks aren'texposed by the application itself but by a heartbeat mechanism running betweenboth VMs.

The following diagram shows an implementation of the load balancing withfailover and heartbeat-exposed health checks pattern:

This diagram shows how an internal client accesses a service behind an internalload balancer. Two VMs are in separate instance groups. One instance group isset as a primary backend. The other instance group is set as a failover backendfor an internal passthrough Network Load Balancer. Keepalived is used as a heartbeat mechanismbetween the VM nodes.

The VM nodes exchange information on the status of the service using the chosenheartbeat mechanism. Each VM node checks its own status and communicates thatstatus to the remote node. Depending on the status of the local node and thestatus received by the remote node, one node is elected as the primary node andone node is elected as the backup node. You can use this status information toexpose a health check result that ensures that the node consideredprimary inthe heartbeat mechanism also receives traffic from the internal passthrough Network Load Balancer.

For example, with Keepalived you can invoke scripts using thenotify_master,notify_backup, andnotify_faultconfiguration variables that change the health check status. On transition to theprimary state (inKeepalived this state is calledmaster), you can start an application thatlistens on a custom TCP port. When transitioning to a backup or fault state, youcan stop this application. The health check can then be a TCP health check thatsucceeds if this custom TCP port is open.

This pattern is more complex than the pattern using failover withapplication-exposed health checks. However, it gives you more control. Forexample, you can configure it to fail back immediately or manually as part of theimplementation of the heartbeat mechanism.

For a full sample implementation of this pattern that uses Keepalived, see theexample deployment with Terraform on GitHub.

Patterns using Google Cloud routes

In cases where your application uses protocols other than TCP or UDP on top ofIPv4, you can migrate your floating IP address to a pattern based on routes.

In this section, mentions of routes always refer toGoogle Cloud routes that are part of a VPC network. References to static routes always refer tostatic routes on Google Cloud.

Using one of these patterns, you set multiple static routes for a specific IPaddress with the different instances as next-hops. This IP address becomes thefloating IP address all clients use. It needs to be outside allVPC subnet IP address ranges because static routes can't override existing subnet routes. You mustturn on IP address forwarding on the target instances. Enabling IP address forwarding lets you accept trafficfor IP addresses not assigned to the instances—in this case the floating IPaddress.

If you want the floating IP address routes to be available frompeered VPC networks,export custom routes so the floating IP address routes propagate to all peer VPC networks.

To have connectivity from an on-premises network connected throughCloud Interconnect orCloud VPN,you need touse custom IP address route advertisements to have the floating IP address advertised on-premises.

Route-based patterns have the following advantage over load-balancing-basedpatterns:

• Protocols and Ports: Route-based patterns apply to all traffic sentto a specific destination. Load-balancing-based patterns only allow for TCP andUDP traffic.

Route-based patterns have the following disadvantages over load-balancing-basedpatterns:

• Health checking: Health checks can't be attached toGoogle Cloud routes. Routes are used regardless of the health of theunderlying VM services. Whenever the VM is running, routes direct trafficto instances even if the service is unhealthy.Attaching an autohealing policy to those instances replaces the instances after an unhealthy time periodthat you specify. However, once those instances restart, traffic resumesimmediately—even before the service is up. This service gap can lead topotential service errors when unhealthy instances are still serving trafficor are restarting.
• Failover time: After you delete or stop a VM instance,Compute Engine disregards any static route pointing to thisinstance. However, since there are no health checks on routes,Compute Engine still uses the static route as long as the instanceis still available. In addition, stopping the instance takes time, sofailover time is considerably higher than it is with load-balancing-basedpatterns.
• Internal floating IP addresses only: While you can implementpatterns using load balancing with an external passthrough Network Load Balancer to createan external floating IP address, route-based patterns only work withinternal floating IP addresses.
• Floating IP address selection: You can set routes only to internalfloating IP addresses that aren't part of any subnet—subnet routes can't beoverwritten in Google Cloud. Track these floating IP addresses so youdon't accidentally assign them to another network.
• Routes reachability: To make internal floating IP addressesreachable from on-premises networks or peered networks, you need todistribute those static routes as described previously.

Using equal-cost multipath (ECMP) routes

Theequal-cost multipath (ECMP) routes pattern is similar to the active-active load balancing pattern—traffic isequally distributed between the two backend instances. When you usestatic routes,ECMP distributes traffic among the next hops of all route candidates by using afive-tuple hash for affinity.

You implement this pattern by creating two static routes of equal priority withthe Compute Engine instances as next-hops.

The following diagram shows an implementation of the ECMP routes pattern:

The preceding diagram shows how an internal client accesses a service using oneof two routes with the next hop pointing to the VM instances implementing theservice.

If the service on one VM becomes unresponsive, autohealing tries to recreate theunresponsive instance. Once autohealing deletes the instance, the route pointingto the instance becomes inactive before the new instance has been created.Once the new instance exists, the route pointed to this instance isimmediately used automatically and traffic is equally distributed betweeninstances.

The ECMP routes pattern requires your service to expose health checks usingsupported protocols so autohealing can automatically replace unresponsive VMs.

You can find a sample implementation of this pattern using Terraform in theGitHub repository associated with this document.

Using different priority routes

The different priority routes pattern is similar to the previous pattern,except that it uses different priority static routes so traffic always flows toa primary instance unless that instance fails.

To implement this pattern, follow the same steps in the ECMP routes pattern.When creating the static routes, give the route with the next-hop pointing tothe primary instance a lower priority value (primary route). Give the instancewith the next-hop pointing to the secondary instance a higher priority value(secondary route).

The following diagram shows an implementation of the different priority routespattern:

The preceding diagram shows how an internal client accessing a service uses aprimary route with a priority value of 500 pointing to VM 1 as the next hop innormal circumstances. A second route with a priority value of 1,000 is availablepointing to VM 2, the secondary VM, as the next hop.

If the service on the primary VM becomes unresponsive, autohealing tries torecreate the instance. Once autohealing deletes the instance, and before the newinstance it creates comes up, the primary route, with the primary instance as anext hop, becomes inactive. The pattern then uses the route with the secondaryinstance as a next hop. Once the new primary instance comes up, the primaryroute becomes active again and all traffic flows to the primary instance.

Like the previous pattern, the different priority route pattern requires yourservice to expose health checks using supported protocols so autohealing canreplace unresponsive VMs automatically.

You can find a sample implementation of this pattern using Terraform in theGitHub repository that accompanies this document.

Using a heartbeat mechanism to switch a route's next hop

If your application implements a heartbeat mechanism, like Keepalived, tomonitor application responsiveness, you can apply the heartbeat mechanismpattern to change the next hop of the static route. In this case, you only use asingle static route with the next-hop pointing to the primary VM instance. Onfailover, the heartbeat mechanism points the next hop of the route to thesecondary VM.

The following diagram shows an implementation of the heartbeat mechanism toswitch a route's next hop pattern:

The preceding diagram shows how an internal client accesses a service using aroute with the next hop pointing to the primary VM. The primary VM exchangesheartbeat information with the secondary VM through Keepalived. On failover,Keepalived calls a Cloud Run function that uses API calls to point thenext hop at the secondary VM.

The nodes use the chosen heartbeat mechanism to exchange information with eachother about the status of the service. Each VM node checks its own status andcommunicates it to the remote VM node. Depending on the status of the local VMnode and the status received by the remote node, one VM node is elected as theprimary node and one VM node is elected as the backup node. Once a node becomesprimary, it points the next hop of the route for the floating IP address toitself. If you use Keepalived, you can invoke a script using thenotify_masterconfiguration variable that replaces the static route using anAPI call or theGoogle Cloud CLI.

The heartbeat mechanism to switch a route's next-hop pattern doesn't require theVMs to be part of an instance group. If you want the VMs to be automaticallyreplaced on failure, you can put them in an autohealing instance group. You canalso manually repair and recreate unresponsive VMs.

Invoking the following procedure on failover ensures that failover time isminimized because traffic fails over after a single API call is completed inStep 1:

1. Create a new static route with the floating IP address as the destination andthe new primary instance as the next hop. The new route should have a differentroute name and a lower route priority (400, for example) than the originalroute.
2. Delete the original route to the old primary VM.
3. Create a route with the same name and priority as the route that you justdeleted. Point it at the new primary VM as the next hop.
4. Delete the new static route you created. You don't need it to ensuretraffic flows to the new primary VM.

Since the original route is replaced, only one route should be active at a timeeven when there is a split network.

Using the heartbeat mechanism to switch the route priority pattern instead ofthe other route-based patterns can reduce failover time. You don't have todelete and replace VMs through autohealing for failover. It also gives you morecontrol over when to fail back to the original primary server after it becomesresponsive again.

One disadvantage of the pattern is that you have to manage the heartbeatmechanism yourself. Managing the mechanism can lead to more complexity. Anotherdisadvantage is that you have to give privileges to change the global routingtable to either the VMs running the heartbeat process or to a serverlessfunction called from the heartbeat process. Changing the global routing table toa serverless function is more secure as it can reduce the scope of theprivileges given to the VMs. However, this approach is more complex to implement.

For a full sample implementation of this pattern with Keepalived, see theexample deployment with Terraform on GitHub.

Pattern using autohealing

Depending on recovery-time requirements, migrating to a single VM instancemight be a feasible option when using Compute Engine. This option istrue even if multiple servers using a floating IP address were used on-premises.The reason why this pattern can be used sometimes despite the number of VMsbeing reduced is that you can create a new Compute Engine instance inseconds or minutes, while on-premises failures typically require hours or evendays to fix.

Using an autohealing single instance

Using this pattern you rely on the autohealing mechanism in a VM instance groupto automatically replace a faulty VM instance. The application exposes a healthcheck and when the application is unhealthy, autohealing automatically replacesthe VM.

The following diagram shows an implementation of the autohealing single instancepattern:

The preceding diagram shows how an internal client connects directly to aCompute Engine instance placed in a managed instance group with a sizeof 1 and with autohealing turned on.

Compared with patterns using load balancing, the autohealing single instancepattern has the following advantages:

• Traffic distribution: There is only one instance, so the instancealways receives all traffic.
• Ease of use: Because there is only one instance, this pattern is theleast complicated to implement.
• Cost savings: Using a single VM instance instead of two can cut thecost of the implementation in half.

However, the pattern has the following disadvantages:

• Failover time: This process is much slower thanload-balancing-based patterns. After the health checks detect a machinefailure, deleting and recreating the failed instance takes at least aminute, but often takes more time. This pattern isn't common in productionenvironments. However, the failover time might be good enough for someinternal or experimental services
• Reaction to zone failures: A managed instance group with a size of 1doesn't survive a zone failure. To react to zone failures, consider addingaCloud Monitoring alert when the service fails, and create an instance group in another zoneupon a zone failure. Because you can't use the same IP address in thiscase, use aCloud DNS private zone to address the VM and switch the DNS name to the new IP address.

You can find a sample implementation of this pattern using Terraform in theGitHub repository.

What's next

• Check out the deployment templates for this document on GitHub.
• Learn about internal passthrough Network Load Balancers.
• Learn about failover options for internal passthrough Network Load Balancers.
• Learn about routes in Compute Engine.
• Review the SQL Server Always On Availability Group solution.
• Learn about running Windows Server Failover Clustering.
• Learn about building a Microsoft SQL Server Always On Availability Group on Compute Engine.
• Explore reference architectures, diagrams, and best practices about Google Cloud.Take a look at ourCloud Architecture Center.