hidekazu-konishi.com

AWS History and Timeline regarding AWS Organizations - Overview, Functions, Features, Summary of Updates, and Introduction

First Published: 2026-05-31
Last Updated: 2026-05-31

This is another installment in the series that I started with the "AWS History and Timeline - Almost All AWS Services List, Announcements, General Availability(GA)", where I extract features from the history and timeline of AWS services (I've previously written about Amazon S3, AWS IAM, AWS KMS, AWS CloudFormation, and AWS Systems Manager, among others).

This time, I have created a historical timeline for AWS Organizations, the account-level governance service that turns a collection of separate AWS accounts into a single, centrally managed and policy-governed organization.
Just like before, I am summarizing the main features while following the birth of AWS Organizations and tracking its feature additions and updates as a "Current Overview, Functions, Features of AWS Organizations".
This article focuses on the major, service-level milestones of AWS Organizations — the introduction of the service, each new policy type, the feature-set and account-scale changes, and the governance primitives such as trusted access and delegated administration. It deliberately does not attempt to list every minor console update or every single service that has added trusted access over the years. AWS Control Tower and Account Factory are treated here as adjacent services whose relationship to AWS Organizations is clarified, not as topics covered in depth.

The reason AWS Organizations is worth a dedicated timeline is that it sits underneath almost every modern multi-account design: the organization root, organizational units (OUs), and member accounts are the canvas on which Service Control Policies, Resource Control Policies, tag policies, backup policies, and the rest of the policy family are painted. Understanding when each of those guardrails arrived explains why multi-account operational patterns look the way they do today. For the operational side of that story, see AWS Multi-Account Operational Patterns.

Background and Method of Creating AWS Organizations Historical Timeline

This time, the reason for creating a historical timeline of AWS Organizations is that since AWS Organizations was announced in preview at re:Invent 2016 and made Generally Available in February 2017, it has steadily accumulated new policy types and governance capabilities on top of an unchanged core model of management account, OUs, and member accounts. The single guardrail type at launch (Service Control Policies) has since been joined by tag policies, backup policies, AI services opt-out policies, chat applications policies, Resource Control Policies, declarative policies, Security Hub policies, Amazon Inspector policies, and Aurora/RDS upgrade rollout policies — leaving today's cloud governance team with a notably broader policy surface to reason about. Therefore, I decided to organize the information of AWS Organizations with the following approaches.

• Tracking the history of AWS Organizations and organizing the transition of updates
• Summarizing the feature list and characteristics of AWS Organizations
• Clarifying the boundary between AWS Organizations itself and the adjacent services that build on it (AWS Control Tower, AWS IAM Identity Center), which are essential context for any multi-account design but are not part of the AWS Organizations service surface

This timeline primarily references the following blogs and document history regarding AWS Organizations.

• What's New with AWS?
• AWS News Blog
• AWS Cloud Operations Blog
• Document history for AWS Organizations

There may be slight variations in the dates on the timeline due to differences in the timing of announcements or article postings in the references used. For example, a feature's "What's New" announcement date and the corresponding documentation-update date sometimes differ by a few days.
The content posted is limited to major features related to the current AWS Organizations and necessary for the feature list and overview description.
In other words, please note that the items on this timeline are not all updates to AWS Organizations features, but are representative updates that I have picked out.
AWS Organizations was first announced in preview at AWS re:Invent 2016 and then announced as Generally Available on February 27, 2017. The history of AWS Organizations is therefore approaching a decade at the time of writing this article.

AWS Organizations Historical Timeline (Updates from February 27, 2017)

Now, from here is the timeline regarding the features of AWS Organizations. AWS Organizations was first offered in preview at re:Invent 2016 (November 2016), and then announced as Generally Available on February 27, 2017.

* You can sort the table by clicking on the column name.

Date	Summary
2016-11-29	AWS Organizations is announced in preview at AWS re:Invent 2016. It introduces policy-based management for multiple AWS accounts and Service Control Policies (SCP) as its first guardrail type, and it absorbs the formerly standalone Consolidated Billing feature. References: Announcing AWS Organizations, Now in Preview
2017-02-27	AWS Organizations is announced as Generally Available (GA), together with Service Control Policies (SCP). After a roughly three-month preview, GA delivered organizational units (OUs), the ability to invite or create member accounts from the console, CLI, and API, and two feature sets — "Consolidated Billing features" and "All features" (the latter required for SCPs). Existing Consolidated Billing customers were migrated into an organization. References: AWS Organizations - Policy-Based Management for Multiple AWS Accounts
2017-12-07	AWS Organizations adds support for AWS Single Sign-On (AWS SSO, later renamed AWS IAM Identity Center). AWS SSO materializes permission sets as IAM roles in member accounts of an organization, becoming the workforce front door for multi-account access. References: AWS Documentation(AWS IAM Identity Center User Guide)
2018-03-29	Trusted access for AWS services is introduced. The management account can enable trusted access so that other AWS services operate across the organization using service-linked roles; AWS SSO (IAM Identity Center) was the first supported trusted service. References: Enable Trusted Organization Access in AWS Organizations
2018-11-19	AWS CloudTrail adds support for an organization trail across AWS Organizations. A single organization trail can log events for every account in the organization, and in the same re:Invent 2018 timeframe AWS Resource Access Manager (RAM) launched for cross-account resource sharing within an organization — both early examples of services building on AWS Organizations trusted access. References: AWS CloudTrail Now Supports Trails Across an Organization
2019-03-25	Service Control Policies gain support for resources, conditions, and the NotAction element. SCPs become far more expressive, allowing fine-grained deny guardrails scoped by resource ARN and request condition across an OU or account. References: Service control policies enable fine-grained permission controls
2019-06-06	AWS Organizations adds the ability to tag accounts. Accounts can carry tags such as cost center, environment, and owner, enabling tag-based reporting and attribute-based access control on the organization structure itself. References: AWS Organizations now supports tagging and untagging of AWS accounts
2019-06-24	AWS Control Tower becomes Generally Available and integrates with AWS Organizations. Control Tower automates a multi-account landing zone on top of Organizations (OUs, guardrails, Account Factory, and centralized logging). It is an adjacent orchestration layer, not part of AWS Organizations itself. References: AWS Control Tower is now generally available
2019-11-20	The aws:PrincipalOrgPaths global condition key is introduced. Complementing aws:PrincipalOrgID, it lets IAM and resource policies match the organizational-unit path of the calling principal, enabling OU-scoped conditions. References: Use IAM to share your AWS resources with groups of AWS accounts in AWS Organizations
2019-11-26	Tag policies are launched, just ahead of AWS re:Invent 2019. A new management policy type standardizes tag keys and allowed values across accounts, with cross-account compliance reporting and optional enforcement of noncompliant tag changes. References: AWS launches Tag Policies
2020-03-30	Delegated administrator support begins to roll out, starting with IAM Access Analyzer. A member account can be registered as the delegated administrator for an integrated service, moving organization-wide administration off the management account — a pattern later extended to Amazon GuardDuty, AWS Security Hub, AWS Config, AWS CloudFormation StackSets, AWS Firewall Manager, and many more. References: Review and remediate unintended access allowed on your AWS resources from outside your AWS organization
2020-06-24	Backup policies and AWS Backup integration are launched. Backup policies attach at the root, an OU, or an account to centrally enforce backup plans — frequency, retention, vault, and Region — across the organization from the management account. References: AWS Backup and AWS Organizations bring cross-account data protection management and monitoring
2020-07-08	AI services opt-out policies are launched. A management policy type controls whether AWS AI services (such as Amazon Rekognition, Amazon Comprehend, Amazon Lex, Amazon Polly, Amazon Textract, Amazon Transcribe, and Amazon Translate) may store and use account content to improve those services, enforced organization-wide instead of per-account support requests. References: Create an opt-out policy for AI services across accounts with AWS Organizations
2020-09-15	AWS Organizations adds tag-on-create and tag-based access control for its own resources. Tags can be applied to Organizations resources at creation time, and IAM policies can restrict access to resources carrying specified tag keys and values, completing tag-based access control on the organization structure. References: AWS Organizations now supports tagging, tag-on-create, and attribute-based access control (ABAC)
2020-10-20	The "master account" is renamed to "management account". This is a terminology change only, with no change in functionality; the management account remains the organization's payer and the owner of the organization root. References: AWS Documentation(AWS Organizations terminology and concepts)
2020-11-18	Backup policies add cross-account backup copies. When backup policies protect resources across the organization, copies of those backups can be stored in other AWS accounts in the organization, hardening recovery against a single-account compromise. References: AWS Documentation(Backup policy syntax and examples)
2020-11-24	AWS Config adds organization-wide resource data aggregation through a delegated administrator account. A registered delegated administrator can aggregate configuration and compliance data from every member account across Regions without additional authorization, an early example of moving organization-wide governance tooling off the management account. References: AWS Config supports organization-wide resource data aggregation from a delegated administrator account
2021-03-10	Backup policies add support for continuous backup. Organization-wide backup policies can enable the AWS Backup continuous-backup feature, extending centralized data protection from periodic snapshots to point-in-time recovery across member accounts. References: AWS Documentation(Backup policy syntax and examples)
2022-03-30	Member accounts can be closed directly from the AWS Organizations console. Principals in the management account can close member accounts and protect them from accidental closure using IAM policies, completing account-lifecycle self-service. References: AWS Organizations enables you to close accounts centrally
2022-07-26	AWS Single Sign-On is renamed to AWS IAM Identity Center. Adjacent to AWS Organizations, it remains the recommended workforce-identity front door, with permission sets continuing to materialize as IAM roles in member accounts; capabilities were unchanged at the rename. References: AWS Single Sign-On (AWS SSO) is now AWS IAM Identity Center
2022-11-27	A member account can be registered as the delegated administrator for managing AWS Organizations policies. Delegated administration is extended from individual integrated services to the organization's own policies — Service Control Policies, tag policies, backup policies, and AI services opt-out policies can now be created and attached from a designated member account instead of the management account. References: Announcing delegated administrator for AWS Organizations
2023-02-14	AWS Organizations adds centralized management of opt-in AWS Regions for member accounts. The management account can enable or disable opt-in Regions across all member accounts programmatically, instead of signing in to each account, tightening control over where the organization is allowed to operate. References: Programmatically manage enabled and disabled opt-in AWS Regions on AWS accounts
2023-11-16	The aws:SourceOrgID and aws:SourceOrgPaths global condition keys are introduced. Resource-based policies can now require that AWS service-to-service requests originate from within the organization (or a specific OU path), a foundational data-perimeter building block that anticipated the resource-side controls later generalized by Resource Control Policies. References: New organization-wide IAM condition keys to restrict AWS service-to-service requests
2024-06-07	The management account can centrally update the root user email address for any member account. Organizations gains the ability to view and change member-account root contact details centrally, reducing the need to sign in to each member account to manage its root user. References: Manage member account root email addresses with AWS Organizations
2024-08-14	The maximum supported organization size is raised to 10,000 member accounts. The maximum number of accounts an organization can contain doubled from the previous ceiling of 5,000 (each still granted through a Service Quotas increase request), reflecting the growth of very large multi-account estates. References: AWS Documentation(Quotas and service endpoints for AWS Organizations)
2024-10-01	Chat applications policies are introduced as a new management policy type. These policies control which chat applications (Slack, Microsoft Teams, Amazon Chime) and which workspaces may access organization accounts; the underlying service, AWS Chatbot, was later renamed Amazon Q Developer in chat applications. References: AWS Chatbot adds support to centrally manage access to AWS accounts from Slack and Microsoft Teams with AWS Organizations
2024-11-13	Resource Control Policies (RCP) are launched as a new authorization policy type. RCPs are the resource-side counterpart to identity-side SCPs, capping the maximum permissions on resources (at launch: Amazon S3, AWS STS, AWS KMS, Amazon SQS, and AWS Secrets Manager) to enforce data-perimeter rules such as "no principal outside the organization can access our resources." Like SCPs, they require "all features" mode and cannot grant permissions. References: Introducing resource control policies (RCPs) to centrally restrict access to AWS resources
2024-11-15	Centralized management of member-account root access is launched. From the management account or a delegated administrator, administrators can remove long-lived root credentials across member accounts and perform tightly scoped, short-lived privileged root actions via the sts:AssumeRoot API. References: Centrally managing root access for customers using AWS Organizations
2024-12-01	Declarative policies are launched at AWS re:Invent 2024. A management policy type declares and continuously enforces a desired baseline configuration for a service across the organization — for example, blocking public access for Amazon VPC and Amazon EBS or enforcing IMDSv2 — and the configuration persists even as the service adds new APIs and as new accounts join. Supported at launch: Amazon EC2, Amazon VPC, and Amazon EBS. References: Amazon Web Services announces declarative policies
2025-06-17	Security Hub policies are added as a new management policy type. Security Hub policies centrally manage AWS Security Hub configuration — enabled standards and controls — across the organization, with accounts inheriting the applicable policy based on their position in the OU hierarchy. References: AWS Documentation(Security Hub policies)
2025-06-19	Resource Control Policies are extended to their first additional services, Amazon ECR and Amazon OpenSearch Serverless. The first post-launch expansion of RCP coverage widened the resource-side data perimeter beyond the five launch services (Amazon S3, AWS STS, AWS KMS, Amazon SQS, and AWS Secrets Manager). References: AWS announces support for additional services in resource control policies (RCPs)
2025-07-22	Tag policies add wildcard statement support. A single tag policy statement can use a wildcard to apply the same rule to all supported resource types of a service (for example, all Amazon EC2 or Amazon S3 resource types), simplifying tag-policy authoring across the organization. References: AWS Organizations tag policies now support wildcard statements
2025-09-15	AWS Organizations adds centralized monitoring of member-account states. The management account can centrally view the state of every account in the organization (such as Active, Suspended, or Closed) from the console, CLI, and SDKs, improving organization-wide account visibility. References: AWS Organizations provides account state information for member accounts
2025-09-19	Service Control Policies gain full IAM policy language support. SCPs reach parity with IAM policy grammar — Allow with conditions and specific resource ARNs, NotResource in Deny statements, and expanded wildcard placement — enabling more concise, precise guardrails while remaining backward compatible with existing SCPs. References: AWS Organizations supports full IAM policy language for service control policies (SCPs)
2025-11-19	Amazon Inspector policies are added as a new management policy type. Inspector policies let the organization centrally configure which Amazon Inspector scan types (Amazon EC2, Amazon ECR, AWS Lambda, and code scanning) are enabled across accounts, with the configuration inherited down the OU hierarchy. References: Amazon Inspector supports organization-wide management through AWS Organizations policies
2025-11-21	An upgrade rollout policy is added as a new management policy type for Amazon Aurora and Amazon RDS. The policy lets the organization stagger automatic minor-version database upgrades across accounts and environments — for example, rolling out to development before production — from a single organization-wide policy. References: AWS Organizations introduces upgrade rollout policy for Amazon Aurora and Amazon RDS
2026-01-22	Resource Control Policies add support for Amazon Cognito and Amazon CloudWatch Logs. RCP coverage continues to grow beyond the launch set, widening the range of resources for which an organization-wide data perimeter can be centrally enforced. References: AWS expands resource control policies (RCPs) to additional services
2026-04-21	Backup policies add support for additional resource types, including Amazon Redshift Serverless namespaces and Aurora DSQL clusters. The continued expansion of backup-policy resource coverage shows AWS Organizations' management policies keeping pace as new database and analytics services ship. References: AWS Organizations backup policies now support Amazon Redshift Serverless and Aurora DSQL

AWS Organizations is one of those AWS services where the core has barely changed while the surface around it has steadily grown. The management account, organization root, organizational units, and member accounts established in 2017 are still the structure today; almost every entry above is either a new policy type attached to that structure or a governance primitive that shifts operational responsibility away from the management account. The next section organizes the resulting feature set as it stands today.

Current Overview, Functions, Features of AWS Organizations

From here, I introduce the current list of AWS Organizations features and overview.
AWS Organizations is a free, global AWS service for consolidating multiple AWS accounts into a single organization that you can centrally manage, govern, and bill. It provides a hierarchy of an organization root, organizational units (OUs), and member accounts, plus a family of policies that attach to that hierarchy to set guardrails and baseline configurations across every account at once.

AWS Organizations Use Cases

The principal use cases of AWS Organizations in current deployments are:

• Consolidating billing for many AWS accounts under a single management (payer) account, with combined volume discounts and shared commitment discounts
• Establishing organization-wide security guardrails with Service Control Policies (SCP) and Resource Control Policies (RCP)
• Grouping accounts into organizational units (OUs) by environment, team, workload, or compliance boundary, and applying policy at the OU level
• Standardizing tagging across accounts with tag policies, and enforcing baseline service configuration with declarative policies
• Centrally managing backups across accounts with backup policies and AWS Backup
• Controlling whether AWS AI services may use account content for service improvement, organization-wide, with AI services opt-out policies
• Delegating administration of organization-wide services (Amazon GuardDuty, AWS Security Hub, AWS Config, IAM Access Analyzer, AWS CloudFormation StackSets, and others) to a dedicated member account instead of the management account
• Providing the account structure on which AWS Control Tower builds an automated, governed landing zone

Specific Examples of Use Cases

• A platform team enforces "deny all actions outside approved Regions" at the organization root using an SCP, so no member account can create resources in unapproved Regions.
• A security team enforces "no resource in the organization may be accessed by a principal outside the organization" using an RCP data perimeter on Amazon S3, AWS KMS, and AWS STS.
• A FinOps team requires a CostCenter tag with a controlled set of values across all accounts using a tag policy, and reports on noncompliant resources.
• A governance team blocks public access for Amazon VPC, Amazon EBS, and Amazon EC2 AMIs across every account with a declarative policy that persists even as new accounts join.
• A compliance team removes long-lived root credentials from hundreds of member accounts using centralized root access, and performs rare privileged tasks through short-lived sts:AssumeRoot sessions.
• A backup administrator applies a single backup policy at an OU so that every account inherits the same backup plan, retention, and cross-account copy rules.
• A central operations account is registered as the delegated administrator for Amazon GuardDuty and AWS Security Hub, so the management account is not used for day-to-day security operations.

The diagram shows the management account on top, owning the organization root, with organizational units and member accounts beneath it. Policies attach at the root, OU, or account level. The management account itself sits outside the governed area because Service Control Policies and Resource Control Policies do not restrict the management account — one of the main reasons AWS recommends keeping workloads out of it.

AWS Organizations Key Functions and Features

• Management account — the account that creates the organization. It is the payer account for consolidated billing, owns the organization root, and is the only account (besides registered delegated administrators) that can enable policy types, invite or create accounts, and manage the organization. AWS best practice is to keep workloads out of the management account.
• Organization root — the top container of the hierarchy. Policies attached here apply to the entire organization.
• Organizational Units (OUs) — containers that group accounts (and can nest), forming the tree where guardrails are applied by environment, team, or compliance boundary.
• Member accounts — the AWS accounts in the organization. They can be invited (existing accounts) or created within the organization, and can be moved between OUs.
• Consolidated billing — a single payer account aggregates the usage of all member accounts, sharing volume pricing and commitment discounts. Organizations superseded the formerly standalone Consolidated Billing feature.
• Feature sets ("Consolidated Billing features" vs "All features") — an organization runs in one of two modes. "All features" mode (the default for new organizations and a prerequisite for SCPs, RCPs, and the other policy types) unlocks the full governance surface; "Consolidated Billing features" mode provides only shared billing.
• Trusted access — the management account can authorize specific AWS services to operate across the organization using service-linked roles (for example, organization CloudTrail trails or AWS Config aggregation).
• Delegated administrator — a member account can be registered to administer an integrated service organization-wide, moving operational duties off the management account.

AWS Organizations Policy Types

AWS Organizations policies fall into two categories: authorization policies (which set maximum permissions) and management policies (which configure or constrain service behavior). The following table summarizes the major policy types and when each became available.

* You can sort the table by clicking on the column name.

Policy Type	Category	Available Since	What It Does
Service Control Policy (SCP)	Authorization	2017-02	Sets the maximum permissions for IAM principals in the affected accounts. SCP cannot grant permissions; it can only cap them.
Resource Control Policy (RCP)	Authorization	2024-11	Sets the maximum permissions on resources in the affected accounts — the resource-side counterpart to identity-side SCPs, used to build data perimeters.
Tag policy	Management	2019-11	Standardizes tag keys and allowed values across accounts, with compliance reporting and optional enforcement.
Backup policy	Management	2020-06	Centrally defines and enforces AWS Backup plans (frequency, retention, vault, Region, cross-account copy) across accounts.
AI services opt-out policy	Management	2020-07	Controls whether AWS AI services may store and use account content for service improvement.
Chat applications policy	Management	2024-10	Controls access to accounts from chat applications such as Slack and Microsoft Teams, and which workspaces are allowed.
Declarative policy	Management	2024-12	Declares and continuously enforces a baseline service configuration (Amazon EC2, Amazon VPC, Amazon EBS) that persists as services and accounts change.
Security Hub policy	Management	2025-06	Centrally manages AWS Security Hub configuration (enabled standards and controls) across accounts.
Amazon Inspector policy	Management	2025-11	Centrally configures which Amazon Inspector scan types (Amazon EC2, Amazon ECR, AWS Lambda, code) are enabled across accounts.
Upgrade rollout policy	Management	2025-11	Staggers automatic minor-version upgrades for Amazon Aurora and Amazon RDS databases across accounts and environments.

How AWS Organizations Policies Are Evaluated

The two policy categories behave differently. Management policies (tag, backup, AI services opt-out, chat applications, declarative, Security Hub, Amazon Inspector, and upgrade rollout policies) are inherited down the OU tree and merged using inheritance operators, so a child policy can refine or extend the effective policy set that it inherits from its parents. Authorization policies (SCPs and RCPs) act as intersection caps: a request is permitted only if the policies at every level of the hierarchy in scope — the root, each OU in the path, and the account — allow it.

Three properties are worth committing to memory:

• Neither SCPs nor RCPs grant permissions. They only set the maximum available permissions; you still grant access with IAM identity-based and resource-based policies. An action must be allowed by both the organization's caps and the account's own policies.
• The default is allow-everything. When you enable SCPs, an AWS managed FullAWSAccess policy is attached to the root and to every OU and account; when you enable RCPs, an RCPFullAWSAccess policy is attached in the same way. Until you attach your own restrictive policy, nothing about your existing permissions changes.
• Allow-list versus deny-list. You can keep FullAWSAccess attached and add deny statements (a deny-list, which is the most common approach), or replace it with an explicit allow-list of permitted actions. An explicit deny anywhere in the path always wins over an allow.

The management account is exempt from SCPs and RCPs, which is the central reason AWS recommends keeping workloads out of it. For how these organization-level caps slot into the broader request-evaluation order alongside identity-based, resource-based, permissions-boundary, and session policies, see AWS History and Timeline regarding AWS IAM and the AWS IAM Glossary.

Delegated Administration and Trusted Access

Originally, every organization-wide service had to be operated from the management account, which conflicted with the best practice of keeping the management account minimally used. Trusted access (2018) lets the management account enable a service to work across the organization, and delegated administration (rolling out from 2020) lets a designated member account perform that service's organization-wide administration. Today, services such as Amazon GuardDuty, AWS Security Hub, AWS Config, IAM Access Analyzer, AWS CloudFormation StackSets, AWS Firewall Manager, and AWS Backup support a delegated administrator, which is why mature landing zones run security and operations tooling from dedicated accounts rather than from the management account.

Account Lifecycle in an Organization

Accounts enter an organization in one of two ways: an existing account is invited and must accept the invitation, or a brand-new account is created directly within the organization. Accounts can be moved between OUs at any time, which immediately changes the policies that apply to them. An invited account can leave the organization, and a created account can be removed by the management account (self-service since 2017). Member accounts can be closed from the AWS Organizations console (2022), and even the management account can be closed following a documented workflow. The management account is special throughout this lifecycle: it is the payer account, it owns the organization root, it is not restricted by SCPs or RCPs, and it cannot be moved into an OU.

Best Practices for the Management Account

• Keep workloads out of the management account. Because it is exempt from SCPs and RCPs, any workload running there operates without those organization-wide guardrails.
• Use delegated administrators for security and operations services (Amazon GuardDuty, AWS Security Hub, AWS Config, IAM Access Analyzer, AWS CloudFormation StackSets, AWS Backup, and others) so that day-to-day administration does not require signing in to the management account.
• Enable centralized root access to remove long-lived root credentials from member accounts and perform the rare privileged actions that still require root through short-lived, task-scoped sessions.
• Test SCPs and RCPs on a non-production OU first. Because they cap permissions organization-wide, an over-broad deny can break many accounts at once; AWS recommends rolling out from a test account upward through the OU hierarchy.
• Attach guardrails at the OU level that matches the intended blast radius rather than attaching everything at the root, so that a change affects only the accounts you mean to govern.

Relationship to AWS Control Tower and AWS IAM Identity Center (Adjacent Services)

AWS Control Tower is built on top of AWS Organizations, but is a separate service. Control Tower automates the setup of a multi-account landing zone — creating OUs, applying guardrails (many implemented as SCPs and, since late 2024, RCPs), provisioning accounts via Account Factory, and centralizing logging — whereas AWS Organizations provides the underlying account hierarchy and the policy mechanisms that Control Tower orchestrates. AWS IAM Identity Center (formerly AWS Single Sign-On) is likewise adjacent: it provides workforce single sign-on into the accounts of an organization by materializing permission sets as IAM roles in member accounts. Neither service is part of the AWS Organizations service surface, but both depend on it. The day-to-day operational patterns that combine these services are described in AWS Multi-Account Operational Patterns.

Integration with Other AWS Services

Many AWS services consume the organization context that AWS Organizations provides:

• AWS IAM evaluates SCPs and RCPs as part of its policy-evaluation pipeline, and exposes organization condition keys such as aws:PrincipalOrgID, aws:PrincipalOrgPaths, and aws:ResourceOrgID. The evaluation order is detailed in AWS History and Timeline regarding AWS IAM and the AWS IAM Glossary.
• AWS CloudTrail can create an organization trail that logs events for every account from the management account.
• AWS Config aggregates configuration and compliance data organization-wide, often through a delegated administrator.
• AWS Backup uses backup policies to apply backup plans across the organization.
• AWS Resource Access Manager (RAM) shares resources across accounts within the organization without bilateral resource policies.
• AWS Control Tower builds the landing zone, and AWS IAM Identity Center federates workforce access, as described above.
• Tag policies underpin the organization-wide tagging strategy described in the AWS Tagging Strategy Complete Guide, and the overall governance posture maps to the controls in the AWS Well-Architected Practical Checklist.

Frequently Asked Questions about AWS Organizations History

The following are direct answers to the most common AWS Organizations history and feature questions. Each answer is intentionally short so that it can be lifted directly into AI search results and human conversations alike.

When did AWS Organizations launch?

AWS Organizations was announced in preview at AWS re:Invent 2016 (November 2016) and was announced as Generally Available on February 27, 2017. At GA it introduced organizational units, account invite and create via console, CLI, and API, and Service Control Policies, and it superseded the standalone Consolidated Billing feature.

What are Service Control Policies (SCP) and when did they arrive?

Service Control Policies are AWS Organizations' first guardrail type, available from the 2017 GA. An SCP is an authorization policy that sets the maximum permissions for IAM principals in the affected accounts — it can only cap permissions, never grant them. SCPs gained resources, conditions, and NotAction support in March 2019, and reached full IAM policy language parity in September 2025.

What is "all features" mode in AWS Organizations?

An organization runs in one of two feature sets. "Consolidated Billing features" mode provides only shared billing, while "all features" mode unlocks the full governance surface — SCPs, RCPs, tag policies, backup policies, and the other policy types all require "all features" mode. "All features" is the default for newly created organizations.

When did tag policies, backup policies, and AI services opt-out policies launch?

Tag policies launched on November 26, 2019, just ahead of re:Invent 2019. Backup policies, together with AWS Backup integration, launched on June 24, 2020. AI services opt-out policies launched on July 8, 2020. All three are management policies that attach to the organization root, an OU, or an account.

When did AWS Organizations add delegated administrator support?

Delegated administration began rolling out per service in 2020 — IAM Access Analyzer was among the first to support a delegated administrator (March 2020) — and has since expanded to many services including Amazon GuardDuty, AWS Security Hub, AWS Config, AWS CloudFormation StackSets, and AWS Backup. It lets a member account, rather than the management account, run an organization-wide service.

When did Resource Control Policies (RCP) and declarative policies launch?

Resource Control Policies launched on November 13, 2024, as the resource-side counterpart to identity-side SCPs (supported at launch on Amazon S3, AWS STS, AWS KMS, Amazon SQS, and AWS Secrets Manager). Declarative policies launched on December 1, 2024 at re:Invent 2024, enforcing a desired baseline configuration for Amazon EC2, Amazon VPC, and Amazon EBS that persists as services and accounts change.

How does AWS Organizations relate to AWS Control Tower?

AWS Control Tower is a separate service built on top of AWS Organizations. Control Tower automates a governed multi-account landing zone (OUs, guardrails, Account Factory, centralized logging), while AWS Organizations provides the account hierarchy and the policy mechanisms (SCPs, RCPs, and others) that Control Tower applies. You can use AWS Organizations without Control Tower, but Control Tower always uses AWS Organizations underneath.

Summary

This article extracted the history of AWS Organizations from its preview at re:Invent 2016 and GA in February 2017, through trusted access (2018) and more expressive Service Control Policies (2019), the arrival of tag policies (2019), backup policies and AI services opt-out policies (2020), the "master account" to "management account" rename (2020), delegated administration extended to the organization's own policies and the data-perimeter condition keys aws:SourceOrgID and aws:SourceOrgPaths (2022–2023), the jump to 10,000 accounts and chat applications policies (2024), the re:Invent 2024 wave of Resource Control Policies, centralized root access, and declarative policies, and on to Security Hub, Amazon Inspector, and Aurora/RDS upgrade rollout policies and full IAM language support for SCPs in 2025.

The most striking feature of the AWS Organizations timeline is that the core has stayed constant — a management account, an organization root, organizational units, and member accounts — while almost every major addition has arrived as a new policy type layered onto that structure, or as a governance primitive (trusted access, delegated administration, centralized root access) that moves operational duties off the management account. The result is that designing multi-account governance today is largely a question of choosing the right policy type at the right level of the OU hierarchy: SCP for identity-side caps, RCP for resource-side data perimeters, tag and declarative policies for baseline configuration, and backup, AI opt-out, chat applications, Security Hub, Amazon Inspector, and upgrade rollout policies for service-specific management.

For the operational patterns that sit on top of this structure, see AWS Multi-Account Operational Patterns; for how Organizations guardrails fit into the IAM evaluation order, see AWS History and Timeline regarding AWS IAM and the AWS IAM Glossary; and for the tagging and governance context, see the AWS Tagging Strategy Complete Guide and the AWS Well-Architected Practical Checklist.

In addition, there is also a historical timeline of all AWS services including services other than AWS Organizations, so please have a look if you are interested.

AWS History and Timeline - Almost All AWS Services List, Announcements, General Availability(GA)

This timeline will be updated as AWS Organizations continues to evolve.

References:
AWS Documentation(AWS Organizations User Guide)
AWS Documentation(Document history for AWS Organizations)
AWS Documentation(Managing policies in AWS Organizations)
AWS Documentation(Service control policies)
AWS Documentation(Resource control policies)
What's New with AWS?
AWS News Blog
AWS Cloud Operations Blog

References:
Tech Blog with curated related content