The landing zone is the structure every migrated workload lands inside: subscriptions, network, identity, policy guardrails, logging, cost controls and recovery. It is built before the first workload moves, and that sequencing is a hard rule rather than a preference. This design covers the topology, the controls that enforce regulatory constraints technically rather than procedurally, the three-party access model created by the co-managed operating decision, and the acceptance gate that must pass before Wave 1 begins. Issued November 6, 2023.
The landing zone is the one thing on this program that cannot be retrofitted. Applications can be re-migrated, interfaces rebuilt, processes corrected. But subscription boundaries, network address space, identity architecture and policy scope are decided once and then have live production workloads sitting on top of them. Changing them afterward is not configuration — it is a second migration, performed on systems that are already serving 2,220,000 members. Everything in this document is cheap now and expensive in six months.
Table of Contents
Part I — Structure
Part II — Control
- Identity and Privileged Access Across Three Parties
- Policy Guardrails
- Logging, Monitoring and Evidence
- FinOps Foundation
Part III — Recovery and Acceptance
1. Sequencing — Why This Comes First
The Cloud Migration Strategy states the rule plainly: landing zone before any wave. It is worth recording why, because the pressure to break it will be real and will come from people acting reasonably.
| If a workload migrates first | What happens |
|---|---|
| Into an unstructured subscription | Cost cannot be attributed, policy cannot be scoped, and separating it later means moving it again |
| Before network address planning | Address ranges collide with the on-premises estate or with each other. Re-addressing a live system is an outage. |
| Before identity architecture | Access is granted ad hoc and never fully recertified. ⚠ Nobody can later answer "who can reach protected health information." |
| Before policy guardrails | Resources deploy into unapproved regions or without encryption, and remediation is a change to production |
| Before tagging is enforced | Untagged resources are never retroactively tagged. The cost baseline is lost permanently. |
The pressure to migrate something early is not unreasonable, and that is what makes it dangerous. A team is ready, the TSA meter is running, and the landing zone is "nearly done" — so one low-risk workload goes first to prove the path. It is a sound instinct and it is how the exception becomes the pattern. The rule holds because the cost of breaking it is invisible for months and then permanent: nobody notices the untagged resource until the first large invoice, and by then there are four hundred of them.
2. Management Group and Subscription Topology
ACME Health (tenant root)
├── Platform
│ ├── Connectivity — hub network, gateways, DNS, firewall
│ ├── Identity — directory services, privileged access
│ └── Management — logging, monitoring, backup vaults
├── Landing Zones
│ ├── Production — PHI — strictest policy set
│ ├── Production — non-PHI
│ └── Non-production — de-identified data only
└── Sandbox — time-limited, no connectivity, no real data
| Decision | Reasoning |
|---|---|
| PHI and non-PHI separated at management group level | ⭐ Policy, access and audit scope differ materially. Separating by data classification rather than by application means a workload's controls follow from what it holds, not from who built it. |
| Non-production carries de-identified data only | Enforced by policy and by the offshore access boundary. Test environments are where real data leaks from. |
| Sandbox is disconnected and time-limited | Engineers learning a new platform need somewhere to experiment. Denying that produces experiments in production instead. |
| Subscription per workload group, not per application | Subscription sprawl is its own governance problem; a subscription per application produces hundreds nobody can review. |
The sandbox row is the one that looks like a lapse in rigor and is the opposite. This organization has never operated Azure. Its engineers will experiment somewhere, and the only question is whether that place is disconnected and dataless or whether it is production at two in the morning. Providing a legitimate place to be wrong is a control, not a concession — and it costs a fraction of what the alternative costs once.
3. Network
| Component | Design |
|---|---|
| Topology | Hub and spoke. Hub carries shared connectivity, firewall and DNS; spokes are workload landing zones. |
| Address space | Non-overlapping ranges reserved for ACME, the acquired estate, and future growth. ⚠ Reconciled against the parent's ranges before any connectivity is established. |
| On-premises connectivity | Private circuit to ACME's data center; separate temporary circuit to Cheatham Mutual's during the TSA period, terminating at TS-05 exit |
| Egress control | All outbound traffic through the hub firewall. No direct internet egress from a workload subnet. |
| Private endpoints | Platform services reached over private endpoints rather than public addresses, so PHI never traverses the public internet |
| Bulk transfer path | ⚠ Physical transfer appliances for the historical claims estate — the circuit cannot carry it inside the window |
The address-space row is the classic carve-out trap. Cumberland Valley's network ranges were assigned by its parent, out of the parent's address plan — and ACME's were assigned independently. There is no reason for them not to collide, and every reason to assume they will. Discovering an overlap after establishing connectivity means re-addressing live systems, which is an outage on a claims platform. The reconciliation is unglamorous, takes days, and prevents a class of incident that has no cheap remedy.
4. Identity and Privileged Access Across Three Parties
The co-managed operating decision means three organizations hold access to this environment. That is a design input, not an operational detail.
| Party | Access | Control |
|---|---|---|
| ACME Health | Full administrative ownership; approval authority for all access | Owns the directory, the roles and the recertification |
| Rutherford Cloud Operations (MSP) | Operational administrative access, scoped per role | ⚠ Just-in-time elevation, time-bound, approved and logged. Standing privileged access is not granted. |
| Arrington offshore test team | Non-production only, de-identified data only | Enforced by management group boundary, not by policy document |
4.1 Controls
- Role-based access, least privilege, with roles defined against job function rather than assembled per person
- Just-in-time privileged elevation — administrative rights are requested, approved, time-boxed and logged. This applies to ACME staff and MSP staff identically.
- Quarterly recertification, owned by ACME regardless of whose staff hold the access
- Break-glass accounts — two, held by ACME only, monitored, alerting on any use
- ⚠ MSP personnel are named individuals, not a shared service account. Personnel changes at the vendor are access events.
The provision worth defending: the MSP does not hold standing administrative access, and neither does anyone else. It is operationally simpler to grant a managed service provider permanent administrative rights — that is what they are being paid to use. It is also how an organization ends up unable to answer, during a privacy investigation, who could reach protected health information on a given date. Just-in-time elevation converts a permanent capability into a logged, approved, time-bounded event, and the log is the thing a regulator asks for. The friction is the feature.
5. Policy Guardrails
Regulatory constraints are enforced by policy engine, not by documentation. A rule that lives in a standards document is followed by people who read it. A rule that lives in a deny policy is followed by everyone, including the engineer at midnight who has never read the document and the automation that nobody remembered.
| Ref | Policy | Effect | Basis |
|---|---|---|---|
| PL-01 | Deploy only to United States regions | Deny | ⭐ Tennessee DOI conditions and ACME privacy policy on member-level data location. The single most important policy in this list. |
| PL-02 | Encryption at rest required on all storage and databases | Deny | HIPAA safeguards; regulator-grade evidence |
| PL-03 | Public network access disabled on platform services | Deny | PHI must not be reachable from the public internet |
| PL-04 | Required tags present at deployment | Deny | ⚠ Enforced at deploy time. Untagged resources are never tagged later. |
| PL-05 | Diagnostic logging enabled to the central workspace | Deploy | Auto-remediated rather than blocked — missing logs should not stop a deployment, but must not persist |
| PL-06 | Backup configured per service tier | Deploy | Recovery is a default, not a decision each team makes |
| PL-07 | Approved resource types only | Deny | A first-time organization should not be operating services nobody has been trained on |
| PL-08 | Non-production may not connect to production data paths | Deny | The de-identified boundary made structural |
| PL-09 | Exceptions time-limited and registered | Audit | ⚠ Exceptions expire. A permanent exception is a policy that was wrong. |
PL-01 deserves particular attention because it is where a documented constraint becomes an enforced one. The DOI condition on member-level data location is a legal obligation that would otherwise be honored by everyone remembering it — including under deadline pressure, including by a contractor who joined last week, including by an infrastructure-as-code template copied from a public example that defaults to a European region. A deny policy makes the violation impossible rather than unlikely, and it is also the evidence that satisfies the regulator asking how the condition is enforced.
6. Logging, Monitoring and Evidence
| Element | Provision |
|---|---|
| Central log workspace | Platform Management subscription; workload subscriptions have write access only |
| Retention | Aligned to record-retention obligations, not to operational convenience |
| Immutability | ⚠ Audit logs write-once. Administrative access must not include the ability to erase evidence of administrative access. |
| Access to PHI logged | Every read of member-level data attributable to a named identity |
| Monitoring | MSP operates alerting during the early step-down phases; ACME owns thresholds and incident declaration |
| Evidence pack | Standing quarterly export of policy compliance, access recertification and restore-test results, retained for audit |
The immutability row is a small provision with an outsized purpose. If administrative access includes the ability to delete audit logs, then the audit trail proves nothing about the actions of the people most able to cause harm. Write-once logging is what makes the rest of the access model evidentiary rather than merely descriptive — and it costs almost nothing to set up before workloads arrive.
7. FinOps Foundation
Not cost optimization — the foundation that makes optimization possible later. Optimization needs consumption history to optimize against, and month one has none.
| Element | Provision |
|---|---|
| Mandatory tags | cost-center · workstream · environment · data-classification · owner |
| Enforcement | PL-04, deny at deployment. ⚠ The only point at which tagging is achievable. |
| Showback | Monthly consumption attributed to workstream and cost center from the first invoice |
| Budgets and alerts | Per subscription, with alerting to the named owner before the invoice arrives |
| Reservation posture | ⚠ Deferred until consumption is stable. Reserving capacity for a workload profile you have not yet observed is a commitment to the wrong shape. |
| Ownership | R. Ilesanmi, FinOps Analyst |
Two of these rows point in opposite directions on purpose. Tagging must be enforced from the first deployment, because retroactive tagging never happens — nobody goes back through four hundred resources to attribute costs to a workstream that has since been reorganized. Reservations must wait, because committing to a capacity profile before observing real consumption locks in a guess. The foundation is urgent; the optimization is not, and a first-time organization that inverts those two ends up with precise cost attribution for the wrong reservations, or cheap reservations it cannot attribute to anyone.
8. Backup and Disaster Recovery
Recovery objectives are set by business consequence and are a property of the service tier, not a decision each team makes at deployment. Policy PL-06 configures backup automatically to the tier the workload declares.
| Tier | RTO | RPO | Workloads |
|---|---|---|---|
| Tier 0 — critical | 4 h | 15 min | Claims adjudication, eligibility 270/271, payroll |
| Tier 1 — essential | 24 h | 1 h | Enrollment, provider data, member portal, ID cards, integration layer |
| Tier 2 — important | 72 h | 24 h | Care management, utilization management, enterprise data warehouse |
| Tier 3 — deferrable | 120 h | 24 h | Document management, internal reporting tools |
8.1 The enterprise data warehouse — a new build with no inherited recovery
Every rehosted workload arrives with an existing backup regime, however imperfect — a tested runbook, an audit history, someone who has restored it before. The data warehouse arrives with none of that, because it never existed. The Replace decision in the Application Disposition Matrix created a system, and therefore created a recovery capability that has to be built rather than inherited. In a regulated health plan operating a cloud platform for the first time, a new system without a demonstrated recovery position does not pass a go-live gate and does not survive a compliance review.
| Gate condition | Implementation in this landing zone |
|---|---|
| Documented RTO and RPO agreed with the business owner | Tier 2 — 72 hours / 24 hours. Recorded in the Quality Plan. |
| Geo-redundant backup to the Azure paired region | Backup vault configured with geo-redundant storage. ⚠ Paired region must itself be a United States region — verified against PL-01. |
| Immutable / soft-delete protection | Vault soft-delete and immutability enabled, against ransomware and accidental deletion alike |
| Business Associate Agreement confirmed to cover backup and secondary region | Scope confirmation, not existence. See the BAA Register. |
| Full restore tested end to end, evidence retained | ⭐ Annual, and once before go-live. The only condition that proves anything. |
| DR runbook with named roles and a named owner | H. Sandifer, Manager Platform Engineering. MSP executes; ACME owns. |
| Recovery obligations in the risk register with a residual rating | Carried as a tracked risk rather than an assumed control |
For a warehouse, availability and durability are different requirements — and durability is the compliance-relevant one. A 72-hour outage is survivable: no claim goes unpaid, no member is denied care, no provider goes unverified. But the warehouse is the system of record for quality measurement and feeds statutory reporting, and losing a measurement year is not recoverable at any RTO, because by the time the loss is discovered the source transactions have aged out of the systems that produced them. Retention is set at seven years, above the HIPAA floor, driven by state insurance record rules.
The tested-restore condition is the one that gets skipped, and it is the only one that proves anything. Backups configure easily and report success daily. A first-time cloud organization can run a green backup dashboard for a year and still be unable to recover, because nobody has tried — and the first attempt will be during the incident. A backup you have never restored is a hypothesis. The test is what discovers that the retention policy excluded a container, that the restore takes eleven days, or that the BAA never covered the paired region.
9. Acceptance Gate Before Wave 1
The landing zone is accepted, not declared finished. Wave 1 does not begin until every condition below is evidenced.
| Ref | Condition | Evidence |
|---|---|---|
| LZ-01 | Management group and subscription structure deployed | Structure exported and reviewed against this design |
| LZ-02 | Network address plan reconciled with both on-premises estates | ⚠ No overlaps, evidenced by the reconciled address register |
| LZ-03 | Connectivity established and tested to both data centers | Routing and firewall validation results |
| LZ-04 | Identity model deployed; JIT elevation operating | Elevation request tested end to end, including for MSP staff |
| LZ-05 | All policies assigned and in effect | ⭐ Compliance report showing zero non-compliant resources, plus a deliberate failed deployment proving PL-01 denies a non-US region |
| LZ-06 | Central logging operating with immutability | Log ingestion confirmed; deletion attempt fails |
| LZ-07 | Tagging enforced; showback producing output | Untagged deployment rejected; first showback report issued |
| LZ-08 | Backup configured per tier | Policy compliance per workload tier |
| LZ-09 | Restore tested end to end | ⚠ Restore evidence retained. Not a configuration screenshot. |
| LZ-10 | MSP step-down phase 1 operating; ACME staff embedded | Named individuals in place; shadowing underway |
LZ-05 asks for a deliberate failure, and that is the pattern worth carrying into every gate on this program. A compliance report showing zero violations is consistent with the policy working and equally consistent with the policy not being assigned. Attempting a deployment that should be denied — and having it denied — is the only evidence that distinguishes the two. The same logic drives LZ-06 (try to delete a log) and LZ-09 (actually restore something). Controls are proven by their failures, not by their dashboards.
Related artifacts: 7 — Due Diligence Findings (DD-05, DD-12) · 20 — Application Disposition Matrix (AD-20) · 22 — TSA Schedule & Exit Plan (TS-04, TS-05) · 24 — Cloud Migration Strategy · 25 — Integration Architecture · 26 — Quality Plan · 28 — Risk Register · 35 — Cloud Migration Wave Plan · BAA Register