はじめに
こんなイベントに参加した
https://jawsug-cdk.connpass.com/event/393595/
AI / CDK と協働する Full TypeScript アプリケーション開発
ほぼ終わりかけで見た。CDK・TSはアプリケーションエンジニアにはやりやすいと感じた。
またAIが活躍しやすい環境を整えるのがこれからのエンジニアの仕事になるだろうと言っていた。
マルチスタックCDKアプリにおける安全なスタック削除運用
コードから消したのに、実リソースが消えない問題があった。
複数にまとめられているスタックに対して、CLIから1つのスタックを削除しても、実リソースは消えない。
5年前からgithubでどうする感じ議論されている。
登壇者はコードと実リソースの差分を比較して、差分をCFnで削除するCICDを実装した。
またご削除防止の制御を追加した。
JUMPアカウント運用を支えるIAMユーザー管理のCDK活用術
マルチアカウントの権限管理は難しい。
IAMユーザが乱立したり、クラブアカウントによる依存関係地獄になる。
問題解決するため、jumpアカウントをCDKで管理してみた。
IAMをCDKでIaC化した。
ベンダーごとのstack、ファイル管理した。
MFAの強制やIP制限などのセキュリティ機能もCDKで実装した。
stacksetは、organization向けとそうじゃないもので使い分けた。
カスタムリソース(Lambda)で、IAMとそのアタッチメントを削除できるようにした。
生成AI×AWS CDK×AWS FISで"振り返れる"ミニGameDayをつくろう
cdkとfisでgame day環境を再現できる。
さらに生成AIでより複雑な環境を作れるようになった。
dbedrockが障害対応を評価するようにした。
CDKユーザーがマルチクラウドにCDKTFを選んで、撤退するまでの記録
CDKTFは去年12月アーカイブされた。
CDKTFはCDKをTerraformに対応させたもの。
去年12月にアーカイブされたため、CDKTNがコミュニティとして引き継いだ。
CDKTFはマルチクラウドを、すでに使っているCDKと同じように実装・運用できるため採用した。
CDKTFを採用して悪かったところ。
- ドキュメントがわかりにくい。CDKTFを調べるのに、Terraformの情報を調べないといけない。
- TSの柔軟性を活かせない。ハードコーティングをしないといけない箇所が多かった。
CDKTFが撤退後は、Terraformに移行した。
移行コストが低いため。
AI Coding Agent時代のcdk-nagガードレール 〜組織ルールを強制CIで守り抜く設計の挑戦〜
社内向けの統制に沿ったCDKのアセットを配布している。
CDK-nagは統制チェク機能がある。
チェック違反になったら、プロダクトコードを編集したりする。
cdk-nag v3で提供側から、条件付きの制限できる機能が廃止された。
cdk-nagの違反例外をCIで管理するようにした。
CIは条件付き許可でやり、SCOは絶対禁止にする操作で使い分けている。
スポンサーセッション3 社内向けCDK Constructライブラリを運用する色々なメリットと始め方
ライブラリの目的
- 社内のよくあるインフラ構成を再利用する
- CDKのUtility関数
- L1のL2化
コンテナ基盤あれば、利用者は意識しなくてもビルドキャッシュを活用できる。
またイメージの脆弱性スキャンを設定できるようになっている。
SAPホスティングは、ホスティングに必要なリソースをまとめてさくせいできるようにしねいる。
Lambdaが不能になるようにライブラリを実装した。
CDKのユニットテスト用のcdk.jsonにある機能フラグを渡すテストヘルパーを実装した。
projenは、githubを前提としたエコシステムと相性が悪いことや単一プロジェクトにはオーバーヘッドが起きるため辞めた。
スポンサーセッション4 AIに書かせたCDK、動くだけで満足してませんか？ 今日から始める、CDKハーネス設計！
AXイノベーションセンターは、全社活用のAIを横断する組織。
AIテンプレートは、AIがCDKを生成するためのルールーをまとめたもの。
従来のIaC開発を解決するために、AIテンプレートを作った。
AIが読みやすい構成図のDraw.ioを作成して、構成図に合わせたパラシを作成する。
そのパラシをレビューできるようにする。
安定したAIによるCDKを実装するには、AIハーネスが必要。
責務に応じたサブエージェントとSkillsを用意する。
構成スケールに応じた生成を分割させる。
AIの計画段階でら誤ってL2ではなく、L1を使ってしまうことを防止しないといけない。
そのためSkillsでL1を使う際はMPCで調査することを明示した。
CDK-nagで最終防衛線を張った。
CDKのテストは、Integrationテストは採用しなかった。
デプロイする前にテストを実装するようにした。
テストを生成する前に、テスト計画レポートを生成するようにした。
2026年最先端のL1コンストラクト活用術
CDKのL1は、CFnの機能である。
L1を活用することで、L2-3の機能追加を自動化できないか？
L1にバリデーション機能がなかったため、バリデーション機能の実層を考えた。
またENUMで型安全を保つようにした。
これらがあることで静的解析を実装することができた。
しかし型安全は、世界中から反対があったためクローズとなった。
CDKでPRごとに使い捨て環境立てたら便利すぎました
PRごとにプレビュー環境があれば便利。
PRをしたら、プレビュー用スタックを作成するようにする。
デプロイ速度を考慮して、全リソースをスタックを作成するわけではない。
プレビュー用スタックがあれば、AIが書いたコードに出して、人間がレビューしやすくなる。
型も通る、synthも通る、それでも危ない 〜AIのCDKの権限とコストを機械で検証する〜
AIは動くコードを早く実装できるが、危険な実装も行う。
そのため危険な実装をしても、静的解析をすり抜けてしまうことがある。
そのため権限・公開設定・コストをCIで検証するようにした。
cdk-nagで