AWS Account and Workload Setup Template
A fill-in record for standing up an AWS workload — account boundaries, identity, network, data classification, cost controls, backup and the recovery test that proves the backups are real.
Markdown. No sign-up, no email.
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 |