AWS AWS Control Tower ランディングゾーンのマルチアカウント戦略 - AWS Control Tower
AWS マルチアカウントガイダンスへの準拠アーキテクチャが適切に設計された環境をセットアップするためのガイドライン完全なマルチアカウント OU 構造を持つ AWS Control Tower の例ルートについて

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

AWS AWS Control Tower ランディングゾーンのマルチアカウント戦略

AWS Control Tower のお客様は、最良の結果を得るために AWS 環境とアカウントを設定する方法に関するガイダンスを求めることがよくあります。AWS では、AWS Control Tower ランディングゾーンを含む AWS リソースを最大限に活用できるように、マルチアカウント戦略 と呼ばれる一連の統合レコメンデーションを作成しました。

基本的に、AWS Control Tower は他の AWS サービスと連携するオーケストレーションレイヤーとして機能します。これにより、 AWS アカウントと の AWS マルチアカウントレコメンデーションを実装できます AWS Organizations。AWS Control Tower は、ランディングゾーンをセットアップした後も、複数のアカウントとワークロードにわたって企業のポリシーとセキュリティプラクティスを維持する場合に役立ちます。

ほとんどのランディングゾーンは時間の経過と共に拡大します。AWS Control Tower ランディングゾーン内の組織単位 (OU) とアカウントの数が増加するのに合わせて、ワークロードを効果的に編成できるように AWS Control Tower のデプロイを拡張できます。この章では、 AWS マルチアカウント戦略に沿って AWS Control Tower ランディングゾーンを計画およびセットアップし、時間の経過と共に拡張する方法について規範的なガイダンスを提供します。

組織単位のベストプラクティスに関する一般的な説明については、「 を使用した組織単位のベストプラクティス AWS Organizations」を参照してください。

AWS マルチアカウント戦略: ベストプラクティスガイダンス

AWS アーキテクチャが適切に設計された環境の ベストプラクティスでは、リソースとワークロードを複数の AWS アカウントに分けることをお勧めします。 AWS アカウントは独立したリソースコンテナと考えることができます。ワークロードを分類する機能と、問題が発生した場合の影響範囲を小さくする機能を備えています。

AWS アカウントの定義

AWS アカウントは、リソースコンテナおよびリソース分離境界として機能します。

注記

AWS アカウントは、フェデレーションまたは AWS Identity and Access Management (IAM) によってセットアップされるユーザーアカウントとは異なります。

AWS アカウントの詳細

AWS アカウントは、リソースを分離し、 AWS ワークロードのセキュリティ脅威を隔離する機能を提供します。また、請求のメカニズムと、ワークロード環境を管理するためのメカニズムも備えています。

AWS アカウントは、ワークロードにリソースコンテナを提供する主要な実装メカニズムです。環境が適切に設計されている場合は、複数の AWS アカウントを効果的に管理できるため、複数のワークロードと環境を管理できます。

AWS Control Tower は、アーキテクチャが適切に設計された環境をセットアップします。 AWS アカウントと に依存し AWS Organizations、複数のアカウントにまたがる環境への変更を管理するのに役立ちます。

アーキテクチャが適切に設計された環境の定義

AWS は、Well-Architected 環境をランディングゾーンで始まる環境として定義します。

AWS Control Tower には、自動的にセットアップされるランディングゾーンがあります。これにより、環境内の複数のアカウントにわたって企業ガイドラインが確実に遵守されるようにコントロールが適用されます。

ランディングゾーンの定義

ランディングゾーンは、デフォルトアカウント、アカウント構造、ネットワーク、セキュリティレイアウトなど、推奨される開始点を提供するクラウド環境です。ランディングゾーンから、ソリューションとアプリケーションを利用するワークロードをデプロイできます。

アーキテクチャが適切に設計された環境をセットアップするためのガイドライン

次のセクションで説明するように、アーキテクチャが適切に設計された環境には次の 3 つの主要なコンポーネントがあります。

  • 複数の AWS アカウント

  • 複数の組織単位 (OU)

  • よく計画された構造

複数の AWS アカウントの使用

アーキテクチャが適切に設計された環境をセットアップするには、1 つのアカウントでは不十分です。複数のアカウントを使用することで、セキュリティ目標とビジネスプロセスを最適にサポートできます。マルチアカウントアプローチを使用する利点は次のとおりです。

  • セキュリティコントロール - アプリケーションによってセキュリティプロファイルが異なるため、アプリケーションごとに異なるコントロールポリシーとメカニズムが必要です。例えば、監査人と話をして、ペイメントカード業界 (PCI) ワークロードをホストしている単一のアカウントを参照した方がはるかに簡単です。

  • 分離 - アカウントは、セキュリティ保護の単位です。潜在的なリスクとセキュリティの脅威は、他のユーザーに影響を与えることなく、アカウント内に封じ込めることができます。したがって、セキュリティのニーズによっては、アカウントを互いに分離する必要があります。例えば、チームによってセキュリティプロファイルが異なる場合を考えてみます。

  • 多数のチーム — チームごとに責任とリソースニーズが異なります。複数のアカウントをセットアップすることで、同じアカウントを使用することがあっても、チームが互いに干渉することはありません。

  • データの分離 - データストアとアカウントを分離することで、データにアクセスしてデータストアを管理できるユーザーの数を制限できます。この分離により、高度にプライベートなデータの不正漏洩を防ぐことができます。例えば、データを分離すると、一般データ保護規則 (GDPR) の遵守をサポートできます。

  • ビジネスプロセス - ビジネス単位または製品によって目的とプロセスがまったく異なることがよくあります。ビジネス固有のニーズに合わせて個々のアカウントを確立できます。

  • 請求 - 転送料金など請求レベルで項目を分けるには、アカウントが唯一の方法です。マルチアカウント戦略は、ビジネス単位、職務チーム、または個々のユーザー間で個別に請求対象項目を作成する場合に役立ちます。

  • クォータ割り当て — AWS クォータはアカウントごとに設定されます。アカウントごとにワークロードを分けると、明確に定義された個別のクォータが各アカウント (プロジェクトなど) に与えられます。

複数の組織単位の使用

AWS Control Tower およびその他のアカウントオーケストレーションフレームワークでは、アカウント境界を越えて変更を加えることができます。したがって、 AWS ベストプラクティスはクロスアカウントの変更に対処します。これにより、環境が破損したり、セキュリティが損なわれたりする可能性があります。場合によっては、変更の影響がポリシーを超えて環境全体に及ぶことがあります。そのため、少なくとも本番稼働とステージングという 2 つの必須アカウントをセットアップすることをお勧めします。

さらに、ガバナンスと制御の目的で、 AWS アカウントは多くの場合、組織単位 (OUsにグループ化されます。OU は、複数のアカウントにわたるポリシーの適用を処理するように設計されています。

最低でも、個別のコントロールとポリシーを使用して、本番稼働環境とは別に本番稼働前 (またはステージング) 環境を作成することをお勧めします。本番稼働環境およびステージング環境は、個別の OU として作成して管理し、個別のアカウントとして請求できます。また、コードのテスト用にサンドボックス OU をセットアップすることをお勧めします。

ランディングゾーンでの OU 向けに適切に計画された構造の使用

AWS Control Tower では、いくつかの OU が自動的にセットアップされます。ワークロードと要件が時間の経過と共に拡大するのに伴い、ニーズに合わせて当初のランディングゾーン設定を拡張できます。

注記

例で示されている名前は、マルチアカウント AWS 環境を設定するための推奨 AWS 命名規則に従います。ランディングゾーンのセットアップ後に OU の名前を変更するには、OU の詳細ページで [Edit] (編集) を選択します。

レコメンデーション

AWS Control Tower で最初の必須の OU (セキュリティ OU) をセットアップした後、ランディングゾーンに追加の OU をいくつか作成することをお勧めします。

AWS Control Tower でサンドボックス OU と呼ばれる追加の OU を少なくとも 1 つ作成できるようにすることをお勧めします。この OU は、ソフトウェア開発環境用です。サンドボックス OU のセットアップを選択していれば、AWS Control Tower がランディングゾーンの作成時にセットアップします。

ユーザー自身がセットアップできるその他の推奨される OU が 2 つあります。共有サービスとネットワークアカウントが含まれるインフラストラクチャ OU と、本番稼働用ワークロードが含まれるワークロード OU です。AWS Control Tower コンソールから [Organizational units] (組織単位) ページで他の OU をランディングゾーンに追加できます。

自動的にセットアップされるものを除く推奨される OU

  • インフラストラクチャ OU - 共有サービスとネットワークアカウントが含まれます。

    注記

    AWS Control Tower は、インフラストラクチャ OU を自動的にセットアップしません。

  • サンドボックス OU - ソフトウェア開発 OU。例えば、この OU は使用量に固定制限がある場合や、本番稼働ネットワークに接続されていない場合があります。

    注記

    AWS Control Tower ではサンドボックス OU をセットアップすることをお勧めします。ただし、これは任意です。ランディングゾーン設定の一環として、自動的にセットアップできます。

  • ワークロード OU - ワークロードを実行するアカウントが含まれます。

    注記

    AWS Control Tower は、ワークロード OU を自動的にセットアップしません。

詳細については、「Production starter organization with AWS Control Tower」(AWS Control Tower を使用して作成された本番稼働用スターター組織) を参照してください。

完全なマルチアカウント OU 構造を持つ AWS Control Tower の例

AWS Control Tower はネストされた OU 階層をサポートしています。つまり、組織の要件を満たす階層 OU 構造を作成できます。 AWS マルチアカウント戦略のガイダンスと一致する AWS Control Tower 環境を構築できます。

また、 AWS マルチアカウントガイダンスに従って適切に機能するシンプルでフラットな OU 構造を構築することもできます。階層 OU 構造を構築できるからといって、必ずそうしなければならないわけではありません。

リンク先のページにある図表は、他にも多くの基礎 OU と追加 OU が作成されていることを示しています。これらの OU は、大規模にデプロイする場合に追加で求められるニーズに対応します。

基礎 OU 列では、次の 2 つの OU が基本構造に追加されています。

  • Security_Prod OU - セキュリティポリシーの読み取り専用領域と、ブレークグラスのセキュリティ監査領域を提供します。

  • インフラストラクチャ OU - 以前に推奨されていたインフラストラクチャ OU を Infrastructure_Test (本番稼働前のインフラストラクチャ用) と Infrastructure_Prod (本番稼働のインフラストラクチャ用) の 2 つの OU に分けることをお勧めします。

追加 OU 領域では、基本構造にさらにいくつかの OU が追加されています。環境の拡大に合わせて次に作成することが推奨されている OU は以下のとおりです。

  • ワークロード OU - ワークロード OU は、以前は推奨されていましたが、現在は任意となった OU です。Workloads_Test (本番稼働前のワークロード用) と Workloads_Prod (本番稼働のワークロード用) の 2 つの OU に分離されました。

  • PolicyStaging OU – システム管理者は、コントロールとポリシーの変更を完全に適用する前にテストできます。

  • 停止 OU - 一時的に無効になっている可能性のあるアカウント用のロケーションを提供します。

ルートについて

ルートは OU ではありません。ルートとは、管理アカウント、および組織内のすべての OU とアカウントのコンテナです。概念的には、ルートにはすべての OU が含まれます。ルートは削除できません。AWS Control Tower 内のルートレベルでは、登録済みアカウントを管理することはできません。代わりに、OU 内の登録済みアカウントを管理します。役立つ図については、「」の AWS Organizations ドキュメントを参照してください。