AWSアカウントを「環境の境界」として設計する
アカウント分離は請求を分けるためだけではない。事故の影響範囲を小さくし、誰がどの環境を操作できるかを一本化する設計である。
TL;DR
- 環境名は短く一貫して命名し、リソース名・ドメイン・IaCの認知負荷を下げる。
- Organizationsでstgとprdを別アカウントに置くと、権限と障害の境界を明確にできる。
- Identity Centerで人のログインと権限セットを管理し、個別IAMユーザーに依存しない。
01名前を環境の識別子として固定する
人が読む名前と自動化が扱う名前をずらさない
環境名を三文字のサフィックスなどに統一すると、リソース名、サブドメイン、Terraformの変数で同じ意味を保てる。後から表記揺れを直すコストを避ける基礎設計だ。
命名は見た目の問題ではない。操作対象を取り違えないための安全装置である。
- 環境名の語彙を先に決める
- 名前の位置とケースを統一する
- ドメインでも同じ略称を使う
02Organizationsで環境を物理的に分ける
stgとprdはタグや名前ではなくアカウントで隔てる
Organizationsで管理アカウントの下にstg・prdのメンバーアカウントを作る。片方の環境で誤操作しても、もう片方のリソースは別のアカウントにあるため同じ権限では触れない。
アカウント分離は「本番だけ特別に注意する」運用ではなく、普段から越境しにくい構造を作る方法である。
- 管理アカウントは組織設定を担う
- stgは検証用リソースの境界
- prdは本番用リソースの境界
03人のアクセスはIdentity Centerへ集約する
誰にどのアカウントの何を許すかを中央で追えるようにする
Identity Centerにユーザーを置き、アカウントごとに権限セットを割り当てる。個別のアクセスキーやIAMユーザーを増やすより、入退室の管理を一箇所で確認しやすい。
管理アカウントへの日常ログインを減らし、必要な環境へ必要な権限だけを渡す。
- ユーザーはIdentity Centerで認証する
- 権限セットができる操作を定義する
- アカウント割り当てで操作先を決める
結論
- 命名・アカウント・認証を同時に整えると環境境界が明確になる。
- stgとprdを分ける理由は、事故と権限の影響範囲を分けるため。
- 人のアクセスはIdentity Centerを起点に追えるようにする。