Amanaged instance group (MIG)that spreads its VMs across multiple zones in aregion is also known as aregional MIG.A MIG that is confined to a single zone is also known as azonal MIG.

You can use a regional MIGto increase the resilience of your MIG-based workload. Spreading your workloadacross multiple zones in a region helps protect you from extreme caseswhere all instances in a single zone fail.

This document contains conceptual information about regional MIGs:

• Why to choose a regional MIG instead of a zonal MIG
• Regional configuration options
• Behavior differences from zonal MIGs
• How to increase availability by overprovisioning

To learn how to create a regional MIG, seeCreating a MIG in multiple zones.

Why choose regional managed instance groups?

Google recommends regional MIGs over zonal MIGs for the following reasons:

• You can use regional MIGs to manage up to 2,000 instances, twice as many aszonal MIGs. If you need more, you can furtherincrease the size limit of a regional MIG to4,000 instances.
• You can use regional MIGs to spread your application load across multiplezones, rather than confining your application to a single zone or managingmultiple zonal MIGs across different zones.

Using multiple zones protects against zonal failures and unforeseen scenarioswhere an entire group of instances in a single zonemalfunctions. If that happens, your application can continue serving trafficfrom instances running in another zone in the same region.

In the case of a zonal failure, or if a group of instances in a zone stopsresponding, a regional MIG continues supporting your instances as follows:

• The number of instances that are part of the regional MIGin the remaining zones continue to serve traffic. No new instances areadded and no instances are redistributed (unless you set upautoscaling).

• After the failed zone has recovered, the MIG starts servingtraffic again from that zone.

When designing for robust and scalable applications, use regional MIGs.

Additional configuration options for regional MIGs

Creating a regional MIG is similar tocreating a zonal MIG,except that you have additional options:

• You canselect which zones within a region to createVMs in.
• You can choose atarget distribution shape todetermine how to distribute instances across selected zones.
• You can choose to disable or re-enableproactive instance redistribution, whichattempts to evenly spread the group's VMs across selected zones.

These options are described in the following sections.

Zone selection

By default, a regional MIG distributes itsmanaged instancesevenly across three zones. For various reasons, you might want to selectspecific zones for your application. For example, if you require GPUs for yourinstances, you might only selectzones that support GPUs, or you mighthave existing persistent disks orreservations that are onlyavailable in certain zones.

If you want to choose the number of zones or choose the specific zones thegroup runs in, you must do that when you first create the group.After you choose specific zones during creation, you can't change or update thezones later.

If you want your MIG to automatically use zones that support the hardware thatyou specify in yourMIG's configuration, you can set the MIG's targetdistribution shape toBALANCED,ANY, orANY_SINGLE_ZONE and select allzones in a region. The MIG automatically checks for resource availability andschedules instances only in zones that have the resources.For more information, seeTarget distribution shape.

• To select more than three zones within a region, you must explicitly specifythe individual zones. For example, to select all four zones within a region,you must provide all four zones explicitly in your request. If you don't,Compute Engine selects three zones by default.

• To select two or fewer zones in a region, you must explicitly specify theindividual zones. Even if the region only contains two zones, you must stillexplicitly specify the zones in your request.

Google regularly expands its infrastructure by making specialized hardwareavailable in more zones. A regional MIG periodically checks hardwareavailability and automatically starts scheduling instances in zones whichsupport required machines. If for any reason you don't want to run yourinstances in some zones, don't select those zones when creating your group.

To learn how to create a regional MIG and select zones, seeCreating a regional MIG.

Target distribution shape

By default, a regional MIG distributes itsmanaged instancesevenly across selected zones. But if you need hardware that is not available inall zones, or if you need to prioritize the use of zonalreservations,you might prefer a different distribution.

To configure how your regional MIG distributes its instances across selectedzones within a region,set the MIG's target distribution shape.The following options are available:

• EVEN (default): the group creates and deletes VMs to achieve and maintain the same number of VMs across the selected zones. In anEVEN distribution, the number of VMs does not differ by more than 1 between any two zones. Recommended for highly available serving workloads.
• BALANCED: the group prioritizes creation of VMs in zones where resources are available, while distributing VMs as evenly as possible across selected zones to minimize the impact of zonal failure. Recommended for highly available serving or batch workloads.
• ANY: the group picks zones for creating VM instances to fulfill the requested number of VMs within present resource constraints and to maximize utilization of unused zonal reservations. Recommended for batch workloads that do not require high availability.
• ANY SINGLE ZONE: the group creates all VM instances within a single zone. The zone is chosen based on hardware support, current resource and quota availability, and matching reservations. Recommended in combination with a compact instance placement policy for workloads that require extensive communication between VMs.

When you create your MIG, if you set its shape toBALANCED,ANY, orANY_SINGLE_ZONE, you don't need to manually verify which zones support thehardware that you specify in theMIG's configuration. You can select allzones in a region and, with its shape set toBALANCED,ANY, orANY_SINGLE_ZONE, your regional MIG checks resourceavailability for you and schedules instances only in zones that have theresources.

Choose an option based on your workload requirements and which MIG capabilitiesyou need. For more information, see thecomparison tableanduse cases.

To learn how to configure the target shape for a new or existing MIG, seeSetting a policy for distributing instances across zones.

Proactive instance redistribution

By default, a regional MIG attempts to maintain an evendistribution of instances across zones in the region to maximize theavailability of your application in the event of a zone-level failure.

If youdeleteorabandoninstances from your group, causing uneven distribution across zones, thegroup proactively redistributes instances to reestablish an even distribution.

To reestablish an even distribution across zones, the group deletes instances inzones with more instances, and adds instances to zones with fewer instances. The groupautomatically picks which instances to delete.

For example, suppose you have a regional MIG with 12 instancesspread across 3 zones:a,b, andc. If you delete 3 managed instances inc, the group attempts to rebalance so that the instances are again evenlydistributed across the zones. In this case, the group deletes 2 instances (onefroma and one fromb) and creates 2 instances in zonec, so that eachzone has 3 instances and even distribution is achieved. There is no way toselectively determine which instances are deleted. The group temporarily losescapacity while the new instances start up.

To prevent automatic redistribution of your instances, you canturn off proactive instance redistribution.

Turning off proactive instance redistribution is useful when you need to:

• Delete or abandon instances from the group without affecting other runninginstances. For example, you can delete a batch worker instance after jobcompletion without affecting other workers.
• Protect instances with stateful workloads from undesirable automatic deletiondue to proactive redistribution.
• Set the MIG'starget distribution shape toBALANCED orANY_SINGLE_ZONE

If you turn off proactive instance redistribution, a MIG doesnot proactively add or remove instances to achieve balance but stillopportunistically converges toward balance during resize operations, treatingeach resize operation as an opportunity to balance the group. For example, whenscaling in, the group automatically uses the rescaling as an opportunity toremove instances from bigger zones; when scaling out, the group uses theopportunity to add instances to smaller zones.

Behavior differences from zonal MIGs

The main difference between a zonal MIG and a regional MIG is that a regionalMIG can use more than one zone.

Because a regional MIG'smanaged instancesare distributed across zones within a region, the following MIG features behavea bit differently.

• Autoscaling
• Automatic updates

Autoscaling a regional MIG

Compute Engine offersautoscaling forMIGs, which allows your groups to automatically add VMs (scale out) orremove VMs (scale in) based on increases or decreases in load.

If you enable autoscaling for a regional MIG, then the feature behaves asfollows:

• The autoscaler distributes VMs across the zones based on the targetdistribution shape that you set.

• The autoscaler is aware of the resource availabilityacross zones. The autoscaler proactively creates VMs only in zones that haveenough quota and capacity for VMs as specified in theMIG's configuration. This behavior mightcause an uneven distribution of VMs in the case ofEVEN target distributionshape.

• If a VM creation fails due to lack of capacity in a zone, then the MIGcreates the VM in a zone where capacity is available.

Updating a regional MIG

You can't change or update the zones for a regional MIG after the group iscreated. But you canset the group's target distribution shapeto prioritize the use of different zones—for example, if you have reservedresources or need hardware that is not available in all zones.

If you want to apply a new template to a regional MIG, seeUpdating a regional MIG.

If you want to add or remove instances in a MIG, the process is similar forregional and zonal MIGs. SeeAdd and remove VMs in a MIG.

If you're interested in configuring stateful disks or stateful metadata in aMIG, seeConfiguring stateful MIGs.

How to increase availability by overprovisioning

A variety of events might cause one or more instances to become unavailable, andyou can help mitigate this issue by using multiple Google Cloudservices:

• Use a regional MIG with anEVEN orBALANCEDtarget distribution shape to distribute yourapplication across multiple zones.
• Use application-basedautohealingto recreate instances with failed applications.
• Useload balancingto automatically direct user traffic away from unavailable instances.

However, even if you use these services, your users might still experienceissues if too many of your instances are simultaneously unavailable.

To be prepared for the extreme case where one zone fails or an entire group ofinstances stops responding, Google strongly recommends overprovisioning yourMIG. Depending on your application needs, overprovisioning your groupprevents your system from failing entirely if a zone or group of instancesbecomes unresponsive.

Google makes recommendations for overprovisioning with the priority of keepingyour application available for your users. These recommendationsinclude provisioning and paying for more instances than your applicationmight need on a day-to-day basis. Base your overprovisioning decisions onapplication needs and cost limitations.

You can set your MIG's size whencreating it,and you canadd or removeinstances after you've created it.

You can configure anautoscaler to automatically add and removeinstances in the group based on the load.

Estimating the recommended group size

We recommend that you provision enough instances sothat, if all of the instances in any one zone become unavailable, your remaininginstances would still meet the minimum number of instances that you require.

Note:The following recommendations for group size assume that yourregional MIG usesproactive instance redistribution, whichis enabled by default.

If youdisable proactive instance redistribution,the instances in your group might not be evenly distributed across zones. Incase of a zonal failure, your group might not have sufficient capacity inremaining zones to handle failover traffic.

Use the following table to determine the minimum recommended size for yourgroup:

Provisioning a regional MIG in three or more zones

When you create a regional MIG in a region with at leastthree zones, Google recommends overprovisioning your group by at least50%. By default, a regional MIG creates instances in threezones. Having instances in three zones already helps you preserve at least2/3of your serving capacity, and if a single zone fails, the other two zones inthe region can continue to serve traffic without interruption. Byoverprovisioning to 150%, you can ensure that if 1/3 of the capacity is lost,100% of traffic is supported by the remaining zones.

For example, if you need 20 instances in your MIG acrossthree zones, we recommend, at a minimum, an additional 50% of instances. In thiscase, 50% of 20 is 10 more instances, for a total of 30 instances in thegroup. If you create a regional MIG with a size of30, the group distributes your VMs across the three zones, like so:

If any single zone fails, you still have 20 instancesserving traffic.

Provisioning a regional MIG in two zones

To provision your instances in two zones instead of three, Googlerecommends doubling the number of instances. For example, if you need 20 instances for yourservice, distributed across two zones, we recommend that you configurea regional MIG with 40 instances, so that each zone has 20instances. If a single zone fails, you still have 20 instancesserving traffic.

If the number of instances in your group is not equally divisible across twozones, Compute Engine evenly divides the group of VMsand randomly puts the remaining instances in one of the zones.

Provisioning a regional MIG in one zone

You can create a regional MIG with just one zone.This is similar to creating azonal MIG.

Creating a single-zone regional MIG is not recommendedbecause it offers the minimum guarantee for highly available applications. Ifthe zone fails, your entire MIG is unavailable,potentially disrupting your users.

What's next

• Create a regional MIG
• Learn how to buildscalable and resilient web applications.
• Learn aboutdisaster recovery on Google Cloud Platform.