What happens to your AWS setup if the engineer who built it leaves?

Why is one person knowing AWS a business risk?

One person knowing AWS is a business risk because production depends on knowledge and access that live in a single head.

AKF Partners, which carries out technical due diligence for investors, names key-person concentration as the single highest-risk finding in the growth-stage audits it describes, and says the fix is not a rewrite but sharing knowledge across more people.

For a small team the risk is sharper, because the person who set up AWS is often a founder or the first engineer who also writes product code. If they leave, or are simply unavailable on the day, nobody else knows where things are.

What breaks first when that person leaves?

Access breaks first, then routine tasks, then anything unusual.

The usual casualties are listed below.

How do you secure the AWS root user so access outlasts one person?

Secure the root user by using a business-owned group email, protecting it with multi-factor authentication and making sure no single person can reach everything.

AWS recommends using an email address managed by the business that forwards messages to a group of users, and says no one person should have access to both the email inbox and the phone number, since both are recovery channels.

• Do not use the root user for everyday work; AWS advises creating an administrative user for that and using temporary credentials.
• Add MFA for the root user. AWS allows up to eight MFA devices, and recommends more than one for resilience.
• Do not create access keys for the root user.
• Keep the contact phone number current and limit who can manage it.
• Log and monitor access to the root credentials' storage location.

How do you make the setup survive a departure?

Make the setup survive a departure by putting it where the whole team can see it: infrastructure in code, deployments in CI and decisions written down.

A setup that exists only as clicks in the console cannot be reviewed, repeated or handed over.

AKF Partners also recommends lightweight architecture decision records, one page per decision covering context, options and reasoning, and a current architecture diagram. Those documents turn a person's memory into something the next person can read. An AWS infrastructure audit for a small SaaS shows what to check first.

What should a one-page runbook contain?

A one-page runbook should answer the questions someone will have at the worst moment: how to check the site, how to roll back, how to restore, who to call and where the dashboards are.

It does not need to be long, only correct and easy to find.

• How to tell whether the product is up, and where the alerts go.
• How to roll back a release, as in how to roll back a failed ECS deployment automatically.
• How to restore the database, with a link to the last test, as in how to prove your AWS backups restore.
• Who has access to what, and how access is added or removed.
• Where secrets live and who can rotate them.

Does a small team need a second person or a service?

A small team needs at least two people who can deploy, roll back and restore, whether they are both staff, a staff member and a fractional engineer, or a staff member and a managed service.

The point is that no task depends on one person being reachable.

Running production on AWS without a DevOps engineer compares the options, and how a small startup handles on-call covers cover outside hours. Under the AWS shared responsibility model the security of your account remains yours, so keep ownership of the account itself even when someone else does the work.

Can a very small team cover this without hiring?

A very small team can cover this through Keel's Startup programme, a foundation-level service for small teams already live with paying customers.

It includes a deploy pipeline with rollback, tested backups, monitoring and monthly patching, all in your own AWS account, with the code, infrastructure and runbooks in your repositories so there is nothing to hand back, plus a monthly check-in with a Keel account manager.

It is for teams of fewer than 5 at pre-seed to Series A, live in production with at least one paying customer, on AWS with code on GitHub or GitLab. Places are limited and awarded on merit. You can apply for a place in the pricing section.

Would your AWS setup survive a departure?

Tick each item that is true today.