AWS Organizations を使用した組織単位 (OU) のベストプラクティス
組織単位 (OU) を使用して、AWS Organizations でマルチアカウント環境を管理する手順は、以下の事項に従って行うことをおすすめします。
AWS Organizations を理解する
適切に設計されたマルチアカウント AWS 環境の基盤は AWS Organizations です。これにより、複数のアカウントを一元的に管理および管理できます。組織単位 (OU) は、組織内のアカウントの論理的なグループ化です。OU を使用すると、アカウントを階層に整理し、管理コントロールを適用できます。Organizations ポリシーは、AWS アカウントのグループに適用できるコントロールを定義します。例えば、サービスコントロールポリシー (SCP) は、組織内のアカウントが実行できる AWS のサービスのアクション (Amazon EC2 Run Instance など) を定義するポリシーです。
AWS では、1 つのアカウントから始めるかもしれませんが、AWS では、ワークロードの規模や複雑さに応じて、複数のアカウントを設定することをお勧めしています。マルチアカウント環境を使用することは、いくつかの利点を提供する AWS のベストプラクティスです。
さまざまな要件を備えた迅速なイノベーション: 社内のさまざまなチーム、プロジェクト、製品に AWS アカウントを割り当てて、それぞれのセキュリティ要件を許容しながら、迅速にイノベーションを行うことができます。
請求の簡素化: 複数の AWS アカウントを使用すると、AWS 料金の原因となっている製品やサービスのラインを特定できるため、AWS コストの配分が簡単になります。
柔軟なセキュリティコントロール: 複数の AWS アカウントを使用して、特定のセキュリティ要件を持つワークロードやアプリケーションを分離したり、HIPAA や PCI などのコンプライアンスの厳格なガイドラインを満たす必要のあるワークロードやアプリケーションを分離することができます。
ビジネスプロセスへの適応: 運用上、規制上、予算上の要件が異なる会社のビジネスプロセスの多様なニーズを最もよく反映した方法で、複数の AWS アカウントを整理できます。
推奨される基本組織単位 (OU)
組織単位 (OU) は、会社のレポート構造をミラーリングするのではなく、関数または一般的な一連のコントロールに基づいている必要があります。AWS では、セキュリティとインフラストラクチャを念頭に置いて開始することをお勧めします。ほとんどのビジネスには、これらのニーズに応じて組織全体に対応する一元化されたチームがあります。これらの特定の機能のために、一連の基礎的な OU を作成することをお勧めします。
セキュリティ: セキュリティサービスに使用されます。ログアーカイブ、セキュリティ読み取り専用アクセス、セキュリティツール、ブレークグラスのアカウントを作成します。
インフラストラクチャ: ネットワークや IT サービスなどの共有インフラストラクチャサービスに使用されます。必要なインフラストラクチャサービスのタイプごとにアカウントを作成します。
ほとんどの企業では、本番稼働ワークロードのポリシー要件が異なるため、インフラストラクチャとセキュリティには、非本番稼働 (SDLC) と本番稼働 (Prod) 用のネストされた OU がある可能性があります。SDLC OU のアカウントは非本番ワークロードをホストし、他のアカウントからの本番依存関係があってはなりません。ライフサイクルステージ間で OU ポリシーにばらつきがある場合、SDLC は複数の OU (開発や事前生産など) に分割できます。Prod OU のアカウントは、本番ワークロードをホストします。
OU レベルでポリシーを適用して、要件に従って Prod 環境と SDLC 環境を管理します。一般に、ポリシー管理と潜在的なトラブルシューティングを簡素化するため、OU レベルでポリシーを適用する方が、個々のアカウントレベルよりも実践的です。
次の図は、セキュリティとインフラストラクチャの基本的な OU (Prod と SDLC) を示しています。
推奨される追加の組織単位 (OU)
中央サービスが導入されたら、製品やサービスの構築または実行に直接関連する OU を作成することをお勧めします。多くの AWS のお客様は、基盤を確立した後、次の OU を 構築します。
サンドボックス: 個々のデベロッパーが AWS のサービスを試すために使用できる AWS アカウントを保持します。これらのアカウントを内部ネットワークからデタッチできることを確認します。
ワークロード: 外部向けアプリケーションサービスをホストする AWS アカウントが含まれます。本番環境ワークロードを分離して厳密に制御するには、SDLC および Prod 環境 (基盤 OU に似ています) の下に OU を構成する必要があります。
また、特定のニーズに応じて、メンテナンスと継続的な拡張のために OU を追加することをお勧めします。以下は、既存の AWS 顧客のプラクティスに基づく一般的なテーマです。
ポリシーステージング: 提案されたポリシー変更を組織全体に適用する前にテストできる AWS アカウントを保持します。まず、目的の OU のアカウントレベルで変更を実装し、他のアカウント、OU、および組織全体で徐々に作業します。
停止: 閉じられ、組織から削除されるのを待っている AWS アカウントが含まれます。すべてのアクションを拒否する SCP をこの OU にアタッチします。アカウントを復元する必要がある場合は、トレーサビリティの詳細がタグ付けされていることを確認してください。
個々のビジネスユーザー: ビジネス生産性関連のアプリケーションを作成する必要があるビジネスユーザー (デベロッパーではない) 向けの AWS アカウントを含むアクセス制限された OU。たとえば、レポートやファイルをパートナーと共有するために S3 バケットをセットアップします。
例外: ワークロード OU で定義されているものとは異なる、高度にカスタマイズされたセキュリティまたは監査要件を持つビジネスユースケースに使用される AWS アカウントを保持します。例えば、機密の新しいアプリケーションまたは機能用に AWS アカウントを特別にセットアップします。カスタマイズされたニーズを満たすために、アカウントレベルで SCP を使用します。Amazon EventBridge と AWS Config ルールを使用して、Detect and React システムを設定することを検討してください。
デプロイ: 継続的統合と継続的配信/デプロイ (CI/CD デプロイ) のための AWS アカウントが含まれています。この OU は、ワークロード OU (Prod および SDLC) のアカウントとは異なる CI/CD デプロイのガバナンスモデルと運用モデルがある場合に作成できます。CI/CD の配布は、中央チームが運用する共有 CI/CD 環境への組織的な依存を減らすのに役立ちます。ワークロード OU 内のAWS アカウントアプリケーションの SDLC/Prod のセットごとに、デプロイ OU の下に CI/CD のアカウントを作成します。
移行: これは、既存のアカウントとワークロードを組織の標準エリアに移動する前の、一時的な保持エリアとして使用されます。これは、アカウントが取得の一部であり、以前はサードパーティーによって管理されていたか、古い組織構造のレガシーアカウントが原因である可能性があります。
次の図は、サンドボックス、ワークロード、ポリシーステージング、一時停止、個々のビジネスユーザー、例外、デプロイ、移行アカウントの追加の OU を示しています。
結論
適切に設計されたマルチアカウント戦略は、セキュリティとスケーラビリティのニーズを満たすと同時に、AWS でのイノベーションに役立ちます。このトピックで説明されているフレームワークは、AWS ジャーニーの開始点として使用すべき AWS ベストプラクティスを示しています。
次の図は、推奨される基本 OU と追加の OU を示しています。
