# AWS Checklist

**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 | | |