iCAREにおけるAWSマルチアカウント運用事例
こんにちは！インフラエンジニアのずやです！
今回はAWSのマルチアカウント運用について弊社での事例を紹介したいと思います。
なお、この記事はiCARE Advent Calendar 2020の7日目の記事です。
AWSのマルチアカウントとは
一つの組織において複数のAWSアカウントを契約し利用することを示します。
AWSアカウントを複数利用することには、主に下記三つの観点での利点があると考えています。
・セキュリティ
・コスト管理
・リソース管理
1点目はセキュリティです。AWS IAMのベストプラクティスの一つとしてIAMユーザ(IAMロール)に与えるアクセス件は必要最低限とするというものがあります。特に本番環境のリソースへのアクセス権はエンジニア内でも最低限に留めたいというケースは多いと思います。一方で開発用のリソースへのアクセス権まで強く制限してしまうと、都度権限の緩和を行う必要があったりと大変不便で開発スピードの低下に繋がりかねません。タグベースでうまくアクセス権設定をすることも可能ですが煩雑になりがちで管理コストが大きくなってしまいます。そこで、AWSアカウントを本番環境/開発環境で分離することでIAM自体も分離されるので、各アカウントでアクセス権限を適切に設定するだけで済むようになります。
2点目はコスト管理です。リソースの用途別にコストを可視化したい場合、単一アカウントではコスト配分タグを設定してフィルタリングする必要があります。対象とするリソースにタグをつけるという多少の手間もありますし、そもそも転送量といったリソースではない課金要素については分別することはできません。アカウントを分けてしまえば請求もアカウント毎になるため、明確にかつ楽に用途別のコスト可視化を行うことが可能です（後述するAWS Organizationsにより一括請求が可能で、請求額はアカウント別に表示されます）。
3点目はリソース管理です。AWSではアカウント毎にリソース数の上限があったり、リソース名の重複ができなかったりなどの制限があります。アカウントを分離することでこれらの制限もある程度気にせずに利用することができます。
AWS Organizations
AWS Organizationsは複数のAWSアカウントを一元管理するためのサービスで、以下のような機能があります。
・AWSアカウントの階層構造によるグループ化および権限管理
・複数アカウントの一括請求
・新規アカウント作成作業の簡素化
AWS Organizationsの詳細については下記リンクを参照ください。
AWS Black Belt Online Seminar AWS Organizations
弊社のマルチアカウント化事情
弊社では長らくシングルアカウントでの運用を続けてきていましたが、開発チームの規模も大きくなり会社としてセキュリティもさらに強化していくフェーズのため、ついに今年（2020年）9月からマルチアカウントでの運用に移行しはじめました。
さっそくですが弊社のAWSアカウントの構成は下図のようになっています。
（現在リソースの移行を順次進めている段階で、まだ全てのリソースを下図の通りに分離できているわけでありませんので、その点ご了承ください。）
マスターアカウントはAWS Organizationsの親アカウントとなり、子アカウントの管理や一括請求の請求先になるアカウントです。
子アカウントは弊社のプロダクトCarelyのリソース用アカウントと、会社のWebサイトや製品LPのCMS用のマーケティングアカウントの大きく二つに別れています。Carely用アカウントはさらに本番環境用と開発環境用に分けています。
アカウントを分ける単位については様々なプラクティスが世の中にあると思いますが、今回はリソースへのアクセス権限の境界を軸に最低限の数のアカウント分割を行いました。
具体的には、Carelyアカウントはエンジニア、マーケティングアカウントはマーケター（と一部のエンジニア）というように 利用者が異なるため、まずこの二つのアカウントを分割しました。次にCarelyの本番環境は基本は閲覧権限のみで限られたエンジニアだけリソースの追加・変更をできるようにしたい一方で、開発環境はエンジニアであれば自由にリソースをいじれる環境としたいというように権限の強度が違うため、Carelyアカウントを環境によってさらに分割しました。
より細かくアカウントを分けたり、ログ集約用などの役割別にアカウントを用意することもできますが、エンジニアのリソースが限られる中でこれ以上アカウントを一気に増やすと、アカウント分割のメリット以上に管理コストが大きくなってしまうと判断しました。もちろん今回の構成がゴールではなく、組織の成長に合わせて継続的にアカウント構成の見直しをしていく必要があると考えています。
マルチアカウント下でのアカウント切り替えの方法
マルチアカウント化する際には「アカウントの切り替え方法」についても考える必要があります。
愚直な方法としては、各アカウントでそれぞれIAMユーザを作成するという方法があります。しかしユーザ・管理者ともに複数・多数のIAMの管理が必要となってしまい、特にアカウント数が多くなる場合には適切ではありません。
幸いにもAWSには複数のアカウントを切り替えて利用するための仕組みとして、スイッチロールという機能やAWS SSOというサービスがあります。それぞれ詳細は下記の記事を参照ください。
・Swith Roleで複数のAWSアカウント間を切替える
・AWS Single Sign-On（SSO）でAWSアカウントへシングルサインオン
弊社ではAWS SSOを採用し、全社員にアカウントが付与されているGoogle Workspace（旧G Suite）をIdPとして利用しています。設定方法は下記のAWSさんのブログを参考にしました。
G Suite アカウントを用いた AWS へのシングルサインオン
AWSへログインする場合、利用者はまずOrganization単位で決められたポータル画面のURLにアクセスします（URLはAWS SSOからカスタムが可能です）。
すると、AWS SSOに設定したIdP（今回の場合はgoogle）の認証画面へリダイレクトします。
IdPでの認証が成功するとポータル画面へ再度リダイレクトします。
ポータル画面ではユーザ毎にアクセス可能なアカウントと権限セットの組み合わせが表示され、「Management console」のリンクからマネジメントコンソールへアクセスできます。また、「Command line or programmatic access」からはAWS CLI用の一時的なアクセス情報を取得することもできます。
管理者側の操作もシンプルで、ユーザを新規追加する場合にはAWS SSOで該当のgmailアドレスをユーザ名として設定したユーザを作成し、適切な権限セットを割り当てるだけなど、非常に管理が楽になります。
その他AWS SSOに関する詳しい情報は下記リンク先を参照ください。
AWS Black Belt Online Seminar AWSアカウント シングルサインオンの設計と運用
おわりに
今回は弊社におけるAWSのマルチアカウント化の事例を紹介しました。
これからマルチアカウントへの移行を検討中の方や、アカウント切り替えの方法に悩んでいる方の参考になれば幸いです。
最後に、弊社ではエンジニアを絶賛大募集中です！
興味のある方はこちらから是非ご応募ください！
