Edited at

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

AWS のアカウントの分け方や複数アカウントの管理方法を教えるための記事です。

もっと管理上やることが多いと思いますが、目立ったところを教えるために書いています。


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

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

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

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



  • コスト


    • アカウント単位で分ければタグによるコスト配分をしなくてよくなる

    • プロダクト単位や環境単位で正確なAWS費用を出せる




  • 環境


    • オペミスを防ぐためにも本番と開発ではアカウントを分けたほうがいい

    • 分けていたほうが開発やテスト時は多少雑な IAM 管理でも許される




  • 役割


    • コスト配分先が同じでも、利用者が異なっていてシステム上分けることが可能ならアカウントを分けたほうが IAM の権限管理が複雑化しにくい

    • 全アカウントに対してなにかを行うアカウントは分けたほうがいい




アカウント分割粒度例

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



  • 一括請求用


    • Organization のマスターアカウント




  • 全アカウントに対してアクションを行うもの


    • セキュリティアカウント

    • 監視アカウント

    • 監査アカウント

    • ログ集約アカウント




  • 多くのサービスが利用するもの


    • サービス向け認証基盤アカウント

    • サービス向け決済基盤アカウント

    • 自社向け認証基盤アカウント




  • サービス&環境単位


    • ほげほげサービスアカウント(Production)

    • ほげほげサービスアカウント(Development)

    • ほげほげサービスアカウント(Test などなど)




  • 小さくて集約したほうがいいサービス向け


    • CloudFront+S3 構成のみアカウント

    • WordPress 構成サービスアカウント



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


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


AWS Control Tower

AWSが推奨する複数アカウント管理に必要なものが結構揃った環境を一発で作れるFormationのようなサービスです。

新規でAWSアカウントを取ったばかりだったり、Organizationをまだ作っていない場合はContorl Towerを利用して複数アカウントの管理を行うのをおすすめします。

Contorl Tower の Landing Zoneがやっていることが多すぎるので以下のリンク先を参照してください。

参考:Landing Zone | AWS Solutions

参考:AWS Control Tower の仕組み - AWS Control Tower

これだけの初期設定を自前で用意するのはかなり大変なので、Landing Zone がデフォルトで作るものに邪魔なものがあったとしても Landing Zone で作っておいたほうが速い場面が多いと思います。

ダッシュボードの機能が Security Hub と若干かぶっている感じがしますが、リリース直後ですし今後に期待しましょう。


注意点

Organizationをすでに使っている場合、Control Tower で Landing Zone を作ることができません。

新規アカウントで Landing Zone を作った後、Organization の引っ越し(組織から削除 → スタンドアロンのアカウント → 新しい組織に加入)をする必要があります。かなりめんどうです。


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 を制限するものだと思って使いましょう。

2019/07/30追記:

Resource の指定や Conditon も使えるようになっていました。Wildcard も使えます。

Config Rule に頼る部分が減るため費用削減にもなりますし、よりセキュアにできます。

参考:AWS Organizations のサービスコントロールポリシーで、きめ細かなアクセス許可管理が可能に

参考:サービスコントロールポリシー - 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 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 かかるのが最大の難点。

追記(2019/07/10):

2019/8/1からConfig Ruleの価格体系が変わるので、もっと気軽に使えるようになります!

料金 - AWS Config | AWS


GuardDuty

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

guardduty

参考: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


各種ログ

全アカウントから集約したいものにログもありますが、そっちはデータレイクの話になるので省略。

AWS Lake Formation が GA したら追記したい。