AWS CDK Conference Japan 2025 に登壇しました『CDKで挑むIdentity Centerの運用改善』
こんにちは、エヌデーデーの池ノ上です。
7/12(土) に開催された AWS CDK Conference Japan 2025 に登壇させていただきましたので、セッション資料を公開いたします。
セッション資料
セッション動画
要約
NotebookLMによる動画からの要約を載せておきます。（一部の誤記や誤りは手動修正）
発表の背景と運用課題
発表者は、マルチアカウント環境においてログイン管理のためにAWS Identity Centerを利用していました。
- IDソースは外部IDプロバイダーでした。
- ログイン先は、Organizations内外の様々なアカウントにまたがっていました。
従来の運用は、以下のような課題を抱えていました。
- 設定は主にマネジメントコンソールやCLIによる手動設定が中心でした。
- 設定情報はExcelで管理されており、その内容は増え続ける一方でした。
- 管理規模は、Organizations内外合わせてアカウント数約450個、グループ数約20個、パーミッションセット数約10個と大規模であり、今後もさらに増加する見込みでした。
このような状況で、最大の課題として挙げられたのは、「実際は今どうなっているのかが分からない」不透明さでした。
CDKの導入と適用範囲の決定
この運用課題を解決するために、CDKの導入が選択されました。CDKが選ばれた大きな理由の一つは、CDK支部をはじめとする日本語の情報発信が豊富であったことだと述べられています。
CDKの適用範囲を明確にするため、Identity Centerの各要素がCDK管理の対象となるか否かが慎重に検討されました。
CDK管理対象外としたもの:
- グループ: 外部IDプロバイダーで設定され、自動プロビジョニングされるため。
- アカウント: Control Towerで作成されるため。
- アプリケーション (AWSマネージドアプリケーションのAWS External Account): 仕様上、マネジメントコンソールからしか作成できない制約があるため。
- メンバーアカウント側で作成するカスタムポリシー: Identity Center側で一元管理できないため。
CDK管理対象としたもの:
- パーミッションセット。
- パーミッションセットとグループ・アカウントを紐づけるアサインメント。
- あるシナリオでは、1グループあたり最大90個のアサインメントに達する可能性があり、これがコード化の大きな動機付けになったと説明されています。
スタック構成の設計と既存環境への適用
スタック構成の設計においては、CloudFormationのスタックあたりのリソース上限（500個）や将来的なリソース増加の可能性を考慮し、スタックの分割が必要と判断されました。特に、グループごとにスタックを分けることで状態把握がしやすくなるというメリットが考慮されました。ネステッドスタックでの管理も検討されましたが、後述の課題により断念されました。
既存環境への適用では、既存のリソースを壊さずに活用するため、cdk importコマンドが活用されました。
- インポートの際には、グループIDなどのランダムな文字列の値をCDKアプリ内に固定値としてハードコードすることで、対話型入力の簡略化を図ったそうです。
- しかし、ここでネステッドスタックがcdk importに対応していないという制約に直面し、最終的にはグループごとにスタックを分割する構成が取られました。発表者は、後から考えると段階を踏めばネステッドスタックも可能だったかもしれないと述べています。
CDK管理の負荷軽減策
CDKでの管理負荷を軽減するため、コード内にランダムな文字列のID（グループIDなど）を持たせない工夫が凝らされました。
- SSM Parameter Storeを利用してIDの値を管理し、CDK側では意味が読み取れるキーの名前のみを持たせるようにしました。
- さらに、Lambdaを用いてSSM Parameter Storeに登録されたIDを自動で最新化する仕組みを構築することで、コード管理を大幅に容易にしました。
CDK導入による成果と今後の課題
CDK導入によって、以下の成果が得られました。
- 現在の状態が可視化されたことで、「今どうなっているのか分からない」という課題が解消されました。
- ループ処理などの簡易なロジックを容易に実現でき、複雑性を抑えられました。
- GitHub Actionsと組み合わせたテスト、レビュー、デプロイの自動化により、運用が安定しました。
一方で、CDK管理における残る課題と考慮点も挙げられています。
- アプリケーションのARNにアカウントIDが含まれるため、アプリケーション利用時にはデプロイ先を管理アカウントにする必要がありました。ベストプラクティスでは委任管理が望ましいが、この点はまだ改善の余地があるとしています。
- グループの増減があった際、CDKアプリから一部のスタックを削除しても、CloudFormationのスタックの実体は残ってしまうため、手動での削除が必要となります。手動作業が発生する点は改善点として認識されています。
- 恒久的なアクセス付与の運用が最適かという論点も存在します。これに対しては、CDKではないものの、AWS Samplesで公開されている、申請ベースで一時的なアクセス権を付与するTeamというソリューションなども解決策として検討できると述べられています。
感想
CDK Conference は2022年から毎年開催されており、今年は4回目の開催でした。
今回の参加人数は、オフラインが約200人、オンラインが約300人とのことで、過去最大の規模だったようです。
内容としては、メイントラックはオープニングとキーノート含め19セッション、セカンドトラックは9セッション、サブイベントとして、CDK Vibe Coding Fes、CDKコントリビュートワークショップ、初心者ワークショップ、Amplifyワークショップ、Ask An Expertが催され、盛沢山な内容でした。
個人的には、日本のCDKの最前線が感じられる、かつ、初心者にも開かれた素晴らしいイベントだと感じました。運営のみなさま、ありがとうございました。
動画や資料がアップされているので、わたしもこれから当日見られなかった発表を見てみたいと思っています。