One cloud account is easy. Five accounts across three providers, each with its own users, keys, payment method and quirks, is where things quietly go wrong: a forgotten server bills for a year, a departed contractor still holds a key, or nobody knows who can approve a support ticket. This article sets out the four practices that keep a portfolio of accounts under control, with OVHcloud and Vultr as the working examples.
Why teams end up with several accounts
Multiple accounts are usually deliberate. Agencies isolate clients. Product teams separate development from production. Some teams place workloads on the platform whose economics or regions suit them best, keeping European infrastructure on OVHcloud and globally distributed edge nodes on Vultr, for example. The homepage guidance on multi-cloud is blunt: the operational complexity must be weighed against the benefits. These practices are how you pay that complexity down.
Practice one: keep a single inventory
The inventory is a document or a small database that lists every account your organization controls. For each account record at minimum:
- Provider, account identifier and console URL. On OVHcloud this includes the NIC handle; on Vultr the account email.
- The named owner and a deputy.
- Billing entity, payment method on file and the invoice contact.
- Regions in use and the main workloads or clients hosted.
- Date of the last access review and the last key rotation.
Keep the inventory where the whole team can find it and treat updating it as part of creating or retiring any account. An inventory that is six months stale is worse than none, because people trust it.
Practice two: name things consistently
Naming is what makes the inventory usable across providers. Adopt one convention and apply it to accounts, projects, servers and tags alike. A pattern such as client-environment-role-region reads the same on an OVHcloud public cloud project as it does on a Vultr instance list. Within OVHcloud, one identity can hold VPS, dedicated servers and public cloud projects, so consistent naming at the project level is what stops a dedicated server for one client being confused with a public cloud instance for another.
Where a provider supports tags or labels, mirror the same fields there. The tagging and cost allocation guide covers a tag schema that also serves billing.
Practice three: assign one owner per account
Every account needs exactly one named person accountable for it. Shared ownership means no ownership. The owner keeps the contact details current, holds the recovery information, approves new users and answers for the bill.
The owner should not be the only person who can get in. Multi-factor authentication recovery codes, the deputy’s access and the provider’s recovery process should all be documented before they are needed. Account recovery considerations covers what to prepare so a single absence never becomes a lockout.
Practice four: review access on a schedule
An access review asks, for each account, who can currently sign in or act through the API, and whether each of them still should. Quarterly is a reasonable cadence for a small team. The review covers:
- Console users and their roles or permission levels.
- API keys and tokens, with last-used dates.
- SSH keys stored in the console.
- Contacts registered for billing, technical and administrative notices.
- Third-party integrations granted access.
Remove anything unrecognized and rotate anything that has changed hands. On OVHcloud the control panel exposes users and contacts per account; on Vultr the account section lists users, API keys and SSH keys. When an account was acquired rather than created, the first review happens on day one, following the handover checklist.
Reading listings with a portfolio in mind
Marketplace listings describe an account’s starting state, and a portfolio manager reads them for how they will fit the inventory. The Buy OVH Account page lists an “OVH vCPU34 Account”, which describes a compute quota worth recording in the inventory under limits. The Buy Vultr Account page lists credit balances (“Vultr $200 Credit Account”, “Vultr $250 Credit Account”, “Vultr $300 Credit Account”), which belong under billing along with their expiry.
Whatever the starting state, the account joins the same inventory, gets the same naming, the same single owner and the same review schedule. That uniformity is what makes ten accounts feel like one. If you are deciding which providers belong in the set at all, all cloud providers at a glance summarizes the listed options side by side.
