How to Separate Production from Your AWS Management Account - A Multi-Account Best Practices Guide

By Vinuthna Korinni, Joe DePaola, and Xuejun Li

The problem

If you're running production workloads in your management account, you're not alone - but it's an anti-pattern that AWS recommends against. Here's why:

• Service Control Policies (SCPs) don't apply to the management account - your production workloads have no SCP guardrails

• Blast-radius risk - a compromise of the management account exposes organizational controls for all member accounts

• Control Tower can't be properly deployed when the management account hosts production workloads

• Organization-level Savings Plans and other billing features may be complicated by mixed-use accounts

As your environment grows - especially after acquisitions or mergers - this structure becomes increasingly unsustainable. This guide walks through a repeatable pattern for separating production from management by creating a new, dedicated management account.

Note: This guide uses AWS Control Tower for centralized governance. If your organization doesn't use Control Tower, Steps 5 and 6 can be replaced with manual SCP configuration and CloudTrail/Config setup. The core separation pattern (Steps 1-4, 7-8) works independently of Control Tower.

Prerequisites

Before starting, ensure you have:

• AWS Organizations admin access on the current management/payer account

• Ability to create a new AWS account (for the new management account)

• Inventory of all linked accounts and their dependencies (delegated admins, Identity Center, CloudTrail trails)

• A backup of your existing Cost and Usage Report (CUR) data in S3

• Planned maintenance window communicated to stakeholders

Step 1: Create the new AWS Organization

Create a new standalone AWS account that will become your dedicated management account. This account should contain no workloads - only organizational management functions.

Key considerations:

• Use a dedicated root email (e.g., aws-management@yourdomain.com)

• Enable MFA on the root user immediately

• This account will only handle: Organizations management, SCPs, Control Tower, billing

Important: The new organization must be at least 7 days old before you can migrate accounts into it. Plan for this waiting period.

Step 2: Assess dependencies in the current organization

Before migrating, inventory everything tied to your current management account:

• Delegated administrators - which services have delegated admin configured? (Security Hub, GuardDuty, Config, etc.)

• Identity Center - how many users, groups, and permission sets? Which accounts have assignments?

• CloudTrail - organization trail configuration and log delivery

• Control Tower - existing landing zone stacks, enrolled accounts, guardrails

• Billing - CUR delivery, Savings Plans, Reserved Instances, consolidated billing

Run the AWS account assessment tool to identify blockers.

Step 3: Back up cost data before migration

This is critical. Once the old payer account is decommissioned, standard CUR backfill is not available. Back up your CUR data from S3 before making any changes.

• Copy existing CUR files to a separate S3 bucket you control

• Note the CUR report name, format (CSV/Parquet), and path structure

• If you use Cloud Intelligence Dashboards (CUDOS/CID), note your current table schema

You'll need this backup if you need to restore historical cost visibility after migration.

Step 4: Phase the migration - dev/test first

Do not migrate everything at once. Use a phased approach:

Phase 1: Non-production accounts

• Migrate development, staging, and test accounts first

• Validate: Identity Center access works, workloads unaffected, billing appears in new org

• Monitor for 2-3 days

Phase 2: Production accounts

• Migrate production accounts only after Phase 1 is validated

• Schedule during a low-traffic window

• Have a rollback plan (accounts can be moved back within the migration window)

For each account migration, follow the AWS documentation on moving accounts between organizations.

Step 5: Clean up legacy Control Tower stacks

If your original organization had Control Tower enabled, the production account likely has residual CT stacks:

• IAM roles created by Control Tower (prefixed AWSControlTower)

• AWS Config recorders and delivery channels

• Service Catalog provisioned products

• CloudFormation StackSets resources

These must be cleaned up before enrolling the account in Control Tower in the new organization. Otherwise, enrollment will fail or produce conflicts.

Steps:

1. Identify legacy CT resources: IAM roles, Config recorders, delivery channels

2. Delete or rename conflicting resources

3. Verify no Service Catalog products reference the old management account

4. Then enroll in Control Tower in the new org

Step 6: Deploy Control Tower in the new organization

With the new management account aged 7+ days and accounts migrated:

1. Set up your landing zone in the new management account

2. Configure organizational units (Security, Sandbox, Workloads, etc.)

3. Enroll migrated accounts - dev/test first, then production

4. Apply SCPs and guardrails

Follow the AWS Control Tower getting started guide.

Step 7: Reconfigure Identity Center

Your users need access to accounts in the new organization:

• Deploy Identity Center in the new management account

• Reconnect your identity source (e.g., Microsoft Entra ID via SAML 2.0 + SCIM)

• Recreate or migrate permission sets

• Reassign users/groups to accounts

For large environments (100+ users, 25+ permission sets), plan this carefully - test with a small group first.

Step 8: Validate and decommission

Final validation checklist:

• All accounts visible in new organization

• SCPs applying correctly (test with a deny rule)

• Control Tower guardrails active

• Identity Center - all users can access all assigned accounts

• Billing - consolidated billing working, Savings Plans active

• CUR - new data flowing on the new payer

• CloudTrail - organization trail delivering to centralized bucket

• No workloads in the new management account

Once validated, the old management account becomes a regular linked account (production) with no special organizational privileges.

Common gotchas

Issue	Solution
7-day org age requirement	You cannot move accounts into an org younger than 7 days. Plan for the wait.
Delegated admin dependencies	Some services (Security Hub, GuardDuty) need delegated admin re-registered in the new org before migrated accounts can use them.
Savings Plans portability	Compute Savings Plans apply at the organization level. Verify they follow your accounts to the new org.
Identity Center session disruption	Users will need to re-authenticate after Identity Center is reconfigured. Communicate the timeline.
Legacy CT stacks blocking enrollment	Clean up before enrolling — don't try to force-enroll over existing CT resources.
Order of operations	Migrate accounts → clean up legacy stacks → deploy CT → enroll accounts. Skipping steps causes failures.

Summary

Separating production from your management account is a one-time effort that permanently improves your security posture, enables proper governance, and positions your organization for scale. The key principles:

1. Back up cost data first - you can't get it back after decommissioning the old payer

2. Phase the migration - dev/test first, production after validation

3. Clean up before enrolling - legacy stacks must go before new Control Tower can work

4. Plan for Identity Center - your users need access on day one

5. Don't rush - the 7-day requirement is there for a reason; use the time to prepare

References

• Best practices for the management account

• Migrating accounts between organizations

• Getting started with AWS Control Tower

• AWS Identity Center

• Cloud Intelligence Dashboards deployment

• Pinterest's AWS Organization Transformation Journey