Zero-Downtime Resource Replacement

Some changes force Terraform to replace a resource rather than update it in place, and the default order is brutal: destroy the old, then create the new. That ordering means a window where the resource does not exist — for the seconds or minutes between the destroy and the create, traffic to it fails. On a stateless side resource nobody notices; on anything serving production it is an outage.

create_before_destroy inverts the order so the replacement is live before the original goes away. For the resources that genuinely cannot replace without a gap — a regional Cloud SQL primary, a resource pinned to a globally-unique name — the answer is sequencing and orchestration, not a single lifecycle flag. Knowing which case you are in starts with reading the plan.

Why Replacement Happens

Changing a force-new attribute makes Terraform replace rather than update. A Compute Engine instance's machine_type on some configurations, a bucket's location, a resource's name — these cannot be changed in place, so the plan shows -/+, meaning destroy then create. Recognizing the -/+ marker in a plan is how you catch downtime before it ships, because the change that triggers it often looks like an innocent edit.

# Changing location forces replacement — the -/+ is the warning
  # google_storage_bucket.raw must be replaced
-/+ resource "google_storage_bucket" "raw" {
      ~ location = "US" -> "EU" # forces replacement
    }

create_before_destroy

The lifecycle block's create_before_destroy = true flips the order: Terraform stands up the new resource first and only then tears down the old. The replacement is live before the original disappears, so there is no gap. The catch is that both exist briefly, which means anything with a globally-unique name collides with itself — a GCS bucket, an instance with a fixed name — unless the name can vary, typically through name_prefix or a random suffix.

resource "google_compute_instance_template" "app" {
  name_prefix = "hatch-app-"   # varying name so old and new don't collide
  # ...
  lifecycle {
    create_before_destroy = true
  }
}

MIG Rolling Updates

A managed instance group does zero-downtime replacement natively, and this — not create_before_destroy on individual VMs — is how you reroll a Hatch compute tier. You point the MIG at a new instance template and configure update_policy: surge instances, max unavailable, a rolling strategy. The group then rolls VMs over gradually, a few at a time, with health checks gating each batch, instead of replacing the whole fleet at once.

resource "google_compute_region_instance_group_manager" "app" {
  version {
    instance_template = google_compute_instance_template.app.id
  }
  update_policy {
    type                  = "PROACTIVE"
    minimal_action        = "REPLACE"
    max_surge_fixed       = 3   # add new VMs before removing old
    max_unavailable_fixed = 0   # never drop below capacity
  }
}

Draining and Health Gating

A zero-downtime rollover is only real if the new instances are healthy before they take traffic and the old ones drain in-flight connections before they die. Load-balancer health checks gate the first half: the LB does not route to an instance until its check passes. Connection draining gates the second: an instance being torn down finishes its in-flight requests instead of dropping them. Skip either and the surge-and-replace stops being safe — the LB sends a request to a not-yet-ready instance, or kills a connection mid-response.

Resources That Cannot Replace Cleanly

Some resources have no in-place zero-downtime path at all. A regional Cloud SQL primary, a resource pinned to a fixed global name, anything with external dependents that cannot be repointed atomically — no lifecycle flag covers these. The answer is a sequenced runbook expressed as staged applies: stand up a replica, promote it, repoint the clients, retire the old primary. That is operations work you script and stage deliberately, not a hope that one flag makes the gap disappear.