Use when choosing a cloud model or provider, or reasoning about the basic building blocks: IaaS, PaaS and SaaS, the deployment models, the five NIST characteristics, the provider landscape (AWS, Azure, Google Cloud and the second tier) and how to choose between them, and the primitives — compute, storage classes, networking and VPCs, and identity and IAM. Includes the router for the whole cloud-computing reference.
Scanned 9/19/2026
npx -y skills add the-vibey-project/vibey --skill cloud-models-providers-and-primitives --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Cloud Models Providers And Primitives?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/the-vibey-project-cloud-models-providers-and-primitives)More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.
---
name: cloud-models-providers-and-primitives
description: "Use when choosing a cloud model or provider, or reasoning about the basic building blocks: IaaS, PaaS and SaaS, the deployment models, the five NIST characteristics, the provider landscape (AWS, Azure, Google Cloud and the second tier) and how to choose between them, and the primitives — compute, storage classes, networking and VPCs, and identity and IAM. Includes the router for the whole cloud-computing reference."
---
# Cloud Computing: Models, the Provider Landscape, and the Primitives
> **Part 1 of 5** of the *Cloud Computing* reference (plugin `cloud-computing`), covering §0–§3. Sibling skills: `cloud-architecture-and-resilience` (§4–§6), `cloud-cost-security-and-operations` (§7–§9), `cloud-migration-sovereignty-and-ai-workloads` (§10–§14), `cloud-reference` (§15–§20). Section numbers are shared across the set; a reference written as §N → `skill` points into that sibling skill.
>
> **Currency:** Verified August 2026. See §17 → `cloud-reference` for the currency snapshot and what goes stale first.
> **How to read this.** Reference, not a certification guide. Three markers:
> - **[DURABLE]** — architectural principles and trade-offs that survive provider churn.
> - **[VERSIONED]** — market data, pricing, service names, regulation. **Verify before
> quoting.**
> - **[CONTESTED]** — genuine disagreement.
>
> **⚠️ GOTCHA** boxes mark the mistakes that produce outages or surprise invoices.
>
> **Provider-neutral by default**, with AWS/Azure/GCP names where the concept needs an
> anchor. Service names change; the primitives don't.
>
> **The three framings that organize everything below:**
> 1. **The cloud is someone else's computer, rented, with an API and a metered bill.**
> Every genuine advantage (elasticity, global reach, managed services, capex→opex) and
> every genuine failure mode (cost surprise, lock-in, shared fate, opaque outages)
> follows from that one sentence.
> 2. **⚠️ Your failure domain is always larger than your architecture diagram says.**
> The 2025 outages taught this expensively: multi-AZ deployments failed because of
> control-plane dependencies nobody had drawn (§6 → `cloud-architecture-and-resilience`). **Map what you actually depend on,
> not what you think you depend on.**
> 3. **Cost is an architectural property, not an operational afterthought.** It is
> determined by design decisions — data placement, service selection, egress paths —
> and **discovered on an invoice 30 days later** (§7 → `cloud-cost-security-and-operations`). Design for it up front or pay
> for it forever.
---
## §0. Routing
| Asked about... | Go to |
|---|---|
| Service and deployment models | §1 |
| Which provider, and market reality | §2 |
| Compute, storage, networking, identity | §3 |
| Architecture and Well-Architected | §4 → `cloud-architecture-and-resilience` |
| Containers, Kubernetes, serverless | §5 → `cloud-architecture-and-resilience` |
| **Resilience, and the 2025 outage lessons** | **§6 → `cloud-architecture-and-resilience`** |
| **Cost engineering and FinOps** | **§7 → `cloud-cost-security-and-operations`** |
| Security and shared responsibility | §8 → `cloud-cost-security-and-operations` |
| Operations and observability | §9 → `cloud-cost-security-and-operations` |
| Migration strategy | §10 → `cloud-migration-sovereignty-and-ai-workloads` |
| **Sovereignty, the EU Data Act, egress** | **§11 → `cloud-migration-sovereignty-and-ai-workloads`** |
| Multi-cloud and lock-in | §12 → `cloud-migration-sovereignty-and-ai-workloads` |
| AI workloads and their economics | §13 → `cloud-migration-sovereignty-and-ai-workloads` |
| Sustainability | §14 → `cloud-migration-sovereignty-and-ai-workloads` |
| "Don't do this" | §15 → `cloud-reference` |
| "Which side is right?" | §16 → `cloud-reference` |
| "Is this still current?" | §17 → `cloud-reference` |
| Books and resources | §18 → `cloud-reference` |
---
## §1. Models
### 1.1 Service models
```
On-prem → IaaS → CaaS → PaaS → FaaS → SaaS
◄─────────── you manage more you manage less ───────────►
◄─────────── more control less operational burden ───►
◄─────────── more lock-in risk? ⚠️ see §12 — it's not that simple
```
**[DURABLE] The trade-off is real in both directions**, and the common mistake is
optimizing only one end. Managed services cost more per unit and less in engineering time;
raw IaaS is cheaper per unit and you pay for it in people. **⚠️ The comparison people skip
is the fully-loaded one** — a managed database's premium is frequently less than one
engineer's fraction of time keeping a self-hosted one patched, backed up, and monitored.
### 1.2 Deployment models
**Public**, **private**, **hybrid** (⚠️ **the actual state of most large enterprises**,
whatever the strategy deck says), **multi-cloud** (§12 → `cloud-migration-sovereignty-and-ai-workloads`), and **edge**. **Sovereign cloud**
is now a distinct category with regulatory meaning rather than a marketing label (§11 → `cloud-migration-sovereignty-and-ai-workloads`).
### 1.3 The five NIST characteristics
On-demand self-service, broad network access, resource pooling, rapid elasticity,
measured service. **[DURABLE] Dated 2011 and still the cleanest definition** — and
"measured service" is the one that quietly determines your architecture (§7 → `cloud-cost-security-and-operations`).
---
## §2. The Provider Landscape
**[VERSIONED — and read the ⚠️ in this section before quoting any number.]**
**Market structure as of Q1 2026**: the Big Three hold roughly **60–68%** of global cloud
infrastructure spend, with the market reaching **~$129B in Q1 2026, growing ~35% YoY** —
described as the **ninth consecutive quarter of increasing year-over-year growth**.
> **⚠️ GOTCHA — the share figures genuinely conflict across sources, and you should know
> why before citing them.** Synergy Research puts Q1 2026 at **AWS 28%, Azure 21%, Google
> Cloud 14%**. Other widely-circulated figures give **AWS 30% / Azure 24–25% / GCP 13%**,
> and others still **AWS 32% / Azure 23% / GCP 11%**.
>
> **The discrepancy is methodological, not an error.** One analysis explains it directly:
> Azure's higher share estimates **exceed a straight revenue calculation because Synergy
> weights IaaS-and-PaaS spend, where Azure is stronger** — and separately, **Microsoft
> does not break out Azure revenue at all, only its growth rate**, so any "Azure revenue"
> figure is derived. **Both kinds of figure are valid; they measure different scopes.**
> **Cite the source and the scope, or don't cite the number.**
**Growth is the more interesting story than share**: Azure and Google Cloud have been
growing substantially faster off smaller bases, with Google Cloud posting the highest rates
of the three. **AI is the driver** — AI-related spending was reported at **~19% of total
cloud spend in 2026, up from ~8% in 2023.**
**⚠️ The capex arms race is the structural fact underneath all of it.** 2026 guidance
figures in circulation: **Amazon ~$200B, Microsoft ~$190B, Alphabet ~$180–190B.** This
functions as a moat — the cost of building global infrastructure excludes almost everyone
— and it carries genuine risk: **the Big Three are betting hundreds of billions that AI
demand will justify the build-out, and if it disappoints the write-downs would be
enormous.** For a buyer, large capex commitments are **both a supply signal and a
lock-in signal.**
**Choosing** — the honest criteria, roughly in order: **existing skills and contracts**
(⚠️ **usually decisive and rarely stated**), **the specific services you need**,
**regional and data-residency footprint** (§11 → `cloud-migration-sovereignty-and-ai-workloads`), **pricing for your actual shape of
workload**, **enterprise agreements and discounts**, and **regulatory posture**.
**Beyond the Big Three**: Oracle Cloud, IBM, Alibaba, and the **"neoclouds"** — GPU-focused
providers (CoreWeave, Lambda and others) estimated collectively at a small but real share
segment. **Cloudflare, Fastly, Vercel, Fly.io** for edge; **DigitalOcean, Hetzner,
Scaleway** for straightforward compute at markedly lower prices.
---
## §3. The Primitives
**[DURABLE] Every provider has these under different names. Learn the primitive, map the
name.**
**Compute**: VMs (⚠️ **still the majority of cloud spend**), containers (§5 → `cloud-architecture-and-resilience`), serverless
functions, GPU/accelerator instances (§13 → `cloud-migration-sovereignty-and-ai-workloads`), bare metal. **Pricing modes matter more than
instance choice**: on-demand, reserved/committed (1–3 year, **large discounts**), savings
plans, **spot/preemptible** (⚠️ **60–90% cheaper and interruptible — enormously underused
for batch, CI, and fault-tolerant work**), dedicated hosts.
**Storage**, and **⚠️ picking the wrong class is one of the most common cost errors**:
| Type | Use | ⚠️ Watch |
|---|---|---|
| **Object** (S3, Blob, GCS) | The default for almost everything: static assets, data lakes, backups | Request costs at high volume; egress (§11 → `cloud-migration-sovereignty-and-ai-workloads`) |
| **Block** (EBS, Managed Disks) | Filesystem for a VM | ⚠️ **Provisioned, not consumed — you pay for the size you asked for, idle or not** |
| **File** (EFS, Azure Files) | Shared POSIX access | Expensive per GB |
| **Archive** (Glacier, Archive tier) | Long-term retention | ⚠️ **Retrieval time and retrieval cost — and early-deletion fees** |
**⚠️ Lifecycle policies are free money and routinely unconfigured.** Object storage tiering
from hot → cool → archive on an age rule takes minutes to set and runs forever.
**Networking**: VPC/VNet, subnets, security groups/NSGs, load balancers (L4 and L7),
DNS, CDN, private endpoints, peering, transit gateway/hub-spoke, NAT gateways
(⚠️ **a surprisingly large and invisible line item at volume**).
**Identity** — **[DURABLE] the most important primitive and the most commonly
misconfigured** (§8 → `cloud-cost-security-and-operations`): workload identity (⚠️ **use it — long-lived access keys are the
single most common cloud breach vector**), roles and policies, federation, and
**least privilege as an actual practice rather than an aspiration**.
**Managed data services**: relational, NoSQL, cache, search, queues and streams, data
warehouse. **⚠️ Each is a lock-in decision as well as an architecture decision** (§12 → `cloud-migration-sovereignty-and-ai-workloads`).
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!