How to set up a cloud landing zone

A landing zone is the account structure, network layout, identity model and guardrails you put in place before the first production workload arrives. Get it roughly right and everything after it is easier. Get it wrong and you spend the next two years unpicking decisions that are now load-bearing.

The mistake most teams make is treating the landing zone as a project to be completed. It is not. It is a foundation that will be extended for as long as you use the platform. What matters is deciding which parts have to be right on day one, and which can be added once you know how the platform is actually being used.

What has to be right before the first workload

Some decisions are expensive to reverse because everything built afterwards depends on them. These are worth slowing down for.

Account and subscription structure

Separate accounts (AWS) or subscriptions (Azure) are the strongest isolation boundary the platform offers. They limit the blast radius of a mistake, they make cost attribution honest, and they let you apply different policy to different environments without writing complicated conditions.

At minimum, separate production from non-production. Most organisations end up with something like a management account, a shared services account for things like logging and DNS, and then one account per environment per workload group.

Resist the urge to start with a single account and split later. Moving resources between accounts is possible but tedious, and the temptation to leave things where they are is strong.

Identity, and how people actually get access

Federate to your existing identity provider rather than creating cloud-native users. You already manage joiners, movers and leavers somewhere; adding a second place to do it means the second place will drift.

Grant permissions to groups, not people. Use roles that are assumed for a session rather than long-lived credentials. Long-lived access keys are the single most common cause of cloud credential exposure, and they are avoidable in almost every case.

Decide early how a human gets administrative access in an emergency. There should be a documented break-glass path that does not depend on the identity provider being available, and it should be monitored so that using it is noticed.

Network layout and address space

Pick your address ranges with more room than you think you need, and check them against what is already in use on-premises and in any network you might one day connect to. Overlapping CIDR ranges are one of the few genuinely painful problems in cloud networking, because the fix is renumbering.

Decide whether workloads reach the internet directly, through a shared egress point, or not at all. Shared egress costs more in data processing charges but gives you one place to inspect and log outbound traffic, which auditors like and incident responders need.

Logging that cannot be turned off from inside

Send audit logs, network flow logs and configuration history to an account that workload teams cannot write to. If someone with production access can delete the evidence of what they did, the logs are not evidence.

Set the retention period deliberately. Default retention is usually shorter than any regulator or insurer expects, and you cannot recover logs you did not keep.

What can wait

Plenty of landing zone advice reads like a list of everything the platform can do. Most of it can be added later without pain, and adding it later means you add it based on what you have learned.

• Fine-grained cost allocation tags. Start with two or three mandatory tags. A twelve-tag taxonomy designed before anyone has deployed anything will be wrong and ignored.
• Every available guardrail. Start with the controls that prevent expensive or irreversible mistakes: blocking public storage buckets, preventing the deletion of logs, restricting which regions can be used. Add detective controls as you find gaps.
• A full service catalogue. Curated, pre-approved templates are genuinely useful, but only once you know which patterns repeat. Build them from real deployments, not hypothetical ones.
• Multi-region anything. Unless you have a stated recovery objective that requires it, a second region adds cost and complexity for benefit you have not yet defined.

Guardrails that pay for themselves

A guardrail is a control that stops a class of mistake rather than catching it afterwards. A few are worth having from the start because the thing they prevent is either expensive or hard to undo.

• Restrict which regions can be used. This limits accidental deployments in the wrong jurisdiction and makes your monitoring and cost views complete.
• Prevent public exposure of object storage by default. Allow it as a deliberate exception on specific buckets, not as a global setting somebody can flip.
• Require encryption at rest. Both platforms make this close to free; the work is in making it non-optional.
• Prevent the deletion or reconfiguration of the audit trail from within a workload account.
• Set budgets with alerts at the account level from day one. Not to control spend, but so that a runaway process is noticed in hours rather than at the end of the month.

Common mistakes worth avoiding

Building the landing zone in isolation from the first workload. A foundation designed with no real application in mind tends to be both over-engineered and subtly wrong. Bring the first migration candidate in early enough that it exposes bad assumptions.

Treating the vendor's reference architecture as a specification. Both AWS and Azure publish good guidance, and both assume an organisation larger and more regulated than most. Use it as a checklist of things to have an opinion about, not as a list of things to build.

Making the platform team a bottleneck. If every new environment requires a ticket to a central team, teams will work around the platform. Automate account creation with the guardrails baked in, so that the fast path is also the compliant path.

Leaving the naming and tagging convention undocumented. It does not have to be elaborate. It does have to be written down somewhere people will find it, and enforced by policy rather than by review.

A reasonable order of work

1. Agree the account or subscription structure and the environments you need.
2. Connect identity, define the role model, and remove any long-lived credentials created during setup.
3. Set the address plan and build the network for one environment.
4. Centralise logging into an account nobody else can write to.
5. Apply the small set of preventive guardrails above.
6. Migrate or build one real workload end to end.
7. Review what the first workload made awkward, and fix that before the second.

That last step is the one most often skipped, and it is the one that determines whether the landing zone helps for the next three years or quietly gets bypassed.

Where it usually goes wrong later

Landing zones decay in predictable ways. Exceptions get granted and never revisited. A team gets a permissive role "temporarily". A new region opens for a proof of concept and stays open. Logging is configured for the accounts that existed at the time and not for the ones created since.

Schedule a review, quarterly is usually enough, that checks a short list: which accounts exist and who owns them, which permissive exceptions are still in place, whether logging covers everything, and what the guardrail violations of the last quarter were. A foundation that is checked stays a foundation. One that is not becomes archaeology.