CloudOps

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).

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.^[5] CloudOps delivers NIST’s self-service and elasticity^[6] without losing control of the estate.

• Not the AWS certification. The exam tests AWS skills;^[4] the practice spans providers and organisations.
• Not SysOps renamed. Host operations (processes, logs, patching a VM) remain 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.
• Not a synonym for DevOps. TechTarget calls CloudOps “often considered a subset or part of DevOps”.^[1] This Atlas treats 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.^[7]

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

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”.^[13] So everything passing through the control plane is governed, and the services that must recover fastest do not need it during an incident.

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”.^[17] 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).

1. Hierarchy. AWS: root → organisational units (OUs) → accounts. Azure: management groups (up to six levels, as of October 2026) → subscriptions → resource groups.^[18] Google: organization → folders → projects; policies “flow down the hierarchy”.^[19]
2. Guardrails. Preventive (block the action), detective (report drift) or proactive (check before deployment).^[14] 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),^[20] 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.^[21][22][23] Google separates allocation quotas, rate quotas and system limits; system limits “cannot be increased or decreased”.^[23]
4. Regions and zones. The unit of latency, residency and failure isolation. AWS Regions introduced after 20 March 2019 must be enabled before use.^[24]
5. Provider signals. AWS Health, Azure Service Health and Google Personalized Service Health report incidents, maintenance and changes that affect you.^[25][26][27]
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),^[28] baseline alarms, and scaling-group maximums that fit the quota (this page’s rule). AWS notes that “Auto Scaling is a control plane activity”.^[17] Workload dashboards and SLO alerts belong to ObservabilityOps and SRE; cluster autoscaling to KubernetesOps.

This Atlas teaches the model here; CloudSecOps applies it to security controls and NoOps uses it to estimate the work that remains.

Rows 1–4 and 8 follow Microsoft’s matrix;^[32] 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”.^[33] Google adds “shared fate”, supplying guidance and secured infrastructure code.^[34] 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.

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.^[16] The RACI below generalises the split (this Atlas’s proposal; R = responsible, A = accountable, C = consulted, I = informed).

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

• Day 0, design. Hierarchy, Regions, baseline, guardrails, identity, network and monitoring; Azure’s eight landing-zone design areas make a usable provider-neutral checklist.^[35]
• 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”).^[36]
• 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.^[37]

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”.^[38] On Azure, Enroll mode is for “staged enforcement through policy enrollments”, and resource selectors widen an assignment by location or type.^[36] When a guardrail blocks an urgent change, the exception path decides (template in Templates).

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”.^[39] Azure divides a landing zone into a platform landing zone and workload landing zones.^[10] Two AWS details shape the design: “SCPs don’t affect users or roles in the management account”,^[40] and AWS advises: “Avoid deploying workloads to the organization’s management account”.^[41]

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

Trade-offs. More accounts mean smaller blast radius and per-account quotas,^[42] 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.

Microsoft lists “Define network topology” and “Configure shared networking (virtual network peering, on-premises connectivity)” as central duties.^[16] CloudOps owns four decisions; running and changing the network belongs to NetOps and 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.^[43]
2. Topology. A hub per Region carries shared connectivity; workload networks are spokes: AWS Transit Gateway (a Regional hub-and-spoke service),^[44] Azure hub-spoke virtual networks,^[45] or a Google Shared VPC host project.^[46]
3. Private access to managed services: AWS PrivateLink and VPC endpoints,^[43] Azure Private Link,^[45] Google Private Service Connect.^[47]
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.^[43][45]

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

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

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

Acceptance criteria: the checklist in Checklists. Provider tooling exists: AWS Account Factory for Terraform “sets up a Terraform pipeline to help you provision and customize accounts”;^[48] Azure subscription vending is “a platform mechanism for programmatically issuing subscriptions to workload teams”.^[15]

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,^[49][50] as does AWS’s deny policy attached as an SCP per OU.^[51][38] 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^[52] and the awsRegion field of CloudTrail records.^[53] 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”.^[49] 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;^[51] Azure’s “Allowed locations” excludes resource groups (a separate policy covers them) and the global location.^[54] 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”.^[55]

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;^[56][57] 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.^[58] Azure’s “Require a tag on resources” “Does not apply to resource groups”,^[54] and “Resources don’t inherit the tags you apply to a resource group or a subscription”.^[59] 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).^[60] FinOps decides what each tag means.

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

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).^[66] NoOps filters, to test one account’s rules; Artefact 4 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.^[67] Where no such control exists, use maintenance windows per environment and track every deprecation notice to closure.

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.^[73] The workload team answers; CloudOps adds the estate questions (quotas, Regions, signals) and tracks the actions.

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.

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”.^[76] 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”.^[77] Azure SRE Agent has “Review” and “Autonomous” run modes.^[78] This page’s recommendation: agents read freely, but every control-plane write runs in review mode, under the same guardrails as a human.

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.

# 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.^[36][55] 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;^[50][51] policy language belongs to IAMOps.

Example status: syntax-checked (bash -n); not executed (requires an Azure tenant). Policy ID and parameter name taken from the built-in definition.^[79]

#!/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.^[55]

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.^[58][57]

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

{
  "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.^[80][66] 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”;^[81] route on detail.affectedAccount.^[82] 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.^[83]

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

#!/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.

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.

{
  "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}
  ]
}

"""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:

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.

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.^[84] 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.^[85][86]

[
  {"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}
]

#!/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.^[87] 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.

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.^[88]
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.^[89]
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.^[88] Can operators fail over without a new console session (automation, break-glass; see 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.^[9] Teardown: none; file the backlog.

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.^[76] 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”.^[76] Method: an external probe and alert path. Success criterion: a provider-wide outage pages you within minutes, whatever the status page says.

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.^[88] 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.

DORA advises: “Avoid measuring success based on the percentage of workloads hosted on cloud servers”.^[5] The first two rows below are DORA’s suggestions; the rest are this page’s proposals.

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,^[21] so a 10-day runway is thin and a 30-day horizon is a sensible default.

Who secures which layer follows the shared responsibility split; which security controls to enforce is 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);^[71] the EU Data Act sets cloud switching rules.^[72] This page describes operational consequences, not legal advice.

CloudOps deploys budget alerts; 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.^[91] 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;^[92][93] Azure likewise “checks quota and capacity separately”.^[22] Region choice can also change carbon; see GreenOps.

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

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

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

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

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.

#!/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).^[94][25]
3. Remediate as the figure shows; for throttling, retry with growing, varied waits;^[92] 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.

• One big account. Everyone shares its quotas, blast radius and bill.^[42]
• 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.^[95]
• 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”.^[96]

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) and on-premises estates (ITOps, 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”.^[97] Power, facility and local network stay with ITOps and NetOps.

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

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

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.

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

Dependencies: identity integration (IdentityOps), an IaC pipeline (InfraOps), tag definitions (FinOps). Quick wins: signal routing and quota alarms.

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

Account request (vending intake)

Guardrail exception

Quarterly scorecard

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

We have one account and five engineers. Do we need a landing zone? Not a full one; see when to use. 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.

Who owns quotas? Both, as in the RACI: workload teams forecast and stay within quota; the platform team monitors limits and files increases.^[16] 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;^[4] 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.^[98] 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.

• AI agents in operations. Agents exist (see 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 may make exit tests cheaper; their effect on multi-cloud economics is speculative.

• Prerequisites: 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), an address plan, required tags in WARN mode, Lab 3 with a real team.
• Specialise: security guardrails (CloudSecOps), policy language (IAMOps), reliability (SRE) or recovery (DisasterRecoveryOps).
• Portfolio project: an estate design file, a vending pipeline and a game-day report for a sample organisation.

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?

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

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

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?

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

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.

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.

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).