AWSには複数のAWSアカウントを管理する機能として AWS Organizationsがあります。
今までは複数のAWSアカウントがある場合、それぞれに個別でログインするかクロスアカウントを使ってログインを柔軟にコントロールすることができます。
具体的には複数のAWSアカウントを同じIAMユーザーのアカウントでログインできるようにしたり、請求を一つにまとめたりすることができます。
受託案件など複数の案件を管理する場合、AWSアカウントから切り分けをしておくことで開発・運用でのアクセスコントロールが強く行うことができたり、ユーザーが混在する状況を解決することができます。
要点
-
AWSアカウントの作成は簡単(ただしrootアカウントのパスワードリセットが必要)
- クレジットカード、電話認証がなくすぐに作成できました
-
Organizationsの単位はOU(組織)
- OUは社内の組織を表すイメージ
-
SCP(サービスコントロールポリシー)によってメンバーアカウント側の操作権限を付与する
- SCPのポリシをグループに付与しておき、グループメンバーをOUに紐付ける?
- 基本的にはメンバーアカウントのAdministratorの全権を渡すことになる?
-
組織に参加させてたり、脱退したりということが可能(未検証)
- 例として、初期開発時はOrganizationsで作成して途中からOrganizationsを脱退してお客さんに渡す、と言ったことが可能(だと思います)
-
費用
- まとめて請求
- ボリュームディスカウントがあれば全適用
- リザーブドインスタンスやセービングプランズの共用
- これは結構便利そうですが、代理請求の場合には計算が複雑になりそうです
- デメリットとして無料枠がなくなります(管理アカウントの作成から12ヶ月)
- おそらく3万円クレジットもなくなります
-
サポートの費用は組織毎
- 通常、メンバーアカウントに対する AWS Support のサブスクリプションは、組織全体には適用されません
-
既存のAWSアカウントがある場合、そこからメンバーアカウントを作るのではなく、別途新規で作ることがベストプラクティスとなるようです
懸念点
- OUの単位が組織のため、自分たちのようにプロジェクトごとに分ける用途とは違うかもしれない?
- SCPの付与がグループ毎のため、複数グループ(OU、プロジェクト)に属したモデルを再現できる?
- SCPでメンバーアカウントの全権が渡るため、パートナーさんで権限を制約することができない?
- 本番、開発でアカウントを分けて開発アカウントに全権などで分けると良いのではないか
- 本番、開発で分けるとき、途中から増やしたい時の階層構造はどうなる?
ログインの方法
Organizations経験者から
知り合いのOrganizationsに話を聞きました。
- 管理用アカウントは人の管理だけを行い、そこでリソースの利用はしないほうが良い
- PoC案件等もメンバーアカウントを作成し、そちらで行う。
- 管理用アカウントは人の管理に集中する。
参考