Cloud Architecture Should Start With Operating Reality

Cloud architecture is easiest to get wrong when it is treated as a purely technical exercise. The better question is: how will this platform be operated, secured, and funded after it goes live?

When teams skip that question, they often end up with a cloud environment that is expensive to maintain, too rigid to change, or both — regardless of how carefully the individual services were chosen.

Key Takeaways

• A landing zone is the foundation everything else sits on, not optional infrastructure. Microsoft defines an Azure landing zone as "a proven and flexible architecture for governing, securing, and scaling a multi-subscription Azure environment" (Microsoft Learn) — the platform layer that every workload subscription inherits policy from.
• Multi-subscription structure is a governance decision, not just an organisational preference. It determines blast radius, billing separation, and how cleanly different teams' access is isolated from one another — the same underlying logic applies to AWS multi-account and Google Cloud multi-project structures.
• The Well-Architected Framework is an audit lens, not a design methodology — and the pillars differ by provider. Azure's framework defines five pillars: reliability, security, cost optimization, operational excellence, and performance efficiency (Microsoft Learn). AWS and Google Cloud both add a sixth — sustainability — as a named pillar of their own frameworks. None of the three frameworks tell you how to structure your specific organisation's subscriptions and controls; they tell you what to check once a structure exists.
• Automation maturity differs meaningfully across clouds. AWS Control Tower is a single managed service that can "build a landing zone in less than an hour" (AWS documentation). Azure's closest equivalent is an infrastructure-as-code accelerator built on Azure Verified Modules, not a single push-button managed service — Microsoft's own guidance notes it requires more manual orchestration in exchange for more flexibility.
• Governance needs to be visible and enforced in tooling, not written down and hoped for. Guardrails engineers can see and self-serve within (policy-as-code, verified modules, automated subscription vending) get followed; guardrails that require a ticket and a wait get worked around.
• Cost allocation is a named discipline, not an afterthought. The FinOps Foundation frames it as the practice that lets "everyone take ownership for their technology usage" (FinOps Foundation) — and it requires a deliberate tagging and shared-cost strategy, not just switching on billing reports.
• The most consequential decisions are rarely about which service to use. They concern identity boundaries, who owns which control, how cost gets allocated back to teams, and what the support model looks like once the architecture is live — all considerably more expensive to change after the fact than before.

What Good Cloud Architecture Actually Does

A strong cloud architecture balances security, scalability, cost, and the team's actual ability to operate it. It gives engineers enough structure to move quickly without creating long-term operational debt. In practice, that starts with getting the foundational layer right before individual workloads are designed — and for organisations building primarily on Microsoft's platform, that foundation is the Azure landing zone.

The landing zone: your foundation, not an afterthought

Microsoft's Cloud Adoption Framework defines an Azure landing zone as "a proven and flexible architecture for governing, securing, and scaling a multi-subscription Azure environment" (Microsoft Learn). It has two parts: a single platform landing zone per Microsoft Entra tenant — the management group hierarchy plus centralized identity, connectivity, and monitoring resources — and multiple application landing zones, the subscriptions where workload teams actually deploy resources, inheriting governance policy from the management groups above them.

The framework organises the design decisions into eight areas across two categories, spanning tenant and billing setup, identity and access management, resource organisation, network topology, security, management, governance, and platform automation (Microsoft Learn). Microsoft's own guidance is explicit that these are meant to be evaluated in sequence rather than all at once — a genuinely useful discipline for teams tempted to design everything simultaneously and finish nothing.

Simplified from Microsoft's Cloud Adoption Framework landing zone model — original Halden Solutions illustration, not a Microsoft-published diagram.

Deploying this isn't a single click. Microsoft's implementation guidance lists three paths: a portal-based accelerator for teams without infrastructure-as-code experience (easier to start with, harder to version and evolve), a library of reusable Azure Verified Modules for Bicep or Terraform, and a full IaC Accelerator that wraps those modules in a four-phase pipeline — plan, prerequisites, bootstrap, run (Microsoft Learn). Notably, Microsoft's own documentation states there is no direct Azure equivalent to AWS Control Tower's single managed service — the IaC Accelerator is the closest analogue, but it automates deployment rather than fully managing the environment for you afterward.

That last point matters when comparing platforms, so it's worth doing briefly rather than assuming. AWS's landing zone concept is defined similarly — "an orchestration framework for your foundational AWS environment" (AWS Prescriptive Guidance) — but AWS Control Tower is a single service that "orchestrat[es] other AWS services like AWS Organizations and AWS Service Catalog to build a landing zone in less than an hour," including automated account provisioning through Account Factory (AWS documentation). Google Cloud takes a third approach: its Architecture Center documents a landing zone (or "cloud foundation") as a set of design decisions across identity provisioning, resource hierarchy, network design, and security controls, without naming one all-in-one managed product (Google Cloud documentation).

None of this makes one provider's landing zone concept better than another's in the abstract — it means the honest cost of automation differs. A team choosing Control Tower's single-service convenience is accepting AWS's structural defaults; a team using Azure's Verified Modules is accepting more setup work in exchange for more control over exactly what gets deployed.

Auditing against a recognised quality framework

Once the foundation exists, a Well-Architected–style framework is worth evaluating any design against — but the three major providers don't define it identically, and treating them as interchangeable overstates how aligned they are.

Azure's Well-Architected Framework names five pillars: reliability (resiliency, availability, and recovery), security (data protection, threat detection, and mitigation), cost optimization (cost modeling, budgets, and reducing waste), operational excellence (observability and DevOps practices), and performance efficiency (scalability and load testing) (Microsoft Learn). AWS's Well-Architected Framework names six pillars, adding sustainability (minimizing environmental impact through efficient resource use) alongside operational excellence, security, reliability, performance efficiency, and cost optimization (AWS documentation). Google Cloud's Architecture Framework also names six, pairing security with privacy and compliance as one combined pillar and including sustainability as its own (Google Cloud documentation).

The practical takeaway isn't that one provider cares more about sustainability than another — it's that "Well-Architected" is not one universal standard. If your organisation reports against a specific pillar set for governance or compliance purposes, confirm which provider's version you're actually using before assuming coverage.

This is a genuinely useful audit lens — a structured way to ask "have we actually thought about this dimension" — but it's a checklist for evaluating a design, not a substitute for the harder work of designing the account structure, identity model, and governance approach in the first place. In practice, we see teams reach for the Well-Architected Framework as a starting template before the landing zone underneath it is sound, which produces a well-reviewed workload sitting on a foundation nobody actually designed.

The Decision Points That Actually Matter

The important decisions are rarely about the latest product release. They concern identity, network boundaries, control ownership, cost allocation, and the shape of the support model — and they're considerably more expensive to change once workloads are live.

Identity and subscription structure

How many subscriptions (or accounts, or projects) will exist, who can create new ones, and what's the default isolation between environments and teams? This determines blast radius directly — a security or configuration mistake in one subscription should not be able to reach another by default. Microsoft's landing zone guidance treats identity and access management as a primary design area precisely because it functions as the main security boundary in the public cloud, not a secondary concern layered on afterward (Microsoft Learn).

Network boundaries

Where do trust boundaries actually sit? A flat network with everything reachable from everything else defeats much of the purpose of a carefully designed identity model, because network-level access ends up substituting for access control that should have been enforced at the identity layer instead.

Control ownership

For every guardrail — a tagging policy, a security control, a cost budget — someone needs to be the actual owner who maintains and enforces it. Controls without an owner decay; they either get silently bypassed or become friction nobody can explain or justify.

Cost allocation

Can the organisation actually attribute cloud spend back to the team or product that generated it? The FinOps Foundation's allocation capability frames this as requiring three deliberate strategies working together: an allocation strategy that maps costs to organisational units, a tagging strategy with consistent naming and metadata, and a shared-cost strategy for resources — like networking or a shared platform — that no single team fully owns (FinOps Foundation). Skip any one of the three and cost conversations become organisation-wide arguments instead of specific, actionable feedback to the team whose workload is driving the spend.

The support model

Who gets paged when something breaks at 2 a.m., and do they have the access and context to actually fix it? An elegant architecture that nobody operationally owns after go-live degrades quickly, regardless of how well it was designed on paper.

Trade-offs and Decision Guidance

Common Mistakes

• Copying a landing zone template built for a much larger organisation. Enterprise-scale management group hierarchies with dozens of specialized subscriptions make sense for large enterprises with dedicated platform teams; a five-person engineering team inheriting that structure spends more time navigating boundaries than building anything.
• Treating governance as a document rather than something enforced in tooling. A written policy nobody automates or checks against is aspirational, not operative.
• No clear owner for cost allocation. Teams that can't see their own cloud spend broken out by workload have no actionable way to respond to a cost conversation — it turns into a vague, organisation-wide debate instead of specific feedback.
• Designing the technical architecture before deciding the operating model. A well-designed set of services deployed without a clear support and ownership plan becomes an operational liability the moment it goes live, regardless of how sound the underlying design was.
• Auditing against a Well-Architected pillar set without first getting the landing zone right, or assuming the pillars are the same across providers. The pillars are a useful lens for evaluating a design, but they assume a reasonably sound subscription, identity, and governance foundation already exists underneath the workload being reviewed — and Azure's five don't map one-to-one onto AWS's or Google Cloud's six.

Cost, Complexity and Timeline

Standing up a landing zone using a provider's own automation — Azure's IaC Accelerator, or AWS Control Tower — is low-to-moderate effort for organisations willing to accept that provider's default best-practice structure; AWS's own documentation puts a basic Control Tower setup at under an hour, though real environments need additional configuration beyond that baseline (AWS documentation). Building a fully custom landing zone is significant effort, justified mainly when specific compliance, network, or organisational requirements the automated option doesn't accommodate are already known upfront. Retrofitting proper subscription and identity structure onto an existing, less-governed cloud environment is generally more effort than building it correctly from the start, since it usually involves migrating live workloads between subscriptions or re-architecting network boundaries under production constraints. Establishing cost allocation and control ownership is comparatively low technical effort but real organisational effort — the tagging and reporting mechanics are straightforward; getting teams to consistently apply tags and accept ownership of specific controls is the harder, ongoing part, which is why the FinOps Foundation treats allocation as a maturing discipline rather than a one-time setup task (FinOps Foundation).

How Halden Solutions Approaches This

We start architecture engagements by understanding the operating model a client actually has the capacity to run — team size, existing cloud maturity, regulatory exposure — before recommending a landing zone structure, rather than defaulting to the most comprehensive template available. For clients standardising on Microsoft's platform, that usually means starting from Azure's landing zone design areas and Verified Modules rather than a from-scratch build. Once the foundation — subscriptions, identity, governance guardrails — is sound, we use the relevant Well-Architected pillars as an audit lens on the resulting design, not as the starting point for the design itself. Throughout, we push toward making cost allocation and control ownership explicit and visible, since those are the decisions that most often determine whether a cloud environment stays maintainable a year after launch.

Frequently Asked Questions

Do we need a full landing zone if we're just starting in the cloud? Some foundational structure — at minimum, separating production from non-production environments and establishing basic identity and logging — is worth doing from the start, even at small scale, since retrofitting it later usually means migrating live workloads. The scale of the landing zone should match your team's actual maturity, not a template built for a much larger organisation.

Is there an Azure equivalent to AWS Control Tower? Not a direct one. Microsoft's own guidance is explicit that there's no single Azure service offering the same fully managed, one-hour setup Control Tower provides (Microsoft Learn). The closest option is the IaC Accelerator, built on reusable Azure Verified Modules — more setup work, more control over the result.

What's the difference between the Well-Architected Framework and a landing zone? A landing zone is the foundational subscription, identity, and governance structure a cloud environment is built on. A Well-Architected Framework is a set of quality pillars used to audit a design — including workloads built on top of a landing zone — against recognised best practices. They're complementary, not interchangeable — and the pillar count and names differ between Azure, AWS, and Google Cloud, so confirm which version applies to your reporting requirements.

Who should own cost allocation in a cloud environment? There's no universal answer, but the workload or team generating the spend needs enough visibility into their own costs to act on it — whether that's owned centrally by a platform/FinOps function or distributed to individual teams depends on organisational size and maturity. What matters is that ownership is explicit, and that a tagging and shared-cost strategy exists to make allocation possible in the first place.

Conclusion

Getting cloud architecture right starts with the foundation — a landing zone sized to your actual organisational maturity, built on Azure's Cloud Adoption Framework design areas if Microsoft's platform is your standard — and treats a Well-Architected Framework as an audit tool for the design, not a substitute for deciding identity boundaries, network structure, control ownership, cost allocation, and support model upfront. Those decisions, not which specific services get chosen along the way, are what determine whether the resulting environment stays maintainable.

If you're planning a new cloud foundation or reassessing an existing one that's become hard to operate, Halden Solutions' Cloud & Platform Engineering team can help align the design with how your organisation will actually run it.

Sources

• Microsoft Learn — "What is an Azure landing zone?" (Cloud Adoption Framework)
• Microsoft Learn — "Azure landing zone design areas"
• Microsoft Learn — "Platform landing zone implementation options"
• Microsoft Learn — "Microsoft Azure Well-Architected Framework" pillars
• AWS Prescriptive Guidance — "Landing zone" (definition and components)
• AWS Control Tower documentation — "What is AWS Control Tower?"
• AWS — "The pillars of the framework" (AWS Well-Architected Framework)
• Google Cloud documentation — "Landing zone design in Google Cloud"
• Google Cloud documentation — "Google Cloud Well-Architected Framework" pillars
• FinOps Foundation — "Allocation" framework capability