The article
Your product runs in AWS, Azure or Google Cloud, and the cloud is looked after by whichever developer has a free afternoon. The bill grows a little every month, nobody is sure which servers can be switched off, and the one person with full access is on vacation. Public cloud managed services put named DevOps engineers on that work: the accounts your product lives in, the servers, containers and databases inside them, who can reach what, and what it all costs.
I have been building software for 18 years, and since 2017 my team of 70+ specialists has delivered 150+ projects. Our DevOps engineers work next to our developers, and in a public cloud that matters more than people expect: much of the trouble that shows up on a server starts in the app. Moves between clouds and security reviews are part of the wider cloud work we do; this page is about running the cloud you are on.
Public cloud managed services: the short version
| What | How it works |
|---|---|
| Clouds | AWS, Google Cloud, Azure |
| What we run | Updates, access, backups, monitoring and costs in your accounts |
| Who does it | Named DevOps engineers, with developers from the same company for faults in the code |
| How it starts | A review of your account, then the price of running it |
| Price | Estimated after the review; the first call and the rough estimate are free |
| Your account | Stays in your name, with the data and the bill |
What changes when someone runs your cloud
The work itself is not new. What changes is that it happens on a schedule and on record, instead of when someone remembers:
- Updates for servers, containers and libraries, planned instead of postponed.
- Access: each person and each service gets only what it needs, with two-factor sign-in on every account that matters.
- Backups, checked by restoring them.
- Monitoring with alerts that reach an engineer, not a shared mailbox.
- Cost reviews, with reserved capacity where the load is steady.
- Every change written down and reviewed, so the next person knows what the last one did.
Your developers get their afternoons back, and the cloud stops depending on whoever happens to be free.
What your cloud provider does, and what stays with you
A common surprise: the three big providers run their data centers, their hardware and their own services, but much of what sits on top stays with you. The providers call this split shared responsibility. In practice, the provider will not:
- install the updates on the servers you created;
- decide who in your company can reach what, or notice that a former employee still can;
- restore your database after someone deletes the wrong table;
- point out, unasked, that a test server has been running, and billing, for a year.
That part of the work is what a managed service takes over. The provider keeps the platform up; we keep your part of it updated, closed to strangers, backed up and sized to what you actually use.
What we look after on AWS, Google Cloud and Azure
The three clouds name things differently, and the work is the same in each:
| Cloud | What we look after | More |
|---|---|---|
| AWS | Accounts, EC2, containers, RDS and the roles around them | Managed AWS |
| Azure | Subscriptions, virtual machines, App Service, databases and Entra ID | Managed Azure |
| Google Cloud | Projects, Compute Engine, GKE, Cloud Run and Cloud SQL | Google Cloud managed services |
If you use more than one of them, the same rules apply across all of them: one list of who can reach what, backups and restore tests in each cloud, and alerts in one place. That is multi-cloud management.
Where a cloud bill leaks, and how to check yours
A public cloud bill more often creeps than jumps. These are the lines worth checking first, and each one can be checked in your provider's billing and monitoring consoles:
| Line on the bill | Why it grows | How to check |
|---|---|---|
| Servers that run all night and all weekend | Test and staging machines stay on after work | Filter costs by environment and look at nights and weekends |
| Servers bigger than their load | Sized for a launch day that has passed | Average processor and memory use over a month |
| Disks and snapshots nobody uses | Left behind when a server was deleted | Disks attached to no server; snapshots older than your retention rule |
| Data leaving the cloud | Downloads, backups sent out, traffic to other providers | The data transfer lines, by service |
| Logs kept forever | Retention left at the default | The log storage line and its retention setting |
| A steady load at the full hourly rate | No reserved capacity for machines that never stop | Servers running around the clock without a reservation |
| Leftovers from old tests | Load balancers, addresses and gateways nobody removed | Resources with no owner and no traffic |
Our cost reviews follow the same list: idle resources switched off, sizes fitted to the load and reserved capacity where the load is steady. Each change comes with what it would save, before we make it.
Reserved capacity deserves a warning of its own. It is a commitment, usually for one or three years, in exchange for a lower rate, and it pays only for machines that will keep running. Reserve what has run steadily for months and will stay; a reservation bought just before a migration or a redesign is money paid for capacity nobody uses.
Your account stays yours
In October 2026 I read five of the pages Google shows first for "public cloud managed services": two providers' service pages and three guides. None of them names a price, none mentions the charge for data leaving the cloud, and only one says the account stays in the client's name. Five pages are a small sample, so read it as a list of things to ask.
With us, the accounts, the data and the bill stay in your name, and we work through roles you can see and remove. This matters most on the day you change providers: if a vendor holds the main account of your cloud, leaving means asking for permission.
There are two bills, and they stay apart. You pay AWS, Azure or Google Cloud directly, in your own account. Our fee covers the work: updates, monitoring, backups, security, support and cost reviews.
One check worth doing today, whoever runs your cloud: the main login of your cloud account belongs to your company, it has two-factor sign-in, and its recovery email is a company address, not the inbox of someone who left.
Cloud and code in one team
Much of the trouble that shows up on a server starts in the app: a slow query that looks like a slow database server, a job that leaks memory, a key left in the code. Our DevOps engineers and developers work in one company, so the fix lands where the problem began, and the question of whose fault it is never holds up the fix.
Two examples from our work:
- For Raina Music, which streams DJ-curated music to hotels and restaurants, we reworked the streaming backend for many venues at once, so playback stays smooth for a high number of concurrent listeners.
- For AAE Plugin, a generative AI plugin for After Effects, an asynchronous architecture of GPU workers ended the cost of idle hardware: the most expensive machines run only when there is work for them.
A cost problem is often an architecture problem. A discount lowers the price of idle hardware; a better design stops paying for it.
How we take over an account
The takeover is four steps:
- Access. A role in your account with only the rights the work needs.
- Review. Security, costs, backups and anything running that nobody uses.
- Fixes. Urgent problems first; a second engineer reviews every change.
- Running. Updates, alerts and cost checks by engineers you know by name.
The review ends in writing: what to change, in what order, and what running the account would cost.
Your part is the access, one person who decides, and a list of what must not stop. The list of work is agreed before we start, so it is clear what we run and what your team keeps. If you need an NDA, we sign it before you share details.
What it costs
We price the work after the review. The price depends on how many accounts, servers, containers and databases you run, how much has to stay up and at what hours, how often your software ships, the rules you must follow, and the state of the setup we take over.
You pay for it in one of three ways: a monthly plan for an agreed list of work, hours of our engineers, or a project such as a move between clouds, with its price fixed in the contract before it starts. The first call and the rough estimate are free; the details are on how we price managed cloud.
When you do not need it
- A simple website does not need a cloud team: outsourced hosting may be all you need.
- A DevOps engineer inside your own team, working in your process and reporting to your lead, is staff augmentation, with specialists from $35 an hour, depending on the role.
- A team that runs its cloud well and wants a second pair of eyes can start with a cloud security review and a list of what to fix first.
- A cloud you are about to leave, for another provider or for servers of your own, starts with a cloud migration plan; managing what stays comes after the move.
Everything else we run in the cloud is under managed cloud services. Tell us which cloud you are on and roughly what runs there; the first call is free.
