AWS Organizations Setup: 13 Steps, 10 Accounts Free [2026]

Every AWS shop hits the same wall eventually. One account turns into five, five turns into thirty, and suddenly nobody can answer a simple question: which team owns this $40,000 line item, and why does the intern account have permission to spin up a p5.48xlarge instance? AWS Organizations is the service built to answer that question, and as of September 2026 it remains free to run, with the cost showing up only in the resources your member accounts actually consume. This tutorial walks through building a working multi-account structure from a blank management account: creating organizational units, writing your first Service Control Policy, wiring in centralized security services, and deploying the whole thing as reusable Terraform so it survives beyond a single afternoon of clicking through the console.

·

Google · Preferred Sources

Don't miss new tech stories on Google

Add Tech Insider once in the Google app and our stories appear in your news suggestions.

Add Now

What AWS Organizations Actually Does

AWS Organizations is the account-management layer that sits above every individual AWS account your company owns. It gives you one management account (formerly called the “master” account) that can create new member accounts, group them into organizational units, apply guardrail policies across entire groups at once, and roll every account’s bill into a single consolidated invoice. None of that requires a licensing fee. AWS charges for the underlying services (EC2, S3, Config, CloudTrail) that run inside member accounts, not for the organizational structure itself, according to AWS’s own FAQ page.

The practical reason teams adopt this in 2026 isn’t abstract governance theory. It’s that isolating workloads into separate accounts is still the single most effective blast-radius control AWS offers. A compromised credential in a sandbox account with a locked-down Service Control Policy can’t touch production billing, production data, or production IAM roles, because the policy denies those actions before IAM even evaluates them. AWS Organizations turns that isolation from a manual, account-by-account chore into something you define once at the organizational-unit level and inherit everywhere below it.

Consider the alternative most small teams start with: one AWS account, dozens of IAM users and roles, and a tangle of tags trying to separate “prod” resources from “test” resources by naming convention alone. That approach works until someone deletes the wrong tagged resource, or a billing alert can’t tell which project actually caused the spike. Splitting workloads into dedicated accounts under a shared Organizations structure fixes both problems at once: billing separates cleanly per account, and a bad deploy or leaked credential in one account has no path into another unless you explicitly wire one up.

Two newer policy types matter more in 2026 than they did a year or two back. Resource Control Policies (RCPs) let you set data-perimeter guardrails on resources themselves, such as blocking public S3 access org-wide regardless of what an individual bucket policy says. Declarative policies handle standardized configuration settings, like enforcing IMDSv2 or a consistent regional footprint, without writing a single line of policy JSON. Both sit alongside the older Service Control Policies (SCPs) on the same Organizations policies page, and this tutorial covers all three.

The quota increases AWS shipped for these policy types this year are not cosmetic. Doubling the SCP size limit to 10,240 characters and the RCP count to 2,000 per organization removed a real constraint that forced larger enterprises to split logically-related guardrails across multiple, harder-to-audit policies just to stay under the old ceilings. If you evaluated Organizations a couple of years ago and walked away because the policy limits felt too tight for a complex compliance program, it’s worth another look now that those specific ceilings have moved.

SCPs vs. RCPs vs. Declarative Policies

Before writing any policy JSON, it helps to know which of the three policy types actually solves the problem in front of you. Teams new to Organizations tend to reach for an SCP by default, then get confused when it can’t stop a misconfigured resource-based policy from exposing data. Each type evaluates differently and covers a different gap, and the table below lays out the practical distinction.

Policy Type	What It Controls	Evaluated Against	Typical Use Case
Service Control Policy (SCP)	What a principal (user or role) is allowed to do	IAM policies attached to that principal	Blocking root actions, restricting regions, denying risky services org-wide
Resource Control Policy (RCP)	How a resource can be accessed, regardless of caller	Resource-based policies (S3 bucket policies, KMS key policies)	Enforcing a data perimeter so only in-org identities can touch a bucket or key
Declarative Policy	Standardized account-level configuration settings	Service-specific default behaviors, not IAM at all	Enforcing IMDSv2, blocking public AMI sharing, locking a default region

Notice that none of the three ever grants a permission. All three are ceilings, not floors. An account still needs an underlying IAM policy that allows an action; SCPs, RCPs, and declarative policies can only take that allowance away, never add to it. This tutorial focuses mainly on SCPs, since they cover the widest range of everyday guardrails, but Step 10 walks through a working RCP as well.

Prerequisites and Requirements

Gather these before starting. Skipping any one of them is the most common reason people get stuck partway through Step 4.

• An AWS account that has never belonged to another organization, to use as your management account (or an existing account you’re comfortable promoting to that role)
• Root-user or an IAM administrator role with organizations:* permissions on that account
• AWS CLI v2.31 or newer installed locally (run aws --version to confirm; run aws configure if you haven’t set up credentials yet). The full Organizations CLI reference lists every command used in this tutorial
• A unique, verifiable email address for every member account you plan to create – each AWS account requires its own, distinct address
• Terraform 1.15 or newer if you plan to follow the infrastructure-as-code section near the end
• Roughly 90 minutes of uninterrupted time, since account creation inside Organizations takes a few minutes per account and you can only have five in progress simultaneously
• A rough map of your teams or environments (production, staging, sandbox, security, shared services) so your OU structure has a starting shape before you touch the console

You do not need AWS Control Tower, AWS Config, or any third-party landing-zone tool to complete this tutorial. Those are optional layers on top of the same Organizations foundation, and the comparison later in this guide explains when they earn their added complexity.

Step 1: Decide Which Account Becomes Your Management Account

The management account is the one account in your entire organization that cannot be restricted by a Service Control Policy, so treat the decision seriously. AWS’s own guidance, echoed across every current landing-zone reference architecture, is to use a dedicated account that runs nothing except organization administration, billing, and identity services. Do not promote your existing production account to management status. If your production workloads and your organization’s root permissions live in the same place, a single compromised credential threatens both at once.

If you’re starting fresh, create a brand-new AWS account specifically for this role, name it something unambiguous like acme-management, and enable MFA on its root user before you do anything else. This single account will eventually own every SCP, every OU, and the consolidated bill for every workload you run.

If you already run several standalone AWS accounts and want to fold them under one organization, pick whichever account currently handles billing or already has the fewest running workloads, and plan to migrate its own resources out over time. Retrofitting an organization onto an existing sprawl of accounts is slower than starting clean, but it’s still far better than continuing to manage everything separately, and every account you invite later inherits the same guardrails without needing to be rebuilt from scratch.

Step 2: Enable AWS Organizations

From the management account, open the Organizations console or run the CLI command below. This single call creates the organization, assigns your current account as the management account, and establishes a root container that every OU and account will eventually sit under.

aws organizations create-organization --feature-set ALL

The --feature-set ALL flag matters. Choosing CONSOLIDATED_BILLING instead gives you a single invoice across accounts but disables SCPs, RCPs, and declarative policies entirely, and you cannot add those features to a consolidated-billing-only organization without a support-assisted upgrade later. Always start with ALL unless you have a specific reason not to.

Expected output looks like this:

{
 "Organization": {
 "Id": "o-a1b2c3d4e5",
 "Arn": "arn:aws:organizations::111122223333:organization/o-a1b2c3d4e5",
 "FeatureSet": "ALL",
 "MasterAccountArn": "arn:aws:organizations::111122223333:account/o-a1b2c3d4e5/111122223333",
 "MasterAccountId": "111122223333",
 "MasterAccountEmail": "[email protected]"
 }
}

Save the Id value. You’ll reference it whenever you need to look up your organization’s root ID in later commands.

Step 3: Confirm Your Feature Set and Root ID

Before building out OUs, grab your root ID, since every top-level OU attaches to it.

aws organizations list-roots

This returns an Id that starts with r-, distinct from your organization ID, which starts with o-. Confusing the two is a common source of “InvalidInputException” errors in the next step, covered further in the troubleshooting section below.

Step 4: Design Your Organizational Unit Structure

This is the step people rush and regret. An OU tree is not just a folder hierarchy, it’s the shape your SCPs and RCPs will inherit down, so getting it wrong means re-parenting accounts later, which briefly drops any account-specific policy attachments during the move. AWS’s current quota documentation allows up to roughly 2,000 OUs per organization, but almost no company needs more than a dozen. Depth matters more than breadth.

A Starting Layout That Works for Most Teams

• Security OU – holds a log-archive account and a security-tooling account, both with restrictive SCPs and no direct developer access
• Infrastructure OU: shared-services accounts for networking, CI/CD runners, and artifact registries
• Workloads OU, split into Production and Non-Production child OUs, the level where the strictest and loosest policies diverge
• Sandbox OU – accounts for experimentation, with a tight budget-based SCP and automatic account decommissioning after 30 days of inactivity

Notice that Production and Non-Production sit under the same parent Workloads OU but as separate children. That lets you attach a shared baseline SCP at the Workloads level (deny leaving approved regions, for instance) while attaching stricter, production-only denials (block IAM user creation, block root actions) exclusively to the Production child.

Step 5: Create Your Organizational Units

With your root ID in hand, create each top-level OU with create-organizational-unit.

aws organizations create-organizational-unit \
 --parent-id r-a1b2 \
 --name "Security"

aws organizations create-organizational-unit \
 --parent-id r-a1b2 \
 --name "Infrastructure"

aws organizations create-organizational-unit \
 --parent-id r-a1b2 \
 --name "Workloads"

aws organizations create-organizational-unit \
 --parent-id r-a1b2 \
 --name "Sandbox"

Each call returns an OU ID starting with ou-, in output that looks like this:

{
 "OrganizationalUnit": {
 "Id": "ou-a1b2-secure01",
 "Arn": "arn:aws:organizations::111122223333:ou/o-a1b2c3d4e5/ou-a1b2-secure01",
 "Name": "Security"
 }
}

Record the Workloads OU ID, since the next command nests Production and Non-Production beneath it rather than beneath the root.

aws organizations create-organizational-unit \
 --parent-id ou-a1b2-workld01 \
 --name "Production"

aws organizations create-organizational-unit \
 --parent-id ou-a1b2-workld01 \
 --name "NonProduction"

Step 6: Create or Invite Member Accounts

You have two options here: create brand-new accounts directly through Organizations, or invite existing standalone accounts to join. Most greenfield setups use the first path, since it guarantees the account starts life already inside your organization’s OU structure and never spends time unprotected as a standalone account.

aws organizations create-account \
 --email "[email protected]" \
 --account-name "prod-app1"

This call is asynchronous. It returns a CreateAccountStatus object with a request ID you poll to confirm completion:

aws organizations describe-create-account-status \
 --create-account-request-id car-a1b2c3d4e5f6g7h8i9j0

Wait for the State field to read SUCCEEDED before moving on. AWS caps concurrent in-progress account creations at five, and the maximum invitation attempts in a rolling 24-hour window is the greater of 20 or your account quota, so batch large rollouts across a couple of hours rather than firing off fifty requests at once.

If you’re bringing in an already-existing standalone account instead, the flow is an invitation and acceptance handshake:

aws organizations invite-account-to-organization \
 --target '{"Type":"ACCOUNT","Id":"444455556666"}'

Step 7: Move Accounts Into the Correct OUs

New accounts land directly under the root by default. Move each one into its intended OU right away, since policies don’t apply retroactively to accounts sitting at the root.

aws organizations move-account \
 --account-id 555566667777 \
 --source-parent-id r-a1b2 \
 --destination-parent-id ou-a1b2-prod0001

Run aws organizations list-accounts-for-parent --parent-id ou-a1b2-prod0001 afterward to confirm the account landed where you expect:

{
 "Accounts": [
 {
 "Id": "555566667777",
 "Name": "prod-app1",
 "Email": "[email protected]",
 "Status": "ACTIVE",
 "JoinedMethod": "CREATED"
 }
 ]
}

This step is worth double-checking, because a mistyped destination OU ID silently succeeds and drops an account somewhere unexpected in the tree. It won’t throw an error if the destination OU ID is valid but not the one you meant, so a quick list-accounts-for-parent check after every move is cheap insurance against an account quietly missing its intended guardrails.

Step 8: Write Your First Service Control Policy

According to AWS’s SCP documentation, SCPs use the same JSON syntax as IAM policies, but they never grant permissions on their own. An SCP defines a permission ceiling: even if an account’s own IAM policy allows an action, an SCP attached above it can still deny that action outright, and an explicit deny in any SCP always wins over any allow. The example below is a deny-list pattern, which is the gentler starting point for teams that don’t yet know every service they need to allow.

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Sid": "DenyLeavingApprovedRegions",
 "Effect": "Deny",
 "NotAction": [
 "iam:*",
 "organizations:*",
 "route53:*",
 "cloudfront:*",
 "support:*"
 ],
 "Resource": "*",
 "Condition": {
 "StringNotEquals": {
 "aws:RequestedRegion": ["us-east-1", "us-west-2", "eu-west-1"]
 }
 }
 },
 {
 "Sid": "DenyRootUserActions",
 "Effect": "Deny",
 "Action": "*",
 "Resource": "*",
 "Condition": {
 "StringLike": {
 "aws:PrincipalArn": "arn:aws:iam::*:root"
 }
 }
 }
 ]
}

Save that document as region-guardrail.json and create the policy:

aws organizations create-policy \
 --name "RegionGuardrail" \
 --type SERVICE_CONTROL_POLICY \
 --content file://region-guardrail.json \
 --description "Restricts activity to approved regions and blocks root user actions"

As of a May 2026 quota increase, a single node (root, OU, or account) can now have up to 10 SCPs attached, up from the previous limit of five, and each SCP can now run up to 10,240 characters, double the old 5,120-character ceiling. That extra headroom matters once you’re layering region restrictions, tagging requirements, and service-specific denials at the same OU level.

Step 9: Attach and Test the Policy

Attach the policy to the Sandbox OU first, not Production. Testing a new SCP against low-stakes accounts before rolling it out to revenue-generating workloads is the single habit that prevents the worst on-call pages.

aws organizations attach-policy \
 --policy-id p-a1b2c3d4 \
 --target-id ou-a1b2-sandbx01

Wait a few minutes for propagation, then have someone with access to a Sandbox account attempt an action the policy should block, like launching an EC2 instance in ap-southeast-2 when only us-east-1, us-west-2, and eu-west-1 are approved. A correctly working SCP returns an UnauthorizedOperation or explicit access-denied error referencing an organization policy, not a generic permissions error. Once verified, attach the same policy to Workloads and Security OUs.

Step 10: Add a Resource Control Policy for Data Perimeter Enforcement

RCPs are the newer counterpart to SCPs. Instead of restricting what principals can do, they restrict how resources can be accessed, regardless of what a resource-based policy on that individual S3 bucket or KMS key claims to allow. AWS expanded the RCP quota to 2,000 per organization in a July 2026 update, doubling the earlier 1,000-policy ceiling, at no additional cost.

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Sid": "EnforceOrgIdentityOnS3",
 "Effect": "Deny",
 "Principal": "*",
 "Action": ["s3:*"],
 "Resource": "*",
 "Condition": {
 "StringNotEqualsIfExists": {
 "aws:PrincipalOrgID": "o-a1b2c3d4e5"
 },
 "BoolIfExists": {
 "aws:PrincipalIsAWSService": "false"
 }
 }
 }
 ]
}

This blocks any S3 access from outside your organization’s ID, closing the door on the classic “bucket accidentally made public” incident even if a developer fat-fingers a resource policy later. Create and attach it the same way as an SCP, but with --type RESOURCE_CONTROL_POLICY.

Step 11: Connect IAM Identity Center for Centralized Access

Organizations manages accounts, but people still need a way to log into them without juggling separate credentials per account. That’s IAM Identity Center’s job, and it depends on Organizations already being enabled with the ALL feature set. Our AWS IAM Identity Center setup guide covers the full permission-set and group-assignment workflow, but the short version from the Organizations side is a single enablement call from the management account:

aws sso-admin list-instances

Once enabled, Identity Center reads your OU structure directly, letting you assign a permission set like ReadOnlyAccess to your entire Non-Production OU in one action instead of touching every account’s IAM individually.

Step 12: Delegate Administration for Security Services

Running GuardDuty, Security Hub, Macie, or Detective from the management account is a common but avoidable mistake, since it gives that highly privileged account operational duties it doesn’t need. Instead, designate your Security OU’s dedicated security-tooling account as the delegated administrator:

aws organizations register-delegated-administrator \
 --account-id 999900001111 \
 --service-principal guardduty.amazonaws.com

aws organizations register-delegated-administrator \
 --account-id 999900001111 \
 --service-principal securityhub.amazonaws.com

From that point forward, GuardDuty and Security Hub auto-enable for every new account that joins the organization, without anyone touching the management account again. If you haven’t set up GuardDuty itself yet, walk through our AWS GuardDuty setup tutorial first, and pair it with the delegated-administrator pattern from our AWS Security Hub CSPM setup guide for a unified security posture across every account in the org.

Step 13: Set Up an Organization Trail and Consolidated Billing

Two last pieces close the loop: audit logging and billing. An organization trail, created once from the management account, captures API activity from every current and future member account automatically. Our AWS CloudTrail setup guide covers trail configuration in depth; the Organizations-specific flag is --is-organization-trail on the create-trail call.

Consolidated billing needs no separate setup step, it’s active the moment you created the organization in Step 2. Every member account’s usage rolls into the management account’s single invoice, and Reserved Instance and Savings Plan discounts share automatically across all eligible accounts unless you explicitly turn sharing off in billing preferences. Check the table below for what changes at each account-count tier.

Metric	Default Quota	Maximum (Adjustable)
Accounts per organization	10	Up to 50,000 with a quota increase request
Organizational units per org	1,000	Up to 2,000
SCPs attached per node	10 (raised from 5 in May 2026)	10
SCP size limit	10,240 characters (raised from 5,120)	10,240 characters
Resource Control Policies per org	2,000 (raised from 1,000 in July 2026)	2,000
Concurrent account creations	5 in progress at once	5
Invitations per 24-hour window	Greater of 20 or your account quota	Scales with quota

As of an August 2026 change, you can also check your current accounts quota and usage directly in the Service Quotas console or via the GetServiceQuota API, without opening a support case, which makes capacity planning ahead of a large account rollout considerably less painful.

AWS Organizations vs. AWS Control Tower: Which Do You Need?

Everything covered so far is AWS Organizations on its own, and for a lot of engineering teams, that’s genuinely enough. AWS Control Tower is a managed layer built on top of Organizations that automates account provisioning through pre-built account factories, ships opinionated guardrails out of the box, and can manage up to 10,000 accounts by default. It requires Organizations underneath it, it doesn’t replace it.

Factor	AWS Organizations (Manual)	AWS Control Tower
Setup cost	Free, DIY effort	Free service, but assumes more architectural buy-in upfront
Account provisioning	CLI or console, one at a time	Self-service Account Factory templates
Guardrails	You write and maintain every SCP/RCP	Pre-built guardrails, still built on SCPs underneath
Best fit	Small teams, custom OU logic, existing accounts	Larger orgs standardizing account creation at scale
Learning curve	Steeper upfront, more transparent later	Faster to a working baseline, more opinionated

If you’re managing a handful of accounts and already understand SCPs, staying on plain Organizations keeps things transparent and avoids an extra abstraction layer to debug. Teams provisioning dozens of new accounts a quarter get more value from Control Tower’s Account Factory. For a deeper breakdown against Azure and GCP equivalents, see our AWS Control Tower vs. Azure Landing Zone vs. GCP comparison.

5 Common Pitfalls When Setting Up AWS Organizations

• Attaching a broad deny-all SCP directly to the root. A mistake at the root level cascades to every single account instantly, including your management account’s ability to fix it. Always test at a leaf OU like Sandbox first.
• Forgetting that SCPs never grant permissions. New team members sometimes attach an SCP expecting it to unlock access. It can only narrow what IAM already allows, never widen it.
• Running production workloads in the management account. Because SCPs can’t restrict the management account, anything running there sits outside your entire guardrail system. Keep it administrative only.
• Leaving new accounts parked at the root. Accounts created via create-account land at the root by default and inherit no OU-specific policy until you explicitly move them, which means a freshly created account can sit unprotected for hours if nobody remembers the move step.
• Ignoring email uniqueness requirements. Every AWS account needs a distinct root email address, and reusing one mid-project because you ran out of team aliases is a frequent cause of stalled account-creation requests.

Troubleshooting AWS Organizations

These are the errors and confusing states that come up most often once real accounts and policies are in play.

• “AccessDeniedException” when calling any Organizations API. You’re likely calling from a member account instead of the management account, or from a role that lacks organizations:* permissions. Only the management account (or a registered delegated administrator, for specific services) can run most Organizations calls.
• “DuplicateOrganizationalUnitException” on OU creation. You already have an OU with that exact name under the same parent. OU names must be unique among siblings, though the same name can exist under different parents.
• “ConstraintViolationException: You have exceeded the allowed number of accounts.” You’ve hit your accounts quota (default 10). Request an increase through Service Quotas rather than opening a support ticket, since the August 2026 change made this self-service.
• SCP attached but the restricted action still works. Check whether the account also carries an older, more permissive SCP inherited from a different OU in its path. Evaluate the effective policy for the account with aws organizations describe-effective-policy to see the merged result of everything above it.
• “PolicyTypeNotEnabledException” when creating an SCP or RCP. Your organization was created with --feature-set CONSOLIDATED_BILLING instead of ALL, or the policy type hasn’t been enabled at the root. Enable it with aws organizations enable-policy-type.
• Invited account never shows up as a member. Invitations expire after 15 days if unaccepted. Check list-handshakes-for-organization and resend if the handshake shows an EXPIRED state.
• Move-account succeeds but Identity Center permission sets don’t apply. Identity Center syncs its account cache on an interval, not instantly. Give it a few minutes, or trigger a manual sync from the Identity Center console if the delay stretches past 15 minutes.
• “MalformedPolicyDocumentException” on a valid-looking SCP. Double-check the character count. Even with the raised 10,240-character limit, verbose policies with inline comments (not valid JSON) or overly explicit action lists still hit the ceiling faster than expected. Minify the JSON before uploading.

Advanced Tips: Scaling to Hundreds of Accounts

Once you pass roughly 20-30 accounts, a few habits pay off that don’t matter at smaller scale. First, stop creating accounts by hand entirely and drive every account through a Terraform module or a CI pipeline, so the account name, email pattern, and initial OU placement are consistent and auditable by default. Second, split your SCPs by concern rather than by team: a region-restriction SCP, a root-lockdown SCP, and a tagging-enforcement SCP attached independently are far easier to reason about and roll back than one 8,000-character policy that does all three.

Third, budget for RCPs early rather than retrofitting them. Since RCPs evaluate independently of SCPs and apply to resources rather than principals, they close gaps that even a well-written SCP can’t, particularly around cross-account resource sharing where the calling principal technically has permission but shouldn’t have access anyway. Finally, treat your Security OU’s delegated-administrator account as sacred: no developer access, no exceptions, since it’s the account with visibility into every other account’s findings.

Use Tag Policies to Keep Cost Allocation Honest

Once you’re past a handful of accounts, cost allocation tags stop being optional. A tag policy, one of the lesser-known Organizations policy types alongside SCPs and RCPs, lets you enforce a consistent tag key and allowed values (like CostCenter restricted to a specific list of valid department codes) across every account in an OU. Attach it the same way as an SCP, but with --type TAG_POLICY. Without this, finance ends up reconciling spend with a spreadsheet full of inconsistent tag casing, which defeats the purpose of consolidated billing in the first place.

Automate New-Account Onboarding End to End

The manual CLI flow in this tutorial is the right way to learn how the pieces fit, but at scale it should trigger from a pull request, not a terminal. A common pattern is an EventBridge rule listening for CreateAccountResult events, which fires a Lambda function that tags the new account, moves it into the correct OU based on a naming convention, and posts a confirmation to a team Slack or Teams channel automatically. That closes the exact gap called out in the pitfalls section: a new account that sits unprotected at the root because a human forgot the move step.

Complete Working Project: A 4-Account Landing Zone in Terraform

Clicking through the console works for learning, but any real rollout should be reproducible. Here’s a trimmed but complete Terraform configuration that reproduces the OU structure and first SCP from this tutorial, ready to expand with more accounts and policies as needed.

terraform {
 required_providers {
 aws = {
 source = "hashicorp/aws"
 version = "~> 5.70"
 }
 }
}

provider "aws" {
 region = "us-east-1"
}

resource "aws_organizations_organization" "org" {
 aws_service_access_principals = [
 "guardduty.amazonaws.com",
 "securityhub.amazonaws.com",
 "sso.amazonaws.com",
 "cloudtrail.amazonaws.com"
 ]
 feature_set = "ALL"
}

resource "aws_organizations_organizational_unit" "security" {
 name = "Security"
 parent_id = aws_organizations_organization.org.roots[0].id
}

resource "aws_organizations_organizational_unit" "workloads" {
 name = "Workloads"
 parent_id = aws_organizations_organization.org.roots[0].id
}

resource "aws_organizations_organizational_unit" "production" {
 name = "Production"
 parent_id = aws_organizations_organizational_unit.workloads.id
}

resource "aws_organizations_organizational_unit" "sandbox" {
 name = "Sandbox"
 parent_id = aws_organizations_organization.org.roots[0].id
}

resource "aws_organizations_policy" "region_guardrail" {
 name = "RegionGuardrail"
 type = "SERVICE_CONTROL_POLICY"
 content = file("${path.module}/region-guardrail.json")
}

resource "aws_organizations_policy_attachment" "sandbox_guardrail" {
 policy_id = aws_organizations_policy.region_guardrail.id
 target_id = aws_organizations_organizational_unit.sandbox.id
}

resource "aws_organizations_account" "prod_app1" {
 name = "prod-app1"
 email = "[email protected]"
 parent_id = aws_organizations_organizational_unit.production.id

 lifecycle {
 ignore_changes = [role_name]
 }
}

Run terraform init then terraform plan to review the changes before applying. Note the lifecycle block on the account resource, which prevents Terraform from trying to recreate the account if the default IAM role name changes after creation, a subtle drift issue that trips up first-time users of this provider resource.

This gives you a version-controlled, peer-reviewable definition of your entire account structure. Expand it by adding more aws_organizations_account blocks and more policy attachments as your organization grows, and pair it with a CI pipeline that runs terraform plan on every pull request touching this configuration.

Keeping Your Organization Healthy Long-Term

A landing zone isn’t a one-time project, it needs light maintenance. Review your SCP and RCP attachments quarterly to catch policies nobody remembers writing. Watch your accounts quota as headcount grows, especially now that Service Quotas exposes usage without a support ticket. And revisit your OU tree whenever a new business unit or acquisition shows up, since bolting a new team onto the wrong OU is far more disruptive to unwind than getting it right at creation time. Teams that treat this structure as living infrastructure, reviewed alongside regular security audits, tend to avoid the sprawling, undocumented account mess that Organizations was built to prevent in the first place.

It also helps to assign one engineer or a small platform team explicit ownership of the OU tree and its attached policies, rather than leaving it as everyone’s shared responsibility and therefore nobody’s. That owner should be the one signing off on new top-level OUs, reviewing quota increase requests before they go to AWS Support, and running the quarterly policy audit mentioned above. Without a named owner, landing zones tend to drift back toward the flat, undifferentiated account sprawl this entire setup exists to prevent.

Frequently Asked Questions

Is AWS Organizations free to use?

Yes. There’s no charge for creating an organization, adding accounts, defining OUs, or writing SCPs and RCPs. You only pay for the AWS services that run inside each member account, plus optional add-ons like AWS Config aggregators or CloudTrail data events if you enable them.

How many AWS accounts can one organization hold?

The default limit is 10 accounts, but this is a soft quota you can raise through Service Quotas. AWS documentation and current guides reference limits scaling up to tens of thousands of accounts for large enterprises that request the increase.

What’s the difference between a Service Control Policy and a Resource Control Policy?

An SCP restricts what a principal (a user or role) can do, evaluated alongside IAM. An RCP restricts how a resource (like an S3 bucket) can be accessed, evaluated independently of who’s asking. Both act only as guardrails and never grant permissions on their own.

Do I need AWS Control Tower to use AWS Organizations?

No. Organizations works completely standalone, and this entire tutorial doesn’t touch Control Tower. Control Tower is an optional layer built on top of Organizations that automates account provisioning and ships pre-built guardrails, useful once you’re creating accounts frequently enough that manual provisioning becomes a bottleneck.

Can I apply a Service Control Policy to my management account?

No. SCPs never apply to the management account itself, only to member accounts. That’s exactly why the management account should run nothing beyond organization administration, billing, and identity services, since nothing running there can be restricted by your guardrails.

What happens to Reserved Instances and Savings Plans when accounts join an organization?

By default, RI and Savings Plan discounts share automatically across every account in the organization through consolidated billing, which typically improves overall utilization. The management account can disable this sharing in billing preferences if you need per-account cost isolation instead.

How long does it take to create a new member account?

Typically a few minutes per account, though it’s an asynchronous process you poll with describe-create-account-status rather than something that completes instantly. AWS allows up to five account creations in progress simultaneously.

Can I move an account between organizations?

Yes, but it’s a multi-step process: the account must first leave its current organization, then accept an invitation to join the new one. Any SCPs, RCPs, or delegated-administrator relationships tied to the old organization no longer apply once the account leaves, so plan the security transition carefully before initiating the move.

Related Coverage

• AWS Cognito Setup: 13 Steps, $0.015/MAU [2026]
• Epic Online Services Setup: Free Backend in 13 Steps [2026]
• AWS Security Hub CSPM Setup: $0.001/Check, 12 Steps [2026]
• AWS Lambda MicroVMs Setup: 12 Steps, 4x Peak Scaling [2026]
• AWS Global Accelerator Game Server Setup: 12 Steps [2026]