The failure modes for a new cloud account are boringly consistent: a bill nobody saw coming, a credential in a public repository, and an administrator who cannot get back in. All three are prevented in the first hour, and almost never fixed comfortably afterwards.
This checklist is platform-agnostic. The names differ; the ideas do not.
1. Secure the top-level login (10 minutes)
Every account has one identity that can do anything — root user, owner, global administrator. Treat it as a break-glass credential, not a working login.
- Set a long, unique password in a password manager.
- Turn on multi-factor authentication. This is the single highest-value action on this page.
- Record the recovery details somewhere a second person can reach.
- Then stop using it. Day-to-day work happens under a separate identity.
Compromised cloud accounts are usually mined for compute rather than data, and the bill arrives before the intrusion is noticed. Multi-factor authentication on the top-level identity is what stops that story starting.
2. Set budget alerts before you deploy (5 minutes)
Do this before the first resource exists, because after it exists you will be busy. Every platform has a budgets feature; every one of them is free.
- Set a monthly figure you would be unhappy to exceed.
- Add alerts at 50 %, 80 % and 100 % of it.
- Send them to an address a human reads daily, not to the account’s own inbox.
- Add a forecast alert if the platform offers one — it warns on trajectory rather than after the fact.
Alerts do not stop spending. They convert a month-end shock into a Tuesday-afternoon question, which is the entire point. See how cloud billing works for what usually causes the spike.
3. Create a working identity (10 minutes)
Make a second user or service principal with the permissions the job needs, and use that. Grant broad permissions now only if you will genuinely narrow them later; if you know you will not, narrow them now.
For anything automated, create a dedicated machine identity rather than reusing a human’s. When something has to be revoked at three in the morning, you want to revoke exactly one thing.
4. Decide the region deliberately (5 minutes)
The console will offer you a default. It is the default because of where the platform is headquartered, not because of where your users are.
Pick on latency to users, on any data residency rule that binds you, and on whether the services you need exist there. Region is painful to change once data has landed — see cloud regions and IP location explained.
5. Look at the network defaults (10 minutes)
Every platform creates a default virtual network and a default firewall, and the defaults are convenience-shaped rather than security-shaped.
- Check what is open to the whole internet. Management ports — SSH, RDP, database ports — should be reachable from your addresses, not from everywhere.
- Prefer key-based authentication over passwords, and disable password login where you can.
- Put anything that does not need a public address on a private subnet.
Automated scanners find a new public IP within minutes. That is not a worst case, it is the normal case.
6. Turn on the audit log (5 minutes)
Every platform can record who did what. Some enable it by default, some do not, and retention is usually short unless you extend it. Switch it on now: the value is entirely retrospective, and you cannot enable it backwards.
Then, and only then, deploy something
The whole list is under an hour, most of it clicking. Set against it: a mined account, a leaked key, or a bill with an extra digit — each of which costs considerably more than an hour.
Once the account is set up properly, the guides cover what comes next, and each provider page links to the platform’s own documentation for the specifics.