The root account is not a user account
Every cloud account has an original identity with unrestricted power: root on AWS, the owner on Google Cloud and Azure, the account holder elsewhere. It can do anything, including delete the account and change billing.
It should be used to set up other identities, secure itself, and then be left alone. Using it for daily work means every action carries maximum privilege, and the audit log records everything as the same anonymous owner.
Start from the job, not from the permissions
The common failure is to grant broad access because a narrower grant produced an error. That works in the moment and produces an account where everyone can do everything within six months.
The better order is to define the role first. What does this person or service actually need to do? Then grant exactly that, and widen it only when a specific task fails for a specific reason.
Group permissions rather than attaching them to people
Attach permissions to a group or role, then put identities into it. When someone joins, they go into a group. When someone leaves, they come out of it. Nobody has to reconstruct which individual grants were made months ago.
This is the difference between an access model you can audit and a pile of exceptions.
Give applications their own identities
An application should never authenticate as a person. Create a service identity for it with only the permissions that specific workload needs, and rotate its credentials independently.
It also means that when a person leaves and their access is revoked, nothing in production stops working, because production was never using their credentials.
Separate environments properly
Development, staging and production should not share an identity, and ideally should not share an account. Keeping them apart limits what a mistake in staging can reach, and it makes cost attribution straightforward because each environment bills separately.
This is one of the strongest arguments for holding more than one cloud account rather than partitioning a single one.
Review it on a schedule
Permissions accumulate silently. Once a quarter, look at every identity on the account and ask whether it should still exist and whether it still needs what it has.
- Identities that have not authenticated in months
- Access keys with an old last-used date
- Grants that were widened for a one-off task and never narrowed again
- Service identities for workloads that no longer run
Related cloud accounts
This guide applies across providers. The cloud account catalogue lists every platform with its configurations and prices, and the comparison table puts them side by side.
Further reading
- IaaS, PaaS and SaaS: Which Layer You Actually Need
- Linode vs Hetzner: Which Cloud Account Should You Buy?
- Deploying for Asia-Pacific Users
- AWS vs Oracle Cloud: Which Cloud Account Should You Buy?
Frequently asked questions
One identity per person, plus one per application or automated process. Shared logins remove attribution and make offboarding unsafe.
Yes, at least to the extent of not using root day to day and giving applications their own credentials. It costs very little time and limits the damage of a leaked key.
Granting broad administrator permissions to resolve a permissions error, then never narrowing them once the task is done.
