Managed Instance Group (MIG)

Le Managed Instance Group (MIG) consomme un Instance Template pour créer et maintenir un groupe de VMs identiques — autohealing, autoscaling, rolling update. Équivalent GCP de l’Auto Scaling Group AWS. Existe en version zonale (google_compute_instance_group_manager) ou régionale, répartie sur plusieurs zones (google_compute_region_instance_group_manager).

Une VM isolée créée avec google_compute_instance_from_template n’a aucun autohealing — sans MIG, un crash de la VM reste un crash définitif.

---

Autohealing

Nécessite deux briques en plus du template :

• un google_compute_health_check qui teste un port/chemin applicatif
• une auto_healing_policies sur le MIG, avec un initial_delay_sec assez long pour laisser le temps au startup_script de finir avant que la VM soit jugée malsaine et recréée

---

Firewall requis pour les health checks

Les probes de health check partent des plages IP Google, pas de l’intérieur du VPC — une règle firewall ingress dédiée est indispensable, sinon le health check échoue en permanence et le MIG recrée les VMs en boucle :

Plage source	Usage
130.211.0.0/22	Health checks legacy / Load Balancer
35.191.0.0/16	Health checks

À ouvrir sur le port testé par le health check, ciblé par les mêmes tags réseau que le template.

---

Ce qui est perdu à chaque recréation

Par défaut, disque de boot et IP (interne/externe) sont recréés à chaque remplacement d’instance par le MIG — sauf configuration stateful explicite :

• stateful_disk — conserve un disque entre recréations
• IP interne/externe stateful — conserve l’adresse

---

En relation avec

• Instance Template — le modèle consommé par le MIG
• Firewall Rules — règles à ouvrir pour les health checks
• Compute Engine — les instances individuelles du groupe
• Cloud Load Balancing — cible souvent un MIG comme backend