Keystone

How to Move from a Single AWS Account to AWS Organizations Without Breaking Billing

You started with one AWS account. Then you ran “everything” out of it for two or three years. Now you’ve hit the wall — IAM is a mess, blast radius is terrifying, and you can’t tell dev costs from prod costs.

It’s time to move to AWS Organizations.

The good news: AWS makes the creation of an Organization almost trivial. The bad news: the migration of existing workloads, billing arrangements, Savings Plans, and Reserved Instances into the new structure is where teams get hurt. This post is a step-by-step playbook for doing it without surprises on the bill.

The end state you’re aiming for

Before any clicks happen, decide what “done” looks like. A reasonable starting structure for most teams:

Root (Management Account)
├── Security OU
│   ├── log-archive
│   └── audit
├── Workloads OU
│   ├── prod-production
│   ├── prod-staging
│   └── prod-shared-services
├── Sandbox OU
│   └── sandbox-<engineer-name>
└── Suspended OU

The Management Account does nothing except billing, identity, and organization-level controls. No workloads should run in it. This is the single most important rule of the migration.

Step 1: Decide the role of your current account

Your existing account contains all your production workloads. You have two options:

Option A: Convert it into the Management Account (don’t)

Tempting, because it requires no workload migration. Don’t do it. Mixing workloads with the management account permanently couples your blast radius and your billing concerns, and you can never split them later without significant pain.

Option B: Keep the existing account as a member, and create a fresh Management Account

This is the right answer in almost every case. You create a brand-new, empty AWS account to act as the Management Account, then invite your existing account into the new Organization as a member.

The rest of this post assumes Option B.

Step 2: Create the new Management Account

  1. Sign up for a brand-new AWS account using a billing email you control (a distribution list, not a personal address).
  2. Enable MFA on the root user immediately. Then put the root credentials in a password manager and never log in as root again except for the small handful of tasks that require it.
  3. Set up AWS IAM Identity Center (SSO) in this account.
  4. Do not deploy any workloads in this account. Ever.

Step 3: Create the Organization and invite the existing account

From the new Management Account:

# Create the organization with all features enabled
aws organizations create-organization --feature-set ALL

# Invite the existing account to join
aws organizations invite-account-to-organization \
  --target Id=123456789012,Type=ACCOUNT \
  --notes "Joining the new org as a member account"

From the existing account, accept the invitation:

aws organizations accept-handshake --handshake-id <handshake-id>

Once an account joins an Organization, its billing is immediately consolidated with the Management Account. There is no “trial period”. Plan the timing accordingly.

Step 4: What happens to your billing on day one

This is the part that scares people. Here’s what actually happens at the moment the existing account joins:

  • Existing payment method on the member account becomes inactive. All charges now bill to the Management Account’s payment method. Update the card in the Management Account before the invite is accepted.
  • The member account’s billing console becomes read-only for invoices. Past invoices remain accessible. Future invoices are unified.
  • Reserved Instances and Savings Plans transfer with the account. They continue to apply to the same workloads. Critically, they also become shareable across the entire Organization by default, which is good — but you should review whether that’s what you want.
  • Cost Explorer history is preserved. It does not reset.

The bill arrives at the Management Account from the next billing cycle. The existing account’s last standalone bill is settled normally.

Step 5: Disable RI/SP sharing if you want isolated cost reporting

By default, the Management Account receives the discount benefit from RIs and Savings Plans across all member accounts. This makes cost allocation harder, because savings appear in the management account rather than against the workload that earned them.

Most organisations turn this off:

  1. Billing console → Preferences → Reserved Instance and Savings Plans discount sharing.
  2. Untick the accounts you want excluded from automatic sharing.
  3. AWS will then attribute RI/SP discounts back to the account that consumed the eligible usage.

Step 6: Move workloads gradually

You do not need to move workloads. The existing account is now a valid member of the Organization, and you can carry on running production in it. Over time, you can create new member accounts (per environment, per team, per workload) and migrate selectively.

A reasonable migration order:

  1. First: stand up new dev/sandbox accounts for engineers. Easy wins, low risk.
  2. Second: move staging environments to a dedicated staging account.
  3. Third: split shared services (DNS, observability, CI) into a shared-services account.
  4. Last: split production. Use Route 53 weighted records, RDS read replicas, and S3 replication to migrate workloads without downtime.

Most teams take 6-12 months from “single account” to “fully multi-account production”. That’s fine. The Organization gives you the option to split; you can take your time exercising it.

Step 7: Add the guardrails that justified the migration

Once the Organization is in place, turn on the controls you’ve been wanting:

# Enable Service Control Policies
aws organizations enable-policy-type \
  --root-id r-abcd \
  --policy-type SERVICE_CONTROL_POLICY

# Enable Tag Policies
aws organizations enable-policy-type \
  --root-id r-abcd \
  --policy-type TAG_POLICY

# Enable AWS Config aggregation across the Organization
aws configservice put-configuration-aggregator \
  --configuration-aggregator-name org-aggregator \
  --organization-aggregation-source AllAwsRegions=true,RoleArn=arn:aws:iam::<mgmt-acct>:role/...

Common starter SCPs:

  • Deny use of root credentials in member accounts
  • Deny the creation of resources outside approved regions
  • Deny disabling CloudTrail
  • Deny the deletion of organization-managed Config rules

Common pitfalls (and how to avoid them)

PitfallAvoidance
Putting workloads in the Management AccountTreat the Management Account as off-limits to anything but billing & IAM
Forgetting to update the payment method before invitationAdd the card to the new Management Account first
Surprise loss of “support tier” on the management accountBuy Enterprise Support on the management account; it applies to all members
Pre-existing CloudTrail charges duplicatingReplace per-account trails with a single Organization Trail
Engineers losing console accessMigrate to IAM Identity Center before deprecating local IAM users

How long does it take?

A clean migration of a single-account environment into a new Organization, with the existing account as a member, typically takes 2-3 hours of focused work plus a few hours of validation. Splitting workloads across additional accounts is a longer, gradual project — typically 3-9 months for a mid-sized environment.

The Organization itself is essentially free. The clarity it gives you is not.

If you’d like a second pair of eyes on the migration plan, or want help splitting your existing account safely, get in touch. We can walk you through the steps for your specific environment before you click anything you can’t undo.