【Richtlinien】Überlegungen zur Einführung von AWS-Organisationen in die Unternehmensstruktur/-systeme

📅 Erstellt: 2025/05/05, Aktualisiert: 2025/05/05 ⏱️ Geschätzte Lesezeit ~8 mins (1,357 Wörter)

Beim Aufbau einer AWS-Umgebung ist es üblich geworden, eine Struktur mit mehreren Konten zu verwenden, um Umgebungen, Berechtigungen und AWS-Nutzungskosten zu trennen.
Durch die Verwendung von AWS Organizations können Sie AWS-Konten zentral verwalten.
Dieser Artikel bietet einen Überblick über AWS Organizations und Punkte, die bei der Überlegung zur Einführung überprüft werden sollten.

Inhaltsverzeichnis

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 streamlines resource sharing, policy management, and access control across AWS accounts.

Considerations for Adoption

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

Before using AWS Organizations, make sure to check your account model (contract type) and confirm whether management account features are available .
The main account models are “Direct Contract” and “Reseller Contract.”
With a “Direct Contract” with AWS, the account owner has full control over all resources, allowing you to take full advantage of all AWS Organizations features.
In contrast, with a “Reseller Contract,” the reseller retains partial control. Some AWS Organizations features may be restricted, so you need to confirm what is available.
Related resources:
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 using AWS Organizations.
By using AWS Control Tower, you can centralize security policies and account management for your entire organization, improving operational efficiency.
However, be sure to consider the costs and features before implementation.
For more information about AWS Control Tower, see the following article on this blog:

【Designrichtlinie】Überlegungen zur Einführung von AWS Control Tower in die Unternehmensstruktur/-systeme

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

Related resources:
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 right away to reduce ongoing costs.
Related resources:
AWS Support Plans

Design Considerations

1. Organizing the Stakeholders

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

No	Stakeholder	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