Cloud Platform Engineering · Chapter 8 of 9
Frameworks, the market, and what is actually in demand
Which parts of the well-architected reviews are worth your time, what the share numbers really measure, and the honest read on certifications.
This chapter is about the meta-layer: the frameworks vendors want you to run, the market numbers people quote, and the credentials people buy. All three are useful and all three are routinely reported without the caveats that make them meaningful.
The well-architected frameworks
| Pillars | Notable | |
|---|---|---|
| AWS Well-Architected | Six, including sustainability | States explicitly that a review 'is not an audit mechanism'. Domain-specific lenses extend the question bank |
| Azure Well-Architected | Five — no sustainability pillar | Publishes a Tradeoffs page per pillar, which is the single best piece of architecture writing any of the three produce |
| Google Cloud Well-Architected | Six, plus two cross-cutting perspectives (AI/ML and financial services) | Five terse design principles: design for change, document the architecture, simplify through managed services, decouple, prefer stateless |
Which parts are worth your time, honestly
Genuinely useful. The tradeoffs pages on Azure's framework are the best thing in the category, because they say explicitly what each pillar's recommendations cost you in the others — which is the actual architecture conversation, and which almost no vendor content admits to. Read them regardless of which cloud you are on; they are cloud-agnostic in substance.
The reliability and security question banks are strong forcing functions. Teams routinely discover they have no tested restore path, no defined recovery objectives, and no break-glass account — precisely because a question asked and nobody could answer.
Closer to a sales motion. The cost pillars are, in every framework, noticeably thinner and more generic than the others — and the automated tooling behind them surfaces what the provider can cheaply detect, which skews toward ‘buy more commitments’ and ‘enable more replicas’ at least as often as toward ‘delete this’. One provider also pays partners per completed review, which makes review volume a partner objective rather than a customer outcome.
The practical recommendation: run the reliability and security pillars seriously, with the workload team in the room and a written remediation backlog. Treat the score as meaningless and the risk list as the deliverable. Do your cost work with your own tooling.
Market share, and what the numbers actually measure
The most-quoted figures come from a single research firm's quarterly estimate of ‘cloud infrastructure services’ spend. As of mid-2026 that put the quarter at roughly $143 billion, growing 43% year on year — the highest growth rate in eight years — with the three largest providers at approximately 28%, 20% and 15% share.
Three caveats that should always travel with those numbers.
The category is the firm's own definition and bundles infrastructure, platform and hosted private cloud. It is not infrastructure-as-a-service share and it is not comparable to another analyst's figures for what sounds like the same thing.
None of the providers disclose a segment that maps to it. One in particular reports a business unit containing far more than its cloud platform, so its share is an estimate rather than a disclosure.
And the structurally interesting fact is not the ordering, which has barely moved in three years. It is that generative-AI services grew around 165% year on year and that nine specialist accelerated-compute providers now sit in the top forty. The competitive question in 2026 is GPU capacity, not general-purpose compute — and a candidate who says that, rather than reciting the three percentages, is describing the market as it is.
A useful counterpoint comes from developer surveys, where usage looks quite different: roughly 43% of developers report using the largest provider, about 26% the second, about 25% the third — and around 20% report using an edge-and-workers provider that appears nowhere in the revenue rankings.
The gap between those two views is instructive rather than contradictory. Revenue share is enterprise-weighted; developer surveys are self-selected and skew toward individuals and startups. One provider under-indexes on developer surveys precisely because its strength is enterprise, and the edge provider over-indexes because it is chosen by individuals for small workloads that generate little revenue and a great deal of goodwill. Both numbers are correct and they answer different questions.
Certifications, read honestly
Published tables of ‘highest-paying certifications’ put cloud security specialisations at the top, with reported averages around two hundred thousand dollars in North America.
Be clear with yourself about what that data is. It is self-reported by people who chose to complete a vendor's survey, and it is massively confounded by seniority: the people holding an advanced security specialisation are senior security engineers who would be paid similarly without it. The certification is a correlate of the role, not a cause of the salary. Any advice implying ‘get this credential, earn that figure’ is misleading, and recognising that is itself a signal of judgement.
A more useful framing is which credentials carry screening weight:
- The associate-level architect certification on the largest cloud functions as a résumé filter more than a skills signal. It is cheap, it is ubiquitous, and its absence is noticed more than its presence is rewarded.
- The hands-on Kubernetes certifications are the ones hiring managers treat as genuinely informative, because they are practical, timed, and cannot be passed by memorising question banks. The security variant in particular is a real differentiator for platform-security roles.
- The infrastructure-as-code associate certification is a low-cost credibility marker mapping to a skill that appears in nearly every posting.
- The security specialisations across all three clouds have the clearest role-specific value.
- And one market effect worth naming: the third-largest cloud's certifications carry less screening weight simply because fewer employers run it. That is a market-size effect rather than a quality judgement, and it should affect which one you invest in if your goal is employability rather than knowledge.
What actually appears in postings
There is no rigorous public dataset for this — the available analyses are marketing content with undisclosed methodology, and it is worth saying so rather than quoting a percentage. What can be said with confidence is the shape:
| Tier | What it contains |
|---|---|
| Baseline — expected, not differentiating | The cloud's identity system, its network primitives, managed Kubernetes, object storage, a managed relational database, and its observability stack. Also containers generally, which moved from a skill to an assumption |
| Differentiators | Infrastructure as code, GitOps, OpenTelemetry, policy-as-code, node autoprovisioning, secrets management, and supply-chain security |
| Rising fastest in 2026 | GPU scheduling and accelerator capacity management, cost attribution for AI workloads, and platform-as-a-product framing — internal portals and golden paths |
| Declining as a differentiator | Individual configuration-management tools, and expertise in one specific CI system |
The row worth acting on is the third. Industry survey data shows the share of practitioners actively managing AI costs going from roughly a third to essentially universal in two years, and accelerator scheduling is the scarcest genuine skill in platform engineering right now. If you want one area to be deliberately strong in, that is it — the supply of people who can reason about GPU utilisation, fractional allocation, queueing and per-inference cost is far smaller than the demand.
How to prepare for a cloud interview
- Know one cloud deeply and the others structurally. Nobody expects three-cloud expertise, and everybody expects you to know that the identity models differ and how.
- Be able to do arithmetic out loud. Egress per gigabyte times volume, commitment break-even, pods per node from the interface limits. This is the single most differentiating behaviour in these interviews and very few candidates do it.
- Have a cost story. Something you reduced, with the mechanism and the number. Even a small one is more convincing than a large architecture you did not measure.
- Have a failure story with a control-plane flavour — an address exhaustion, a forced upgrade, an identity escalation, a bill that tripled. These are the problems the job actually contains.
- And know what you would not build. The most common weakness in cloud-architecture interviews is over-building: a multi-region active-active design for a workload with a four-hour recovery objective. Saying ‘this does not need that, and here is what it does need’ is the senior answer.
Check yourself