本日はだいぶ趣向を変えて、本業の仕事でハマった話について備忘録としてまとめます。
おそらくほとんどの方が興味ない話になるので、ブラウザをそっと閉じてください。

そもそも本業は？

Webのフロントエンド周り全般を制作するエンジニアです。
去年までは大手企業のコーポレートやECサイトの制作をプロジェクト管理からディレクション、新人やニア・オフショアの教育まで幅広く担当してきました。
大規模サイトはCMS自社開発したり、EC-CubeやMagento等EC系大手CMSでのサイト構築がほとんどで、小中規模サイトを触る機会が少なかったので、自身の勉強のためもあってこのサイトを制作しました。（とはいえまだほとんど何も触れていませんが。。）
今年は一転してnode.jsでAPI作ったり、DB触ったり、フロントエンドから少し守備範囲が広がりつつありますが、バックエンドも勉強すればできるはずと思って勉強と挑戦の毎日です。

AWS API Gateway CORS有効化にハマる

早速ですが、AWSの S3・API Gateway・Lambda・DynamoDB・SNS を組み合わせて、PHPを使わずに、AWSのみでバックエンドが完結するお問い合わせフォームを制作中です。
何かと制約があり今回PHPが使用できないためこのようなフローでの開発となっています。
一連の動き自体は完成したのですが、本日API GatewayでAPIキーを設定しようと、
レスポンスヘッダーに「Access-Control-Allow-Origin」の追加等、CORS設定を行いましたが、

「No ‘Access-Control-Allow-Origin’ header is present on the requested resource.」

というエラーがでました。
色々原因を追究しましたが見事にハマってしまい、かなり工数をとられてしまいました。

原因

アクションからCORSの有効化を行い、デプロイ時に「OPTIONS」はCORSが有効となっているが、メソッド「ANY」から生成される「POST」にはCORSが有効となっていなかったことが原因のようです。
「ANY」のレスポンスヘッダーには間違いなく「access-control-allow-origin:*」が確認できたが、デプロイ後生成される「POST」に関しては、Chromeデベロッパーツールのネットワークタブで「access-control-allow-origin:*」が確認できずCORSエラーとなっていた。
メソッド「ANY」を削除し、メソッドの作成から「POST」を作成、同様の設定をしたところ、レスポンスヘッダーに「access-control-allow-origin:*」が確認でき、エラーが解消された。

Webサイトからajax通信でAPIをたたく場合等、クロスドメインでAPIを使う際は、現状「ANY」を避けたほうが良いかもしれません。
自分のやり方が間違っているのか、またはAWS API Gatewayのバグで今後改善されるのか、試行錯誤しながら様子をみたいと思います。