Build a multi-account AWS Org with SCPs

Most cloud security work in real companies starts at the Org level: account vending, guardrails, federated access. Building a tiny version of that yourself proves you can think at that altitude — which is exactly what hiring managers screen for in mid-level and senior interviews.

The artifact is a public Terraform repo that, given a fresh AWS account, will provision a minimal-but-real production-shaped organization in 15 minutes. Hiring managers love this one.

What you'll have at the end

• A public Terraform repo that spins up a 3-account AWS Organization (management + workload + audit).
• IAM Identity Center configured with one permission set and one assignment.
• A baseline of SCPs covering: deny root usage, require MFA, deny region usage outside a chosen region, enforce IMDSv2.
• Centralized CloudTrail in the audit account writing to an S3 bucket with object-lock.
• A README explaining each design choice and the trade-off you considered.

Prerequisites

• An AWS account that will become your Organization management account (use a separate email; don't use your existing personal account).
• Budget guardrails on the management account.
• Terraform 1.x and the AWS provider.
• Comfort with HCL and the AWS console; this isn't a beginner project.

Step-by-step

1. Plan the account layout on paper first

Sketch it: management, workload-prod, workload-dev, audit. (You can collapse workload-prod/dev for cost.) Decide which account owns CloudTrail, which OU each account lives in, and which SCPs apply at the OU vs root level.

2. Bootstrap the management account

In the management account, enable AWS Organizations and create a Terraform IAM user (or, better, a role assumed via federated SSO). Store its credentials in ~/.aws/credentials as a named profile.

3. Terraform the OU structure

Create three OUs: Workloads, Audit, Sandbox. The aws_organizations_organizational_unit resource is what you want.

resource "aws_organizations_organization" "this" {
  feature_set = "ALL"
  enabled_policy_types = ["SERVICE_CONTROL_POLICY"]
}

resource "aws_organizations_organizational_unit" "workloads" {
  name      = "Workloads"
  parent_id = aws_organizations_organization.this.roots[0].id
}

4. Create the member accounts

Use aws_organizations_account to create the workload and audit accounts. AWS issues each one a unique email (use Gmail's + aliasing or a catch-all).

5. Write your first SCP

Start with deny root user activity — the simplest non-trivial guardrail. Then add: deny disabling CloudTrail, deny regions other than us-east-1, require IMDSv2 on EC2 launches, require MFA for sensitive actions. Apply at the Workloads OU.

6. Set up IAM Identity Center

Enable Identity Center in the management account, create one permission set called AdminAccess, create one user (yourself), and assign that user to one account via the permission set. Sign in to the user portal and confirm SSO works end-to-end.

7. Centralize CloudTrail in the audit account

Enable an organization trail from the management account writing to a bucket in the audit account. Configure the bucket with object-lock (compliance mode, short retention so you can delete the lab later) and bucket policies that prevent deletion.

8. Test the guardrails by trying to violate them

Sign into a workload account, try to launch an instance in a forbidden region, try to disable CloudTrail, try to launch with IMDSv1. The SCPs should block each one. Screenshot every denial.

9. Document the design decisions

In the README: why three accounts? Why these SCPs? What's the threat model each one addresses? What would you add for production? What did you skip and why? This is the section hiring managers actually read.

10. Tear down (or keep)

This lab can stay running cheaply if you keep CloudTrail volume low — the org itself costs nothing. Or destroy when done; closing accounts in Organizations takes 90 days though, so factor that in.

What hiring managers look for

• Your Terraform is modular and re-usable, not one giant main.tf.
• Your SCPs include comments explaining the threat each one addresses.
• You used aws_iam_policy_document data sources rather than inlining JSON — shows you've worked with IAM at scale.
• Your README discusses trade-offs ("I considered ControlTower but chose hand-rolled SCPs because…").
• You can speak to what you'd change for production scale (account vending automation, AFT, Service Catalog, etc.).

Common mistakes

• Trying to use a hand-clicked org. Use Terraform from the start; it's the artifact.
• Granting AdministratorAccess to your SSO user without a JIT pattern. Pretend it's real — use a less-privileged default and elevate when needed.
• Skipping the SCP-violation testing. The screenshots of denied actions are some of the most compelling evidence of working guardrails.
• Forgetting that closing AWS accounts takes 90 days. Plan the teardown.
• Hard-coding account IDs into your Terraform. Use data sources or variables.

Where to publish

The full publishing playbook is on the portfolio hub page. The short version: a public GitHub repo with a thorough README is the strongest single signal; pair it with a LinkedIn post and (optionally) a 5-minute lightning talk at a CSOH Friday Zoom.