【Guidelines】Considerations for Introducing AWS Organizations to Corporate Structure/Systems

Created date: 2025/05/05, Update date: 2025/05/05

When building an AWS environment, it has become common to use a multi-account structure to separate environments, permissions, and AWS usage costs.
By using AWS Organizations, you can centrally manage AWS accounts.
This article provides an overview of AWS Organizations and points to check when considering its introduction.

Table of Contents

What is AWS Organizations?
Considerations for Adoption
Design Considerations
Related Documents

What is AWS Organizations?

AWS Organizations is a service for centrally managing multiple AWS accounts.
It simplifies resource sharing, policy management, and access control across AWS accounts.

Considerations for Adoption

① What is the account model (contract type) of your AWS account?

Before using AWS Organizations, it is important to check the account model (contract type) and confirm whether the management account features are available.
The main account models (contract types) are “Direct Contract” and “Reseller Contract”.
With a “Direct Contract” with AWS, the account owner has full control over all resources. This allows you to maximize the use of all AWS Organizations features.
In contrast, with a “Reseller Contract,” the reseller has partial control. Some AWS Organizations features may be restricted, so confirmation is necessary.
Related materials:
- AWS Control Tower Best Practices for AWS Solution Providers | AWS Partner Network (APN) Blog

② Will you use AWS Control Tower?

AWS Control Tower is an AWS-managed service that deploys security and compliance governance on AWS Organizations.
By using AWS Control Tower, you can centralize security policies and account management for the entire organization, improving operational efficiency.
However, you should consider costs and features before implementation.
For more information about AWS Control Tower, please refer to the following article on this blog:

【Design Guideline】Considerations for Introducing AWS Control Tower to Corporate Structure/Systems

As part of security measures for AWS environments in organizations, it has become common to establis ... [Read more]

Related materials:
- How AWS Control Tower works - AWS Control Tower

AWS Support Plans provide technical support from AWS experts.
Business and Developer Support Plans are billed per account. Support is only available for accounts registered with a support plan, so if you use multiple AWS accounts for testing, you may need to subscribe to a support plan for each account.
If you only subscribe to the Developer Support Plan for one AWS account for testing, you may want to consider not using AWS Organizations immediately to reduce running costs.
Related materials:
- AWS Support Plans

Design Considerations

1. Organizing the Actors Involved

When formulating the design of Organizations, it is important to clarify the roles of stakeholders within the organization.
Refer to the table below for the roles of the actors involved, and use this organization of actors in “3. Consideration of AWS Account Access Policy” and other sections of this page.
- Based on Best Practices for Standardization Guideline Formulation | Amazon Web Services Blog .
  Note: The related materials linked above are written in Japanese.
- In some organizations, the four actors—CCoE, Common Platform Admin, Security, and Accounting/Finance—may be handled by the same department or person.

No	Actor	Role	Tasks
01	CCoE	Promotes and operates cloud usage	Develops guidelines
02	Common Platform Admin	Provides cross-system common platforms/functions	Builds and operates common platforms
03	Security	Maintains security in the cloud environment	Defines security policies, builds/operates security functions, monitors security
04	System Admin	Builds/operates systems running on the cloud	Builds/operates AWS resources and systems
05	Operations	Manages operations in the cloud environment	Monitors and operates systems
06	Accounting/Finance	Allocates and optimizes AWS usage costs	Considers cost allocation, purchase options, monitors costs, pays AWS fees

② Consider AWS account structure

Consider how to divide “common accounts” and “individual accounts”.

Common Accounts

Functions (AWS services) used by “common accounts” include:
- Only AWS service names are listed, but SaaS, AD, WSUS, etc. may also be provided as common functions.

No	Category	Common AWS Account Name	Representative AWS Services
01	Identity and Access Management	Bastion, ID Management	AWS IAM, AWS IAM Identity Center
02	Detective Controls	Audit, Security Monitoring	AWS SecurityHub, AWS Cloudrail, AWS Config, Amazon GuardDuty, Amazon EventBridge
03	Network Infrastructure Protection	Common Network, External Connection	AWS Transit Gateway, AWS Direct Connect, AWS Network Firewall
04	Data Protection	Log Management	Amazon S3
05	Monitoring	System Monitoring	Amazon CloudWatch, Amazon EventBridge, Amazon SNS, AWS User Notifications
06	Infrastructure Provisioning (CI/CD)	CI/CD	AWS CodeCommit, AWS CodePipeline, AWS CodeBuild, AWS CodeDeploy
07	Operations Management	Operations Management	AWS Systems Manager
08	Cost Management	Management Account *1	AWS Budgets, AWS Cost Explorer, AWS Cost Anomaly Detection

*1: As of July 11, 2023, cost management information for individual accounts can only be viewed by the management account.

In AWS Control Tower, “Identity and Access Management (Bastion)” is the management account, “Detective Controls (Security Monitoring)” is the audit account, and “Data Protection (Log Management)” is the log archive account.
- Reference: About AWS accounts in AWS Control Tower - AWS Control Tower
If you provide other categories as common functions, consider creating dedicated common accounts.
First, consider which common functions to adopt, then in “③ AWS Account Access Policy Consideration” organize who will access them and consider account division.

Individual Accounts

Consider dividing “individual accounts” based on the following perspectives:
- As additional perspectives not listed below, such as “system billing destination” and “AWS resource quotas,” may also be considered, but dividing AWS accounts too much will make management complicated, so it is not recommended.

System: Divide by system to separate resources for each system.
Environment: Divide by environment such as production, test, development. Separating production and non-production environments enhances production security.
Control: For large systems, you may divide further for management reasons.

③ Consider OU structure

In AWS Organizations, AWS accounts can be managed in a hierarchical structure called OUs.
OU design should be optimized for your organization, but start with a basic OU structure and customize as needed.
The following article describes best practices for OU design:
- Reference: Best Practices for Organizational Units with AWS Organizations | AWS Cloud Operations Blog
The article introduces the following basic OU structure:
- In AWS Control Tower, only the Security OU is created by default, but consider creating other OUs as needed.

OU Name	Considerations for Subdivision	Required/Optional	Purpose
Security	Production or Non-production	Required	Stores AWS accounts related to security
Infrastructure	Production or Non-production	Optional	Stores shared infrastructure AWS accounts
Sandbox	-	Optional	Stores AWS accounts for PoC or AWS learning
Workloads	Production/Non-production, System Name	Required	Stores AWS accounts providing software lifecycle

Consider creating the following OUs as needed:

OU Name	Required/Optional	Purpose
Policy Staging	Optional	Stores AWS accounts for testing SCPs and guardrails
Suspended	Optional	Stores suspended AWS accounts
IndividualBusinessUsers	Optional	Stores AWS accounts for business users
Exceptions	Optional	Stores AWS accounts assigned exceptional security policies
Deployments	Optional	Stores AWS accounts for CI/CD

④ Organize which AWS accounts each actor accesses

At this stage, organize which people access which AWS accounts.
The following table is an example of organizing which actors access which AWS accounts.
- This is just an example; organize according to your organization.

Actor	1.ID Mgmt	2.Audit	3.Common Network	4.Log Mgmt	5.System Monitoring	6.CI/CD	7.Operations Mgmt	8.Management	a.Production System	b.Non-production System
CCoE	RW	RW	RW	R	RW	RW	RW	RW	RW	RW
Common Platform Admin	RW	R	RW	R	RW	RW	RW	R	R	R
Security	-	R	RW	R	-	-	-	-	RW	RW
System Admin	-	-	-	-	RW	RW	RW	-	RW	RW
Operations	-	-	-	-	RW	RW	RW	-	RW	RW
Accounting/Finance	-	-	-	-	-	-	-	-	R	R

If the actors accessing “1.ID Mgmt” to “8.Management” common accounts are the same, consider consolidating AWS accounts.
- For example, in the table above, “5.System Monitoring,” “6.CI/CD,” and “7.Operations Mgmt” are accessed by the same actors, so consider consolidating them into one AWS account.

⑤ Organize operational items

The following three operational items are organized below.

AWS Account Creation/Deletion
- Consider who will create/delete AWS accounts and the workflow for creation.
- For AWS resources provided at account creation, allow selection in the application form if optional.
Service Control Policy Creation/Modification/Deletion
- Consider who will create/modify/delete service control policies applied to individual accounts and the workflow for doing so.
Use/Update of Root User
- Consider the workflow for using the root user in cases where it is required.
- AWS account root user - AWS Identity and Access Management
- There was a case where the root user of an individual account could not be logged in, and AWS Support was contacted via the management account, but AWS Support requested contact from the management account’s root user, not an IAM user.
- This is an irregular case, but ensure that the root user can be used when needed.

What is AWS Organizations? - AWS Organizations