An agency running infrastructure for a dozen clients has a different problem from a company running its own. The technology is identical; the structure around it is what fails.
One account per client, always
The temptation is a single account with everything in it, separated by naming convention. It is cheaper to set up and it fails in four predictable ways:
- A mistake in one client’s environment can reach another’s.
- Billing cannot be attributed cleanly, so neither can invoicing.
- Handing a client their infrastructure at the end means extracting it from a shared account.
- One client’s compliance requirement becomes everybody’s problem.
Separate accounts — ideally under an organisation structure that gives you consolidated billing and central policy — solve all four. Every provider in this catalogue supports some form of it.
Decide ownership at the start
Client-owned with agency access is usually the right default. It means the client keeps their infrastructure if the relationship ends, keeps their billing relationship and their support entitlement, and there is no argument later about what belongs to whom.
Agency-owned makes sense when you are genuinely selling managed hosting rather than services, and it should then be explicit in the contract — including what happens to the data at termination. Handing over a cloud account covers the mechanics.
Access that survives staff changes
- Named identities for every person, never a shared login.
- Access granted by role, and by client, so joining a project is a permission change.
- Multi-factor authentication mandatory, including for contractors.
- Automation credentials owned by the agency’s tooling account, not by an individual.
- A quarterly review that removes what is unused.
The automation credential is the one that outlives everybody. A deploy key created by somebody who left three years ago, still working, still unreviewed, is the most common finding in any agency access audit.
Standardise ruthlessly
The economics of running many small environments come entirely from them being the same:
- One reference architecture, with a documented reason for every deviation.
- The same monitoring and the same alerts everywhere — see monitoring a cloud server.
- The same backup policy and the same restore procedure — see snapshots vs backups.
- The same deployment mechanism.
- One runbook per client, kept current rather than written at the end.
A bespoke environment per client is charming until the person who built it is on holiday.
Billing and margin
If you are reselling infrastructure, know two things precisely: what each client’s environment actually costs, and what your provider’s terms say about resale. Consolidated billing with per-account attribution gives you the first; the acceptable use policy gives you the second — see reading a cloud provider’s terms.
Tag every resource with the client at creation. Untagged resources become unattributable cost, which comes out of margin.
Design the exit at the beginning
Every engagement ends. The version that goes well has: a client-owned account, documentation written as you went, named identities to revoke, and a handover meeting where a deploy and a restore are performed together. The version that goes badly is an archaeology project billed to nobody.
Where to go next
Questions
Frequently asked
Should an agency use one cloud account for all clients?
No. Separate accounts per client keep blast radius, billing attribution, compliance and handover clean. Consolidated billing under an organisation gives you the convenience without the coupling.
Who should own a client's cloud account?
Usually the client, with agency access granted. It keeps continuity, billing and data with the party that remains after the engagement.
What is most often missed when an agency engagement ends?
Automation credentials. Deploy keys and API tokens survive the removal of human logins and are frequently left active for years.