How to Take Back Control of Your AWS Account From a Former Vendor

The short answer

You take back an AWS account in five phases: discover what is running, transfer ownership and billing, rebuild access before removing the vendor's, prove continuity with a tested restore, and document it so your team can operate without anyone in the room. Most of the elapsed time is coordination, not engineering. On my last engagement it took six to eight weeks.

The client was a SaaS company in the Gulf region. The business had changed hands: a new owner had bought the organization, but in practice they had not bought its cloud. Production ran on AWS, and the account sat with the outgoing vendor. No root access, no billing visibility, no documentation, no reliable inventory of what was running or what it cost.

This position is more common than people admit, and the risk is rarely malice. It is attrition. The people who built the environment move on, and the knowledge of how it was assembled leaves with them. The engagement was about closing that gap permanently, not swapping one set of credentials for another.

Think of it as taking back a house you've been renting

The outgoing vendor is not the villain. They are a landlord who happened to keep the deed, the spare key, and the maintenance log. The job is not to evict them in anger. It is to transfer the deed, re-key the locks, write down where the fuse box is, and make sure the backup generator actually starts. Then the landlord's key stops working.

That maps directly onto the five phases of the work:

1. Discovery and inventory. Find out what is in the house.

2. Ownership transfer. Transfer the deed: root access and billing.

3. Access rebuild. Re-key the locks: least-privilege roles for your team, vendor access retired in sequence.

4. Continuity verification. Start the generator: test a restore, confirm DNS and certificates.

5. Documentation and handover. Write down where the fuse box is, then prove someone else can find it.

Phase 1: Discovery turns a vague dependency into a named list

Roughly a third of the client's monthly AWS spend sat on resources nobody, on either side, could confidently name. Discovery changed the shape of the whole engagement, so I front-loaded it: every running resource catalogued across every region and service, the architecture reconstructed from the live environment, and actual monthly cost attributed by service.

Three findings stood out:

• Services running in regions nobody mentioned. Leftovers from an earlier deployment, with no users, billing every month. Not malicious, just never cleaned up.

• A shadow environment. The client believed they ran one production environment. What actually ran was production plus a set of support services, and that gap was 20 to 30 percent of the bill.

• Access keys nobody could explain. No owner, no documented purpose, no record of what they touched. This was the finding that worried me most.

The inventory itself was not the point. Once every resource had an owner, a cost, and a purpose, the rest of the handover stopped being a negotiation about trust and became a checklist. You can only remove access in a controlled sequence if you know what is behind each door.

It also changed the vendor conversation. The pushback I met was inertia, not hostility: the vendor could not say which access they needed, because nobody had ever inventoried it. With a real resource list and cost picture on the table, the conversation moved from "trust us, we need this" to "here is what's running, here is what each role touches, and here is what can be retired."

Phase 2: Start the ownership transfer on day one

Ownership transfer is the longest pole in the engagement, and it cannot be compressed by working harder. In this case the account moved from the previous owner to the party who had bought the organization. That depends on the outgoing vendor's cooperation and on administrative steps that neither you nor they fully control.

The deliverables here are concrete:

• Account and billing ownership formally transferred to the business

• Root access re-established, with MFA enforced

• Payment method and billing alerts verified under the client's control

I ran discovery first because I needed the inventory to argue from. That was right for the access work. But in hindsight the ownership conversation should have started in week one, in parallel with discovery. It needed calendar time more than effort, and calendar time is the one thing you cannot get back.

Phase 3: Rebuild access before you remove anyone's

The rule is simple: stand up the new keys before you change the locks. I designed a least-privilege IAM model for the client team, with scoped roles per function instead of shared credentials, and had it working before any vendor access was retired. There was never a moment where nobody could get in.

The vendor's instinct was to keep a foot in the door "just in case." I didn't argue with that instinct. I satisfied it with evidence, which is what Phase 4 is for.

How to retire an unknown access key without breaking production

Never delete first. Unexplained keys are where handovers break things, because they are the one part of the inventory with no owner. Retire them in stages, and don't skip a stage because you are in a hurry to close out:

1. Find out who uses it. Pull the key's last-used timestamp from IAM, then cross-check CloudTrail. Last-used tells you the key was called. CloudTrail tells you what it called and from where. Keys turned out to be either clearly live or untouched for months, with little in between.

2. Deactivate, don't delete. Quiet keys go to inactive. An inactive key fails immediately but can be restored in seconds. Keys still being called go on a list to investigate first.

3. Watch. A dead key failing quietly is fine. A live dependency failing loudly is information, and you want it within hours, not at the end of the engagement.

4. Delete and rotate. Only after a key has been inactive and quiet does it get deleted. Anything exposed during the transition gets rotated regardless of how clean it looks, because a handover is exactly when a dormant key becomes live again.

Did anything break? Nothing that took the environment down. But one or two keys flagged as quiet turned out to have a slow, low-volume caller. The watch window caught them. A blind delete would have surfaced the same dependency as an outage. Deactivate, watch, delete turned it into a five-minute fix.

Phase 4: A backup that has never been restored is a belief, not a fact

The first restore took six hours against an expected two, and it exposed a gap nobody knew existed. That is the usual outcome, and it is the reason to run the test.

The database was in the snapshot schedule. One of its volumes was not. And the configuration and secrets lived outside the backup entirely. A "clean" restore would have brought up an application that could not talk to its own dependencies. Nobody had noticed, because nobody had ever restored it.

We fixed the schedule, pulled configuration into the backup, and ran the whole restore again. The second run, with the gaps closed and the steps written down, took about two and a half hours. The difference was never the data. It was the undocumented steps, and the first restore of any environment surfaces them.

The tested restore did two more things:

• It ended the "just in case" argument. Once you can demonstrate a tested restore, keeping vendor access stops being a risk argument and becomes a preference.

• It went straight into the runbook as a verified procedure rather than a theoretical one.

In the same phase, I verified that DNS records and domain ownership sat with the client, and confirmed the TLS certificates and their renewal path. Certificates are the item that quietly breaks a cutover weeks later.

Phase 5: Documentation isn't the receipt, it's the proof

What finally made the handover land was the runbook, not a speech. I wrote it as "who can reach what, and how," covering access, backup, recovery, and escalation. Alongside it went an architecture and cost overview written for non-technical stakeholders.

Then I walked the client's team through it live, next to a simple before-and-after picture. Before: vendor, then account, then client, with no root, no inventory, no runbook. After: the client owns the account directly, with root and billing in hand, roles documented per function, and zero remaining vendor dependency. When people see the transfer as a finished state rather than a leap of faith, the resistance goes away.

The handover session is the part I would protect in any engagement. Documentation is usually the first thing squeezed when a schedule tightens. It is also the thing that makes the technical work durable.

Buying a SaaS? Check the AWS account before you sign

If the account isn't part of the deal, it's a surprise waiting to happen. These are the signs you are in the same position my client was in:

• Someone else holds root. Whatever the contract says, you don't control the account.

• Billing sits with someone else. If you can't see the bill, you can't see the environment. Billing visibility is a proxy for operational visibility.

• There's no inventory. If the answer to "what's running?" is "the vendor will tell us," you don't have one.

• There's no runbook. The knowledge lives in people, and people leave.

• Access is shared. With shared credentials, nobody can tell who did what, and you can't remove one person without breaking something.

• The cost doesn't reconcile. You have a number, but you can't break it down by service.

• The vendor is your continuity plan. If the business stops when the vendor stops answering, that's the risk.

What to ask for before signing

• Ownership as a deliverable. Who holds root and billing today, and a written commitment that both transfer to you, with a deadline. Not "we'll sort it after completion."

• Evidence. A screenshot of the billing console and an IAM summary showing root status and roles. If they won't show you, that is your answer.

• A resource inventory, by region and by service, with cost attached. An inventory, not a summary.

• The runbook for access, backup, and recovery. If it doesn't exist, price the gap into the deal.

• DNS, domains, and certificates under your control, with a known renewal path.

• Proof of a tested restore, not proof that backups exist.

• The clean-slate question. Which access does the vendor expect to keep after handover, and why? The answer to aim for is none. If it's "some, just in case," it needs an end date and an owner on your side.

How long it takes, and whether you can do it yourself

The engagement ran six to eight weeks from kickoff to the final handover session. It is short in effort and longer in calendar, because most of the elapsed time sits in coordination.

The client's team did not need many hours, just the right people at the right moments: a decision maker to sign off on the ownership and billing change, a technical contact who knows the product and can answer "what is this resource for?", and the team's time for the handover session and runbook review.

Can a capable developer do this alone?

Most of the individual steps, yes. The IAM rebuild is a well-understood pattern, and an inventory is tedious rather than hard. The dividing line is not skill. It is whether you can absorb what first-timers underestimate:

• Sequencing. Roles before removal, deactivation before deletion. Obvious in hindsight, easy to get wrong the first time, and the failures are quiet. They show up weeks later.

• What a real restore test looks like. Any developer can restore a database. Knowing that configuration and secrets often live outside the backup, and that the test must prove the whole path, comes from having been bitten by it.

• Coordination. The vendor conversation, the removal sequence, documentation a non-technical stakeholder can use. That's half the job, and it isn't engineering.

If your environment is small and documented, and you have someone with real AWS depth and time to spare, do it yourself. If any of those are missing, and especially if an outgoing vendor holds access, bring in someone who has done it before. Not because the steps are exotic, but because the mistakes are the kind you only recognize after the fact.

What I'd do differently

The outcome was right: the client owns the account outright, access follows least privilege, and vendor dependency is zero. What I would change is order and lead time, not the shape of the work.

• Start the ownership conversation on day one, in parallel with discovery, because it needs calendar time you can't compress.

• Run the restore test earlier, before the access rebuild, so the runbook is written against tested reality the first time instead of being revised afterwards.

• Budget for the social side of cost attribution. Attaching each line of spend to a service was quick. Attaching it to a person who would recognize the resource and confirm it was still wanted took far longer, and it decides how fast everything else lands.

The lesson I carry forward: identify everything that needs calendar time on day one, and start it, even while discovery is still running.

The opinion most people will push back on

Most teams treat documentation as the last deliverable. I think that's backwards. Documentation is not a record of the work, it is a test of whether the work is finished. If you can't write down who can reach what, the access model isn't done. If you can't describe the restore in steps someone else could follow, you haven't tested it, you've only run it once.

So the runbook should exist before the handover session, and the session should be a live test: someone who wasn't involved follows it without you in the room. If they can, it's done. If they can't, you found the gap for free instead of three months later.

Underneath that is a wider opinion about who should own infrastructure. At small SaaS companies, the common default is to let the agency hold the account because it's simpler. I think that's a bad default. Not because agencies are untrustworthy, but because ownership is leverage. If you don't hold the account, you don't hold the ability to leave, and a vendor who knows you can't leave has a different relationship with you than one who knows you can. The account should sit with the business from day one, with the agency working inside it under scoped access. It's slightly more setup at the start, and dramatically less pain at exit.

FAQ

How long does an AWS account handover take? About six to eight weeks for a production SaaS environment. The technical work is a fraction of that. Most of the time goes to coordination, especially the ownership and billing transfer.

Can I get root access back if the vendor won't cooperate? Cooperation makes it far faster, which is why the ownership conversation should start on day one. Make the transfer of root and billing an explicit, dated deliverable in your contract or acquisition terms.

Is it safe to delete access keys I don't recognize? Not directly. Check last-used data in IAM and CloudTrail, deactivate first, watch for breakage, and only then delete. Rotate anything exposed during the transition.

How do I know my AWS backups actually work? Restore them. Test the whole path, including configuration and secrets, not only the database. The first restore of any environment almost always surfaces undocumented steps.

Should my agency own my AWS account? No. The account should belong to the business from day one, with the agency working inside it under scoped, least-privilege access.

Running production on an AWS account you don't fully control, or about to acquire a SaaS that does? I run AWS account handovers end to end: discovery, ownership transfer, access rebuild, tested restore, and runbooks your team can operate from. See the AWS handover case study or book a 30-minute call.