# Ensure Managed Instance Groups Span Multiple Zones for High Availability

- Source: https://support.icompaas.com/support/solutions/articles/a_1788888299348483-ensure-managed-instance-groups-span-multiple-zones-for-high-availability
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [GCP Benchmarks](https://support.icompaas.com/support/solutions/62000112667) › [GCP Knowledge Bases](https://support.icompaas.com/support/solutions/folders/62000169178)
- Last updated: 2026-09-08
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

**Description**

Ensure that Managed Instance Groups (MIGs) supporting production workloads are configured as regional (multi-zone) instance groups, distributing instances across multiple zones within a region rather than being confined to a single zone.

**Rationale**

A zonal Managed Instance Group places all of its instances within a single zone, so a zonal outage or maintenance event can simultaneously affect every instance in the group, resulting in a full service outage. A regional Managed Instance Group automatically distributes instances across multiple zones in the region, so that the loss of a single zone only affects a portion of the group's capacity, improving overall availability.

**Impact**

-   Reduces the risk of a complete service outage due to a single zonal failure
    
-   Improves overall availability and resilience of the workload
    
-   May require re-architecting an existing zonal group, since the instance group scope generally cannot be changed after creation
    

**Default Value**

Managed Instance Groups can be created as either zonal or regional; there is no single default, and the scope must be explicitly selected at creation.

**Pre-Requisites**

-   An instance template compatible with deployment across multiple zones in the target region
    
-   IAM permissions to create and manage Managed Instance Groups (e.g., Compute Instance Admin)
    

**Test Plan**

1.  Sign in to the Google Cloud Console at [https://console.cloud.google.com](https://console.cloud.google.com/).
    
2.  Select the relevant project.
    
3.  Navigate to Compute Engine > Instance groups and select the group to review.
    
4.  Open the group's Location / Details section.
    
5.  Verify that the group's Location is set to a region with instances distributed across multiple zones, rather than a single zone.
    
6.  If a production group is zonal (single-zone), follow the implementation steps.
    

**Implementation Steps**

1.  Sign in to the Google Cloud Console at [https://console.cloud.google.com](https://console.cloud.google.com/).
    
2.  Navigate to Compute Engine > Instance groups and select Create instance group.
    
3.  Choose New managed instance group and select the appropriate instance template.
    
4.  Set Location to Multiple zones and select the region and (optionally) the specific zones to include.
    
5.  Configure autoscaling, autohealing, and any load balancer attachment as required.
    
6.  Create the new regional group, verify instances are distributed across the expected zones, and migrate traffic from the old zonal group.
    
7.  Decommission the old zonal group once the migration is verified.
    

**Backout Plan**

1.  Sign in to the Google Cloud Console at [https://console.cloud.google.com](https://console.cloud.google.com/).
    
2.  Navigate to Compute Engine > Instance groups.
    
3.  Because a regional group's scope cannot be changed to zonal directly, reverting requires creating a new zonal group with the same instance template and migrating traffic back to it.
    
4.  Redirect load balancer backends or clients to the new zonal group.
    
5.  Delete the regional group once the migration is verified.
    

**Reference**

-   [https://cloud.google.com/compute/docs/instance-groups/regional-migs](https://cloud.google.com/compute/docs/instance-groups/regional-migs)

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.