翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# で組織単位 (OUsを管理するためのベストプラクティス AWS Organizations
<a name="orgs_manage_ous_best_practices"></a>

組織単位 (OUs) AWS Organizations を使用して でマルチアカウント環境を管理する手順については、以下の推奨事項に従ってください。

**Topics**
+ [について AWS Organizations](#ous_best_practices_intro)
+ [推奨される基本 OU](#ous_best_practices_foundational)
+ [推奨される追加の OU](#ous_best_practices_recommended)
+ [結論](#ous_best_practices_conclusion)

## について AWS Organizations
<a name="ous_best_practices_intro"></a>

適切に設計されたマルチアカウント AWS 環境の基盤は です。これにより AWS Organizations、複数のアカウントを一元的に管理できます。組織単位 (OU) は、組織内のアカウントの論理的なグループ化です。OU を使用すると、アカウントを階層に整理し、管理コントロールを適用できます。Organizations [ポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies.html)は、グループに適用できるコントロールを定義します AWS アカウント。たとえば、[サービスコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCP) は、組織内のアカウントが実行できる Amazon EC2 Run Instance などの AWS のサービス アクションを定義するポリシーです。

1 つのアカウントで AWS ジャーニーを開始する場合がありますが、 では、ワークロードのサイズと複雑さが大きくなるにつれて、複数のアカウントを設定する AWS ことをお勧めします。マルチアカウント環境を使用することは、いくつかの利点をもたらす AWS ベストプラクティスです。
+ **さまざまな要件を伴う迅速なイノベーション**: 社内のさまざまなチーム、プロジェクト、製品 AWS アカウント に を割り当てて、それぞれのセキュリティ要件を考慮しながら、各チームを迅速にイノベーションさせることができます。
+ **請求の簡素化**: 複数の を使用すると AWS アカウント 、 AWS 料金を負担する製品やサービスのラインを特定できるため、 AWS コストの割り当て方法を簡素化できます。
+ **柔軟なセキュリティコントロール**: 複数の を使用して AWS アカウント 、特定のセキュリティ要件を持つワークロードやアプリケーションを分離したり、HIPAA や PCI などのコンプライアンスの厳格なガイドラインを満たす必要があります。
+ **ビジネスプロセスへの適応**: 運用 AWS アカウント 要件、規制要件、予算要件が異なる会社のビジネスプロセスの多様なニーズを最もよく反映した方法で複数の を整理できます。

## 推奨される基本組織単位 (OU)
<a name="ous_best_practices_foundational"></a>

組織単位 (OU) は、会社のレポート構造をミラーリングするのではなく、関数または一般的な一連のコントロールに基づいている必要があります。 AWS では、セキュリティとインフラストラクチャを念頭に置いて開始することをお勧めします。ほとんどのビジネスには、これらのニーズに応じて組織全体に対応する一元化されたチームがあります。これらの特定の機能のために、一連の基礎的な OU を作成することをお勧めします。
+ **セキュリティ**: セキュリティサービスに使用されます。ログアーカイブ、セキュリティ読み取り専用アクセス、セキュリティツール、ブレークグラスのアカウントを作成します。
+ **インフラストラクチャ**: ネットワークや IT サービスなどの共有インフラストラクチャサービスに使用されます。必要なインフラストラクチャサービスのタイプごとにアカウントを作成します。

ほとんどの企業では、本番稼働ワークロードのポリシー要件が異なるため、インフラストラクチャとセキュリティには、*非本番*稼働 (SDLC) と*本番稼働* (Prod) 用のネストされた OU がある可能性があります。SDLC OU のアカウントは非本番ワークロードをホストし、他のアカウントからの本番依存関係があってはなりません。ライフサイクルステージ間で OU ポリシーにばらつきがある場合、SDLC は複数の OU (開発や事前生産など) に分割できます。Prod OU のアカウントは、本番ワークロードをホストします。

OU レベルでポリシーを適用して、要件に従って Prod 環境と SDLC 環境を管理します。一般に、ポリシー管理と潜在的なトラブルシューティングを簡素化するため、OU レベルでポリシーを適用する方が、個々のアカウントレベルよりも実践的です。

次の図は、セキュリティとインフラストラクチャの基本的な OU (Prod と SDLC) を示しています。

![\[このイメージは、セキュリティとインフラストラクチャの基礎 OU (Prod と SDLC) を表示します。\]](http://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/images/foundational-OUs.png)


## 推奨される追加の組織単位 (OU)
<a name="ous_best_practices_recommended"></a>

中央サービスが導入されたら、製品やサービスの構築または実行に直接関連する OU を作成することをお勧めします。多くの AWS お客様は、基盤を確立した後に次の OUs を構築します。
+ **サンドボックス**: 個々のデベロッパー AWS アカウント が実験に使用できるものを保持します AWS のサービス。これらのアカウントを内部ネットワークからデタッチできることを確認します。
+ **ワークロード**: 外部向けアプリケーションサービスをホスト AWS アカウント する が含まれます。本番環境ワークロードを分離して厳密に制御するには、SDLC および Prod 環境 (基盤 OU に似ています) の下に OU を構成する必要があります。

また、特定のニーズに応じて、メンテナンスと継続的な拡張のために OU を追加することをお勧めします。以下は、既存の AWS お客様のプラクティスに基づく一般的なテーマです。
+ **ポリシーステージング**: 提案されたポリシー変更を組織全体に適用する前にテストできる AWS アカウントを保持します。まず、目的の OU のアカウントレベルで変更を実装し、他のアカウント、OU、および組織全体で徐々に作業します。
+ **停止: **閉じ AWS アカウント られ、組織から削除されるのを待っている が含まれます。すべてのアクションを拒否する SCP をこの OU にアタッチします。アカウントを復元する必要がある場合は、トレーサビリティの詳細がタグ付けされていることを確認してください。
+ **個々のビジネスユーザー**: ビジネス生産性関連のアプリケーションを作成する必要があるビジネスユーザー (デベロッパーではない) AWS アカウント 向けの を含む制限付きアクセス OU。たとえば、レポートやファイルをパートナーと共有するための S3 バケットを設定します。
+ **例外**: ワークロード OU で定義されているものとは異なる、高度にカスタマイズされたセキュリティ要件または監査要件を持つビジネスユースケース AWS アカウント に使用されるホールド。たとえば、機密の新しいアプリケーションまたは機能用に AWS アカウント を特別にセットアップします。カスタマイズされたニーズを満たすために、アカウントレベルで SCP を使用します。[Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) と [AWS Config ルール](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)を使用して、Detect and React システムを設定することを検討してください。
+ **デプロイ**: 継続的インテグレーションと継続的デリバリー/デプロイ (CI/CD デプロイ) AWS アカウント を目的としています。この OU は、ワークロード OU (Prod および SDLC) のアカウントとは異なる CI/CD デプロイのガバナンスモデルと運用モデルがある場合に作成できます。CI/CD の配布は、中央チームが運用する共有 CI/CD 環境への組織的な依存を減らすのに役立ちます。ワークロード OU 内の AWS アカウント アプリケーションの SDLC/Prod のセットごとに、デプロイ OU で CI/CD のアカウントを作成します。
+ **移行**: これは、既存のアカウントとワークロードを組織の標準エリアに移動する前の、一時的な保持エリアとして使用されます。これは、アカウントが取得の一部であり、以前はサードパーティーによって管理されていたか、古い組織構造のレガシーアカウントが原因である可能性があります。

次の図は、サンドボックス、ワークロード、ポリシーステージング、一時停止、個々のビジネスユーザー、例外、デプロイ、移行アカウントの追加の OU を示しています。

![\[このイメージには、サンドボックス、ワークロード、ポリシーステージング、一時停止、個々のビジネスユーザー、例外、デプロイ、移行アカウントの追加の OU が表示されます。\]](http://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/images/additional-OUs.png)


## 結論
<a name="ous_best_practices_conclusion"></a>

適切に設計されたマルチアカウント戦略は、セキュリティとスケーラビリティのニーズを満たすのに役立つと同時に AWS、イノベーションにも役立ちます。このトピックで説明するフレームワークは、 AWS ジャーニーの開始点として使用する AWS べきベストプラクティスを示しています。

次の図は、推奨される基本 OU と追加の OU を示しています。

![\[このイメージには、推奨される基本 OU と追加の OU が表示されます。\]](http://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/images/recommended-OUs.png)