Hi, I’m Simone, Principal Consultant at Arkahna and the owner of Elements Core, our flagship landing zone product. If you’ve heard people talk about landing zones and thought, “Whats a landing zone, why do I need one or how do I get started?” this post is for you.
Throughout my career, I’ve seen many businesses approach cloud by adding resources as needed and growing their cloud footprint organically. Then, as they grow without a solid foundation, they start to hit subscription limits, security concerns, or find teams are accidently impacting other teams workloads because there’s no boundaries between them.
For a long time there was also lots of confusion about what was considered “best practice” for the cloud in the absence of detailed guides like the ones VMware used to provide, so people continued as they had on premises and saw cost blowouts, sprawl and performance issues as a result.
Thankfully in the past few years the big cloud vendors have developed their own Cloud Adoption and Well Architected frameworks. Microsoft’s Cloud Adoption Framework (CAF) is opinionated guidance for adopting the cloud, based on thousands of customer migrations. Within that mountain of advice, the Ready phase outlines how to build Azure Landing Zones so you can confidently build your cloud footprint while minimising technical debt.
An Azure landing zone is an environment designed using key principles across eight core areas, enabling you to scale and manage application portfolios at any size. It includes:
Enterprise Agreement and Subscription Organisation: Defining how to structure your subscriptions and manage them within an enterprise, including isolation of workloads and applications.
Identity and Access Management: Implementing Entra ID for user authentication, role-based access control (RBAC), and identity governance to manage access securely.
Network Topology and Connectivity: Designing a scalable and secure network architecture, including virtual networks (VNets), hybrid connectivity, and secure communication between resources.
Resource Organisation: Structuring your resources using resource groups, management groups, and naming conventions for consistent organisation and easy governance.
Governance, Security, and Compliance: Applying Azure Policy and role assignments to enforce governance, security baselines, and compliance guardrails across the environment.
Management and Monitoring: Setting up Azure Monitor, Azure Log Analytics, and Azure Security Center to ensure operational insights, monitoring, and automated issue detection.
Business Continuity and Disaster Recovery (BCDR): Implementing backup and recovery solutions to ensure resilience and minimise downtime, using services like Azure Backup and Site Recovery.
Platform Automation and DevOps: Enabling automation and continuous integration/continuous delivery (CI/CD) pipelines through Azure DevOps, Terraform, and infrastructure as code (IaC) to deploy and manage resources efficiently.
Based on these design areas, there are “zones” aka subscriptions that are used to isolate and scale resources. These include:
Application landing zones for workloads
Platform landing zones for the core, shared infrastructure.
The architecture is modular and repeatable. Ensuring security, scalability, and governance from the start. It supports ARM, Bicep, and Terraform, making it easy to apply configurations across subscriptions and evolve as your needs change.
If you look at the Microsoft Documentation, a landing zone looks like this:
Which is where most people nope out and go back to building things organically as they need them. But before you run for the hills, lets break it down so it’s a bit more digestible.
At Arkahna our landing zones start with the governance layer, we deploy management groups to govern subscriptions.
Then we have the core connectivity, identity and management subscriptions or sometimes resource groups depending on the org. This is where the core, shared, platform resources live. Your hub network, your firewall, front door, container registry and logging for example.
We add a dash of governance and security across the whole environment which includes core alerts, budgets, azure policy and logging:
We use subscription vending to automatically create base subscriptions for your workloads, applications, and sandboxes. This means new Azure subscriptions are programmatically generated with consistent, predefined settings, guardrails, and core resources.
Instead of manually setting everything up, you simply fill out a few values in GitHub, and a new subscription is created. It comes ready with essentials like a VNet peered to the hub network, Azure Policy applied, budgets configured, and core alerting and logging enabled. This ensures everything is deployed and governed consistently, so your teams can work, innovate, and even break things—without accidentally affecting other teams.
And eventually, we end up with a fully baked, governed environment that can scale and grow, which looks like this:
And since everything is managed as Terraform code, tracking, updating, and documenting your infrastructure becomes straightforward. Terraform lets you version control your infrastructure just like code—every change is logged, reviewed, and can be rolled back if needed, ensuring full visibility and control.
While coming in to beautify unwieldy cloud environments keeps me employed, it’s in your best interests to avoid technical debt where you can. There’s usually a catalyst for deciding to “re-do” the cloud environment, and the most common reasons I see are:
Accidental Resource Destruction
Without clear access controls, one team can easily interfere with another. Someone deletes a critical resource in a shared environment, taking down production. With no guardrails, deployment gates, or proper tagging, teams can’t see what might be impacted until it’s too late.
Subscription Limits, Cost Blowouts, and Sprawl
As your cloud grows, you’ll hit subscription limits, and without proper structure, resources become hard to track and control. Tagging, budgeting, and governance can help keep costs in check, pinpoint resource owners, and enable cost-saving measures like auto-shutdown but they’re hard to retrofit to an exiting environment.
Rebuilding Everything into Infrastructure as Code
Hand-built resources work—until they don’t. As your environment grows, redeploying or expanding to a new region becomes a headache. Whether you’re setting up DR, scaling for high availability, or recovering from a security breach, you’ll eventually need to refactor into code for consistency. Retrofitting this is a costly, time-consuming task that could have been avoided.
The Pain of Migrating to a Proper Landing Zone
When it’s time to scale seriously, migrating into a well-architected landing zone often means starting from scratch. While there are tools to move some resources, many still need to be rebuilt, and that’s never fun for any team.
The good news is that getting started with landing zones doesn’t need to be complicated. Microsoft’s Azure Landing Zone Accelerator is a great starting point, offering pre-configured, opinionated options to fast-track your setup.
However, if you need something more production ready, Arkahna’s Elements Core product can step in to handle the heavy lifting.
It’s one thing to get a landing zone up and running, but it’s another to make sure it’s production-ready. The Microsoft documentation has a detailed list of considerations that you can work through:
At Arkahna we take our industry experience working with SMEs and Start-ups and make sure your Landing Zone is ready for production workloads and equipped to support your business as it grows.
To do this we deploy:
Subscription vending: to automate subscription creation as code to manage cloud resources at scale.
Consistent naming and tagging: defined naming standard for all resources and enforced minimum tags.
Core platform logging and monitoring: to ensure complete visibility into your cloud infrastructure, with tools that track performance and detect anomalies.
Security baselines: We implement Azure Policy for governance and compliance to safeguard your environment.
Azure Advisor alerts: To help you stay on top of cost optimisations and performance recommendations.
Backups: We set up automatic backups for resilience and disaster recovery.
Multi-tenant deployments: We build in the ability to scale across different regions for resilience, data sovereignty or flexibility as you grow.
Once your landing zone is production-ready, you’re positioned to start deploying application-specific workloads into the vended subscriptions, as shown in the diagram below. You can leverage Arkahna Elements products or Azure’s verified modules to simplify and speed up these deployments.
Whether you’re launching a new service, scaling up existing applications, or managing multi-region deployments, landing zones provide the structure to make it all seamless. The modular architecture ensures that your infrastructure can grow with you, and the built-in governance keeps everything secure and compliant from day one.
If you’re part of a smaller business or startup, you might wonder, “Do I really need all this structure?”
And honestly, the answer is yes. Piecing together your cloud setup as you go might work for a while, but it often leads to technical debt and an infrastructure that struggles to scale. By the time you’re ready to grow, retrofitting governance and security can become expensive and disruptive.
For larger organisations, the benefits are clear. Landing zones provide a consistent framework for governance, security, and scalability, ensuring that your infrastructure can handle growth without becoming unwieldy. For smaller teams, having these foundational elements in place means you won’t have to scramble to address gaps later on.
As a bonus, here are some of my go-to resources for keeping up with the latest Azure Landing Zone developments:
The Azure Landing Zone Community Calls: Azure Landing Zones - External Community Calls
The ALZ Terraform Roadmap: Azure Landing Zones Public Roadmap • Azure
Azure Landing Zones repo: Azure Enterprise-Scale · Discussions
Azure Verified Modules Community Calls: Customer Architecture & Engineering
Matthew Nixon : May 6, 2024 3:30:36 PM
As part of an engagement with a client, I had to write guidance around using Managed Identity when interacting directly with Azure REST APIs on Azure...
Ryan Royals : Jun 17, 2024 10:00:00 AM
An ambiguous name for a hard to track down issue! When you are doing a NSlookup for a blob endpoint on a Storage Account in a Virtual Network in...
Ryan Royals : May 27, 2024 3:06:45 PM
Howdy! In my previous article about Getting Started with Terraform I talked about what Terraform is, why it's neat-o, and a small example on getting...
Simone Bennett