AWS
CloudFormation
Organization

15分で教えるAWSの複数アカウント管理

AWSのアカウントの分け方や複数アカウントの管理方法を教えるための記事です。
もっと管理上やることが多いと思いますが、目立ったところを教えるために書いています。

なぜアカウントを分ける必要があるのか

AWS におけるマルチアカウント管理の手法とベストプラクティス.png

参考:AWS におけるマルチアカウント管理の手法とベストプラクティス

上記スライドにすべて書いてあるが、個人的な意見も交えてると アカウントを分ける基準はコストと環境と役割

  • コスト
    • アカウント単位で分ければタグによるコスト分配をしなくてよくなる
  • 環境
    • オペミスを防ぐためにも本番と開発ではアカウントを分けたほうがいい
    • 分けていたほうが開発やテスト時にIAM管理に気を使わなくていい
  • 役割
    • 利用者が完全に異なっていてシステム上分けることが可能なら分けたほうがIAM管理が楽
    • 全アカウントに対してなにかを行うアカウントは分けたほうがいい

アカウント分割粒度例

実際に分けてみた例が以下のもの。

  • 一括請求用
    • Organizationのマスターアカウント
  • 全アカウントに対してアクションを行うもの
    • セキュリティアカウント
    • 監視アカウント
    • 監査アカウント
    • ログ集約アカウント
  • 多くのサービスが利用するもの
    • サービス向け認証基盤アカウント
    • サービス向け決済基盤アカウント
    • 自社向け認証基盤アカウント
  • サービス&環境単位
    • ほげほげサービスアカウント(Production)
    • ほげほげサービスアカウント(Development)
    • ほげほげサービスアカウント(Testなどなど)
  • 小さくて集約したほうがいいサービス向け
    • CloudFront+S3構成のみアカウント
    • WordPress構成サービスアカウント

組織の規模によっては、ここまで分ける必要がないが一度書き出して分けてみて、各アカウントで入る人や持つべき権限が同じようなものがあれば合体させるといいと思います。

複数あるアカウントはどう管理していけばいいのか

AWS Organization

規模の大きな組織になるとAWSアカウントが数百になったりしますが、AWSには一元管理する方法が用意されています。

AWS Organizationを使うとAWSアカウント間で親子関係を構築することができます。
現状Organization内で親となれるアカウントは1つのみで、子が複数の親を持つことはできません。子が孫にあたるアカウントを持つこともできません。

現状できることは主に3つです。

  • 請求の一元化
  • Service Control Policiesによる利用制限
  • AWSアカウントの作成、招待

参考:AWS Organizations の用語と概念 - AWS Organizations

Service Control Policiesによる利用制限

Organization Unit(OU)という単位にService Control Policies(SCP)を設定することができて、OUに属するAWSアカウントレベルの機能を制限できます。
OUは階層構造を持つことができ、SCPは子のOUにも影響を与えます。
AWSアカウントが所属できるOUは1つのみです。

下記の例だとブラックリスト方式で制限をかけています。

OrganizationSCP.png

個人的にSCPの一番の利点だと思うのは、AWSアカウントのルートユーザーも制限の対象として含まれる点です(一部制限できない操作はあり)。
例外として考えなくてはいけなかったルートユーザーの不正利用を制限できるため、SCPで制限してしまえば監視する必要がある項目が減ります。
使う予定の機能が定まっているのならばホワイトリスト方式のほうがセキュアです。

一見便利なSCPですがIAMのPolicyほど柔軟性はありません。
Resourceは * しか使えない上にConditionもなく、Principalも指定できません。
ServiceとActionを制限するものだと思って使いましょう。

参考:サービスコントロールポリシー - AWS Organizations

複数アカウント間で同じ環境を作りたい

CloudFormation StackSets

アカウントの初期設定をしたり、初期テンプレートリソースをばらまくのに使えるサービスです。

image.png

参考:AWS CloudFormation StackSets の操作 - AWS CloudFormation

CloudFormation(CFn)は1アカウント内のAWSリソース構成管理としてしか使えませんでしたが、CloudFormation StackSetsが出たことで、複数アカウントのAWSリソースの構成管理に使うことができます。

StackSets の制約事項 - AWS CloudFormation
管理者アカウントでは最大 20 個のスタックセットを、そして各スタックセットに最大で 500 個のスタックインスタンスを作成することができます。

便利な機能なのですが、少々厄介なのがこの制約。
20個しかStackSetを作れないので、1セットに複数の役割を持たせたりStackSetsでデプロイするのと、それ以外の方法でデプロイするので分けたりが必要になってくる。
またnestしたStackSetを数百アカウントにデプロイすると500個のスタックインスタンスを超えることがあるので、そこも注意が必要。

複数アカウントの監視・監査の情報を集約したい

CloudTrail

AWS APIの呼び出しログが記録されます、コンソールの操作もAPI呼び出しに相当するため、AWSへの操作ログはこのCloudTrailを見ればだいたい把握できます。

image.png

参考:AWS CloudTrail (AWS API の呼び出し記録とログファイル送信) | AWS
参考:AWS Black Belt Online Seminar 2016 AWS CloudTrail & AWS Config

監査ログの保存先を別アカウントのS3にできるので、すべてのアカウントのログを1つのS3バケットに集約することができます。

AWS Config Aggrigator

監査やコンプライアンスチェックで使うAWS Configを集約するサービスです。

image.png

参考:マルチアカウントマルチリージョンのデータ集約 - AWS Config

AWS Configで監査やコンプラチェックをしていても、個々のアカウントで状態を見るか通知を飛ばして把握するしかなかったですが、Aggrigatorを使うとOrganizationのMasterアカウントにてAWS Configの結果を集約して閲覧することができます。

Config Ruleにかかった個別のリソースを見るには、個々のアカウントにログインしないといけないのが、ちょっといまいちですが、結果だけでも集約して見ることができるのはありがたいです。
機能自体は大変すばらしいのですが、1つのRuleに $2 かかるのが最大の難点。

GuardDuty

監視で使われるGuardDutyもAWS Configのように通知を集約することができます。

aa

参考:20180509 AWS Black Belt Online Seminar Amazon GuardDuty

GuardDutyの全アカウント全リージョン有効化+集約アカウントに対しての承認まで一気にやってくれるスクリプトがGithubで公開されているので、これを叩くだけで集約させることができます。
結構時間かかるので複数アカウント一気に有効化しようとするとLambdaの実行時間上限に引っかかります。

AWS Config Aggrigatorと違いOrganization Masterアカウントでないアカウントを集約アカウントにすることができます。

参考:Amazon GuardDuty で AWS アカウントを管理する - Amazon GuardDuty
参考:aws-samples/amazon-guardduty-multiaccount-scripts: This script automates the process of running the GuardDuty multi-account workflow across a group of accounts that are in your control