個人AWS環境でもOUを作り、アカウントの役割を整理した

前回はアカウントを三つに分けた

第6回では、管理・本番・検証をsamekoro-management、samekoro-prod、samekoro-labへ分けました。ログイン先を選ぶ時点で作業の目的を意識できるようになり、一つのアカウントへ集めていた時より境界が見えます。

ただ、AWS Organizationsの画面でメンバーアカウントが並んでいるだけでは、名前から役割を読んでいる状態でした。数が三つなら困りませんが、Organizationsを使う意味がアカウント一覧だけなのかは気になりました。

OUはOrganizational Unitの略で、組織内のAWSアカウントをまとめる単位です。説明を読むと企業向けの大きな構成に見え、個人環境で作るのは少し大げさだと思っていました。

実際、アカウント名にはすでにprodとlabが入っています。名前で分かるなら、さらに同じ名前のOUを作るのは二重管理にも見えました。

それでもOUを試したのは、次にSCPを適用したいと考えていたからです。アカウントの名前だけでなく、どのまとまりへ制御をかけるのかを形にしておく必要がありました。

今回は次の二つのOUを作りました。

そのうえで、samekoro-labをLab OUへ、samekoro-prodをProd OUへ配置しました。管理アカウントsamekoro-managementと二つのメンバーアカウントの役割が、一覧の名前だけでなく組織の構造として見えるようになりました。

作業自体よりも、どの単位で分けるかを決めるほうに時間を使いました。環境名、用途、サービス単位など分け方はいくつも考えられます。今回はアカウント名と運用目的がすでにLabとProdで揃っていたため、その境界をそのままOUにしました。

画面上では、OUはアカウントを入れるフォルダのように見えます。最初は見た目を整理するための箱だと捉えていました。

しかし次のSCPを考えると、重要なのは見た目よりも適用先です。Lab OUへポリシーを付ければ、検証側というまとまりを対象にできます。アカウントを一件ずつ選ぶのではなく、役割に対してルールを置ける形です。

ここで、OUを作った意味がようやくつながりました。今回の二つは小さな構成ですが、今後アカウントが増えた場合も、同じ役割のOUへ置くという判断基準を残せます。

OUは入れ子にもできますが、今回はLabとProdより深くしませんでした。個人環境で階層を先に作り込んでも、実際のアカウントやルールがなければ空の分類が増えるだけです。

企業なら、組織、部署、環境、システム、セキュリティ要件などを踏まえ、OUを移動した時の影響も含めて設計します。SCPなどのポリシーが階層を通して効くため、見た目の好みだけでは決められません。

一方、今回のSAMEKORO LABでは、次に試す制御を置ける最小限の構造で十分でした。必要になった時に増やし、今は理由を説明できる二つだけにしています。

samekoro-labがLab OU、samekoro-prodがProd OUに入った画面を見ると、三つのアカウントを作っただけの状態より役割が読みやすくなりました。

アカウントは作業場所、OUは同じ扱いをしたいアカウントのまとまりです。この二つを分けて考えられるようになったことで、次に「Lab側だけへ制御を付ける」という話へ進めます。

最初は、個人環境ならアカウント名だけで十分だと思っていました。実際にOUを作ると、整理のためのフォルダではなく、役割ごとにルールを置くための境界だと分かりました。

第8回では、このLab OUへDenyLeaveOrganizationというSCPを適用し、メンバーアカウントが組織から抜けられないことを実際に確認します。