Landing zones: getting the guardrails right on day one

Cloud security rarely fails on day one. It fails on day four hundred, when there are sixty accounts, three naming conventions, a production database in someone's sandbox, and nobody can say which logs exist. Almost every one of those problems was decided — by omission — when the first account was created.

A landing zone is the answer. Microsoft defines an Azure landing zone as "a proven and flexible architecture for governing, securing, and scaling a multi-subscription Azure environment", split into a central platform landing zone and the application landing zones where workload teams deploy "within the guardrails of the platform landing zone". AWS uses the same term in Control Tower, and its guidance on organising multiple accounts describes the same idea: a foundation of accounts, organisational units and policies that workloads land into.

What both Well-Architected frameworks agree on

AWS's Well-Architected Framework has six pillars; Azure's has five. Both include Security, and while the wording differs, the foundations converge:

• Identity first. AWS's first security design principle is to "implement a strong identity foundation" — least privilege, separation of duties, centralised identity, and no reliance on long-term static credentials. Azure's landing zone guidance calls identity and access management "a primary security boundary in the public cloud".
• Segmentation and blast radius. Azure asks whether your security measures will be "effective in restricting the blast radius of an incident" and recommends segmentation to plan security boundaries. AWS describes an account as "an isolation boundary for identity and access management", with no access between accounts unless you explicitly allow it.
• Traceability. AWS: "maintain traceability" — monitor, alert and audit actions and changes in real time. Azure: "maintain an audit trail of all types of access activities".
• Automation. AWS recommends controls "defined and managed as code in version-controlled templates". Azure recommends enforcing policies to maintain your posture and automating repetitive tasks to reduce human error.
• Assume breach. Azure's pillar is built on Zero Trust — verify explicitly, use least-privilege access, assume breach. AWS's equivalent is "prepare for security events".

The guardrails I put in before the first workload

1. Structure as a security boundary

Separate accounts (AWS) or subscriptions (Azure) per workload and environment, grouped into organisational units or management groups so policy is inherited rather than copied. Keep security and logging out of workload teams' reach: AWS recommends a clean security OU that contains only the essential security accounts, and Azure's reference hierarchy gives Security, Management, Identity and Connectivity their own management groups and subscriptions under the platform landing zone.

One AWS detail that catches people out: service control policies don't affect users or roles in the management account. That alone is a good reason to keep workloads out of it entirely.

2. Preventive guardrails that set the outer boundary

On AWS, service control policies (SCPs) set the maximum permissions for member accounts — they never grant anything, they cap what identity policies can grant, and they apply even to an account's root user. On Azure, Azure Policy assigned at a management group is inherited by every subscription and resource beneath it and can deny non-compliant changes outright. The day-one set I reach for: allowed regions only, logging that can't be switched off, no public exposure of storage by default, and required tags for ownership and data classification.

3. Detective guardrails and traceability

Centralise logs from every account or subscription into a place workload teams can't alter or delete. AWS Control Tower sets up dedicated logging and security accounts as part of the landing zone; on Azure, a policy can require resources to send diagnostic logs to a Log Analytics workspace. Turn on posture management centrally too, so a new environment is watched from the moment it exists rather than from the moment someone remembers.

4. Identity without standing access

One identity provider, federated everywhere; no long-lived access keys; elevation that expires. Azure's security principles recommend just-in-time and just-enough access to replace standing permissions wherever possible, and AWS's identity principle aims to eliminate reliance on long-term static credentials. Standing admin rights are among the most valuable things an attacker can find in a cloud estate — don't leave them lying around.

5. A paved road for new workloads

A landing zone only works if getting a new environment is easier through it than around it. Azure calls this subscription vending — "a repeatable process for requesting, creating, and distributing application landing zones". AWS Control Tower provides Account Factory. Either way, every new environment arrives with the guardrails already applied, and nobody has to file a ticket to be secure.

Why day one matters

Guardrails applied before workloads exist are cheap, because nothing depends on the old behaviour. Applied later, every new policy has to be tested against everything already running — which is exactly why both vendors tell you to audit before you enforce. And moving a workload into a properly structured account or subscription after the fact is migration work, not configuration.

Each guardrail should also earn its place. "No public storage" exists because a business attribute — confidentiality — is threatened by a specific risk. If you can trace a guardrail back like that, it's easy to defend; if you can't, it's a candidate for removal. I wrote about building that chain in Mapping controls to frameworks without drowning in them.

Start small

You don't need a full enterprise reference architecture to begin. The minimum I'd accept, even for a small team:

• a management account or root with no workloads in it;
• a security and logging area that workload teams can't touch;
• a handful of preventive guardrails — regions, logging, public exposure;
• central identity with no long-lived keys;
• a way to create new environments that applies all of the above automatically.

Both vendors provide tooling for exactly this — Azure's landing zone accelerators and AWS Control Tower. Use them unless you have a clear reason not to.

---

A landing zone isn't a project you finish; it's the ground every future workload stands on. Get the guardrails right while the ground is still empty, and security becomes something teams inherit rather than something they have to remember.

Sources

• What is an Azure landing zone? and design areas — Microsoft Cloud Adoption Framework
• Security design principles and pillars — Azure Well-Architected Framework
• Overview of Azure Policy — Microsoft Learn
• Security design principles and Security Pillar — AWS Well-Architected Framework
• Organizing your AWS environment using multiple accounts — AWS whitepaper
• Service control policies (SCPs) — AWS Organizations
• About AWS accounts in AWS Control Tower — AWS