AWS Control Tower ランディングゾーンに対する AWS マルチアカウント戦略 - AWS Control Tower

AWS Control Tower ランディングゾーンに対する AWS マルチアカウント戦略

AWS 環境とアカウントをどのようにセットアップすれば最良の結果が得られるのか、AWS Control Tower のお客様から助言を求められることがよくあります。AWS では、AWS Control Tower ランディングゾーンなどの リソースを最大限に活用するために役立つレコメンデーションが「マルチアカウント戦略」という名称でまとめられています。AWS

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

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

組織単位のベストプラクティスに関する全般的な説明については、「Best Practices for Organizational Units with AWS Organizations」(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 では、アーキテクチャが適切に設計された環境をランディングゾーンで始まる環境であると定義しています。

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

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

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

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

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

  • 複数の AWS アカウント

  • 複数の組織単位 (OU)

  • よく計画された構造

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

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

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

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

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

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

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

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

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

複数の組織単位の使用

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

また、管理と制御の目的で AWS アカウントを組織単位 (OU) にグループ化することもよくあります。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 を自動的にセットアップしません。

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

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

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

  • AWS マルチアカウントガイダンスに従って広範でフラットな AWS Control Tower 環境に構築された一連の OU の例を示す図表については、「Example: Workloads in a Flat OU Structure」 (例: フラットな OU 構造のワークロード) を参照してください。

  • AWS Control Tower でネストされた OU 構造を使用する方法の詳細については、「AWS Control Tower のネストされた OU」を参照してください。

  • AWS Control Tower が AWS ガイダンスをどのように遵守しているかについては、AWS ホワイトペーパーの「Organizing Your AWS Environment Using Multiple Accounts」 (複数のアカウントを使用した AWS 環境の編成) を参照してください。

リンク先のページにある図表は、他にも多くの基礎 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 に分離されました。

  • ポリシーステージング OU - システム管理者はガードレールとポリシーに対する変更をテストしてからそれらを完全に適用できます。

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

ルートについて

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