Study Guide: Understanding MIGs
Managed Instance Groups (MIGs) are a foundational Compute Engine feature that allows you to manage a collection of identical Virtual Machine (VM) instances as a single entity. Whether you are running a high-traffic web server or a batch processing job, MIGs provide the automation necessary to maintain availability and scale dynamically.
The “Restaurant Kitchen” Analogy
Imagine a busy restaurant kitchen. A VM Instance is a single chef. If you have only one chef and they get sick (VM failure), the kitchen stops. If 100 customers arrive at once, one chef can’t keep up (Scaling issue).
- The Managed Instance Group is the Kitchen Manager.
- Instance Template: The “Chef Job Description” (What skills/tools they need).
- Autohealing: If a chef gets sick, the manager immediately hires an identical replacement.
- Autoscaling: If the dining room fills up, the manager hires 5 more chefs. When the rush ends, the manager lets them go to save money.
Core Concepts & Deep Dive
1. Reliability (Autohealing)
MIGs use Health Checks to monitor instances. If an instance stops responding or its application fails, the MIG automatically recreates that instance. This ensures your application is “self-healing.”
2. Scalability (Autoscaling)
MIGs can automatically add or remove instances based on load metrics such as CPU utilization, Cloud Monitoring metrics, or Load Balancing capacity. This ensures you only pay for what you need while maintaining performance.
3. Operational Excellence (Updates)
When you need to update your software, you don’t update VMs individually. You create a new Instance Template and apply a Rolling Update. The MIG replaces instances one by one (or in batches) to ensure zero downtime.
MIG vs. Unmanaged Instance Groups
| Feature | Managed Instance Group (MIG) | Unmanaged Instance Group |
|---|---|---|
| Instance Consistency | Identical (based on template) | Heterogeneous (different types) |
| Autoscaling | Yes | No |
| Autohealing | Yes | No |
| Use Case | Stateless apps, web servers, batch processing | Legacy apps with unique configurations |
Decision Matrix: Choosing Your Strategy
If the requirement is… Then use…
- High Availability across a whole region: Regional MIG (spreads VMs across multiple zones).
- Lowest possible latency between VMs: Zonal MIG (all VMs in one zone).
- Updating software with zero downtime: Rolling Update with a Max Surge > 0.
- Preserving data on specific disks: Stateful MIG (preserves disk state on restart).
Exam Tips: ACE Golden Nuggets
- Templates are Immutable: You cannot “edit” an Instance Template. To change a machine type or image, you must create a NEW template and update the MIG.
- Regional vs. Zonal: For the exam, always prefer Regional MIGs for production workloads to protect against a single zone failure.
- Health Checks: Distinguish between a “Liveness” check (is the VM up?) and an “Application” check (is the web server actually returning 200 OK?).
- The “Delete” Trap: If you manually delete a VM that is part of a MIG, the MIG will think it failed and immediately recreate it. To scale down, you must change the MIG size or Autoscaler settings.
Architecture Visualized
Key GCP Services
Compute Engine: The underlying VMs.
Cloud Load Balancing: Distributes traffic to the MIG.
IAM: Controls who can update templates.
Common Pitfalls
Using Local SSDs with MIGs (data is lost on recreate).
Setting Cool-down periods too short (leads to flapping).
Forgetting to set a Target CPU for autoscaling.
Quick Patterns
Web Tier: Stateless MIG + External HTTP(S) LB.
Batch Processing: MIG + Preemptible VMs to save up to 80% cost.
Stateful: MIG + Persistent Disk preservation for DBs.