cloudpack あら便利カレンダー 2017 の11日目です。

追加されたのはだいぶ前ですが、 Lambda Backed Custom Resource のおかげでカスタムリソースを使う敷居がだいぶ下がりました。

カスタムリソースは CloudFormation でネイティブサポートされていないリソース（AWS のリソースでなくても構わないです）を作成・更新・削除する仕組みですが、 Lambda Backed カスタムリソースは大まかに言うと以下のような流れでリソースを操作します（話を単純にするため、ここでは Create の例のみ）。

リソースの操作を行う Lambda Function をあらかじめ用意しておくか、カスタムリソースを含めるテンプレート内で作成する（この Function が custom resource provider となる）
テンプレートにカスタムリソースの定義を含める
- ServiceToken として上で用意した Lambda Function の ARN を指定する
- そのリソースの操作に必要なプロパティもここに指定する
カスタムリソースを含めたテンプレートで CreateStack を実行する
custom resource provider が Custom Resource Request を与えられ起動される
custom resource provider がリクエストの内容に基づきリソースを作成する
custom resource provider はリソースが作成できたことを CFn に通知する必要があるため、前述のリクエストに含まれている ResponseURL （S3 オブジェクトの署名済み URL）に対して、 Custom Resource Response の JSON を HTTPS PUT する

前置きが長くなりました。今回のネタはこの最後の段階についてです。

罠って何

Custom Resource Response の PUT で、 Content-Type ヘッダーに application/json を指定すると 403 Forbidden で失敗します。

Content-Type を指定しつつ、内容は何も設定しない（空文字）のが正解です。使用するライブラリー等によっては自動で付加されることもあるので要注意。

地味にハマる仕様なので気をつけましょう。