AWS移行時のアカウント管理の考え方（エンタープライズ向け）
今週勉強したことのアウトプットです。
オンプレの環境をAWSに移行します、となったときに考えることの一つに
アカウント管理があります。
大きく分けて
・シングルアカウント
・マルチアカウント
のいずれかで運用を考えることになるかと思います。
どちらにもそれぞれメリット、デメリットはありますが、ここではエンタープライズを対象として個人的な見解を書いていこうと思います。
マルチアカウントのメリットデメリットの資料は以下が参考になります。
さて、結論から言ってしまうと個人的にはマルチアカウント運用をオススメします。
その理由は以下の3点です。
セキュリティの観点
セキュリティの観点では複数の環境(業務システム、会計システム、本番、検証など)がある中で
「誰が」「どの環境に」「何をしていいのか」を制御する必要があります。
これをシングルアカウントでやる場合、IAMで制御がとても複雑になります。
例えばAさんは業務システムと人事システムしか触らせないポリシーとした際に、人事システムはもう触られたくない、となった際には
ポリシーを編集する必要があります。
また、システムが増えるたびにポリシーを編集する必要があるので設定もれや解除もれと言うことが発生しやすくなります。
これをマルチアカウントで実施すると、システムや環境ごとにアカウントを切ることで管理コストを下げることができます。
そのシステムや環境に対するポリシーのみ考えれば良いですし、ドメイン単位でアカウントを括ることで例えば会計というドメインであれば同一のポリシーで良いとすることで管理はグッと楽になります。
また、機密情報を持つサーバーなどでサブネットを分ける場合にも
シングルアカウントの場合は多数のシステムが乱立していると管理しにくい面もあります。
コスト管理の観点
AWSに関する費用請求はアカウント単位になります。
なのでシングルアカウントの場合、複数のシステムや子会社のシステムなどが同じアカウント内にいるしても、料金としては一まとめにされてしまいます。
タグである程度分けることはできますが、ネットワークに関する部分はタグ付できないので正確にコストを明確化することはできません。
これに対してマルチアカウントであれば、そのアカウントごとに請求書が出るので、何にどれだけのコストがかかったのかが明確になります。
この辺りは企業ごとの考え方にもよります。
例えばHD会社で複数の事業会社のシステムがAWS上にある場合でも
費用は一括でIT子会社が受け持って、各子会社からは一定額をプールするという考え方もありますし
明確なコストを出して、各事業会社にかかった分だけ費用請求するという形にもできます。
前者であればシングル、後者であればマルチのような考え方です。
リスクの観点
個人的にはこれが大きいと思います。
シングルアカウントの場合、全部のリソースが見えてしまうんですよね。
例えば検証環境のサーバーを触っていたつもりが、実は本番環境でした、なんてことが起きやすいんですね。
会計システムの管理者が、人事システムのEC2ものぞけてしまう、なんてことがあり得てしまいます。。。
これはセキュリティリスクの観点もありますし、オペミスのリスクとしてもシングルアカウントはまぁまぁのリスクを抱えることになります。
これに対してマルチアカウントの場合はアカウントごとに見えるリソースが分かれるので、誤操作と言ったことはなくなります。
ここまでマルチアカウント推しの内容を書いてきましたが、もちろんマルチアカウントは万能ではなく、デメリットもあります。
結局は大事にする観点はなんなのか？を整理しながら企業のポリシーごとに決めていくことになります。
以前はマルチアカウントは運用的に煩雑になることが多かったので、あまり採用されなかったようですが、
今はTransit GatewayやOrganizations、Cloud Formationなどいろんな技術を組み合わせることでマルチアカウントのデメリットをカバーできるようになってきています。
ベストプラクティスを目指すにはいろいろ考えるべきポイントがあると思うので引き続きキャッチアップを進めていこうと思います。