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

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

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

  1. リソースの操作を行う Lambda Function をあらかじめ用意しておくか、カスタムリソースを含めるテンプレート内で作成する（この Function が custom resource provider となる）
  2. テンプレートにカスタムリソースの定義を含める
    ・ ServiceToken として上で用意した Lambda Function の ARN を指定する
    ・ そのリソースの操作に必要なプロパティもここに指定する
  3. カスタムリソースを含めたテンプレートで CreateStack を実行する
  4. custom resource provider が Custom Resource Request を与えられ起動される
  5. custom resource provider がリクエストの内容に基づきリソースを作成する
  6. 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 を指定しつつ、内容は何も設定しない（空文字）のが正解です。使用するライブラリー等によっては自動で付加されることもあるので要注意。

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

元記事はこちら

「CFn Custom Resource でハマりがちな罠」