本発表では CI 環境での実行や、クロスアカウントでのデプロイメントのシナリオをカバーする CDK 標準の仕組みを解説します。
本発表で想定している主な状況は、GitHub Actions のような CI ツールでデプロイを行う場合や、Organizations の統制側で複数のメンバーアカウントに共通の仕組みを展開する場合です。自前でデプロイ用に強い権限 (e.g. Administrator) を持つ IAM Role を構成していませんか?
実際のところ、cdk deploy の実行主体となるクレデンシャルに必要な権限はほとんどありません。CDK の使い方を覚えたばかりのユーザーにとってキャッチアップの意識が後回しになりやすいであろうデプロイ権限構成の問題について、より安全な権限構成を「仕組みを理解して」使えるようになっていただくことを、この発表のゴールとしています。
CDKプロジェクトが成長すると、「ユーザー認証ロジックがLambda関数に直書き」「DynamoDB操作がビジネスロジックと混在」「インフラ変更でドメインロジックも影響を受ける」など
ビジネスロジックとインフラコードが密結合し、テストが困難になり、新メンバーの理解が進まない問題が発生する可能性があります。
monorepo構成で、CDK・Lambda・ドメインロジックをパッケージ単位で分離、Clean Architecture原則をCDKに適用し、
@app/coreでAWS依存ゼロのドメインモデル設計、リポジトリパターンでDynamoDB抽象化、Lambda関数での依存性注入によるレイヤー分離を実装方法を考えます。
Before/Afterコード比較で具体的実装を解説し、ビジネスロジック変更がインフラに影響しない、テスト容易性が向上した持続可能なCDK開発パターンをお伝えします。
フロントエンド・バックエンド・インフラが分離されたプロジェクトでは、API仕様変更時の型不整合、スキーマ定義の重複管理、デプロイ時の仕様ズレなどが発生します。
CDKを独立管理すると「Zodスキーマを定義してもフロントエンドは手動型定義」「API Gatewayスキーマも手動で重複定義」「OpenAPI生成が動作しない」など悩みがつきません。
CDKをmonorepoに組み込み、@app/coreのZod-OpenAPIスキーマを唯一の真実の源として、フロントエンド型定義自動生成、CDK API Gatewayスキーマ自動生成、OpenAPI仕様書自動出力する設計を実装について考えます。
Zodスキーマ変更がフロントエンド・CDK・ドキュメントに反映される型安全な開発体験を実現した具体的手法と、ライブラリバージョン問題の解決策をお伝えします。
実案件でECS on Fargate + Ruby on Rails を構築した際 「アプリ開発担当にも扱える シンプルな自動デプロイ を提供したい」と考え、 単一の CDK Pipelines でアプリとインフラを丸ごとデプロイする構成を採用しました。
しかし実運用ではビルド時間の肥大化などの課題に直面し、 最終的にパイプラインを インフラ/アプリの 2 レーン に分割し次のように解決しました。
本セッションでは
AWS CDKに興味はあるけど、何から手を付ければいいかわからない…そんな方のための「最初の一歩」を徹底解説します。公式ドキュメントやサンプルの使い方、開発を効率化するツール、生成AIの活用法まで、これから AWS CDK を使い始めるあなたに必要な情報をお伝えします。セッション後には「これなら自分も始められる!」という自信が持てる内容です。
CDKプロジェクトを手動で更新しちゃった…この積み重ねで地獄になってませんか?
残念ながら、CDKやCloudFormationでは、プロパティの差分を簡単に解消できる方法は提供されてません
あなたはどうやって立ち向かいますか?
本セッションでは、次の観点を持って課題解決に挑みます
CDKやCloudFormationの盛りだくさんな機能も扱います!
せっかくCDKで管理しているのに手動で変更しているプロジェクトを撲滅しましょう!
AWS MCP Serversの中には、「AWS CDK MCP Server」や「Cost Analysis MCP Server」、「AWS Serverless MCP Server」、「AWS Documentation MCP Server」とCDK開発をサポートするMCPがたくさんあります。
しかしながら、「なんとなくMCPを使っているものの、それぞれのMCPがどのような処理をしているのかは、よく知らない」という方も多いのではないでしょうか。
そこで本セッションでは、それぞれのMCPの挙動をソースコードから確認しながら、各MCPがどのような機能を提供してくれているのか紹介したいと思います。
AWS CDK Toolkit LibraryがGAになり、CLIを使わずともNode.jsなどから直接クラウドアセンブリ作成やデプロイといったAWS CDKの機能が使えるようになり、インテグレーションテストの導入も容易になりました。
しかしAWS CDK Toolkit Libraryでも今まで同様、テストの機能は含まれていないため外部ライブラリを使うしかなく、特に単体テストは相変わらずCLIを使うしかありません。
ただ、どうせなら単体テストもAWS CDK Toolkit Libraryソースで完結させたいと思いませんか?
そこでこのトークでは、AWS CDK Toolkit Libraryのテストに対する考え方の紹介や単体テストもAWS CDK Toolkit Libraryで完結させる方法、およびその際のメリットデメリット・ユースケースなどを紹介したいと思います。
AWS CDKには、リソースやテンプレートの「差分」を確認するさまざまな手段があります。それぞれの操作が何を比較しているかを正しく理解することによって、意図しない変更を見つけられるようになります。このセッションでは、CDKとCloudFormationの世界のつながりを意識しながら、さまざまな差分検出のしくみを解説し、CDKの運用を安全にする方法を紹介します。
一般的なソフトウェア開発における「テストピラミッド」の概念を応用し、AWS CDKで定義したインフラに対する効果的なテスト戦略を模索し、理論化します。
一般的なソフトウェア開発におけるテストと、AWS CDKで定義したインフラ管理におけるテストとの類似点と違いを見極め、インフラ管理における最適な「テストピラミッド」の形を考察します。
インフラに対する効果的なテスト戦略を模索している皆様の助けになればと思います。
インフラをコードで書く技術として馴染みのあるAWS CDK。 しかし2025年、コーディングをプログラマーでもインフラエンジニアでもなくAIが出来るようになってしまいました。じゃあCDKって必要なの?CloudFormationで良くない?という疑問は当然現れます。本トークではこの時代にCDKを選ぶ理由についてCDKとCoding Agentに熱狂している人間として、「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を用いたLambdaを30個ほど作成しました。
そろそろ品質担保が大変になってきたぞ、、と思いつつテストコードを書くと良いことがたくさん!
実際にCDKコードや、Lambdaコードを眺めつつ、得られた知見を還元したいと思います。
CDK Confということで★の部分にフォーカスしつつ、下記内容でお話する予定です。
・どんな構成のシステムか?
・テストコードを書くことによりどのようなことが嬉しかったか?
・CDK配下におけるLambda(Python,TypeScript)のテストコード書いてて困った点、プラクティス ★
・今後CDK構成をどう良くしていきたいか? ★
お話しないこと
・CDK自体のテスト(Snapshot、Assertion)
AWS CDKのGitHubリポジトリにコントリビュートしたいと思いつつ、「自分にはハードルが高い」と感じている方は多いのではないでしょうか。私も同じように感じていた一人です。しかし、アプリケーションエンジニアとしての経験を活かしてCDKコントリビュートに入門し、2ヶ月で8件のプルリクエストがマージされました。
本セッションでは、アプリケーションエンジニアだからこそ見えたCDKコントリビュートの難しさおよびその乗り越え方をお話しし、コントリビュートの面白さを伝えます。
本セッションの想定聴講者は「CDKコントリビュートに興味があるが一歩踏み出せていない人」です。「CDKコントリビュートは特別な人だけのものではない」と感じてもらえるよう、一歩踏み出す勇気を持ち帰っていただけるセッションとなります。