Which Cloud Provider for an Agency Managing Client Infrastructure

An agency’s infrastructure problem is not technical scale. It is
multiplicity. Twenty clients means twenty sets of credentials, twenty billing
questions, twenty security boundaries and, eventually, several handovers to
other people. Providers differ considerably in how well they handle that, and
the differences are not on the pricing page.

The decision that matters most

Before choosing a provider, decide how clients will be separated. There are
three models and the choice shapes everything else.

One account per client, owned by the client. The client
registers, you are granted access. Cleanest legally and commercially: the client
owns their infrastructure, billing goes directly to them, and handover is
revoking your own access. The cost is administrative overhead and the fact that
you cannot resell.

One account per client, owned by you. You register and
manage each. Simpler for you, and you control the relationship. But you are now
holding infrastructure that arguably belongs to the client, and the handover
conversation at the end of a relationship can be difficult.

One account, all clients inside it. Tempting, and usually a
mistake. A single compromised credential exposes every client at once, billing
attribution becomes manual work every month, and separating one client out later
is a migration rather than a permission change.

The first model is right for most agencies. The second is defensible when
you are selling a managed service rather than project work. The third is worth
avoiding even though it looks easiest at five clients.

What to look for in a provider

• Granular access control, so a contractor can be given
  access to one environment rather than everything.
• Usable billing attribution, through tags, projects or
  sub-accounts, so you can answer “what did this client cost” without a
  spreadsheet exercise.
• A clean ownership transfer path, for when a client leaves
  or brings work in-house.
• An API worth automating against, because the twentieth
  client should take less effort than the second.
• Support that responds, because the client is waiting and
  “our provider has not replied” is not something they want to hear.

Where each provider fits

Kamatera suits agencies
specifically because of configuration flexibility: you can size a server to a
client’s exact requirements rather than fitting them to a fixed plan menu,
with hourly or monthly billing. Its support reputation is a genuine factor when
you are the one answering to a client.

DigitalOcean and
Linode both offer predictable
pricing and clear interfaces, which matters when you are explaining a bill to a
non-technical client. Predictable pricing is easier to mark up and easier to
justify.

Hetzner gives the best
margin on hosting-style work, with the caveat that its verification process is
strict and its support is email-based.

The hyperscalers earn their place when clients are enterprises with
procurement requirements, or when projects genuinely need managed services
beyond compute and storage. Their organisational structures are also the most
mature for separating many accounts under one umbrella.

Three things worth settling in writing

Who owns the account. Put it in the contract. This is the
single most common source of unpleasantness when a relationship ends.

Who pays the provider. Client-paid is simpler and avoids you
financing their infrastructure. Agency-paid with a markup is a legitimate
business model, but it makes you responsible for a bill that varies with
something you do not fully control.

What happens at the end. Define the handover: what you
transfer, in what format, within how long. Agreeing it at the start costs
nothing and removes the worst conversation in agency work.

Two operational habits

Standardise ruthlessly. The same base image, the same deployment approach,
the same monitoring across every client. Bespoke infrastructure per client does
not scale past a handful, because every incident becomes an exercise in
remembering how that particular one was built.

Automate provisioning early. The point where it becomes clearly worth it
arrives sooner than it feels, and infrastructure defined in code is also the
documentation you will want during a handover.