Managed Instance Groups and Autoscaling in GCP

Managed Instance Groups and Autoscaling in GCP

You launch a service on GCP on a dozen virtual machines. Load spikes force you to keep reserve capacity, and manually creating instances eats up hours. Managed Instance Groups (MIG) solve this: a pool of identical VMs that GCP automatically creates, recreates on failures, and scales based on metrics. We use MIG in 80% of projects instead of Kubernetes when cluster overhead isn't justified. Our experience — over 50 production schemas, budget savings up to 40% compared to manual management. According to Managed Instance Groups documentation, MIG supports autoscaling by CPU, load balancer traffic, and custom metrics, allowing precise instance count adjustment to real load without overpaying. This approach is especially effective for stateless applications with uneven load, e.g., image processors or web servers behind Cloud Load Balancer. In this article, I'll cover how to set up MIG with CPU-based and Pub/Sub-based autoscaling, enable auto-healing, and perform rolling updates without downtime. We'll also cover stateful MIG for workers with local data.

Instance Template — the Foundation

MIG won't work without an Instance Template. It's a snapshot of VM configuration: machine type, disk image, network, service account, startup script. Below is a typical Terraform template:

resource "google_compute_instance_template" "app" {
  name_prefix = "app-template-"
  machine_type = "n2-standard-4"

  disk {
    source_image = "projects/debian-cloud/global/images/family/debian-12"
    auto_delete  = true
    boot         = true
    disk_size_gb = 50
    disk_type    = "pd-ssd"
  }

  network_interface {
    network    = google_compute_network.main.id
    subnetwork = google_compute_subnetwork.app.id
  }

  service_account {
    email  = google_compute_service_account.app.email
    scopes = ["cloud-platform"]
  }

  metadata = {
    startup-script = file("scripts/startup.sh")
  }

  lifecycle {
    create_before_destroy = true
  }
}

create_before_destroy = true is mandatory — on template update, Terraform first creates the new one, then deletes the old, otherwise MIG briefly loses its template.

How to Set Up Autoscaling for Pub/Sub Workers?

If your worker processes messages from Pub/Sub, use an autoscaler with the metric pubsub.googleapis.com/subscription/num_undelivered_messages. Example configuration:

resource "google_compute_region_instance_group_manager" "app" {
  name = "app-mig"
  region = "us-central1"
  base_instance_name = "app"
  version {
    instance_template = google_compute_instance_template.app.id
  }
  target_size = 2
  auto_healing_policies {
    health_check = google_compute_health_check.app.id
    initial_delay_sec = 120
  }
  update_policy {
    type = "PROACTIVE"
    minimal_action = "REPLACE"
    max_surge_fixed = 3
    max_unavailable_fixed = 0
    replacement_method = "SUBSTITUTE"
  }
}

resource "google_compute_region_autoscaler" "app" {
  name = "app-autoscaler"
  region = "us-central1"
  target = google_compute_region_instance_group_manager.app.id
  autoscaling_policy {
    min_replicas = 2
    max_replicas = 20
    cooldown_period = 90
    cpu_utilization {
      target = 0.65
    }
    metric {
      name = "pubsub.googleapis.com/subscription/num_undelivered_messages"
      target = 100
      type = "GAUGE"
    }
  }
}

What Autoscaling Metrics Does MIG Support?

Why Choose MIG Over Kubernetes?

Compare the two approaches:

For stateless workers, rendering, ML inference, and traditional web applications, MIG wins in simplicity and cost by 2–3 times.

What Pitfalls Are Common?

• initial_delay_sec too low. Application starts in 90 seconds, health check configured with delay 30s — MIG starts replacing "unhealthy" instances before they finish booting. You get an infinite replacement loop. Rule: initial_delay_sec should have a 1.5x buffer over actual startup time.
• Canary update via versions. MIG supports two templates simultaneously — handy canary without Kubernetes. Roll to 2 out of 10 instances, watch metrics, expand.
• Stateful MIG for workers with local disk. If the worker needs a persistent disk that persists on recreation, always specify delete_rule = "NEVER". Otherwise, the disk is deleted with the instance during auto-healing.

When Is Stateful MIG Preferred Over Stateless?

Stateful MIG preserves persistent disks when instances are recreated. It is needed for workers with local data, e.g., caching services or databases. Specify stateful_disk with delete_rule = "NEVER" in Terraform configuration.

stateful_disk { device_name = "data-disk" delete_rule = "NEVER" } 

Without this rule, the disk is deleted with the instance during auto-healing — you get data loss.

Integration with Load Balancer

MIG connects to the Load Balancer's Backend Service via named port:

resource "google_compute_region_instance_group_manager" "app" {
  # ...
  named_port {
    name = "http"
    port = 8080
  }
}

Health checks for LB and for auto-healing can differ — LB-check looks at /ready, auto-healing check at /live. This is important for proper graceful shutdown.

What's Included in Turnkey MIG Setup

• Audit of current deployment and monitoring scheme
• Design: regional vs zonal MIG, update policy, autoscaling metrics
• Implementation in Terraform using modules
• Health checks and auto-healing setup
• Rolling update and canary deployment testing on staging
• Cloud Monitoring and alert integration
• Documentation and RBAC roles transfer
• Team training (1 hour)

We guarantee stable operation: if something goes wrong, we fix it free of charge within 2 weeks after deployment. Our engineers are GCP certified and have experience with over 50 successful projects. Contact us for a proper MIG configuration consultation.

Process

1. Analysis — review current infrastructure, load, budget
2. Design — choose MIG type, metrics, update policy
3. Implementation — write Terraform configs, test on staging
4. Test — verify auto-scaling, rolling update, health checks
5. Deploy — apply to production, set up monitoring

Timeline: 2–3 days for a standard scheme. Longer if stateful configuration or existing LB integration is needed.

Contact us for an infrastructure audit — we'll assess the project in one day. Get turnkey MIG setup and achieve stable autoscaling without surprises.