Replacing a VM is not the same as accepting its application
A managed instance group maintains virtual machines from a defined configuration. During an update, the platform may create replacements or take existing instances out of service according to its update policy. A running VM can still have an application that is initializing, misconfigured or unable to reach a dependency.
Google documents maximum surge and maximum unavailable settings for automated updates. Surge requires enough quota and resources for extra instances; unavailable capacity can include instances unavailable for reasons other than the update. Review these settings against actual service capacity instead of copying a percentage from an unrelated fleet.
Prepare a replacement contract
- Record the accepted instance template, application artifact, required dependencies and operational owner. Keep a recoverable reference to the previous accepted configuration.
- Measure startup and readiness under representative conditions. Decide how much capacity the service must retain while one or more replacements initialize.
- Review regional or zonal placement, quotas and update policy. Rehearse a small candidate group and an intentionally failed startup before approving a broad rollout.
Do not store irreplaceable application data on a disposable instance without an explicit state and recovery design. Stateful workloads require additional planning beyond a stateless rolling-update checklist.
Illustrative incident: replacements cannot use their database
A new template changes runtime identity. Replacement VMs start, but the application cannot establish its database connection. Existing instances still serve customers. This is an illustrative scenario. Increasing update speed would remove useful working capacity before the candidate configuration is accepted.
Observe both update state and application evidence
Compare the intended template with the configuration actually applied to each instance. Review creation failures, startup logs, application readiness and customer request behavior. Check whether unrelated unhealthy instances are already consuming the availability budget.
| Observation | Evidence | Decision |
|---|---|---|
| Extra instances cannot be created | Quota and resource-availability result | Capacity or rollout-plan review |
| VM runs, application remains unready | Startup and dependency evidence | Candidate configuration investigation |
| Working capacity falls unexpectedly | Existing failures plus update state | Protect the availability budget |
| Candidate passes, rollout does not advance | Actual update policy and instance state | Update-policy investigation |
Keep a timeline of the first candidate's startup before changing the entire group's policy. A successful boot alone should not authorize removing every old application instance.
Correct and rehearse the candidate first
For the illustrative identity fault, review the candidate's intended database access with the application and identity owners. Preserve the previous accepted group configuration and avoid deleting working instances as a troubleshooting step. Apply the demonstrated correction to a small candidate set and verify a real user operation.
Observe readiness and request behavior through replacement, not only after the group stabilizes. Rehearse reversal to the previous configuration and record what it does to new and existing instances. Update-policy settings reduce particular rollout risks; they do not establish a universal zero-downtime guarantee.
Reliability objectives and the rollout SOP
Measure successful user requests and available application capacity during the change. An illustrative internal release gate could require a candidate to pass a defined observation window before expansion, with a stop condition for error or latency regression. It is a team acceptance rule, not a provider SLA or measured customer outcome.
The SOP should retain templates, update policy, quota review, readiness evidence, approver and reversal trigger. Escalate changes to stateful resources or broad identity permissions. Review the capacity budget before each significant instance-size or replica-count change rather than assuming the previous rollout's settings remain sufficient.
Clouvenix can scope related engineering support around documented ownership, change approval and acceptance evidence.
Technical reference
Google Cloud: automatic MIG configuration updates. References reviewed 19 October 2026; confirm the configuration and supported behavior for your deployed environment.