The short answer, and why it is not enough
DevOps owns the path from commit to production and is judged on how fast change moves. CloudOps owns the infrastructure that path deploys onto and is judged on what the running estate costs, whether it stays up, and whether it survives an audit. Same tooling, same culture, different accountability.
That definition is correct and almost useless on a Monday morning, because nobody actually asks it as a definitional question. They ask it because two teams are arguing about who owns the Terraform repository, or because a VP has asked whether CloudOps is a new headcount line or a rename of one that already exists. The CloudOps guide covers the definitions and the four-way comparison with ITOps and SRE. This page is about the organisational question underneath them.
Four shapes, and which one you actually have
Almost every company lands in one of these. Read the symptoms rather than the labels, because the label on the org chart is frequently wrong.
1. You have DevOps and no CloudOps
Symptoms: product teams provision their own infrastructure. Deploys are fast and nobody complains about them. The AWS bill grew 30% last quarter and the explanation took a week to assemble. Nobody can say how many accounts exist without opening Organizations and counting.
What is actually wrong: nothing, yet. This shape works well up to a point, and the point is usually the first surprise bill or the first compliance review. The failure is not technical — it is that cost, security posture and account hygiene have no owner, so they get attention only when they become emergencies.
The move: do not create a team. Create an owner. One named person, part-time, accountable for tagging, account structure and the bill, reporting into platform or infrastructure leadership. The team comes later and only if the work justifies it.
2. You renamed ITOps to CloudOps
Symptoms: the team has the new name, a ticket queue, and the same request-and-approve workflow it had when it owned physical servers. Product teams route around it. There is shadow infrastructure in accounts the team does not know about.
What is actually wrong: the operating model did not change with the name. In a data centre, a central team could be the gate because it owned the hardware. In cloud it does not own anything — it can only set policy that others operate inside. A gate that can be bypassed is not a gate, it is a queue.
The move: convert gates into guardrails. Every control the team enforces by reviewing a ticket should become a Service Control Policy, a preventive control, or a policy-as-code check in the pipeline. The team’s output changes from approvals to paved road.
3. You have both, and they are fighting
Symptoms: DevOps says CloudOps slows them down. CloudOps says DevOps leaves a mess. Both are right. Ownership of the IaC repository is contested. Someone has proposed merging them, which will not help.
What is actually wrong: the two are measured on goals that genuinely conflict — delivery speed against cost and compliance — and nobody has written down where one ends. Merging them does not resolve the conflict; it just moves it inside one team, where whichever metric the manager is personally judged on quietly wins.
The move: keep them separate and write the split down explicitly. The table in the next section is a starting point. The conflict is healthy as long as it is visible and arbitrated above both teams.
4. You have a platform team
Symptoms: a small central team owns the landing zone, policy and shared tooling. Product teams run their own workloads on it. There is an internal developer portal, or something aspiring to be one.
What is actually wrong: possibly nothing. This is the shape most organisations are heading toward. The failure mode is subtler: the paved road gets built for the platform team’s convenience rather than the product teams’, and adoption quietly stalls. If product teams are building their own escape hatches, that is the signal.
The move: measure adoption rather than compliance. What percentage of new workloads launch on the paved road without a conversation? If it is under about half, the road is the problem.
Drawing the line: a split that survives contact
Copy this, argue about it, change it. The value is in having written it down at all — most organisations never do, which is why the same argument recurs every quarter.
| Decision or artefact | DevOps owns | CloudOps owns |
|---|---|---|
| CI/CD pipeline | Yes | Consulted on deploy targets |
| Application IaC (the service’s own resources) | Yes | Reviews against policy |
| Foundational IaC (VPCs, accounts, landing zone) | Consulted | Yes |
| Account creation and structure | Requests | Yes |
| IAM roles for applications | Proposes | Approves the pattern |
| Alert definitions for a service | Yes | Owns the platform they run on |
| On-call for a service | Yes | On-call for the platform |
| Patching and OS baselines | No | Yes |
| Cost of a workload | Accountable for its efficiency | Accountable for visibility and the total |
| Tagging standard | Applies it | Defines and enforces it |
| Backup and DR testing | Defines RPO/RTO for the service | Runs and proves it |
| Compliance evidence | Supplies it | Owns and presents it |
Two things to notice. Most rows have both columns filled — the split is rarely clean, and pretending otherwise is how these documents become shelfware. And the pattern underneath is consistent: DevOps owns the service, CloudOps owns the substrate. When a new row comes up, ask which side of that line it falls on.
Making the change without a turf war
If you are moving from shape 2 or 3 toward shape 4, the sequence matters more than the destination. A reorganisation announced before the groundwork is done produces a reorganisation plus the original problem.
- Write the split before you move anyone. Circulate the table above, filled in for your organisation, and let both teams argue with it for two weeks. Disagreement at this stage is cheap. After a reorg it is expensive.
- Move one control from gate to guardrail. Pick the approval both teams find most tedious and replace it with a preventive control. This proves the model works before anyone’s reporting line changes.
- Give the platform a customer. One product team, by name, who will onboard first and tell you what is wrong with it. Not a pilot in the abstract.
- Change reporting lines last. By the time you do, the split should already describe how people actually work. The org chart documents reality rather than attempting to create it.
Expect this to take two to three quarters. Anyone promising it in one has not done it.
What breaks when you get it wrong
Three failure modes, in order of how often they turn up:
Merging the teams. The conflict between speed and cost does not disappear; it becomes invisible. Six months later the bill is still growing and nobody can point at who was supposed to stop it.
Making CloudOps a ticket queue. Product teams route around it, which is rational of them. You now have shadow infrastructure, which is strictly worse than slow infrastructure because you cannot see it.
Giving CloudOps policy authority with no engineering capacity. This produces a team that writes standards it cannot enforce and reports on findings it cannot fix. It is the most demoralising shape of the three and the easiest to create accidentally, usually by staffing the function with one manager and no engineers.
Frequently asked questions about CloudOps and DevOps
What is the difference between CloudOps and DevOps?
DevOps owns the path from code commit to production and is measured on delivery speed. CloudOps owns the cloud infrastructure that path deploys onto and is measured on cost, availability and compliance. They share tooling and culture but answer for different outcomes.
Can one team do both CloudOps and DevOps?
Small organisations do, and it works until the goals conflict. Delivery speed and cost control pull against each other, so in one team whichever metric the manager is judged on tends to win quietly. Splitting usually becomes worthwhile somewhere around ten AWS accounts or thirty engineers.
Does CloudOps replace DevOps?
No. They operate at different layers and most mature organisations run both. DevOps makes change move safely; CloudOps makes the platform that change lands on reliable, affordable and auditable. Removing either does not redistribute its work, it just leaves it undone.
Who should own the Terraform repository?
Split it. Application infrastructure — the resources a service owns — belongs to the team that ships the service, reviewed against policy. Foundational infrastructure such as accounts, VPCs and the landing zone belongs to CloudOps. One shared repository with unclear ownership is the most common source of the argument.
Is CloudOps just a rebrand of ITOps?
Partly. The goals are the same ones ITOps always had. What changed is that provisioning became self-service, billing became consumption-based, and infrastructure became code — so control has to be designed into the platform rather than enforced at a request queue.
How long does it take to separate CloudOps from DevOps?
Two to three quarters if done in the right order: write the responsibility split, convert one gate into a guardrail, onboard one named product team, then change reporting lines. Announcing the reorganisation first tends to produce the reorganisation plus the original problem.
Where to go from here
Three places to go next:
Give a mid-level engineer work that used to wait for a senior one
CloudOpsGPT proposes an itemised plan, waits for a human approval, executes inside your own AWS account through roles you control, and logs every action.
No credit card required. Your trial clock starts when the Runtime connects.