Cookie Preferences
We use cookies to enhance your experience, analyse site traffic, and support our marketing. You can customise your preferences or accept all cookies. See our Privacy & Cookie Policy for details.

Multi-Cloud Architecture

The Landing-Zone Decision Nobody Documents (and What It Costs Later)

Multi-Cloud Architecture

6 min read

Landing zones are usually designed under time pressure, by whoever is available in week one, and then never formally reviewed again. The decisions made in that first sprint — account structure, network topology, identity model — quietly become permanent.

This is the undocumented decision that costs the most later: not which cloud, but how the first twenty accounts were organised.

The decisions that calcify fastest

Account or subscription boundaries, the shared-services network hub, and the first identity federation pattern are the three elements almost impossible to restructure once a handful of workloads depend on them. Everything else — compute choice, deployment tooling, even provider — can be changed with effort. These three cannot without a genuine re-platform.

Yet these are typically decided fastest, often before a single production workload exists, because there is no workload yet to pressure-test the design against.

Document the decision, not just the outcome

An architecture decision record for the landing zone should state the alternatives considered, the constraint that ruled each one out, and the specific conditions under which the decision should be revisited. Most landing zones have none of this — only a Terraform repository with no narrative behind it.

This matters because the people who inherit the landing zone two years later cannot tell deliberate design from historical accident, and so they are afraid to touch any of it.

A lightweight review cadence that actually happens

Full landing-zone reviews are expensive and therefore get skipped. A better pattern is a 90-minute quarterly review against four fixed questions: has account sprawl outpaced the original design, does the network hub still match current traffic patterns, has identity federation grown organically past its original scope, and has any workload silently become 'too big to move' within this structure.

Answering 'yes' to any of these is not an emergency — it is simply the trigger to schedule a proper redesign conversation before the cost of doing so compounds further.

The most expensive architecture decisions are the ones made before anyone thought they were architecture decisions.MNB Cloud Practice

Key actions

  • Write an ADR for account structure, network hub and identity pattern
  • State the revisit trigger, not just the decision
  • Run a 90-minute quarterly structural review
  • Treat 'too big to move' workloads as a design alarm, not a compliment

Sources & further reading

  1. AWS Landing Zone guidance

Discuss this with an architect →