Multi-Cloud Architecture
Landing zones, network topology, and identity that hold up when the org chart changes.
§ 01 — Position
Most multi-cloud estates are not designed. They accumulate — an acquisition here, a team that preferred a different provider there, a workload that had to sit in a particular region for a particular regulator. By the time anyone draws the diagram, the diagram is a record of decisions rather than a plan.
The work is rarely to consolidate onto one provider. That argument is usually already lost, and often correctly. The work is to make a deliberately plural estate governable: consistent identity, predictable network paths, and a policy boundary that does not need rewiring every time the business reorganizes.
§ 02 — Method
- 01
Start with what is actually deployed
Not the target architecture, not the diagram in the wiki. An inventory of accounts, subscriptions, and projects; who can access what; and which controls are enforced versus documented. This step regularly surfaces the thing that changes the whole engagement.
- 02
Separate the policy boundary from the business boundary
Organizational units that mirror the current reporting structure need rewiring every time that structure changes. Units that mirror risk posture do not. This one decision determines how much of the design survives the next reorganization.
- 03
Design the onboarding path, not just the target
A landing zone that requires an architect to absorb a new estate will be bypassed at least once under time pressure. The path has to be documented and dull enough that a competent engineer can follow it.
- 04
Leave something operable
Reference architecture, infrastructure-as-code, and runbooks that a team can actually run. Documentation that describes intent as well as configuration, so the next person understands why rather than only what.
§ 03 — Deliverables
- Current-state assessment with findings ranked by consequence
- Target landing zone design across the providers in scope
- Network topology and cross-cloud connectivity design
- Identity federation and access model
- Terraform or equivalent IaC for the foundational layer
- Onboarding runbook for new accounts and acquired estates
- Architecture decision records for every significant choice
§ 04 — Fit
Best whenThe estate spans more than one provider and nobody can state with confidence what is enforced where.
Not forA single-provider greenfield build. The provider is better placed to help, and cheaper.
§ 05 — Field notes
- Multi-region does not mean redundancyA BigQuery dataset in the US multi-region lives in one of Iowa or Oregon. Not both. You bought quota, not resilience.
- Your data pilot is not temporaryThe word temporary, in an enterprise data platform, usually means permanent — but without the controls.
- Your failover depends on the thing that failedA financial services client found seventeen hidden dependencies on us-east-1 inside a payment system they had signed off as redundant.
§ 06 — Other practices
The estate spans more than one provider and nobody can state with confidence what is enforced where.
Start a conversation