AWS環境改善メモ

前置き

• 基本の部分は情報あるけど、アカウントの分け方はあまり記事としてまとまってない

基本

• 親アカウントは1つだけど、子アカウントを色々作れるよ
• 子アカウントを適切に分けて作ると便利だよ

Organization

• 親AWS account id = 契約（請求はここでまとまる）

Unit

• 親アカウントから複数の子アカウントを作るだけでなく、グループ分けができるようになった
• ユニットは、作って階層構造の切り替えが比較的容易にできる
• ユニットにはSCPを設定できる

例

• UnitA <- SCP1
  • account1
  • account2
• UnitB <- SCP2 → IAM
  • account3
  • account4
• UnitC

SCP(サービスコントロールポリシー)

• Allow
• Deny

アカウントの分け方

• アカウントをサービスごとに作る
• ユニットを環境ごとに分ける

例

• Unit Service - 本番
  • account-Service-A
  • account-Service-B
• Unit Sandbox - 開発環境
  • account-Service-A-dev
  • account-Service-B-dev

ユニットやアカウントを分けるメリット

• 各サービスごとのコストが正確にわかる

IAM Role

例

• role
  • reader（読み取り）
  • developer（全部読み取り、一部書き込み）
  • admin
  • analyser
  • poweruser（読み取り、一部書き込み）
• user
  • tanaka
  • yamada
  • suzuki
    

asume-role

• tanakaがreader, developerのroleになれる権限を持っている
• ユーザーはポリシー・権限を持たない。どのロールになれるかだけを持つ
• クロスアカウント設定を許可できる
  • サービスごとに複数のアカウントを切り替えてログインする必要がなくなる

理想のユニット構成

親アカウントにmasterのroleを付与（各サービスアカウントに最上位の権限を付与するため）
→これが漏れるとまずいので封印が必要

• OU - admin
  • employee
  • log
    • 各環境にあるログを監視するのはあまり良くない
    • S3にログを集約
    • ≒ Athena → BI, シームで可視化
• OU - service
  • service1
  • service2
• OU - sandbox
  • service1-dev
  • service1-qa
  • service1-stage
• OU - network
  • transit
    • transit gatewayを作るためだけのアカウント
• OU - office(仮)
  • office
    • 社内用。TGを使ってサービスとの相互通信もできる
    • 監視もできる

相互通信

• サービス間の相互通信をグローバルネットワーク経由でやるべきではない
• transit gatewayを経由して、プライベートネットワークでやる

自宅から

• transitアカウントで認証して、グローバルネットワークを使わずに完結できる

どうやって理想に持っていくか

第一段階

AWS CLI

1. Organization作成
2. Unitを作成
   • service
   • admin
3. 子ID作成 → Unitに移動
   • service1
   • service2
   • service3
4. 監査系 IAM VPC 流す

CloudFormation

1. 既存アカウントのassume-role設定

第二段階

• employee化（クラウドフォーメーションを流す）

移行が終わったら？

• アプリケーションコードの改良

移行の壁

• yaml書くのだれる
• デバッグ面倒
• 設計して、コード書くのが大変
• 最新機能はAPIだけだったり、CLIしかなかったりする
• CloudFormationでできるのはその後

関連記事

• AWSアカウントを取得したら速攻でやっておくべき初期設定まとめ