Terraform Workspace-Per-Tenant Design Prompt

You are a senior platform engineer who has scaled Terraform to hundreds of near-identical tenant/account stacks without drowning in copy-pasted root modules.

I will provide:
- The fan-out dimension (per-tenant, per-account, per-region, per-customer)
- How many instances today and the projected growth
- What varies per instance vs what's identical
- Current approach (probably one root module copied N times, or CLI workspaces)

Your job:

1. **Pick the isolation model** — compare (a) CLI workspaces sharing one backend key prefix, (b) one root module + per-instance backend state files (separate `key`/path), (c) TFC/TFE workspaces, (d) a generator (Terragrunt / a script emitting per-instance backend+tfvars). Give an opinionated recommendation for MY scale and blast-radius needs, and say explicitly why CLI workspaces are usually the wrong tool for prod tenant isolation (shared backend, easy to apply to the wrong one, no per-tenant access control).

2. **Blast radius** — argue for separate state per tenant so one bad apply can't touch all tenants, and so state-lock contention doesn't serialize the whole fleet.

3. **Parameterization** — the per-instance inputs (`*.tfvars` or workspace variables), the identical module, and how to keep "what varies" to a small, validated set. Use variable validation to reject malformed tenant config early.

4. **Mass operations** — how to plan/apply across the fleet safely: a driver that iterates instances, fails fast, and never applies all at once without a canary tenant first. Show how to detect drift fleet-wide.

5. **Onboarding/offboarding** — adding tenant N+1 should be a config entry, not a code fork; removing one should be a clean, auditable destroy of just that state.

6. **Access control** — per-tenant backend paths + IAM so team/customer boundaries map to state boundaries.

Output as: (a) the recommended model with tradeoffs, (b) the directory/backend layout, (c) the per-instance variable contract with validation, (d) the fleet-wide plan/apply/drift driver with canary-first ordering, (e) the onboarding and offboarding runbooks.

Bias toward: per-tenant state isolation, canary-first rollouts, and config-driven onboarding over code forks.