AWS Organizationsでマルチアカウント戦略を始めよう【ウェビナー資料公開】
2023/02/08のウェビナー AWS Organizationsのユースケースで学ぶ AWSアカウント管理のベストプラクティス にて、 『 AWS Organizationsでマルチアカウント戦略を始めよう 』というタイトルで話しました。
発表したスライドを以下に載せます。
また実際に話した内容を(少し盛って)記載していきます。
イントロ
みなさんが日常で使っているAWSアカウント、 マネジメントコンソールの風景を思い浮かべてください。 例えば以下のような画面です。
- EC2インスタンスのリソース一覧
- IAMユーザーやIAMロール
- AWS利用の請求情報
こんな感じ(▼)になっていて、頭を悩ませていないでしょうか？
- いろんなプロジェクト/環境のEC2インスタンスがごちゃまぜ
- IAMポリシー精査に疲弊している
- 疲弊してしまい、過剰なIAMポリシーを付与している
- 色んなプロジェクトのコストがごちゃまぜ
- …
そういった課題、当てはまる方は、ぜひ今回の資料に目を通していただき、 マルチアカウント戦略 with AWS Organizations を検討ください。
マルチアカウント戦略はなぜ必要？
そもそもマルチアカウント戦略とは 『特定の単位や基準でAWSアカウントを分けて運用する』戦略のことを言います。
上図は環境(本番/非本番)や稼働するシステム単位でAWSアカウントを 分けているイメージになります。
なぜ必要なのでしょう？ 簡潔な回答としては『 AWSアカウントの特性を上手く活用して、アジリティとガバナンスの両立させるため 』です。
(追記) ウェビナーではそう言いましたが、改めて考えると 『両立を維持する』 と言ったほうが個人的にはしっくりきますね。
そもそもAWS(クラウド)を使うこと自体が、アジリティとガバナンスを両立できるための手段となります。 開発者は調達プロセスなど必要なく、瞬時にリソースを建てられます。 さらに建てたリソースに対して、以下のような管理体制も簡単に "AWS内に完結して" 作られます。
- リソースへの操作権限 ( by AWS IAM )
- リソースへの操作履歴 ( by AWS CloudTrail )
- リソースの構成管理 ( by AWS Config )
- リソースのセキュリティ評価 ( by AWS Security Hub, Amazon Inspector ) など…
しかし、AWSアカウント(シングルアカウント)内で成熟してくると色々な課題が出てきます。 イントロで話したような、「複数プロジェクトのリソースが乱立」などです。 「だれが、どう管理しているのか」があやふやになってきます (ガバナンスの低下)。 結果として何か新規リソースを建てる時に影響把握や、権限制御などがボトルネックになってきます (アジリティの低下)。
如何にしてスケールするビジネスに対し、AWSのメリットである「アジリティとガバナンスの両立」を維持し続けるか。 その課題解決にマルチアカウント戦略は役立ちます。
では、具体的に何がマルチアカウント戦略のメリットなのか、見ていきましょう。
メリット1: セキュリティ向上
AWSアカウントは セキュリティの境界線 になります。
セキュリティにおいては『最小権限の原則』が大事になってきます。 AWSにおいても、それが求められます。
- IAM でのセキュリティのベストプラクティス #最小特権アクセス許可を適用する - AWS Identity and Access Management
- 最小権限実現への4ステップアプローチ 前編 | Amazon Web Services ブログ
- 最小権限実現への4ステップアプローチ 後編 | Amazon Web Services ブログ
そしてAWSアカウントを分けることは 「完全な権限分離」を実現する、最も簡単な方法 です。
シングルアカウントでもIAMグループをIAMポリシーを駆使して、柔軟な権限制御は可能です。 ただし、だんだんとスケールしてくると、やはりポリシーが煩雑になったり、管理が大変になったりします。
もちろんマルチアカウント戦略でもIAMポリシー設計は必要ですが、 アカウントを分割していることで、より労力少なく最小権限のアプローチが可能になります。
※ ポリシー管理のスケールを抑えるために 属性ベースのアクセスコントロール (ABAC) という認可戦略が活用できます。 が、いざAWS環境で実装・運用しようとするとタグの整備やIAMポリシーの理解など、苦労する点が多いです。
メリット2: 開発スピードの促進
AWSアカウントは リソースの境界線 になります。
AWSにはサービスクォータがあります。 リソースの作成上限やAPIリミットなど、アカウント/リージョン単位で設定されています。
シングルアカウント運用だと、あるシステムや環境のAWSサービス/リソースの利用状況が 他のワークロードへ干渉してしまう可能性があります。
アカウントを分割していると、サービス/リソースの利用状況の把握や 影響範囲の予測が容易になります。
結果として他の環境(本番環境など)の影響を気にせずに、開発を回すことができます。
メリット3: コスト最適化
AWSアカウントは コストの境界線 になります。
コスト分類は大事です。
シングルアカウント上でコスト分類を行おうとする場合は、コスト配分タグ を使います。 タグを整備したり、タグ付のルール徹底が結構大変です。 また、そもそもタグで分類できないもの (ネットワーク利用量など)もあったりします。
アカウントを分割していると「どの環境(アカウント)」が「どれだけ使ったか」 を "簡単に" なおかつ "厳密に" コスト把握できます。
ここまでのまとめ
以上 3つがマルチアカウント戦略の主なメリットです。 マルチアカウント戦略により、アジリティとガバナンスを両立が容易になります。
AWSアカウントの "様々な境界線" という特性をうまく活用しましょう。
AWS Organizationsはなぜ必要？
AWS Organizationsは 「 複数AWSアカウントを組織化して色々できるようにする 」サービスです。 「色々」といったとおり、できることは多岐に渡ります 主要な用語としては以下のようなものがあります(それぞれ後ろで説明します)。
- 管理アカウント(Management Account)
- メンバーアカウント(Member Account)
- Organizational Unit(OU: 組織単位)
- サービスコントロールポリシー(SCP)
– 画像: AWS Organizations の用語と概念 - AWS Organizations
AWS Organizations はなぜ必要か？
ざっくり言うと マルチアカウント戦略の特性上、統制が煩雑になりがちな部分をサポート するためにあります。
以降で「統制が煩雑になりがちなこと」と「AWS Organizationsがサポートすること」を 紹介していきます。
請求の簡素化
マルチアカウント戦略では アカウントごとの請求管理 が煩雑になりがちです。
素の状態では各アカウントごとに請求情報を登録・管理する必要があります。
※弊社(Classmethod)のような請求代行サービス側で複数アカウントの一括請求を サポートしているケースはあります
AWS Organizationsを使うことで 管理アカウントへ請求を集約 できます。 ( AWS Organizationsの一括請求 機能 )
管理アカウント というワードが出てきましたが、 これは AWS Organizationsを有効化したAWSアカウントです。 「組織の代表となるアカウント」とイメージいただければ良いです。
それ以外のAWSアカウント群(実際にワークロードを走らせたりするアカウント群)は メンバーアカウント と言います。 メンバーアカウントでは請求を管理する必要が無いです。 管理アカウントへ一括で請求されます。
ログ(証跡)の集約と集中管理
マルチアカウント戦略では ログ(証跡)統制 が煩雑になりがちです。 特に「どのAWSアカウントでも共通して取るログ」は集中管理しておきたいですよね。
例えば AWS CloudTrailです。 これはAWSアカウント上の操作履歴(証跡)を記録する重要なサービスです。
AWS CloudTrailの Organizations連携 を使うと組織の証跡 を作成できます。
組織内の全アカウント上でCloudTrail証跡を有効化して、 1つのS3バケット(やCloudWatch Logs)へ集約できる便利な機能です。 「あるアカウントで証跡を取り忘れた」といったことが無くなります。
CloudTrailに限らず、AWS Organizationsは多くのAWSサービスと連携しています。
アカウント横断でAWSサービスを "より簡単に" 活用できて便利です。 マルチアカウント運用をサポートします。
アクセス制御の一括設定
マルチアカウント戦略では セキュリティ統制 が煩雑になりがちです。
管理者として、各アカウント上で共通して 「やってはいけないことを禁止する統制( 予防的ガードレール )」 を展開することは大事です。
AWS Organizations には予防的ガードレールを敷くための便利機能として、 サービスコントロールポリシー(SCP) があります。 アカウント横断で「やってはいけないこと」を制御するのに役立ちます。
SCPはOrganizational Unit(組織単位: OU)もしくはAWSアカウント自身に 付けられるポリシーです。 OU単位に追加付与して、統制を効かせるのがベストプラクティスです。
※ Organizational Unit(組織単位: OU) … メンバーアカウントをグループ化/階層化するための枠
ユーザーとアクセスの集中管理
マルチアカウント戦略では ユーザー・アクセス管理 が煩雑になりがちです。
その都度、各アカウントにIAMユーザーを作成して管理していくと、 アカウント数のスケールに耐えられません。
AWS IAM Identity Center(旧称: AWS Single Sign-On) は 「ユーザー」と「アカウントへのアクセス」を集中管理するためのサービスです。 AWS Organizationsの有効化が前提条件になっています。
各アカウントにIAMユーザーを作る必要はありません。 「どのユーザーが、どのアカウントに、どのポリシーでアクセスできるか」 を IAM Identity Center で集中管理できます。
ここまでのまとめ
以上、AWS Organizations がサポートしてくれることを抜粋しました。
紹介したもの以外にも、AWS Organizations でできることは沢山あります。 ぜひ実際に触って、試してみると良いです。
マルチアカウント戦略、何から始める？
では、これまでの話を踏まえた上で、 「じゃあ何からマルチアカウント戦略始めればいいの？」 について私見を紹介します。
以下におすすめのステップを掲載します。 (※順番通りに進めてね、といったものではありません)
- AWSアカウント分割方針を決めよう
- サービスコントロールポリシー(SCP)を活用しよう
- AWS IAM Identity Center を活用しよう
- 色んなOrganizations連携サービスを活用しよう
1. AWSアカウント分割方針を決めよう
まずはどのような基準でAWSアカウントを分割するかを決めておきましょう。 最初に述べたAWSアカウントの性質(さまざまな境界線)の理解が必要になります。 また、今後 開発/稼働させるワークロードのセキュリティレベルや依存関係、 関係者の違いを把握することも大事です。
そして、決めたアカウント分割方針をOU設計に落とし込みます。
以下、比較的シンプルなアカウント分割/OU設計のモデルケースです。
Security OU にアカウント横断で統制を効かせるためのAWSアカウントを配置しています。 例えば以下のようなAWSアカウントです。
- セキュリティアカウント: アカウント横断でセキュリティ運用するためのAWSアカウント
- ログアーカイブアカウント: アカウント横断でログを集中管理するためのAWSアカウント
Workloads OU に ステージ単位 × システム単位で AWSアカウントを配置しています。 検証環境と本番環境では求められるセキュリティレベルが異なります。 なのでOUで分けています。こうすることで、サービスコントロールポリシー(SCP)を使った 異なるアクセス制御を実現したりできます。
より細かなOU設計を行いたい場合は、以下AWSブログが役に立ちます。
OU自体は課金無く利用でき、後から拡張可能です。 上記のようなブログは参考にしつつ、スモールスタートを意識して 必要最小限のOU構成から始めるのが良いでしょう。
2. サービスコントロールポリシー(SCP)を活用しよう
SCPは予防的ガードレールとしてフル活用します。
良くある制限としては、まず「使わないリージョンでの操作禁止」があります。 "知らない間に普段使わないリージョンでリソースが作られていた" と いったことを未然に防げます。
あとは「セキュリティサービスの無効化禁止」もよく設定します。 管理者が設定したセキュリティサービスを他の利用者に無効化されないようにします。
その他 SCPの実設計やサンプルは以下ドキュメント・ブログを参考ください。
- サービスコントロールポリシーの例 - AWS Organizations
- <AWS Organizations> SCP(サービスコントロールポリシー)の継承の仕組みを学ぼう | DevelopersIO
3. AWS IAM Identity Center を活用しよう
「誰がどのアカウントにどの権限でアクセスできるか」といった、 認証・認可の設定は集中管理したいです。 よくあるアンチパターンは IAMユーザーを各アカウントに散らばらせることです。 各アカウントにIAMユーザーのログイン情報、アクセスキーが散乱して、 セキュリティのリスクになり得ます。
マルチアカウント環境のアクセス方法は色々あります(参考)が、 AWS Organizationsを使っているのであれば、 まずは IAM Identity Center(旧称: AWS Single Sign-On) が使えないか検討したいです。
追加料金無しで利用できます。より労力少なく、AWSアカウントへのアクセスを実現できます。
なお、IAM Identity Center でどの認証情報を使うかはいくつか選択肢があります。 既存の認証基盤がある場合は、利用できるか検討しましょう。
- AWS管理の 独自IDストア
- 外部IDプロバイダー(Azure AD, Okta等) 利用
- Active Directory利用
また、実際に設計をする際の各種リソースの理解は以下ブログが役に立ちます。
4. 色んなOrganizations連携サービスを活用しよう
AWS Organizationsは多くのAWSサービスと連携しています。 先程の IAM Identity Center もその1つです。
全てを活用していく必要はありません。AWSサービスが必要になったタイミングで、 Organizations連携に対応しているか調べて、使える場合は試してみるのが良いかと思います。
いくつか主観ですが、よくお世話になりそうな Organizations連携サービスを ピックアップします。
- AWS CloudTrail : 「組織の証跡」を簡単に作成できます。証跡の集約に役立ちます
- AWS CloudFormation : スタックセットを使って、OU単位でCloudFormationテンプレートを展開できます。 汎用性が高いです
- Amazon GuardDuty, AWS Security Hub : アカウント横断でセキュリティ管理・運用できます
特にGuardDuty, Security Hub あたりは、ぜひ Organizations連携を触ってみてください。
それぞれセキュリティの発見的ガードレール (リスクのある設定や状況を発見してアクションに繋げるための仕組み) として役立ちます。Organizations連携をすることで、手間無く有効化・集約できます。
セットアップや運用の際には以下ブログを参考にすると良いです。
- Organizations 環境で Amazon GuardDuty を全リージョンへ簡単セットアップしてみる | DevelopersIO
- Organizations 環境で AWS Security Hub を全リージョンへ簡単セットアップする | DevelopersIO
- <2021年版>Amazon GuardDutyによるAWSセキュリティ運用を考える | DevelopersIO
- <2021年版>AWS Security HubによるAWSセキュリティ運用を考える | DevelopersIO
おわりに
以上、マルチアカウント戦略やAWS Organizationsの話をしました。
AWSアカウントは様々な境界線となります。 その特性を生かしてマルチアカウント戦略を推進しましょう。
推進サポートには AWS Organizations が大活躍します。
"スモールスタート"、"まずは触ってみる" を意識していきましょう。
最後に宣伝
クラスメソッドメンバーズ の1特典として Classmethod Cloud Guidebook があります。 これは「組織的なAWS活用のためのノウハウ」をまとめたAWSナレッジ集です。 現在クラスメソッドメンバーズ向けに無償公開しております。
今回話した AWS Organizations や AWS Control Tower などの 「よくAWSガバナンスで使われるサービス」に関するTipsや、 AWS利用ガイドラインのサンプルなど、提供しております。
お客様のクラウドジャーニーのお供として、ぜひご活用いただければと思います。
Classmethod Cloud Guidebook のより詳細については以下ブログを参照ください。
参考
- AWS Organizations
- ほか
![[アップデート]待望！管理アカウントでメンバーアカウントのルートユーザ操作禁止などが設定できるRoot access managementがリリースされました！](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-2eddd7f989fa67416ea2d27b4223cc32/8f5b157eb82ee11cc288225119e0c290/aws-organizations)
