Agencies run several clients concurrently, each with different data, different stakeholders and a defined end date. Sharing one cloud account across them creates problems that only become visible at handover, which is the worst moment.
What separation gives you
-
Clean billing
The invoice is the client report. No tag archaeology at month end.
-
Contained permissions
A mistake on one engagement cannot reach another client’s data.
-
Simple handover
Transfer the account, remove your access, done.
-
Honest scope
What the project actually consumes is plainly visible to both sides.
A repeatable engagement pattern
- Create the account at kickoff with your standard baseline applied.
- Federate identity so staff use their own logins, not shared credentials.
- Tag by project and environment from the first resource.
- Keep infrastructure in a repository the client will eventually receive.
- Review spend monthly with the client rather than at the end.
- Run the handover checklist at close, and confirm access removal in writing.
What to standardise across clients
| Element | Approach |
|---|---|
| Security baseline | Standardise. Every account starts the same. |
| Tagging scheme | Standardise. Reporting depends on it. |
| Infrastructure modules | Standardise and reuse; parameterise per client. |
| Region | Customise. Follow the client’s users and obligations. |
| Architecture | Customise. That is the work. |
| Handover process | Standardise. It is where reputation is made or lost. |
Set expectations about ownership early
Agree in writing, at kickoff, who owns the account at the end, who pays for what during the project, and what happens to data after handover. That conversation is far easier before the work starts than during the final invoice.
Summary
One account per client, a standard baseline applied automatically, identity federated, infrastructure in a repository, and a rehearsed handover. It costs a little discipline and removes most of the friction at the end of an engagement.
