4 Principles for the Perfect Landing Zone in Azure and AWS (2026)

Over the years I've worked with a lot of organisations that give their business teams direct access to platforms like Azure and AWS. It unlocks a huge amount of flexibility, and teams can test new products at pace. It also tends to create a bit of tension between IT, the business and the exec.

On one side, the business needs to get new features out to customers. On the other, costs can spiral and the security team's overtime starts to look like a weekly line item. A well-designed landing zone is how you get the benefits of cloud without giving up control of your costs or your data. Here are the four principles I build into every cloud strategy, updated for how Azure and AWS work in 2026.

Key Takeaways: Landing Zone Principles

• A landing zone is a pre-configured cloud environment with networking, identity, security and monitoring built in, so teams can deploy quickly without bypassing governance.
• Good landing zones enable teams rather than block them. Agree the rules of the road and make the compliant route the easiest one.
• Report on most things and block only what really matters, such as public data exposure or deploying into the wrong region.
• A pattern-led service catalogue, delivered through subscription vending in Azure or Account Factory in AWS, lets teams self-serve environments that are secure by default.
• Start small and iterate. Over-engineering the landing zone on day one is one of the most common reasons these projects stall.

What is a landing zone?

A landing zone is a pre-configured, governed cloud environment that workloads are deployed into. Networking, role-based access, policy, logging and monitoring are set up from the start, so every new workload inherits the same guardrails rather than building its own.

If you think back to the golden years of on-prem IT, organisations had well-defined processes (well, mostly!). A project bought the right-sized servers, installed the OS and the security tooling, and any change went through a change board. It was slow, but it was controlled.

Then along came the cloud. Armed with a credit card, anyone could set up an account, spin up some services and put them on the internet. Shadow IT quickly became critical to business processes, and retrofitting the safety nets was painful. Microsoft and Amazon responded with landing zone frameworks: agreed guardrails that are deployed automatically when environments are provisioned. They had a nice side effect too. They took the "shadow" out of shadow IT, because business teams could now request their own landing zone, connected and supported, instead of going it alone.

Both providers now split this into two layers. In Microsoft's Azure landing zone guidance, the platform landing zone holds shared services like identity, connectivity and management, and application landing zones are the subscriptions where workload teams deploy their apps. AWS follows a similar multi-account model, usually built and managed through AWS Control Tower.

Why do landing zones matter more in 2026?

Because more of the business is building in the cloud than ever, and the stakes are higher. AI workloads, data platforms and customer-facing services are being spun up by teams well outside central IT, often in weeks rather than months.

For regulated firms the bar has moved too. FCA operational resilience rules and, for firms serving the EU, DORA both expect you to show that your important services run on controlled, monitored infrastructure. A landing zone is the most practical way to prove that every environment starts from the same secure baseline, rather than hoping each team got it right on their own.

What are the four principles of a good landing zone?

The four principles are: keep governance light, report before you block, build a pattern-led service catalogue, and don't over-engineer. Each one is about reducing friction between security and the business while keeping the controls that matter.

1. Governance with a lowercase g

The landing zone shouldn't be a blocker. Teams should be able to deploy the services they need, quickly. Agree the rules of the road up front, then put a requirements-led process in place that enables services rather than gatekeeping them. If the compliant route is slower than the workaround, people will find the workaround (I've seen it more times than I'd like to admit).

2. Report first, block only what really matters

Most controls should report, not block. Set up compliance reporting and alert account owners when patterns and principles aren't followed, then work with them to fix it.

In Azure, that means using Azure Policy in Audit mode for most rules and saving Deny for a short list of non-negotiables. In AWS Control Tower, it's the difference between detective controls (AWS Config rules that flag drift) and preventive controls (service control policies that stop the action outright). For regulated firms, the non-negotiables usually include publicly exposed storage, deploying outside approved regions, and turning off logging. Block those. Report on the rest.

3. Build a pattern-led service catalogue

Give teams validated patterns they can consume without building the plumbing themselves. Each pattern should include monitoring, alerting, role-based access and network connectivity by default.

This is where subscription vending in Azure and Account Factory in AWS come in. A team requests an environment, and automation creates it with the right policies, networking and access already in place. Microsoft's Azure Verified Modules (in Bicep and Terraform) and the landing zone accelerators make this much easier than it was a few years ago.

4. Don't over-engineer it

Coming from an architecture background, this is the hardest one for me, but believe me, it works. Start small, agree the requirements, accept the guardrails and iterate as new applications move to the cloud. You don't need to decide every setting on day one.

The accelerators are powerful, but they come with a lot of parameters and decisions that most teams aren't ready to make yet. Get closer to the business and engineering teams, ditch the silos, and let the landing zone grow with the workloads you're actually running.

How do Azure and AWS landing zones compare?

Both follow the same idea, a governed foundation with self-service environments on top, but the building blocks differ:

• Structure: Azure uses management groups and subscriptions (typically Platform, Landing zones and Sandbox). AWS uses organisational units and accounts under AWS Organizations.
• Guardrails: Azure uses Azure Policy with effects like Audit, Deny and DeployIfNotExists. AWS Control Tower uses preventive, detective and proactive controls.
• Self-service: Azure uses subscription vending. AWS uses Account Factory.
• Design guidance: Microsoft's Cloud Adoption Framework covers eight design areas: billing and Entra tenant, identity and access, resource organisation, networking, security, management, governance, and platform automation and DevOps. AWS publishes equivalent guidance for Control Tower landing zones.

How do you get started with a landing zone?

Step 1: Agree the requirements

Sit down with security, the business and engineering and agree what the landing zone must do. Which regions, which compliance obligations, which networks need to connect back to on-prem.

Step 2: Build the platform landing zone

Set up the shared foundation first: identity, connectivity, logging and the core policy set. Use the Microsoft or AWS accelerators as a starting point, not a finished product.

Step 3: Decide what to block and what to report

Write a short list of controls that must be enforced and set everything else to audit. Review the list with your risk team so the reasoning is documented.

Step 4: Create your first patterns

Pick one or two common workload types and build them as vendable patterns. Prove the process with a real team before you build ten more.

Step 5: Iterate as workloads land

Review compliance reports regularly, tune policies that create noise, and add patterns as new demand comes in. A landing zone is never really finished.

Common landing zone mistakes

• Trying to design everything up front. Months of design with nothing deployed is how landing zone projects lose the business.
• Blocking by default. Too many deny policies push teams back towards shadow IT.
• No owner for the platform. Someone has to run the landing zone as a product, with a backlog and a roadmap.
• Ignoring cost. Budgets, tagging and cost alerts belong in the landing zone from day one, not after the first surprise bill.
• Treating it as an IT-only project. Without the business and engineering teams involved, nobody uses the patterns you build.

How Yobah helps with landing zones

We help organisations, particularly regulated fintechs, design and build landing zones on Azure that the business will actually use. That usually starts with a short requirements workshop, then a platform landing zone built on Microsoft's accelerators, a small set of enforced controls, and one or two vendable patterns proven with a real team. From there we help you iterate, so the landing zone keeps pace with what you're building.

FAQs About Landing Zones

What is the difference between a platform landing zone and an application landing zone?

The platform landing zone holds shared services like identity, networking and management that every workload relies on. Application landing zones are the subscriptions or accounts where individual teams deploy their workloads, inheriting the platform's guardrails.

Do I need a landing zone if I only run a few workloads in the cloud?

Yes, but keep it small. Even a handful of workloads benefits from consistent identity, logging and network design, and it's much easier to start with a light landing zone than to retrofit one later.

How long does it take to build a landing zone?

A basic platform landing zone using Microsoft's or AWS's accelerators can be in place within a few weeks. Most of the time goes into agreeing requirements and decisions, not deploying the code.

Should landing zone policies block or report?

Mostly report. Block only the small set of things that would cause real harm, such as public data exposure or deploying outside approved regions, and use reporting and alerts for everything else.

What is subscription vending?

Subscription vending is Microsoft's term for automatically creating new Azure subscriptions, with networking, policies and access already applied, when a team requests one. AWS offers the same idea through Account Factory in Control Tower.

Thinking about a landing zone, or wondering whether the one you've got is holding your teams back? Grab some time in my diary and we can talk it through.

Book a time with Paul