プログラマでありたい

おっさんになっても、プログラマでありつづけたい

複数のAWSアカウント管理を制するものが、AWSを制する

 いよいよ明日発売開始であるAmazon Web Services 業務システム設計・移行ガイドの一貫したテーマが、「企業内でどのようにAWSを使っていくのか」です。企業内でのユースケースを元に、ネットワーク/システム設計や運用管理、移行の話をしています。その中で1章を割いて説明しているのが、AWSアカウントをどのように管理するかです。

複数(マルチ)AWSアカウント管理の重要性


 AWSを利用する上で、AWSアカウントをどのように管理していくかは最重要事項です。AWSアカウント管理というと、一般的には、AWSリソースの認証認可であるIAMを使った運用方法について語られることが多いです。しかし、企業内で利用する際は、それだけでは不十分です。何故なら、企業内では1つのAWSアカウントではなく、複数のAWSアカウントを作成し運用することになるからです。いわゆるマルチアカウント運用です。
 企業内での運用がマルチAWSアカウントとなる理由は、主に管理上のメリットです。現状のIAMの機能では、サービス単位の管理が基本となります。リソース単位の権限管理も可能ですが、安全簡単に設定できるという構造にはなっていません。例えば、EC2のインスタンス管理について考えてみましょう。開発者と運用者というロールがあるとして、開発環境は開発者が管理し、本番環境は運用者が管理するとします。この場合、開発者は本番環境のインスタンスの操作はできないようにしないといけません。現状のIAMの機能では、これを実現するにはIAMの設定中に具体的なりソース名(インスタンスID)を列挙していくしかありません。また、インスタンスの一覧から権限がないものについて見えなくするというようなことも出来ません。
 現実的にはIAMのみでの運用は難しいので、本番環境用のAWSアカウントと開発環境用のAWSアカウントを分離することになります。これがマルチアカウント化の第一歩です。次に組織別のAWSアカウントです。一定以上の規模であれば、複数のサービス・プロジェクトを運用していることでしょう。また企業内の組織構造も、そのミッションに従って本部/部/室などの単位で別れていると思います。ここで、AWSのアカウントを組織横断で運用できるかという問題がでてきます。横串にAWSアカウントを管理するような組織があれば可能かもしれませんが、現実的には余り実現していません。
 結果的に、AWSアカウントは組織ごと環境ごと作成されることになります。つまり1つの企業内にAWSアカウントが10も20もあるというのが当たり前の状況なのです。これを何も考えずに放置していると、それぞれの組織毎に同じようなことに頭を悩ませ、試行錯誤することになります。それを回避するには、最初に下記のようなことを考える必要があります。

・AWSのアカウント管理方法
・AWSアカウントをどの単位で分割するべきか
・IAMの権限付与設計

 こんなようなことを考えていくのがアカウント管理設計ですね。

f:id:dkfj:20180119072331p:plain

AWSのアカウント管理方法 には、AWS Organizations


 現状のAWSの機能でいうとAWSのアカウント管理には、AWS Organizationsを使うことになります。これは名前の通り、組織内で利用するAWSアカウントを管理する為の機能が提供されています。AWS Organizationsを使うことにより、アカウントのグループ化であったり、アカウントで利用できる機能の制限することができます。また、このサービスについては従来の一括決済機能の発展的な部分があり、請求を一つにまとめるということができます。概念図としては、次のような形になっています。

f:id:dkfj:20180119072307p:plain

 このAWS Organizationsについて、どう使っていくのか明確な指針を出せている所は少ないと思います。例えば、サービスコントロールには、ブラックリスト方式とホワイトリスト方式の2種類があります。また、制限をかける範囲をrootからにするか、Organization Unit単位にするかなどの選択肢があります。この辺りについて、Amazon Web Services 業務システム設計・移行ガイドの3章で重点的に解説しています。

マルチアカウント化したものの


 一方でマルチアカウント化したら、それで全て解決かというとそうでは無いのですよね。例えば、ネットワーク接続をどうするかなどの問題があります。2017年末にDirect Connect Gatewayが出て、専用線を使った複数VPCの接続方法が柔軟にできるようになりました。ただし、現状では別アカウントのVPCを接続できません。或いは、AWS Systems Managerという機能がでてEC2やRDSをグルーピング化できるようになりました。これで権限管理も出来ないかなぁとか色々思うところもあります。
 組織が違えば運用形態も違うので、ただひとつの正解というのは無いと思います。その中で、比較的ベスト・プラクティスに近いのを集めて行ければなぁと思っています。ということで、Amazon Web Services 業務システム設計・移行ガイドは明日発売です!!

Amazon Web Services 業務システム設計・移行ガイド

Amazon Web Services 業務システム設計・移行ガイド

  • 作者: NRIネットコム株式会社:佐々木拓郎,林晋一郎,株式会社野村総合研究所:瀬戸島敏宏,宮川亮,金澤圭
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2018/01/20
  • メディア: 単行本
  • この商品を含むブログを見る

See also:
Amazon Web Services 業務システム設計・移行ガイドの目次
「Amazon Web Services 業務システム設計・移行ガイド」という本を書きました