Configuring Managed Instance Groups with Autoscaling

Overview and What You Will Learn

In this lab, you will create an Instance Template defining a VM's configuration, build a Managed Instance Group from it, configure an autoscale policy watching CPU utilization, and simulate load to watch the group actually add capacity automatically.

Why This Matters in Production

During a flash sale, an e-commerce app needs to handle a sudden spike in traffic without the engineering team manually launching new VMs at 2 AM, and without paying for that same peak capacity to sit idle for the rest of the year. A properly configured Managed Instance Group with autoscaling handles both sides of this problem automatically.

Core Principles

A Managed Instance Group (MIG) manages a group of identical VMs created from an Instance Template as a single unit - GCP's equivalent of an AWS Auto Scaling Group or Azure VM Scale Set. Instead of manually deciding when to add or remove capacity, an autoscale policy watches a metric and adjusts instance count on its own.

Detailed Step-by-Step Practical Lab

1. Create a project and enable Compute Engine:

2. Create an Instance Template defining the VM configuration:

3. Create a Managed Instance Group using that template, starting with 2 instances:

4. Confirm both instances are running:

5. Configure autoscaling based on CPU utilization, with a minimum of 2 and a maximum of 10 instances:

Note

--cool-down-period=90 gives each newly created instance 90 seconds before its metrics are factored into scaling decisions - this prevents the autoscaler from reacting to a brand-new instance's initial startup CPU spike as if it were sustained load, avoiding an unnecessary premature scale-out decision.

6. Simulate load on the instances (using a tool like stress installed via SSH) and watch the instance count grow:

7. Check the autoscaler's recent scaling decisions and reasoning:

8. Clean up:

Production Best Practices & Common Pitfalls

Common Mistake

Setting the cool-down period too short for an application with a genuinely slow startup process. If new instances take 60 seconds to become fully ready, but the cool-down period is only 30 seconds, the autoscaler may factor in misleading startup-phase metrics and make an inappropriate scaling decision.

Tip

Combine a Managed Instance Group with a health check tied to a Load Balancer's backend service, so unhealthy instances are automatically recreated - not just scaled based on load, but actively self-healed when an individual instance stops responding correctly.

• Instance Templates are immutable once created - updating a VM's configuration means creating a new template version and performing a rolling update on the Managed Instance Group, rather than editing the existing template in place.
• Regional Managed Instance Groups spread instances across multiple zones within a region automatically, providing resilience against a single zone failure - a zonal MIG, by contrast, keeps every instance in one zone, which is simpler but has no such built-in protection.

Quick Reference & Troubleshooting Commands