Most cloud account incidents are not sophisticated. They are an exposed key, a root user with no second factor, or a bill nobody was watching. All three are preventable in the first hour, and all three are much harder to fix afterwards.
This checklist applies to any cloud account regardless of how it was created. Work through it in order, before you deploy anything you care about.
1. Change every delivered credential
Any password, key or token that arrived with the account should be replaced immediately. This is not a comment on where the account came from: credentials that have travelled through email, chat or a support ticket have been outside your control, and the only way to bring them back inside it is to rotate them.
Change the console password first, then regenerate any programmatic access keys.
2. Enable multi-factor authentication on the root user
The root or owner identity can do everything, including removing your other protections. It should be the single most defended thing in the account.
Enable a second factor on it immediately. Use an authenticator app or a hardware key rather than SMS where the platform supports it. Then record the recovery codes somewhere you will still be able to reach them if you lose the device.
3. Stop using root for daily work
Create a separate identity for yourself with only the permissions you actually need, and use that instead. On AWS this means an IAM user or role; on Google Cloud, a user with a scoped role rather than owner; on Azure, a directory user with a specific role assignment.
Root should be used for the handful of operations that genuinely require it, and nothing else. If root is your everyday login, every mistake is an unrecoverable mistake.
4. Apply least privilege deliberately
Grant the narrowest permission set that lets a person or service do its job. Broad wildcard permissions are convenient on day one and painful the first time something is compromised, because the blast radius is whatever you granted.
For service identities in particular, scope to specific resources rather than whole services. A deployment role that can write to one bucket is a much smaller problem than one that can write to all of them.
5. Set a billing alert
This is the step people skip, and it is the one that causes the most expensive surprises. A misconfigured autoscaler, an accidentally public storage bucket serving traffic, or a crypto-mining payload on a compromised instance all show up as spend long before they show up anywhere else.
Set a threshold that reflects your expected monthly spend, not the maximum you could tolerate. On accounts carrying a promotional credit balance, set the alert so it fires while credit remains, otherwise the first signal you get is a bill after the balance ran dry.
6. Turn on audit logging
Enable the platform’s audit trail: CloudTrail on AWS, Cloud Audit Logs on Google Cloud, Activity Log on Azure. Turn it on before an incident, because it only records what happened after it was enabled.
Send the logs somewhere separate from the account that generates them if you can. An audit trail an attacker can delete is not much of an audit trail.
7. Review what is already there
On any account you did not create from empty, look at what exists before you add to it:
- Which identities, users and service accounts exist, and what can they do?
- Are there active access keys you did not create?
- Are any resources already running, in any region?
- Are there storage buckets with public access?
- What do the firewall or security group rules currently allow?
Check every region, not just the one you plan to use. Resources in an unused region are easy to miss and cost money regardless.
8. Rotate keys on a schedule
Set a rotation interval for programmatic credentials and actually keep to it. Long-lived keys accumulate copies in build systems, developer laptops and configuration files, and each copy is another way for one to escape.
Where the platform supports short-lived credentials issued to a role, prefer those over static keys entirely.
The order matters
Credentials and multi-factor authentication come first because they close the door. Scoped identities and least privilege come next because they limit what happens if the door opens anyway. Billing alerts and audit logging come last because they tell you when something has gone wrong. Skipping straight to logging without doing the first two means you will have a detailed record of an incident you could have prevented.
Common questions
How long should this take?
Under an hour on a fresh account. Considerably less once you have done it a few times.
Do I need all of this for a throwaway sandbox?
Credentials, multi-factor authentication and a billing alert, yes. A sandbox with a live payment method attached can generate a real bill just as easily as production can.
What is the single most important step?
Multi-factor authentication on the root user. Everything else is recoverable if that one holds.