How to Add or Remove an AWS Organizations Account (Do This First)

You've opened the AWS Organizations console to change your account membership: create a new account, absorb one that already exists, or take one out entirely. An account you create gets an admin role automatically. An account you invite doesn't. Get that distinction wrong during an acquisition and you'll spend an afternoon figuring out why you can't get into an account you just added.

Below: all three actions end to end, exactly what changes when an existing account joins, and the removal prerequisites that catch teams who assume every account is ready to leave on request.

Which of these do you actually need?

Name the actual job before opening any console screen. There are three ways an account's membership can change, plus one job people confuse with all three:

• Create a brand-new AWS account inside your organization.
• Invite an AWS account that already exists (an acquired subsidiary, a team that started on its own, a duplicate you want consolidated).
• Remove an account from your organization.
• Add a user (not something AWS Organizations does).

AWS Organizations manages accounts, not people. There's no CreateUser or InviteUser API. If you actually want to give a person access to accounts your org already has, that's IAM Identity Center's job, assigning users and groups to accounts through permission sets, the model AWS recommends over hand-rolled per-account IAM users at scale.

One terminology note: an account is a single AWS environment with its own resources and billing; an organization is the collection of accounts under one management account; an organizational unit (OU) is a folder used to group accounts for policy purposes. If any of that is new, start with the AWS Organizations implementation guide and come back. Deciding which OU a new account belongs in is a structural question covered in the multi-account strategy guide.

Creating a brand-new member account

Creating an account is the simplest of the three actions, and the one where AWS does the most automatically. Call it from the management account only: console (AWS accounts → Add an AWS account → Create an AWS account) or aws organizations create-account.

Four parameters matter: Email (root sign-in identity, can't already belong to another AWS account), AccountName (a friendly label), RoleName (optional, defaults to OrganizationAccountAccessRole), and IamUserAccessToBilling (defaults to ALLOW; set DENY to restrict billing visibility to root only).

CreateAccount is asynchronous, returning immediately with a CreateAccountStatus object in state IN_PROGRESS:

aws organizations create-account --email susan@example.com --account-name "Production Account"
# {"CreateAccountStatus": {"State": "IN_PROGRESS", "Id": "car-examplecreateaccountrequestid111"}}

Poll with describe-create-account-status until State flips to SUCCEEDED or FAILED. On failure, FailureReason tells you what went wrong: EMAIL_ALREADY_EXISTS (email tied to another AWS account) and ACCOUNT_LIMIT_EXCEEDED (account quota hit) are the two you'll see most.

The moment CreateAccount succeeds, Organizations auto-provisions OrganizationAccountAccessRole: an IAM role trusting the management account with full administrator permissions. That's what makes a created account immediately usable: assume the role and start deploying baseline infrastructure right away. It's also a standing, high-privilege trust relationship, so restrict exactly who in the management account can assume it. Administrator permissions are not a bypass, either: the role is still subject to whatever SCPs apply to the account, so a restrictive root policy can block your bootstrap before it starts.

With centralized root access management enabled (the current AWS-recommended baseline), the new account gets no root password by default. Day-one human access happens through OrganizationAccountAccessRole or an IAM Identity Center permission set.

If someone genuinely needs root, the management account has two different tools, and they are worth not confusing. Most privileged tasks (unlocking an S3 bucket policy, deleting a stuck SQS policy) run as a short-term, task-scoped root session via sts:AssumeRoot, capped at 15 minutes and limited to the one action you scoped it to. Nothing persists afterward. Allowing password recovery is different: it creates a root login profile on the member account, and that password is a standing credential that keeps working until someone explicitly removes it. Treat recovery as a two-step operation, not one: recover, do the work, then delete the credentials again with the IAMDeleteRootUserCredentials task. An access runbook that stops after step one quietly leaves a permanent root password behind on an account that was designed not to have one.

Before you click Create: the email you can't reuse

Every AWS account needs a globally unique root email; Organizations won't create one against an address that's already claimed. The aws+<alias>@yourdomain.com plus-addressing pattern (aws+prod@company.com) generates unique addresses under one domain without new mailboxes, the easiest way to avoid an EMAIL_ALREADY_EXISTS failure.

Console and CLI steps

1. Sign in to the management account, open the AWS Organizations console.
2. AWS accounts → Add an AWS account → Create an AWS account.
3. Enter the account name, root email, and optionally a custom role name.
4. Submit, then poll describe-create-account-status until the state resolves.

Two quotas to know before scripting this: an organization holds 10 accounts by default (adjustable up to 50,000 via Service Quotas, us-east-1 only), and 5 account creations run concurrently.

An account that already exists, whether it arrived through an acquisition or a team that started on their own, follows a different path with a different default security posture.

Inviting an existing AWS account into your organization

You call InviteAccountToOrganization from the management account, targeting the other account by email or account ID. Three things need to be true first.

Prerequisites before you send the invite

The management account's email must be verified (required since September 2018; a verification email goes out automatically when you create the org and can take time to arrive), and the target account can belong to only one organization at a time.

The third bites hardest on international acquisitions: both accounts must share the same AWS Seller of Record. Invite across a mismatch and Organizations refuses with Only join an organization whose Seller of Record is same as your account, a billing-entity problem no amount of IAM tuning fixes. Update the joining account's SOR to match and allow up to 24 hours to propagate before retrying.

That second rule used to mean the target account had to leave its current org and go standalone before it could join yours, a real obstacle on a fast-moving M&A timeline. As of November 19, 2025, that's no longer strictly true: AWS Organizations supports direct account transfers, so an org can invite an account that's still a member of a different organization. Accepting moves it directly across without an intermediate standalone period, and payment method, contact info, and support plan don't need reconfiguring mid-transfer.

One more thing to plan for: billing history from before the account joins doesn't transfer. Export historical Cost and Usage Reports before the handshake completes if either team will need them.

Console and CLI steps

1. From the management account: AWS accounts → Add an AWS account → Invite account, then supply the email or account ID.
2. The invited account's administrator accepts through the console or accept-handshake.
3. Track status with list-handshakes-for-account / describe-handshake before it's accepted.

aws organizations invite-account-to-organization \
  --target Id=123456789012,Type=ACCOUNT

An unanswered invitation expires after 15 days (the "Invitation acceptance expiration" quota, fixed and not adjustable). AWS also caps invitations at 20 per 24-hour period, or your max-accounts quota if higher, scaling automatically rather than through a separate Service Quotas request. Accepted invitations don't count against it, so a script that waits for each acceptance before sending the next won't get throttled on a large batch.

So what does the invited account actually look like the moment that handshake completes?

What actually happens to the invited account's users, root, and permissions

This is the question every team absorbing an acquired account needs answered before they click accept. The short version: less changes on the identity side than you'd expect, and less gets created for you than a brand-new account gets automatically.

AWS states the trap plainly in its invitation documentation: member accounts you invite "do not automatically get an administrator role created. You have to do this manually." The management account has no cross-account admin path into an invited account until someone deliberately creates OrganizationAccountAccessRole, named identically for consistency. Follow up with an IAM Identity Center account assignment so ongoing access doesn't ride on a single shared role.

The one thing that does change immediately is policy, and where the account lands decides which. An invitation can't target an OU: an accepted account joins at the organization root, exactly like a created one. So the SCPs attached to your root apply the instant the handshake completes, to every IAM user and role already in that account. Anything attached to the OU you eventually want it in applies only after a separate MoveAccount. One exception when sizing up the blast radius: SCPs never restrict service-linked roles, so whatever an AWS service does through its own SLR keeps working whatever your root policy denies. Credentials don't change; effective permissions still can, the moment you click accept.

That ordering makes root policy the thing to check first. Review what your root-attached SCPs deny before you send the invitation, because a restrictive root policy hits an acquired account's running workloads on acceptance, with no staging step in between. If your root is permissive, the useful pattern is to accept, verify what's running, then move the account into its permanent governed OU once nothing breaks. If your root is restrictive, get the account's workloads inventoried first: there is no way to soften the landing after the fact.

If your organization is Control Tower managed, accepting an invitation does not enroll the account. Joining through Organizations neither enrolls it nor extends governance, so it sits unenrolled whichever OU it ends up in. Unenrolled isn't ungoverned, though: SCPs attached to the root or to the destination OU still apply, including the preventive controls Control Tower attached there itself. What the account misses is the enrollment baseline, the Control Tower roles plus the CloudTrail and Config coverage and the detective controls that only land when you enroll. Enroll it deliberately: choose Enroll account in the Control Tower console, or register the destination OU, which enrolls the accounts inside it. A raw MoveAccount only relocates an ungoverned account.

DriftType: ACCOUNT_MOVED_BETWEEN_OUS is a different scenario: it applies to accounts Control Tower had already enrolled, where an out-of-band move leaves guardrails that don't cleanly reapply. Avoid manual moves once an account is governed.

Removal runs the same story backwards, and it has prerequisites most teams don't discover until the call fails.

Removing an account from your organization

Removal has real prerequisites, and they're not obvious until an account you assumed was ready to leave gets rejected with "You can't leave the organization yet."

The standalone-account requirements (and why created accounts fail this first)

Before RemoveAccountFromOrganization or LeaveOrganization will succeed, AWS requires the target account to have a selected AWS Support plan, verified contact information, a current valid payment method, and a verified phone number.

Here's the asymmetry that trips up teams on their first removal: accounts you created with CreateAccount never went through the standard AWS sign-up flow, so none of these four are collected automatically. Accounts you invited were standalone before they joined, so they typically already satisfy all four, unless something's lapsed, like an expired card.

Try to remove or leave without these in place and the console walks you through what's missing; the API returns a ConstraintViolationException with a reason like ACCOUNT_CANNOT_LEAVE_WITHOUT_PHONE_VERIFICATION. Complete the missing items through the console flow, then retry.

Two more blockers to check first: a delegated administrator registration (Security Hub, GuardDuty, IAM Identity Center, and StackSets are common ones) blocks removal until you reassign delegated admin status. And a freshly created account can't be removed for its first 4 days, a fixed minimum-age quota that doesn't apply to invited accounts.

Console and CLI steps

The API you call depends on who's initiating:

# From the management account, targeting the departing account
aws organizations remove-account-from-organization --account-id 123456789012

# From the member account itself
aws organizations leave-organization

Both require the standalone-account requirements above to already be satisfied, and both log the same underlying event with a different departureMethod in CloudTrail (REMOVED vs. LEFT).

The moment removal completes, billing separates immediately and SCPs stop applying, so principals in the account may have more effective permissions than a moment before. The account keeps its historical cost and usage data only if it rejoins later, so export what you need first. Nobody cleans up OrganizationAccountAccessRole for you either: delete that role from the now-standalone account yourself to revoke the former management account's access path.

There's more than one way to offboard an account, and picking the wrong one is hard to undo.

Remove, leave, or close: picking the right offboarding action

These sound similar and aren't. RemoveAccountFromOrganization and LeaveOrganization produce the same outcome, a live standalone account intact, called by different parties. Closing is different: it terminates the account. It also splits into two operations that live in different services and are easy to conflate. The management account closes a member through AWS Organizations, which works only in all-features mode and can never close the management account itself. A member account closes itself through AWS Account Management, signed in as its root user; that path still works in consolidated-billing mode, where the Organizations console hides the Close button entirely.

Closing isn't a soft delete. After 90 days the account and everything in it is gone for good, no recovery path. AWS also caps closures: the greater of 250 or 20% of total member accounts within a rolling 30-day period, up to 1,000, with only 3 closures running concurrently.

One more thing that changes the "day one" picture: as of July 2026, organizations created through the AWS Organizations console automatically get a default SCP at the root denying organizations:LeaveOrganization and account:CloseAccount, which stops member accounts from removing or closing themselves. It's scoped narrowly: organizations created via the CLI, SDKs, or CloudFormation with CreateOrganization never get it, regardless of date, and neither do organizations that already existed. The management account can modify or remove it anytime; on an API-created org, attach the same policy manually if you want that protection.

Every step so far is something a person does by hand, once per account. Here's what changes when it isn't a person doing it.

Automating this instead of repeating it by hand

Before you wire any of this into CloudFormation, know about one specific trap.

AWS::Organizations::Account defaults to DeletionPolicy: Retain. Deleting the stack does not close or delete the AWS account; it just stops CloudFormation from managing it. Teams that assume cdk destroy tears an account down find out the expensive way, when an account they thought was gone keeps showing up on the bill. AccountName, Email, and RoleName also can't be updated post-creation; a template change to any of the three gets rejected on both the update and its rollback.

Resources:
  ProdAccount:
    Type: AWS::Organizations::Account
    Properties:
      AccountName: "Production Account"
      Email: "susan@example.com"
      RoleName: "OrganizationAccountAccessRole"
    # DeletionPolicy defaults to Retain - deleting this stack does NOT close the account
  DevAccount:
    Type: AWS::Organizations::Account
    DependsOn: ProdAccount # required for multiple Account resources in one stack
    Properties:
      AccountName: "Dev Account"
      Email: "susan+dev@example.com"

AWS Control Tower's Account Factory exists to close the gaps raw CreateAccount and CloudFormation leave open, provisioning through a Service Catalog product that applies guardrails and OU placement at vend time; see the Control Tower vs. Organizations comparison for how that changes the operating model. Account Factory for Terraform does the same for Terraform-native pipelines; the Control Tower vs. CDK Landing Zone breakdown covers where that fits against a code-first approach.

What we build for clients takes a third path: codify the account itself. Adding an account becomes one entry in organization-structure.ts and a deploy, not console clicks repeated per account. OU-targeted StackSets already deployed against the landing zone pick up the new account automatically the moment it joins its OU, no redeploy needed. The same deploy applies the security baseline, CloudTrail, cost controls, CDK bootstrap, and alternate contacts, the list this article just walked through by hand.

If your team runs a handful of accounts with no SOC 2, ISO, or multi-team governance pressure yet, the manual path above is genuinely enough. Revisit it once account count or audit pressure grows, not before.

Frequently Asked Questions

Key takeaways

Name the actual job before opening the console: create, invite, remove, or IAM Identity Center if you meant a person. Created accounts get OrganizationAccountAccessRole automatically; invited accounts don't, and nobody manages that gap for you. Accounts join at the organization root, not an OU of your choosing, so your root-attached SCPs are what hit an invited account's existing principals the instant it accepts; review those before you send the invitation. Removal has real prerequisites that created accounts start with none of and invited accounts usually already satisfy. And deleting a CloudFormation stack does not delete an AWS account; closing it is the only action that does, and only after a 90-day window shuts for good.

Once your account membership is settled, the next real work is governance: SCPs, OU structure, and who has access to what. Start with the configurations most teams miss, then work through the wider multi-account best practices. If you're still consolidating a sprawl of accounts that grew without a plan, the single-to-multi-account migration roadmap sequences that work, and you can list what you already have by OU before you start moving anything.