Build a Multi-Account AWS Landing Zone with AWS Organizations

This milestone turns your account into the management account and lets the AWS services you use later work across all member accounts. Without trusted access, an organization trail and a service-managed StackSet cannot see your other accounts.

Allow CloudTrail and StackSets to work across accounts:

Your shell variables disappear when the terminal closes, so write them to a file you can source at the start of every session:

Common Mistake

Running every later command in a new terminal without sourcing landing-zone.env. You will get empty IDs and confusing errors such as "parent-id is required". Run source landing-zone.env first.

An OU is a folder of accounts. SCPs attach to OUs and every account inside inherits them, so the tree should mirror which guardrails apply to which accounts, not your org chart.

Verify the tree:

You should see Security, Logging and Workloads.

Common Mistake

Putting Production and Non-Production directly under the root. Then a rule meant for "all workloads" has to be attached twice and will drift. Nest them under Workloads so one attachment covers both.

Account creation is asynchronous, so this helper creates the account, polls until it is ready, and moves it into the right OU. Each new account gets its own root user, IAM namespace and an OrganizationAccountAccessRole that the management account can assume.

Security

In a real company, use shared team aliases such as aws-prod@yourcompany.com, never a personal address. The root email cannot be changed without access to that inbox, so an account tied to one person is lost when that person leaves.

Common Mistake

Hitting the default account quota on a new organization and seeing ACCOUNT_LIMIT_EXCEEDED. New organizations start with a small account limit. Request an increase in Service Quotas if you plan to add more accounts.

Each SCP below removes one specific risk. You attach them to the Non-Production OU first and only promote them to Production after you have proven they behave, because a bad SCP at a high level can lock out your own team.

SCPs apply to every principal in the account, including your own pipelines. If a CI role needs a region you blocked, add a Condition that exempts that role, for example with aws:PrincipalArn.

Common Mistake

Attaching a new SCP straight to the root. It affects every account at once and a typo can block IAM changes everywhere. Always attach to one test OU first, test, then widen the scope.

An organization trail records API activity from every account, present and future, into one S3 bucket. The bucket lives in the LogArchive account and denies deletes to everyone in the organization, so the evidence survives a compromise of any workload account.

First, a helper to work inside a member account by assuming the role Organizations created:

Create and lock down the bucket from inside LogArchive:

Now create the trail from the management account:

Security

--enable-log-file-validation writes a signed digest for every log file, so you can later prove logs were not altered. Many compliance frameworks expect this and it costs nothing extra. For stricter retention, S3 Object Lock is a good extension once you understand the lifecycle trade-offs.

Common Mistake

Creating the trail before the bucket policy exists. CloudTrail then fails with InsufficientS3BucketPolicyException. Apply the policy first, then create the trail.

GuardDuty watches for suspicious activity such as unusual API calls or crypto-mining behaviour. By making the Security account the delegated administrator, findings from every account appear in one place and new accounts are enrolled automatically. GuardDuty is regional, so you repeat the setup in each approved region.

Member enrolment can take a few minutes. Check it:

Tip

The management account is also a member. If it does not appear as Enabled, that is the first thing to check when findings look incomplete.

Re-running setup commands for every new account does not scale. A service-managed StackSet deploys the same CloudFormation template to every account in an OU, including accounts you add later. This template gives each workload account a read-only audit role for the Security account and a monthly cost budget, which is how you get per-account cost visibility.

Common Mistake

Deploying a template with a fixed IAM role name to two regions. IAM is global, so the second region fails with "already exists". Deploy IAM resources to one region only.

An SCP that looks right in JSON may be attached to the wrong target or never take effect. Test with a real denied action, using the Development account as the safe test bed.

Both denied calls should fail with a message that includes explicit deny in a service control policy. SCP changes can take a few minutes to apply, so retry after a short wait before assuming something is wrong.

Once you are happy, promote the two workload SCPs to Production:

Tip

Screenshot the denied call. It is the single most convincing artifact in this project because it shows a guardrail working, not just existing.

Run each check and compare with the expected result.

Within about 15 minutes of enabling the trail, logs from the member accounts should appear under AWSLogs/ in the bucket. Check from the LogArchive account with aws s3 ls s3://$BUCKET/AWSLogs/ --recursive | head.

Cleanup

• Detach SCPs, then close the four member accounts with aws organizations close-account --account-id ID. AWS limits how many accounts you can close in a rolling 30-day window, and closed accounts stay visible for a while.
• Delete the StackSet instances and then the StackSet, and stop or delete the trail.
• The bucket policy denies deletes on purpose. To empty it, first remove the NobodyInTheOrgCanDelete statement from inside the LogArchive account.
• Disable GuardDuty in both regions to stop charges.

Common Mistake

Forgetting that the management account is exempt from every SCP. If you test a guardrail from the management account it will appear not to work. Always test from a member account.

Commit the scripts with a README that includes your architecture diagram and the screenshot of the denied call. A reviewer can see that you understand account isolation, guardrails and tamper-proof logging.