The skills cost of running a second cloud
The largest cost of a second provider is the second body of knowledge, and it is the one that never appears in the business case. Cloud competence is mostly memory: which service limit bites first, what a particular error message really means, which failure looks like a network problem and is actually a permission problem. That memory takes a year or two to build, does not transfer between platforms, and decays when it is not used. A team can learn a second provider. What it cannot do is be as good at two as it was at one, on the same headcount.
What does competence on a cloud platform actually consist of?
Knowledge of failure, mostly, which is why certifications and competence are only loosely related. A certification demonstrates that someone knows what the services do. Operating a platform requires knowing what they do when they are stressed, misconfigured or hitting a quota, and that knowledge is accumulated from incidents rather than from courses.
The specific items look small individually and are decisive collectively. Which quotas are soft and which are hard, and how long an increase takes to be approved. Which errors are eventually consistent and will resolve on their own. What an access denial actually means when the policy looks correct, which is usually a different service's condition. Which managed service behaves badly during a maintenance window. How the billing data is structured, so a cost anomaly can be traced to a change.
None of that transfers. An engineer with four years on one provider starts near the beginning on another, and the risk is that neither they nor their manager recognises it, because the concepts map so cleanly that competence feels transferable. Concepts transfer. Reflexes do not, and incidents are handled with reflexes.
What does a second platform do to on-call?
It roughly doubles the surface a responder must hold in their head, without doubling the number of people who can respond. That is the mechanism behind slower resolution in multi-cloud estates: the responder is competent on one side and reading documentation on the other, and the first minutes of an incident are spent establishing which side is at fault.
The cross-provider dependency makes it worse than two separate rotations would be. A failure in a system spanning both platforms presents ambiguously, and the honest diagnosis requires someone who understands the interconnect, the identity federation and both application environments. Organisations that split the rotation by provider discover that their most common incidents require both rotations awake, which is not a rota but a conference call.
The practical minimum is uncomfortable to state. For any platform carrying production traffic you want at least three people who could lead an incident on it unaided, so that holidays, illness and departures do not leave a single point of failure. Two platforms means two such groups, and if the same three people cover both, they are on call permanently for twice the surface, which is the arrangement that produces the resignations.
Which knowledge transfers and which does not?
Architecture transfers, operations do not. Someone who understands distributed systems, network design and identity in the abstract will make good decisions on any platform. Someone diagnosing a production fault needs the specific, and the specific is what took years to acquire.
| Area | What competence means in practice | Transfers to another provider? |
|---|---|---|
| Architecture and design patterns | Choosing the right shape for a workload | Yes, almost entirely |
| Service selection | Knowing which managed service fits and which disappoints | Partly, names map but behaviour differs |
| Identity and permissions | Diagnosing why access is denied when policy looks right | No, evaluation models differ |
| Networking | Address planning, routing, private access paths | Concepts yes, implementation no |
| Quotas and service limits | Knowing which limit bites first and how to raise it | No, and it is learned from outages |
| Cost management | Tracing an anomaly through the billing data | No, structures and granularity differ |
| Incident response | Knowing where to look in the first five minutes | No, this is the expensive one |
What happens to hiring?
The candidate pool narrows sharply if you insist on depth in both platforms, and the people who genuinely have it are expensive and in demand. The workable approach is to hire strong engineers with depth in one and fund the time to build the second, which is a real cost measured in months of reduced output rather than in a training budget.
The failure mode to watch for is the single expert. Multi-cloud estates commonly end up with one person who understands the second provider, because that person built it. Everything on that side routes through them, they cannot take a holiday during a release, and their departure converts a working platform into an unmaintained one. This is the most predictable and most ignored risk in the whole pattern.
Retention has a specific shape here too. Engineers generally want depth, and being spread across two platforms with no time to master either is a recognised reason people leave. If the second provider carries a small workload, the people who work on it are doing occasional work in an unfamiliar environment, which is both the least enjoyable arrangement and the least safe.
Does a managed partner remove the problem?
It moves it and it does not remove it. A partner can genuinely own the platform layer on a provider you do not want to staff: the landing zone, patching, monitoring configuration, cost reporting and first-line response. That is a legitimate way to run a small forced footprint, and it is usually cheaper than hiring three people to cover a rotation for one workload.
What cannot be outsourced is the boundary. When a system spans both providers, the failure is often in the interaction, and no external party has visibility of both sides of your architecture unless you have given it to them. You still need someone internally who understands how the estates connect, how identity flows and what the application depends on, which means the internal capability shrinks rather than disappearing.
Test any arrangement against a specific scenario before signing it. Ask exactly who does what when a workload on the second provider is failing and the cause is ambiguous: who is paged, who has permission to change what, how the handover works, and what happens if the partner concludes the fault is on your side. A contract that cannot answer that clearly is a support agreement rather than an operating model.
How do you size this honestly?
Name the people. Write down who could lead a serious incident on the second provider without help, at three in the morning, without the person who built it. If you cannot name at least two, you do not have the capability yet, whatever the architecture diagram says, and the gap is the real cost of the decision.
Then run the same test operationally rather than on paper. Pick a quiet week, make the person who built the second platform unavailable for it, and have the rest of the team handle a planned change or a game day exercise there. What the exercise reveals is usually not missing knowledge but missing documentation: undocumented conventions, access nobody else has, and steps that exist only in one person's habits.
Budget the ramp explicitly when the decision is made. A reasonable planning assumption is that reaching genuine operational competence on a second platform takes a team the better part of a year of real usage, not a training course, and that maintaining it requires enough ongoing work there to keep the knowledge alive. If the second provider will carry one small workload, plan for a partner or plan for the knowledge to decay, because those are the two honest options.
Common questions
- Do cloud skills transfer between AWS, Azure and Google Cloud?
- Architecture and design knowledge transfers almost entirely. Operational knowledge does not. Identity evaluation models differ, quotas and service limits differ and are learned from outages, networking implementation differs beneath similar concepts, billing structures differ, and incident reflexes are entirely platform-specific. An engineer with years on one provider starts near the beginning on another, and the risk is that this goes unrecognised because the concepts map so cleanly.
- How many engineers do you need to run a second cloud provider?
- Enough that at least three people could lead an incident on that platform unaided, so holidays, illness and departures do not create a single point of failure. If the same three people cover both platforms, they are effectively on call permanently for double the surface. Where the second provider carries only one small workload, a managed partner for the platform layer is usually cheaper than staffing a rotation for it.
- Why do multi-cloud incidents take longer to resolve?
- Because the first minutes go on establishing which side is at fault, and the responder is typically fluent on one platform and reading documentation on the other. Failures in systems spanning both providers present ambiguously and need someone who understands the interconnect, the identity federation and both application environments. Splitting the rotation by provider does not help, since the common incidents require both groups awake.
- Can a managed service provider run our second cloud for us?
- It can own the platform layer: landing zone, patching, monitoring configuration, cost reporting and first-line response, which is a reasonable way to run a small forced footprint. It cannot own the boundary between the estates, where failures often occur, because no external party sees both sides of your architecture. Before signing, establish exactly who is paged, who may change what, and what happens when the partner concludes the fault is yours.
- How long does it take a team to become competent on a new cloud?
- Plan for the better part of a year of real usage rather than a training course, because the knowledge that matters is accumulated from incidents: which quotas bite first, which errors resolve themselves, what an access denial really means, how billing data is structured. Maintaining that competence needs enough ongoing work on the platform to keep it alive, which is why a second provider carrying one small workload tends to leave knowledge decaying.
