【初心者向け】AWSで実現するマルチアカウント構成について

はじめに

本記事では、シングルアカウント構成のリスクとマルチアカウント構成の必要性を初学者向けに解説します。
またそれに付随して活用できるAWSサービスや考え方についても触れていきます。

なぜマルチアカウント構成が必要なのか

そもそもなぜマルチアカウント構成が必要になるのでしょうか。
たとえば以下のケースでシングルアカウント構成をとった場合を想定します。

開発、本番など複数の環境を運用している
プロジェクトの規模が拡大し、新規プロダクトの開発が必要となった
複数ベンダーが関わる大規模プロジェクトが立ち上がった

すると以下のような問題が発生します。

別環境や別プロダクトのリソースが分離されてない

シングルアカウント構成では異なる環境や異なるプロダクトのリソースが同一アカウント内に存在します。
そのため一方の変更が他方に意図しない影響を与える可能性があります。
たとえば以下の図のように、プロダクトBのリソースを削除するつもりがリソース名の見間違えなどで誤ってプロダクトAのリソースを削除してしまう可能性があります。

missoperation

アクセスポリシー制限が複雑化する

上記のような誤操作を防止するために各ユーザーに適切なアクセス権限を付与します。
しかし複数のプロダクトを同一アカウントで管理する場合、各プロダクトに紐づくユーザーや付与するアクセス権限を適切に設定・維持するための管理が複雑になります。
たとえば以下の図では、ベンダーB用のポリシーに対してプロダクトAのリソースへのアクセス権限が誤って付与されてしまっていた状況を表しています。
ベンダーやプロダクトが増えるほどアクセス権限の制御条件が複雑化し、不必要に広範なアクセス権限が付与されていたことなどが原因で、結果として図のような他プロダクトのリソースへの操作を許してしまうリスクが高まります。

multivendor

コスト管理が大変になる

複数の環境や複数のプロダクトを同一アカウントで運用している場合、どの環境・プロダクトがどれだけのコストを消費しているか把握することが困難になります。
その結果コストの透明性が低下して予算の管理や計画が複雑になったり、リソースの過剰割り当てや使われないリソースの放置が発生したりといったコストの無駄遣いにもつながります。

このような弊害を防止するためにマルチアカウント構成が必要になります。

マルチアカウントを効率よく管理するためには

マルチアカウント構成をさまざまなプロジェクトで採用しはじめると、今度は以下のような問題が発生します。

会社内で利用されているAWSアカウントが全部でどのくらいあるか管理できなくなる
設定者のスキルレベルがバラバラで適切な設定ができているか把握できず、良くない設定が放置される
アカウントごとに請求が発生するため経理処理が煩雑になる
IAMユーザーをアカウントごとに管理しているため、ログイン情報の管理やユーザー作成に手間がかかる

そこでAWSにおけるマルチアカウント戦略の中核となるサービスであるAWS Organizationsを使用することで、複数のAWSアカウントを一元管理でき、マルチアカウント構成における問題を解決できます。

AWS Organizationsとは

AWS Organizationsは、複数のAWSアカウントをひとつの組織として統合するためのアカウント管理サービスです。
AWS Organizationsで組織を作成したアカウントが管理アカウントになり、組織にメンバーアカウントを作成したり、組織に参加するための招待の送信、組織からのアカウントの削除を行うことができます。
組織に追加、招待されたアカウントは、組織単位「Organizational Unit（OU）」としてグループ化して管理します。
OUはワークロードの種類や用途（たとえば企業の部署など）ごとに作成し、そこにメンバーアカウントを所属させる形になります。
OUに他のOUをネストさせて階層化することもできます。
またサービスコントロールポリシー (SCP) を使用して、組織のアカウントでプリンシパル（アカウントルート、IAMユーザー、IAMロール）にアクセスできるAWSのサービスアクションを管理できます。

overview

AWS Organizationsを使用すると、すべてのメンバーアカウントの請求を管理アカウントで一括管理できます。
またAWS Organizationsは他の多くのAWSサービスと統合されており、たとえばAWS IAM Identity Centerと統合することで、シングルサインオン（SSO）を通じて管理者や開発者が複数のAWSアカウントにアクセスしやすくなります。
個別のアカウントごとにIAMユーザーを作成して管理する必要がなくなるため、利便性が高まります。

ランディングゾーンとは

AWS Organizationsはあくまでマルチアカウントの一元管理を実現するサービスで、実際にマルチアカウントを運用するにはアカウントの設計やどのようなポリシーを設定するかなど、追加で検討しなければならないことがあります。
そこでマルチアカウント環境を構築する際に参考になるランディングゾーンという概念があります。
ランディングゾーンとは、AWS Well-Architected FrameworkをはじめとしたAWSのベストプラクティスに基づいたセキュアなマルチアカウント環境を提供する仕組みの総称で、以下の機能から構成されます。

アカウントの発行 : 必要な初期設定の済んだアカウントを作成

管理用権限の発行 : 対象アカウントを管理するための権限を作成

共有サービスへのアクセス（ユーザー環境に合わせて個別に実装する） : ADやファイルサーバー等の共有サービスや運用拠点への接続経路の確保

AWSログの集約 : 監査用ログをセキュアに一元保存

ガードレールの設置 : 実施してはいけない操作の禁止（予防的ガードレール）とリスクのある設定の発見（発見的ガードレール）

【引用】 : AWS マルチアカウント管理を実現するベストプラクティスとは ?

このランディングゾーンを備えたマルチアカウント環境を実現するために、独自ですべて実装すると大変です。
そこでAWS Control Towerを使用することで簡単に実装できます。

AWS Control Towerとは

AWS Control Towerとはセキュアなマルチアカウント環境を自動でセットアップするサービスです。
AWS Organizationsをベースとした環境を、AWSのベストプラクティスに則った形で自動セットアップすることができ、マルチアカウント環境構築のハードルを大幅に下げることができます。
つまりAWS Control Towerを使用することでランディングゾーンに必要とされる機能を簡単に実装できます。

control-tower