# AWS Workload Setup Record

> Fill this in before the first production resource exists. Retrofitting account boundaries,
> tagging and identity onto a running workload is one of the most expensive pieces of work in
> cloud engineering, and it is entirely avoidable.

**Workload:** _______________
**Owner (person):** _______________
**Date:** _______  **Environment:** dev / staging / prod

## 1. Account and organisation

| | |
|---|---|
| Account ID | |
| Organisational unit | |
| Separate account per environment | yes / no |
| Root user MFA enabled and credentials stored where | |
| Billing alerts configured to | |

🔴 The account is the strongest isolation boundary AWS offers. A misconfigured IAM policy inside
one account cannot reach into another. Sharing one account across production and development to
save administrative effort trades a permanent security boundary for a temporary convenience.

## 2. Identity and access

| | |
|---|---|
| Human access via | SSO / IAM users |
| Long-lived access keys in existence | yes / no — list them |
| Roles used by workloads | |
| Who can assume the admin role | |
| Access review cadence | |

**Every long-lived access key listed above needs an owner and an expiry.** Leaked static
credentials remain the most common route into a cloud account, and they leak through ordinary
mistakes — a commit, a laptop, a screenshot.

## 3. Network

| | |
|---|---|
| VPC / CIDR | |
| Public subnets — what is deliberately in them | |
| Private subnets | |
| Internet egress path | NAT / gateway endpoints / none |
| Security groups: what is open to 0.0.0.0/0 and why | |
| VPC endpoints used | |

**Anything reachable from the internet, listed explicitly:** _______________

## 4. Data

| Store | Classification | Encrypted at rest | Key | Public access blocked | Retention |
|---|---|---|---|---|---|
| | | | | | |

- S3 account-level public access block: on / off
- Versioning on buckets holding anything that matters: yes / no
- **Deletion protection on production databases:** yes / no

## 5. Cost controls

| | |
|---|---|
| Budget and alert threshold | |
| Tagging standard applied (owner, environment, workload) | yes / no |
| Untagged resources permitted | yes / no |
| Instance/database right-sizing reviewed on | |
| Storage lifecycle rules | |
| **Anything running that nobody would notice if it stopped** | |

Cloud spend is not usually one large mistake; it is a slow accumulation of resources that nobody
owns. Tagging is what makes that accumulation visible, and it only works if it is enforced from
the first resource.

## 6. Backup and recovery

| | |
|---|---|
| What is backed up | |
| Frequency | |
| Where backups live (separate account?) | |
| Retention | |
| **Restore tested on (date)** | |
| Time the restore actually took | |

🔴 An untested backup is a belief, not a control. Fill the last two rows with real dates and real
numbers or record the gap honestly. Backups in the same account as the thing they protect do not
survive an account compromise.

## 7. Observability

| | |
|---|---|
| CloudTrail enabled, logs written to | |
| Log retention | |
| Metrics and alarms that page someone | |
| Who receives the page | |
| Dashboard location | |

## 8. Before go-live

- [ ] Root user secured, MFA on, keys removed
- [ ] No security group open to the world except deliberately listed ones
- [ ] Public access block on for S3
- [ ] Budget alert firing to a real inbox someone reads
- [ ] Restore tested and timed
- [ ] Every resource tagged with owner and environment
- [ ] Alarms tested by causing the condition, not by assuming
- [ ] Runbook written for the three most likely failures

## Sign-off

| | Name | Date |
|---|---|---|
| Built by | | |
| Security review | | |
| Cost owner | | |
| Approved for production | | |