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 を指定しつつ、内容は何も設定しない（空文字）のが正解です。使用するライブラリー等によっては自動で付加されることもあるので要注意。
地味にハマる仕様なので気をつけましょう。