You can create and manage groups of virtual machine (VM) instances so that you don't have to individually control each instance in your project. Compute Engine offers two different types of instance groups: managed and unmanaged instance groups.
Managed instance groups
A managed instance group uses an instance template to create a group of identical instances. You control a managed instance group as a single entity. If you wanted to make changes to instances that are part of a managed instance group, you would make the change to the whole instance group. Because managed instance groups contain identical instances, they offer the following features:
- When your applications require additional compute resources, managed instance groups can automatically scale the number of instances in the group.
- Managed instance groups work with load balancing services to distribute traffic to all of the instances in the group.
- If an instance in the group stops, crashes, or is deleted by an action other than the instance groups commands, the managed instance group automatically recreates the instance so it can resume its processing tasks. The recreated instance uses the same name and the same instance template as the previous instance, even if the group references a different instance template.
- Managed instance groups can automatically identify and recreate unhealthy instances in a group to ensure that all of the instances are running optimally.
Types of managed instance groups
You can create two types of managed instance groups:
- A zonal managed instance group, which contains instances from the same zone.
- A regional managed instance group, which contains instances from multiple zones across the same region.
Regional managed instance groups are generally recommended over zonal managed instance groups because they allow you to spread application load across multiple zones, rather than confining your application to a single zone or having to manage multiple instance groups across different zones. This replication protects against zonal failures and unforeseen scenarios where an entire group of instances in a single zone malfunctions. If that happens, your application can continue serving traffic from instances running in another zone in the same region.
Choose zonal managed instance groups if you want to avoid the slightly higher latency incurred by cross-zone communication or if you need fine-grained control of the sizes of your groups in each zone.
Managed instance groups and the network
By default, instances in the group will be placed in the
default network and
randomly assigned IP addresses from the regional range.
Alternatively, you can restrict the IP range of the group by creating a
custom mode VPC network and
subnet that uses a smaller IP range, then specifying this subnet in the instance
template. This can simplify the creation of firewall rules.
After you create a managed instance group, the new instances start in the group as soon as the system can provision them. This process can take a significant amount of time depending on the number of instances in the group. Verify the status of instances in your managed instance group.
Unmanaged instance groups
Unmanaged instance groups are groups of dissimilar instances that you can arbitrarily add and remove from the group. Unmanaged instance groups do not offer autoscaling, rolling update support, or the use of instance templates so Google recommends creating managed instance groups whenever possible. Use unmanaged instance groups only if you need to apply load balancing to your pre-existing configurations or to groups of dissimilar instances.
If you must create a group of dissimilar instances that do not follow an instance template, see Unmanaged Instance Groups.
Instance groups and load balancing
All of the load balancing configurations available on Google Cloud Platform require that you specify instance groups or target pools that can serve traffic distributed from the load balancer.
For HTTP(S), internal, and SSL load balancing, you must assign an instance group to a backend service. A backend service is a centralized service for managing backends, which in turn manages instances that handle user requests for your load balancer. Each backend service contains one or more backends, and each backend contains one instance group. The backend service knows which instances it can use, how much traffic they can handle, and how much traffic they are currently handling. You can assign either a managed or unmanaged instance group to a backend service.
For Network load balancing, you must add individual VM instances to a target pool or assign one or more managed instance groups to a target pool, which causes the server to add all instances that are part of the instance group to the specified target pool.
For more information on different load balancing configurations, see the load balancing documentation.
Managed instance groups and autoscaling
Managed instance groups support autoscaling so you can dynamically add or remove instances from a managed instance group in response to increases or decreases in load. You enable autoscaling and choose an autoscaling policy to determine how you want to scale. Applicable autoscaling policies include scaling based on CPU utilization, load balancing capacity, Stackdriver monitoring metrics, or by a queue-based workload like Google Cloud Pub/Sub.
Because autoscaling requires adding and removing instances from a group, you can only use autoscaling with managed instance groups so the autoscaler can maintain identical instances. Autoscaling does not work on unmanaged instance groups, which can contain heterogeneous instances.
For more information, read Autoscaling Groups of Instances.