Govern Multi-Account AWS Environments

Set up AWS Control Tower with OUs, guardrails, and Account Factory.

Introduction

30 Second Summary

When a company runs dozens of cloud accounts without central oversight, one misconfigured permission can expose customer data or rack up thousands in surprise charges. Governance at scale means setting security rules once and having them automatically apply to every account in your organization.

In this project, you will set up AWS Control Tower to create a fully governed multi-account environment. You'll configure organizational units, enable security controls, and provision a new account that automatically inherits your governance policies.

What You'll Build

A centralized governance layer on AWS that enforces security best practices across all accounts using preventive, detective, and proactive controls.

By the end of this project, you'll have:

A landing zone with a Security OU and Sandbox OU, plus centralized logging through dedicated Log Archive and Audit accounts.
Preventive and detective controls enabled on your Sandbox OU to block policy violations and monitor compliance automatically.
A new member account provisioned through Account Factory with governance policies applied from the moment it's created.
Secret Mission: Enable a proactive control that blocks non-compliant CloudFormation deployments before they happen.

Are there any prerequisites?

You need an AWS account with administrator access. You also need three unique email addresses: one already associated with your management account, one for the Log Archive account, and one for the Audit account. These cannot be reused across AWS accounts.

Prepare Your AWS Account

Before you can build a governed multi-account environment, you need to make sure your AWS account is ready for AWS Control Tower.

Control Tower makes a few permanent decisions during setup. The most important is your Home Region, which determines where your governance infrastructure lives. Getting this right now saves you from having to tear everything down later.

In this step, get ready to:

Sign in to the AWS Management Console and confirm your Home Region.
Verify you have three unique email addresses ready for account creation.
Navigate to the AWS Control Tower console and confirm the service is available.

Sign in and verify your Home Region

Your Home Region is the AWS Region where Control Tower deploys its core governance resources. It cannot be changed after setup, so choose the Region where you plan to run most of your workloads.

Open your browser and navigate to the AWS Management Console at https://console.aws.amazon.com.
Sign in with your root or administrator credentials.
Look at the Region selector in the upper-right corner of the console. This displays your current Region.
Click the Region selector and choose the Region you want as your permanent Home Region (for example, US East (N. Virginia) us-east-1).

What is a Home Region?

Your Home Region is where AWS Control Tower stores its configuration and runs its governance logic. By default, Control Tower selects whichever Region your console is currently operating in.

Pick the Region closest to your team or where you expect to deploy most workloads. Changing it later requires decommissioning the entire landing zone and starting over with AWS Support assistance.

Can't sign in?

Make sure you're using an account with administrator access. If you're using an IAM user, confirm it has the AdministratorAccess policy attached.

If you've forgotten your root account password, use the Forgot password? link on the sign-in page to reset it.

help me sign in to my AWS Management Console

Confirm your three email addresses

AWS Control Tower creates two shared accounts during setup: a Log Archive account and an Audit account. Each requires a unique email address that is not already associated with any AWS account.

Confirm you have these three email addresses ready:
Verify that the Log Archive and Audit email addresses are not already used by any existing AWS account.

Why three separate email addresses?

AWS requires every account to have a unique email address. Control Tower uses this constraint to create distinct, purpose-built accounts for logging and auditing.

The Log Archive account centralizes all CloudTrail and Config logs from every account in your organization. The Audit account gives your security team a read-only view into compliance data across all accounts.

Use email aliases

If you use Gmail or a similar provider, you can create aliases by adding a plus sign. For example, yourname+logarchive@gmail.com and yourname+audit@gmail.com both deliver to your main inbox while counting as unique addresses.

Navigate to the AWS Control Tower console

Now that your Region is set and your emails are ready, confirm that the Control Tower service is available in your chosen Region.

In the AWS Management Console search bar at the top, type Control Tower and select AWS Control Tower from the results.
Alternatively, navigate directly to https://console.aws.amazon.com/controltower.
Verify that the Region displayed in the upper-right corner still matches the Home Region you chose earlier.
Confirm you see the Control Tower landing page with a Set up landing zone button. Do not click it yet.

What should I see?

The Control Tower console displays a welcome page explaining what the service does and how it sets up your multi-account environment. The key indicator that everything is ready is the presence of the Set up landing zone button.

If you see this button, Control Tower is available in your selected Region and your account meets the prerequisites.

Don't see the Control Tower console?

Check that you're signed in with an account that has administrator permissions. Control Tower is not visible to users without sufficient access.

Also verify your Region supports AWS Control Tower. Most major Regions do, but some newer or opt-in Regions may not have the service available yet.

help me access the AWS Control Tower console

Your account is prepped and ready. Next up, you'll click that button and configure the full landing zone with organizational units, centralized logging, and security accounts.

Set Up Your Landing Zone

Your AWS account is prepared and the Control Tower console is open. Now it's time to create your landing zone.

A landing zone is the automated foundation that governs every account in your AWS organization. Control Tower creates Organizational Units, shared security accounts, and logging baselines in a single setup process. Without it, you would need to manually wire up dozens of services yourself.

In this step, get ready to:

Configure your Home Region and organizational unit structure.
Set up the Log Archive and Audit accounts with designated email addresses.
Launch the landing zone creation and wait for it to complete.

Start the landing zone configuration

The setup wizard walks you through several configuration screens. You will confirm your Region, name your organizational units, and provide email addresses for the shared accounts.

Click Set up landing zone on the AWS Control Tower console page.
Review the Home Region field at the top. It should already display your chosen Region. This cannot be changed after setup.
Confirm the Foundational OU name is set to Security.
Confirm the Additional OU name is set to Sandbox.

What are Organizational Units?

Organizational Units (OUs) are logical containers inside AWS Organizations that group related accounts. The Security OU holds accounts dedicated to logging and auditing. The Sandbox OU is where you will place new workload accounts later.

Separating accounts by purpose makes it easy to apply different governance rules to each group.

Why can't I change the Home Region later?

Control Tower stores governance metadata and deploys resources in your Home Region. Changing it after setup would require decommissioning the entire landing zone with AWS Support assistance. Choose the Region closest to where you run most workloads.

Enter account emails and review optional settings

Control Tower creates two shared accounts during setup. Each account needs a unique email address that is not used by any other AWS account.

In the Log Archive account section, enter the email address you prepared for this account.
In the Audit account section, enter the email address you prepared for this account.
Review the CloudTrail configuration. CloudTrail is enabled by default to record all API activity across your organization.
Review the Log retention settings. Standard retention is set to 1 year. Access logging retention is set to 10 years.
Review the IAM Identity Center configuration. IAM Identity Center is managed by Control Tower by default, giving you centralized single sign-on across all accounts.

What do the Log Archive and Audit accounts do?

The Log Archive account stores centralized logs from every account in your organization. All CloudTrail events and AWS Config snapshots flow into an S3 bucket in this account.

The Audit account gives your security team cross-account read access to review compliance findings. It also receives SNS notifications when controls detect violations.

Account names cannot be changed later

The display names you give the Log Archive and Audit accounts during setup are permanent. Double-check spelling before you proceed.

Confirm and launch the landing zone setup

You are now ready to finalize your configuration and kick off the automated setup process.

Scroll down to the Service permissions section and review the permissions Control Tower needs.
Select the checkbox labeled I understand the permissions AWS Control Tower will use to administer AWS resources and enforce rules on my behalf.
Click Set up landing zone to begin the creation process.

What happens during the 30-minute setup?

Control Tower creates your Root-level organization, the Security OU with your Log Archive and Audit accounts, and the empty Sandbox OU. It also configures CloudTrail trails, AWS Config rules, and IAM Identity Center in the background.

You can monitor progress on the Landing zone settings page. The setup takes approximately 30 minutes to complete.

What is the one-time cost?

The landing zone creation incurs a one-time charge of approximately $0.03 for initial AWS Config recording and CloudTrail event logging. Ongoing costs depend on your number of accounts and Regions.

Stay on the Landing zone settings page and watch for the status to change to a success state. You do not need to keep the browser tab open the entire time.
Check the email inbox for your Audit account. You will receive subscription confirmation emails from each governed Region. Click Confirm subscription in each email to enable compliance notifications.

Setup stuck or showing a failure?

If the landing zone setup fails or remains in progress beyond 45 minutes, check that your account has no pre-existing AWS Organizations setup that conflicts with Control Tower.

Also confirm that the email addresses you entered are not already associated with another AWS account. Duplicate emails cause account creation to fail silently.

If the issue persists, contact AWS Support for diagnostic assistance.

Help me troubleshoot my Control Tower landing zone setup failure.

Your landing zone is live. Next up, you will explore the organizational structure that Control Tower just created and see how your accounts and OUs are connected.

Explore Your Landing Zone Structure

Your landing zone is now fully set up. You have a multi-account environment with two Organizational Units, centralized logging, and governance controls already in place.

Before you start adding controls and provisioning accounts, it helps to understand the structure Control Tower built for you. In this step, you will navigate the Dashboard, Organization view, and Controls library to see how everything fits together.

In this step, get ready to:

Review your landing zone summary on the Control Tower Dashboard.
Explore the Organization view to see OUs and accounts.
Review the Controls library to understand mandatory vs optional controls.

Review the Control Tower Dashboard

The Dashboard gives you a bird's-eye view of everything AWS Control Tower manages. It surfaces your OUs, accounts, and active controls in one place.

In the left navigation of the Control Tower console, click Dashboard.
Review the summary panel at the top of the page.
Confirm you see two OUs listed: Security and Sandbox.
Confirm you see three accounts listed: your management account, Log Archive, and Audit.
Note the number of enabled controls shown in the summary.

What does the Dashboard show?

The Dashboard is your governance command center. It shows the total number of OUs, accounts, and controls in your environment at a glance.

The enabled controls count represents the mandatory controls that Control Tower applied automatically during setup. These protect your landing zone resources and cannot be deactivated.

Don't see the Dashboard?

If the landing zone setup is still in progress, the Dashboard will not show the full summary yet. Return to the landing zone settings page and confirm the status shows as complete before continuing.

Help me find the Control Tower Dashboard after setup.

Explore the Organization view

The Organization page shows your full account hierarchy. This is where you can see which accounts are nested inside which OUs.

In the left navigation, click Organization.
You should see a hierarchical list of your OUs and accounts.
Click on the Security OU name to expand its details.
Confirm you see the Log Archive and Audit accounts nested inside the Security OU.
Navigate back to the Organization page and click on the Sandbox OU.
Confirm the Sandbox OU is empty and ready for new accounts.

Why two separate OUs?

The Security OU isolates your logging and auditing infrastructure from everyday workloads. Nobody should deploy applications into the Security OU.

The Sandbox OU is where you will provision new member accounts for actual work. Any controls you enable on the Sandbox OU automatically apply to every account inside it.

Review the Controls library

Controls are governance rules that Control Tower enforces across your accounts. They come in different categories depending on how critical they are.

In the left navigation, click Controls.
Review the list of controls that are already enabled on your landing zone.
Notice that the enabled controls are labeled as Mandatory in their guidance category.
Look at the behavior column to see whether each control is Preventive or Detective.

What is the difference between mandatory and optional controls?

Mandatory controls are applied by default during landing zone setup and cannot be deactivated. They protect core AWS Control Tower resources like CloudTrail trails and AWS Config rules.

Optional controls fall into two guidance categories: strongly recommended and elective. You choose which ones to enable based on your security and compliance needs. You will enable some of these in the next step.

What are preventive, detective, and proactive controls?

Preventive controls use Service Control Policies (SCPs) to block actions before they happen. Detective controls use AWS Config rules to detect violations after they occur.

There is also a third type called proactive controls. These use CloudFormation Hooks to block non-compliant resources before they are even created. You will explore proactive controls in the Secret Mission.

You now have a clear picture of your landing zone structure. Next up, you will enable preventive and detective controls on your Sandbox OU to enforce security best practices on any accounts you provision there.

Enable Preventive and Detective Controls

Your landing zone provides the organizational structure, but structure alone doesn't stop misconfigurations from happening inside your accounts.

Controls are the enforcement layer that actively governs what can and cannot happen. In this step, you'll enable two types: a preventive control that blocks dangerous actions before they happen, and a detective control that monitors for violations after resources are deployed.

In this step, get ready to:

Enable a preventive control that blocks unauthorized S3 bucket policy changes.
Enable a detective control that monitors EBS volume encryption.
Verify both controls appear on your Dashboard with a Clear compliance status.

Enable a preventive control on your Sandbox OU

Preventive controls are implemented with Service Control Policies (SCPs). They act as guardrails that block API actions entirely, so the prohibited action never executes in the first place.

In the Control Tower console, click Controls library in the left navigation.
Click the Behavior filter dropdown.
Select Preventive.
Find the strongly recommended control named Disallow Changes to Bucket Policy for Amazon S3 Buckets and click on it.
Click Enable control.
Select your Sandbox OU from the list.
Click Enable control to confirm.

What does this preventive control do?

This control creates an SCP that prevents anyone from modifying S3 bucket policies in accounts under the Sandbox OU. The status of a preventive control is either enforced or not enabled. There is no in-between.

Once enforced, the blocked action simply fails if anyone attempts it. The control is supported in all AWS Regions.

After a few moments, the control status should show as Enabled on the Sandbox OU.

Control not showing as enabled?

Make sure you selected the Sandbox OU (not the Security OU) when enabling the control. If the status is still processing, wait a minute and refresh the page.

Help me troubleshoot why my preventive control isn't enabling on my Sandbox OU in AWS Control Tower.

Enable a detective control on your Sandbox OU

Detective controls work differently from preventive ones. Instead of blocking actions, they monitor your environment and flag resources that don't meet compliance standards. They are implemented with AWS Config rules.

Return to the Controls library in the left navigation.
Click the Behavior filter dropdown.
Select Detective.
Find the strongly recommended control named Detect Whether Encryption is Enabled for Amazon EBS Volumes Attached to Amazon EC2 Instances and click on it.
Click Enable control.
Select your Sandbox OU from the list.
Click Enable control to confirm.

What is ConfigBaseline?

Enabling your first detective control requires AWS Config recording (ConfigBaseline) to be active on the target OU. If prompted, allow Control Tower to enable ConfigBaseline on your Sandbox OU.

ConfigBaseline is what enables AWS Config to continuously record the configuration state of resources in your accounts. Without it, detective controls have nothing to evaluate against.

How do detective control statuses differ from preventive ones?

A detective control has three possible statuses: clear (no violations found), in violation (non-compliant resources detected), or not enabled. Detective controls only apply in Regions supported by AWS Control Tower.

The detective control may take a few minutes to fully activate while AWS Config begins recording in the Sandbox OU accounts.

Seeing an error about ConfigBaseline?

If Control Tower asks you to enable ConfigBaseline first, follow the on-screen prompts to activate it on the Sandbox OU before retrying the detective control. This is a one-time setup per OU.

Help me resolve the ConfigBaseline requirement when enabling a detective control in AWS Control Tower.

Verify your enabled controls on the Dashboard

Now that both controls are enabled, you can confirm they are actively governing your Sandbox OU from the main Dashboard.

Click Dashboard in the left navigation.
Look for the Enabled controls summary on the Dashboard.
Confirm that both your newly enabled controls appear in the list.
Check that the compliance status shows Clear for both controls. This means no violations have been detected yet.

Why does my compliance status show Clear?

Your Sandbox OU currently has no accounts with resources deployed in it. Since there are no resources to evaluate, there are no violations. The status will change to In violation if a future account creates a non-compliant resource (like an unencrypted EBS volume).

Your Sandbox OU is now actively governed by two layers of protection. Next up, you'll provision a brand new account through Account Factory and see these controls automatically apply to it.

Provision a New Account with Account Factory

Your governance controls are active and ready to enforce compliance. Now it's time to see the real power of this setup by provisioning a brand-new AWS account that automatically inherits every control you enabled.

Account Factory is Control Tower's built-in tool for creating new member accounts. Every account it provisions lands in the OU you specify and immediately picks up all the controls enabled on that OU.

In this step, get ready to:

Navigate to Account Factory and configure a new account's details.
Review network configuration defaults and launch provisioning.
Verify the new account inherits all governance controls from the Sandbox OU.

Navigate to Account Factory and configure account details

Account Factory lets you create a new AWS account with a few form fields. The account email, display name, and destination OU are the key inputs.

In the AWS Control Tower console, click Account Factory in the left navigation panel.
Click Create account.
In the Account email field, enter a unique email address for this new account. This email cannot already be associated with another AWS account.
In the Display name field, enter Development-Workload.
In the IAM Identity Center section, enter the SSO user email address. This user will have administrative access to the new account.
For the Organizational unit dropdown, select Sandbox as the destination OU.

What is Account Factory doing here?

Account Factory uses AWS Service Catalog under the hood to provision accounts. When you fill in these details, Control Tower will create a brand-new AWS account, link it to your organization, place it in the Sandbox OU, and configure IAM Identity Center access for the SSO user you specified.

The account email must be globally unique across all of AWS. If you use an email that's already tied to an existing AWS account, provisioning will fail.

Use email aliases for multiple accounts

If you use Gmail, you can add a + suffix to create unique addresses from one inbox. For example, yourname+dev-workload@gmail.com routes to your main inbox but counts as a unique email for AWS.

Review network settings and provision the account

Before finalizing, Control Tower shows you the default network configuration it will apply to the new account. This includes VPC settings like CIDR ranges and subnet layout.

Review the Account factory network configuration section. The defaults configure a VPC with subnets in your governed Regions.
Accept the default network configuration for this project.
Click Create account to begin provisioning.

How long does provisioning take?

Account provisioning typically takes several minutes. Control Tower is creating a new AWS account, configuring Organizations membership, setting up IAM Identity Center access, deploying the VPC, and applying all controls from the Sandbox OU.

You can monitor progress on the Organization page. The account status will show as provisioning in progress until it completes.

Wait for the provisioning to complete. You can refresh the page periodically to check the status.
Once you see the account status change to Enrolled, provisioning is finished.

Account provisioning failed?

The most common cause is using an email address that's already associated with an existing AWS account. Double check that the email is globally unique.

Another common issue is insufficient permissions. You must be signed in with an IAM user or role that has the required Service Catalog and Control Tower permissions. Do not sign in as the root user.

Why did my Account Factory provisioning fail?

Verify the new account and its inherited controls

The real payoff of Control Tower is that governance follows accounts automatically. Every control on the Sandbox OU should now apply to your new Development-Workload account without any extra configuration.

Click Organization in the left navigation.
Click on the Sandbox OU to expand it.
Verify that Development-Workload appears as a member account under the Sandbox OU.
Click on the Development-Workload account to view its details.
Confirm that the controls enabled on the Sandbox OU are listed as applied to this account.

Why are controls inherited automatically?

Controls in AWS Control Tower are applied at the OU level, not at the individual account level. When you enable a preventive control (SCP) on the Sandbox OU, that policy restricts every account in the OU. When you enable a detective control (AWS Config rule), it monitors every account in the OU.

This means any future account you place in the Sandbox OU will also inherit these controls. You never have to remember to apply governance to each new account individually.

Navigate back to the Dashboard in the left navigation.
Review the compliance summary. It should show all accounts in a Clear state with no violations detected.

Your Dashboard now shows the full organizational health across your management account, Log Archive, Audit, and the new Development-Workload account.

Don't see the new account under Sandbox?

Provisioning may still be in progress. Return to the Organization page and refresh. The account will appear once provisioning completes.

If you see a Failed status, click the account to view the error details. The most frequent cause is a duplicate email address or a permissions issue with the provisioning role.

Help me find my new account in the Control Tower Organization view

Secret mission

Enable a Proactive Control

You've enabled preventive controls that block API actions and detective controls that catch violations after the fact. But what if you could stop non-compliant resources from being created in the first place? In this secret mission, you'll enable a proactive control that scans CloudFormation templates before deployment and rejects anything that doesn't meet your standards.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. Your landing zone incurs ongoing charges from AWS Config and CloudTrail even when idle.

Cost warning

Your AWS Control Tower landing zone incurs approximately $3.75/month for a small setup (10 accounts, 1 Region). These charges come from AWS Config recording configuration items and evaluating rules, plus CloudTrail management event logging.

If you do not plan to use this environment going forward, choose the Delete option below to decommission the landing zone and close member accounts.

Resources you used:

AWS Control Tower landing zone (ongoing AWS Config and CloudTrail charges).
Log Archive account (S3 storage costs for centralized logs).
Audit account (minimal costs unless you add monitoring tools).
Development-Workload account provisioned via Account Factory (costs depend on what you deploy inside it).

Keep everything running

No action needed. Choose this if you plan to use this as your real AWS multi-account environment going forward.

Your landing zone continues governing all accounts under your organizational units.
Expect approximately $3.75/month for a small setup (10 accounts, 1 Region) from AWS Config and CloudTrail charges.
AWS Control Tower itself has no additional charge.
You can continue adding accounts via Account Factory and enabling additional controls at any time.

Pause - I'll come back to this later

AWS Control Tower cannot be paused. However, costs remain minimal if you do not deploy workloads into your accounts.

Leave your landing zone as-is. The governance layer stays active with minimal charges.
Avoid provisioning new accounts or deploying resources into existing member accounts to keep costs low.
When you return, your OUs, controls, and accounts will be exactly as you left them.

Delete - I don't want to use this again

Remove all Control Tower governance and close member accounts you no longer need. This is a destructive action that cannot be easily undone.

Decommission your landing zone by following these steps:

Navigate to the Landing Zone Settings page in the AWS Control Tower console.
Choose Decommission your landing zone within the Decommission your landing zone section.
Select every confirmation box and type the confirmation as requested. The process takes up to two hours.
After decommissioning completes, some resource artifacts remain (S3 buckets, CloudWatch Logs log groups). Delete these manually from the S3 and CloudWatch consoles to avoid unexpected charges.

Close individual member accounts if you no longer need them:

Open the AWS Organizations console and sign in to your management account.
On the AWS accounts page, find and select the member account you want to close (e.g., Development-Workload, Log Archive, or Audit).
Choose Close next to the account name at the top of the page.
Enter the member account ID, then choose Close account.
Repeat for each member account you want to close. Closed accounts display a CLOSED label for up to 90 days before permanent removal.

Your management account stays open

Decommissioning removes Control Tower governance but does not delete your AWS accounts or your AWS Organization. Your management account remains active. You cannot close it from the Organizations console.

Nice Work!

You've just built an enterprise-grade multi-account governance layer on AWS. Your environment now automatically enforces security best practices across every account, from the moment they're created.

Here's what you learned:

Set up an AWS Control Tower landing zone with a Security OU and Sandbox OU, establishing a governed multi-account foundation.
Enabled preventive controls (SCPs) to block policy violations and detective controls (AWS Config rules) to monitor compliance across your organization.
Provisioned a new account via Account Factory with governance controls automatically inherited from its parent OU.
Enabled a proactive control that uses CloudFormation Hooks to block non-compliant resource deployments before they are created.

Ready to quiz yourself?