What belongs in an AWS landing zone

A landing zone is the part of a migration with no visible output. Nothing is faster, nothing is migrated, and to anyone watching the programme it looks like three to five weeks of nothing. It is also the part that determines how much everything afterwards costs.

Account structure

Use AWS Organizations with separate accounts per environment and, where it makes sense, per business unit or product. This is not bureaucracy — it is the only hard boundary AWS offers.

An account boundary gives you three things at once: a blast radius limit, so a mistake in development cannot reach production; a natural billing split, so cost attribution needs no tagging discipline to be roughly right; and a clean permission boundary, so access can be granted per account rather than carved out of a single sprawling policy.

A common baseline: a management account that runs nothing, a security account holding logs and audit tooling, a shared services account for CI/CD and networking, then per-environment workload accounts.

Networking

Design the VPC topology before workloads need it. Typically a hub-and-spoke arrangement with Transit Gateway, non-overlapping CIDR ranges allocated deliberately, and hybrid connectivity back to on-premise via Direct Connect or VPN for the migration period.

Allocate address space with room to grow. Overlapping or exhausted CIDR ranges are among the most tedious problems to fix after the fact, because resolving them means re-addressing live workloads.

Identity

Federate IAM Identity Center to your existing directory. Nobody should be creating IAM users by hand, and long-lived access keys should not exist — human access comes from federated short-lived credentials, and machine access from roles.

Define permission sets by job function rather than per person. "Read-only auditor", "database operator", "platform administrator" scale; a bespoke policy per individual does not.

Guardrails

Service control policies enforce what cannot be done, at the organisation level, regardless of what permissions someone has been granted within an account. Common baselines: deny disabling CloudTrail, deny deployment outside approved regions, deny creating public S3 buckets, require encryption at rest.

The distinction from a compliance scanner matters. A scanner tells you afterwards that someone created a public bucket. A service control policy means they could not. Remediation without prevention is a task you repeat every quarter.

Logging and detection

CloudTrail across all accounts writing to a central, immutable destination in the security account. AWS Config for resource state history. GuardDuty and Security Hub enabled organisation-wide.

Turn this on before the first workload, not after the fiftieth. Evidence you did not collect is evidence you cannot produce, and the first time that matters is usually an audit or an incident.

Tagging

Agree a minimal mandatory tag set — owner, environment, product, cost centre — and enforce it with a policy that prevents untagged resources being created.

This is the one that gets deferred most often and costs most to add later. Without tags applied from the beginning you cannot attribute cost to a team or product, and unattributed cost is nobody's problem to reduce.

Deliver it as code

All of the above should be Terraform or CloudFormation held in your own repository. A landing zone assembled through the console works exactly once and cannot be reproduced, reviewed or rolled back. AWS Control Tower automates a good deal of the setup and is worth using, but you should still hold the configuration as code you control.