Landing Zones and Infrastructure as Code

Cloud account foundations, network guardrails, IaC workflows, and drift control.

Landing Zones and Infrastructure as Code

A landing zone is the governed cloud foundation where workloads can be deployed safely. Infrastructure as Code (IaC) is the change workflow that keeps that foundation reproducible, reviewable, and recoverable.

Use this guide when creating AWS, Azure, Google Cloud, Oracle Cloud, hybrid, or bare-metal foundations for Assistance cloud infrastructure work.

Landing zone building blocks#

IaC workflow checklist#

• Keep state remote, encrypted, access-controlled, and backed up.
• Separate reusable modules from environment instantiation.
• Require code review for infrastructure changes.
• Run plan/diff checks in CI and store results with the change record.
• Protect production applies with approval, policy checks, and rollback notes.
• Detect drift on a schedule and route it to an owner.
• Document manual emergency changes and reconcile them back into code.

Tool selection criteria#

The tool matters less than the operating discipline: versioned changes, least-privilege access, tested modules, drift visibility, and clear production approval rules.

Reference architecture#

1
Cloud organization
2
  -> Management / security / shared services accounts
3
  -> Network hub and environment spokes
4
  -> Workload accounts or projects per domain
5
  -> IaC pipeline with plan, policy, approval, apply, and drift checks
6
  -> Observability, cost, audit, backup, and incident runbooks

Migration path from manual cloud#

1. Inventory current resources, owners, costs, and exposure.
2. Decide which resources are imported, rebuilt, retired, or left temporary.
3. Build the landing-zone baseline first: identity, logging, network, and policy.
4. Import or recreate low-risk resources to prove the workflow.
5. Move production resources only after backup, rollback, and validation plans exist.

Landing zone acceptance checklist#

A landing zone is ready for production workloads when these controls have named owners and working evidence:

• Identity federation, administrator roles, break-glass access, and access-review cadence.
• Central audit logs, security findings, network flow logs, and retention settings.
• Environment separation for production, non-production, sandbox, and shared services.
• DNS, certificate, ingress, egress, and private connectivity patterns.
• Remote IaC state, module versioning, plan review, policy checks, and drift detection.
• Backup, restore, incident, and cost-allocation runbooks for the first workloads.

Do not treat the first application migration as the landing-zone proof. Prove the foundation with a low-risk workload first, then promote critical services after the operational controls are exercised.

Keep a landing-zone decision log for exceptions such as public ingress, cross-account access, unmanaged resources, and manual changes. Each exception should have an owner and review date.

Assistance engagement fit#

• Cloud Infrastructure for landing zone design and implementation.
• Cloud Account Management for ongoing governance and cost hygiene.
• Cost Optimization for tagging, rightsizing, and financial controls.
• Managed DNS and Managed Certificates for foundational platform dependencies.

References#

• AWS Prescriptive Guidance: cloud foundations and landing zones
• Microsoft Cloud Adoption Framework landing zones
• Google Cloud landing zone design
• OpenTofu documentation