What Is CloudOps? A Practical Guide to Cloud Operations

What is CloudOps?

The migration finishes. The project team that ran it goes back to its day jobs. Three months later the bill has grown by 40% with no clear explanation, an outage takes four hours to resolve because nobody is certain who owns the service, and an auditor asks for evidence of quarterly access review that nobody has been collecting.

Nothing went wrong, exactly. The organisation simply never decided who runs the thing now.

CloudOps is the answer to that question. Cloud operations is the practice of running cloud infrastructure in production: provisioning and decommissioning it, watching it, fixing it, governing who can change it, and keeping what it costs in proportion to what it does. It is sometimes called cloud operations management, and it picks up exactly where the migration project puts things down.

It became a distinct discipline because cloud broke the old model. In a data centre, a central team owned the hardware and anything new had to go through them. That was slow, but the slowness was also a control. In cloud, an engineer with the right IAM permissions can create thirty resources before lunch, in an account nobody has tagged, in a region the company does not officially use. The central team no longer owns the infrastructure — and yet someone is still accountable for its cost, its security and whether it stays up.

CloudOps fills that gap. It is not a rebrand of ITOps, though it inherits a great deal from it. It is not a synonym for DevOps, though the two overlap heavily and work badly when run by people who do not speak daily. And it is not a product you buy, which is worth saying plainly given how much of the writing on this subject arrives with a logo attached to the end of it.

CloudOps vs DevOps vs ITOps vs SRE

Four terms, heavy overlap, and most teams use at least two of them to mean the same thing. The confusion is understandable, because all four are responses to the same underlying problem — software has to keep running after somebody writes it — and they were invented at different times by different parts of the industry.

The useful distinction is not what each one does. On a whiteboard, the activity lists look almost identical: automate, monitor, respond, improve. The distinction is what each one is accountable for, and what number its lead gets asked about in a quarterly review.

Read the table by column and the boundaries become obvious. DevOps is judged on how fast change moves. CloudOps is judged on what the running estate costs and whether it stays up and compliant. Those two goals pull against each other often enough that keeping them in one team tends to mean one of them quietly loses.

Where CloudOps and DevOps overlap

Heavily, and that is fine. Both automate relentlessly, both treat manual repetition as a defect, both live in version control. The split is scope: DevOps owns the pipeline, CloudOps owns what the pipeline deploys onto. A DevOps engineer cares that the deploy succeeded in four minutes. A CloudOps engineer cares that the deploy created a load balancer in a subnet with no NAT gateway, in an untagged account, that will cost ₹18,000 a month until somebody notices.

Where this gets genuinely difficult is organisational rather than technical — who owns the Terraform repository, whether to merge the two teams, how to change it without a turf war. That is a longer answer than it belongs here: CloudOps vs DevOps: where the responsibility actually splits covers the four shapes teams land in and gives a responsibility split you can copy.

Is CloudOps just ITOps with a new name?

Partly, and pretending otherwise is how these articles lose credible readers. The goals are the same ones ITOps has always had: keep it running, keep it secure, keep it within budget. Three things genuinely changed. Provisioning became self-service, so control has to be designed in rather than enforced at a request queue. Billing became consumption-based, so cost is now an engineering variable rather than an annual procurement event. And infrastructure became code, so operations became a software problem with software’s tooling and software’s failure modes. The name is new. The change underneath it is real.

Do you need CloudOps if you already have SRE?

Yes, and they coexist comfortably because they work at different widths. SRE goes deep on a small number of services that must not fail, with error budgets and SLOs as the governing mechanism. CloudOps goes wide across the whole estate — including the internal tool nobody loves, the dormant dev account and the analytics workload that quietly became the second-largest line on the bill. Where the two meet, SRE usually sets the reliability bar and CloudOps owns the platform that makes meeting it possible.

What a CloudOps team actually does

Red Hat frames cloud operations as three jobs — orchestrate, operationalise, govern. It is the cleanest model anyone has published on this, and it is worth borrowing. It is also missing a fourth function that every team I have seen spends real time on, so here it is with that addition.

Orchestrate — getting infrastructure into existence

A product team needs a new environment. In a mature setup, they request an account, it is vended from a template with guardrails and a billing tag already attached, network connectivity is established, and they are running the same afternoon. In an immature one, they open a ticket, wait a week, and get a hand-built account that resembles nothing else in the estate.

Orchestration covers account structure, landing zones, infrastructure as code, provisioning and — the part everyone skips — decommissioning. Most of the waste on a mature cloud bill is not oversized; it is simply forgotten. Things were created for a reason that expired and nobody had a process for taking them away.

Operationalise — keeping it running

An alarm fires at 02:40. Whether that is a two-minute acknowledgement or a two-hour incident depends almost entirely on work done months earlier: whether the alert corresponds to something a user would notice, whether the runbook exists, whether the person paged has the permissions to fix it without waking somebody else up.

This is the day-to-day surface — monitoring, alerting, incident response, patching, backup verification, routine change. It is also where CloudOps teams accumulate the most toil, because every new workload arrives with its own alarms and its own edge cases and very little of that is standardised unless somebody actively standardises it.

Govern — deciding who may do what

Someone opens a security group to 0.0.0.0/0 on a Friday evening. Governance is the difference between finding out on Monday from a dashboard, finding out in six weeks from an auditor, or the change simply being prevented at the policy layer and never happening.

Governance covers identity and access, tagging standards, policy as code, compliance evidence, backup and disaster recovery. It is the least popular function and the one that determines whether the other three can be trusted to run at speed. Governance done well is invisible and feels like freedom; done badly it is a spreadsheet nobody updates.

Optimise — keeping the cost honest

The bill arrives. It is 18% higher than last month. Someone asks why, and the honest answer takes three days to assemble because nothing is tagged consistently and two teams share an account.

Optimisation covers rightsizing, commitment planning, waste removal, storage lifecycle and performance tuning. It overlaps with FinOps and the boundary is worth stating: FinOps is the financial discipline — allocation, forecasting, showback, the conversation with finance. CloudOps is the engineering half — actually changing the instance type, actually deleting the volume, actually moving the data to a cheaper tier. FinOps decides what should happen. CloudOps is who makes it happen, which is why the two functions fail together when they are not talking.

CloudOps on AWS: what it looks like in practice

Most writing on cloud operations says “AWS, Azure or GCP” and moves on, which is how you end up with a definition nobody can act on. So here is the same four-function model mapped to the services that actually do the work on AWS.

A few of these are worth knowing in more detail, because they are the ones teams underuse.

Control Tower is the difference between an estate and a collection of accounts. Account Factory vends new accounts from a pre-approved template, and controls come in three flavours — preventive, detective and proactive — applied at the organizational unit rather than per account. Preventive controls are the valuable ones: a Service Control Policy that stops a region being used at all is worth more than a dashboard telling you somebody used it.

Systems Manager is the most underrated service on this list, largely because it is really a dozen tools under one name. Patch Manager and State Manager handle configuration drift on instances. Automation runs documented runbooks as code rather than as a wiki page. Incident Manager handles on-call rotas and escalation. One note if you are planning around it: Change Manager has been closed to new customers since 7 November 2025, so if you are designing an approval workflow today, design it somewhere else.

Compute Optimizer now covers far more than EC2 — Auto Scaling groups, EBS volumes, Lambda functions, ECS on Fargate, RDS and Aurora, NAT gateways, DynamoDB, ElastiCache and more. It works from 14 days of CloudWatch history by default; the 93-day lookback is a paid feature and is usually worth it, because two weeks of data will happily recommend downsizing something that only gets busy at month end.

What AWS gives you, and what you still have to build

The native tooling is genuinely good, and it is good at one specific thing: telling you what is wrong. Security Hub CSPM will run continuous checks against CIS, PCI DSS, NIST and AWS’s own Foundational Security Best Practices, aggregate findings from GuardDuty, Inspector and Macie, and calculate you a security score. Trusted Advisor will list your idle resources. Compute Optimizer will tell you which instances are oversized and by how much.

None of them fix anything.

That gap — between a console showing 200 findings and somebody having actually resolved them — is where the overwhelming majority of CloudOps effort goes. It is not a tooling problem, and buying another scanner makes it worse rather than better, because every new source adds findings without adding hands. It is a capacity problem, and it is the subject of the next two sections.

How to structure a CloudOps team

Almost nobody writes this part down, which is strange, because “what does this team look like” is the first question anyone asks when told to build one.

The administrator role is the one most teams skip and then regret. Without it, senior engineers spend a third of their week on access requests and tag corrections, which is both expensive and a reliable way to lose them.

How big should the team be?

As a starting rule of thumb: one cloud operations engineer per 20 to 40 AWS accounts in a well-automated estate, dropping to one per 5 to 10 accounts where provisioning is still manual and alerting is noisy. The spread between those two numbers is the entire business case for automation, and it is worth putting on a slide exactly that way.

The harder constraint is on-call. A sustainable 24×7 rota needs six engineers minimum — below that you are running a one-in-four or worse, and attrition will make the decision for you within a year. If you have four engineers and a 24×7 requirement, you have three options: reduce the requirement to business hours with best-effort overnight, buy follow-the-sun coverage from a partner, or accept that you are going to rehire this team annually.

Both figures assume a single cloud and a reasonably homogeneous estate. Multi-cloud roughly doubles the specialist count, because depth does not transfer as readily as vendors claim it does.

Centralised, embedded, or both?

Three shapes, and each breaks in a predictable way.

Centralised puts everything in one team. It is the easiest to govern and the fastest to start. It breaks when product teams begin queuing — at which point the CloudOps team is the bottleneck everyone complains about, and shadow infrastructure starts appearing in accounts nobody told you about.

Embedded puts an operations engineer inside each product team. Nothing queues and context is excellent. It breaks on governance: six teams invent six tagging schemes, five monitoring approaches and at least two opinions about what “production” means.

The platform model is centralised for the foundation and embedded for the edges. A small central team owns the landing zone, policy, the paved road and the shared tooling; product teams operate their own workloads on top of it. It works better than either alternative and it demands the most maturity, because a paved road nobody wants to drive on is just a centralised team with extra steps.

What skills does a cloud operations engineer need?

Concretely, and this list is the reason the role is hard to fill:

• Infrastructure as code — Terraform or CloudFormation, to a standard where they review someone else’s module rather than just writing their own
• One scripting language, usually Python, well enough to automate against an SDK
• Networking fundamentals — VPC design, routing, DNS, TLS. This is where most candidates are weakest and where outages get longest
• IAM, properly: roles, trust policies, permission boundaries, and the judgement to know when least privilege has become unworkable theatre
• One observability stack, deeply rather than three shallowly
• The ability to read a bill and connect a line item to a workload

That is a senior engineer. Read the list again and notice that it is not one skill set but four adjacent ones, which is precisely why the market does not produce these people at anything like the rate the job postings demand.

The reason most CloudOps teams stall

Every article on this subject lists “skills gap” as one bullet among eight challenges. That understates it considerably. For most teams, it is not one constraint among several. It is the constraint, and everything else is downstream of it.

Go back to the skill list in the previous section. Infrastructure as code, Python, networking, IAM, observability, and the ability to read a bill. That is a senior engineer with four adjacent specialisms, and in India that person is being hired by somebody else, quickly. The Zinnov–nasscom India GCC Landscape report counts 2,117 global capability centres operating 3,728 units as of March 2026, employing 2.36 million professionals — a 32% increase in centres since FY2021. ANSR’s 2026 analysis puts GCC hiring growth at 12–15% year on year in the first half of 2026, with cloud platforms named as one of the foundational competencies those centres are recruiting for.

That is the market you are hiring against. You are not competing with the company down the road. You are competing with several hundred well-funded captive centres that have been told to staff up this quarter.

The second problem is arithmetic. CloudOps work does not scale linearly with the size of the estate, because every additional account, workload and compliance standard multiplies findings rather than adding to them. Turn on Security Hub CSPM across thirty accounts and you do not get thirty findings; you get several thousand, of which perhaps forty matter this week. Deciding which forty is judgement work, and judgement does not come from a dashboard.

So teams arrive at the same place from opposite directions. Trusted Advisor has flagged a page of idle resources. Security Hub CSPM has several hundred open findings. Compute Optimizer has rightsizing recommendations worth a meaningful fraction of the bill. And there are three people on the rota, two of whom are on call this week.

The backlog is not a discipline failure. It is a capacity ceiling, and there are only three honest ways through it.

Hire and train. Works, and produces the best long-term outcome. It is also slow, expensive, and you are bidding in the market described above. Budget twelve to eighteen months before a trained hire is operating independently, and plan for the possibility that a GCC hires them at month fourteen.

Outsource to a managed service provider. Fast, and it converts a hiring problem into a commercial one. It costs margin, it creates dependency, and unless the contract is written carefully you end up paying someone else to run the same backlog with the same tooling.

Raise what each engineer can safely do. Not more dashboards — automation and, increasingly, agents that carry work from recommendation to completed change rather than stopping at the alert. This is the only one of the three that changes the shape of the problem rather than the size of it, and it is where most of the interesting work in cloud operations is happening right now. It is also the one with the most legitimate scepticism attached, which is why it gets a section of its own further down.

The CloudOps maturity model

A cloud operating model is not a document. It is the honest answer to a simpler question: when something needs to change in your cloud estate, what actually happens? Four broad answers, and most organisations can place themselves within about thirty seconds of reading the second column.

A word on level 4, because “autonomous” invites eye-rolling and mostly deserves it. It does not mean nobody is accountable, and it does not mean software makes decisions on its own. It means the routine path — the rightsizing, the patch, the tag correction, the stale snapshot — runs without occupying a senior engineer’s afternoon, while every action still passes an approval step and lands in an audit log. The distinguishing feature of level 4 is not the absence of humans. It is that humans are spending their time on the interesting 5% instead of the repetitive 95%.

Placing yourself honestly

Most teams reading this are at level 1 or 2 and believe they are at level 3. The belief is sincere — there is a Terraform repository, there is a CI pipeline, there are dashboards. The gap is usually between what exists and what is universal.

Three diagnostic questions settle it faster than any assessment framework:

1. Can you tell me, right now, what you spent last month on your largest single workload? Not the account total — the workload. If that takes more than five minutes, you are not above level 2, because you cannot optimise what you cannot attribute.
2. If someone deleted your largest production environment, how long to rebuild it from code? If the answer contains the phrase “and then we’d have to remember”, parts of your estate are not actually code.
3. What proportion of last month’s alerts resulted in someone doing something? Below about 30% and your operational signal is noise, whatever level your tooling suggests you are at.

The levels matter less than the direction. A team that knows it is at level 1 and is deliberately working on tagging is in far better shape than one at level 2 that has just bought its fourth observability product.

How to start: the first 90 days

The honest answer to “how do we start CloudOps” is that you already have it — somebody is doing this work, unnamed and probably at night. Starting a practice means making it deliberate. Here is a sequence that works, in the order it works in.

Days 1–30: find out what you actually have

Resist changing anything. The instinct is to fix the obvious waste in week one, and it is the wrong instinct, because you do not yet know what that resource is for or who will shout when it disappears.

Build four inventories instead. What accounts exist and who opened them — there are almost always more than the org chart suggests. What is running in them, by account and region, with particular attention to regions nobody admits to using. Who has access to what, especially long-lived credentials and anything with administrative privileges. And what the bill consists of — the top twenty line items, traced back to a workload and an owner where possible.

The deliverable at day 30 is not a fix. It is a document that says, accurately, what you are running and roughly what it costs. Almost nobody has this, and every subsequent decision depends on it.

Days 31–60: make it visible

Four things, in this order.

A tagging standard, enforced rather than published. Five or six mandatory tags at most — owner, environment, cost centre, workload, data classification. More than that and compliance collapses. Enforce it with preventive controls on new resources and a remediation backlog for old ones. Everything in the optimise function depends on this one step, which is why it comes first.

One dashboard everybody trusts. Not the best dashboard — the agreed one. Cost, availability and open security findings on a single screen.

Alerting that people do not ignore. Take last month’s alerts, find the ones nobody acted on, and delete them. Expect to remove more than half. Every alert that survives should correspond to something a user would notice.

A named owner for every workload. A human name, in the tags, reviewed quarterly. Unowned workloads are where waste and security debt accumulate, and they multiply quietly.

Days 61–90: automate the three most repeated tasks

Not the three most interesting. The three most repeated — and the difference matters, because engineers will reliably choose the interesting ones.

Find them from evidence rather than memory. Pull the last quarter’s tickets and on-call handovers, group them by what was actually done, and count. The list is usually more boring than anyone expects: access requests, certificate renewals, disk expansion, restarting the same service, cleaning up the same class of orphaned resource. That is good news, because boring and repetitive is exactly what automates well.

Automate those three properly — runbooks in Systems Manager Automation rather than scripts on someone’s laptop, with logging and a rollback path. Then measure the hours recovered and use that number to fund the next three. A CloudOps practice earns its budget by showing time returned, and this is the first point in the ninety days where you can show it.

What not to do first

CloudOps tools: what you actually need

By category rather than by vendor, because the category is the decision and the product is a detail you can change later.

Six of those seven categories are mature, and you probably already have something in most of them. Which is the point worth making before anyone opens a procurement process.

Most teams do not have a tooling gap. They have seven tools producing more findings than four people can action, and the instinct when the backlog grows is to buy an eighth that promises better prioritisation. Occasionally that helps. More often it adds a source, a login, an integration to maintain and a few hundred more findings, while the number of hands stays exactly the same.

Before buying anything, it is worth being able to answer two questions. What proportion of findings from the tools you already own get resolved within thirty days? And of the ones that do not, how many are blocked on knowing what to do versus having someone free to do it? If the answer is overwhelmingly the second — and it usually is — then another detection tool is not the purchase that helps.

That distinction is also why the last row in the table exists as a separate category rather than as a feature of the others.

Where AI agents fit in cloud operations

What actually changed

The gap between detection and action has been the bottleneck in operations for roughly a decade, and it has been a stable bottleneck. Tooling got progressively better at finding things and never got meaningfully better at fixing them, for a reason that was not laziness: fixing requires context. Knowing that an instance is oversized is a metrics problem. Knowing whether it can be resized during business hours, whether it is part of a cluster with quorum requirements, and whether the team that owns it is mid-release is a judgement problem, and judgement was the part that needed a person.

That is the specific thing that has shifted. Systems can now assemble context across accounts, services and history, and propose a specific change with its reasoning attached. Not decide. Propose. The distinction is the entire subject of this section.

The problem with letting an AI near production

If your first reaction to “AI operates your cloud” is a flat no, that reaction is correct and worth keeping. The objections are real and they are not addressed by enthusiasm.

Blast radius. A confident wrong action at the infrastructure layer is not a bad suggestion, it is an outage. The failure mode of a language model — fluent, plausible, incorrect — is close to the worst possible failure mode for something with API access to production.

Unreviewable actions. If a change happens and you cannot reconstruct afterwards what was changed and why, you do not have automation. You have an incident with extra steps.

Credentials leaving your environment. Any architecture that requires handing long-lived access keys to a third party has made a decision about your security posture that should be made deliberately, at a level well above the engineer evaluating the tool.

Scope creep in permissions. “It needs admin to be useful” is the sentence that precedes most of the bad outcomes in this category.

These are not objections to overcome. They are requirements to design against, and they give you a straightforward checklist for evaluating anything in this space.

What a safe agent pattern looks like

Four properties. Treat them as the minimum bar, and demand them from any vendor in this category including the one at the end of this section.

1. The agent proposes; a person approves. Nothing executes on the strength of the model’s own confidence. The approval step is a gate, not a setting.
2. The plan is legible before it runs. You see the specific actions, on the specific resources, with the reasoning, in advance — not a summary of intent afterwards.
3. Execution happens inside your environment, under your identity model. The work runs in your account, through roles you grant and can revoke, scoped to what you chose. No credentials leave.
4. Everything is audited. Every action, every approval, every actor, reviewable months later by someone who was not there.

Remove any one of the four and the pattern stops being safe. Remove the first and it is an unsupervised script with a language model attached.

A worked example

What that looks like end to end, as a scenario rather than a case study:

Ask. An engineer writes: find the biggest cost optimisation opportunities in this production account.

Plan. The agent returns what it intends to inspect and what it proposes to change, itemised — six idle EBS volumes totalling 4TB, three oversized RDS instances with 14 days of supporting utilisation data, and a NAT gateway in a subnet with no remaining workloads. Each item carries its evidence and its estimated monthly saving.

Approve. The engineer reads the plan and approves four of the nine items, rejecting the RDS changes pending a conversation with the owning team. Nothing has executed yet. Nothing executes until this step completes.

Execute. The approved changes are applied inside the organisation’s own AWS account, through IAM roles it connected and controls, scoped to exactly those permissions.

Audit. Each action is logged with its plan, its approver and its outcome, reviewable later by anyone who needs to reconstruct what happened.

The work in that sequence is not conceptually new — a senior engineer with a free afternoon does the same thing. What changes is that the afternoon is no longer the constraint, which matters a great deal if you read the section on capacity above.

CloudOpsGPT implements this pattern for AWS: the Runtime deploys into your own AWS account and performs operations there through IAM roles you connect, with no AWS access keys handed over, while the control plane handles only portal login, workspace entitlement, activation and connectivity metadata. It is one implementation in a category that is still forming, and the four properties above are worth checking against any option you evaluate, this one included.

Frequently asked questions about CloudOps

Where to go from here

If you take one thing from this, take the maturity model and place your team on it honestly. Most of the disagreement inside operations teams about what to do next is really disagreement about where they currently are, and that resolves quickly once someone tries to answer the cost-attribution question out loud.

Three places to go next, depending on which part of this is your immediate problem:

Sources

• AWS Control Tower — What is AWS Control Tower?, AWS documentation
• AWS Systems Manager — Using Systems Manager tools, AWS documentation
• AWS Security Hub CSPM — What is Security Hub CSPM?, AWS documentation
• AWS Compute Optimizer — What is Compute Optimizer?, AWS documentation
• Zinnov–nasscom India GCC Landscape Report FY2026, data as of March 2026
• New ANSR Report Finds AI Skills Driving GCC Hiring in India, September 2026