CloudOps

WHAT IT IS. CloudOps is the discipline of operating a cloud estate — accounts, networks, compute, storage, identities — as a reproducible system rather than a collection of consoles someone clicked. Its three load-bearing practices are infrastructure as code (the estate's desired state lives in version control and is applied by automation), tagging governance (every resource attributable to a service and owner, enforced at creation, not audited later), and guardrails (organization policies that make the dangerous configurations undeployable — public buckets, unencrypted volumes, over-privileged roles). WHY IT EXISTS. Cloud velocity without governance compounds silently: every console click is state nobody can reproduce, every untagged resource is spend and risk with no owner, and every "temporary" exception is permanent. The failure mode is not dramatic — it is an estate that cannot be rebuilt, defended, or costed, discovered all at once during an incident or an audit. AWS's Well-Architected Framework (the operational-excellence, security, and reliability pillars linked below) is the reference for the trade-offs. WHEN TO USE IT. The moment a cloud footprint outgrows one person's memory — practically, past a handful of services or a second account. Below that, a single well-documented account is fine; above it, the absence of IaC and tagging converts smoothly into an unrecoverable mess. WHO OWNS IT. A platform or cloud group owns the landing zone: account structure, network baseline, guardrail policies, the IaC toolchain, and the tagging standard. Service teams own their resources inside that frame — their Terraform modules, their tags, their quota headroom. The split is "guardrails central, driving local." WHAT GOOD LOOKS LIKE. The entire estate can be rebuilt from version control plus data — a DR rehearsal proves it periodically. Tag coverage is above 95% and enforced by policy, so cost allocation and blast-radius analysis are queries, not projects. Changes to infrastructure go through the same PR flow as code, with plan review. Well-Architected reviews run on a cadence per tier-1 service, and the trade-offs they surface (cost vs. redundancy, latency vs. region spread) are written decisions with owners — not folklore. HOW TO IMPLEMENT. Freeze console mutations for new resources first (break-glass documented), then backfill IaC one service at a time starting with the most critical — import existing state, do not rebuild. Enforce the tagging standard with a policy that rejects non-compliant creates. Turn on the guardrail policies that map to your actual incidents. Then schedule the first Well-Architected review for the service you would least like to lose. HOW TO ASSESS YOURSELF. The production readiness assessment scores redundancy, backup, DR, and capacity — the cloud-runtime controls — with every point traceable: /assess. Related: /platform-engineering turns these practices into self-service for product teams, /gitops adds continuous reconciliation of the declared state, /finops prices the estate, /resilience-engineering rehearses losing pieces of it.