5分でわかって、明日からCDKを使いたくなる！個人的感動機能10選！¶

チェック¶

[ ] 本文を確認した
[ ] 概要を確認した
[ ] タグを確認した
[ ] inbox/ 直下へ移行した

概要¶

AWS CDK を使いたくなる機能を 10 個に絞って紹介するスライド。 TypeScript の型補完、CDK の抽象化レイヤー、grant、タグ管理、RemovalPolicy、NodejsFunction、fromLookup、Snapshot/Assertions テスト、Mixins、AWS 公式 MCP servers が挙げられている。 CDK の良さを、IaC をプログラミング言語で書けることだけでなく、AWS 利用時の実務負荷を減らす機能として紹介している。

本文¶

資料は、AWS CDK を短時間で好きになるための機能紹介。 CloudFormation を直接書く場合と比べ、CDK はプログラミング言語の表現力、型、抽象化、テスト、補助機能を使ってインフラを扱える。

1. TypeScript とプログラミング言語の力¶

CDK は TypeScript、JavaScript、Python、Java、C#、Go などで書ける。資料では TypeScript の体験が強調される。

TypeScript で書くと、IDE の補完、型チェック、コンパイルエラー、リファクタリング、フォーマッタ、linter、既存エコシステムが使える。 JSON/YAML のテンプレートを手で書くより、構造や型を使って安全に記述しやすい。

配列操作、条件分岐、関数化、map/filter など、通常のプログラミングの道具も使える。 AI にコードを読ませる場合も、TypeScript の構造があることで扱いやすい。

2. CDK の抽象化レイヤー¶

CDK には L1、L2、L3 の抽象化レイヤーがある。

L1 は CloudFormation リソースにほぼ 1:1 で対応する CfnXXX。 CloudFormation の全機能に近いが、低レベルで記述量が多い。

L2 は AWS リソースを使いやすくした高レベル Construct。デフォルト値、便利メソッド、依存関係の解決などが入る。資料では、L2 が抽象化と汎用性のバランスがよいものとして扱われる。

L3 は複数リソースをまとめたパターン。たとえば API + Lambda + DynamoDB のような構成を一つの Construct として扱える。

3. Grants¶

CDK の grant 系メソッドは、IAM policy を手で書く負担を減らす。

たとえば Lambda に S3 Bucket の読み取り権限を与えたい場合、IAM policy の action、resource ARN、principal を自分で組み立てなくても、bucket 側のメソッドで権限を付けられる。

bucket.grantRead(fn);
table.grantReadWriteData(fn);
queue.grantSendMessages(fn);

権限の対象と付与先がコード上で読みやすい。 IAM policy を直接書くより、意図が分かりやすく、CDK が必要な ARN や action を組み立ててくれる。

4. タグ管理¶

AWS リソースには、コスト管理、所有者、環境、プロダクトなどのタグが必要になる。 CDK では Stack や App の入口でタグを付けると、配下のリソースへまとめて適用できる。

Tags.of(app).add("Project", "example");
Tags.of(app).add("Environment", "dev");

これは CDK の Aspects の仕組みを使って実現される。各リソースに個別にタグを書く必要が減り、タグ付け漏れを防ぎやすい。

5. RemovalPolicy / RemovalPolicies¶

CDK では、Stack 削除時やリソース置き換え時の扱いを RemovalPolicy で指定できる。

代表的な値は次の通り。

DESTROY: Stack 削除時にリソースも削除する。
RETAIN: Stack から外れてもリソースは残す。
SNAPSHOT: 削除前に snapshot を残す。
RETAIN_ON_UPDATE_OR_DELETE: 更新や削除時に保持する。

テスト環境では削除しやすく、本番の DB や Bucket は保持する、といった環境別の使い分けができる。新しい RemovalPolicies のような仕組みにより、複数リソースへまとめて方針を当てる使い方も紹介されている。

6. NodejsFunction¶

NodejsFunction は、TypeScript/JavaScript の Lambda を CDK から簡単に bundle できる Construct。 entry file を指定すれば、esbuild を使って依存関係をまとめ、Lambda 用の artifact を作る。

new NodejsFunction(this, "Handler", {
  entry: "src/handler.ts",
  handler: "handler",
});

Lambda 用に別途 build script を組み立てる負担が減る。 CDK の deploy と Lambda の bundle が自然につながる。

7. fromLookup¶

既存の VPC や Subnet を参照したい場合、ID を直接書くと環境差分に弱い。 CDK の fromLookup を使うと、AWS アカウントやリージョンから既存リソースを検索して参照できる。

const vpc = ec2.Vpc.fromLookup(this, "Vpc", {
  tags: {
    Name: "shared-vpc",
  },
});

タグや名前を使って既存 VPC を引くことで、ハードコードを減らしつつ、安全に参照できる。

8. Snapshot と Assertions テスト¶

CDK はインフラコードをテストできる。 Snapshot test では、生成される CloudFormation template を snapshot と比較し、意図しない差分を検出する。

Assertions では、特定のリソースやプロパティが含まれるかを細かく確認する。

const template = Template.fromStack(stack);

template.hasResourceProperties("AWS::S3::Bucket", {
  VersioningConfiguration: {
    Status: "Enabled",
  },
});

AI に CDK を書かせる場合も、テストがあると出力の検証に使える。インフラコードの品質ゲートとして有効。

9. Mixins¶

Mixins は、L1 と L2 の隙間を埋めるような新しい機能として紹介されている。 CDK の L2 Construct がまだ対応していない機能や、組織独自の設定を後から注入したい場合に使える。

自作 mixin によって、複数リソースへ共通設定や追加プロパティを適用できる。これにより、L2 の使いやすさを保ちながら、足りない設定を補える。

10. AWS 公式 MCP Servers¶

最後に、AWS 公式の MCP servers が紹介される。 AWS IaC MCP Server、AWS Knowledge MCP Server、AWS API MCP Server などにより、AI エージェントが AWS ドキュメント、IaC、API 情報へアクセスしやすくなる。

CDK と AI の組み合わせでは、AWS の仕様確認、Construct の使い方、リソースのプロパティ確認が重要になる。 MCP server は、AI が古い知識や曖昧な記憶だけでコードを書くリスクを下げる補助になる。

要点¶

CDK は TypeScript の型、補完、linter、テストをインフラ管理に使える。
L1/L2/L3 の抽象化により、低レベル制御と高レベル利便性を選べる。
grant により IAM policy の手書きを減らせる。
Tags と Aspects でタグ付けをまとめて適用できる。
RemovalPolicy で削除時の挙動を環境に合わせて制御できる。
NodejsFunction は Lambda bundle を CDK に統合する。
fromLookup は既存 VPC などの参照に便利。
Snapshot/Assertions テストは CDK と AI コーディングの品質ゲートになる。
Mixins と MCP servers は、CDK の拡張性と AI 連携を広げる。

タグ¶

aws-cdk #iac #typescript #testing #mcp¶