俺的CDKアップデートin2025 〜Enhanced L1にアラカルト添え〜

JAWSUG CDK支部 #24での発表資料です。独断と偏見で2025年のCDKアップデートを振り返ります。

Transcript

1. 俺的CDKアップデートin2025 〜Enhanced L1にアラカルト添え〜 JAWS UG CDK⽀部 #24 クライヤー篠塚 一帆 1
2. クライヤー篠塚 ⼀帆 @nixieminton @badmintoncryer AWS CDK Top Contributor & Community Reviewer 179 merged PRs / 116 reviewed PRs 19 / 1664 contributors (AWS社CDKチーム以外では世界2位🥈) APJC community leaders awards 2025 AWS community builders (Dev Tools) IPA資格 ネスペ, セキスペ, エンスペ バドミントンはキャリア20年！ 2025年は年代別(30歳以上) 全国ベスト16でした🎉 APJC community leaders awards 2025に選出！ re:invent不参加なので沼⼝さんが代理受賞
3. おさらい https://aws.amazon.com/jp/blogs/aws/boost-your-infrastructure-with-cdk/ CDKアプリケーションの構成 - App - Stack - Construct Constructの構成 - L1 (Low level) - Cloudformationリソースと1対1対応 - ⾃動⽣成 - Cloudformation更新に⾃動追従 - L2 (High level) - L1を抽象化 - 型、関数、引数チェック、etc.. を提供 - L3 (Pattern) - 複数のL1, L2を更に抽象化 3
4. 2025年のCDK更新 4 例年同様、L2には多種多様な新機能が追加されました。 ⼀⽅で今年印象的だったのは、これまであまり⼿が⼊ってこなかった L1に対しても数多くの拡充が⾒られた点です。 本⽇はL2への機能追加をアラカルト的に紹介する前半(Level 100-200)と、 L1の強化(Enhanced L1)を紹介する後半(Level 300)に分けて説明します。
5. 02 01 L2アップデート アラカルトin2025 Enhanced L1 5
6. ‧明⽇から使えるCDK新機能個⼈的第⼀位！ ‧マージまで3ヶ⽉ 特定のScopeに対するRemovalPolicy⼀括適⽤ 6 https://github.com/aws/aws-cdk/pull/32283 特定のscope配下の全リソースに⼀括で RemovalPolicyを適⽤ ex. scopeとしてstackを渡す → stack内の全リソースに適⽤ 同じことを実現する⾃作Aspects ⼆度と使うことはないでしょう。
7. Cloudfront VPC Origins 7 https://github.com/aws/aws-cdk/pull/33318 https://mazyu36.hatenablog.com/entry/2025/02/27/101630 ALB, NLB, EC2 instanceへの容易なorigin確⽴が可能！ ‧待望の新機能VPC OriginsをCDKで簡単に作成！ ‧Cloudfrontからoriginへの通信を許可するSG設定に⼀癖あり ‧stableなaws-cdk-libモジュールへのコミュニティからのL2追加がすんなり受け⼊れられた初のケース ‧マージまで2週間!!!!!!
8. Step FunctionsのJSONata対応 8 https://github.com/aws/aws-cdk/pull/32343 ‧直感的なファクトリーメソッドでjsonPathとJSONataを使い分け可能 ‧私は「JSONataなんてあるんだ」とこのPRで知りました ‧愚直な修正が膨⼤な数にのぼるPR。お疲れ様でした... ‧マージまで2ヶ⽉
9. APIGateway(REST API)の ストリーミングレスポンス対応 9 https://github.com/aws/aws-cdk/pull/36155 ‧AWS_PROXY, HTTP_PROXYでのIntegrationで設定可能 ‧AIエージェントからのレスポンス表⽰での⾼いニーズを汲んでいると推測 ‧機能追加からマージまで1週間! ストリーミングレスポンスを設定
10. Aurora Clusterのlookup 10 https://github.com/aws/aws-cdk/pull/34849 ‧IaC管理しづらいAuroraを容易にlookupできる選択肢が追加 ‧元々lookup関数はCLIからリソース情報を取得してAppに渡すcontext providerの実装が⾯倒だったが、  cloud control APIを汎⽤的に叩けるものが追加 ‧⼤変容易にいろんなlookupが実装できるステキな時代になっています iam.Role by go-to-k, ec2.PrefixList by tietew, ecr.Repository by badmintoncryer, … ‧マージまで1週間 クラスターIDから既存のAurora clusterをlookup
11. S3レプリケーション 11 https://github.com/aws/aws-cdk/pull/30966 ‧複数の宛先バケットを配列で設定可能 ‧Cfn仕様複雑怪奇ランキング圧倒的第⼀位。頑張って抽象化したのでぜひ使ってみてください。  ‧詳細が気になる⽅はこちら ‧マージまで8ヶ⽉ 複製先バケットを指定
12. NLBのSG設定をデフォルト化 12 https://github.com/aws/aws-cdk/pull/34675 ‧NLBにはSG無しNLB(レガシー)とSG有りNLBの2種類が存在 ‧CDKでは後⽅互換性の観点から、デフォルトではレガシーNLBを作るようになっていた ‧機能フラグ実装で破壊的変更を回避しつつ、デフォルトでSG有りNLBを作成するように変更 ‧マージまで10ヶ⽉ SG有りNLBを作成するために、 明⽰的なSG設定が必要だったが、 これを記述せずとも作られるように!!!!
13. EKS V2 13 EKS Cluster V1 module カスタム リソースで構築 V2 module Cloudformation で構築 V1とV2で記述内容はほぼ同⼀ ‧カスタムリソースで構築していたものをcloudformationでの構築に置き換えるケースはたまにある ‧毎回V2として別コンストラクト作成されてる気がする ‧既にGAさせるPRも発⾏済！⾼速alphaモジュール卒業でした
14. コントリビュートデビューして頂いた皆様 ありがとうございます！！ 14 AIの進化からCDKコントリビュートへのハードルは⼤きく下がっている今⽇この頃ですが、 レビューのスループットは変わらないため、マージまでにかかる時間は悪化し続けている状況です。 ゆったりとした気持ちでメンテナレビューをお待ち下さい and much more!
15. 02 01 L2アップデート アラカルトin2025 Enhanced L1 15
16. 注意点 16 ここからの内容はクライヤーの独⾃解釈を多く含みます。 AWS CDKの公式⾒解では無いことをご承知おきください
17. 背景 17 L2への機能追加は盛んに⾏われているが、 ⼈⼿を介するという点が実装の⼤きなボトルネック ⾃動⽣成されるL1⾃体を強化できれば、 わざわざPRを経由した機能追加を⾏わずとも ユーザは便利にCDKコンストラクトを扱えるのでは？
18. Enhanced L1 18 ⾃動⽣成されるL1⾃体の 機能拡張を⾏うことで、 L2に頼らずにユーザビリティの 向上を図る 2024/11にRFCが作成される • バリデーション • L1インターフェース導⼊ • Grantsクラスの⾃動⽣成 • stringよりも型安全な引数 https://github.com/aws/aws-cdk-rfcs/pull/657
19. 提案1 バリデーション 19 L1コンストラクトにおいても引数に対してバリデーションを実⾏する L2 L1 L1もsynth時に引数のバリデーションを⾏い、シフトレフトを実現する deploy時にcloudformation側でデプロイエラー😢 synth時にCDK側でバリデーションエラー 😆 synth正常終了 1-365のみ設定可能 1-365のみ設定可能
20. 提案2 L1インターフェース導⼊ 20 L1,L2コンストラクトが継承する新しいInterfaceをL1として⾃動⽣成する CfnBucket(L1)とBucket(L2)は無関係のクラス CfnBucket(L1)とBucket(L2)は同⼀Interfaceの具象クラス
21. 提案3 Grantsクラスの⾃動⽣成 21 RFCへの@mrgrain(CDKメンテナ)のコメント re:invent 2024にて3⼈のAWS Heroesと会話したメモ L1へのバリデーション導⼊めっちゃええやん！ 同様にIAM grants周りもCFNから⾃動⽣成 できたらなお良いんじゃない？！ grants周りの例 - sns.Topic.grantPublish() - agentcore.Runtime.grantInvoke()
22. 提案4 Stringよりも型安全な引数 22 ACM の証明書検証⽅法は ʻEMAIL’, ʻDNS’, ʻHTTP’ の3種類の⽂字列だけが許容 Cloudformation定義 ʻEmail’, ʻemail’, ʻmail’なども型的にはOKだが デプロイ時にエラーとなる L1 L1の引数はString型 型安全に引数を渡せる
23. 提案 提案4 Stringよりも型安全な引数 23 ACM の証明書検証⽅法は ʻEMAIL’, ʻDNS’, ʻHTTP’ の3種類の⽂字列だけが許容 Cloudformation定義 ʻEmail’, ʻemail’, ʻmail’なども型的にはOKだが デプロイ時にエラーとなる L1 stringより型安全な引数型にする L1の引数はString型 例: Enum型を⾃動⽣成 型安全に引数を渡せる 「L1にstringより型安全な引数を渡せるようにする」 後で出てきます
24. 提案4がハードル⾼すぎてRFCはペンディング 24 CDKでは引数のunion型が許容されないのでボツ シンプルな解決策
25. 提案4がハードル⾼すぎてRFCはペンディング 25 「xxxProps_v2として、 既存の引数と並列にEnum型の引数を追加」 提案された実装案 CDKでは引数のunion型が許容されないのでボツ シンプルな解決策
26. 提案4がハードル⾼すぎてRFCはペンディング 26 型安全な引数の導⼊があまりにもハードルが⾼く、 CDKv3へのアップグレードが不可避ということでペンディング 「requiredな引数の場合、 既存とv2引数を両⽅optionalにするので 型安全性が落ちない？」 AWSJ 友岡さん (@tmokmss) 後藤さん (@go-to.k) 「AspectsでL1引数のバリデーションを 独⾃実装してる場合に書き直しが必要...」 「xxxProps_v2として、 既存の引数と並列にEnum型の引数を追加」 提案された実装案 CDKでは引数のunion型が許容されないのでボツ シンプルな解決策 全世界から集まる数多の反対意⾒
27. 27 ⼀旦闇に葬られたかのように⾒えたRFCだったが....??
28. 2026/02/10時点での実装状況 28 • バリデーション • Grantsクラスの⾃動⽣成 • L1インターフェース導⼊ • stringよりも型安全な引数 実装済みの3つをご紹介します
29. ① Grantsクラスの導⼊ 29 L2 ⾮常に便利なgrantXxx関数だが、 L2でしか使えないことが⻑年の⽋点だった
30. ① Grantsクラスの導⼊ 30 L2 L1 ⾮常に便利なgrantXxx関数だが、 L2でしか使えないことが⻑年の⽋点だった L1コンストラクトであっても、 Grantsクラス(TopicGrants)を⽣成することで grant関数が実⾏可能に!!!!!
31. ① Grantsクラスの導⼊ (L2の内部実装) 31 L2でのgrant関数の使い⽅ (再掲) L1でのgrant関数の使い⽅ (再掲)
32. ① Grantsクラスの導⼊ (L2の内部実装) 32 L2でのgrant関数の使い⽅ (再掲) L1でのgrant関数の使い⽅ (再掲)
33. ① Grantsクラスの導⼊ (L2の内部実装) 33 L2でのgrant関数の使い⽅ (再掲) L1でのgrant関数の使い⽅ (再掲) L2内部でのgrant実装
34. ① Grantsクラスの導⼊ (L2の内部実装) 34 L2でのgrant関数の使い⽅ (再掲) L1でのgrant関数の使い⽅ (再掲) L2内部でのgrant実装 同じ関数を実⾏！
35. ① Grantsクラスの導⼊ (L2の内部実装) 35 L2でのgrant関数の使い⽅ (再掲) L1でのgrant関数の使い⽅ (再掲) L1ではユーザが⾏う「TopicGrantsの⽣成」を L2はコンストラクト内で暗黙的に⾏っているだけ。 実質、L1, L2のgrant関数で実⾏している内容は完全に同⼀ L2内部でのgrant実装 同じ関数を実行！
36. ① Grantsクラスの導⼊ (L2の内部実装) 36 L2でのgrant関数の使い⽅ (再掲) L1でのgrant関数の使い⽅ (再掲) 既存のgrantXxx関数は破壊的変更回避のために存続しているが、 内部的にはgrants.xxx()を実⾏するだけにリファクタされた。 grantXxx()は実質⾮推奨化。 ただし混乱回避のため明⽰的に@deprecated とはされていない L2内部でのgrant実装
37. ① Grantsクラスの導⼊ (こぼれ話1) 37 grants.jsonというファイルが各サービス毎に設置されています。 まだいくつかのサービスでしか作成されていないため、コントリビュートチャンスなはず?! 当初⽬標としていた「Cloudformationからの⾃動⽣成」には⾄っていない grantに必要なIAM action定義をcloudformationから引っ張ってこれないことが理由 必要なIAM actionを定義 「grants.publish()では 　`sns:publish`を追加する」
38. ① Grantsクラスの導⼊ (こぼれ話2) 38 @ren-yamanashi さんのAWS CDK向けeslintプラグインでも grantXxx()ではなくgrants.xxx()を使うことを推奨するルールが追加されています！ステキ！ https://github.com/ren-yamanashi/eslint-plugin-awscdk
39. ② L1インターフェース(Reference Interface)導⼊ 39 従来の実装
40. ② L1インターフェース(Reference Interface)導⼊ 40 従来の実装 L1インターフェース導⼊後 L1,L2ともにReference Interfaceをimplementsするように
41. 41 なにが嬉しいのか？
42. 42 L1インターフェース(Reference Interface)導⼊で嬉しいこと その1
43. (i) 引数にL1&L2を受け取れる 43 引数をReference Interface型にすると L1,L2コンストラクト全てを受け取ることができる IBucketRef型の引数 多様なS3バケットのコンストラクト達 - CfnBucket: L1 - Bucket: L2 - IBucket: ImportしたL2など 全てsomeFunction() に渡すことができる
44. 引数はL2 InterfaceよりもReference Interfaceが推奨に 44 https://github.com/aws/aws-cdk/pull/35032 コンストラクトを引数で受け取るときには L2 Interface型が推奨されていたが、 可能な限りReference Interface型に置換するPRが既にマージ済み
45. 45 https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md#consuming-construct-interfaces-what-interface-type-to-choose DESIGN_GUIDELINESにおいても、 引数でのL2 Interfaceの使⽤は “Most likely for legacy code”と表現😢 引数はL2 InterfaceよりもReference Interfaceが推奨に
46. 46 L1インターフェース(Reference Interface)導⼊で嬉しいこと その2
47. (ii) L1の引数にコンストラクト&⽂字列を渡せる 従来のL1 ⽂字列しか受け取れず、型安全性が低い
48. (ii) L1の引数にコンストラクト&⽂字列を渡せる 従来のL1 ⽂字列しか受け取れず、型安全性が低い 新しいL1 従来通り⽂字列はOK L1コンストラクトが渡せる！！ L2コンストラクトも渡せる！！ StringとReference Interfaceが引数型として許容されている
49. どうやってString or Reference Interfaceの 受け取りを実現している？ 49 Cfnから⾃動⽣成されるtopicArnの引数型が ITopicRefとstringのunion型に!!!
50. どうやってString or Reference Interfaceの 受け取りを実現している？ 50 引数のunion型は許容されないはずでは..?? Cfnから⾃動⽣成されるtopicArnの引数型が ITopicRefとstringのunion型に!!!
51. 引数におけるunion型 51 各⾔語版のCDKコードを ⽣成するツール
52. 引数におけるunion型 52 各⾔語版のCDKコードを ⽣成するツール string | number Union[str, Union[int, float]] Object interface{} (実質any) Javaやgolangではunionを表現できず、緩い制約の型に劣化してしまう。
53. 引数におけるunion型 53 各⾔語版のCDKコードを ⽣成するツール string | number Union[str, Union[int, float]] Object interface{} (実質any) Javaやgolangではunionを表現できず、緩い制約の型に劣化してしまう。 L1におけるReference Interface | stringもこの問題に直⾯するが、 利⽤頻度の少ないgo版CDKなどでのデメリットを上回るメリットがあると判断され、 例外的に採⽤に⾄っている
54. (ii) L1の引数にコンストラクト&⽂字列を渡せる (再掲) 54 新しいL1 従来通り⽂字列はOK L1コンストラクトが渡せる！！ L2コンストラクトも渡せる！！ Reference Interfaceを引数型として活⽤することで 「L1にstringよりも型安全な引数を渡せるようになった」 見覚えありますね
55. Enhanced L1での提案 RFCでの⽬的
56. Enhanced L1での提案 56 Enum型を⾃動⽣成する (RFCでの提案) → ボツ 実現⽅法 Reference Interfaceを 引数の型にする 当初の⽬的を「Reference Interface」活⽤という形で ⼀部実現したと解釈しています RFCでの⽬的
57. 57 L1インターフェース(Reference Interface)導⼊で嬉しいこと その3
58. ③ Grantsクラスを簡単に作れる L1でのgrant関数の使い⽅ (再掲) L2内部でのgrant実装 (再掲) 同じ関数を実⾏
59. ③ Grantsクラスを簡単に作れる L1でのgrant関数の使い⽅ (再掲) L2内部でのgrant実装 (再掲) 引数はL1 引数はL2
60. ③ XxxGrantsを簡単に作れる 60 L1でのgrant関数の使い⽅ (再掲) L2内部でのgrant実装 (再掲) 引数はL1 引数はL2 TopicGrantsクラスの実装
61. ③ XxxGrantsを簡単に作れる 61 L1でのgrant関数の使い⽅ (再掲) L2内部でのgrant実装 (再掲) 引数はL1 引数はL2 TopicGrantsクラスの実装 fromTopic()の引数はReference Interface!! だからL1とL2を受け取れる L1とL2どちらも受け取れるありがたみが 伝わったでしょうか？ ⾮常に応⽤の幅が広いステキなアップデート だと感じています
62. まとめ 62 • L2アップデートアラカルト in 2025 ◦ 今年も⽇本からのアツいアップデートがたくさんありました！！ ◦ 特にRemovalPoliciesは明⽇から全員活⽤できる新機能 ▪ Thank you @watany • Enhanced L1 ◦ L1⾃体の機能拡充が図られる新しい動き ◦ RFCはペンディングとなったが、いくつかは既に実装済み ▪ L1インターフェース導⼊ ▪ Grantsクラスの⾃動⽣成 ▪ stringよりも型安全な引数 ◦ 「L1とL2の差分を縮める」という考え⽅はMixinにも引き継がれているはず ◦ バリデーションもいつかくるかも？ ◦ L1コンストラクトにも使いこなし⽅が要求されてきました。 みんなでベスプラを模索していきましょう！