プロポーザル

データベースの運用は、バージョンアップデートなどさまざまなことを考慮する必要があり、多くの開発チームにとって頭の痛い課題です。
また障害や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がエージェント時代に向いている」ことを証明します。

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コントリビュートは特別な人だけのものではない」と感じてもらえるよう、一歩踏み出す勇気を持ち帰っていただけるセッションとなります。

AWSのCDKを実験中にリソースをいろいろ作って遊んで、たのし〜ってやってたらcdk destroyだけやってVPCやELBを削除できていないことに気づいていなくて$70課金された時のお話です。
背景として、以下のようなことがありAWSCDKさわってみるかぁ〜から始まった遊び心です。

・一からAWSでサーバレスアーキテクチャを構築したことないな
・AWS CDK使ったことないな
・この技術書典で買った本がAWS CDKで構築するハンズオンだった

この遊び心がどう＄７０課金される原因と対策、これから個人でAWS CDKに触れる方の参考になればという思いを込めてお話しするLTです。
具体的には、構築したインフラ構成（RDS,ECS,ELB,APIGateway etc...）やCDKの扱い方のTips、そもそもどうやって書くのみたいなところも簡単にお話ししていきたいと考えています。