個人アカウントでも AWS Organizations と IAM Identity Center を使う a.k.a. 古の AWS アカウントにかけられた東京リージョン az-a の呪いからの脱出

アカウント温故知新と東京リージョン 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

参考情報