What managed AWS hosting actually includes, and what's still on you

Managed AWS hosting is not Amazon taking over your application. It is a written arrangement in which a provider looks after agreed parts of the environment in your AWS account, while you still own the account, the code and the decisions. Before you pay for it, get those parts in writing: patching, backups, monitoring, scaling and who acts when something breaks, and be clear about what stays on you.

What AWS is responsible for, and what it is not

Amazon's shared responsibility model is straightforward. AWS secures the cloud infrastructure. You are responsible for what you run in it: the operating system on a server, the runtime, the application, the data, the backups you keep, and who has access.

That second half is the work managed hosting is meant to take on, in part or in full. It is a different question from AWS vs managed hosting for a small SaaS, which is about choosing owned AWS or a simpler platform. This piece assumes you are already on AWS, or have chosen it, and are deciding what a managed arrangement should actually cover.

What a good managed AWS service should cover

These are the items worth naming in an agreement, not a standard bundle every supplier includes by default.

OS and runtime patching should have an owner. So should backups, and whether anyone actually restores them. Monitoring should say what is watched and who is alerted. Scaling, if you need it, should be described rather than assumed. And incident response needs names, hours and a next step, because an alert on its own is not a fix. We made that distinction in uptime monitoring for a small business website, and it applies here too. A backup you have never restored is the same kind of gap, which is why a backup restore test matters.

At Eight Mile, infrastructure support can include patching, backups and on-call cover, through a monthly arrangement with agreed coverage. Under a support retainer, monitoring can cover uptime, errors and cost, with an engineer alerted when a threshold is crossed. Our infrastructure work also includes backups tested by restoration and written recovery plans. Restore testing as an ongoing rhythm, scaling, and the exact shape of incident response should still be defined in that written retainer, rather than treated as automatic.

Out-of-hours cover is part of the retainer only if it is written down. Ordinary enquiries are handled during London business hours, Monday to Friday. If the bill climbs and nobody can explain it, that is often a sign that cost is not being watched, which we covered in cloud bill went up and nobody can say why.

What stays on you

• Your application: the code, releases and defects in the product itself, unless you have a separate contract for that work. If only one person can ship a change, a hosting retainer will not fix that by itself. See one person knows how to deploy it.
• Your data: what you store, and the lawful handling of it.
• Access decisions: who is allowed in, what they can do, and what happens when someone leaves. If the root login still sits with a freelancer, start with leaving a freelancer with your AWS root login. Keys left in the repository are another access problem, covered in secrets in git repository.
• Priorities and risk: which issues get attention first, and which risks you accept.
• The AWS account: it should be in the business's name. A provider can work with access to it. They should not take it over.

What to get in writing

If you are comparing managed AWS hosting quotes, ask each supplier to put the following on paper. What will be patched, and how often. That backups exist, and whether restores are tested. What is monitored, who is alerted, and in which hours someone is expected to act. Any out-of-hours cover. Scaling, if you need it. And response times, if they are offering any. A supplier who says they keep an eye on it has not given you an agreement.

How Eight Mile looks after infrastructure on AWS

Our infrastructure and cloud work includes designing, building and running infrastructure on AWS, with UK and EU regions as the default. Customers keep the cloud accounts. We work with access to them. After a build, delivered work is covered for twelve months. Ongoing monitoring, patching, backups and on-call support are available through a monthly arrangement with agreed coverage.

If we did not build the system, work starts with a review of what it does, its fragile areas and running costs, then a written plan. Support is a separately agreed monthly retainer, sized to what is covered. Secrets belong in a managed secret store, not the repository.

The useful test is simple. If something fails tonight, who is allowed to act, and is that written down? If the honest answer is that you assumed the hosting covered it, you do not have a managed arrangement yet.

If you want that split agreed properly on an AWS account you own, talk to an engineer. Tell us what is running and what you think is already covered.