はじめに
AWS を触り始めたばかりの頃にやらかした初歩的なミスをまとめたアドベントカレンダー、題して「AWS初歩ミス図鑑」の 18 日目です。
今回は Lambda@Edge用の関数を間違ったリージョンで作成してしまい、関数が見つからなくて困った話 を書いていきます。
過去のリージョン関連のミスは下記にまとめております。（お恥ずかしい限りです…。）
やっていたこと
CloudFront を使用したWebサイトで、特定のパスに関するリダイレクト処理を Lambda@Edge で行うことになりました。
なんとこちら当時のコードが残っていたのですが、（前職でこちらに関するブログを作成していたため）どう頑張っても特定につながりそうだったので引用はあきらめました。かわりに今話題沸騰の kiro さんにどんな処理をするコードだったのかを簡単にまとめてもらいましたので、以下に記載をしておきます。
このコードは Lambda@Edge で使用される リダイレクト処理 のコードですね！
コードの概要
撤退したサービスのドメインから、メインサイトに自動リダイレクトする機能です。
動作の流れ
1. ホスト名の判定
2. リダイレクト先の決定
3. 301リダイレクトレスポンス
具体的な動作例
パターン1: 特定ドメインへのアクセス
パターン2: 別の特定ドメインへのアクセス
パターン3: その他のドメインへのアクセス
…という感じです！
Lambda@Edge はまず Lambda のコンソールから関数を作成し、その後に CloudFront のコンソールからビヘイビアに紐づける必要があります。
この時も Lambda 関数を作成し、狙いのビヘイビアに Lambda@Edge として紐づけようとしていました。
結果
どれだけリロードをしても作成したはずの Lambda関数が選択肢に表示されませんでした。
度重なるミスで「リージョンは統一！リージョンは統一！」と呪文のように唱えていた私は、さっとくリージョンを確認し、関連リソースがすべてap-northeast-1で作成されていることを確認します。設定問題なし、コードの中身問題なし、権限問題なし……じゃあなんででないんだろう…とさんざん悩み、しばらくして以下の記事にたどり着きます。
何を考えていたのか
上記ドキュメントの通り、Lambda@Edge 用の関数を作成したい場合は、米国東部 (バージニア北部) リージョンで Lambda 関数を作成する必要があります。それをよく理解しないままに、Lambda@Edge という名前だけど結局やることは従来の Lambda関数と変わらないんだなあ、なるほど。と設定を進めていたのが間違いです。
その後無事にリージョンを切り替え、Lambda@Edge を使用することができました。
まとめ
Lambda@Edge を使用する場合はリージョンに気を付けましょう！
というのは大前提として、いまは CloudFront Functions というものがあります。
あまり複雑ではない処理をする場合は、こちらの方が設定も実装も簡単（あとは安い！）なので、Lambda@Edge と使い分けてみてはいかがでしょうか。