Glossary
Landing zone
The prepared foundation of an AWS environment: accounts, networking, permissions, logging and cost allocation, before the first application moves in.
A landing zone answers the questions that are painful to change later: how many accounts exist and what for, how the networks connect, who may do what, where logs end up, and how costs are attributed to a department.
AWS offers ready-made building blocks such as Control Tower. Whether you take them or describe the structure yourself in Terraform depends less on the technology than on who will operate it afterwards.
The most important building block is the account structure. An AWS account is the hardest boundary the platform knows: permissions, quotas, costs and the blast radius of mistakes all end there. So you separate at least production, pre-production and development, plus dedicated accounts for logging and security that nobody in the working accounts can write into.
Above the accounts sits an organization with organizational units and permission guardrails. These guardrails are prohibitions, not grants: they stop anyone in an account from switching off logging, launching resources in regions that were never approved, or removing the encryption from a data store. They do not replace permission management, they cap its maximum reach.
The network belongs in the same early round of decisions. Address ranges are handed out and documented centrally, otherwise two environments overlap exactly when they are supposed to be connected for the first time. How the accounts are connected, through a central transit or through targeted endpoints, depends on the traffic profile and has immediate cost consequences: traffic across central transit points is billed per gigabyte.
Access comes through the central identity service and roles from day one, not through users with long-lived keys. Long-lived keys are almost impossible to collect back in later, because nobody knows which script is using them.
The part that is missing most often is cost allocation. A binding set of mandatory tags, activated for cost allocation, plus an automatic check when resources are created. Introducing that afterwards means spending weeks relabelling resources that are long since in production.
How you notice it
- Everything runs in one AWS account, production next to test.
- Permissions were granted generously during setup and never trimmed.
- Logs live in the same account they are logging.
- There are users with long-lived access keys.
- Costs cannot be broken down by team or product.
Not to be confused with
- Control Tower
- An AWS product that sets up a landing zone and keeps checking it. The landing zone is the result, Control Tower one way to get there.
- Well-Architected Framework
- A catalogue of questions for assessing an existing architecture. A landing zone is built structure, not an assessment.
- Infrastructure as code
- The method a landing zone is described with. Without it the structure exists only as console state and drifts.
When it fits
- Before the first production application in AWS.
- Before a migration out of your own data centre.
- When more than one team is meant to create resources independently.
- When costs have to be reported per department, product or customer.
When it does not
- For a single experiment with a clear end date.
- As a large project ahead of the first production value: the structure grows in stages, not in six months of groundwork.
How to approach it
- Decide the account splitProduction, pre-production and development separated, plus dedicated accounts for logs and security. That is the only boundary AWS enforces hard.
- Put the organization and guardrails in placeOrganizational units and service control policies that protect logging, regions and encryption. Prohibitions nobody inside the account can lift.
- Hand out address ranges centrallyA documented plan before the first network exists. Overlaps only show up at the first connection, and by then the move happens in production.
- Access through roles and the identity serviceNo long-lived access keys. Whatever ends up in a script once is never found again later.
- Write logs into a separate accountAccess logs, configuration history and events belong where nobody who is currently making mistakes can delete them.
- Cost allocation from day oneDefine mandatory tags, activate them for cost allocation, enforce them at creation time. Labelling afterwards is the most expensive variant.
- Everything as code, with a pipelineThe structure belongs in Terraform or CDK and in a pipeline. What is built in the console is not reproducible for the next account.
Frequently asked
Do I need Control Tower for a landing zone?
No, but it removes work. Describing the structure yourself in Terraform gives more control and more maintenance. The decision hinges on who operates the environment later: a small team usually fares better with Control Tower, a platform team with its own code.
How many accounts make sense?
At least five: management, logs, security, production, non-production. As the organization grows, the answer is one account per application and environment rather than one larger shared account. Accounts are free, the limit is manageability, and that depends on whether the structure is described as code.
Can a landing zone be retrofitted?
Partly. Logging, guardrails and permissions can be pulled in later. The account structure and the network addresses are the problem: moving a production system into a different account means recreating resources and moving data, usually with downtime. That is why it is the one decision that falls before the migration.
How long does it take to build?
A few weeks are realistic for a workable base structure with accounts, guardrails, networking, access, logging and cost allocation, provided the decisions have been made. The time rarely goes into the implementation, it goes into clarifying who owns which environment and how costs should be attributed.