What this prompt does
This prompt makes the model act as a senior AWS platform architect and specify a secure multi-account foundation tightly enough to build. You provide [team_size], [workloads], and [compliance], and it returns an account structure, a Control Tower landing zone with IAM Identity Center SSO, example Service Control Policies as JSON, centralised CloudTrail and GuardDuty, a break-glass access path, and a phased rollout that migrates an existing single account without downtime.
The structure works because it treats account boundaries as the primary security control, then layers guardrails on top. The [compliance] value (for example, SOC 2 with centralized audit logging) drives the logging and SCP design, so the audit trail is built in rather than retrofitted. [team_size] shapes the SSO and access model, and [workloads] decides how many prod, staging, and dev accounts you actually need. Asking for example SCP JSON snippets forces the abstract guardrails into something you can paste and adapt, instead of hand-waving about "policies you should add." The phased rollout at the end matters just as much, because it sequences the migration so the security and logging accounts exist before any workload moves into the org.
When to use it
- You've outgrown a single AWS account and dev and prod share dangerous blast radius.
- You're pursuing SOC 2 or similar and need centralised, tamper-resistant audit logging.
- You want SCP guardrails that stop a single mistake from becoming a company-wide incident.
- You're setting up SSO across a growing engineering org with IAM Identity Center.
- You need a documented break-glass path for emergency access.
- You have to migrate from one account to a multi-account org without downtime.
Example output
Expect an account-structure diagram described in text — management, security tooling, log archive, prod, staging, and dev, each with a reason it's separate — followed by two or three example SCP JSON snippets you can adapt, a CloudTrail and GuardDuty centralisation plan, a break-glass procedure, and a phased rollout plan ordered so nothing breaks mid-migration.
Pro tips
- State
[compliance]precisely; SOC 2 versus HIPAA versus nothing changes the logging and SCP requirements substantially. - Stand up the log-archive and security accounts first, as the prompt's rollout suggests — you can't retrofit a clean audit trail.
- Treat the example SCPs as templates; test each one in a sandbox OU before applying it org-wide, since a bad SCP can lock out legitimate work.
- Use
[workloads]to justify each account; don't create accounts you have no workload for. - Confirm the break-glass path actually works before you tighten the guardrails around it.
- Keep
[team_size]realistic so the SSO and permission-set design matches how people actually need access. - Apply CloudTrail centralisation to the log-archive account early; a tamper-resistant trail is most valuable when it predates the incident you'll need it for.
- Roll out one OU at a time and watch GuardDuty findings as you go, rather than flipping every guardrail across the org in a single change.
