---
title: "CloudOps"
slug: cloudops
category: cloud
term_status: emerging
evidence_status: verified
summary: "CloudOps (cloud operations) is running workloads on public cloud through the provider's control plane: account hierarchy, guardrails, quotas, Regions, provider signals and managed-service change. The label is common, but no neutral body defines it."
audience: [Cloud and platform engineers, Cloud centre-of-excellence teams, Architects, Engineering leaders, Beginners]
last_verified: 2026-10-17
key_takeaways:
  - "CloudOps is a common job and team label without a vendor-neutral definition. AWS renamed its SysOps Administrator certification to CloudOps Engineer in 2025, and published definitions range from ITOps applied to cloud architecture to frameworks that include software delivery."
  - "This page's emphasis is the provider control plane as the operating surface: organisation hierarchy, guardrails, quotas, Regions, provider signals and managed-service change."
  - "AWS's guidance is that control planes are statistically more likely to fail than data planes. The shorter a service's recovery time objective, the fewer create, change or delete steps its recovery may contain; for the most critical services, none (static stability)."
  - "Quotas belong to an account, subscription or project and usually a Region. A capacity error is not a quota error, and neither is API throttling. Forecast quotas before peak, not during it."
  - "A guardrail needs an owner, an exception path and a measurement. Region allow-lists and tag rules each have documented blind spots, such as global resources and untagged resources missing from reports."
  - "Multi-cloud adds a second control plane to operate. Choose it for exit, regulation or a specific capability, not as a reflex after an outage."
related: [infraops, finops, cloudsecops, iamops, platformops, kubernetesops, serverlessops, sysops, noops, disasterrecoveryops]
---

## What CloudOps is

### In 30 seconds

**CloudOps** (cloud operations) keeps workloads on public cloud governed, observable and able to scale by operating what the
provider exposes: the organisation hierarchy, accounts (Azure: subscriptions; Google: projects), policies, quotas, Regions, and the
provider's health and change signals. The provider runs the data centres; everything you configure through its APIs is yours.

**In one line: CloudOps runs your estate through the provider's control plane, and designs the estate so that workloads keep
serving when that control plane is impaired.**

**For** cloud and platform engineers, cloud centre-of-excellence teams, architects and leaders. Facts checked 2026-10-16 and 2026-10-17 (dates per footnote).

::: note Term status and this page's emphasis
Published definitions differ in breadth. TechTarget's list of CloudOps responsibilities includes cost, cybersecurity, disaster
recovery, compliance and ITIL service management.[^tt] IBM calls CloudOps "a framework that combines tools and best practices for
managing, delivering and optimizing cloud-based IT services and workloads" and includes software delivery.[^ibm] Red Hat notes
that "Some define CloudOps as ITOps (IT operations) applied to cloud architecture, while others consider it to be a blend of ITOps,
cloud computing, and DevOps".[^redhat] This Atlas gives cost, security, infrastructure as code and the runtime layers their own
pages, and centres CloudOps on the provider control plane. That split is an **editorial distinction**, not an industry standard.
:::

### At a glance

| Item | Summary |
|---|---|
| Term status | **Emerging.** Definitions still settling; no standards body or neutral certification. AWS's 2025 certification rename, "to reflect the evolving nature of cloud operations and a shift in industry terminology",[^soa] is a vendor signal, not a standard. |
| Goals | Accounts created the same way every time; guardrails that hold; no outage caused by a quota, an unread provider notice or a Region assumption. |
| In scope | Shared responsibility, well-architected reviews, landing zones and vending, network foundations, guardrails (Regions, tags, budget alerts), quotas, provider signals, native monitoring, managed-service change, multi-Region, hybrid and multi-cloud trade-offs. |
| Out of scope | Cost decisions → [FinOps](../finops/); security guardrails and posture → [CloudSecOps](../cloudsecops/); writing and evaluating policy → [IAMOps](../iamops/); writing infrastructure as code → [InfraOps](../infraops/); running networks → [NetOps](../netops/); clusters → [KubernetesOps](../kubernetesops/); functions → [ServerlessOps](../serverlessops/); the host OS → [SysOps](../sysops/). |
| Prerequisites | Delivery basics ([DevOps](../devops/)); the console and CLI of one provider. |
| Key outputs | A versioned estate design, a guardrail set with exceptions, an account-vending pipeline, a quota register with forecasts, routed provider signals, Region decision records, game-day evidence. |

### The problem it solves

Without deliberate cloud operations an estate drifts, and recovery plans come to need the provider's APIs just when they fail.

DORA names the gap: where developers raise tickets and wait days for environments, "although the organization may pay for a cloud
service, they don't have a cloud by NIST's definition". In DORA's 2019 report only 29% of respondents who claimed to have adopted
cloud agreed or strongly agreed that they met all five of NIST's essential characteristics.[^dora-flex] CloudOps delivers NIST's
self-service and elasticity[^nist] without losing control of the estate.

| Operating reality | Without CloudOps | With CloudOps |
|---|---|---|
| New account | A ticket, days of waiting, a hand-built baseline | Vended from a request in hours, with a recorded baseline version |
| Region use | Wherever someone clicked | An allow-list with time-limited exceptions |
| Quotas | Discovered when a launch fails | Forecast and raised ahead of demand |
| Provider notices | A shared mailbox | Routed to an owner, with a deadline |
| Provider control plane impaired | Recovery needs new resources | Critical services recover without creating anything |

### What CloudOps is not

- **Not the AWS certification.** The exam tests AWS skills;[^soa] the practice spans providers and organisations.
- **Not SysOps renamed.** Host operations (processes, logs, patching a VM) remain [SysOps](../sysops/) territory.
- **Not lift-and-shift ITOps.** The operating surface is an API with quotas and policies, not a rack; ITIL practices live in
  [ITOps](../itops/).
- **Not a synonym for DevOps.** TechTarget calls CloudOps "often considered a subset or part of DevOps".[^tt] This Atlas treats
  [DevOps](../devops/) as the delivery system and CloudOps as the estate it delivers into.
- **Not the HPE product.** HPE bundled Morpheus, OpsRamp and Zerto "as the HPE CloudOps Software suite" in 2025.[^hpe]

## Where CloudOps comes from and where it sits

### Origins and evolution

No founding document exists; the label grew out of job titles. Verifiable milestones:

| Year | Milestone | What it shows |
|---|---|---|
| 2011 | NIST SP 800-145 defines cloud computing: "five essential characteristics, three service models, and four deployment models"[^nist] | The shared vocabulary |
| 2021–2022 | Estate-level guidance: AWS's multi-account whitepaper (first published March 2021) and fault isolation boundaries (November 2022); Azure and Google landing-zone guides (current editions cited)[^aws-multi][^fib-cp][^az-lz][^gcp-lz] | The estate becomes the unit of operations |
| 2025 | AWS SOA-C03 "CloudOps Engineer – Associate" (first exam day 30 September 2025); HPE launches a "CloudOps" product suite[^soa-dates][^hpe] | The label spreads, and collides |

### Glossary and mental model

| Term | Meaning on this page |
|---|---|
| **Control plane / data plane** | The control plane provides "administrative APIs used to create, read/describe, update, delete, and list (CRUDL) resources"; the data plane delivers the service itself, such as a running VM or a DNS answer.[^fib-cp] |
| **Static stability** | Systems that "continue to operate as normal without the need to make changes during the failure or unavailability of dependencies".[^fib-static] |
| **Shared responsibility** | The provider's published split of who operates each layer; it moves with the service model ([details](#shared-responsibility-what-moves-with-the-service-model)). |
| **Landing zone** | The provider-specific foundation of accounts, hierarchy and baseline. Google: "also called a cloud foundation" and "not a zone or zonal resources".[^gcp-lz] |
| **Guardrail (control)** | In AWS Control Tower's words, "a high-level rule that provides ongoing governance".[^aws-ct] |
| **Quota** | A provider limit on resources or request rates; adjustable or fixed. |
| **Account vending** | Issuing accounts programmatically with a baseline; Azure calls it subscription vending.[^az-vend] |
| **Tier, RTO** | Tier is this page's label for criticality (tier-1: recover within minutes); the recovery time objective (RTO) is the longest acceptable restore time. Microsoft's CAF has the platform team define "reliability requirements (SLO, RPO, RTO) per workload priority".[^ms-manage] |
| **SLO, error budget** | A service level objective is a target for a measured service level; the error budget is the unreliability it allows. Taught in [SRE](../sre/). |

**The mental model: two planes, one contract.** You change the estate through the control plane; users depend on the data plane,
and "control planes are statistically more likely to fail than data planes".[^fib-static] So everything passing through the control
plane is governed, and the services that must recover fastest do not need it during an incident.

### How CloudOps relates to other Ops

| Page | Shared ground | CloudOps focus | Their focus |
|---|---|---|---|
| [DevOps](../devops/) | Automation, flow | The estate deployments land in | The delivery system, DORA metrics |
| [InfraOps](../infraops/) | Terraform, drift | Which constructs to govern | How to write and test IaC |
| [PlatformOps](../platformops/), [DevExOps](../devexops/) | Self-service | Accounts, guardrails, quotas beneath the platform | The platform product; measuring developer friction |
| [CloudSecOps](../cloudsecops/) | Org policies | Operational guardrails (Regions, tags, budgets) | Security guardrails, posture, CIS benchmarks |
| [IAMOps](../iamops/) | SCPs, Azure Policy | Where policies attach and why | Policy language and evaluation |
| [FinOps](../finops/) | Tags, budgets | Deploying tag and budget guardrails | Allocation, commitments, unit economics |
| [NoOps](../noops/) | Managed services | Provider signals, quotas | Estimating the operations that remain |
| [SRE](../sre/), [IncidentOps](../incidentops/) | Reliability | Provider failure domains and signals | SLOs and error budgets; running incidents |
| [DisasterRecoveryOps](../disasterrecoveryops/) | Multi-Region | Region architecture | Recovery strategies; invoking recovery |
| [NetOps](../netops/), [NetworkOps](../networkops/) | Connectivity | [Network foundations](#network-foundations): address plan, hub, private access | Running and changing networks |

## Principles and operating model

### Charter and principles

This charter is **this Atlas's proposal**; no official CloudOps manifesto exists.

**Mission:** make the right way to use the cloud the easy way, and keep workloads serving when the provider's control plane is not.

1. **The estate is designed, not accumulated.** Hierarchy and baseline are versioned; every account is vended.
2. **Every guardrail has an owner, an exception path and a measurement.** Unmeasured rules decay; rules without exceptions create
   shadow accounts.
3. **The shorter the RTO, the fewer control-plane steps in recovery.** AWS: "For maximum resiliency, you should use only data plane
   operations as part of your failover operation".[^aws-dr] Backup and restore or pilot light rebuild and scale during recovery and
   are valid where the RTO allows; tier-1 recovery should contain none.
4. **Limits are inventory.** Quotas and Region capacity are forecast like any other capacity.
5. **Provider signals are work items.** Every health event, scheduled change and deprecation reaches a named owner.
6. **Learn the construct, use the native tool.** Concepts are provider-neutral; mechanisms are native. Abstract only where it pays.

**Non-goals:** choosing security controls, deciding commitments, building the developer platform (see the neighbours above).

### Fundamentals: the building blocks

1. **Hierarchy.** AWS: root → organisational units (OUs) → accounts. Azure: management groups (up to six levels, as of October
   2026) → subscriptions → resource groups.[^az-mg] Google: organization → folders → projects; policies "flow down the
   hierarchy".[^gcp-hier]
2. **Guardrails.** Preventive (block the action), detective (report drift) or proactive (check before deployment).[^aws-ct]
   Engines: AWS Organizations policies (service control policies (SCPs) and resource control policies (RCPs), which set the
   "maximum available permissions" for IAM users and roles and for resources respectively, and declarative policies such as tag,
   backup and upgrade-rollout policies),[^org-pol] Azure Policy, and Google's Organization Policy Service.
3. **Quotas.** Per account and Region on AWS, per subscription and Region on Azure (compute), and generally per project on
   Google.[^sq][^az-vmquota][^gcp-quota] Google separates allocation quotas, rate quotas and system limits; system limits "cannot be
   increased or decreased".[^gcp-quota]
4. **Regions and zones.** The unit of latency, residency and failure isolation. AWS Regions introduced after 20 March 2019 must be
   enabled before use.[^aws-regions]
5. **Provider signals.** AWS Health, Azure Service Health and Google Personalized Service Health report incidents, maintenance and
   changes that affect you.[^aws-health][^az-sh][^gcp-psh]
6. **Native monitoring and autoscaling.** CloudOps sets the defaults each vended account gets: an organisation-wide audit trail (on
   AWS, one organization trail covers every member account),[^ct-org] baseline alarms, and scaling-group maximums that fit the
   quota (this page's rule). AWS notes that "Auto Scaling is a control plane activity".[^aws-dr] Workload
   dashboards and SLO alerts belong to [ObservabilityOps](../observabilityops/) and [SRE](../sre/); cluster autoscaling to
   [KubernetesOps](../kubernetesops/).

### Shared responsibility: what moves with the service model

This Atlas teaches the model here; [CloudSecOps](../cloudsecops/) applies it to security controls and [NoOps](../noops/) uses it to
estimate the work that remains.

| Responsibility | IaaS (a VM) | PaaS or managed service | SaaS |
|---|---|---|---|
| Data, identities, configuration | You | You | You |
| Applications | You | Shared | Shared |
| Network controls | You | Shared | Provider |
| Operating system and patching | You | Provider | Provider |
| Zone placement and self-healing | You (multi-zone, Auto Scaling) | Varies: built in (DynamoDB)[^ddb] or your setting (RDS Multi-AZ, S3 storage class)[^rds-maz][^s3-class] | Provider |
| Backup, versioning, replication of data | You | You | Read the service's terms |
| Quotas and constraints | You | You | Read the service's terms |
| Hosts, physical network, data centre | Provider | Provider | Provider |

Rows 1–4 and 8 follow Microsoft's matrix;[^az-srm] rows 5–7 follow AWS's resiliency model ("of the cloud" versus "in the cloud";
the SaaS cells are this page's reading; zone examples from the service guides), where managed-service customers own "resiliency
of your data including backup, versioning, and replication strategies".[^aws-resil] Google adds "shared fate", supplying guidance
and secured infrastructure code.[^gcp-srm] **Consequence:** moving a workload from a VM to a managed service moves patching and
host recovery to the provider, not backups, configuration or quotas, and zone redundancy only where the service builds it in.

### Roles, ownership and RACI

Microsoft's Cloud Adoption Framework splits cloud management into "central (platform) responsibilities and workload
responsibilities": "Monitor subscription limits and handle requests for quota increases" is central, "ensuring resources remain
within subscription quotas" is a workload duty.[^ms-manage] The RACI below generalises the split (this Atlas's proposal; R =
responsible, A = accountable, C = consulted, I = informed).

| Activity | Cloud platform team | Workload team | Security | FinOps |
|---|---|---|---|---|
| Hierarchy and baseline | A/R | C | C | C |
| Account vending | A/R | R (requests) | C | I |
| Address plan and shared network | A/R | C | C | I |
| Region allow-list and exceptions | A/R | R (requests) | C | I |
| Required tag keys | R (enforces) | R (applies) | I | A (defines) |
| Quota limits and increase requests | A/R (monitors, files) | R (forecasts own use) | I | I |
| Provider signals | R (routing) | A/R (action) | R (security events) | I |
| Security guardrails | C | I | A/R | I |
| Budget alerts | R (deploys) | R (responds) | I | A |

**Skills:** provider APIs, policy design, networking, monitoring, IaC ([InfraOps](../infraops/)) and incident handling. In a small
organisation two or three people hold every platform-team duty.

### Lifecycle: Day 0, Day 1, Day 2

- **Day 0, design.** Hierarchy, Regions, baseline, guardrails, identity, network and monitoring; Azure's eight landing-zone design
  areas make a usable provider-neutral checklist.[^az-design]
- **Day 1, build and onboard.** Landing zone, vending pipeline, first workloads; guardrails in audit mode before deny (Azure's
  `DoNotEnforce` exists "when you want to evaluate the policy assignment before enforcement").[^az-assign]
- **Day 2, run.** The cadences below, plus baseline upgrades, Region launches and retirements, and account closure: back up
  what you keep; AWS lets you reopen a closed account within 90 days, and its email cannot become another account's primary
  email.[^acct-close]

### Operating model and governance

| Cadence | Activity | Output |
|---|---|---|
| Continuous | Vending, signal routing, quota alarms | Accounts, acknowledged events, increase requests |
| Weekly | Signal and quota review | Open notices with owners and deadlines; forecasts |
| Monthly | Exception review | Renewed or expired exceptions; rules to change |
| Quarterly | Estate review (scorecard in [Templates](#templates)) | Metrics trend, baseline roadmap, game-day plan |
| Per change | Baseline or guardrail release | Staged rollout: sandbox, non-production, then production OUs |

Release guardrails like software. AWS recommends testing SCPs in a separate organisation or OU: "Once tested, you should deploy
changes to more specific OUs and then slowly deploy the changes to broader and broader OUs over time".[^scp-examples] On Azure,
`Enroll` mode is for "staged enforcement through policy enrollments", and resource selectors widen an assignment by location or
type.[^az-assign] When a guardrail blocks an urgent change, the exception path decides (template in [Templates](#templates)).

## Architecture and workflow

### Reference architecture: a landing zone

A landing zone separates foundational accounts from workloads and attaches policy at the highest node it should apply to. AWS
recommends foundational OUs (Security, Infrastructure), Workloads and Sandbox OUs, but adds that "it is your organization's
responsibility to define a customized OU structure".[^aws-ous] Azure divides a landing zone into a platform landing zone and
workload landing zones.[^az-lz] Two AWS details shape the design: "SCPs don't affect users or roles in the management
account",[^scp] and AWS advises: "Avoid deploying workloads to the organization's management account".[^mgmt-bp]

::: figure A reference landing zone and its signal paths
```mermaid
flowchart TB
  ROOT["Organisation root"]
  ROOT --> MGMT["Management account"]
  ROOT --> SEC["Security OU"]
  ROOT --> INFRA["Infrastructure OU: network hub"]
  ROOT --> WL["Workloads OU"]
  ROOT --> SBX["Sandbox OU"]
  MGMT ~~~ WL
  INFRA ~~~ SBX
  SEC --> LOG["Log archive and audit accounts"]
  WL --> PROD["Production accounts"]
  WL --> NP["Non-production accounts"]
  SBX -.->|"audit logs"| LOG
  WL -.->|"audit logs"| LOG
  PROD -.->|"health, quota, budget"| ROUTER["Signal router"]
  ROUTER --> TEAM["Owning team queue"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class ROOT,SEC,INFRA,WL,SBX,PROD,NP,LOG core
  class ROUTER,TEAM neutral
  class MGMT risk
```
Text equivalent: The organisation root has five children: the management account (highlighted as sensitive; billing and
organisation administration only), a Security OU with the log archive and audit accounts, an Infrastructure OU with the network hub
account, a Workloads OU with production and non-production accounts (created by the vending pipeline described below), and a
Sandbox OU. Accounts in the Workloads and Sandbox OUs send audit logs to the log archive; production accounts send health,
quota and budget signals to a router that forwards each to the owning team's queue. Policies attached at the root or an OU are
inherited.
:::

**Trade-offs.** More accounts mean smaller blast radius and per-account quotas,[^aws-multi-ben] but more baselines and more
cross-account networking. OUs by environment simplify policy; OUs by business unit simplify cost reporting. A common compromise is
OUs by environment, with the business unit as a tag.

### Network foundations

Microsoft lists "Define network topology" and "Configure shared networking (virtual network peering, on-premises connectivity)" as
central duties.[^ms-manage] CloudOps owns four decisions; running and changing the network belongs to [NetOps](../netops/) and
[NetworkOps](../networkops/).

1. **Address plan.** Allocate non-overlapping ranges by Region, environment and account; the vending pipeline takes each new
   network's range from the plan. AWS calls IP planning imperative and offers VPC IP Address Manager across Regions and
   accounts.[^aws-mvpc]
2. **Topology.** A hub per Region carries shared connectivity; workload networks are spokes: AWS Transit Gateway (a Regional
   hub-and-spoke service),[^aws-tgw] Azure hub-spoke virtual networks,[^az-hub] or a Google Shared VPC host project.[^gcp-svpc]
3. **Private access** to managed services: AWS PrivateLink and VPC endpoints,[^aws-mvpc] Azure Private Link,[^az-hub] Google
   Private Service Connect.[^gcp-psc]
4. **Egress and DNS.** Central egress is a hub function in AWS's multi-VPC guidance and Azure's hub-spoke design; Azure's hub
   often provides the DNS service that all spokes use.[^aws-mvpc][^az-hub]

::: figure Network foundations in one Region: plan, hub and spokes
```mermaid
flowchart TB
  PLAN["Address plan (IPAM)"] -.->|"allocates a range at vending"| P1
  PLAN -.-> P2
  ONP["On-premises network"] --- HUB
  HUB["Network hub account: transit, egress, DNS"]
  HUB --- P1["Production spoke"]
  HUB --- P2["Non-production spoke"]
  HUB --> NET["Internet via central egress"]
  P1 -.->|"private endpoint"| SVC["Managed service"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class HUB,PLAN core
  class ONP,P1,P2,NET,SVC neutral
```
Text equivalent: An address plan allocates a non-overlapping range to each spoke network when its account is vended. A network hub
account connects the on-premises network and the production and non-production spokes, provides DNS and sends internet traffic
through central egress. The production spoke reaches a managed service through a private endpoint, not the internet.
:::

Each hub is a shared dependency: give it its own account, quota review and change window.

### End-to-end workflow: vending an account

::: figure Account vending: the happy path and two exception paths
```mermaid
sequenceDiagram
  participant W as Workload team
  participant P as Vending pipeline
  participant C as Platform team
  W->>P: Request (owner, env, Regions, budget)
  alt Region outside allow-list
    P->>C: Exception review
    C-->>P: Approve with expiry, or reject
  end
  Note over P: Org API: create account in target OU
  Note over P: Apply baseline and quota template
  break Baseline step fails
    Note over P: Move account to quarantine OU
    P->>C: Page platform on-call
  end
  P->>W: Hand over with test signal delivered
```
Text equivalent: The workload team submits a request with owner, environment, Regions and budget. If a requested Region is outside
the allow-list, the pipeline asks the platform team for an exception, which is approved with an expiry date or rejected. The
pipeline then calls the provider's organisation API to create the account in the target OU and applies the baseline and the quota
template. If a baseline step fails, the pipeline stops: it moves the account to a quarantine OU and pages the platform on-call
engineer. Otherwise it hands the account to the workload team after a test signal has reached their queue.
:::

**Acceptance criteria:** the checklist in [Checklists](#checklists). Provider tooling exists: AWS Account Factory for Terraform
"sets up a Terraform pipeline to help you provision and customize accounts";[^aft] Azure subscription vending is "a platform
mechanism for programmatically issuing subscriptions to workload teams".[^az-vend]

## Practices, frameworks and tools

### Core practices and playbooks

| Practice | Trigger | Owner | Output | Verification |
|---|---|---|---|---|
| Region guardrail | Estate design; Region request | Platform team | Allow-list, exceptions | No resources outside it |
| Required tags | Vending; IaC change | Platform (enforce), FinOps (define) | Keys checked at creation | Cost-weighted compliance |
| Quota management | Alarm; forecast; new account | Platform (requests, templates), workload (forecast) | Early increase requests | No quota-caused launch failures |
| Signal routing | Every account and Region | Platform (routing), workload (action) | Owned events with deadlines | Test event reaches the queue |
| Managed-service change | Deprecation or maintenance notice | Workload team | Upgrade before deadline | No overdue notices |

**Region guardrails: choose a mechanism you can stage.** Control Tower's AWS-GR_REGION_DENY "applies to the entire landing zone"
and "cannot be configured for individual OUs"; CT.MULTISERVICE.PV.1 applies to the OUs you choose,[^ct-region][^ct-ou] as does
AWS's deny policy attached as an SCP per OU.[^iam-region][^scp-examples] SCPs have no documented evaluate-only mode like Azure's `DoNotEnforce`, so audit on
AWS from data: Resource Explorer's cross-Region, multi-account search[^rex] and the `awsRegion` field of CloudTrail records.[^ct-record]
Three blind spots are documented. *Existing resources:* AWS says "be sure that you do not have existing resources in these Regions,
because you will not have access to your resources after you apply the control".[^ct-region] *Global resources:* Control Tower
exempts some global services (IAM, Organizations); AWS's example policy must exempt services whose single endpoint is in
us-east-1;[^iam-region] Azure's "Allowed locations" excludes resource groups (a separate policy covers them) and the `global`
location.[^az-builtin] *Data location:* Google's constraint "controls only where resources are created. Some Google Cloud services
might not store or process data contained by a resource in the same location", and "does not identify or remediate existing
violations".[^gcp-loc]

**Required tags: enforce at creation, measure from inventory.** Since November 2025, AWS tag policies can mark tag keys as required
and validate them in CloudFormation (a WARN or FAIL hook), Terraform and Pulumi;[^tag-news][^tag-iac] resources created another way
are not checked (this page's reading). AWS warns: "Untagged resources don't appear as non-compliant in results", and suggests
Resource Explorer with `tag:none`.[^tag-report] Azure's "Require a tag on resources" "Does not apply to resource groups",[^az-builtin]
and "Resources don't inherit the tags you apply to a resource group or a subscription".[^az-tags] Google's labels are per-resource;
its tags are inherited, and mandatory tags need a custom organization policy (Preview, listed resource types, as of October
2026).[^gcp-tags] [FinOps](../finops/) decides what each tag means.

**Quotas: forecast per account and Region.** AWS support "might approve, deny, or partially approve" increase requests.[^sq]
Request templates request increases for new accounts automatically, but not in China or opt-in Regions, where the vending pipeline
must file them;[^sq-templ] Automatic Management notifies at 80% and 95% use and can request increases.[^sq-auto] Three traps:
Capacity Reservations "count toward your On-Demand Instance quotas, even if they are unused";[^ec2-od] default quotas for several
accelerated instance families are 0 vCPUs (as of October 2026);[^ec2-quotas] and Microsoft "may review and adjust Quotas from time
to time, including increasing or decreasing" them.[^az-quota]

**Provider signals: cover every Region, plus the global one.** On AWS you create an EventBridge rule per Region. In the standard
partition each event is also sent to a backup Region (US West (Oregon); N. Virginia for Oregon), and AWS documents two options:
rules in both Regions with de-duplication on `detail.communicationId` (high availability), or a filter on `detail.backupEvent`.
Global events such as IAM's need a rule in US East (N. Virginia).[^health-region] [NoOps](../noops/) filters, to test one account's
rules; [Artefact 4](#reference-implementation) keeps the copies, so an organisation-wide feed survives the loss of one Region.

**Managed-service change: stage the provider's upgrades too.** AWS Organizations upgrade rollout policies "centrally manage and
stagger automatic upgrades" in three orders (First, Second, Last); as of October 2026 they cover Aurora and RDS.[^upgrade] Where
no such control exists, use maintenance windows per environment and track every deprecation notice to closure.

### Methods, standards and frameworks

| Framework | Status | Use in CloudOps |
|---|---|---|
| NIST SP 800-145[^nist] | Authoritative definition, not an operating standard | Vocabulary; DORA measures against its five characteristics |
| Well-Architected: AWS (six pillars), Azure (five), Google (six plus cross-pillar perspectives)[^aws-wa][^az-wa][^gcp-wa] | Vendor frameworks (recommendations) | Workload reviews; operational-excellence and reliability questions |
| Microsoft CAF Manage (Ready, Administer, Monitor, Protect)[^ms-manage] | Vendor operating guidance | Central versus workload split |
| AWS Fault Isolation Boundaries[^fib-cp] | Vendor design guidance | Control and data planes; static stability; global services |
| EU DORA, EU Data Act[^dora-eu][^data-act] | Law (EU, sector-specific or general) | Exit strategies; switching; see [compliance](#quality-security-and-compliance) |

Only the regulations are mandatory, and only where they apply; the frameworks are recommendations from the sellers. **Running a
well-architected review:** AWS wants "a conversation and not an audit", "early on in the design phase" and again "before the
go-live date", ending in a set of actions.[^aws-wa-review] The workload team answers; CloudOps adds the estate questions (quotas,
Regions, signals) and tracks the actions.

### Tooling landscape

| Job | AWS | Azure | Google Cloud | Cross-cloud |
|---|---|---|---|---|
| Hierarchy and vending | Organizations, Control Tower, Account Factory for Terraform | Management groups, subscription vending | Resource Manager, enterprise foundations blueprint | Terraform or OpenTofu ([InfraOps](../infraops/)); Crossplane (CNCF graduated 2025-10-28)[^crossplane] |
| Guardrails | Organizations policies, Control Tower controls | Azure Policy | Organization Policy Service | Cloud Custodian (CNCF incubating)[^custodian] |
| Quotas | Service Quotas, CloudWatch usage metrics | Quotas | Cloud Quotas | Your own register (Lab 1) |
| Provider signals | AWS Health, EventBridge | Service Health, Resource Health | Personalized Service Health | Your incident tool |
| Monitoring and scaling | CloudWatch, EC2 Auto Scaling | Azure Monitor | Google Cloud Observability | [ObservabilityOps](../observabilityops/) |

**Selection criteria:** coverage of every account and Region; audit mode; exceptions with expiry; evidence export; and whether
the tool sits in your recovery path. Cross-cloud tools reduce duplication but can trail new provider features.

### Automation and AI

Automate vending, baseline rollout, guardrail deployment, small quota requests and signal routing; keep a human approval for
organisation-wide policy changes. Google's June 2025 outage began with a quota-policy change inside Google's Service Control, whose
metadata "was replicated globally within seconds".[^gcp-inc] This page's inference: your organisation policies are global
configuration too, so roll them out by OU.

AWS announced general availability of AWS DevOps Agent on 31 March 2026, saying it "resolves and proactively prevents
incidents".[^devops-agent] Azure SRE Agent has "Review" and "Autonomous" run modes.[^az-sre] This page's recommendation: agents read
freely, but every control-plane write runs in review mode, under the same guardrails as a human.

## CloudOps in practice

### Reference implementation

**Assumptions (illustrative):** one AWS organisation of about 40 accounts in two EU Regions; Azure and Google equivalents shown
for the Region guardrail.

**Artefact 1: the estate design file,** read by the vending pipeline and the reviews. The format is this page's proposal.

_Example status: YAML syntax-checked; illustrative design file, not consumed by a specific tool._

```yaml
# estate.yaml: the CloudOps contract for one organisation (illustrative)
version: 7
hierarchy:
  - ou: security          # log archive, audit tooling; owned by security
    accounts: [log-archive, audit]
  - ou: infrastructure    # network hub, shared services
    accounts: [network-hub, shared-services]
  - ou: workloads/prod
  - ou: workloads/non-prod
  - ou: sandbox           # budget alert and 30-day expiry
network:
  ipam_pools: {eu-west-1: 10.16.0.0/12, eu-central-1: 10.32.0.0/12}
  vpc_prefix_length: 20   # one range per vended account and Region
account_baseline:         # applied by the vending pipeline, recorded per account
  - central-audit-logging
  - monitoring-and-dashboards
  - provider-signal-routing     # every enabled Region, plus the global-events Region
  - budget-alerts: [0.8, 1.0]
  - quota-request-template      # not available in opt-in Regions: file requests
guardrails:
  allowed_regions: [eu-west-1, eu-central-1]
  region_deny_scope: per-ou     # staged: sandbox, non-prod, prod
  required_tags: [owner, env, cost-center]
  tag_spend_target: 0.95
quota_policy:
  warn_ratio: 0.80
  forecast_days: 30
signals:
  issue:            {route: cloud-oncall, acknowledge_within_minutes: 15}
  scheduled_change: {route: owning-team-queue, acknowledge_within_hours: 72}
exceptions:
  max_duration_days: 90
  approver: cloud-platform-lead
```

**Artefact 2: one Region guardrail on Azure and Google Cloud.** Start Azure in `DoNotEnforce` mode; Google advises testing on
non-production first.[^az-assign][^gcp-loc] On AWS use the OU-level Control Tower control (CT.MULTISERVICE.PV.1) or AWS's deny
policy attached per OU, not the landing-zone-wide control;[^ct-ou][^iam-region] policy language belongs to [IAMOps](../iamops/).

_Example status: syntax-checked (`bash -n`); not executed (requires an Azure tenant). Policy ID and parameter name taken from the
built-in definition._[^az-allowed-json]

```bash
#!/usr/bin/env bash
set -euo pipefail
MG="mg-landing-zones"   # placeholder management group
az policy assignment create \
  --name allowed-locations-eu \
  --policy e56962a6-4747-49cd-b67b-bf8b01975c4c \
  --scope "/providers/Microsoft.Management/managementGroups/${MG}" \
  --params '{"listOfAllowedLocations": {"value": ["westeurope", "germanywestcentral"]}}' \
  --enforcement-mode DoNotEnforce
```

_Example status: YAML syntax-checked; not executed (requires a Google Cloud organisation). Apply with
`gcloud org-policies set-policy policy.yaml`._[^gcp-loc]

```yaml
name: organizations/ORGANIZATION_ID/policies/gcp.resourceLocations
spec:
  rules:
    - values:
        allowedValues:
          - in:europe-west1-locations
          - in:europe-west3-locations
```

**Artefact 3: a required tag key (AWS tag policy).** This follows AWS's documented example. The `report_required_tag_for` key marks
`cost-center` as required for EC2 resources; enforcement happens in the IaC hook or plan check, not in the policy alone.[^tag-report][^tag-iac]

_Example status: JSON syntax-checked; not applied to an organisation._

```json
{
  "tags": {
    "cost-center": {
      "tag_key": {"@@assign": "cost-center"},
      "report_required_tag_for": {"@@assign": ["ec2:ALL_SUPPORTED"]}
    }
  }
}
```

**Artefact 4: provider signals in every Region (AWS).** One rule per enabled Region for operations events and one for abuse events,
which go to security; the event names and Region rules come from AWS's documentation.[^eb-health][^health-region] **Where to run
it:** the management or a delegated-administrator account with organizational view on, which receives "a single feed of AWS
Health events from all accounts";[^health-agg] route on `detail.affectedAccount`.[^health-schema] Otherwise deploy equivalent
rules to every account. **Permissions:** `ec2:DescribeRegions`, `events:PutRule`, `events:PutTargets`. **Prerequisite:** both
topics exist in every Region the loop covers (create them in the same pipeline), each dedicated to these rules and carrying AWS's
documented statement letting `events.amazonaws.com` call `sns:Publish` on that topic only.[^eb-res]

_Example status: syntax-checked (`bash -n`); Region-list pipeline run with a mocked `aws`; not executed against AWS. Account ID is a
placeholder._

```bash
#!/usr/bin/env bash
set -euo pipefail
ACCOUNT_ID="111122223333"   # placeholder
OPS='{"source":["aws.health"],"detail-type":["AWS Health Event"]}'
ABUSE='{"source":["aws.health"],"detail-type":["AWS Health Abuse Event"]}'
# Enabled Regions, plus us-east-1, where global events (for example IAM) arrive
REGIONS=$( (aws ec2 describe-regions --query 'Regions[].RegionName' --output text \
  | tr '\t' '\n'; echo us-east-1) | sort -u)
for r in $REGIONS; do
  aws events put-rule --region "$r" --name health-ops \
    --event-pattern "$OPS" --state ENABLED
  aws events put-targets --region "$r" --rule health-ops \
    --targets "Id=ops,Arn=arn:aws:sns:${r}:${ACCOUNT_ID}:cloud-signals"
  aws events put-rule --region "$r" --name health-abuse \
    --event-pattern "$ABUSE" --state ENABLED
  aws events put-targets --region "$r" --rule health-abuse \
    --targets "Id=sec,Arn=arn:aws:sns:${r}:${ACCOUNT_ID}:security-signals"
done
# Each event also reaches a backup Region (standard partition: us-west-2, or
# us-east-1 for us-west-2): de-duplicate downstream on detail.communicationId.
```

### Hands-on labs

#### Lab 1 (beginner): audit an estate against its guardrails

**Objective:** measure baseline drift, Region conformance, cost-weighted tag compliance and quota runway from one inventory.
**Prerequisites:** Python 3.8 or later; no cloud account, cost or risk; 45 minutes.

1. Save the inventory as `estate.json` and the script as `estate_audit.py`.
2. Run `python3 estate_audit.py estate.json`, then `echo $?`.
3. Fix the findings: set `dev-payments` to `v7`, delete the `gpu-test` resource, add `"cost-center": "4200"` to `es-search`, and
   raise the `prod-payments` quota `limit` to `384` (an approved increase). Run again.
4. What-if: starting from the step 3 result, change `growth_per_day` for `prod-payments` to `6.0` and run again.

_Example status: verified by execution (Python 3.8.10, 2026-10-16); output below is verbatim._

```json
{
  "policy": {
    "baseline_version": "v7",
    "allowed_regions": ["eu-west-1", "eu-central-1"],
    "required_tags": ["owner", "env", "cost-center"],
    "tag_spend_target": 0.95,
    "quota_warn_ratio": 0.80,
    "forecast_days": 30
  },
  "accounts": [
    {"id": "prod-payments", "ou": "workloads/prod", "baseline": "v7"},
    {"id": "prod-search", "ou": "workloads/prod", "baseline": "v7"},
    {"id": "dev-payments", "ou": "workloads/non-prod", "baseline": "v6"},
    {"id": "sandbox-ana", "ou": "sandbox", "baseline": "v7"}
  ],
  "resources": [
    {"id": "db-pay-1", "account": "prod-payments", "region": "eu-west-1",
     "monthly_cost": 4200,
     "tags": {"owner": "payments", "env": "prod", "cost-center": "4100"}},
    {"id": "asg-pay-web", "account": "prod-payments", "region": "eu-west-1",
     "monthly_cost": 3100,
     "tags": {"owner": "payments", "env": "prod", "cost-center": "4100"}},
    {"id": "es-search", "account": "prod-search", "region": "eu-central-1",
     "monthly_cost": 2600,
     "tags": {"owner": "search", "env": "prod"}},
    {"id": "vm-dev-pay", "account": "dev-payments", "region": "eu-west-1",
     "monthly_cost": 300,
     "tags": {"owner": "payments", "env": "dev", "cost-center": "4100"}},
    {"id": "gpu-test", "account": "sandbox-ana", "region": "us-east-1",
     "monthly_cost": 1800,
     "tags": {}}
  ],
  "quotas": [
    {"account": "prod-payments", "region": "eu-west-1",
     "name": "Standard vCPUs", "limit": 256, "usage": 184, "growth_per_day": 2.0},
    {"account": "prod-search", "region": "eu-central-1",
     "name": "Standard vCPUs", "limit": 128, "usage": 64, "growth_per_day": 0.5}
  ]
}
```

```python
"""Audit a cloud estate inventory against operational guardrails (CloudOps Lab 1)."""
import json
import sys


def days_until(target, usage, growth_per_day):
    """Days until usage reaches target at linear growth; None if never."""
    if usage >= target:
        return 0.0
    if growth_per_day <= 0:
        return None
    return (target - usage) / growth_per_day


def fmt_days(d):
    return "never" if d is None else "%.1f d" % d


def main(path):
    with open(path) as f:
        estate = json.load(f)
    pol = estate["policy"]
    findings = 0

    accounts = estate["accounts"]
    current = [a for a in accounts if a["baseline"] == pol["baseline_version"]]
    print("Baseline: %d/%d accounts on %s (%.1f%%)" % (
        len(current), len(accounts), pol["baseline_version"],
        100.0 * len(current) / len(accounts)))
    for a in accounts:
        if a["baseline"] != pol["baseline_version"]:
            findings += 1
            print("  DRIFT  %s (%s) is on %s" % (a["id"], a["ou"], a["baseline"]))

    resources = estate["resources"]
    allowed = pol["allowed_regions"]
    outside = [r for r in resources if r["region"] not in allowed]
    print("Regions: %d resource(s) outside %s" % (len(outside), ", ".join(allowed)))
    for r in outside:
        findings += 1
        print("  REGION %s in %s (account %s)" % (r["id"], r["region"], r["account"]))

    required = pol["required_tags"]
    tagged = [r for r in resources if all(r["tags"].get(k) for k in required)]
    spend = sum(r["monthly_cost"] for r in resources)
    tagged_spend = sum(r["monthly_cost"] for r in tagged)
    share = tagged_spend / spend
    print("Tags: %d/%d resources (%.1f%%); %.0f of %.0f monthly spend (%.1f%%), "
          "target %.0f%%" % (
              len(tagged), len(resources), 100.0 * len(tagged) / len(resources),
              tagged_spend, spend, 100.0 * share, 100.0 * pol["tag_spend_target"]))
    if share < pol["tag_spend_target"]:
        findings += 1
    for r in resources:
        missing = [k for k in required if not r["tags"].get(k)]
        if missing:
            print("  TAGS   %s missing %s" % (r["id"], ", ".join(missing)))

    warn, horizon = pol["quota_warn_ratio"], pol["forecast_days"]
    print("Quotas: warn at %.0f%%, horizon %d days" % (100 * warn, horizon))
    for q in estate["quotas"]:
        used = float(q["usage"]) / q["limit"]
        to_warn = days_until(q["limit"] * warn, q["usage"], q["growth_per_day"])
        to_full = days_until(q["limit"], q["usage"], q["growth_per_day"])
        action = "ok"
        if used >= warn or (to_full is not None and to_full <= horizon):
            action = "ACT NOW"
        elif to_warn is not None and to_warn <= horizon:
            action = "REQUEST INCREASE"
        if action != "ok":
            findings += 1
        print("  QUOTA  %s/%s %s: %d/%d (%.1f%%)" % (
            q["account"], q["region"], q["name"], q["usage"], q["limit"], 100 * used))
        print("         warn in %s, full in %s -> %s" % (
            fmt_days(to_warn), fmt_days(to_full), action))

    print("Findings: %d" % findings)
    return 1 if findings else 0


if __name__ == "__main__":
    sys.exit(main(sys.argv[1] if len(sys.argv) > 1 else "estate.json"))
```

**Expected output (step 2), exit code 1:**

```text
Baseline: 3/4 accounts on v7 (75.0%)
  DRIFT  dev-payments (workloads/non-prod) is on v6
Regions: 1 resource(s) outside eu-west-1, eu-central-1
  REGION gpu-test in us-east-1 (account sandbox-ana)
Tags: 3/5 resources (60.0%); 7600 of 12000 monthly spend (63.3%), target 95%
  TAGS   es-search missing cost-center
  TAGS   gpu-test missing owner, env, cost-center
Quotas: warn at 80%, horizon 30 days
  QUOTA  prod-payments/eu-west-1 Standard vCPUs: 184/256 (71.9%)
         warn in 10.4 d, full in 36.0 d -> REQUEST INCREASE
  QUOTA  prod-search/eu-central-1 Standard vCPUs: 64/128 (50.0%)
         warn in 76.8 d, full in 128.0 d -> ok
Findings: 4
```

**Validation.** Step 3 prints `Baseline: 4/4`, `Regions: 0`, `Tags: 4/4 resources (100.0%); 10200 of 10200`, the payments quota
at `184/384 (47.9%)` with `warn in 61.6 d, full in 100.0 d -> ok`, and `Findings: 0` with exit code 0. Step 4 prints `warn in 20.5
d, full in 33.3 d -> REQUEST INCREASE` and `Findings: 1`. **Troubleshooting:** `JSONDecodeError` usually means a trailing comma;
`KeyError`, a missing field. **Teardown:** delete the two files.

#### Lab 2 (intermediate): see and alarm on a quota (AWS)

**Objective:** read the hierarchy and one quota, then alarm at 80% of it. **Prerequisites:** AWS CLI v2; non-production credentials
that can read Service Quotas and create CloudWatch alarms; an SNS topic. `list-roots` works only from the management account or a
delegated administrator.[^list-roots] **Cost and risk:** one CloudWatch alarm. Save the JSON block as
`quota-metrics.json` in the directory where you run the script.

_Example status: JSON and bash syntax-checked; not executed (requires AWS credentials). Quota code and metric dimensions taken from
AWS documentation._[^gsq][^ec2-usage]

```json
[
  {"Id": "m1", "ReturnData": false,
   "MetricStat": {"Period": 300, "Stat": "Maximum",
     "Metric": {"Namespace": "AWS/Usage", "MetricName": "ResourceCount",
       "Dimensions": [
         {"Name": "Service", "Value": "EC2"},
         {"Name": "Type", "Value": "Resource"},
         {"Name": "Resource", "Value": "vCPU"},
         {"Name": "Class", "Value": "Standard/OnDemand"}]}}},
  {"Id": "e1", "Expression": "m1/SERVICE_QUOTA(m1)*100",
   "Label": "Standard vCPU quota used (%)", "ReturnData": true}
]
```

```bash
#!/usr/bin/env bash
set -euo pipefail
export AWS_REGION="eu-west-1"
TOPIC="arn:aws:sns:eu-west-1:ACCOUNT_ID:cloud-oncall"   # placeholder

# 1. Hierarchy (management or delegated-administrator account only)
aws organizations list-roots --query 'Roots[].Id' || echo "not an org admin account: skip"

# 2. Applied quota for On-Demand Standard vCPUs in this account and Region
aws service-quotas get-service-quota --service-code ec2 --quota-code L-1216C47A \
  --query 'Quota.{name:QuotaName,value:Value,adjustable:Adjustable}'

# 3. Alarm when usage stays at or above 80% of the quota for 15 minutes
aws cloudwatch put-metric-alarm --alarm-name ec2-standard-vcpu-quota-80pct \
  --metrics file://quota-metrics.json \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --threshold 80 --evaluation-periods 3 --treat-missing-data notBreaching \
  --alarm-actions "$TOPIC"

# 4. Teardown
# aws cloudwatch delete-alarms --alarm-names ec2-standard-vcpu-quota-80pct
```

**Expected output:** step 2 returns "Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) instances", its value and
`"adjustable": true`; step 3 prints nothing, and the alarm appears in `INSUFFICIENT_DATA` or `OK`. **Validation:** the alarm graph
matches the Service Quotas console; AWS's console guide builds the same expression.[^cw-quota] **Troubleshooting:** `AccessDenied`
on step 1 is expected outside the management account; a `--metrics` validation error is usually a dimension typo.
**Teardown:** run the commented `delete-alarms` line.

#### Lab 3 (advanced): control-plane impairment game day

**Objective:** prove that a tier-1 service survives a Region where existing resources run but nothing new can be created.
**Prerequisites:** service owner, platform engineer, on-call engineer and the architecture diagram; two hours; no production change.

1. **Scenario.** "In your primary Region, nothing new can be launched for eight hours; running instances keep working." This
   models one aspect of AWS's October 2025 event (failed launches, healthy existing instances) and leaves out its DynamoDB and
   load-balancer errors.[^aws-pes]
2. **Label every failover step** *data plane* (DNS answers, traffic to running capacity, reads) or *control plane* (launching,
   scaling out, changing IAM, creating resources, raising quotas).
3. **Check partitional services.** "Do not rely on the control planes of partitional services in your recovery path"; IAM's and
   Organizations' control planes are in us-east-1.[^fib-global]
4. **Check operator access.** In the same event, console sign-in failed in other Regions for root users and federation through
   `signin.aws.amazon.com` for about 90 minutes.[^aws-pes] Can operators fail over without a new console session (automation,
   break-glass; see [DisasterRecoveryOps](../disasterrecoveryops/))?
5. **Check signals.** Does monitoring run outside the impaired Region and provider?
6. **Record.** Each control-plane step becomes a backlog item: pre-provision capacity, pre-create roles, or remove the step.

**Expected output:** runbook steps with plane labels, and a backlog. **Validation:** the tier-1 failover path has no control-plane
step, or each has an accepted risk. **Troubleshooting:** unsure of a step's plane? If it creates, updates or deletes something, it is
control plane.[^fib-cp] **Teardown:** none; file the backlog.

### Use cases and scenarios

#### Case 1: Google Cloud's global API outage, June 2025 (sourced)

**What happened.** On 12 June 2025 a quota-policy change containing "unintended blank fields" reached Service Control, which checks
Google API requests; its metadata "was replicated globally within seconds", and a code path added on 29 May without error handling
or a feature flag crashed in every region. us-central1 took up to about 2 h 40 min to recover.[^gcp-inc] **The CloudOps lesson** is in Google's report: the first update reached Cloud Service Health about an
hour in, because that infrastructure was down, and "For some customers, the monitoring infrastructure they had running on Google
Cloud was also failing".[^gcp-inc] **Method:** an external probe and alert path. **Success criterion:** a provider-wide outage
pages you within minutes, whatever the status page says.

#### Case 2: AWS us-east-1, October 2025 (sourced)

**What happened.** From 11:48 PM PDT on 19 October, a latent race condition in DynamoDB's DNS automation left an empty DNS
record for its regional endpoint. "Existing EC2 instances that had been launched prior to the start of the event remained healthy", but new launches failed with
"request limit exceeded" or "insufficient capacity" errors from 2:25 AM to 10:36 AM.[^aws-pes] **The CloudOps lessons:** plans that relied on launching capacity failed while running instances stayed
healthy (static stability), though NLB connection errors hit some load balancers; and error codes during a provider incident
mislead, since "insufficient capacity" was a symptom of the control-plane failure. **Success criterion:** tier-1 services ride out
hours without new launches in the Region, or fail over using only the data plane.

#### Case 3: an EU financial entity plans for exit (illustrative scenario)

::: example Concentration risk and exit
An EU bank's critical payments service runs on one provider. EU DORA: "For ICT services supporting critical or important functions,
financial entities shall put in place exit strategies".[^dora-eu] **Method:** CloudOps keeps an exit inventory (managed services,
data volumes, proprietary APIs), a Region guardrail aligned to the data-location policy (location constraints govern creation, not
processing[^gcp-loc]) and a tested data export. The EU Data Act removes switching charges, including egress for switching, from
12 January 2027;[^data-act] egress for in-parallel (multi-cloud) use may still be charged, but only at cost (Art. 34(2)).[^data-act-text]
**Success criterion:** an exit runbook with measured export time. **Pitfall:** treating exit planning as a mandate for multi-cloud
active-active (see the [judgement call](#a-judgement-call-multi-cloud-after-a-region-outage)).
:::

## Measure, govern, pay

### Metrics and KPIs

DORA advises: "Avoid measuring success based on the percentage of workloads hosted on cloud servers".[^dora-flex] The first two
rows below are DORA's suggestions; the rest are this page's proposals.

| KPI | Definition / formula | Data source | Pitfall | Cadence |
|---|---|---|---|---|
| Time to provision | Median hours from request to a usable, baselined account | Vending pipeline | Measure from submission, not approval | Monthly |
| Self-service rate | Requests fulfilled by automation ÷ all requests | Pipeline, tickets | Hand-run "automation" counted | Monthly |
| Baseline coverage | Accounts on the current baseline ÷ all accounts | Estate inventory | Accounts created outside vending are invisible | Weekly |
| Region conformance | Resources outside the allow-list; open and expired exceptions | Inventory, policy engine | Global resources are excluded by design | Weekly |
| Tag compliance (cost-weighted) | Spend on resources with all required keys ÷ total spend | Inventory joined with billing | Provider reports may omit untagged resources[^tag-report] | Monthly |
| Quota runway | (warn ratio × limit − usage) ÷ daily growth, in days | Usage metrics, quota API | Linear growth hides launches and seasons | Weekly |
| Notice closure | Notices actioned before deadline ÷ notices with a deadline | Signal router, tickets | Unreceived notices are never counted | Monthly |
| Control-plane steps in tier-1 failover | Create, update or delete steps in recovery runbooks | Game days (Lab 3) | Untested runbooks look clean | Quarterly |

**Worked calculation (from Lab 1).** Tag compliance is 3 ÷ 5 = 60% by count but 7,600 ÷ 12,000 = 63.3% by spend; finance cares
about spend. Quota runway for `prod-payments` is (0.8 × 256 − 184) ÷ 2 = 10.4 days to the warning line and (256 − 184) ÷ 2 = 36
days to exhaustion. Increases need review and may be partly approved,[^sq] so a 10-day runway is thin and a 30-day horizon is a
sensible default.

### Quality, security and compliance

Who secures which layer follows the [shared responsibility](#shared-responsibility-what-moves-with-the-service-model) split; which
security controls to enforce is [CloudSecOps](../cloudsecops/) work. **Auditability:** guardrails as code, exceptions with expiry,
audit logs from every account in a separate account. **Regulation is jurisdictional:** EU DORA (applicable from 17 January
2025) adds exit strategies and "ICT concentration risk" duties for financial entities
([Case 3](#case-3-an-eu-financial-entity-plans-for-exit-illustrative-scenario));[^dora-eu] the EU Data Act sets cloud switching
rules.[^data-act] This page describes operational consequences, not
legal advice.

### Cost, capacity and sustainability

CloudOps deploys budget alerts; [FinOps](../finops/) decides budgets and commitments. Alerts do not stop spending: on Google Cloud,
"an alerts-only budget doesn't automatically cap" usage, while spend-cap budgets (where supported) pause services "until you
manually lift the cap", which trades a cost risk for an availability risk.[^gcp-budget] For capacity, separate your quota (a limit
you can raise) from the provider's capacity (which can run out in a zone). EC2 returns `VcpuLimitExceeded` (On-Demand vCPUs) or
`InstanceLimitExceeded` (instance count) for the first and `InsufficientInstanceCapacity` for the second;[^ec2-errors][^ec2-launch]
Azure likewise "checks quota and capacity separately".[^az-vmquota] Region choice can also change carbon; see [GreenOps](../greenops/).

### Assurance of the operating model

::: figure The CloudOps feedback loop: from signal to baseline change
```mermaid
flowchart TB
  SIG["Signals: health events, quota alarms, guardrail findings, budget alerts"] --> TRI["Triage: owner and deadline"]
  TRI --> ACT["Action: upgrade, increase, fix, exception"]
  ACT --> VER["Verify: alarm clears, inventory conforms"]
  VER --> REV["Quarterly review: metrics and incidents"]
  REV --> BASE["Change the baseline or a guardrail"]
  BASE -->|"staged rollout by OU"| SIG
  TRI -->|"no owner found"| GAP["Ownership gap"]
  GAP --> REV
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class SIG,TRI,ACT,VER,REV,BASE core
  class GAP risk
```
Text equivalent: Signals (health events, quota alarms, guardrail findings, budget alerts) go to triage, which assigns an owner and
a deadline. The owner acts (upgrade, increase, fix or exception) and verifies the result. The quarterly review uses metrics and
incidents to change the baseline or a guardrail, rolled out by OU, which changes future signals. A signal with no owner is
recorded as an ownership gap and goes straight to the quarterly review.
:::

**Risk indicators:** exceptions renewed rather than closed; quota alarms without an increase request; late acknowledgements;
accounts created outside vending; rising untagged spend.

## When things go wrong

### Common failures and troubleshooting

| Symptom | Likely cause | Diagnosis | Remediation | Prevention |
|---|---|---|---|---|
| Team locked out after a guardrail change | Region deny with resources still in the Region[^ct-region] | Inventory by Region | Temporary exception; migrate | Audit first; OU-by-OU rollout |
| `VcpuLimitExceeded` or `InstanceLimitExceeded` at peak | vCPU or instance-count quota reached[^ec2-errors] | Usage vs applied quota | Increase; shed load | Runway alarm; templates |
| `InsufficientInstanceCapacity` | Zone or type capacity, or a provider incident[^ec2-launch][^aws-pes] | Provider health; other zones | Other zones or types | Type flexibility; headroom |
| `RequestLimitExceeded`, no provider event | Your own EC2 API call rate[^ec2-errors] | CloudTrail by caller | Retry with growing, varied waits; slow the caller | Rate limits in automation |
| Monitoring silent in an outage | Monitoring inside the failing provider[^gcp-inc] | External probe | Fallback channel | External alert path |
| Deprecation hits production | Notice in a mailbox; rule missing in a Region | Router coverage report | Emergency upgrade | Rule per Region plus global[^health-region] |
| Tag report 100%, spend unallocated | Untagged resources not reported[^tag-report] | Search for untagged resources | Tag or delete | Measure from inventory |
| New account cannot run GPU jobs | Accelerated quota defaults to 0 vCPUs[^ec2-quotas] | Quota for that family | Request increase | Template per account type |

### Worked runbook: instances will not launch during scale-out

**Context (illustrative):** the checkout Auto Scaling group is at 70% of desired capacity and latency is rising. Live incident
command belongs to [IncidentOps](../incidentops/); this runbook is the cloud-side diagnosis.

::: figure Diagnosing launch failures: quota, capacity, throttling or control plane
```mermaid
flowchart TB
  A["Scale-out activity shows failed launches"] --> B{"Error code?"}
  B --> Q["VcpuLimitExceeded or InstanceLimitExceeded"]
  B --> I["InsufficientInstanceCapacity"]
  B --> R["RequestLimitExceeded"]
  Q --> Q1["Quota reached: shed load; request increase"]
  I --> C{"Provider event posted?"}
  R --> T{"Provider event posted?"}
  C -->|"No"| C1["Capacity: allow more zones and types"]
  T -->|"No"| T1["Throttling: back off; find caller in CloudTrail"]
  C -->|"Yes"| CP["Control-plane incident: stop launching; use running capacity"]
  T -->|"Yes"| CP
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  class B,C,T decision
  class Q,I,R risk
  class Q1,C1,T1,CP core
```
Text equivalent: Read the error code of the failed launches. VcpuLimitExceeded or InstanceLimitExceeded: a quota (vCPUs or
instance count) is reached; shed load and request an increase. InsufficientInstanceCapacity or RequestLimitExceeded: check for a
provider health event in this Region. Without one, the first means zone or instance-type capacity (allow more zones and types) and
the second your own API call rate (back off; find the caller in CloudTrail). With one, treat either as a control-plane incident:
stop launching and serve from running capacity.
:::

_Example status: syntax-checked; the DNS lookup ran on 2026-10-16 (returned us-east-1); AWS calls not executed (need
credentials). Group name is a placeholder._

```bash
#!/usr/bin/env bash
set -euo pipefail
ASG="checkout-web"   # placeholder
# 1. What failed, and with which message?
aws autoscaling describe-scaling-activities --auto-scaling-group-name "$ASG" \
  --max-items 5 --query 'Activities[].[StartTime,StatusCode,StatusMessage]' \
  --output text
# 2. Quota headroom for Standard On-Demand vCPUs
aws service-quotas get-service-quota --service-code ec2 --quota-code L-1216C47A \
  --query 'Quota.Value'
# 3. Open provider events. The Health API is active/passive: ask DNS which Region
#    is active. (Needs an eligible support plan; otherwise use the Health Dashboard.)
HEALTH_REGION=$(dig +short CNAME global.health.amazonaws.com \
  | sed -E 's/^health\.([a-z0-9-]+)\.amazonaws\.com\.?$/\1/')
aws health describe-events --region "${HEALTH_REGION:-us-east-1}" \
  --filter eventStatusCodes=open \
  --query 'events[].[service,eventTypeCode,region]'
```

1. **Stabilise (minutes 0–10).** Read the error (step 1). If a tier-1 zone has no healthy capacity, shift traffic at the data
   plane (DNS or load-balancer weights); do not wait for new instances.
2. **Diagnose (10–20).** Follow the figure: quota headroom (step 2); provider health from your EventBridge feed or the Health
   Dashboard first, then the API, whose active Region can change (step 3).[^health-api][^aws-health]
3. **Remediate** as the figure shows; for throttling, retry with growing, varied waits;[^ec2-errors] in a provider incident, also
   freeze deployments and scaling changes.
4. **Verify.** Desired capacity is reached, or latency is inside the SLO with the capacity you have.
5. **Prevent.** A runway alarm (Lab 2), running headroom for tier-1, instance-type flexibility, rate limits in automation.

### Anti-patterns and myths

- **One big account.** Everyone shares its quotas, blast radius and bill.[^aws-multi-ben]
- **Guardrails without exceptions.** Teams route around them.
- **"The SLA is our availability."** An SLA defines credits. The EC2 Region-level SLA of 99.99% is paid as service credits.[^ec2-sla]
- **Myth: multi-cloud makes you resilient.** It adds a second control plane, identity system and guardrail set to operate; Google's
  own guidance says long-term growth "can introduce complexities that might outweigh the initial benefits".[^gcp-multi]

## Deciding and adopting

### When to use CloudOps and when not to

**Invest in full CloudOps** when several teams deploy to the cloud, you have more than a handful of accounts, regulated data or
revenue runs there, or you use more than one Region. **Keep it minimal** for one small team with one or two accounts: create an
organisation from day one, choose Regions deliberately, route provider signals, set budget alerts and watch quotas; build vending
when requests queue. **It is the wrong lens** for SaaS-only estates ([IdentityOps](../identityops/)) and on-premises estates
([ITOps](../itops/), [SysOps](../sysops/)).

**Hybrid** sits between. When on-premises hardware runs under the provider's control plane, as with AWS Outposts, CloudOps
practices apply and so does the plane split: if an Outpost loses its link to the Region, local instances "continue to operate
normally", but "the run, start, stop, and terminate APIs might not work".[^outposts] Power, facility and local network stay with
[ITOps](../itops/) and [NetOps](../netops/).

### Decision framework

The most consequential CloudOps decision is the failure domain a service must survive. Use it per service, not per company.

::: figure Choosing the failure domain a service must survive
```mermaid
flowchart TB
  S["Service, its SLO and RTO"] --> Z{"Survive the loss of one zone?"}
  Z -->|"No"| ONE["Single zone: accept risk; back up data"]
  Z -->|"Yes"| R{"Survive the loss of a Region?"}
  R -->|"Yes"| P{"Keep serving through a provider-wide event?"}
  R -->|"No"| MAZ["Multi-zone with running headroom"]
  P -->|"Yes"| MC["Multi-cloud for this service only"]
  P -->|"No"| X{"Exit plan required?"}
  X -->|"Yes"| EX["Add a tested exit plan"]
  X -->|"No"| RTO{"RTO in minutes?"}
  EX --> RTO
  RTO -->|"Yes"| MR["Pre-scaled multi-Region, data-plane failover"]
  RTO -->|"Hours or more"| PL["Pilot light or backup and restore"]
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class Z,R,P,X,RTO decision
  class ONE,MAZ,MR,PL,EX core
  class MC risk
```
Text equivalent: Start from the service, its SLO and RTO. No need to survive a zone loss: one zone, accept the risk, back up
data. Zone but not Region: multi-zone with running headroom. Region, and serving through a provider-wide event: that one service on
more than one provider, the costly option. Otherwise, if law or contract requires an exit plan, add a tested one; then the RTO
decides. Minutes mean multi-Region, pre-scaled, with data-plane failover; hours or more allow pilot light or backup and restore,
which accept control-plane steps in recovery.
:::

**Assumptions:** each step up adds an estate to operate for that service (zone capacity, a Region's baseline, a provider's control
plane), and a business impact analysis prices an outage. If you cannot price an outage, start one level lower and measure. Strategy
detail lives in [DisasterRecoveryOps](../disasterrecoveryops/).

### Maturity model

This is **this Atlas's model**, not an official one.

| Level | Observable behaviour | Exit criteria to the next level |
|---|---|---|
| 0 Ad hoc | Accounts built by hand; Regions and tags as people please; notices in a mailbox | An organisation exists; management account holds no workloads |
| 1 Foundations | Hierarchy, central audit logs, address plan, Region allow-list in audit mode | Inventory of every account and Region; owners named |
| 2 Governed | Vending pipeline, enforced Region and tag guardrails with exceptions, signal routing everywhere | 90% of accounts vended; baseline coverage above 95% |
| 3 Measured | Metrics reviewed quarterly; quota runway alarms; staged guardrail releases | Two quarters without quota-caused or notice-caused incidents |
| 4 Resilient | Game days prove tier-1 failover has no control-plane steps; external monitoring; tested exit plan | Sustained; re-test after every architecture change |

### Adoption roadmap: 30/60/90 days

| Window | Actions | Milestone |
|---|---|---|
| Days 1–30 | Inventory accounts, Regions and owners; route provider signals in every Region; budget alerts; choose the estate design and address plan | Inventory complete; every signal has an owner |
| Days 31–60 | Build the landing zone (provider accelerator or IaC); Region and tag guardrails in audit mode; quota register and alarms for the top 10 quotas | First account vended; audit findings triaged |
| Days 61–90 | Enforce guardrails by OU; vending for all new accounts; first game day (Lab 3); quarterly review with the scorecard | Baseline coverage above 80%; tier-1 recovery backlog filed |

**Dependencies:** identity integration ([IdentityOps](../identityops/)), an IaC pipeline ([InfraOps](../infraops/)), tag definitions
([FinOps](../finops/)). **Quick wins:** signal routing and quota alarms.

## Toolkit

### Checklists

**New account readiness**

- [ ] In the right OU; baseline version recorded
- [ ] Network range allocated from the address plan
- [ ] Owner, environment and cost-centre tags on the account
- [ ] Budget alert applied; quota template applied, or requests filed in opt-in Regions
- [ ] Provider signals routed in every enabled Region (and the global-events Region on AWS)
- [ ] A test event reached the owning queue

**Before enforcing a Region guardrail**

- [ ] Inventory shows no resources in Regions to be denied, or exceptions exist
- [ ] Global services the teams use are exempt
- [ ] Audit evidence covers one release cycle (Azure `DoNotEnforce`; on AWS, resource and CloudTrail data by Region)
- [ ] An OU-scoped mechanism, rolled out Sandbox, then non-production, then production

**Quarterly estate review**

- [ ] Scorecard metrics trended; exceptions renewed or closed
- [ ] Quota runway reviewed against the next peak
- [ ] Every provider notice with a deadline closed or owned
- [ ] One game day held or scheduled; monitoring checked from outside the provider

### Templates

**Account request (vending intake)**

| Field | Example |
|---|---|
| Owner team and on-call contact | payments, payments-oncall |
| Environment and OU | prod, workloads/prod |
| Regions (default allow-list or exception) | eu-west-1; exception needed: no |
| Expected peak quotas | 400 Standard vCPUs, 20 load balancers |
| Monthly budget alert | 8,000 at 80% and 100% |
| Expiry (sandbox only) | 30 days |

**Guardrail exception**

| Field | Example |
|---|---|
| Guardrail and scope | Region allow-list, account `ml-research` |
| Reason; alternative considered | GPU type unavailable in allowed Regions; quota request pending |
| Risk accepted, by whom | Synthetic data only; cloud platform lead |
| Expiry and review date | 90 days; review at the monthly exception review |

**Quarterly scorecard**

| Measure | Target | This quarter | Trend |
|---|---|---|---|
| Time to provision (median) | under 1 day | | |
| Baseline coverage | at least 95% | | |
| Cost-weighted tag compliance | at least 95% | | |
| Quota-caused launch failures | 0 | | |
| Provider notices closed before deadline | 100% | | |
| Control-plane steps in tier-1 failover | 0 | | |

### Deep comparisons

The same construct carries different names and edge cases across providers (as of October 2026):

| Construct | AWS | Azure | Google Cloud |
|---|---|---|---|
| Isolation and quota unit | Account (quotas per Region) | Subscription (compute quotas per Region)[^az-vmquota] | Project |
| Region guardrail | Control Tower OU Region deny or a per-OU deny policy on `aws:RequestedRegion`[^ct-ou][^iam-region] | "Allowed locations" (excludes resource groups and `global`)[^az-builtin] | `gcp.resourceLocations` (creation only)[^gcp-loc] |
| Required tags | Tag policy required keys plus IaC validation[^tag-iac] | "Require a tag on resources" (not resource groups)[^az-builtin] | Custom organization policy for mandatory tags (Preview, listed types)[^gcp-tags] |
| Network hub | Transit Gateway (Regional)[^aws-tgw] | Hub-spoke virtual networks[^az-hub] | Shared VPC host project[^gcp-svpc] |

### FAQ

**We have one account and five engineers. Do we need a landing zone?** Not a full one; see
[when to use](#when-to-use-cloudops-and-when-not-to). Keep the management account empty from the start.

**Does multi-cloud make us more resilient?** Against provider-wide failures, possibly, for the services you duplicate; everywhere
else it adds a control plane to govern. See the [judgement call](#a-judgement-call-multi-cloud-after-a-region-outage).

**Who owns quotas?** Both, as in the [RACI](#roles-ownership-and-raci): workload teams forecast and stay within quota; the platform
team monitors limits and files increases.[^ms-manage] Delegating requests is valid if recorded.

**Preventive or detective guardrails?** Preventive for simple rules that must never break (Regions, the management account);
detective for rules that need judgement. Start both in audit mode, or from audit data where the engine has no audit mode.

**Is the AWS CloudOps certification worth it?** It validates AWS operations skills;[^soa] its exam guide puts "Design hybrid and
multi-VPC networking", "Define security, compliance, and governance requirements" and "Assess and plan resource capacity" out of
scope.[^soa-guide] This page counts network foundations, capacity and operational guardrails as CloudOps work; in its view, the
certificate shows day-to-day AWS operating skill, not estate design.

## Going further

### Advanced topics and emerging direction

- **AI agents in operations.** Agents exist (see [Automation and AI](#automation-and-ai)); this page found no independent evidence
  yet of reliable autonomous control-plane changes. Treat agent actions as changes.
- **Switching rules.** The EU Data Act rules in [Case 3](#case-3-an-eu-financial-entity-plans-for-exit-illustrative-scenario) may
  make exit tests cheaper; their effect on multi-cloud economics is speculative.

### Learning path

- **Prerequisites:** [DevOps](../devops/) basics; one provider's console and CLI.
- **One day:** NIST SP 800-145; AWS's pages on control planes and static stability; Lab 1.
- **One week:** a sandbox organisation with two OUs, an audited Region guardrail and Health routing; Lab 2.
- **Thirty days:** vending through IaC ([InfraOps](../infraops/)), an address plan, required tags in WARN mode, Lab 3 with a real team.
- **Specialise:** security guardrails ([CloudSecOps](../cloudsecops/)), policy language ([IAMOps](../iamops/)), reliability
  ([SRE](../sre/)) or recovery ([DisasterRecoveryOps](../disasterrecoveryops/)).
- **Portfolio project:** an estate design file, a vending pipeline and a game-day report for a sample organisation.

## Wrap-up

### Executive recap and cheat sheet

| Topic | Remember |
|---|---|
| Definition | Running the estate through the provider's control plane; label without a neutral definition |
| Decisions | Hierarchy and OUs; address plan and hub; Region allow-list; failure domain and RTO per service |
| Practices | Vend every account; guardrails with exceptions; forecast quotas; route every signal; stage provider upgrades |
| Metrics | Time to provision; baseline coverage; cost-weighted tag compliance; quota runway; notice closure; control-plane steps in failover |
| Watch-outs | Global and untagged resources slip past guardrails; capacity and throttling are not quota; monitoring inside the blast radius |
| Next action | Run Lab 1 on your inventory and Lab 3 with your tier-1 team |

### A judgement call: multi-cloud after a Region outage?

::: decision The board asks for multi-cloud active-active after the us-east-1 event
**Situation (illustrative).** Checkout runs in one AWS Region across three zones with an SLO of 99.95% a month: 30 × 1,440 × 0.0005
= 21.6 minutes of error budget. In October 2025, DynamoDB API errors in us-east-1 alone lasted 172 minutes (11:48 PM to 2:40 AM
PDT),[^aws-pes] about eight months of that budget for a dependent service. The board asks for "multi-cloud active-active".

**Option A: multi-Region, one provider.** A hot standby in a second Region, with replicated data and running capacity for full
load (AWS's "statically stable configuration"; a warm standby must scale up, a control-plane dependency),[^aws-dr] data-plane
failover and one identity system, guardrail set and skill set. It does not cover a provider-wide event like Google's in June
2025.[^gcp-inc]

**Option B: active-active on two providers.** It covers provider-wide events, but doubles the landing zone, guardrails, identity
integration, quota management and on-call knowledge, and forces a choice between proprietary managed databases and a portable data
layer the team does not yet run.

**Assumptions:** six cloud engineers; no regulator requires a second provider; checkout's RTO is minutes.

**Reasoning.** The October event's service impact was mostly regional, but some effects reached further: console sign-in failed
in other Regions for root and federated users, Redshift queries using IAM credentials failed in all Regions (a Redshift defect
called an IAM API in us-east-1), and support cases were unavailable for almost three hours.[^aws-pes]
Option A addresses it if failover uses only the data plane, avoids global control planes (IAM changes, new accounts) and needs
neither a new console session nor a support case.[^aws-dr][^fib-global] Option B sounds complete, but with six engineers the
second provider will be the less practised one, converting provider risk into operator risk. **Recommendation:** Option A, plus
external monitoring and a tested exit plan; revisit B if a regulator, a contract or a priced provider-wide outage requires it.
**Uncertainty:** provider-wide events are rare and hard to price; after one, re-run this analysis with its real duration.
:::

### Learning objectives and mastery check

You can now **explain** control and data planes, static stability and shared responsibility; **design** a hierarchy, address plan
and guardrails with exceptions; **operate** quotas and provider signals; **evaluate** multi-Region and multi-cloud proposals.

1. A team's Auto Scaling group fails with `InsufficientInstanceCapacity` and no provider event is posted. What do you change?

::: answer Show answer for question 1
Capacity, not quota. AWS's remedies: retry, smaller batches, no Availability Zone pinning, other instance types.[^ec2-launch] Allow
more zones and types in the group; a quota increase would not help.
:::

2. Your AWS tag-compliance report shows 100%, yet finance says 20% of spend is unallocated. Why might both be true?

::: answer Show answer for question 2
AWS warns that "Untagged resources don't appear as non-compliant in results".[^tag-report] Measure compliance from an inventory
weighted by cost (Lab 1), find untagged resources with a `tag:none` search, and require keys at creation with the IaC hook.
:::

3. A failover runbook step for a tier-1 service says "launch replacement instances in Region B". Why does Lab 3 flag it?

::: answer Show answer for question 3
Launching is a control-plane action, and control planes "are statistically more likely to fail than data planes".[^fib-static]
With an RTO of minutes, pre-provision the capacity in Region B: for maximum resiliency, AWS advises only data-plane operations in
failover.[^aws-dr] If the RTO allows hours, the step may stay, with quota and capacity checked ahead.
:::

4. A Google Cloud organisation enforces `gcp.resourceLocations` for the EU. A compliance officer says that proves all data is processed in the EU. Is that right?

::: answer Show answer for question 4
No. The constraint "controls only where resources are created", some services may process data elsewhere, global resources are not
affected, and existing violations are not remediated.[^gcp-loc] It is one control, not proof.
:::

5. Design challenge: monitoring and alerting run in the same Region and provider as production. What do you add, and why?

::: answer Show answer for question 5
An external probe and an alert path outside the provider. In June 2025 Google's own status updates lagged by about an hour, and some
customers' monitoring on Google Cloud failed with the workloads.[^gcp-inc]
:::

### Conclusion

CloudOps is a label in search of a definition, but the work behind it is concrete, and provider frameworks describe its parts well.
They leave the ownership to you: who decides a Region exception, who reads the deprecation notice, and who proved that failover
works without creating anything. An
organisation that can answer those three questions does CloudOps, whatever its job titles say.

## Sources and further reading

Claim-by-claim evidence: `research/cloudops-ledger.md`. Provider documentation changes; re-check limits and features before use,
and re-verify dated facts (Preview features, quota defaults, policy types) quarterly or on provider announcements.

[^soa]: [AWS Certified CloudOps Engineer – Associate](https://aws.amazon.com/certification/certified-cloudops-engineer-associate/) — AWS. Checked 2026-10-16.
[^soa-dates]: [Coming soon to AWS Certification](https://aws.amazon.com/certification/coming-soon/) — AWS, 2025. Checked 2026-10-16.
[^soa-guide]: [AWS Certified CloudOps Engineer - Associate (SOA-C03) exam guide](https://docs.aws.amazon.com/aws-certification/latest/sysops-administrator-associate-03/sysops-administrator-associate-03.html) — AWS. Checked 2026-10-16 and 2026-10-17.
[^tt]: [What is CloudOps (cloud operations)?](https://www.techtarget.com/it-infrastructure/definition/What-is-CloudOps-cloud-operations) — TechTarget, 2025-09-05. Checked 2026-10-16.
[^ibm]: [What is CloudOps (cloud operations)?](https://www.ibm.com/think/topics/cloudops) — IBM, updated 2025-11-17. Checked 2026-10-16.
[^redhat]: [What is CloudOps?](https://www.redhat.com/en/topics/automation/what-is-cloudops) — Red Hat, 2024-09-03. Checked 2026-10-16.
[^hpe]: [HPE launches software push with CloudOps bundle](https://www.techtarget.com/it-infrastructure/news/366626451/HPE-launches-software-push-with-CloudOps-bundle) — TechTarget, 2025-06-25. Checked 2026-10-16.
[^nist]: [SP 800-145, The NIST Definition of Cloud Computing](https://csrc.nist.gov/pubs/sp/800/145/final) — Peter Mell, Tim Grance, NIST, 2011. Checked 2026-10-16.
[^dora-flex]: [Flexible infrastructure](https://dora.dev/capabilities/flexible-infrastructure/) — DORA, updated 2026-06-18. Checked 2026-10-16.
[^az-srm]: [Shared responsibility in the cloud](https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility) — Microsoft Learn, 2026-08-24. Checked 2026-10-16.
[^gcp-srm]: [Shared responsibilities and shared fate on Google Cloud](https://docs.cloud.google.com/architecture/framework/security/shared-responsibility-shared-fate) — Google Cloud, updated 2023-08-21. Checked 2026-10-16.
[^aws-resil]: [Shared Responsibility Model for Resiliency](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/shared-responsibility-model-for-resiliency.html) — AWS Well-Architected Reliability Pillar. Checked 2026-10-16 and 2026-10-17.
[^ddb]: [What is Amazon DynamoDB?](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) — Amazon DynamoDB Developer Guide. Checked 2026-10-17.
[^rds-maz]: [Multi-AZ DB instance deployments for Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZSingleStandby.html) — Amazon RDS User Guide. Checked 2026-10-17.
[^s3-class]: [Understanding and managing Amazon S3 storage classes](https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.html) — Amazon S3 User Guide. Checked 2026-10-17.
[^aws-wa]: [The pillars of the framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/the-pillars-of-the-framework.html) — AWS Well-Architected Framework. Checked 2026-10-16.
[^aws-wa-review]: [The review process](https://docs.aws.amazon.com/wellarchitected/latest/framework/the-review-process.html) — AWS Well-Architected Framework. Checked 2026-10-16.
[^az-wa]: [Azure Well-Architected Framework](https://learn.microsoft.com/en-us/azure/well-architected/) — Microsoft Learn, 2026-09-11. Checked 2026-10-16.
[^gcp-wa]: [Google Cloud Well-Architected Framework](https://docs.cloud.google.com/architecture/framework) — Google Cloud, updated 2026-10-13. Checked 2026-10-16.
[^ms-manage]: [Ready your Azure cloud operations](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/manage/ready-cloud-operations) — Microsoft Cloud Adoption Framework, 2025-04-01. Checked 2026-10-16.
[^aws-multi]: [Organizing Your AWS Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) — AWS whitepaper, first published 2021-03-18, updated 2025-04-30. Checked 2026-10-16.
[^aws-multi-ben]: [Benefits of using multiple AWS accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html) — same whitepaper. Checked 2026-10-16.
[^aws-ous]: [Recommended OUs and accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/recommended-ous-and-accounts.html) — same whitepaper. Checked 2026-10-16.
[^aws-ct]: [What is AWS Control Tower?](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) — AWS. Checked 2026-10-16.
[^ct-region]: [Configure the Region deny control](https://docs.aws.amazon.com/controltower/latest/userguide/region-deny.html) — AWS Control Tower. Checked 2026-10-16.
[^ct-ou]: [Region deny control applied to the OU](https://docs.aws.amazon.com/controltower/latest/controlreference/ou-region-deny.html) — AWS Control Tower Controls Reference. Checked 2026-10-16.
[^iam-region]: [Denies access to AWS based on the requested Region](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_aws_deny-requested-region.html) — AWS IAM User Guide. Checked 2026-10-16.
[^rex]: [What is AWS Resource Explorer?](https://docs.aws.amazon.com/resource-explorer/latest/userguide/welcome.html) — AWS. Checked 2026-10-16.
[^ct-org]: [Creating a trail for an organization](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/creating-trail-organization.html) — AWS CloudTrail User Guide. Checked 2026-10-17.
[^ct-record]: [CloudTrail record contents for management, data, and network activity events](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-record-contents.html) — AWS CloudTrail. Checked 2026-10-16.
[^acct-close]: [Close an AWS account](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-closing.html) — AWS Account Management Reference Guide. Checked 2026-10-17.
[^aft]: [Overview of Account Factory for Terraform](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html) — AWS Control Tower. Checked 2026-10-16.
[^az-lz]: [What is an Azure landing zone?](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/) — Microsoft Cloud Adoption Framework, 2025-07-24. Checked 2026-10-16.
[^az-design]: [Azure landing zone design areas](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-areas) — Microsoft Learn, 2025-09-03. Checked 2026-10-16.
[^az-mg]: [Management groups overview](https://learn.microsoft.com/en-us/azure/governance/management-groups/overview) — Microsoft Learn, 2024-07-18. Checked 2026-10-16.
[^az-vend]: [Subscription vending](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/subscription-vending) — Microsoft Learn, 2025-12-11. Checked 2026-10-16.
[^gcp-hier]: [Resource hierarchy](https://docs.cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy) — Google Cloud, updated 2026-10-13. Checked 2026-10-16.
[^gcp-lz]: [Landing zone design in Google Cloud](https://docs.cloud.google.com/architecture/landing-zones) — Google Cloud, updated 2026-01-02. Checked 2026-10-16.
[^aws-mvpc]: [Building a Scalable and Secure Multi-VPC AWS Network Infrastructure](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/welcome.html) — AWS whitepaper, 2024-04-17. Checked 2026-10-16.
[^aws-tgw]: [AWS Transit Gateway](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/transit-gateway.html) — same whitepaper. Checked 2026-10-16.
[^az-hub]: [Hub-spoke network topology in Azure](https://learn.microsoft.com/en-us/azure/architecture/networking/architecture/hub-spoke) — Azure Architecture Center, 2026-04-10. Checked 2026-10-16.
[^gcp-svpc]: [Shared VPC](https://docs.cloud.google.com/vpc/docs/shared-vpc) — Google Cloud, updated 2026-10-13. Checked 2026-10-16.
[^gcp-psc]: [Private Service Connect](https://docs.cloud.google.com/vpc/docs/private-service-connect) — Google Cloud, updated 2026-10-13. Checked 2026-10-16.
[^org-pol]: [Managing organization policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies.html) — AWS Organizations. Checked 2026-10-16.
[^scp]: [Service control policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) — AWS Organizations. Checked 2026-10-16.
[^scp-examples]: [SCP examples](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html) — AWS Organizations. Checked 2026-10-16.
[^mgmt-bp]: [Best practices for the management account](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices_mgmt-acct.html) — AWS Organizations. Checked 2026-10-16.
[^upgrade]: [Upgrade rollout policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_upgrade_rollout.html) — AWS Organizations. Checked 2026-10-16.
[^az-builtin]: [Azure Policy built-in policy definitions](https://learn.microsoft.com/en-us/azure/governance/policy/samples/built-in-policies) — Microsoft Learn, 2026-07-07. Checked 2026-10-16.
[^az-allowed-json]: [AllowedLocations_Deny.json](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/General/AllowedLocations_Deny.json) — Azure/azure-policy, version 1.1.0. Checked 2026-10-16.
[^az-assign]: [Azure Policy assignment structure](https://learn.microsoft.com/en-us/azure/governance/policy/concepts/assignment-structure) — Microsoft Learn, 2026-07-30. Checked 2026-10-16.
[^az-tags]: [Use tags to organize your Azure resources](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/tag-resources) — Microsoft Learn, 2025-09-15. Checked 2026-10-16.
[^gcp-loc]: [Restrict resource locations](https://docs.cloud.google.com/organization-policy/restrict-locations) — Google Cloud Organization Policy, updated 2026-10-13. Checked 2026-10-16.
[^gcp-tags]: [Tags overview](https://docs.cloud.google.com/resource-manager/docs/tags/tags-overview) — Google Cloud, updated 2026-10-13. Checked 2026-10-16.
[^tag-news]: [Validate and enforce required tags in CloudFormation, Terraform and Pulumi with Tag Policies](https://aws.amazon.com/about-aws/whats-new/2025/11/validate-enforce-required-tags-cloudformation-terraform-pulumi/) — AWS, 2025-11-20. Checked 2026-10-16.
[^tag-iac]: [Enforce "Required tag key" with IaC](https://docs.aws.amazon.com/organizations/latest/userguide/enforce-required-tag-keys-iac.html) — AWS Organizations. Checked 2026-10-16.
[^tag-report]: [Report tagging compliance](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies-report-tagging-compliance.html) — AWS Organizations. Checked 2026-10-16.
[^sq]: [What is Service Quotas?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) — AWS. Checked 2026-10-16.
[^sq-auto]: [Service Quotas Automatic Management](https://docs.aws.amazon.com/servicequotas/latest/userguide/automatic-management.html) — AWS. Checked 2026-10-16.
[^sq-templ]: [Using Service Quotas request templates](https://docs.aws.amazon.com/servicequotas/latest/userguide/organization-templates.html) — AWS. Checked 2026-10-16.
[^cw-quota]: [Visualizing your service quotas and setting alarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Quotas-Visualize-Alarms.html) — Amazon CloudWatch. Checked 2026-10-16.
[^ec2-usage]: [CloudWatch metrics for your instances (usage metrics)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html) — Amazon EC2. Checked 2026-10-16.
[^gsq]: [get-service-quota](https://docs.aws.amazon.com/cli/latest/reference/service-quotas/get-service-quota.html) — AWS CLI 2.38.1 Command Reference. Checked 2026-10-16.
[^list-roots]: [list-roots](https://docs.aws.amazon.com/cli/latest/reference/organizations/list-roots.html) — AWS CLI Command Reference. Checked 2026-10-16.
[^ec2-od]: [On-Demand Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-on-demand-instances.html) — Amazon EC2. Checked 2026-10-16.
[^ec2-quotas]: [Amazon EC2 instance quotas](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-instance-quotas.html) — Amazon EC2. Checked 2026-10-16.
[^ec2-launch]: [Troubleshoot instance launch issues](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-launch.html) — Amazon EC2. Checked 2026-10-16.
[^ec2-errors]: [Error codes for the Amazon EC2 API](https://docs.aws.amazon.com/ec2/latest/devguide/errors-overview.html) — Amazon EC2 Developer Guide. Checked 2026-10-16.
[^az-quota]: [Quotas overview](https://learn.microsoft.com/en-us/azure/quotas/quotas-overview) — Microsoft Learn, 2025-03-25. Checked 2026-10-16.
[^az-vmquota]: [vCPU quotas](https://learn.microsoft.com/en-us/azure/virtual-machines/quotas) — Microsoft Learn (Azure Virtual Machines), 2026-01-16. Checked 2026-10-16.
[^gcp-quota]: [Cloud Quotas overview](https://docs.cloud.google.com/docs/quotas/overview) — Google Cloud, updated 2026-10-13. Checked 2026-10-16.
[^gcp-budget]: [Create, edit, or delete budgets and budget alerts](https://docs.cloud.google.com/billing/docs/how-to/budgets) — Google Cloud Billing, updated 2026-10-13. Checked 2026-10-16.
[^fib-cp]: [Control planes and data planes](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/control-planes-and-data-planes.html) — AWS Fault Isolation Boundaries, 2022-11-16. Checked 2026-10-16.
[^fib-static]: [Static stability](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/static-stability.html) — AWS Fault Isolation Boundaries. Checked 2026-10-16.
[^fib-global]: [Global services](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/global-services.html) — AWS Fault Isolation Boundaries. Checked 2026-10-16.
[^aws-dr]: [Disaster recovery options in the cloud](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html) — AWS whitepaper. Checked 2026-10-16.
[^aws-regions]: [AWS Regions](https://docs.aws.amazon.com/global-infrastructure/latest/regions/aws-regions.html) — AWS General Reference. Checked 2026-10-16.
[^outposts]: [Outposts rack maintenance](https://docs.aws.amazon.com/outposts/latest/userguide/outpost-maintenance.html) — AWS Outposts User Guide. Checked 2026-10-16.
[^ec2-sla]: [Amazon Compute Service Level Agreement](https://aws.amazon.com/compute/sla/) — AWS, updated 2022-05-25. Checked 2026-10-16.
[^aws-health]: [What is AWS Health?](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html) — AWS. Checked 2026-10-16.
[^health-api]: [Integrating AWS Health with other systems using the AWS Health API](https://docs.aws.amazon.com/health/latest/ug/health-api.html) — AWS Health. Checked 2026-10-16.
[^eb-health]: [AWS Health events](https://docs.aws.amazon.com/eventbridge/latest/ref/events-ref-health.html) — Amazon EventBridge events reference. Checked 2026-10-16.
[^health-region]: [Creating EventBridge rules for AWS Region coverage](https://docs.aws.amazon.com/health/latest/ug/choosing-a-region.html) — AWS Health. Checked 2026-10-16.
[^health-agg]: [Aggregating AWS Health events using organizational view](https://docs.aws.amazon.com/health/latest/ug/aggregating-health-events.html) — AWS Health. Checked 2026-10-16.
[^health-schema]: [Reference: AWS Health events Amazon EventBridge schema](https://docs.aws.amazon.com/health/latest/ug/aws-health-events-eventbridge-schema.html) — AWS Health. Checked 2026-10-16.
[^eb-res]: [Using resource-based policies for Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-use-resource-based.html) — Amazon EventBridge. Checked 2026-10-16.
[^az-sh]: [What is Azure Service Health?](https://learn.microsoft.com/en-us/azure/service-health/overview) — Microsoft Learn, 2025-10-31. Checked 2026-10-16.
[^gcp-psh]: [Personalized Service Health overview](https://docs.cloud.google.com/service-health/docs/overview) — Google Cloud, updated 2026-10-14. Checked 2026-10-16.
[^gcp-inc]: [Google Cloud incident report, 12 June 2025](https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1SsW) — Google Cloud Service Health, 2025-06. Checked 2026-10-16.
[^aws-pes]: [Summary of the Amazon DynamoDB Service Disruption in the Northern Virginia (US-EAST-1) Region](https://aws.amazon.com/message/101925/) — AWS post-event summary, 2025-10. Checked 2026-10-16 and 2026-10-17.
[^dora-eu]: [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng) — Official Journal of the EU via EUR-Lex, 2022 (applies from 2025-01-17). Checked 2026-10-16.
[^data-act]: [Data Act explained](https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained) — European Commission. Checked 2026-10-16.
[^data-act-text]: [Regulation (EU) 2023/2854 (Data Act), Article 34](https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng) — Official Journal of the EU via EUR-Lex, 2023. Checked 2026-10-16.
[^gcp-multi]: [Partitioned multicloud pattern](https://docs.cloud.google.com/architecture/hybrid-multicloud-patterns-and-practices/partitioned-multicloud-pattern) — Google Cloud, updated 2025-01-23. Checked 2026-10-16.
[^crossplane]: [Crossplane](https://www.cncf.io/projects/crossplane/) — CNCF project page. Checked 2026-10-16.
[^custodian]: [Cloud Custodian](https://www.cncf.io/projects/cloud-custodian/) — CNCF project page. Checked 2026-10-16.
[^devops-agent]: [Announcing General Availability of AWS DevOps Agent](https://aws.amazon.com/blogs/mt/announcing-general-availability-of-aws-devops-agent/) — AWS, 2026-03-31. Checked 2026-10-16.
[^az-sre]: [Run modes in Azure SRE Agent](https://learn.microsoft.com/en-us/azure/sre-agent/run-modes) — Microsoft Learn, 2026-06-02. Checked 2026-10-16.

**Changelog.** 2026-10-16, r0: first version (research, ledger, draft, diagrams; Blueprint v2 structure); not yet independently reviewed.
2026-10-16, r1: after review `reviews/cloudops-r1.md`: runbook error codes fixed; network foundations and shared responsibility
added; recovery principle tied to RTO; Lab 3 rescoped; OU-level Region deny; Lab 1 re-run; Figure 1 and a case cut for length.
2026-10-17, post-score polish: `reviews/cloudops-score.md` S1–S8 (wider October 2025 effects; PaaS zone cell; Figure 6 exit branch
via RTO; Figure 3 `break`; certification FAQ; topic prerequisite; account closure; monitoring defaults; re-check cadence).