The article
The engineer who set up your AWS account left last year. The product still runs and the bill still arrives, but nobody can say what all of it pays for, or who still holds the keys.
That is the moment to look at AWS managed services providers. I have been building software for 18 years. At 26 Lines of Code, a team of 70+ specialists, our DevOps engineers run AWS accounts - updates, monitoring, backups, access and costs - and our developers change the app when the cloud calls for it. Here is what the AWS part of our cloud work covers, what it costs and a check of your bill you can run this week.
AWS managed services providers: the short version
| What | With us |
|---|---|
| What we run | Servers, containers, serverless functions, databases, storage, networks, access, alerts and the bill |
| Who does it | DevOps engineers you know by name, with our developers on the same account |
| How it starts | A role in your account with only the rights the work needs, then a review |
| Your AWS bill | Stays in your account, paid by you to AWS |
| Our price | A monthly fee named after the review; the first call and the rough estimate are free |
| Who it is for | A product on AWS with no DevOps engineer of its own, or whose engineer has left |
Three things called AWS managed services
The words mean three things, and it helps to know which one you are buying:
- AWS's own managed services. With Amazon RDS, Lambda or Fargate, AWS runs the machines underneath. The sizes, the access, the backups and the bill stay yours.
- AWS Managed Services, the product. AWS sells its own operations service under this exact name, AMS. Its Advanced plan stopped taking new customers on June 30, 2026, and AWS points them to its Accelerate plan, a support plan or a partner.
- A provider. An outside company that runs your account day to day. AWS validates some of them in its MSP program, after a third-party audit.
AWS managed services providers are the third kind. In October 2026, Google's top ten for this search held two provider pages, both blog posts, and I added a third that covers all three big clouds.
Two of the three lean on a badge: a partner tier or certified architects. None says who would do the work or what it costs, and those are the two things to ask any provider. Three pages are a small sample.
Before you build, and the takeover in four steps
Before you build, the same engineers answer the next decision: which services to use, how to split accounts and environments, what a new feature will cost to run. The architecture then fits the budget instead of surprising it.
Taking over goes in four steps:
- Access. You create a role in your account with only the rights the work needs, and you can remove it at any time.
- Review. Security, costs, backups and anything running that nobody uses. You get the fixes and the price of running the account.
- Fixes. Urgent problems first; a second engineer reviews every change.
- Running. Updates, alerts and cost checks by engineers you know by name.
Where an AWS bill leaks: a cost check
These are the places I would look first, and you can check each of them in the AWS console yourself.
| What to look for | Where | What it usually means |
|---|---|---|
| Servers busy a small part of the day | Compute Optimizer; CPU graphs in CloudWatch | A smaller instance type would do the same work |
| Disks with no server, old snapshots | EC2: volumes marked "available"; snapshots | Leftovers of deleted servers, billed every month |
| Test environments running nights and weekends | Cost Explorer by account or tag, day by day | A schedule can stop them outside working hours |
| Logs kept forever | CloudWatch Logs, the retention column | A new log group never expires unless someone sets a period |
| Steady servers at on-demand prices | Savings Plans coverage in Cost Explorer | A one- or three-year commitment costs less |
| Load balancers and public IP addresses with nothing behind them | EC2 | Billed by the hour, traffic or not |
When we take over an account, we run the same review and show what each change would save before we make it.
Our work: code and cloud in one team
When a slow page turns out to be a slow query, the person who finds it can fix it: with developers and DevOps engineers on one team, a problem is solved where it is, not passed between two companies. From our case pages:
- Mutualz, a restaurant app from Oldenburg, Germany, is live on the App Store and Google Play in German and English, on Flutter, Node.js and AWS. The hard part was losing nothing between the app, the restaurant and the backend: orders, points and user activity are tracked end to end.
- RxPhoto keeps before-and-after photos for clinics. We worked on the backend, the web front end and the API behind the mobile app, and we support the platform; its stack includes CloudFront, Amazon's content delivery network, and per rxphoto.com it stores more than 80 million photos. The hard part was one record per patient: photos, videos, forms and notes in one place instead of separate systems.
- AAE Plugin brings generative AI into Adobe After Effects. GPUs were the expensive part, and the fix was in the architecture, not the console: asynchronous GPU workers run when there is a task, so the product never pays for idle hardware.
What it costs and what stays yours
We price by the account: how many services and environments it holds and how much of it has to keep running. After the review you get a monthly price for an agreed list of work; how we price managed cloud has the details. A DevOps engineer inside your own team is staff augmentation, from $35 an hour depending on the role.
The account, the data and the AWS bill stay yours, and every access we use is written down, so leaving us comes with a ready list of what to revoke. One check worth doing today: the root user of an AWS account signs in with the email address the account was opened with. That inbox should belong to the company, not to the engineer who left, and the root user should have multi-factor sign-in.
When you need something else
- One small site or a single server: outsourced hosting or server maintenance may be enough.
- Not on AWS yet, or leaving it: start with cloud migration.
- Part of your setup in Azure or Google Cloud: that is multi-cloud management.
Show us your AWS setup: we review the account and tell you what to change and what running it would cost. The rest of what we run is on managed cloud services.
