Outcome and driver mapping
A short document naming the real drivers behind the multi-cloud ambition, separating regulatory or commercial requirements from preferences that would not survive a cost review.
Infrastructure & Cloud
Multi-Cloud & Hybrid Strategy
A costed answer on multi-cloud, including the answer that you do not need it.
The work
What this actually does
Multi-cloud is a strategy question before it is a technical one. We start by asking which specific outcomes you need — regulatory separation, negotiating position, a genuine capability only one provider has, or simply avoiding a single point of failure — and then cost each of them honestly against the operational overhead of running two estates.
When the case holds, we design the smallest amount of duplication that delivers it: shared identity, consistent networking and a deployment model that does not require rewriting every service. When it does not, you get a written recommendation to stay on one provider, with the triggers that would change that advice later.
If any of these sound familiar
- Two clouds are running and nobody can say what the second one bought
- Engineers maintain parallel tooling and neither side is well supported
- Data residency commitments cannot be met with the current region layout
- Failover to the second provider has never actually been tested
Scope
What's included
Every engagement on this page covers the following, sized to your setup rather than delivered as a fixed package. If something here is not relevant to you, it comes off the scope and off the price.
Placement assessment
Each workload scored for where it belongs, based on data gravity, latency, licence portability and the cost of running it twice, with a recommended home for each one.
Cross-cloud identity
One directory driving access in both providers, with federated roles and no second set of long-lived credentials to rotate, review or lose track of.
Interconnect and DNS
Private connectivity, routing and DNS designed so the two estates can talk without the public internet, including the failure modes when a link degrades rather than drops cleanly.
Portability and abstraction
Where portability is worth its cost we use Kubernetes, Terraform and open formats; where it is not, we use managed services deliberately and record the exit cost rather than pretending none exists.
Operating model
Who owns which cloud, how on-call works across both, how incidents escalate when the problem spans providers, and what the escalation looks like with two vendor support contracts.
What changes
What teams typically see
1 decisionWritten and costed
2Clouds only where justified
1 directoryIdentity across providers
Handover
What you keep
Everything produced during the engagement is yours: the repositories, the accounts, the documentation. There is no proprietary layer and nothing to unlicense if you take the work in-house.
- Written recommendation on whether to go multi-cloud
- Workload placement map with cost and latency notes
- Cross-cloud identity and network design document
- Portability assessment listing abstraction and exit costs
- Hybrid connectivity runbook covering degraded links
Tooling
Tools we use here
A starting point, not a requirement. We work in whatever you already run wherever it does the job.
AWS
Microsoft Azure
Google Cloud
Kubernetes
Terraform
Istio
HashiCorp Vault
Cloudflare
How it runs
From first call to handover
The same four steps on every engagement. You see each one before it starts and can stop at any of them.
- 01
Interview the stakeholders
We talk to the people who asked for multi-cloud and the people who will operate it, because the gap between those two answers is usually the whole problem.
- 02
Cost the options
Three or four plausible end states are priced over three years, including egress, support duplication, tooling and the engineering time that never appears on a cloud bill.
- 03
Design the minimum viable version
For a go decision we scope the smallest footprint that satisfies the driver, rather than starting with two full estates and a shared control plane.
- 04
Prove it on one workload
One service runs in both places for a month, including a real failover exercise, so the operating cost and the on-call reality are measured rather than estimated.
Questions
Asked before we start
Are you going to tell us multi-cloud is a bad idea?
If that is what the numbers say, yes. Plenty of multi-cloud programmes are driven by a fear of lock-in that a documented exit plan would address at a fraction of the cost. We would rather keep one provider well run.
What does active-active really cost?
More than most estimates. Two regions means duplication in networking, monitoring, security tooling and the people who understand both, plus a data strategy that survives the link between them failing. We price that explicitly before anyone commits.
Can we keep our on-premises data centre in the mix?
Yes. Hybrid is often the practical answer, especially where latency, data volume or regulation keeps a workload on site. We design the connectivity and identity so on-premises looks like another region rather than a separate world.
How long before we see any benefit?
If the driver is regulatory or contractual, the benefit is compliance, and design work can take six to twelve weeks. If the driver is resilience, expect several months before failover is genuinely trustworthy and regularly exercised.
Infrastructure & Cloud
Often needed alongside this
Infrastructure & Cloud
Cloud Architecture & Migration
Well-architected landing zones and migrations that move workloads without moving your risk profile.
- AWS, Azure and Google Cloud landing zones
- Lift-and-shift, replatform and re-architect paths
- Network, IAM and multi-account structure design
Networking & Data
Networking, Ingress & Service Mesh
Traffic that reaches the right service, stays encrypted in transit, and fails over without dropping connections.
- Load balancers, ingress and API gateways
- Istio and Cilium service mesh, mTLS by default
- Traffic shifting for canary and blue/green rollout
Optimisation & Advisory
Cloud Cost Optimisation (FinOps)
Find the 30% of your bill nobody can justify, then keep it gone with budgets and guardrails.
- Spend visibility, tagging and chargeback
- Rightsizing, savings plans and spot strategy
- Automated anomaly alerts and budget guardrails
Worth a conversation about Multi-Cloud & Hybrid Strategy?
Bring the specific problem. We will tell you honestly whether this is the service that fixes it, and what it would take.