AWS マルチアカウント管理のベストプラクティス（re:invent2018後版）

AWS マルチアカウント管理のベストプラクティス（re:invent2018後版）:

AWS#2 Advent Calendar 2018の16日目の記事です。

TL;DR

• AWSアカウントは下記の観点で分割した方が良いことが多い
  
  
  • ガバナンス、課金、組織、運用
  • ただし手間がかかる -> AWSのサービスをうまく使おう
• AWS Organizationでの適用
  
  
  • OU（Organization Unit : 組織単位)とポリシー
  • ロール切り替え（sts:AssumeRole）でクロスアカウントアクセスさせる
• re:Invent周辺で関連機能がアナウンスされた
  
  
  • 監査ログ：AWS OrganizationでCloudTrailの一括設定
  • ネットワーク管理：AWS Transit Gateway, Resouce Access Manager(RAM)
  • 自動化？：AWS Control Tower
• もっと気軽にアカウントを作ったり消したりしたい、ここはGCP/Azureを正直見習ってほしい
  
  
  • AWSの技術的負債な気もします

はじめに

企業向けに統制を効かせながらAWSを使おうとすると、皆辿り着く場所はマルチアカウントとなるはずです。

結構クセがあるのでサービスとその情報ソースを追いながら、2018年12月時点ではこれが良いと言っているはず、というのをまとめます

re:invent2018でのサービスの内容は取り込みますが、セッションの内容まではフォローできていないので後で更新する可能性があります

コンテンツ

AWSマルチアカウント戦略（２０１７夏)

AWSSummit 2017Tokyo

- 古いですが日本語でまとまってるのはたぶんこれ。一読すべし。

• 最終的な図だけ見ると結構引く
  
  
  
  

AWS Organization

公式blackbelt

• こちらもP43以降になぜマルチアカウント化か？が書いてあります
  
  
  • 料金や権限を明確に分離するためには、IAMや課金タグの工夫では限界
    
    
    • タグをつけ忘れたり、つけられない共有リソース（eg.ネットワーク転送）に対する課金
    • S3のトップページでそのアカウントの「バケット名」一覧は取得できてしまうはず
      
      
      • 当該ユーザが関係ないものも。中身は見れないようにIAMで制限できる。
  • アカウントごと分けてしまうのが、わかりやすくなる
• 主な機能
  
  
  • 請求統合（Billing Consolidation)
  • メンバーアカウント（子アカウント）への強制適用ポリシー（SCP：ServiceControlPolicy）
    
    
    • CloudTrailを触れないようにする、など。あまり使いこなせてないです
  • スイッチロール
    
    
    • このロールで適切に権限設計する方がやりやすいとは思います

具体的な事例

• re:invent2017のワークショップ(sid311)
  
  
  • 資料
  • slideshare
  • なぜそれをやるのか？その手順は？が丁寧にあるが、結構地道に作るイメージ
• re:invent2017のワークショップ(arc325)
  
  
  • Github
  • 実際にコードもあるので、技術者向けではある。それでも面倒。
• re:invent2017の(sid331)
  
  
  • クラスメソッド社Blog
  • slideshare
  • トムソン・ロイター社の事例が出てくる
    
    
    • Shared service, loggingなど具体的なアカウントが入ってるのがイメージしやすいはず
    • 
    • ぶっちゃけ超めんどくさそう、ということはわかる

課題

• 
  監査ログの分離は必須だと思うが、これすら結構面倒
  
  
  
  
  • それぞれのメンバーアカウントに対してCLoudTrailの設定を入れるような自動化を組んで頑張ろうね、というのがAWSの宣言だった
  • こちらは2018/11にAWS Organization配下であれば楽に統合設定できる機能がリリースされた
    
    
    • AWS Blog
  • 今から新規でやるならこれ一択。今までやってきた人たちは継続性を失わないように使う必要あり
    
    
    • 未検証です。。
• 
  DirectConnectの共有ができない
  
  
  
  
  • トムソン・ロイターの事例でも、DX用のアカウントを作ってうまくやりくりしようね、という方針
  • 
    re:invent2018のTransitGatewayで解決されるはず
  • クラスメソッド社Blog
  • 東京にもやや遅れてきたようです
• 
  共有したいリソースをどのように管理するか？
  
  
  
  
  • SharedServiceアカウントで管理すべきもの、ということ
  • 
    ResourceAccessManagerで一部は対応できるかも
    
    
    • VPCなどのNW系。
    • ADなどは管理できないようにも見える
  • クラスメソッド社Blog
  • re:grow slide
• 
  他もいろいろと面倒
  
  
  
  
  • アカウント（SSO,AD）管理や細かいセキュリティなど
  • 
    re:invent2018のControlTower
    
    
    • まだプレビュー状況でどんなものなのかはよくわかっていないがこれがベスプラになるはず
  • 
    クラスメソッド社Blog
    
    
    • この記事にてメンションされているLanding Zoneという考え方が最先端
    • それをうまく自動化してくれるはず、とのこと
    • ワークショップへのリンクもある

その他

• VPCを分けるか、アカウントを分けるか？
  
  
  • クラスメソッド社Blog
  • 管理の手間だけを除けばアカウントを分けたほうが基本良い、と書いてある

雑感と要望

• AWSもAzureやGCPのようにProjectのような概念を持ってきてくれればやりやすい、と思う
  
  
  • なぜ（実質）開放しないルートアカウント用にメールアドレスを複数作る必要があるのか
    
    
    • 
      xxx+alias@domain.comのようなエイリアス機能がないと死ぬ、あっても辛い
    • 古き良き企業にはそんなのなくて、意外と手間取る
• 謎の制約がいろいろあって陥りがち
  
  
  • blackbeltの資料に詳しく書いてあります
  • 組織に追加した後は課金タグ設定を変更できない、デフォルトOFFとか謎の制約がやばい
  • アカウントは削除できなくて、組織から外した後で個別削除する必要性
    
    
    • 外した瞬間の課金とかどーなるのか（未実施）
    • S3のコンプライアンスモードとか使うと課金を止められないケースすらありそう。。。

終わりに

正直AWSマルチアカウント運用についてはまだまだ改善余地はあると思うのですが、このre:invent2018で進歩した部分の一つだと思っています。

今後もフォローしていきたいところです。