プロポーザル

「とあるIaCツールで構築したAWSリソースをCDKで管理したいけど、どうやってやればいいの…？」「CloudFormationや手動で構築したリソースをCDKに移行したいけど、なんか難しそうで踏み出せない…」そんな悩みはありませんか？

本セッションでは、とあるIaCツールで構築していたリソースを「cdk migrate」を使用してCDKに移行した私の経験を通して、
cdk migrateの気をつけるべき点や、CDK移行時の開発フローの考え方や工夫など、「無理なく着実に、移行するTips」をお伝えします。

あなたのCDK移行を「無理しない、頑張りすぎずにやりきる」ためのヒントをお伝えできれば幸いです。

後輩「先輩、このcdk initで出来るtsconfig.jsonとかってなんですか？」
先輩「ああ、あれね。うーん…なんかCDKを良い感じに動かすのにいるやつだよ！」

こんな返答していませんか？私はするかもしれません。
毎度疑問になるたび調べるけど、毎回忘れていく。あるいは見逃している。そんな知識をここで改めて一緒に身につけませんか？

本セッションでは、CDKの初期セットアップコマンドであるcdk initを実行した時にできる以下のファイルや、synth時に生成されるファイルと設定されるパラメータを深堀りしていきます。これでいつ聞かれても大丈夫になりましょう！

• tsconfig.json
• .npmignore
• package.json
• jest.config.js
• cdk.json ..and more

AWS CDK Toolkit Libraryが5/30にGAになり、CLIを使わずともNode.jsなどから直接クラウドアセンブリを作成したりAWSにデプロイしたり...といったAWS CDKの機能が使えるようになりました。
しかし今まで同様、AWS CDK Toolkit Libraryでも単体テストの機能は（6/2現在）含まれていないので、単体テストだけは相変わらずCLIを使うしかありません。

ただ、AWS CDK Toolkit LibraryによりAWS CDKでCLIを使わなくても良くなった以上、どうせなら単体テストもCLIを使わずに完結させたいと思いませんか？

そこでこのトークでは、AWS CDK Toolkit Libraryのソース上で単体テストも一緒に実行する方法、そしてその際のメリットデメリットやユースケースといった知見を紹介したいと思います。

２０２５年には日本語対応やAmazon Q Developer for GitHubのプレビュー版の発表など、何かと話題になるAmazonQですが、AWS CDKを利用した開発を進めるうえではどのような活用方法があるのでしょうか？
コーディング支援やエラー対応支援、レビュー、テストの支援など各シーンでのAmazonQの活用方法を探ります。

データベースの運用は、バージョンアップデートなどさまざまなことを考慮する必要があり、多くの開発チームにとって頭の痛い課題です。
また障害やDisaster Recovery 時の復旧など、緊急事態にも対応が必要となるため、事前に備えておくことが重要です。

本セッションでは、AWS CDK を使用して Amazon RDS を運用していくための tips をご紹介します。

AWS CDKには、リソースやテンプレートの「差分」を確認するさまざまな手段があります。それぞれの操作が何を比較しているかを正しく理解することによって、意図しない変更を見つけられるようになります。このセッションでは、CDKとCloudFormationの世界のつながりを意識しながら、さまざまな差分検出のしくみを解説し、CDKの運用を安全にする方法を紹介します。

AWS CDKでは、きめ細かなアサーションテストを行う為のモジュールが標準で提供されており、コンストラクトからCloudFormationテンプレートの合成に関する挙動をテストすることが可能です。
しかし標準のモジュールでは、テスト対象のリソースやテンプレートに関する型情報やスニペットが不足しており、IDE上で効率的にテストを実装出来るとは言い難いです。

そこで、それらの課題を解決し、IDE上で効率的にきめ細かなアサーションテストを実装するためのTypeScriptライブラリ「aws-cdk-utul - AWS CDK Unit Test Utility Library」をリリースしました。

一般的なソフトウェア開発における「テストピラミッド」の概念を応用し、AWS CDKで定義したインフラに対する効果的なテスト戦略を模索し、理論化します。
一般的なソフトウェア開発におけるテストと、AWS CDKで定義したインフラ管理におけるテストとの類似点と違いを見極め、インフラ管理における最適な「テストピラミッド」の形を考察します。
インフラに対する効果的なテスト戦略を模索している皆様の助けになればと思います。

インフラをコードで書く技術として馴染みのあるAWS CDK。 しかし2025年、コーディングをプログラマーでもインフラエンジニアでもなくAIが出来るようになってしまいました。じゃあCDKって必要なの？CloudFormationで良くない？という疑問は当然現れます。本トークではこの時代にCDKを選ぶ理由についてCDKとCoding Agentに熱狂している人間として、「CDKがエージェント時代に向いている」ことを証明します。

IaC

AWS Step Functions はサーバーレスにワークフローを組めるサービスで、2024年の re:Invent 直前に JSONata と変数のサポートで大きく使い勝手が進化して以前よりも遥かに簡単に構築できるようになりました。

そんな JSONata と変数機能が AWS CDK の L2 でサポートされた 2025 年 3 月頃に、VSCode の拡張機能である AWS Toolkit でも Step Functions のサポートが強化されました。これによりマネジメントコンソールで構築するかのように VSCode 内で Step Functions を編集できるようになりました。

さて、これらはぶっちゃけどちらを使うべきなのか？また、具体的にどう使い分けるべきなのか？といった観点を JSONata サポートを実装した本人が包み隠さずお話します。

AWS CDK は TypeScript などのプログラミング言語で AWS リソースを構築できる革新的なツールであるものの、CDK を使用した開発を行う際には AWS に関する知識のみではなく、TypeScript や CDK のセオリー・ベストプラクティスやアンチパターンの理解が求められる場面があります。

しかし、CDK エコシステムにおいては、セオリー違反のコードに対する自動検知システムが十分に整備されていません。
そのため、こうした問題に対し多くの開発現場では、経験豊富なエンジニアによるコードレビューなどに依存してコードの品質や安全性を担保しているのが現状ではないでしょうか。

本セッションでは、そのような問題と向き合う方法のひとつとして、TypeScript の型システムや静的解析ツールを使用して、CDK のセオリー・ベストプラクティスを自動適用する方法について紹介します。

みなさんはIdentity Centerの設定をどのように管理されていますか？
私はあるプロジェクトで、当初はマネジメントコンソールやCLIを使って運用していましたが、利用範囲が広がるにつれ、「今どういう設定になっているのか？」がだんだん見えづらくなっていきました。
このままでは運用がつらくなると感じ、CDKによるコード管理にチャレンジしてみました。
今回は、CDKへの移行やその後の運用を通じて得られた気づきや工夫について、ぜひ共有させていただきたいと思います。

AWS CDK Toolkit LibraryはAWS CDKをCLIではなくプログラムAPIを通して扱うことができるツールキットライブラリです。
2025/05/30にGAになったばかりの AWS CDK Toolkit Library をどういった時に使うのか？どう使うのか？何ができるのか？について実際にAWS CDK Toolkit Libraryを利用している Amplify Gen2 (@aws-amplify/backend) の実装を通して紹介します。

2025年、CDKコードを書く際のセオリーはだんだんと固まりつつあります。

しかし規模が大きくなるにつれてコードが複雑になり、読み辛くなってきたり拡張しづらくなってきたりするケースもあるかと思います。

またプログラミング言語で記述するCDKですが、インフラ定義として理解しづらくならないようにプログラミング言語ならではの記述方法をあまり取らないケースも多いでしょう。
逆に、できるからこそそんな書き方をして出来上がったものの、後でよくわからなくなってしまったこともあるのではないでしょうか。

本セッションではそんな課題を解決すべく、今までのセオリーに反することなく、かつプログラミング言語ならではの記述も活用して、より理解容易性や拡張性を担保できるようにするためのCDKの設計/実装アプローチを紹介します。

AWS CDKを、「リソース構築できた」のフェーズから次のフェーズへ。

CDKでは、CloudFormationのリソースをそのまま扱うL1コンストラクトと、それらを抽象化・簡素化したL2以上のコンストラクトに大別されます。L1はCloudFormationの仕様に忠実である一方で、引数の扱いやすさという点では必ずしも開発者フレンドリーとは言えません。そのため、L2以上のコンストラクト設計においては、いかに直感的APIを提供できるかが重要であり、設計者の力量が問われるポイントでもあります。
私はこれまでに約140件のCDKへのコントリビュートを通じて、さまざまな引数設計のパターンに関わってきました。本セッションでは、その知見を元に「どのような設計がユーザーにとって使いやすいか」「L1の制約をどう抽象化・解消するか」といった観点から、辞書的に活用可能なノウハウを共有します。

AWS CDKでは、プログラミング言語でリソースを宣言的に定義し、cdkコマンドによってデプロイが実行されます。
リソースの抽象化やCloudFormationでのデプロイ以外にも、Lambdaコードやコンテナイメージのビルドやパブリッシュまで、CDKだけで様々なデプロイの関心ごとをワンストップで行うことができます。

そんな便利なCDKですが、内部ではCDK CLIとCDK Appのそれぞれで様々な処理が行われることでデプロイの一連の流れを実現しています。

本セッションでは、どのような流れでCDKのデプロイが行われるのか、デプロイの過程でどんなことが行われているのか、そんなAWS CDKの仕組みについて解説します。

この仕組みを知ることで、CDK開発の中で遭遇した思わぬ挙動の原因を突き止められたり、CDKコントリビュートをよりスムーズに行えるようになるでしょう。

CDKプロジェクトを運用していると、こんな経験ありませんか？
・「いつの間にかCDKバージョンが古くなっている」
・「CDKが自動作成するLambdaのランタイムが古いまま」
この発表では、これらの依存関係管理を自動化するアプローチを紹介します。

【Renovate活用術】
依存関係の自動更新設定から、安全な自動マージまでの実践的な運用方法を解説します。

【Vitest導入】
頻繁なテスト実行で気になるJestの実行速度を、Vitestへの移行で改善する手法も紹介します。

これらの組み合わせにより「手離れの良いCDKプロジェクト」の構築が可能になります。実際の設定例や移行時のポイントを交えながら、明日から始められる持続可能なCDK運用のノウハウをお伝えします。

みなさんテストコード書いてますか？
お恥ずかしながら私は今まであまり書いておらず、ずっと避け続けていました。

そんな中、とある案件でCDKを用いたLambdaを30個ほど作成しました。
そろそろ品質担保が大変になってきたぞ、、と思いつつテストコードを書くと良いことがたくさん！
実際にCDKコードや、Lambdaコードを眺めつつ、得られた知見を還元したいと思います。

CDK Confということで★の部分にフォーカスしつつ、下記内容でお話する予定です。
・どんな構成のシステムか？
・テストコードを書くことによりどのようなことが嬉しかったか？
・CDK配下におけるLambda(Python,TypeScript)のテストコード書いてて困った点、プラクティス ★
・今後CDK構成をどう良くしていきたいか？ ★

お話しないこと
・CDK自体のテスト（Snapshot、Assertion）

AWS CDKのGitHubリポジトリにコントリビュートしたいと思いつつ、「自分にはハードルが高い」と感じている方は多いのではないでしょうか。私も同じように感じていた一人です。しかし、アプリケーションエンジニアとしての経験を活かしてCDKコントリビュートに入門し、2ヶ月で8件のプルリクエストがマージされました。
本セッションでは、アプリケーションエンジニアだからこそ見えたCDKコントリビュートの難しさおよびその乗り越え方をお話しし、コントリビュートの面白さを伝えます。

本セッションの想定聴講者は「CDKコントリビュートに興味があるが一歩踏み出せていない人」です。「CDKコントリビュートは特別な人だけのものではない」と感じてもらえるよう、一歩踏み出す勇気を持ち帰っていただけるセッションとなります。