IaC Governance, Multi-Account Strategy, and Migration Path Planning

You're directing an IaC governance engagement for Dina Farouk, the CIO of Nile Health Group — an 8-hospital network across Cairo and Alexandria migrating from on-premises to AWS.

The discipline skills: an IaC standards framework an 8-engineer team will adopt; a multi-account topology that encodes the regulator's audit obligation; a canonical hospital-baseline Terraform module with versioning and a staged-rollout pattern; an HL7 FHIR middleware architectural decision record; a workflow-phase MCP-connectivity matrix; an 8-hospital migration plan across four waves with rollback and stakeholder communication, two hospitals deferred behind a hardware refresh; and a governance-as-ongoing-practice handover that staffs a named platform-IaC function.

The AI-direction lesson is that IaC at the organisational summit is governance, architecture, and migration planning all at once — and AI does not see the organisation. It produces a 50-page binder when the team can adopt 10. It draws a topology that omits the regulator's audit retention. It writes a working module without versioning or staged rollout. It recommends AWS HealthLake without naming the Bahrain-region residency constraint. It generates migration plans without rollback or stakeholder communication. And it treats governance as a one-off deliverable rather than a practice with named owners. You design what AI does not.

Your Role

You own the standards framework, the multi-account-topology document, the canonical module, the architectural decision record, the MCP-connectivity matrix, the migration plan with its communication matrix, the handover brief, and the persistence-architecture pass over CLAUDE.md. Applied Terraform is intentionally small — a budget alarm, one CloudTrail-destination S3 bucket, and one demonstration apply of the canonical module against a single sandbox account. The substance is the markdown, the module HCL, and the judgment behind both.

Communication is a forwarded email chain. Dina replies during Cairo business hours in formal English with occasional Arabic — authoritative, compassionate, protective of her hospitals. She says "the patient impact is" before discussing risk, and she tests expertise. Priya Subramanian returns twice as the IaC-governance edge-ratifier, but does not propose the design. You do.

What's New

Last time at Tienda Sur in Santiago you designed the operations practice and cost-governance framework, with a persistence-architecture pass over CLAUDE.md and a team-adoption brief for a 25-engineer Slack channel.

This time IaC reaches its summit. The deliverables are organisational artefacts at multi-environment scale: 8 hospital environments inherit the standards and the canonical module, the audit obligation is a regulator's, and the migration plan sequences four production cutovers across four waves while two hospitals stay on-prem behind a hardware refresh. Communication switches from Slack back to email, and the senior colleague register flips from Marco's warm war stories to Priya's terse precision.

The hard part: a framework an 8-engineer team will not follow is documentation, not governance. A reusable module without versioning or staged rollout is a blast-radius problem — a bug in the canonical module is a bug in 8 hospitals at once. An architectural recommendation that ignores residency is wrong on the dimension that matters most. A migration plan without rollback per phase, communication per stakeholder, and a realistic-timeline-multiplier is a wish, not a plan.

Tools

• Terraform — small applied footprint (budget alarm, audit-trail bucket, demo module apply); the canonical module is substantial HCL authored as the deliverable.
• AWS Console and CLI — light. Organizations console as reference; aws ce get-cost-and-usage for the per-wave cost projection.
• AWS MCP server — the connectivity-per-phase design surface. Read-only during audit; scoped read-write only in the Phase C matrix cell (the demo apply runs through Terraform CLI, not MCP).
• CloudTrail — the audit-trail substrate. Destination bucket provisioned at sandbox scale (object-lock governance-mode, 1-day retention for teardown); the production design's seven-year retention and the cross-account trail are documented but not applied (a real Organization is out of sandbox scope).
• CLAUDE.md — extended with four new entries across the three persistence tiers; one unit decides each tier.
• scripts/verify.sh — extended with scripts/check-migration-plan-coverage.sh asserting the plan covers rollback, communication, blast radius, and timeline per wave.
• Mermaid and Markdown — every framework document and the wave-timeline diagram.

Materials

In the project zip:

• Dina's forwarded email chain (dina-forwarded-email.md) — her cover paragraph forwarding her own three-week-ago update to Dr. Hassan, the CEO. Constraints surface in the discovery exchange.
• Organisational and regulatory context (nilehealth-org-context.md) — 8 hospitals by city, network headcount, partnership structure, platform-team split.
• Per-hospital roster (hospitals-roster.csv) — current state, OS baseline, migration priority. Two Windows-Server-2012 flags signal the deferred-hospitals constraint.
• Compliance summary (nha-compliance-summary.md) — HL7 FHIR R4, seven-year audit retention, residency with the Bahrain-region exception, audit cadence.
• CLAUDE.md — engagement governance with four <!-- TODO --> markers where the new entries will land.
• Terraform starter (terraform/budget/) — wired. The audit-trail bucket and canonical module are authored from scratch under governance/ and modules/.
• Script starter (scripts/check-migration-plan-coverage.sh) — TODO-body shell alongside the verify harness from Tienda Sur.
• Empty governance/ and modules/ directories — where framework documents and canonical module will live.