If you only need to create multiple VMs, but don't want them grouped together in a MIG, see the bulk instance API.
To learn about other Compute Engine options, see Choose a Compute Engine deployment strategy for your workload.
To get started with creating a MIG, read this document to find a basic configuration that works for you.
Basic scenarios for creating a MIG
MIGs have many configuration options. See the following guides to quickly get a MIG up and running for various scenarios:
|Create a MIG with VMs in a single zone (zonal MIG)||Your VMs can be deployed to a single zone|
|Create a MIG with VMs in multiple zones in a region (regional MIG)||You want to distribute your VMs across multiple zones in a region in order to protect against zonal failure or to automatically find zones with limited resource like Spot VMs|
|Create a MIG with autoscaling||You want your MIG to automatically create VMs in the group when demand increases and delete VMs when demand drops|
|Create a MIG that uses preemptible VMs||Your workload can tolerate disruptions and you want to take advantage of the cost-savings associated with preemptible VMs|
|Create a MIG with stateful configuration||Your workload needs stateful configuration—for example, you need disks that must retain their data whenever VMs are autohealed, updated, or recreated|
MIGs have different limitations depending on which features you use. The following lists show general MIG limitations as well as additional limitations if you use regional or stateful features.
When confined to a single zone, you can create up to 1,000 VMs in a single MIG. If you need more, use one of the following options:
When updating a MIG, you can specify up to 1,000 VMs in a single request.
You cannot create a MIG with multiple subnets. Once created, you cannot change the network or subnetwork in a MIG.
Shared VPC on interfaces other than
nic0for managed instance groups is supported in gcloud CLI and the API, but not in Google Cloud console.
A MIG that is spread across multiple zones—a regional MIG—has the following limitations:
- You can create up to 2,000 VMs. If you need more, contact support.
- You must select which zones are associated with a regional MIG when you create the MIG. After you choose specific zones during creation, you cannot change or update the zones later. But you can set the MIG's target distribution shape to specify how the group distributes its managed instances across the zones that you selected.
If you set the group's target distribution shape to
BALANCED, review the target distribution shape limitations.
- If you want to autoscale a regional MIG, the following limitations apply:
If you want to use load balancing with a regional MIG, the following limitations apply:
- You cannot use the
- If you use an HTTP(S) load balancing scheme with a regional MIG, you must
- You cannot use the
A MIG with stateful configuration—a stateful MIG—has the following limitations:
- You cannot use autoscaling if your MIG has stateful configuration.
- If you want to use automated rolling updates, you must set the
- For stateful regional MIGs, you must
disable proactive redistribution
(set the redistribution type to
NONE) to prevent deletion of stateful instances by automatic cross-zone redistribution.
If you want to configure an autoscaler for your MIG, review the autoscaler specifications, too.
Additional MIG tasks
After you've created a MIG, you might want to do the following:
Learn about the group and its VMs
- View info about your MIG and its managed VM instances
- Learn what a managed instance is and how to work with managed instances
Resize the group
Add or remove VMs from the group
Change the group's VM configuration
Learn how to add stateful configuration in order to preserve disks, IP addresses, and metadata when VMs are recreated
Add MIG features
- Set up an application-based health check to automatically recreate VMs if your application does not respond as expected
- Set up a load balancer to distributes user traffic across multiple instances of your application
Try a tutorial:
- Use autohealing for highly available applications
- Use load balancing for highly available applications
- Use autoscaling for highly scalable applications
- Migrate an existing workload to a stateful managed instance group