アカウント温故知新と東京リージョン az-a の呪い
昔話になりますが、私は個人の AWS アカウントを 東京リージョンが利用可能になった 2011年 に作成しました。それ以降 EC2 をはじめとして散発的に AWS リソースを使用してきましたが、時代とともに古いアカウントならではの制限事項が目につくようになってきました。
制限事項の中で最も大きいのが 古い AWS アカウントでは東京リージョンのアベイラビリティゾーン a が使用できない という問題です。AWS CDK しかり、Cfn しかり、何かのハンズオンしかり、基本的に新しめの(?) AWS アカウントを想定しており、その度に「他の人のアカウントではうまくいくが自分のアカウントだとエラーになってしまう」ケースが「稀ではなくよくある」事態となっていました。
こういった経緯を含め、アカウント管理の体制を一新して AWS Organizations + IAM Identity Center での運用に切り替えたところ AWS のユーザー体験はかなり向上しました(古いアカウントは管理用のマネジメントアカウントとして残していますが場合によっては削除するかもしれません。また、個人アカウントとは別に同様の管理方法で個人事業向けのアカウントも別口に用意しています。こちらは将来の法人化を見据えたものになります)
AWS 公式で複数アカウントでの運用が推奨されている
複数アカウントでの運用については参考情報にあげたリンクを含めて AWS が豊富なベストプラクティスとガイドラインを出しています。主に AWS Organizations と IAM Identity Center を利用することになります。監査用に Control Tower や AWS Confing を利用してもよいですが個人アカウントでは不要なケースが多いと思います。
ただ、AWS 初心者にとってこれらのベストプラクティスとガイドラインを最初から理解し実装するのはなかなかハードルが高いのではないでしょうか。どちらかというと既に AWS でいくらかの経験があり、リソースや Billing 情報の管理で効率化を図りたい既存ユーザーが複数アカウント運用に切り替えると、ユーザー体験がかなり向上するのではないかと睨んでいます。
押さえておきたいベストプラクティス
AWS で推奨されているベストプラクティスです。AWS ハンズオンを受講した方は一番最初のスライドで「他リソースへの影響を避けるために専用のアカウントを作成することを推奨〜」という断り書きを目にした方も多いと思います。アカウントは「目的ごとにフットワーク軽く作る」ことがプラットフォーム側からも期待されているのです。
- アカウントにおける AWS Organizations の OU 構造とメールアドレス構成要素を一致させる。こうすることでどのアカウントにどのメールアドレスが紐づいているのか一目瞭然になり管理がしやすくなる(以下は、AWS のドキュメントで紹介されているベストプラクティスの具象化を私なりに行なった結果です。例として John Smith さん(jsmith@gmail.com) さんが xenogeneic という会社で admantine と bomburst という 2 つのサービスを AWS で開発かつデプロイしている場合、アカウント運用は以下のようになります)
| AWS アカウント | アカウントのメールアドレス | AWS Organizations の Organization Unit および配下のメンバーアカウント |
|---|---|---|
| xenogeneic | jsmith+aws+xenogeneic@gmail.com | Management Account |
| adamantine-prod | jsmith+aws+adamantine+workload+prod@gmail.com | Workload/Prod/adamantine-prod |
| bomburst-prod | jsmith+aws+bomburst+workload+prod@gmail.com | Workload/Prod/bomburst-prod |
| bomburst-dev | jsmith+aws+bomburst+workload+sdlc+dev@gmail.com | Workload/SDLC/bomburst-dev |
| handson-20240103 | jsmith+aws+xenogeneic+sandbox+handson-20240103@gmail.com | Sandbox/handson-20240103 |
| xenogeneic-infrastucture | jsmith+aws+xenogeneic+infrastructure+prod@gmail.com | Infrastructure/Prod |
| xenogeneic-security | jsmith+aws+xenogeneic+security+prod@gmail.com | Security/Prod |
- AWS の新機能の試用やハンズオンは一時利用するアカウントを OU: Sandbox 配下に作成して実施する。こうすることでアカウント単位で Billing 情報を独立させ可視化/監視することができ、結果的にリソースの無駄遣いを防ぐことができる。基本的に Sandbox 配下のアカウントで料金が発生することはない。ハンズオン実施時にアカウントを削除してしまってもよい。
- AWS Organizations のルートの頂点となる Management アカウントは管理専用にし、開発やテストなどを行わない。つまり、ワークロードを持たせない。
※OU: Organization Unit, SDLC: Software Development Life Cycle
スクリーンショット
IAM Identity Center のポータル経由のログイン例
Sandbox 配下のアカウント運用例
個人的なベストプラクティス
以下は私が個人的に採用している運用上の工夫です。
- IAM Identity Center における Group と Permission Set を一致させています。Rails におけるテーブル名(複数)とモデル名(単数) の Naming Convention を適用しています。BizPeople には営業やマーケティング担当を含みます(基本的に非エンジニアに与えるポリシーは AWS で見るべき情報は Predefined permissions で用意されている Billing のみ になる ので営業、マーケティング、経理を別々にする必要はないいう判断)
| Group | Permission Set | Predefined Policies |
|---|---|---|
| Administrators | Administrator | AdministratorAccess |
| SREs | SRE | SystemAdministrator |
| Engineers | Engineer | ReadOnlyAccess (デフォルトはこれで、ここから ABAC で Switch Role させる) |
| BizPeople | BizPerson | Billing |
- IAM Identity Center や ABAC の運用/確認のためにダミーの架空ユーザーをあらかじめ作成しておく。アクセスコントロールの確認はこれらのダミーユーザーのメンバーアカウントを通して行う。
| Username | Name | Primary Email | Title | Division | Department |
|---|---|---|---|---|---|
| ramuro | Ray Amuro | [DefaultEmailAccountBeforeAtMark]+aws+[ProjectName]+ramuro@gmail.com | sfe | gundam | origin |
| myashima | Mirai Yashima | [DefaultEmailAccountBeforeAtMark]+aws+[ProjectName]+myashima@gmail.com | sre | gundam | origin |
| blinks | Banagher Links | [DefaultEmailAccountBeforeAtMark]+aws+[ProjectName]+blinks@gmail.com | sfe | gundam | unicorn |
| mlzabi | Mineva Lao Zabi | [DefaultEmailAccountBeforeAtMark]+aws+[ProjectName]+mlzabi@gmail.com | salesrep | gundam | unicorn |
※sfe: Software Engineer, sre: site reliability engineer, salesrep: sales representative
IAM Identity Center を使う場合は aws configure sso で期限付きの credentials 情報を作成する
aws configure sso を利用して期限付きの credentials 情報を発行したのちに aws cli や SDK を利用します。
~/.aws/cli/cache 配下に期限付きの AWS ACCESS KEY と SECRET ACCESS KEY が発行されキャッシュされた .json が作成されます。またこちらと対になる形で ~/.aws/sso/cache 配下にはセッション情報がキャッシュされた .json が作成されます。結果的に通常の ~/.aws/credentials は不要になります。
➜ aws configure sso
参考情報
- Best Practices for Organizational Units with AWS Organizations | AWS Cloud Operations & Migrations Blog
- Best practices for member accounts - AWS Organizations
- 個人でもAWS Organizationsを使ったほうが良い理由 - 本日も乙
- AWSのSSO導入において工夫したポイント5選 #Terraform - Qiita
- 15分で教えるAWSの複数アカウント管理 #AWS - Qiita
- 【AWS】ひとりでもOrganizationsを使うと便利で勉強になる話(AWS SSOの始め方を手厚く) #AWS - Qiita
- Token provider configuration with automatic authentication refresh for IAM Identity Center - AWS Command Line Interface
