【要約】【AWS Organizations】個人アカウントで一人アドミンに挑戦してみた！(org環境の作成編) [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
AWSのマルチアカウント管理を導入する際、単にアカウントを増やすだけではガバナンスが効かず、管理コストが増大する。特に、個人や小規模チームが実務に近い統制環境を構築しようとする際、以下の課題に直面する。
- ・アカウント作成時に必要な、一意なメールアドレスの確保。
- ・新規作成アカウントと既存招待アカウントにおける、IAMロールや制約の仕様差。
- ・アカウント閉鎖や組織離脱に関する、AWS側の制限事項の把握不足。
// Approach
筆者は、既存の個人アカウントを管理アカウントとして利用し、Sandbox環境を想定した組織構造を段階的に構築する手法を採用した。
- ・AWS Organizationsによる組織の立ち上げと、階層管理のためのOU（Sandbox）の作成。
- ・Gmailのエイリアス機能を活用し、メールアドレスの重複を避けたメンバーアカウントの新規作成。
- ・
invite-account-to-organizationおよびaccept-handshakeを用いた、既存アカウントの安全な招待。 - ・CLIを用いた非同期API（
create-account）のステータス確認と、move-accountによるOUへの配置。
// Result
本手順により、管理者が組織の基盤となるアカウント集約プロセスを完了させた。
- ・コンソールとCLIの両方で、OU作成からアカウント移動までの操作手順が確立された。
- ・新規作成アカウントと招待アカウントの仕様差（Roleの有無や離脱待機期間）が明確化された。
- ・後編におけるSCPやタグポリシーによる統制に向けた、準備段階が整った。
Senior Engineer Insight
> マルチアカウント戦略の第一歩として、OUによる論理的分離と、招待・新規作成の仕様差を理解することは極めて重要だ。特に、招待アカウントに
OrganizationAccountAccessRoleが自動生成されない点は、運用自動化の設計時に見落としがちなリスクとなる。また、アカウント閉鎖のクォータや離脱待機期間といった「消せない・離れられない」制約を事前に把握しておくことは、Sandbox環境の乱用による管理不能状態を防ぐために不可欠である。