会社のAWSアカウントでAWS Organizationsの整理をした

社内整理の一環で、社内AWSアカウントにてAWS Organizationｓを利用して環境の整理を行いました。
特にOUとメンバーアカウントの整理はなかなか悩んだので書いておきます。

AWS Organizationsについて

複数のAWSアカウントを一元管理し、組織全体のポリシーを適用するためのサービスです。　　
複数アカウントに対するセキュリティのルールをシステム的に敷いたり、コンプライアンス、コスト管理が容易になるのが魅力です。

背景

これまで案件ではFirebaseやGoogle Cloudを使ったり、AWSを使ったりと利用サービスが様々でしたが、今後は周辺技術なども考慮しAWSに寄せていきたいという話になりました。　　
また社内AWSアカウントでは、育休中のメンバーが既にAWS Control TowerとAWS Organizationsのセットアップを済ませており、なんとなく使用されていました。

弊社はクライアントワークを行っておりますが、場合によってはアプリケーションのホスティングを自社のアカウントで行う場合があります。後々アカウントをクライアントに引き渡す場合を考えると、新たにアカウントを作ってセットアップする方が良いとは思いますがなかなか大変です。かといって1つのAWSアカウントの中に複数クライアントのサービスが同居する状況は回避したいです。

また、社内で活用しているツールがAWSやGASに存在し、この辺りも合わせて管理できるといいよねという話になりました。

こういったことをAWS Control　TowerとAWS Organizationsで解消できそうだというところからあらためて導入・整理をしてみました。

OU(組織単位)の分割はどうするか

早速ですが、AWS Organizations内では、OU(組織単位)と組織ごとにメンバーアカウントを発行し、運用していきます。
調査・検討を進めていくなかで、OUはセキュリティポリシーを充てる対象にもなりうることから、AWS Organizationsを運用していくうえで、どういった単位でOUを切るかは結構重要な事だと感じました。

色々と考え方がありそうですが、AWS Organizations における組織単位のベストプラクティス
にある程度のっておくのが良さそうでした。

ただ、すべて乗らずこれを見据えて状況に応じて少しずつ作っていくと良いという話を元に、今はこの形に落ち着いています。

┠━　Products　 // プロダクト用OU
┃　　　　　　　　┠━ プロダクト名
┃　　　　　　　　┃　　　　　　　┗━ Stg // 環境OU
┃　　　　　　　　┃　　　　　　　　　　　　　┗━ メンバーアカウント
┃　　　　　　　　┗━ InternalTools // 社内ツール
┃　　　　　　　　　　　　　　　　┗━ Prod // 環境OU
┃　　　　　　　　　　　　　　　　　　　　　　┗━ メンバーアカウント
┠━　Sandbox　 // 実験用用OU
┃　　　　　　　　┗━ メンバーアカウント
┠━　Security　　// 監査用OU
┃　　　　　　　　┠━ Audit
┃　　　　　　　　┗━ Log Archive
┠━　Saspend　 // 休眠用OU
┃　　　　　　　　┗━ メンバーアカウント
┗━　管理アカウント

SCPの適用や更新を環境別にやれる方がいいのでので環境用のOUを作っています。

Products

プロダクト開発用のOUです。今後社内のプロダクトの開発が始まった際はこちらで管理します。
今は社内ツールのOUを作って中で管理しています。

Sandbox

新しいサービスの検証や案件用のAWS環境が整うまでの先行開発に使っています。

Saspend

使わなくなったメンバーアカウントの退避場所としています。
現在SREのようなメンバーが居ないため、こういった管理をエンジニアのリーダー陣で行っています。完全な削除まで少しタイムラグが空いたりするため、休眠状態として扱う用のOUを設置しています。
専用の休眠ポリシーを設定しており、作業の制限をかけることで不要なリソースの使用を防いでいます。

今後

まだ実際に管理するシーンが訪れていませんが、クライアント様の環境を預かる事になったら workloads OUを作ることになるかなと思っています。

参考

その他OUの分割をはじめ、Organization周りは以下を参考にしました。
https://blog.serverworks.co.jp/oranizations/ou/design
https://tech.asken.inc/entry/2022/08/16/170000

メンバーアカウントと作業者のIAMユーザーについて

メンバーアカウントの名称は、OU踏まえると少し冗長ですが、ログイン時や表示されたときに分かりやすいほうがいいよねということから、 {案件名}_{役職}_{環境}　という形式にしています。(例: product_developer_stg)少し長いというところ以外は現状困りごとは無いかなと思っています。

作業者のIAMユーザーについて

IAMユーザーは、案件にアサインされているメンバー毎に必要に応じてIAM Identity Centerから作成しています。

AWS Organizationｓのメンバーアカウントには適宜グループを作成・紐づけし、そこにIAMユーザーを所属させています。アサインが途中で変わることもありえるため、権限管理は個々にせずグループ単位で管理するようにしています。

グループ	役割	概要	許可セット
FNT{プロダクト名}Developer	開発者	インスタンスの作成や変更を行うAWSAdministratorAccessはCLIのキーを発行する時のみ。普段遣いはAWSPowerUserAccessとする	AWSAdministratorAccess AWSPowerUserAccess
FNT{プロダクト名}ReadOnly	プロジェクト管理者	サービスの状態確認、費用感確認	AWSReadOnlyAccess　　AWSBillingReadOnlyAccess

※AWSで作成されたグループと差別化するため、頭にFNTをつけています。

整理してみて

とりあえず始めてみるというタイミングでは、いい具合の整理ができたかなと思っています。
今後も必要に応じて適宜テコ入れしていければなと思っています。