Why a landing zone comes before the first workload
Most cloud estates do not start with a plan. They start with one account, one engineer and a deadline. A year later there are shared credentials, a production database sitting next to experiments, no central audit trail and a bill nobody can break down. Fixing that after the fact means moving live systems, which is slow and risky.
A landing zone reverses the order. You decide the structure of accounts, identity, logging and guardrails first, then place workloads inside it. This page covers how we approach it. It is the entry point to our wider ClickOps and cloud setup service, and each component has its own page: multi-account structure, security baseline and Terraform code for the lot. We also publish a dedicated AWS landing zone page.
What a landing zone contains
Whatever the platform, the same concerns appear:
- Structure: a management layer, a place for security and logging, and separate homes for workloads by environment.
- Identity: single sign-on, role-based access and no long-lived user credentials.
- Guardrails: policies that stop dangerous actions regardless of who attempts them.
- Logging and audit: an immutable record of API activity, stored where workload admins cannot edit it.
- Network foundation: address planning, egress, and connectivity patterns.
- Cost controls: budgets and tagging rules from day one.
None of these is exotic. The skill is in choosing sensible defaults for your size and enforcing them consistently.
Control Tower, Azure reference architecture or manual
AWS Control Tower
Control Tower sets up a multi-account environment on top of AWS Organizations, creating log archive and audit accounts, enabling CloudTrail and Config centrally, and applying a library of managed controls. Its Account Factory provisions new accounts to a standard. For a team that wants a defensible baseline quickly, it is usually the right start.
The trade-offs are real. Control Tower has opinions about its home region and organisational unit layout, some operations are slow, and drift happens if people change managed resources by hand. Its configuration is also not as transparent as code you wrote yourself.
Manual build with Terraform
A manual build uses Organizations, SCPs, IAM Identity Center and security services directly, all in Terraform. You get exact control and reviewable code, and no dependency on a managed service’s release cycle. You also take on responsibility for every piece, including keeping up with new AWS features.
Azure
Microsoft publishes a landing zone reference architecture built around a management group hierarchy, Azure Policy assignments, a hub virtual network for shared services and spoke networks per workload. We start from that model and trim it, because the full enterprise pattern is heavy for a team of fifteen engineers. Subscriptions play the role AWS accounts play: a billing, access and blast-radius boundary.
How we choose
| Situation | Our usual recommendation |
|---|---|
| Startup, first multi-account setup on AWS | Control Tower for the base, Terraform for everything on top |
| Strict custom layout or existing Organizations tree | Manual Terraform build |
| Microsoft-first company with Entra ID | Azure reference landing zone, simplified |
| Single product, one environment, pre-revenue | A hardened single account, with a plan to split later |
How it works in practice
A typical AWS foundation, expressed in Terraform, begins with the organisation itself and its organisational units:
resource "aws_organizations_organization" "this" {
feature_set = "ALL"
aws_service_access_principals = [
"cloudtrail.amazonaws.com",
"config.amazonaws.com",
"sso.amazonaws.com",
]
enabled_policy_types = ["SERVICE_CONTROL_POLICY"]
}
resource "aws_organizations_organizational_unit" "workloads" {
name = "Workloads"
parent_id = aws_organizations_organization.this.roots[0].id
}
On top of that go the security and log archive accounts, the organisation-wide CloudTrail trail, identity configuration and baseline policies. The Terraform state lives in a dedicated account with versioning and restricted access, as we describe in our Terraform and IaC work.
Changes flow through pull requests. A plan is posted, a second engineer approves, and a pipeline applies it with short-lived credentials. Nobody applies foundation changes from a laptop.
What goes wrong without one
- Everything in one account. A compromised credential or a runaway script reaches production data and the audit logs alike.
- No central logging. After an incident there is nothing trustworthy to read.
- Inconsistent access. Some people have admin everywhere because it was easier at the time.
- Surprise bills. Without per-account budgets, a forgotten GPU instance goes unnoticed.
- Slow audits. Evidence is scattered, and every question becomes a research project.
Common failure modes in landing zone projects
Over-engineering. A twelve-account design with five organisational units is wrong for a team of eight. We size to what you will actually operate in the next eighteen months, leaving room to grow.
Under-documenting. If nobody records why a guardrail exists, it gets disabled during the first awkward deployment. We write short decision records alongside the code.
Ignoring the humans. A perfect structure that engineers cannot work in gets bypassed. We test the developer experience: how long it takes to get a new account, and what a failed deployment message looks like.
Treating it as finished. Cloud services change. A landing zone needs periodic review, which is something we can fold into ongoing managed DevOps if you want it.
When not to buy this
If you are running a prototype with no customer data and a single developer, spend your time on the product. Enable MFA, set a budget alert and revisit this when you hire your third engineer. Our DevOps maturity assessment is a quick way to judge whether you are at that point.
Delivery and handover
We work in short phases with a written design at the end of the first one. Code goes into your repository from the start, never ours. At handover you receive the architecture decision records, a runbook for adding an account or workload, and a recorded walkthrough for new joiners. If you want help afterwards, that is optional and discussed separately under our engagement models.
How to tell it is working
- A new workload account can be created from a pull request in an afternoon, not a week.
- Every account sends API activity to the log archive, and engineers cannot alter it.
- Guardrails block a deliberately bad action in a test account.
- Each team sees its own spend.
- Nobody remembers the root user password, because nobody needs it.
If you are weighing up a landing zone for a new or existing environment, book a consultation and we will tell you honestly which approach fits.