プロダクト基盤本部 SREの藤原です。
2022/12/13にSTORES Tech Talk AWS Organizations活用のリアルにて登壇いたしました。
本エントリはその補足です。
登壇内容について
当日は、AWS OrganizationsとIAM Identity Center, Terraformを連携した権限管理と題して、15分ほどトークを担当いたしました。
弊社におけるAWS OrganizationsとIdentity Center導入の経緯を説明した上で、oktaをIdPとした実際の構成、Terraformを組み合わせた運用について解説しました。 具体的なトーク内容については、リンクしているスライドを参照してください。
本エントリの経緯
本エントリを書いた経緯ですが、イベント当日にAWSを検証のために個人利用している場合のプラクティスを教えてくださいといった趣旨の質問をいただいていました。その場での回答はしたのですが、個人的にもう少し踏み込んだ回答をしたいと考えこのエントリを書くことにしました。 AWS OrganizationsおよびAWS IAM Identity Centerは個人で利用する場合も非常に有用なサービスです。 個人利用に限った回答をしてしまうのもスコープとして狭いと思うので、もう少し質問のスコープを広げて回答します。 具体的には利用規模（個人 or 会社）ごとにAWS Organizations, IAM Identity Centerを導入すべきか、導入するのであればいつ導入すべきかと質問を読み替えた上で回答を述べます。
AWS Organizationsについて
AWS Organizationsの基本的な機能については発表資料で述べているので割愛します。 ここでは、そもそもAWS Organizationsを導入すべきかと導入するのであればいつ導入すべきかについて述べます。
AWS Organizations、導入すべきか？
結論から述べるとAWS利用の規模、用途問わずに導入したほうが良いでしょう。
理由としては下記2点が挙げられます。
- AWSでは用途ごとにマルチアカウントでの運用を推奨している
- Organization配下にアカウントを集約することでコストメリットが得られる
個別に理由を説明します。
AWSでは用途ごとにマルチアカウントでの運用を推奨している
AWSの Well-Architected Frameworkをご存知でしょうか。 AWS上で高い非機能要件を実現するためのプラクティスを集めたフレームワークです。
この中のセキュリティの柱で、用途ごとにAWSアカウントを分けることを推奨しています。
これはシステムの用途によって要求される非機能要件が異なり、その結果として適用されるべきプロセスが異なることに起因します。 たとえば、検証用の一時的なシステムと個人情報を取り扱う本番システムでは要求されるセキュリティレベルや運用プロセスが大きく変わることは想像に難くないでしょう。 それらを単一のAWSアカウントに混在させてしまうと、運用や権限の割り当てを複雑化させてしまうことも容易に想像できます。
また、AWSの機能によってAWSアカウント単位でしか設定できないものもあります*1。 それらを設定することによって意図しない影響がもたらされていないかを確認するには、開発環境に適用、確認した上で本番環境にも適用する形をとったほうが安全でしょう。
このような理由からAWSでは用途ごとにAWSアカウントを準備することを推奨しています。
しかし、都度AWSアカウントを完全に新規で準備することは大変です。 そこでAWS Organizationsが役立ちます。AWS Organizationsを使うことで容易にAWSアカウントを払い出すことができます*2。
AWSアカウントの払い出し機能をAWS Organizationは備えていますが、root用メールアドレスをどうするかが問題です。
GmailやGoogle Workspaceを利用している場合、メールアドレスのローカルパートに+でサフィックスをつけることでエイリアスを作成できます。
たとえば、user@example.comのエイリアスとしてuser+awsroot@example.comを利用することで擬似的にroot用メールアドレスを確保できます。
ここまでで述べたように、企業でAWSを利用する場合は、AWS Organizationsを利用することで、AWSアカウントの払い出しを容易化できます。また、用途に応じてAWSアカウントを分離することでより適切な管理を実現しやすくなります。
では、個人利用の場合はどうでしょうか。 個人利用の場合でもAWSアカウントを容易に払い出せるようになることはメリットになります。 個人でAWSを利用する場合、個人の学習や検証目的での利用が多いでしょう。 おそらく多くの方がリソースを削除し忘れて翌月の請求にびっくりしたことがあるのではないでしょうか。
Organization配下にアカウントを集約することでコストメリットが得られる
AWS Organizationsの同一Organization配下で管理されているアカウントのリソース利用量は合算されます。 AWSではリソース利用の総量が増えるほどボリュームディスカウントが効くため、複数のAWSアカウントの利用料を合算することは料金的にもよい影響があるでしょう。 個々のサービスや環境ごとの利用量が少なくともそれらを合算するとボリュームディスカウントが効く場合は多々あります。 企業で一定以上の規模でAWSを利用している場合、ボリュームディスカウントで削減される料金は無視できない金額になるでしょう。
また、AWS OrganizationsとCost Explorerを組み合わせることで、組織横断でAWSの利用状況、利用料金を確認できます。この組み合わせを使うことで特定時点のAWS利用状況や推移がどうなっているかを任意の観点で分析できるためコスト管理観点では導入しない手はないでしょう。
ここまでで、AWS Organizationsを利用することでマルチアカウント運用による管理性の改善、利用料金面でのメリットについて述べました。しかもAWS Organizationsは無料で利用できます。追加の料金はありません。利用の規模問わずぜひ導入しましょう。
AWS Organizationsを導入すべきはいつか？
AWS Organizationの導入はいつから検討すべきか、いつまでに導入すべきかという問題ですが、基本的にはAWSを利用し始めたら即導入することをオススメします。 すでにAWSを導入している場合も、既存のAWSアカウントをOrganization配下に組み込むことができます。 イベントの中でも触れていますが弊社でも、AWS Organizationsをあとから導入しています。 後から導入する際の操作についても単純でありとくに難しいものはありません。
AWS IAM Identity Center(旧 AWS SSO)について
AWS IAM Identity Centerは複数のAWSアカウントへのシングルサインインを実現しつつ、一時的なアクセスキーの払い出しを容易に実現できる仕組みです。 かつてはAWS SSOと呼ばれていたものがIAMとの連携を強化しつつ、名称変更したものとなります。 これを踏まえた上でAWS IAM Identity Centerを導入すべきか、導入するのであればいつ導入すべきかを考えてみましょう。
AWS IAM Identity Centerを導入すべきか
導入すべきかをいきなり考える前に、導入していない場合を考えてみましょう。 たとえばIAMユーザーを作成してID/パスワード+MFAでログインしている場合を考えてみます。
企業での利用であれば、程度利用規模が拡大して複数のAWSアカウントを利用し始めたり、個人であれば複数の検証や学習を並列して進めている場合があるでしょう。
AWSアカウントごとにIAMユーザーを作成し、多数のID・パスワード・MFAのためのトークンを管理しなければいけない状態は開発者体験としてはよろしくありません。 AWS IAM Identity Centerでは、容易にシングルサインインとログインのためのポータル機能を提供できます。
上のスクリーンショットから分かるようににAWS IAM Identity Centerは複数のAWSアカウントにまたがって仕事を進める必要のあるITエンジニアにとってはとくに便利な仕組みになります。
IAMユーザーを使っていると定期的にアクセスキーを入れ替えたとしても毎月程度だと思います。頻度を上げるほど手間は増えるので入れ替え頻度を上げるにも限度があるでしょう。 AWS Identity Centerでは、数時間程度で期限切れするアクセスキーを都度払い出せる仕組みを提供できます（下図）。もしアクセスキーが流出したとしても影響を局所化できるでしょう。
期限付きのアクセスキーが取得できることはAWSアカウントを利用する場合、個人だろうと会社組織での利用であろうと大きなメリットと言えそうです。 このような観点からとりあえず導入しましょうと言ってしまいたいところですが既に他の方法でログインを実現している場合は注意が必要かもしれません。 すでに他のIdP（Azure ADやokta）を導入している場合、IdPとIAM Identity Centerを個別に導入してしまうと両方でユーザー管理をする必要が生じてしまいます。 このような場合は、認証はすでに導入しているIdPに、認可をIAM Identity Centerに任せる形を考えても良いでしょう。
弊社でも認証はokta、認可はIAM Identity Centerに担わせる形で棲み分けをしています（下図参照）。
すでにAzureADやoktaからSAMLをつかって直接AWSアカウントにログインできる場合、移行に伴う作業コストの問題もあるので十分に検討の上導入可否を決めたほうが良いでしょう。検討の際のポイントとしては、IAM Identity Centerの場合とSAMLを使ったフェデレーションログインでは、アクセス権限を設定する場所が異なる点に注意しましょう（下図参照）。
前者の場合はIAM Identity Centerを管理しているAWSアカウントでログイン時、アクセスキー取得時の権限管理を集約できますが、後者の場合は個々のAWSアカウント側に設定が必要です。
ここまででIAM Identity Centerの導入要否についてまとめてみましょう。原則としてAWS IAM Identity Centerの導入したほうが良い、ただし、すでに他の方法でフェデレーションログインを実現している場合は移行に伴うコストを考えた上で検討と言えるでしょう。
AWS IAM Identity Centerを導入すべきはいつか？
複数のAWSアカウントを利用し始めるまでの導入が効果的です。 また、IAM Identity Center自体、IdPとしても振る舞うことも可能です。 まだ組織内でIdPを導入していない場合はIdentity CenterをIdPとして使う候補に含めても良いでしょう。 シングルサインイン、期限付きのアクセスキー取得を容易にする観点で個人であってもIAM Identity Centerを導入する価値はあると言えます。
まとめ
本エントリではAWS OrganizationsとAWS IAM Identity Centerを導入すべきかとそのタイミングについて論じました。
AWS Organizationsは、導入していない場合は取り急ぎ導入しましょう。 IAM Identity Centerについては、組織ですでにIdPが存在し、AWSアカウントとの間でフェデレーションログインを実現していない場合を除き、導入する前提でよいでしょう。導入している場合でも認可の際に割り当てる権限を管理する観点でメリットは存在します。 その部分を含めてSAMLを使ったフェデレーションログインからIAM Identity Centerに切り替えることを考えても良いでしょう。
両サービスとも追加料金はいっさい発生しません。 一度試してみた上で導入を考えてみてはいかがでしょうか。
