ベストプラクティスの AWS 環境を確立する

マルチアカウントの AWS 環境を設定する必要があるのはなぜですか?

AWS を使用すると、最も柔軟で安全なクラウド環境を提供しながら、より迅速に実験、革新、およびスケールを実行できます。AWS では、アプリケーションのセキュリティを確保するための重要な手段として AWS アカウントを使用しています。AWS アカウントは、AWS リソースに自然なセキュリティ、アクセス、請求の境界を提供するとともに、リソースの独立性と分離を実現することを可能にします。例えば、アカウント外のユーザーは、デフォルトではリソースにアクセスできません。同様に、消費する AWS リソースのコストはアカウントに割り当てられます。単一のアカウントで AWS ジャーニーを開始することもできますが、ワークロードの規模と複雑さの増大に伴って、AWS では複数のアカウントを設定することをお勧めします。マルチアカウント環境を使用することは AWS のベストプラクティスであり、いくつかの恩恵を受けることができます。

さまざまな要件に対応した迅速なイノベーション – AWS アカウントを社内のさまざまなチーム、プロジェクト、または製品に割り当てて、それぞれが独自のセキュリティ要件を考慮しながら迅速にイノベーションを推進できるようにすることができます。
簡素化された請求 – 複数の AWS アカウントを使用すると、AWS の料金を発生させている製品またはサービスラインの特定が容易になります。これにより、AWS のコストを割り当てる方法を簡素化できます。
柔軟なセキュリティコントロール – 複数の AWS アカウントを使用して、特定のセキュリティ要件を持つワークロードやアプリケーション、また HIPAA や PCI などのコンプライアンスに関する厳格なガイドラインの要件を満たす必要があるワークロードやアプリケーションを分離できます。
ビジネスプロセスに簡単に適応 – 運用、規制、予算の要件が異なる企業のビジネスプロセスの多様なニーズを最もよく反映する方法で、複数の AWS アカウントを簡単に整理できます。

最終的に、マルチアカウント AWS 環境では、安全でスケーラブルかつ回復力のある方法を採用しながら、クラウドでより高速に作業を進め、差別化された製品やサービスを構築できます。しかし、どのようにマルチアカウント AWS 環境を構築すればよいでしょうか? 使用するアカウント構造、実装する必要のあるポリシーとガードレール、監査用の環境を設定する方法などについて、疑問が生じる場合があるかもしれません。

このガイドの残りの部分では、安全で生産的なマルチアカウント AWS 環境を構築するための要素について説明します。よく、AWS が推奨する「ランディングゾーン」と呼ばれることがあります。これは、AWS ワークロードの時間の経過に伴う増加に引き続き柔軟に対応できるようにしながら、初期フレームワークを構築するために使用できるベストプラクティスを表しています。

マルチアカウント AWS 環境を設定するためのベストプラクティス

Well-Architected マルチアカウント AWS 環境の基盤となっているのは AWS Organizations です。これは、複数のアカウントを一元的に管理および統制することを可能にする AWS のサービスです。開始する前に、いくつかの用語を理解しましょう。組織単位 (OU) は、AWS Organization 内のアカウントの論理的なグループです。OU を使用すると、アカウントを階層に編成し、管理のためのコントロールを簡単に適用できるようになります。AWS Organizations のポリシーは、そのようなコントロールを適用するために使用するものです。サービスコントロールポリシー (SCP) は、組織内のアカウントが実行できる AWS のサービスのアクション (Amazon EC2 Run Instance など) を定義するポリシーです。

まず、作成する必要のあるアカウントグループまたは OU を検討します。OU は、会社の報告体制を反映するのではなく、機能または共通の一連のコントロールに基づいている必要があります。AWS では、セキュリティとインフラストラクチャを念頭に置いて開始することをお勧めします。ほとんどの企業には、これらのニーズに対応するために組織全体にサービスを提供する一元化されたチームがあります。そのため、これらの特定の機能のための基本的な一連の OU を作成することをお勧めします。

インフラストラクチャ: ネットワークや IT サービスなどの共有インフラストラクチャサービスに使用されます。必要なインフラストラクチャサービスの種類ごとにアカウントを作成します。
セキュリティ: セキュリティサービスに使用されます。ログアーカイブ、セキュリティ読み取り専用アクセス、セキュリティツール、および Break Glass 用のアカウントを作成します。

ほとんどの企業が本番ワークロードについて異なるポリシー要件を満たす必要があることから、インフラストラクチャとセキュリティは、非本番 (SDLC) と本番 (Prod) 向けのネストされた OU を持つことができます。SDLC OU のアカウントは非本番ワークロードをホストするため、他のアカウントからの本番依存関係を有するべきではありません。ライフサイクルステージ間で OU ポリシーが異なる場合、SDLC を複数の OU (dev と pre-prod など) に分割できます。Prod OU のアカウントは、本番ワークロードをホストします。

OU レベルでポリシーを適用して、要件に応じて Prod および SDLC 環境を統制します。一般的に、OU レベルでのポリシーの適用は、ポリシー管理と潜在的なトラブルシューティングを簡素化できるため、個々のアカウントレベルにおける場合よりも優れた方法です。

中心となるサービスを導入したら、製品またはサービスの構築または実行に直接関連する OU を作成することをお勧めします。AWS のお客様の多くは、基盤を確立した後にこれらの OU を構築します。

サンドボックス: 個々のデベロッパーが AWS のサービスを試すために使用できる AWS アカウントを保持します。これらのアカウントを内部ネットワークから確実にデタッチできるようにし、使い過ぎないように支出を制限するプロセスを設定します。
ワークロード: 外部向けのアプリケーションサービスをホストする AWS アカウントが含まれます。本番ワークロードを分離して厳密に制御するには、SDLC および Prod 環境 (基本的な OU と同様) で OU を構築する必要があります。

基本的な OU と本番指向の OU の両方が確立されたので、特定のニーズに応じて、メンテナンスと継続的な拡張のために OU をさらに追加することをお勧めします。既存の AWS のお客様の慣習に基づくいくつかの共通のテーマを以下に示します。

ポリシーのステージング: 提案されたポリシーの変更を組織に広く適用する前にテストできる AWS アカウントを保持します。目的の OU で、アカウントレベルで変更を実装することから始めます。その後、他のアカウント、OU、および組織の残りの部分全体で徐々に変更を実装していきます。
保留中: 閉鎖され、組織から削除されるのを待機している AWS アカウントが含まれます。すべてのアクションを拒否する SCP をこの OU にアタッチします。アカウントを復元する必要がある場合は、追跡可能性のために、確実に詳細がアカウントにタグ付けされているようにしてください。
個々のビジネスユーザー: ビジネス生産性関連のアプリケーションを作成する場合がある (デベロッパーではない) ビジネスユーザーの AWS アカウントを含む制限付きアクセス OU。例えば、パートナーとレポートやファイルを共有するために S3 バケットを設定します。
例外: ワークロード OU で定義されているものとは異なり、高度にカスタマイズされたセキュリティまたは監査要件を満たす必要があるビジネスユースケースに使用される AWS アカウントを保持します。例えば、秘密の新しいアプリケーションまたは機能専用に AWS アカウントを設定します。カスタマイズされたニーズに対応するため、アカウントレベルで SCP を使用します。CloudWatch Events および AWS Config Rules を使用して、Detect and React システムを設定することを検討してください。
デプロイ: CI/CD デプロイメント用の AWS アカウントが含まれています。ワークロード OU (Prod および SDLC) のアカウントと比較して CI/CD デプロイのガバナンスおよび運用モデルが異なる場合は、この OU を作成できます。CI/CD のディストリビューションは、中心的なチームが運営する共有 CI/CD 環境への組織の依存を減らすのに役立ちます。ワークロード OU 内にあるアプリケーション用の SDLC/Prod AWS アカウントの各セットについて、デプロイ OU の下に CI/CD のアカウントを作成します。
移行: これは、既存のアカウントとワークロードを組織の標準領域に移動する前の一時的な保持領域として使用されます。理由としては、アカウントが買収の一部である、以前にサードパーティーによって管理されていた、または古い組織構造のレガシーアカウントであることなどが考えられます。

まとめ

Well-Architected マルチアカウント戦略は、セキュリティとスケーラビリティのニーズを確実に満たしながら、AWS でより迅速にイノベーションを実現するのに役立ちます。このページに記載のフレームワークは、AWS ジャーニーの開始点として使用すべき AWS のベストプラクティスを表しています。