Accounts and Organizations

This content was generated with the assistance of AI and should be verified against the official documentation before being relied on in production.

See the section bibliography for the reference material consulted while preparing these pages.

Commands and console steps below were checked against the AWS CLI v2 command reference and the AWS Organizations and AWS Control Tower user guides on 2026-10-01; re-verify against the linked reference pages if you are reading this later. The AWS account is the basic container for resources, identities and billing in AWS, and almost every production setup uses many accounts rather than one. This page covers the tools that manage that fleet: AWS Organizations, its policy types, AWS Control Tower with its landing zone and Account Factory, consolidated billing, tagging, and the multi-account layout used by the Bookshelf scenario. The account-creation and root-user steps for a single first account are in Getting Started with AWS; users, roles and policies inside an account are in Identity and Access.

Why more than one account

An AWS account is the strongest isolation boundary the platform offers: resources, IAM identities, service quotas, blast radius of a compromised credential and the bill all stop at the account edge. Splitting workloads across accounts therefore buys:

Blast-radius control. A mistake or breach in the development account cannot touch production data.
Quota isolation. Service quotas are per account and Region, so one noisy workload cannot exhaust another’s.
Cost visibility. Each account is a natural cost centre in billing reports.
Policy boundaries. Guardrails can be attached to a group of accounts instead of being re-created in each.
Least privilege by default. Access to production can be granted separately from access to a sandbox.

The cost of that isolation is coordination: creating, governing, billing and securing dozens of accounts by hand does not scale, which is exactly what AWS Organizations and Control Tower automate. Older single-account tutorials still put everything — development, production and security tooling — in one account; that is fine for learning but not the recommended structure for anything shared by a team. The Azure counterpart of this layout is described in Resource Organization and Governance and Compliance.

AWS Organizations

AWS Organizations lets you create an organization that groups AWS accounts under one management point. The building blocks are:

Management account: The account that created the organization. It pays for every member account (consolidated billing), creates and invites accounts and attaches policies. It is also the one account that policies cannot restrict, so keep it free of workloads and use it only for organization administration.
Member accounts: Every other account in the organization. They are subject to the organization’s policies.
Root (the organization root): The parent container of everything in the organization hierarchy. Do not confuse it with the account root user.
Organizational units (OUs): Containers for accounts (and other OUs), nestable up to five levels below the root. Policies attach to the root, to an OU or directly to an account and are inherited downward.
Delegated administrator: A member account that is allowed to administer a given integrated service (for example Security Hub or IAM Identity Center) on behalf of the organization, so the management account does not have to be used for day-to-day security work.

An organization has one of two feature sets. All features is the default for new organizations and is required for policy types such as SCPs, tag policies and centralized root access; consolidated billing only is a legacy mode that offers only the billing roll-up and can be upgraded to all features.

The Bookshelf scenario uses the layout in the diagram below. The names are placeholders; the identifiers are fake.

graph TD ROOT["Organization root (r-ex00)"] --> MGMT["Management account
bookshelf-management"] ROOT --> SEC["OU: Security"] ROOT --> INFRA["OU: Infrastructure"] ROOT --> WL["OU: Workloads"] ROOT --> SB["OU: Sandbox"] SEC --> LOG["Account: log-archive"] SEC --> AUD["Account: audit"] INFRA --> NET["Account: network"] WL --> DEV["Account: bookshelf-dev"] WL --> PROD["Account: bookshelf-prod"] SB --> EXP["Account: sandbox-alice"] PROD --> RES["Resources: ECS, S3, Aurora"] SCP["SCP and RCP attached at root and OUs"] -.-> WL SCP -.-> SB

Creating an organization

In the AWS Management Console

Sign in with the account that will become the management account and open AWS Organizations.
Choose Create an organization. Organizations enables all features by default.
Check the email address of the management account for the verification message and confirm it; invitations and some operations are blocked until the address is verified.
Under AWS accounts, choose Add an AWS account to Create an AWS account (or invite an existing one), then use Actions and Move to place it in an OU. Organizations is a global service, so the Region selector does not matter, although the console runs in us-east-1.

With the AWS CLI

# Create the organization from the current account (becomes the management account)
aws organizations create-organization --feature-set ALL

# Discover the root and the organization id (placeholders shown: o-exampleorg1, r-ex00)
ROOT_ID=$(aws organizations list-roots --query 'Roots[0].Id' --output text)

# Create the OUs used by Bookshelf
aws organizations create-organizational-unit --parent-id "$ROOT_ID" --name Workloads
aws organizations create-organizational-unit --parent-id "$ROOT_ID" --name Sandbox

# List OUs under the root
aws organizations list-organizational-units-for-parent --parent-id "$ROOT_ID" \
  --query 'OrganizationalUnits[].[Name,Id]' --output table

Reference: https://docs.aws.amazon.com/cli/latest/reference/organizations/create-organization.html, https://docs.aws.amazon.com/cli/latest/reference/organizations/create-organizational-unit.html and https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org.html

Creating and moving member accounts

New accounts are created asynchronously: create-account returns a request id that you poll. Each account needs a unique root email address (a plus-addressed alias such as aws+bookshelf-dev@example.com works with most mail providers) and Organizations creates an administrative role in the new account, OrganizationAccountAccessRole by default, that the management account can assume. After creation the account has no root password until you use the password-recovery flow or, better, centralize root access as described below.

In the AWS Management Console

In AWS Organizations open AWS accounts and choose Add an AWS account, then Create an AWS account.
Enter the account name (bookshelf-dev), the unique root email address and, optionally, a role name other than OrganizationAccountAccessRole.
Choose Create AWS account; the new account appears under the root after a few minutes.
Select the account, choose Actions, then Move, and pick the target OU.

With the AWS CLI

# Replace the email with an address you control; account names and emails must be unique
REQUEST_ID=$(aws organizations create-account \
  --email "aws+bookshelf-dev@example.com" \
  --account-name "bookshelf-dev" \
  --role-name OrganizationAccountAccessRole \
  --query 'CreateAccountStatus.Id' --output text)

# Poll until State is SUCCEEDED, then read the new account id
aws organizations describe-create-account-status \
  --create-account-request-id "$REQUEST_ID" \
  --query 'CreateAccountStatus.[State,AccountId]' --output text

DEV_ACCOUNT_ID=111122223333      # placeholder; use the id returned above
WORKLOADS_OU=ou-ex00-aaaa1111    # placeholder; id of the Workloads OU

# Move the account from the root into the Workloads OU
aws organizations move-account --account-id "$DEV_ACCOUNT_ID" \
  --source-parent-id "$ROOT_ID" --destination-parent-id "$WORKLOADS_OU"

# Review the whole organization
aws organizations list-accounts \
  --query 'Accounts[].[Name,Id,Status]' --output table

Reference: https://docs.aws.amazon.com/cli/latest/reference/organizations/create-account.html and https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_create-cli.html

Quotas matter at scale: the number of accounts per organization has a default quota that you can raise through Service Quotas, creating accounts is rate limited, and AWS limits how many member accounts can be closed in a rolling window. Closed accounts remain in a suspended state for a post-closure period before they are removed. Check the current numbers on the quotas page before planning a large rollout.

Reference: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_reference_limits.html

Consolidated billing

When accounts join an organization, billing consolidates into the management account, which becomes the payer account: it receives a single invoice that itemizes the charges of every member. Besides one bill, consolidation combines usage across accounts for tiered and volume pricing, and lets Savings Plans and Reserved Instance discounts be shared between accounts under the organization’s sharing settings. Member accounts still see their own usage in Cost Explorer. Billing is covered in more depth in Cost Management and Support.

Practical points:

Costs are attributed to accounts out of the box, so an account-per-workload layout gives per-workload cost reporting without any tagging effort; tags add finer grain inside an account.
The management account can control whether member accounts see discount-sharing and which billing information they can view.
Pricing is not repeated here; AWS Organizations itself has no additional charge, and the pricing of each service you use applies as usual. See https://aws.amazon.com/pricing/ for the current pricing hub.

Reference: https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html

Organization policies

Organizations supports several policy types. Authorization policies set permission guardrails; management policies standardize configuration. Each type must be enabled on the root before it can be attached.

Policy type	What it does	Applies to
Service control policies (SCPs)	Define the maximum permissions available to IAM principals in member accounts. They never grant access.	Principals (users and roles, including the member account root user)
Resource control policies (RCPs)	Define the maximum permissions available on resources in member accounts, regardless of who calls. Support a growing list of services.	Resources in member accounts, including access from outside the organization
Declarative policies	Enforce the baseline configuration of a service (for example EC2 block public access or the IMDS defaults) across the organization, so settings hold even if new APIs appear.	Service configuration
Tag policies	Standardize tag keys and allowed values and report on non-compliance.	Tag keys and values on supported resource types
Backup policies	Apply AWS Backup plans across accounts.	Backup configuration
AI services opt-out policies	Control whether AWS AI services may store and use your content to improve those services.	Content use by AI services

Policy type

What it does

Applies to

Service control policies (SCPs)

Define the maximum permissions available to IAM principals in member accounts. They never grant access.

Principals (users and roles, including the member account root user)

Resource control policies (RCPs)

Define the maximum permissions available on resources in member accounts, regardless of who calls. Support a growing list of services.

Resources in member accounts, including access from outside the organization

Declarative policies

Enforce the baseline configuration of a service (for example EC2 block public access or the IMDS defaults) across the organization, so settings hold even if new APIs appear.

Service configuration

Tag policies

Standardize tag keys and allowed values and report on non-compliance.

Tag keys and values on supported resource types

Backup policies

Apply AWS Backup plans across accounts.

Backup configuration

AI services opt-out policies

Control whether AWS AI services may store and use your content to improve those services.

Content use by AI services

Reference: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies.html

Service control policies

An SCP is a JSON policy with almost the IAM syntax. Three rules explain nearly every surprise:

An SCP never grants anything. A principal needs an identity-based or resource-based policy that allows the action and every SCP above it, at every level between the account and the root, must also allow it.
SCPs affect member accounts only, including their root users; the management account is never restricted by them. Service-linked roles are also exempt.
A newly enabled organization attaches the managed FullAWSAccess policy to the root, OUs and accounts so that everything keeps working. Use deny statements added on top of it (a deny list) for most guardrails; replacing it with an allow list is stricter but needs much more maintenance.

Effective permissions are the intersection of the SCP and RCP, any permissions boundary, and the identity and resource policies. The full evaluation flow is covered in Identity and Access.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeavingOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    },
    {
      "Sid": "DenyOutsideApprovedRegions",
      "Effect": "Deny",
      "NotAction": [
        "iam:*",
        "organizations:*",
        "route53:*",
        "cloudfront:*",
        "support:*",
        "sts:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["us-east-1", "eu-west-1"]
        }
      }
    }
  ]
}

Reference: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html

Test every new SCP on a sandbox OU first: an overly broad deny can lock administrators out of services, and a too-wide NotAction list for global services is a common mistake. Use the service last accessed data and CloudTrail to see what is actually used. SCPs have a maximum document size and a maximum number of direct attachments per root, OU or account; the limits are on the quotas page above.

Resource control policies

An RCP guards the resource side. Where an SCP says what your principals may do, an RCP says what anyone may do to your resources, which is the control you need to enforce a data perimeter (for example, "all S3 requests must use TLS" or "only principals from our organization may read these buckets"). RCPs do not grant either and do not apply to service-linked roles; they apply only to resource types of the services that support them.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnforceTlsOnS3",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": "*",
      "Condition": {
        "BoolIfExists": { "aws:SecureTransport": "false" }
      }
    }
  ]
}

Reference: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html

Enabling and attaching policies

In the AWS Management Console

Open AWS Organizations, choose Policies, then the policy type (for example Service control policies).
If the type is not enabled, choose Enable service control policies and confirm.
Choose Create policy, enter a name and description, paste or build the JSON, and choose Create policy.
Open the policy, choose the Targets tab, then Attach and select the OU (or account, or root).
To test safely, attach to the Sandbox OU first and use CloudTrail and the IAM service last accessed data to observe effects.

With the AWS CLI

# Enable SCPs on the root (also: RESOURCE_CONTROL_POLICY, TAG_POLICY, BACKUP_POLICY,
# DECLARATIVE_POLICY_EC2, AISERVICES_OPT_OUT_POLICY)
aws organizations enable-policy-type --root-id "$ROOT_ID" \
  --policy-type SERVICE_CONTROL_POLICY

# Create the SCP from a local file and capture its id
POLICY_ID=$(aws organizations create-policy \
  --name bookshelf-guardrails \
  --description "Deny leaving the org and unapproved Regions" \
  --type SERVICE_CONTROL_POLICY \
  --content file://scp-guardrails.json \
  --query 'Policy.PolicySummary.Id' --output text)

# Attach it to the Sandbox OU first
SANDBOX_OU=ou-ex00-bbbb2222   # placeholder
aws organizations attach-policy --policy-id "$POLICY_ID" --target-id "$SANDBOX_OU"

# See which SCPs apply to a target
aws organizations list-policies-for-target --target-id "$SANDBOX_OU" \
  --filter SERVICE_CONTROL_POLICY \
  --query 'Policies[].[Name,Id]' --output table

Reference: https://docs.aws.amazon.com/cli/latest/reference/organizations/attach-policy.html and https://docs.aws.amazon.com/organizations/latest/userguide/enable-policy-type.html

AWS Control Tower

AWS Control Tower builds an opinionated, governed multi-account environment on top of Organizations and several other services (IAM Identity Center, CloudTrail, AWS Config, Service Catalog and more). It is the fastest way to get a well-architected baseline when you start a new organization, or to bring an existing one under governance. Its main concepts are:

Landing zone: The governed multi-account environment: the organization with its OU structure, the shared Log Archive and Audit accounts, centralized logging with CloudTrail and Config, IAM Identity Center access, and the set of governed Regions. Landing zone versions are numbered; you update to a newer one from the console or the API, and the 4.0 line changed how the landing zone is built and added a controls-only option so that existing organizations can use controls without Control Tower creating the full environment. Check the release notes for the current version.
Controls (formerly guardrails): Pre-packaged governance rules, each either preventive (implemented with SCPs or RCPs), detective (implemented with AWS Config rules) or proactive (CloudFormation hooks that block non-compliant resources before they are created). They are mandatory, strongly recommended or elective, and are enabled per OU. Controls are inherited by the accounts in an OU.
Account Factory: A Service Catalog-based way to provision new accounts that already meet the baseline, with a standard network setup and enrollment into IAM Identity Center. Account Factory for Terraform (AFT) offers the same through a Terraform pipeline.
Dashboard and drift detection: Control Tower reports compliance by OU and detects when someone changes a managed resource outside it (for example moving an account without re-enrolling it), which you repair with Repair or by re-registering the OU.

Control Tower itself has no additional charge; you pay for the underlying services it uses, notably AWS Config, CloudTrail, S3 storage for logs, and Service Catalog usage. See https://aws.amazon.com/controltower/pricing/ (dated pricing information) for the current model. Older guides sometimes describe Control Tower as always creating a fixed set of OUs and an immutable landing zone; today you choose additional OUs and Regions, and you can update or decommission the landing zone.

Reference: https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html

Setting up a landing zone

In the AWS Management Console

Sign in as the management account administrator and open AWS Control Tower. Choose your home Region carefully: it cannot be changed later and it hosts Control Tower resources. us-east-1 is used here as a placeholder.
Choose Set up landing zone. Select the additional governed Regions.
Configure the foundational OU (Security) and, optionally, additional OUs such as Workloads and Sandbox.
Provide separate, unique email addresses for the Log Archive and Audit accounts, and configure log retention and encryption (optionally with a customer managed KMS key).
Choose IAM Identity Center as the access configuration (or self-managed federation), review, and choose Set up landing zone. Setup takes around an hour.

With the AWS CLI

Landing zone creation is driven by a JSON manifest; the console is the practical way to build the first one. After that, the CLI is useful for inspecting the environment and for managing controls in bulk.

# List landing zones and read the status/version of the first one
aws controltower list-landing-zones
LZ_ARN=$(aws controltower list-landing-zones --query 'landingZones[0].arn' --output text)
aws controltower get-landing-zone --landing-zone-identifier "$LZ_ARN" \
  --query 'landingZone.[status,version,driftStatus.status]' --output text

# Enable a control on an OU (control and OU ARNs are placeholders)
aws controltower enable-control \
  --control-identifier "arn:aws:controltower:us-east-1::control/EXAMPLE_CONTROL_ID" \
  --target-identifier "arn:aws:organizations::111122223333:ou/o-exampleorg1/ou-ex00-aaaa1111"

# Review what is enabled on the OU
aws controltower list-enabled-controls \
  --target-identifier "arn:aws:organizations::111122223333:ou/o-exampleorg1/ou-ex00-aaaa1111"

Reference: https://docs.aws.amazon.com/cli/latest/reference/controltower/index.html and https://docs.aws.amazon.com/controltower/latest/userguide/setting-up.html

Account Factory

In the AWS Management Console

In AWS Control Tower choose Account Factory, then Create account.
Enter the account email, display name, IAM Identity Center user details and the target OU (for example Workloads).
Choose Create account; provisioning runs through Service Catalog and enrolls the account in the landing zone.
Use Customizations (Account Factory Customization) to attach a blueprint, for example a baseline VPC, so every new account starts identical.

With the AWS CLI

The product behind Account Factory is a Service Catalog product, so accounts are provisioned with Service Catalog. Look up the product and its parameters in your own environment first; the parameter names below are the ones the standard product exposes.

aws servicecatalog provision-product \
  --product-name "AWS Control Tower Account Factory" \
  --provisioning-artifact-name "AWS Control Tower Account Factory" \
  --provisioned-product-name "bookshelf-prod" \
  --provisioning-parameters \
    Key=AccountEmail,Value=aws+bookshelf-prod@example.com \
    Key=AccountName,Value=bookshelf-prod \
    Key=ManagedOrganizationalUnit,Value=Workloads \
    Key=SSOUserEmail,Value=admin@example.com \
    Key=SSOUserFirstName,Value=Ada \
    Key=SSOUserLastName,Value=Admin

Reference: https://docs.aws.amazon.com/controltower/latest/userguide/account-factory.html and https://docs.aws.amazon.com/cli/latest/reference/servicecatalog/provision-product.html

For an existing account, use Enroll account in Control Tower instead; the account must already be an organization member and have the required roles in place. Account Factory for Terraform and customization pipelines are the infrastructure-as-code route; see Infrastructure as Code.

A recommended multi-account strategy

AWS publishes prescriptive guidance for a multi-account layout; the shape most teams converge on is:

OU Typical accounts Purpose

OU	Typical accounts	Purpose
Security	`log-archive`, `audit` (security tooling)	Immutable, centralized logs and the delegated-administrator accounts for security services. Few people have access.
Infrastructure	`network`, `shared-services`	Shared networking (Transit Gateway, DNS), CI/CD tooling and artifact registries used by every workload.
Workloads	One account per application and environment, such as `bookshelf-dev`, `bookshelf-prod`	Application resources. Separate non-production and production, either as sub-OUs or by account naming.
Sandbox	Per-person experiment accounts	Loosest guardrails but strict budget limits and regular clean-up.
Policy staging / Suspended	Test accounts for new SCPs; closed or quarantined accounts	Safe place to rehearse policy changes and to park accounts awaiting closure.

Security

log-archive, audit (security tooling)

Immutable, centralized logs and the delegated-administrator accounts for security services. Few people have access.

Infrastructure

network, shared-services

Shared networking (Transit Gateway, DNS), CI/CD tooling and artifact registries used by every workload.

Workloads

One account per application and environment, such as bookshelf-dev, bookshelf-prod

Application resources. Separate non-production and production, either as sub-OUs or by account naming.

Sandbox

Per-person experiment accounts

Loosest guardrails but strict budget limits and regular clean-up.

Policy staging / Suspended

Test accounts for new SCPs; closed or quarantined accounts

Safe place to rehearse policy changes and to park accounts awaiting closure.

Guidelines that keep this manageable:

Attach guardrails to OUs, never to individual accounts, so a new account inherits them the moment it is moved.
Keep the management account almost empty. Use delegated administration for security, networking and identity services.
Aim for one account per workload and environment; do not share a production account between unrelated teams.
Use IAM Identity Center for human access to all accounts, with permission sets assigned to groups, as described in Identity and Access.
Automate account creation (Account Factory or an API-driven pipeline) so every account gets the same baseline of logging, networking and budgets.
Treat the org structure itself as code or at least as reviewed change; moving an account between OUs changes its effective guardrails immediately.

Reference: https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html

Related governance services — Config, Security Hub, GuardDuty and others — are covered in Governance, Security and Compliance, and logs and trails in Monitoring and Observability.

Centralized root access

Every member account is born with a root user that has a password and, once set, MFA to maintain. At fleet scale this is a liability: dozens of long-lived root credentials to protect. Centralized root access lets the management account (or a delegated administrator for IAM) remove the root credentials from member accounts and perform the few tasks that need root through short-lived, task-scoped privileged sessions instead, available since late 2024. Older guides that tell you to give every account its own root MFA device describe the pre-2024 approach, which is still needed for the management account and any account not using the feature.

Supported privileged tasks include deleting a misconfigured S3 bucket policy or SQS queue policy that denies everyone, and removing or re-enabling the root user’s credentials. Newly created member accounts have no root credentials when the feature is on.

In the AWS Management Console

In the IAM console of the management account open Root access management.
Choose Enable and turn on both Root credentials management and Privileged root actions in member accounts.
Select a member account and choose Delete root user credentials to remove its password, keys and MFA, or Take privileged action for an S3 or SQS policy fix.

With the AWS CLI

# Enable the two capabilities (run in the management account or as the IAM delegated administrator)
aws iam enable-organizations-root-credentials-management
aws iam enable-organizations-root-sessions

# Start a short-lived privileged session scoped to one task; use a Regional STS endpoint
aws sts assume-root \
  --target-principal 111122223333 \
  --task-policy-arn arn=arn:aws:iam::aws:policy/root-task/IAMDeleteRootUserCredentials \
  --duration-seconds 900 \
  --region us-east-1

Reference: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-enable-root-access.html and https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user-privileged-task.html

The caller needs the sts:AssumeRoot permission; restrict which tasks it may perform with the sts:TaskPolicyArn condition key. The root user of the management account itself is not covered, so keep strong MFA on it as described in Getting Started with AWS.

Tagging

A tag is a key/value pair on a resource. Tags drive cost allocation, ownership, access control (attribute-based access control with aws:ResourceTag and aws:PrincipalTag conditions) and automation (backup selection, patch groups). Unlike an Azure resource group, an AWS account is not tagged "down" onto its resources: tags are not inherited by child resources, and an account tag does not appear on the resources inside it unless you apply it there.

A workable strategy is small and enforced:

Tag key Example value Used for

Tag key	Example value	Used for
`Project`	`bookshelf`	Cost allocation and grouping
`Environment`	`dev`, `prod`	Policy and cost splits by stage
`Owner`	`bookshelf-team`	Who to contact; budget alerts
`CostCenter`	`cc-1234`	Chargeback

Project

bookshelf

Cost allocation and grouping

Environment

dev, prod

Policy and cost splits by stage

Owner

bookshelf-team

Who to contact; budget alerts

CostCenter

cc-1234

Chargeback

Keys are case sensitive, so environment and Environment are different tags; choose one convention and let a tag policy enforce it. Each resource has a limit on the number of tags, and keys and values have length and character limits; check the Tagging best practices guide. Never place secrets or personal data in tags: they appear in billing data and many APIs. The aws: key prefix is reserved for AWS.

Tag policies

A tag policy defines the approved keys, their capitalization, and optionally allowed values and the resource types to which the rule applies. It reports non-compliance; by default it does not block creation, but for supported types you can add enforced_for so that non-compliant tag writes are rejected.

{
  "tags": {
    "Environment": {
      "tag_key": { "@@assign": "Environment" },
      "tag_value": { "@@assign": ["dev", "test", "prod"] },
      "enforced_for": { "@@assign": ["ec2:instance", "s3:bucket"] }
    }
  }
}

Reference: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html

In the AWS Management Console

In AWS Organizations choose Policies, then Tag policies, and enable the type if needed.
Choose Create policy, define the tag key, allowed values and enforced resource types, and create it.
Attach it to the root or an OU under the policy’s Targets tab.
Review compliance in Resource Groups & Tag Editor, under Tag Policies, for each account.

With the AWS CLI

aws organizations enable-policy-type --root-id "$ROOT_ID" --policy-type TAG_POLICY

TAG_POLICY_ID=$(aws organizations create-policy \
  --name bookshelf-tags \
  --description "Approved Environment tag values" \
  --type TAG_POLICY \
  --content file://tag-policy.json \
  --query 'Policy.PolicySummary.Id' --output text)

aws organizations attach-policy --policy-id "$TAG_POLICY_ID" --target-id "$ROOT_ID"

# Organization-wide compliance report to an S3 bucket (run in the management account)
aws resourcegroupstaggingapi start-report-creation \
  --s3-bucket bookshelf-tag-reports-111122223333

Reference: https://docs.aws.amazon.com/cli/latest/reference/resourcegroupstaggingapi/start-report-creation.html

Tag Editor, Resource Groups and cost allocation tags

Tag Editor (part of AWS Resource Groups) searches resources across Regions and resource types in one account and adds, edits or removes tags in bulk, which is the console answer to fixing tags on resources you have already created. Resource Groups build a saved, queryable group from a tag filter or a CloudFormation stack and are the supported way to give an application a view across services; they replace the retired myApplications grouping for new work. The Resource Groups Tagging API gives the same cross-service view from the CLI. EC2 Global View shows VPCs, subnets, instances, volumes and security groups for all Regions in a single console page, useful to find forgotten resources.

A tag only appears in billing reports after you activate it as a cost allocation tag in the Billing and Cost Management console, using the management account in an organization; it then shows in Cost Explorer and the Cost and Usage Report from the activation date onward.

In the AWS Management Console

Open Resource Groups & Tag Editor, then Tag Editor. Choose Regions and resource types and optionally a tag filter, then Search resources.
Select the resources, choose Manage tags of selected resources, add Project=bookshelf and review.
For billing, open Billing and Cost Management, then Cost allocation tags, select the keys and choose Activate.
For a cross-Region inventory, open EC2 Global View from the EC2 console.

With the AWS CLI

# Find resources by tag across services in the current Region
aws resourcegroupstaggingapi get-resources \
  --tag-filters Key=Project,Values=bookshelf \
  --query 'ResourceTagMappingList[].ResourceARN' --output text

# Tag several resources at once (ARNs are placeholders)
aws resourcegroupstaggingapi tag-resources \
  --resource-arn-list \
    arn:aws:s3:::bookshelf-uploads-111122223333 \
    arn:aws:ecs:us-east-1:111122223333:cluster/bookshelf \
  --tags Project=bookshelf,Environment=dev

# See which tag keys are in use
aws resourcegroupstaggingapi get-tag-keys

# Activate a cost allocation tag (management account; Cost Explorer API in us-east-1)
aws ce update-cost-allocation-tags-status \
  --cost-allocation-tags-status TagKey=Project,Status=Active \
  --region us-east-1

Reference: https://docs.aws.amazon.com/cli/latest/reference/resourcegroupstaggingapi/index.html and https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html

Reference: https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html

Cross-account access

Accounts do not trust each other by default. Reaching one account from another works through IAM roles (assume role) or resource-based policies, and the organization gives you shortcuts: the aws:PrincipalOrgID and aws:PrincipalOrgPaths condition keys let a bucket or KMS key policy say "any principal in my organization" without listing account ids; OrganizationAccountAccessRole lets the management account administer a member account it created; and trusted service access lets an AWS service (CloudTrail, Config, IAM Identity Center) operate across all accounts.

# Allow Security Hub administration to be delegated to the audit account (placeholder id)
aws organizations register-delegated-administrator \
  --account-id 111122223333 \
  --service-principal securityhub.amazonaws.com

# List which member accounts are delegated administrators
aws organizations list-delegated-administrators \
  --query 'DelegatedAdministrators[].[Name,Id]' --output table

Reference: https://docs.aws.amazon.com/cli/latest/reference/organizations/register-delegated-administrator.html and https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services.html

Most services require you to enable trusted access first (aws organizations enable-aws-service-access, or the service’s own console flow) before delegation works. The role-assumption flow is shown in Identity and Access.

Pricing, limits and recent changes

Pricing. AWS Organizations has no additional charge. Control Tower has no additional charge either; the Config rules, CloudTrail, S3 log storage and other resources it creates are billed at their normal rates, and detective controls multiply Config evaluations as you add accounts and Regions. Consolidated billing itself is free.
Quotas. Accounts per organization, OU nesting depth (five), SCP size, direct SCP attachments per target and the number of policies are all capped; some can be raised. Account closure has a rolling-window limit.
Recent changes. Resource control policies and declarative policies are newer than most tutorials; Control Tower landing zone 4.0 added controls-only mode; centralized root access arrived in November 2024; IAM Identity Center is the current name for what older guides call AWS SSO.
Outdated guidance. Guides that create a separate IAM user with long-lived keys in every account, that use a single account for everything, or that treat Control Tower as a fixed template, no longer match current practice.

Reference: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_reference_limits.html

Clean up

Everything on this page is reversible except account closure, so clean up in dependency order and keep what you want to retain. Most of these resources cost nothing on their own, but accounts, Config rules and logs created by Control Tower do incur charges through the services they use.

Remove resources you created inside the member accounts (stacks, buckets, clusters). Empty versioned S3 buckets before deleting them.

Detach and delete policies you tested:

aws organizations detach-policy --policy-id "$POLICY_ID" --target-id "$SANDBOX_OU"
aws organizations delete-policy --policy-id "$POLICY_ID"
aws organizations detach-policy --policy-id "$TAG_POLICY_ID" --target-id "$ROOT_ID"
aws organizations delete-policy --policy-id "$TAG_POLICY_ID"

Delete the tag report bucket and revert cost allocation tag activation if you do not want them:

aws ce update-cost-allocation-tags-status \
  --cost-allocation-tags-status TagKey=Project,Status=Inactive --region us-east-1

Remove centralized root access if it was only a test, with aws iam disable-organizations-root-sessions and aws iam disable-organizations-root-credentials-management.
Close the test member accounts. Closing is initiated from the management account, accounts stay suspended for a post-closure period, and the number you can close in a rolling window is limited:
```
aws organizations close-account --account-id "$DEV_ACCOUNT_ID"
```

Move or remove the remaining accounts from the OU, then delete the empty OUs:

aws organizations delete-organizational-unit --organizational-unit-id "$SANDBOX_OU"

If you set up a Control Tower landing zone, use Decommission landing zone (console) or aws controltower delete-landing-zone first. This removes the Control Tower resources but does not close the accounts; the Log Archive and Audit accounts and their buckets must be cleaned up separately.
To dissolve the organization, remove every member account (an account must have its own payment method and contact details to leave) and then, from the management account, run aws organizations delete-organization.

Reference: https://docs.aws.amazon.com/cli/latest/reference/organizations/close-account.html, https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_delete.html and https://docs.aws.amazon.com/controltower/latest/userguide/decommission-landing-zone.html

References

Getting started with AWS
Identity and access
Governance, security and compliance
Cost management and support
Infrastructure as code
Azure resource organization for the Azure equivalent

Accounts and Organizations

Why more than one account

AWS Organizations

Creating an organization

In the AWS Management Console

With the AWS CLI

Creating and moving member accounts

In the AWS Management Console

With the AWS CLI

Consolidated billing

Organization policies

Service control policies

Resource control policies

Enabling and attaching policies

In the AWS Management Console

With the AWS CLI

AWS Control Tower

Setting up a landing zone

In the AWS Management Console

With the AWS CLI

Account Factory

In the AWS Management Console

With the AWS CLI

A recommended multi-account strategy

Centralized root access

In the AWS Management Console

With the AWS CLI

Tagging

Tag policies

In the AWS Management Console

With the AWS CLI

Tag Editor, Resource Groups and cost allocation tags

In the AWS Management Console

With the AWS CLI

Cross-account access

Pricing, limits and recent changes

Clean up

References

Related pages