CloudFormationから理解するCDKのAwsCustomResourceの使用法

1. CloudFormation から理解する CDK のAwsCustomResource の使用法
2. 自己紹介 名前: Shota Kawasaki 年次: 2 年目 好きなサービス: AWS CDK x: @kawaaaas
3. Cfn やCDK での開発時、こんな課題ありませんか？ WAF Web ACL を us-east-1 に作る必要があるが、スタックは ap-northeast-1 クロスリージョンでWeb ACL のARN を疎結合に参照したい CloudFront とWAF の間で 循環依存 が発生する 依存関係を断ち切るために、別の手段でリソース情報を取得したい デプロイ後に自動でCloudFront の キャッシュを無効化 したい CloudFormation にはInvalidation のリソースタイプがない 標準リソースだけでは解決できない → CloudFormation のCustom Resource の出番 CloudFront を扱っていると遭遇しがちな場面
4. CloudFormation でのCustom Resource の書き方 Type に Custom:: プレフィクスをつける ServiceToken に Lambda 関数（またはSNS トピック）の ARN を指定 Create / Update / Delete 時に Lambda が invoke される 任意のCfn のライフサイクルのタイミングで、指定したLambda の処理を実行できる Resources: MyCustomResource: Type: Custom::MyResource Properties: ServiceToken: arn:aws:lambda:ap-northeast-1:123456789012:function:my-handler Param1: value1 Param2: value2
5. CloudFormation Custom Resource の仕組み S3 (ResponseURL) Lambda 関数 CloudFormation ServiceToken でLambda ARN を指定 2. ResponseURL （署名付きS3 URL ）が 含まれるイベントが渡される 1. Invoke （Create/Update/Delete ） 3. 任意の処理を実行 4. 結果をHTTP PUT で返す 5. 結果を受け取り、スタック操作を続行
6. CloudFormation Custom Resource のプロトコル CFn → Lambda （イベント） RequestType — Create / Update / Delete ResponseURL — 結果を返す署名付きS3 URL Lambda → CFn （レスポンス） Data は Fn::GetAtt で参照可能 PhysicalResourceId が変わると → 旧ID に Delete が走る { "RequestType": "Create", "ServiceToken": "arn:aws:lambda:...", "ResponseURL": "https://cfn-response...", "ResourceProperties": { ... } } { "Status": "SUCCESS", "PhysicalResourceId": "my-resource-id", "Data": { "Key": "Value" } }
7. ただ、これは結構めんどくさい Lambda 関数を 自分で実装する 必要がある Create / Update / Delete の条件分岐を自分で実装する必要がある ResponseURL への HTTP PUT を正しく実装 しないとスタックが最大1 時間ハングする エラーハンドリング、タイムアウト処理も自前 PhysicalResourceId の管理を間違えるとリソースの意図しない削除が発生する CDK はこの面倒を抽象化してくれる
8. CDK による抽象化: AwsCustomResource 素のCustom Resource AwsCustomResource Lambda 関数を自分で書く 自動生成（汎用SDK プロキシ） ResponseURL 処理を実装 抽象化済み RequestType の分岐を実装 onCreate/onUpdate/onDelete で宣言的に定義 IAM ポリシーを自分で設定 SDK 呼び出しから自動推論 PhysicalResourceId を自分で管理 宣言的に指定 →ユーザーが書くコード = なし（SDK 呼び出しを宣言するだけ） CloudFormation Custom Resource の面倒な部分をCDK が全て引き受ける
9. AwsCustomResource の書き方 onCreate / onUpdate / onDelete でライフサイクルごとにSDK 呼び出しを定義 service + action でどのAWS API を叩くか指定 policy — IAM アクションは自動推論、リソーススコープは手動指定 new cr.AwsCustomResource(this, "MyResource", { onCreate: { // onCreate / onUpdate / onDelete service: "s3", // AWS SDK のサービス名 action: "ListBuckets", // SDK API アクション名 physicalResourceId: cr.PhysicalResourceId.of("my-id"), region: "us-east-1", // 省略可（クロスリージョン時に指定） }, policy: cr.AwsCustomResourcePolicy.fromSdkCalls({ resources: cr.AwsCustomResourcePolicy.ANY_RESOURCE, // ARN で絞れないAPI はANY_RESOURCE }), // IAM アクションはSDK 呼び出しから自動推論 });
10. ユースケース① クロスリージョンWAF ARN 取得 ポイント: region を指定するだけでクロスリージョンのAPI 呼び出しが可能 SSM パラメータ経由でus-east-1 のWeb ACL ARN を取得 const ssmCall: cr.AwsSdkCall = { service: "ssm", action: "GetParameter", parameters: { Name: props.ssmParameterName }, region: "us-east-1", // クロスリージョン！ physicalResourceId: cr.PhysicalResourceId.of("waf-acl-arn-lookup"), }; const customResource = new cr.AwsCustomResource(this, "Lookup", { onCreate: ssmCall, onUpdate: ssmCall, policy: cr.AwsCustomResourcePolicy.fromSdkCalls({ resources: [`arn:aws:ssm:us-east-1:*:parameter${props.ssmParameterName}`], }), });
11. ユースケース② キャッシュ無効化 ポイント: onUpdate + CallerReference: Date.now() で毎デプロイ実行を保証 デプロイのたびにCloudFront キャッシュを無効化 this.customResource = new cr.AwsCustomResource(this, "Invalidation", { onUpdate: { service: "cloudfront", action: "CreateInvalidation", parameters: { DistributionId: props.distributionId, InvalidationBatch: { CallerReference: Date.now().toString(), // 毎回ユニーク Paths: { Quantity: invalidationPaths.length, Items: invalidationPaths }, }, }, physicalResourceId: cr.PhysicalResourceId.of("cf-cache-invalidation"), }, policy: cr.AwsCustomResourcePolicy.fromSdkCalls({ resources: [`arn:aws:cloudfront:*:*:distribution/${props.distributionId}`], }), });
12. 補足: 他の選択肢 Provider + CustomResource — 任意のLambda を書きたい時に 複雑なロジック、AWS 以外のAPI 、非同期処理（ポーリング）が必要な場合 ResponseURL 処理はフレームワークが担当してくれる Trigger — デプロイ時にLambda を1 回実行するだけ 値の参照もDelete 処理も不要な場合（マイグレーション、初期データ投入等） AwsCustomResource では対応できないケースもある
13. デメリット・注意点 デプロイ時間が伸びる（Lambda 実行分） デバッグが難しい ResponseURL PUT 失敗 → 最大1 時間ハング シングルトンLambda のIAM ポリシーが 全AwsCustomResource 分累積 する 便利だけど乱用は控え、必要最小限で使うべき。
14. まとめ CloudFormation Custom Resource は ServiceToken + 署名付きURL のプロトコルで実現されている CDK の AwsCustomResource はこのプロトコルを完全に抽象化してくれる Lambda 不要、IAM ポリシー自動推論、宣言的なSDK 呼び出し定義 クロスリージョン参照やキャッシュ無効化など、標準リソースでは解決できない課題に有効 ただし乱用は禁物。デプロイ時間増加やIAM ポリシー累積に注意 複雑なロジックが必要なら Provider + CustomResource や Trigger も選択肢に
15. ご清聴ありがとうございました！