プロポーザル

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

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

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

IaC

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

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

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

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

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