AWS Organizationsで管理・本番・検証アカウントを分けた話

前回までのあらすじ

第5回では、ルートユーザーを普段の入口にせず、IAM Identity CenterからAWSへ入る運用へ切り替えました。入口を分けたあとに気になったのが、その先にあるAWSアカウントの分け方です。

最初にSAMEKORO LABを作り始めた頃は、一つのアカウントの中で必要なサービスを動かせば十分だと思っていました。個人で使う環境なので、アカウントを増やすほど管理が複雑になるように見えたからです。

ただ、サイトとして残したい環境と、これから試す設定が同じ場所にある状態は落ち着きませんでした。入口だけ整えても、作業先が一つなら、本番を触っているのか検証しているのかを毎回自分で意識し続ける必要があります。

一つのアカウントには、分かりやすさがあります。ログイン先を迷わず、請求や設定を見る場所も一つです。S3、CloudFront、Route 53など、これまで使ってきたサービスを同じ画面で確認できるのも便利でした。

その一方で、新しい設定を試すたびに「これは公開中のサイトへ影響しないか」を先に考えるようになりました。試したい気持ちはあっても、残したい環境と壊してもよい環境が同じだと、操作の一つひとつが慎重になります。

ここで、アカウントを増やすことを単なる管理項目の追加ではなく、役割の境界を作ることとして考え直しました。

AWS Organizationsは、複数のAWSアカウントを一つの組織として管理する仕組みです。今回の環境では、次の三つに分けました。

名前を並べただけでは、最初はアカウントが三つに増えただけにも見えました。実際に使い分けると、ログイン先を選ぶ時点で「今日は何をするのか」を決める形になります。

公開中のものを扱うならprod、試して結果を確認するならlab、組織全体に関わる作業ならmanagementです。操作の直前ではなく、入口で目的を分けられるようになりました。

管理アカウントは、名前だけを見ると最も強くて便利な作業場所に見えます。最初は、ここへ主要なものを置けば三つに分けたあとも迷わないのでは、と考えました。

しかし、それでは一つのアカウントへ集めていた時と発想が変わりません。管理アカウントは組織を管理する役割、本番と検証はそれぞれのメンバーアカウントという境界を優先しました。

今回の記事で扱っているのは、サービスをどこへ移したかという作業手順ではありません。まずアカウントの役割を決め、これから行う作業の置き場所を揃えた段階です。

構成図やアカウント一覧だけでは、分けた実感はまだ薄いままでした。そこで前回作ったAWS Access Portalから、samekoro-management、samekoro-prod、samekoro-labの三つへ実際にログインしました。

同じsamekoro-adminから入れても、選んだ先は別のAWSアカウントです。この違いを画面で確認したことで、IAM Identity Centerは入口をまとめ、AWS Organizationsは作業先を分けるという役割がつながりました。

アカウントを分けたから自動的に安全になるわけではありません。それでも、どこで何をするかを名前とログイン先で確認できるようになったことは、今後の作業を整理する土台になりました。

今回は自分一人の環境なので、管理・本番・検証という最小限の三役から始めました。担当部署やシステムごとに細かく増やすのではなく、今のSAMEKORO LABで使い分けられる数にしています。

企業で行うなら、アカウント作成の申請、命名規則、連絡先、請求、ログの集約、緊急時のアクセスなども合わせて決める必要があります。単にアカウントを作るだけでは、運用の境界にはなりません。

個人環境でも、役割を言葉にしてから分けたことで、「何となく別アカウント」にはせずに済みました。小さい環境だからこそ、構成を変えながら違いを確かめられた部分です。

今回変えたのは、AWSサービスの設定ではなく、作業を置く単位でした。一つに集めたほうが簡単だと思っていましたが、残したい環境と試したい環境を分けることで、ログイン先を選ぶ意味がはっきりしました。

次に気になったのは、三つのアカウントが並んでいるだけで十分なのかということです。第7回では、LabとProdのOUを作り、アカウントの役割を組織の中でも見分けられるようにした話をまとめます。