Your first hour with a new cloud account

When cloud account credentials are delivered, full responsibility for that account transfers to you. Security configuration, cost monitoring and compliance with the provider’s terms become yours from that moment. No marketplace can remove those responsibilities, and nothing in this checklist is specific to where the account came from: it is what any administrator should do on taking over any account.

The order below matters. Each step reduces the blast radius of the step before it.

1. Change the primary password

Do this before anything else, and before you create a single resource. Use a password manager and a unique, long password. Until the primary password is rotated, you are not the only party who has ever known it, and every later step rests on this one.

2. Enable multi-factor authentication

Enable MFA on the root or primary account immediately after the password change. Prefer an authenticator app or a hardware key over SMS where the provider offers the choice. On platforms where the root account is distinct from day-to-day users, secure the root account first, then stop using it for routine work.

3. Review every access credential

A password is not the only way into a cloud account. Work through the account and account for each of the following:

• Access keys and API keys. Revoke any you did not create. Generate new ones for your own use, scoped as narrowly as the task allows.
• Additional users and service accounts. Remove any you do not recognise, and review the permissions of the ones you keep.
• Roles and permission assignments. Confirm that nothing holds broader rights than it needs.
• SSH keys and registered devices, where the platform keeps them at account level.

This step is the one most often skipped and the one most worth doing carefully. A rotated password does nothing about a long-lived API key.

4. Set billing alerts before you deploy

Cloud spending rises quietly. Resources left running, a forgotten test cluster or an over-provisioned instance will keep billing until someone notices. Set a budget and an alert threshold now, while the account is still empty and the numbers are obvious, rather than after the first surprising invoice.

Most services are billed by consumption, with rates that vary by service, region and performance tier. Reserved capacity and savings plans can reduce the cost of predictable workloads, but only once you know what the workload actually is.

5. Audit what already exists

Look at the account’s existing resources before adding your own. Check compute instances, storage buckets, networks and any scheduled jobs across the regions the provider offers, not just your default region. Delete anything you did not create and do not need. An empty account should look empty.

6. Record the account properly

Before the account becomes one of several, write down what it is for, who owns it, which project it belongs to and where its credentials live. Teams that keep separate accounts per client or per environment gain real isolation from doing so, but only if each account is identifiable six months later.

Then start building

With the password rotated, MFA on, credentials reviewed, alerts set and the account audited, the account is genuinely yours and you can deploy with confidence. The whole sequence takes well under an hour, and it is the difference between a clean starting point and an account you do not fully control.

Each platform page in the catalogue notes the specifics that apply to that provider, and the FAQ covers delivery and what is included.