Checklist · AWS

AWS Account Setup & Cost Control Checklist

The decisions that are painful to change later, the security defaults to set on day one, and the cost mechanics that surprise people. Ordered by how expensive it is to fix later.

Download the checklist Read the full guide

Markdown. No sign-up, no email.

Account / Organisation: _______________ Date: _______

Ordered by how expensive it is to fix later. Section 1 is a migration project if you skip it.

1. Hard to change later — do these first#

[ ] Separate accounts for production and non-production, under an organisation
[ ] Account structure decided before workloads land
[ ] Region chosen deliberately — data residency, latency, price. Moving data later is a project
[ ] Tagging convention decided and enforced: owner, environment, cost centre
[ ] Naming convention decided
[ ] Infrastructure as code from the start — console-created resources are invisible and unreproducible

2. Security on day one#

[ ] MFA on the root account, then lock it away and never use it for daily work
[ ] Root account has no access keys
[ ] Identity federation for humans — no long-lived access keys
[ ] Roles, not users, for applications
[ ] Least privilege from the start — widening is easy, narrowing later is not
[ ] CloudTrail on, logging to a separate account if possible
[ ] S3 public access blocked at account level, exceptions granted deliberately
[ ] Encryption at rest on by default
[ ] Security groups scoped to specific sources, never 0.0.0.0/0
[ ] Billing alarm set — unexpected spend is often the first sign of compromised credentials

3. Cost — the mechanics that surprise people#

[ ] Budget alerts on day one, before the first workload
[ ] Non-production shut down outside working hours — roughly two-thirds of the week
[ ] NAT Gateway usage reviewed — hourly and per-GB, and frequently in the top five line items
[ ] Data transfer out understood and monitored
[ ] Cross-AZ traffic reviewed — a chatty architecture can cost more in transfer than compute
[ ] Stopped instances audited — attached storage still bills
[ ] Unattached IP addresses and volumes cleaned up
[ ] Snapshot and log retention policies set
[ ] Load balancers with no traffic removed
[ ] Reserved capacity or savings plans committed only to a provable baseline
[ ] Top ten line items reviewed monthly, with someone who can explain each

4. Architecture#

[ ] Availability level chosen deliberately: single-AZ / multi-AZ / multi-region
[ ] Multi-AZ for production; multi-region only with a stated reason
[ ] Compute choice deliberate: Lambda for event-driven, Fargate for containers, EC2 for control
[ ] Managed services preferred where they genuinely save work
[ ] App Service equivalent considered before defaulting to virtual machines

5. Operations#

[ ] Managed database patching and upgrades still owned by someone — "managed" is not maintenance-free
[ ] Storage growth monitored on managed databases
[ ] Backups tested by restoring
[ ] Runbooks exist for the tasks done rarely and under pressure

6. The lift-and-shift trap#

[ ] Workloads assessed for whether they benefit from cloud at all
[ ] Steady, always-on workloads costed against owned hardware
[ ] Not simply moving virtual machines unchanged and paying the rental margin

Cost review#

Line item	Monthly	Owner	Action

Sign-off#

	Name	Date
Completed by
Account owner

Back to AWS