AWS is running. Knowing what it costs and who can change it is the problem.
The account was opened years ago by someone who has since left. It works, until it has to change.
Workloads spread across accounts nobody has inventoried, with a root user and long-lived access keys still in play.
No clear boundaryThe bill grows month on month, nobody can attribute it to a team, and Savings Plans were bought once against a workload that has since changed.
Growing, unattributedHalf the estate is Terraform and half was clicked in, so the code no longer describes what is running.
Code out of dateOne engineer understands the VPC design, the IAM boundaries and why that one security group exists.
Single ownerWe run AWS. Landing it in the first place is a separate job.
Where this sits relative to the work either side of it, so you can tell what you are and are not buying.
Cloud Enablement
Getting onto AWS properly in the first place: landing zones, migration and the architecture underneath.
Go to the pageAWS, operated
Day-to-day operation of an AWS estate: patching, identity, network, backups, cost and on-call. Continuous rather than scoped.
Site Reliability
When the question stops being "is it up" and becomes "what is our error budget".
Go to the pagePlenty of clients buy one layer and run the rest themselves. That is a normal outcome, not a half-sale.
What running AWS actually involves
Accounts, identity and guardrails
Organizations with an account-per-environment boundary, SSO through IAM Identity Center rather than long-lived keys, permission boundaries and Service Control Policies, and CloudTrail landing somewhere nobody can quietly delete.
Network
VPC design that survives a second region: subnet strategy, Transit Gateway or peering where each fits, PrivateLink for the services that should never traverse the internet, and egress you can actually account for.
Compute and workloads
EC2, ECS, EKS or Lambda chosen for what the workload is rather than what is fashionable — with autoscaling, Graviton and Spot where the workload tolerates them.
Data and backup
RDS or Aurora with a restore that has been rehearsed, S3 lifecycle and object-lock where retention matters, and AWS Backup policies you can produce evidence from.
Cost
Tag policy that survives contact with engineers, Cost Explorer and Budgets wired to the teams who cause the spend, Savings Plans and Reserved Instances reviewed against observed usage rather than bought and forgotten.
Observability and response
CloudWatch, Prometheus and Grafana where each earns its place, alerts that mean something, and an on-call rota with runbooks during UK and EU hours.
Investigate, implement, hand over
What is genuinely running: accounts, workloads, identity, network, backups, cost, and how a change reaches production today. You get a written picture of the current state and a scope in priority order — what is dangerous, what is expensive, and what can wait.
The priority items, in sequence, as code in your repositories. Rehearsed in the lower environments first, with the rollback run rather than described. Nothing goes in that your own engineers cannot read.
Runbooks, architecture decisions and the reasoning behind them, written down. A working session per area with your team. We stay on-call afterwards only if you want us to.
AWS runs the infrastructure. Count what is left.
This is the honest version of a comparison most pages skip. The provider takes real work off you — and it takes one layer, not the stack.
AWS
The physical estate, the hypervisor, the managed service control planes, and the availability commitments in their SLAs. AWS does this well, and it is genuinely worth paying for.
What is left
Account structure and IAM. Network design. Patching and AMI currency. Backup and rehearsed restore. Observability. Cost. Data residency decisions. And every workload running on top.
What you are actually choosing between
| Option | Left as code | Runs day to day | Actively cuts cost | Security you can evidence | No key-person risk | Best fit when… |
|---|---|---|---|---|---|---|
| Hire in-house | the work is genuinely continuous — then hiring is the right call. | |||||
| Generalist MSP | you only need the lights kept on. | |||||
| Leave it alone | nothing has broken, been audited, or been queried yet. | |||||
| OpsHero | the work comes in bursts and has to outlast us. |
Managed AWS is not right for everybody
With one production workload and an engineer who enjoys running it, a managed AWS contract mostly buys you a second opinion. Below roughly ten engineers you are usually better served by a scoped piece of work — a landing zone, a cost exercise — than by a monthly retainer. We would rather say that on a page than halfway through an engagement.
None of it is true yet. Worth a conversation.
Your answers stay in your browser.
The ones people actually ask
We already have an AWS partner.
Then the useful question is what they own. Many partners resell capacity and answer tickets. If upgrades, cost attribution, IAM boundaries and rehearsed restores are still yours, that is the gap we fill — and if they are not, you do not need us.
Can you take over an estate somebody else built?
Yes, and it is the normal case rather than an exception. An estate nobody has documented is the engagement, not a reason to be embarrassed.
Do you resell AWS capacity?
No. You keep your own billing relationship and pay AWS directly. We are not in the middle of it, and you can end the engagement without a migration.
How do you handle security?
By mechanism: SSO instead of static keys, permission boundaries and SCPs, CloudTrail you cannot quietly delete, secrets in Secrets Manager or Parameter Store, and infrastructure-code scanning in the pipeline. Note that AWS compliance certifications belong to AWS; we tell you what we implement and what it evidences.
Will we be locked in?
Your repositories, your accounts, your estate — documented and reproducible. Nothing we build depends on us still being here.
Talk to an AWS engineer
Not a salesperson. You will get a read on your estate, the specific risks in it, and what the work would involve.
- A written picture of what is actually running, and what state it is in
- The risks in priority order — dangerous, expensive, and can wait
- What the work would involve, and in what sequence
- Everything delivered into your own repositories and cloud accounts