Day-two operations that keep the bill and the pager quiet.
After the migration the work changes. Certificates expire. A Kubernetes version drops out of support, and a dev account everyone forgot about starts costing more than production. We run the day-two side of AWS, Azure and Google Cloud, or set it up so your own team can.
Cloud management is the day-two work: monitoring, patching, backup, cost control, access hygiene, and keeping infrastructure code in step with what's really running.
Cohash runs it on AWS, Azure and Google Cloud, or builds it for your team. We tie every alert to a runbook and schedule patching against vendor support dates. Restores get tested, cost is reported in the FOCUS format, and cloud permissions nobody uses get removed.
you probably need this if
Alerts page the on-call engineer all night and most of them need no action.
Nobody has restored a backup since the system went live.
A managed database or Kubernetes version reaches end of support and the upgrade becomes an emergency.
terms on this pageDriftdefinitionWhen a live configuration slowly wanders away from what you intended, often through emergency edits nobody tracked.explained in a field note →RunbookdefinitionA step-by-step procedure, written down, for an operational job such as a cutover. An on-call engineer should be able to follow it.explained in a field note →FinOpsdefinitionTreating cloud spend as an engineering problem. Resources get tagged, costs land with the team that owns them, and someone acts on them while the numbers are still fresh.explained in a field note →
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Cloud Management, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · cloud management3 open
openAlerts page the on-call engineer all night and most of them need no action.
recurringNobody has restored a backup since the system went live.
blockedA managed database or Kubernetes version reaches end of support and the upgrade becomes an emergency.
exposure
Monitoring and on-callPatching and end-of-support…Backup and restore testingFinOps reportingDrift detectionCloud permission reviews
startrehearsehandover
Baseline
Fix the urgent items
Operate
Review monthly
we are here
ready to hand over
The clusters reach a version in standard support before AWS upgrades the control plane…
The pager only goes off for things that need someone awake.
Each remaining service principal has an owner, a scope that fits its job and, where…
Runbook library linked from each alert
chapter 01 · where it hurts
Why teams reach out
Alerts page the on-call engineer all night and most of them need no action.
Nobody has restored a backup since the system went live.
A managed database or Kubernetes version reaches end of support and the upgrade becomes an emergency.
chapter 02 · what we change
How we solve it
Monitoring and on-call
Patching and end-of-support tracking
Backup and restore testing
FinOps reporting
Drift detection
Cloud permission reviews
chapter 03 · how it runs
Our approach
Baseline
Fix the urgent items
Operate
Review monthly
chapter 04 · where you end up
What changes
The clusters reach a version in standard support before AWS upgrades the control plane on its own schedule.
The pager only goes off for things that need someone awake.
Each remaining service principal has an owner, a scope that fits its job and, where possible, no secret at all.
Runbook library linked from each alert
what we do
Where we spend the hours
6 areas of work, each one done by an engineer who has run it in production.
Alerts tied to service-level objectives and a runbook for each one. If an alert has no action attached, we delete it or fix it.
Operating systems, runtimes, managed databases and Kubernetes versions tracked against vendor support dates, so upgrades are scheduled before they're forced.
Restores carried out on a schedule and timed against the recovery objectives written for each workload. A backup nobody has restored is only a hope.
Tag enforcement, rightsizing, commitment planning and cost exports in FOCUS, the FinOps Foundation's open billing schema, now at version 1.4, so AWS, Azure and Google Cloud spend can sit in one report.
Terraform plans run against every environment on a schedule. If someone changed something in the console, it shows up as a diff, and we either codify it or revert it.
We use each cloud's access analysis tooling to find roles, service principals and service accounts with permissions they haven't touched in months. Then we trim them with the team that owns them.
capability 01 / 06in production
Monitoring and on-call
Alerts tied to service-level objectives and a runbook for each one. If an alert has no action attached, we delete it or fix it.
Operating systems, runtimes, managed databases and Kubernetes versions tracked against vendor support dates, so upgrades are scheduled before they're forced.
Tag enforcement, rightsizing, commitment planning and cost exports in FOCUS, the FinOps Foundation's open billing schema, now at version 1.4, so AWS, Azure and Google Cloud spend can sit in one report.
Terraform plans run against every environment on a schedule. If someone changed something in the console, it shows up as a diff, and we either codify it or revert it.
We use each cloud's access analysis tooling to find roles, service principals and service accounts with permissions they haven't touched in months. Then we trim them with the team that owns them.
We pieced these together from Cloud Management situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
EKS clusters on Kubernetes 1.31 as extended support runs out
composite · not a client story
Beforethe situation
Three EKS clusters still run Kubernetes 1.31. Standard support ended in November 2025, extended support ends on 26 November 2026, and the clusters have paid the extended support rate all year. Two Helm charts still use removed APIs.
What we dothe work
Scan manifests and Helm releases for removed APIs, update the VPC CNI, CoreDNS and kube-proxy add-ons, and upgrade one minor version at a time in a non-production cluster first. Upgrade managed node groups separately, since a control plane upgrade doesn't touch them.
Afterwhere you end up
The clusters reach a version in standard support before AWS upgrades the control plane on its own schedule. The patch calendar now shows each cluster's next end-of-support date months ahead.
case file 02
A pager that fires hundreds of times a week
composite · not a client story
Beforethe situation
On-call gets a few hundred alerts a week from CloudWatch and Azure Monitor. Most are CPU thresholds on autoscaling groups and nobody acts on them. Last month a real database failover went unnoticed in the noise.
What we dothe work
Export a month of alert history and mark each alert as acted on or ignored. Delete or downgrade the ignored ones, rewrite the rest against SLOs such as error rate and latency, and attach a runbook link to every alert that pages a person.
Afterwhere you end up
The pager only goes off for things that need someone awake. Each page comes with a runbook, and once a month the alert list gets reviewed together with the incidents.
case file 03
Service principals holding Owner on subscriptions nobody remembers
composite · not a client story
Beforethe situation
An Azure tenant has dozens of service principals with Owner or Contributor at subscription scope. Some belong to pipelines from projects that ended years ago, and their client secrets are still valid.
What we dothe work
Pull role assignments and sign-in logs for every service principal and match each to an owner. Disable the ones with no sign-ins for months, then delete them after a waiting period. Scope the rest to resource groups and move pipeline principals to federated credentials so their secrets can go.
Afterwhere you end up
Each remaining service principal has an owner, a scope that fits its job and, where possible, no secret at all. The review repeats in the monthly operations meeting.
Where day-two operations sit around your running cloud
Running workloads send metrics, billing and configuration data into the operations layer. That layer turns it into alerts with runbooks, cost reports, drift diffs and access reviews that go back to the owning teams.
Access analysisunused permissions → Monthly review · trim list
04 · Owners
On-call and ticketsITSM · paging
Monthly reviewcost · risk · end-of-support dates
Read the diagram as text
Workloads → Metrics and logs: telemetry
Data services → Billing exports: usage
Metrics and logs → Operations runbook: SLO alerts
Scheduled Terraform plan → Operations runbook: drift diff
Cloud identities → Access analysis: last-used data
Operations runbook → On-call and tickets: incident
Billing exports → Monthly review: cost by owner
Access analysis → Monthly review: trim list
how it runs
A typical engagement
We don't start a step until the last one has produced something you can check.
step 01
Baseline
We review alerts, patch levels, backups, spend, drift and permissions, and rank what we find by risk.
step 02
Fix the urgent items
Unsupported versions, untested backups and over-permissioned identities first.
step 03
Operate
Run the agreed scope, whether that is business hours or around the clock, with tickets and changes in your systems.
step 04
Review monthly
Cost, incidents, upcoming end-of-support dates and access review results, with a short list of decisions for you.
you keep
What you're left with
We write these for your Cloud Management setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Put these to anyone bidding on your Cloud Management work. The ones who've done it answer differently from the ones who've read about it.
Q1
Which alerts will page a person, and can we read the runbook for each before go-live?
An operations contract that inherits every existing alert inherits the noise too. The page list and its runbooks show whether the partner has studied your estate or only priced it.
Q2
When was each of our backups last restored, and how long did the restore take?
A green backup job tells you nothing about how long recovery takes. What auditors and incident managers need is a dated restore log, measured against each workload's recovery objective.
Q3
How will you track Kubernetes and managed database end-of-support dates for us?
EKS gives each version 14 months of standard support and 12 months of paid extended support. After that it upgrades the control plane itself. Miss the dates and you pay for it, first in money and then in stability.
Q4
What standing permissions will your operators hold in our accounts?
Managed service staff often get permanent admin roles. Ask for just-in-time elevation through your identity provider, session logging and a written removal process for contract end.
Q5
Against what baseline will you report savings, and who checks the numbers?
Savings claims without a dated baseline can't be verified. FOCUS-format exports make before and after comparable across clouds, and your finance team should be able to rerun the math.
01Do you operate the environment or hand it over?
Either. Some clients want us on call. Others want the monitoring, runbooks and pipelines built so their own team can run them. We agree the split up front.
02What drives the cost of managed cloud operations?
The number of accounts or subscriptions, the hours of coverage, how many workloads need change management, and whether you need compliance evidence produced on a schedule.
03Can you reduce our cloud bill?
Usually there is waste in idle resources, oversized instances and missing commitments. We measure it before quoting any saving, because the number depends entirely on your usage.
04Do you manage Kubernetes clusters?
Yes, on EKS, AKS and GKE. That includes version upgrades on each provider's schedule, node pool changes and pod-level workload identity.
05Will you work inside our ITSM tool and change process?
Yes. Tickets, changes and incidents go through your ServiceNow, Jira Service Management or equivalent, and our engineers follow your approval rules. We'd rather not run a separate queue, because it hides the work from your own team.
related
Often paired with
Projects on Cloud Management usually end up touching one of these, so they're worth a look.
