Set Up an AWS Landing Zone

Deploy a governed multi-account AWS environment with Control Tower.

Introduction

30 Second Summary

When a team grows beyond a single person, a shared AWS account becomes a liability. Without structure, anyone can accidentally delete critical resources, run up costs, or access sensitive data they shouldn't see.

In this project, you will set up an AWS landing zone using Control Tower to create a secure, governed multi-account environment for a team of 4. You'll configure centralized logging, billing controls, security guardrails, and single sign-on access.

What You'll Build

A production-ready AWS Control Tower landing zone that gives your team secure, governed access to AWS through a multi-account structure.

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

  • A governed multi-account AWS environment with a Security OU (Log Archive and Audit accounts) and a Sandbox OU for team workloads.
  • Centralized logging, cost budgets, and security guardrails enforcing best practices across all accounts.
  • IAM Identity Center configured with 4 team members assigned to role-based access groups through a single sign-on portal.
  • Secret Mission: Create a custom Service Control Policy that restricts resource creation to only your home region.

Are there any prerequisites?

You need an existing standalone AWS account with root or administrator access. The account should not already be part of an AWS Organizations organization.

You'll also need two additional unique email addresses for the shared accounts that Control Tower creates (Log Archive and Audit). Gmail aliases like yourname+logarchive@gmail.com work perfectly.

Prepare Your Account

Before you can deploy a landing zone, your AWS account needs to be free of configuration conflicts that could block the setup process.

In this step, you'll verify your account is ready for AWS Control Tower by removing any existing AWS Config recorders, confirming your email addresses, and locking in your home region choice.

In this step, get ready to:
  • Verify no existing AWS Config configuration recorders or delivery channels will block setup.
  • Confirm two unique email addresses for your shared accounts.
  • Navigate to the AWS Control Tower console and confirm your home region.
Check for AWS Config blockers

If your account has an existing AWS Config configuration recorder or delivery channel, Control Tower setup will fail. Most standalone accounts do not have these active, but it is important to check.

  • In the AWS Management Console, type Config in the search bar at the top and select Config from the results.
  • Make sure the region selector in the top-right of the console is set to your chosen home region.
  • In the left navigation pane, choose Settings.
  • On the Customer managed recorder tab, check if a configuration recorder exists.

✔️ No recorder exists

If the Settings page shows no customer managed configuration recorder (or the page prompts you to set up AWS Config), you are clear to proceed. Skip to the next substep.

ⓧ A recorder is active

You need to delete the configuration recorder and its delivery channel before Control Tower can set up. You will use AWS CloudShell to run the required CLI commands.

  • Open CloudShell by clicking the CloudShell icon on the console navigation bar (it looks like a terminal prompt).
  • Wait for the shell prompt to appear. CloudShell is pre-authenticated with your console credentials.
  • Stop the configuration recorder by running this command:
aws configservice stop-configuration-recorder --configuration-recorder-name default
  • Delete the configuration recorder by running:
aws configservice delete-configuration-recorder --configuration-recorder-name default
  • Delete the delivery channel by running:
aws configservice delete-delivery-channel --delivery-channel-name default

What do these commands do?

The configuration recorder tracks changes to your AWS resources. The delivery channel sends those recorded changes to an S3 bucket. Control Tower needs to set up its own versions of both, so any existing ones must be removed first.

The default name default is used by AWS Config unless you previously customized the recorder or channel name. If your recorder has a different name, replace default with that name. You can check the name by running:

aws configservice describe-configuration-recorders
  • Verify both are deleted by running:
aws configservice describe-configuration-recorders

You should see an empty list: "ConfigurationRecorders": [].

  • Also confirm the delivery channel is removed by running:
aws configservice describe-delivery-channels

You should see: "DeliveryChannels": [].

Getting a "cannot be deleted" error?

If you see an error when trying to delete the delivery channel, make sure you stopped the configuration recorder first. The recorder must be stopped before the delivery channel can be deleted.

If you see a "does not exist" error, that means the resource was already removed or never existed. You can safely proceed.

help me troubleshoot AWS Config deletion errors in CloudShell

Prepare your email addresses

Control Tower creates two shared accounts as part of the landing zone: a Log Archive account and an Audit account. Each requires a unique email address that is not already associated with an AWS account.

  • Confirm you have two unique email addresses ready. If you do not have separate addresses, Gmail aliases work. For example:
  • Write both addresses down or save them in a note. You will need them in the next step when launching Control Tower.

What are Gmail aliases?

Gmail treats anything after a + sign as the same inbox. So yourname+logarchive@gmail.com delivers to the same inbox as yourname@gmail.com. AWS sees each alias as a unique address, making it perfect for creating multiple accounts from one inbox.

Keep these addresses accessible

You will need to verify the email addresses during account creation. Make sure you can receive emails at both addresses throughout this project.

Choose and confirm your home region

Your home region is where Control Tower deploys its core resources and where IAM Identity Center will run. This choice is permanent. Changing it after setup requires decommissioning the landing zone with AWS Support assistance.

  • Decide which AWS Region will be your home region. Pick the region closest to you or your team, where you plan to run most workloads.
  • In the AWS Management Console, confirm the region selector (top-right corner) shows your chosen region.
  • Navigate to the AWS Control Tower console by typing Control Tower in the search bar and selecting AWS Control Tower from the results.
  • Confirm that the region displayed in the console header matches your intended home region.

Your home region cannot be changed later

Once Control Tower is set up, changing the home region requires decommissioning the entire landing zone. This process needs AWS Support assistance and is not recommended. Double check your region selection now before proceeding.

What is a home region?

The home region is where Control Tower stores its configuration data and where IAM Identity Center (your team's single sign-on portal) operates. All governance resources are anchored here. Choose a region with low latency for your team and good service availability.

Your account is now clean and ready for Control Tower. Next up, you will launch the landing zone setup and watch AWS build your multi-account foundation.

Launch AWS Control Tower

With your prerequisites cleared and email addresses ready, it's time to deploy your landing zone.

A landing zone is the foundational multi-account environment that AWS Control Tower builds for you. It creates your AWS Organization, shared security accounts, organizational units, and baseline guardrails in one automated process.

In this step, get ready to:
  • Initiate the Control Tower landing zone setup wizard.
  • Configure your foundational OU and shared accounts.
  • Launch the automated provisioning and verify completion.
Initiate the landing zone setup

The Control Tower setup wizard walks you through configuring your multi-account environment. It starts by confirming your home region and showing pricing details for the underlying services.

  • In the AWS Control Tower console, choose Set up landing zone.
  • Confirm that the region displayed in the upper-right corner of the console matches your chosen home region.

What is the home region?

Your home region is the AWS Region where Control Tower provisions shared resources and where IAM Identity Center lives. You selected this in the previous step. It cannot be changed after setup without decommissioning the entire landing zone.

What about costs?

AWS Control Tower itself has no additional charge. You pay only for the underlying services it enables (AWS Config, CloudTrail, S3) based on usage.

For a small team with light practice usage, expect roughly $0.05 to $0.50 per month total.

Configure the foundational OU and shared accounts

Control Tower needs to know where to place your security accounts and what email addresses to associate with them. The wizard guides you through each field.

  • Accept the default foundational OU name: Security. This is the organizational unit that will contain your Log Archive and Audit accounts.
  • In the Log Archive account section, enter the email address you prepared for the Log Archive account (e.g., yourname+logarchive@gmail.com).
  • In the Audit account section, enter the email address you prepared for the Audit account (e.g., yourname+audit@gmail.com).
  • Create an additional OU by entering Sandbox as the name. This OU will hold team workload accounts later.
  • Leave the remaining optional configurations (CloudTrail, log retention, KMS encryption) at their default settings.

Why two separate accounts for logging and auditing?

Separating log storage from audit access is a security best practice. The Log Archive account holds all centralized logs where nobody except approved automation can modify them. The Audit account gives your security team read-only cross-account access for investigations.

If both responsibilities lived in one account, a compromised admin could both tamper with logs and cover their tracks.

Launch the setup and wait for provisioning

The final screen asks you to review service permissions and agree to the Terms of Service before Control Tower begins creating resources across your accounts.

  • Review the Service permissions section. Expand each topic to see what Control Tower will do on your behalf.
  • Select the checkbox: I understand the permissions AWS Control Tower will use to administer AWS resources and enforce rules on my behalf.
  • Choose Set up landing zone to start the automated provisioning.

What happens during provisioning?

Control Tower creates your AWS Organization, the Security OU with your Log Archive and Audit accounts, the Sandbox OU, an organization-level CloudTrail trail, AWS Config across all enrolled accounts, and IAM Identity Center with preconfigured groups. This process takes approximately 30 minutes.

You can leave the browser tab open and check back periodically. Do not navigate away from the Control Tower console or close it during provisioning.

Confirm your SNS subscription emails

While you wait, check the inbox of your Audit account email address. You will receive subscription confirmation emails from AWS for each supported region. Click the Confirm subscription link in each email to enable compliance notifications for your Audit account.

  • Wait for the landing zone setup to complete. The Control Tower dashboard will display your landing zone as active with your OUs and accounts listed.
  • Confirm you see the Security OU listed with two accounts (Log Archive and Audit) and the Sandbox OU listed with zero accounts.

Setup taking longer than 30 minutes?

Common causes of landing zone launch failure include a lack of response to the SNS confirmation emails and CloudFormation StackSet failures. Check the email inboxes for your Audit account address and confirm any subscription links.

If the setup fails entirely, navigate to the CloudFormation console and check for a failed stack. AWS recommends waiting an hour and trying again. If the issue persists, contact AWS Support.

help me troubleshoot my Control Tower landing zone setup failure

Your landing zone is live. Next up, you'll explore the centralized logging infrastructure that Control Tower just built and verify that logs are flowing correctly across all your accounts.

Configure Centralized Logging

Your landing zone is deployed and your multi-account structure is in place. Now you need to confirm that one of its most critical features is working correctly: centralized logging.

AWS Control Tower automatically routes all audit data to a dedicated Log Archive account, keeping it safe from tampering by individual team members. In this step, you'll verify this logging pipeline is active and review its retention settings.

In this step, get ready to:
  • Verify the organization-level CloudTrail trail in your management account.
  • Explore the Log Archive account's S3 buckets.
  • Review log retention settings in the Control Tower console.
Verify the organization-level CloudTrail trail

Every API call made across your AWS accounts is recorded as a management event. CloudTrail captures these events and delivers them to a centralized S3 bucket in the Log Archive account.

  • In the AWS Management Console, type CloudTrail in the top search bar and select the service.
  • In the left navigation pane, click Trails.
  • Find the trail created by Control Tower. It will have aws-controltower in its name.
  • Click the trail name to open its details page.

On the trail details page, confirm these key settings:

  • Multi-region trail is set to Yes.
  • Organization trail is set to Yes.
  • Management events shows that both Read and Write events are being logged.
  • The S3 bucket destination points to a bucket in the Log Archive account.

What does this trail do?

An organization-level trail automatically logs management events from every account in your AWS Organization. This includes actions like creating EC2 instances, modifying IAM policies, and changing S3 bucket permissions.

Because logs are delivered to a separate Log Archive account, no one in a member account can delete or tamper with the audit trail. This is essential for compliance and incident investigation.

Don't see a trail?

Make sure your landing zone setup completed successfully. Return to the AWS Control Tower console and check the dashboard for any error messages.

Also confirm you are viewing CloudTrail in your home region. The trail is created in the region you selected during Control Tower setup.

Ask for help: Why don't I see a CloudTrail trail after Control Tower setup?

Explore the Log Archive account

Now that you've confirmed the trail is active, verify that log files are actually arriving in the Log Archive account's S3 buckets.

  • Open the IAM Identity Center portal URL (found on the Control Tower dashboard) in a new browser tab.
  • Sign in and select the Log Archive account.
  • Choose the AWSAdministratorAccess permission set to open the console for that account.

Switching accounts via IAM Identity Center

The IAM Identity Center portal acts as your single sign-on hub. From here, you can switch between any account in your Organization without needing separate credentials for each one.

  • In the Log Archive account console, type S3 in the top search bar and select the service.
  • Locate the bucket named aws-controltower-logs- followed by your account ID and region.
  • Click the bucket name to open it.
  • Navigate into the folder structure. You should see subdirectories organized by account ID (one for each account in your Organization).
  • Return to the S3 bucket list and confirm the aws-controltower-s3-access-logs- bucket also exists. This bucket stores access logs for the main log bucket itself.

Why two buckets?

The aws-controltower-logs-* bucket stores your actual CloudTrail logs organized by account ID. The aws-controltower-s3-access-logs-* bucket logs every time someone accesses the main log bucket.

This creates an audit trail of the audit trail. If someone tries to read or delete log files, that access attempt is itself logged in the access logs bucket.

Bucket appears empty?

CloudTrail log files take approximately 5 minutes to appear after API activity occurs. If your landing zone just finished deploying, wait a few minutes and refresh the S3 bucket view.

Also confirm you are signed into the Log Archive account (not the management account) by checking the account name in the top-right corner of the console.

Ask for help: Why is my aws-controltower-logs bucket empty?

Review log retention settings

Log retention determines how long your audit data is preserved before automatic deletion. You need to confirm the defaults match your team's compliance requirements.

  • Switch back to your management account. You can use the IAM Identity Center portal or close the Log Archive tab and return to your original console session.
  • Navigate to the AWS Control Tower console.
  • In the left navigation pane, click Landing zone settings.
  • Review the log retention configuration displayed on this page.

Confirm the following default retention periods:

  • Standard account logging: 1 year.
  • Access logging: 10 years.

What do these retention periods mean?

Standard account logging (1 year) covers the CloudTrail log files delivered to the aws-controltower-logs-* bucket. After one year, these files are automatically deleted.

Access logging (10 years) covers the aws-controltower-s3-access-logs-* bucket. This longer retention ensures you can investigate access patterns even years after the fact. You can adjust both values up to 15 years when updating your landing zone.

Adjusting retention for your team

If your team needs to meet specific compliance requirements (such as retaining logs for 7 years), you can change these values by updating your landing zone. Navigate to Landing zone settings and choose Update to modify the retention periods in increments of days or years, up to 15 years.

Your centralized logging is confirmed and active. Every API call across your entire Organization is being captured, stored securely in a dedicated account, and retained according to your configured policy. Next up, you'll set up billing controls to keep costs visible and under control.

Configure Billing and Budgets

Your centralized logging is verified and working. Every management event across your organization flows into the Log Archive account automatically.

With visibility into security events sorted, the next priority is visibility into costs. A multi-account environment can accumulate charges across accounts without anyone noticing until the monthly bill arrives. In this step, you will set up consolidated billing verification, create a cost budget with email alerts, and activate Cost Explorer for cross-account cost analysis.

In this step, get ready to:
  • Verify consolidated billing is active across all accounts.
  • Create a monthly cost budget with alerts at 80% and 100%.
  • Enable Cost Explorer and filter costs by linked account.
Review consolidated billing

When Control Tower created your AWS Organization, it automatically enabled consolidated billing. This means your management account receives a single bill covering all member accounts. Let's confirm that every account shows up under one bill.

  • In the AWS Management Console, search for Billing and Cost Management and open it.
  • In the left navigation pane, choose Bills.
  • Review the bill summary. You should see charges listed for your management account, Log Archive account, and Audit account under a single consolidated view.

What is consolidated billing?

Consolidated billing is a feature of AWS Organizations that combines charges from all member accounts into one bill paid by the management account. It also pools usage across accounts to unlock volume pricing discounts.

Your management account is now the payer account for the entire organization. Member accounts receive informational bills only.

  • To see all accounts listed together, open the AWS Organizations console (search for it in the top search bar).
  • In the left navigation pane, choose AWS accounts.
  • Confirm that your management account, Log Archive account, and Audit account all appear in the list with an Active status.

Don't see all three accounts?

If an account shows a status other than Active, the account creation may still be in progress. Wait a few minutes and refresh the page. Control Tower account provisioning can occasionally take longer than expected.

help me troubleshoot why my Control Tower accounts aren't showing as Active in AWS Organizations

Create a cost budget

Now that you've confirmed billing is consolidated, the next step is setting a spending threshold. AWS Budgets lets you define a monthly cost ceiling and receive email alerts when your actual spend approaches or exceeds it.

  • In the AWS Management Console, search for Billing and Cost Management and open it.
  • In the left navigation pane, choose Budgets.
  • At the top of the page, choose Create budget.
  • Under Budget setup, choose Use a template (simplified).
  • Under Templates, choose Monthly cost budget.

Why a template instead of a custom budget?

The simplified template creates a monthly recurring cost budget with sensible defaults in a single-page workflow. The advanced (custom) path requires 5 steps and more decisions. For a practice environment, the template approach gets you to a working budget faster.

  • For Budget name, enter Landing-Zone-Monthly-Budget.
  • For Budgeted amount, enter 10 (this sets a $10/month threshold).
  • For Email recipients, enter the email address where you want to receive budget alerts.

The template automatically creates alerts at 85% and 100% of your budgeted amount. You will customize these thresholds to 80% and 100% in a moment.

  • Under Template settings, choose Custom to switch into the advanced workflow so you can adjust the alert thresholds.
  • Navigate to the alerts step. Under Set alert threshold, set the first alert to 80 with % of budgeted amount selected, and set the trigger to Actual.
  • Choose Add an alert threshold to add a second alert.
  • Set the second threshold to 100 with % of budgeted amount selected, and set the trigger to Actual.
  • Confirm your email address appears in the notification recipients for both alerts.
  • Choose Next through any remaining steps until you reach the review page.
  • Review your budget settings, then choose Create budget.

You should see your new budget listed on the Budgets page with a status of Normal (green). This means your actual spend is below the threshold.

What does this budget do?

Your budget monitors the total spend across all accounts in the organization. When actual costs reach 80% of $10 (i.e., $8), you receive a warning email. At 100% ($10), you receive a second alert.

Budgets do not stop spending automatically. They are an awareness tool. If you want automated enforcement, you can add budget actions later to restrict provisioning when thresholds are hit.

Don't see the budget after creating it?

Make sure you chose Create budget on the final review page. If the page shows validation errors (highlighted in red), check that your email address format is correct and that the budgeted amount is a number.

help me troubleshoot why my AWS Budget isn't appearing after creation

Enable Cost Explorer

Budgets tell you when spending crosses a line. Cost Explorer tells you where the money is going. It provides graphs and filters so you can see which account, service, or region is driving costs.

  • Return to the Billing and Cost Management console.
  • In the left navigation pane, choose Cost Explorer.
  • If this is your first time opening Cost Explorer, you will see a Welcome to Cost Explorer page. Choose Launch Cost Explorer.

What happens when you launch Cost Explorer?

AWS begins preparing cost data for the current month and the previous 13 months. The current month's data appears within about 24 hours. Cost Explorer also automatically enables Cost Anomaly Detection, which alerts you to unexpected spending spikes.

Enabling Cost Explorer at the management account level enables it for all member accounts in your organization by default.

  • Once Cost Explorer loads, look for the filter options on the right side of the chart.
  • Find the Linked Account filter (sometimes labeled as Account).
  • Select one of your member accounts (Log Archive or Audit) to filter the view to that account's charges only.
  • Verify that costs appear for the selected account. The values will be small or zero since the accounts were just created.

Cost data takes time to appear

If Cost Explorer shows no data yet, that is expected. AWS needs up to 24 hours to populate the graphs after first enabling. Check back later in the day and you should see cost data begin to appear.

Can't access Cost Explorer?

If you see a permissions error, make sure you are signed in to the management account (not a member account). Cost Explorer must be enabled from the management account first. If you are using an IAM user rather than the root account, ensure the Activate IAM Access setting is enabled under Account settings.

help me troubleshoot why I can't access AWS Cost Explorer in my management account

Your billing controls are now in place. You have a consolidated view of all account charges, a budget that alerts you before costs get out of hand, and Cost Explorer ready to break down spending by account and service. Next up, you will set up team access through IAM Identity Center.

Configure IAM Identity Center for Your Team

Your billing controls are in place. Now it's time to give your team secure access to this multi-account environment.

Instead of creating individual IAM users in each account, you'll use IAM Identity Center to manage your team from one place. Control Tower already set up Identity Center with preconfigured groups and permission sets. You just need to create your users and slot them into the right groups based on their roles.

In this step, get ready to:
  • Create 4 team members in IAM Identity Center.
  • Assign each user to a role-based group with appropriate permissions.
  • Enforce MFA for all users signing in.
Create your team users

Each person on your team needs their own identity in IAM Identity Center. You'll create 4 users, each with a unique email address, first name, and last name.

  • In the AWS Management Console, type IAM Identity Center in the top search bar and select the service.
  • In the left navigation pane, click Users.
  • Click Add user.
  • Fill in the required fields for your first user (this will be your admin user):
  • Click Next.
  • On the group assignment page, skip group selection for now (you'll assign groups in the next substep). Click Next.
  • Review the details and click Add user.
  • Repeat this process 3 more times to create your remaining team members (2 developers and 1 read-only member). Each user must have a unique email address.

Use Gmail aliases for practice

If you don't have 4 separate email addresses, Gmail aliases work well. Use patterns like yourname+admin@gmail.com, yourname+dev1@gmail.com, yourname+dev2@gmail.com, and yourname+readonly@gmail.com. All emails will arrive in your single inbox.

After creating all 4 users, you should see them listed on the Users page with their email addresses and a status of Enabled.

Don't see all 4 users?

Make sure you completed the final Add user button on each user's review page. If a user shows a different status, click on their name to check their details.

Also confirm you're in the correct region. IAM Identity Center was set up in your home region by Control Tower.

Help me troubleshoot my IAM Identity Center user creation in AWS Control Tower.

Assign users to groups

Control Tower created several preconfigured groups with specific permission sets. You'll assign each user to the group that matches their role on the team.

What are these groups?

Each group maps to a permission set that controls what the user can do across your accounts:

  • AWSControlTowerAdmins grants AWSAdministratorAccess to the management, Log Archive, and Audit accounts. This is for you as the team admin.
  • AWSSecurityAuditPowerUsers grants AWSPowerUserAccess to all accounts. This is for developers who need to build and deploy resources.
  • AWSSecurityAuditors grants AWSReadOnlyAccess to all accounts. This is for team members who need to view but not modify resources.
  • In the left navigation pane, click Groups.
  • Click on the AWSControlTowerAdmins group.
  • Click Add users.
  • Select your admin user from the list and click Add users.
  • Return to the Groups page.
  • Click on the AWSSecurityAuditPowerUsers group.
  • Click Add users.
  • Select your 2 developer users and click Add users.
  • Return to the Groups page.
  • Click on the AWSSecurityAuditors group.
  • Click Add users.
  • Select your read-only team member and click Add users.

After completing all assignments, click into each group to verify the correct users appear. Your admin user should be in AWSControlTowerAdmins, your 2 developers in AWSSecurityAuditPowerUsers, and your read-only member in AWSSecurityAuditors.

Configure MFA enforcement

Multi-factor authentication adds a critical security layer. AWS best practice requires MFA for all users in your landing zone. You'll enforce it on every sign-in so that even if a password is compromised, the account stays protected.

  • In the IAM Identity Center left navigation, click Settings.
  • Select the Authentication tab.
  • In the Multi-factor authentication section, click Configure.
  • Under Prompt users for MFA, select Every time they sign in.
  • Under Users can authenticate with these MFA types, ensure authenticator apps and security keys are enabled.
  • Click Save changes.

You should see the MFA configuration updated on the Authentication tab showing that MFA is required every time users sign in.

Why require MFA on every sign-in?

AWS prescriptive guidance for Control Tower landing zones states that you must require multi-factor authentication for all root, IAM, and IAM Identity Center users. Enforcing it on every sign-in (rather than only once per device) gives you the strongest protection against credential theft.

Don't see the MFA configuration option?

Make sure you're on the Settings page (not the dashboard) and have selected the Authentication tab. The MFA section should appear under the authentication settings.

Help me find the MFA settings in IAM Identity Center for my Control Tower landing zone.

Your team now has secure, role-based access to your multi-account environment. Next up, you'll put this to the test by provisioning a brand new governed account through Account Factory.

Provision a Team Member Account

Your team members are set up with secure, role-based access through IAM Identity Center. Now it's time to give them an actual AWS account to work in.

Account Factory is Control Tower's built-in tool for provisioning new AWS accounts that are automatically enrolled in your landing zone's governance. In this step, you'll create a dedicated sandbox account for your development team.

In this step, get ready to:
  • Open Account Factory and start creating a new account.
  • Configure account details and assign an owner.
  • Verify the account is enrolled and governed by your Sandbox OU.
Open Account Factory

Every new account provisioned through Account Factory automatically inherits the controls and guardrails of whichever OU you place it in. This means your team gets a governed workspace without any manual security configuration.

  • In the AWS Control Tower console, choose Organizations from the left navigation to view the Organization page.
  • From the upper right, choose Create resources.
  • In the dropdown menu, choose Create account.

What is Account Factory?

Account Factory is the mechanism inside Control Tower that lets you spin up new AWS accounts pre-configured with your landing zone's baseline. Each account it creates is automatically enrolled and governed by the OU's controls, centralized logging, and billing.

IAM Identity Center users that provision accounts must be in the AWSAccountFactory group or the management group. Since you're working from the management account as an administrator, you already have the required permissions.

Configure the new account

You'll need a unique email address for this account. Like before, a Gmail alias works (e.g. yourname+sandbox@gmail.com).

  • In the Account email field, enter a unique email address that is not already associated with any AWS account.
  • In the Display name field, enter Team-Sandbox-Dev.
  • Under Access configuration, enter the IAM Identity Center email address and user name of the team member you want to assign as the account owner.
  • Select your Sandbox OU from the registered OU dropdown list.
  • Skip the Account factory customization section. You can add blueprints later.
  • Review your selections, then choose Create account in the lower right.

Why assign an IAM Identity Center user as owner?

The user you assign here gets administrative access to the new account through IAM Identity Center. They can sign in to the account through the SSO portal without needing separate credentials for each account.

Choose one of the developers you created in the previous step. They'll be able to access this sandbox account immediately after provisioning completes.

Verify provisioning

Account provisioning takes approximately 5 minutes. Control Tower is creating the account, applying baseline guardrails, enrolling it in your Organization, and configuring access through IAM Identity Center.

  • Refresh the Organization page periodically to update the displayed status information.
  • Wait until Team-Sandbox-Dev appears in the account list with a status of Enrolled.
  • Confirm the account is listed under the Sandbox OU in the organizational tree.

Account stuck in provisioning?

If the account stays in a provisioning state for more than 15 minutes, refresh the page and check the status details. Common causes include:

  • The email address is already associated with another AWS account. Try a different unique address.
  • Another Control Tower configuration change is in progress. Wait for it to complete and try again.
  • You've hit the concurrent operations limit. AWS Control Tower allows up to 5 account operations at a time.

Get help troubleshooting: Why is my Account Factory provisioning failing?

What happened behind the scenes?

When Account Factory provisions a new account, Control Tower automatically creates the account within your AWS Organization, applies your OU's baseline guardrails, and sets up the AWSControlTowerExecution role for ongoing governance. It also configures IAM Identity Center access for the assigned user.

The new account also starts reporting configuration changes to AWS Config and sending management events to your organization-level CloudTrail trail in the Log Archive account.

Your team now has a dedicated, governed AWS account to build in. Next up, you'll enable guardrails and verify that your team members can only access what their roles allow.

Enable Guardrails and Verify Governance

Your landing zone is deployed, your team has accounts and access, and your billing is under control. The final piece is governance.

In this step, you will enable security controls (formerly called guardrails) that automatically detect misconfigurations across your accounts. Then you will verify that your team members can sign in through the SSO portal and see only the resources they should.

In this step, get ready to:
  • Review the mandatory preventive controls already enforcing governance.
  • Enable additional detective controls on your Sandbox OU.
  • Verify team member access through the IAM Identity Center portal.
Review default controls

AWS Control Tower automatically applies mandatory preventive controls to protect the foundational resources in your landing zone. These controls are implemented as Service Control Policies (SCPs) that block dangerous actions like deleting your CloudTrail trail or modifying the Log Archive account.

  • Return to the AWS Control Tower console.
  • In the left navigation pane, select Controls.
  • Review the list of controls. You will see mandatory preventive controls already applied, such as controls that disallow changes to the log archive and disallow deletion of CloudTrail.

What are controls in AWS Control Tower?

Controls are high-level governance rules that apply to an entire organizational unit (OU) and all accounts within it. AWS previously called these "guardrails" but is transitioning to the term "controls."

There are three types of controls. Preventive controls block prohibited actions using SCPs. Detective controls detect misconfigurations using AWS Config rules. Proactive controls check resources before they are provisioned using CloudFormation hooks.

  • Click the name of any mandatory preventive control (for example, one that disallows changes to the log archive).
  • On the control details page, review the OUs enabled tab to confirm which OUs it applies to.
  • Verify that the Security OU shows the control status as Enabled.

Why are mandatory controls important?

Mandatory controls prevent accidental or malicious changes to the foundational resources that make your landing zone work. Without them, a team member could accidentally delete your centralized logging trail or modify the Log Archive account permissions.

Enable additional detective controls on your Sandbox OU

Strongly recommended detective controls are not enabled by default. These controls use AWS Config rules to monitor your accounts for common security misconfigurations and report violations on the dashboard.

  • In the left navigation pane of the AWS Control Tower console, select Controls.
  • Search for the control named Detect whether MFA is enabled for the root user.
  • Click the control name to open its details page.
  • On the control details page, select the OUs enabled tab.
  • Choose Enable control on OU.
  • Select your Sandbox OU from the list.
  • Choose Enable control.

Wait for the control status to show as Enabled. This typically takes less than a minute.

  • Navigate back to Controls in the left navigation pane.
  • Search for the control named Detect whether public read access to S3 buckets is allowed.
  • Click the control name to open its details page.
  • Select the OUs enabled tab.
  • Choose Enable control on OU.
  • Select your Sandbox OU and choose Enable control.

Wait for the control status to show as Enabled.

What do these detective controls do?

The root user MFA control checks whether each account in the Sandbox OU has MFA enabled for its root user. The S3 public read control checks whether any S3 bucket in those accounts allows public read access over the internet.

If either condition is violated, the control shows a status of "in violation" on the Control Tower dashboard. This gives you visibility into security issues without blocking any actions.

Control not enabling?

Make sure your Sandbox OU is registered with AWS Control Tower and that the Team-Sandbox-Dev account shows as "Enrolled" in the OU. Detective controls only apply to enrolled accounts within a registered OU.

help me troubleshoot why my detective control won't enable on my Sandbox OU

Verify team access through the IAM Identity Center portal

The final check is confirming that your team members can sign in and see only the accounts and permissions assigned to their group. The IAM Identity Center portal (called the AWS access portal) is where your team signs in to access their assigned AWS accounts.

  • Open the IAM Identity Center console at https://console.aws.amazon.com/singlesignon/.
  • In the left navigation pane, select Dashboard.
  • Locate the Settings summary section.
  • Find the AWS access portal URL and copy it. The URL follows the format d-xxxxxxxxxx.awsapps.com/start.

Bookmark this URL

This is the URL you will share with your team members so they can sign in to access their assigned AWS accounts. Save it somewhere you can easily find it later.

  • Open a new browser window (or use an incognito/private window so your admin session is not affected).
  • Paste the AWS access portal URL you just copied and press Enter.
  • Sign in using the credentials of one of your team members (the username and temporary password they received via email when you created their account).
  • Complete MFA setup if prompted.
  • After signing in, select the Accounts tab in the portal.
  • Confirm that the team member can see only the accounts and permission sets assigned to their group.

What should each group see?

Users in the AWSControlTowerAdmins group see the management, Log Archive, and Audit accounts with AWSAdministratorAccess. Member accounts show AWSOrganizationsFullAccess.

Users in the AWSSecurityAuditPowerUsers group see all accounts with AWSPowerUserAccess. Users in the AWSSecurityAuditors group see all accounts with AWSReadOnlyAccess.

Team member can't sign in?

Make sure the team member activated their account using the email invitation that was sent when you created their user. Check their email (including spam folders) for the activation link from AWS.

If the team member sees no accounts after signing in, confirm that their user is added to a group with account assignments in IAM Identity Center.

help me troubleshoot why my team member cannot sign in or see accounts in the IAM Identity Center portal

Your landing zone is now fully governed. You have mandatory controls protecting your foundational resources, detective controls monitoring your team's accounts for misconfigurations, and verified single sign-on access for your team. Next up, take on the Secret Mission to lock workloads to a single region with a custom SCP.

Secret mission

Create a Region-Restriction SCP

Ready for a real-world governance challenge? Enterprise cloud teams often restrict workloads to a single approved region to meet compliance and data residency requirements. In this secret mission, you'll create a custom Service Control Policy that locks your Sandbox OU to your home region only.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project uses AWS services that incur small usage-based charges (AWS Config, CloudTrail, S3 log storage), typically $0.05 to $0.50 per month for a small team with light usage.

Cost warning

AWS Control Tower itself has no additional charge, but the underlying services (AWS Config, CloudTrail, S3 log storage) will continue to generate small charges as long as enrolled accounts are active. If you do not plan to use this landing zone, choose the Delete tab below to avoid ongoing costs.

Resources you used:

  • AWS Control Tower landing zone (deployed in your home region).
  • AWS Organization with Security OU and Sandbox OU.
  • Log Archive account and Audit account (in the Security OU).
  • Team-Sandbox-Dev account (in the Sandbox OU).
  • IAM Identity Center directory with 4 users and role-based groups.
  • Organization-level CloudTrail trail.
  • S3 log buckets (aws-controltower-logs-* and aws-controltower-s3-access-logs-*).
  • AWS Config (active across all enrolled accounts).
  • AWS Budget ($10/month threshold with alerts at 80% and 100%).
  • Region-restriction SCP attached to the Sandbox OU.
  • AWS Cost Explorer (activated in management account).

Keep everything running

No action needed. Choose this if you plan to continue using your landing zone for team workloads or future projects.

  • Your costs will remain minimal (approximately $0.05 to $0.50 per month) for a small team with light usage.
  • AWS Config records configuration changes. CloudTrail logs management events. S3 stores the log files. These are the primary cost drivers.
  • Your AWS Budget alerts will notify you if costs approach your $10/month threshold.
  • Cost Explorer remains activated in your management account for ongoing visibility.

Pause - I'll come back to this later

You cannot pause AWS Control Tower directly. However, costs are usage-based, so inactive accounts with no workloads incur very little.

  • Avoid launching any resources in your member accounts. With no active workloads, AWS Config records will be minimal and CloudTrail charges will stay within the free tier (100,000 management events per month).
  • Your IAM Identity Center users and groups remain configured for when you return.
  • The region-restriction SCP and all guardrails remain in effect, keeping your environment governed.
  • Monitor costs through your budget alerts. If charges are higher than expected, investigate in Cost Explorer.

Delete - I don't want to use this again

Remove all project resources completely. This process is difficult to undo. Only choose this if you are certain you no longer need the landing zone.

This process cannot be undone

Decommissioning your landing zone is irreversible. It removes governance from all accounts but does not delete the accounts themselves. You must close individual accounts separately after decommissioning.

  • Delete your custom region-restriction SCP. In the AWS Organizations console, navigate to **Policies**, then **Service control policies**. Select your region-restriction policy and delete it.
  • Delete your AWS Budget. In the AWS Budgets console, select your $10/month budget, choose **Actions**, then **Delete**.
  • Delete IAM Identity Center users. In the IAM Identity Center console, navigate to **Users**, select each of your 4 users, and delete them.
  • Unenroll member accounts. AWS recommends unenrolling accounts before decommissioning. In the AWS Control Tower console, choose **Organization** in the left navigation. Expand the OU containing the account, select the account, and choose **Unmanage**.
  • Decommission your landing zone. In the AWS Control Tower console, navigate to the **Landing Zone Settings** page. In the **Decommission your landing zone** section, choose **Decommission your landing zone**. Select every confirmation box and type the confirmation as requested. This process takes up to two hours.
  • Close member accounts. After decommissioning completes, navigate to the AWS Organizations console. On the **AWS accounts** page, choose the name of each member account (Log Archive, Audit, Team-Sandbox-Dev). Choose **Close** next to the account name, read the closure guidance, enter the member account ID, and choose **Close account**. Repeat for each account.
  • Clean up remaining resources. After decommissioning, some resources remain (S3 buckets, CloudWatch Logs log groups, IAM roles). Delete the IAM roles named AWSControlTowerAdmin, AWSControlTowerCloudTrailRole, and AWSControlTowerStackSetRole from the IAM console. Delete corresponding policies named AWSControlTowerAdminPolicy, AWSControlTowerCloudTrailRolePolicy, and AWSControlTowerStackSetRolePolicy.

Nice Work!

Nice Work!

You've just built a secure, enterprise-grade AWS foundation from scratch. This is the same multi-account architecture that platform engineering teams deploy before any workload touches the cloud.

Here's what you accomplished:

  • Deployed AWS Control Tower and created a governed multi-account structure with a Security OU (Log Archive + Audit) and a Sandbox OU for team workloads.
  • Configured IAM Identity Center with 4 team members in role-based groups, MFA enforcement, and provisioned a governed member account through Account Factory.
  • Set up centralized logging with an organization-level CloudTrail trail, configured AWS Budgets with cost alerts, and enabled preventive and detective guardrails enforcing security best practices.
  • Secret Mission: Created a custom region-restriction SCP to lock workloads to your home region.

Ready to quiz yourself?