はじめに
現職でHD会社のIT部門でAWS移行を担当しています。
AWSのアカウント管理の考え方について勉強したので一度整理してみます。
AWSアカウントの種類
まず、AWSで扱うアカウントには以下の種類があります。
・AWSアカウント(root)
・IAMアカウント
・組織アカウント
AWSアカウント
AWSを利用する際に登録するアカウントで、全ての権限を持っています。
非常に強力なアカウントのため、通常は使用しないようにします。
IAMアカウント(ユーザー)
各サービスやマネージメントコンソールのログインの際に使用するユーザー。
ポリシーをアタッチすることで操作できる範囲や権限を指定します。
組織アカウント(Organizations)
組織内で複数のAWSアカウントを扱う場合に、共通のポリシーなど統制を効かせるために
Organizationsというサービスがあります。
このサービスで利用する、複数のアカウントを管理するアカウントになります。
なぜIAMユーザーが必要なのか
AWSアカウント(root)では権限が強すぎるため、もし乗っ取りにでもあったらそのアカウント内では全ての操作ができてしまいます。
なので基本的にはrootアカウントは使わずに、IAMユーザーを利用します。
IAMユーザーには必要最小限の権限を必要最小限のユーザーに与えて運用することが基本です。
アカウント管理の考え方
アカウント管理にはいろんな考え方がありますが、
1アカウントに全てのシステムを構築し、複数のVPCを管理するやり方。
システムごとにアカウントを分けて、本番、ステージングなどの環境はVPCで分けるやり方。
１システム、環境ごとにアカウントを分けるやり方。
私の結論は１システム、環境ごとに1アカウントです。
理由は後述
複数のAWSアカウントを管理するには
複数AWSアカウントを作ると、管理が煩雑になってきます。
監査ログやセキュリティポリシーもアカウントごとにバラバラになってしまうと、統制が効かなくなってしまいます。
そんな時に利用できるサービスがAWS Organizationsです。
Organizations専用のアカウントを登録して、配下に組織内のAWSアカウントを紐づけることで
同一のポリシー(SCP)を適用したり、請求を一括管理することも可能です。
シングルアカウントとマルチアカウントどちらがいい？
「アカウント管理の考え方」の部分でも書きましたが、結局は
その組織で何を重要視するかに尽きると思います。
それぞれのメリットデメリットはクラメソさんの以下の記事が参考になります。
AWSアカウントとVPC、分ける？ 分けない？: 分割パターンのメリット・デメリット
その上で弊社では「１システム、環境ごとに1アカウント」の方向で進めることになっています。
これは、以下の点を考慮した結果となります。
・1アカウントでは各システム担当の領域外のリソースが見えてしまう。
→ポリシーで権限管理はしんどい。。。
・環境ごとに分けることで、誤操作の影響リスクを分断する。
・利用料金を明確にする。
→弊社がHD会社なので、複数事業者でどれだけ利用しているのかコスト管理が明確になる。
・OrganizationsやTransitGatewayなどマルチアカウント運用に最適なサービスが出てきている。
以上のことから、「１システム、環境ごとに1アカウント」としましたが、おそらくエンタープライズの企業であれば同じような状況で議題に上がるかと思います。
・社内に複数システムがある
・各事業部ごとにアカウントを分けたい(コスト把握、権限分離)
そのようなことを実現するにはベストプラクティスとしては「１システム、環境ごとに1アカウント」が正解なのではないかと思っています。
まだまだAWS学び始めて日が浅いので、「こういう考えもある」「そこは違う」などご意見ありましたら、コメントいただけるとありがたいです。