A landing zone is usually described as a foundation, which is accurate and unhelpful. The practical question is what you get on day one, what still has to be decided, and which parts are expensive to change once workloads exist.
What the tooling gives you
AWS Organizations and Control Tower can create a multi-account structure, apply a set of preventive and detective guardrails, and centralise log storage. That is genuinely useful: it removes the manual work of creating accounts correctly and gives you a baseline that an auditor recognises.
It also produces a structure that looks complete and is not. Accounts exist, but who belongs in which group, what the network looks like, and how the bill is attributed are still your decisions.
What it does not decide
Identity. Control Tower can enable IAM Identity Center, but the group model, the role names and the break-glass process are yours. A landing zone where everyone is an administrator is compliant on paper and unsafe in practice.
Network. Address ranges, segmentation, egress paths, private connectivity and DNS are design work. Getting the CIDR plan wrong is the single most expensive mistake to correct later, because overlapping ranges block peering.
Cost attribution. Tags and budgets need a scheme, and the scheme needs an owner. A landing zone with twelve mandatory tags will be bypassed; four enforced tags will be used.
Environments. How many accounts, what belongs in each and who can create resources are business decisions. The tool can create the accounts faster than you can decide what they are for.
The guardrails that earn their place
Region restrictions, blocked public storage, required encryption and mandatory tags prevent the expensive mistakes. Guardrails that block routine work get bypassed through an exception process that nobody reviews.
Start with a short list and add only when a real incident justifies one. A policy created after an incident has a story behind it and gets respected; a policy copied from a checklist does not.
The network plan deserves its own week
Draw the address plan before creating anything. Decide which workloads need private connectivity to an office or data centre, whether egress is centralised, and where DNS resolves. Those three answers shape every later connection.
A common failure is creating a VPC per team with overlapping ranges, then discovering that the shared services account cannot reach two of them without a redesign.
Logging, retention and the bill
Centralised logs are the right pattern, and retention is where the cost lives. Application logs kept for a year, in a searchable tier, can cost more than the workload that produced them.
Set retention by data type: security logs long, application debug logs short, access logs somewhere in between. Write it down, because the default will be whatever the console suggested.
Migration into the landing zone
Workloads should arrive after the structure exists, not before. When a workload lands first, the account it lands in becomes the structure by accident, and moving it later means rebuilding network paths and identity.
If you already have workloads, a landing zone project becomes a staged move: create the target structure, migrate the least risky workload, prove the pattern, then continue.
How long it actually takes
A single-environment foundation takes two to three weeks. A multi-account build with federated identity, shared networking and policy enforcement takes four to six, with identity integration and compliance review as the usual delays.
The work is not difficult. It is sequential, and the sequence is what most teams underestimate.
The build itself is described on cloud landing zone setup. If the account already exists and the bill is the symptom, start with cloud cost optimisation; the platform comparison is on cloud services.
