ENECHANGE所属のエンジニア id:tetsushi_fukabori こと深堀です。お久しぶりです。
この4月から所属事業部がかわりました。
元はEMAPシリーズを提供しているエネルギークラウド事業部に所属して「アプリケーションエンジニア兼PM兼事業部内テックリード」という長い肩書を持っていましたが、今はCTO室という事業部で肩書のない一般社員をやっています。
インフラ管理なんかもCTO室の業務なので、なれないterraformをこわごわ触っている日々です。そのへんはまた別記事で。
この記事の概略
- AWS Lambdaの2022年4月の新機能「関数URL」を実戦投入しました
- Route53 + CloudFront + Lambda関数URLでシンプルなリダイレクト処理を構成しました
- CloudFront functionやLambda@Edgeを使う場合と比較して小さいながらコストメリットがあることを整理しました（次回コスト編で紹介します）
Lambda関数URLを使いたい
Lambda関数URLは2022年4月6日に発表された機能でLambda関数に直接URLを生やせます。
ユースケースとしてはcallbackのURLにして小さい処理をするとかでしょうか。
今まではLambdaの前段にAPI Gatewayなど何かが必要だったのをなくしてくれるので良いですね。ワクワクします。
せっかく新しく生えた機能なのでなにかに使いたいですね。
できれば本番環境に使いたいですね。
都合の良さそうな開発テーマが発生した
使いたい機能があると使えそうなテーマが生まれるものです。なんだかちょうど良さそうなテーマが発生しました。
画像は弊社CTOからの依頼です。
ENECHANGE社は「enechange」ドメインを取得していますが、「enechange.com」は放置していたのでDNS登録もなく何もレスポンスしない状態でした。
それをエネチェンジのコーポレートサイト英語ページ「enechange.co.jp/en/」にリダイレクトしたいようです。
これ、都合が良い気がしますね。
ただリダイレクトする処理を実装する
弊社では過去にも諸事情により「ただ固定的なURLにリダイレクトする処理」を作ったことがあります。
その際には
- CloudFront distribution（オリジンは空のS3バケット）を作り
- CloudFront functionでリダイレクト処理を行い
- Route53でCroudFront distributionにドメイン名を当てる
という対応をしていました。
この構成でも問題はないのですが、空のS3バケットが発生するのが少し気になりました。
今回はLambdaの関数URLを使うことでシンプルなリダイレクト処理を実装してみます。
Sandbox環境でLambda関数URLを試す
ENECHANGE社ではAWSのサービスをお試しで使ってプロダクト開発の実験ができるようにSandbox環境が用意されています。
ENECHANGE社が商用環境として使っているアカウントとは切り離されているため安心してお試しができます。
ありがたいですね。
まずはSandbox環境でリダイレクトの処理を書いて関数URLを発行し、実際にURLにアクセスしてリダイレクトされることを試します。
マネージドコンソールからLambda関数の新規作成画面を開き、特に細かいことは考えず関数を作成します。
パブリックなURLを払い出したいので認証は「NONE」を選択して関数URLも一緒に作成します。
できました。URLも発行されていますね。
実際にcURLでGETすると想定通りステータスコード302でhttps://enechange.co.jp/en/に転送されます。
あとはこの関数URLに向けてRoute53でenechange.comを向けてあげれば良いですね！やった！完！！！
HTTPに対応できていない
残念ながら上記の方法ではHTTPSではなくHTTPでアクセスされた場合に対応できません。
関数URLはHTTPSのURLを発行してくれますが、HTTPについてはケアされません。AWSの公式でも以下のように記載があります。
（前略）この新機能は、AWS Lambda サービスの組み込み機能として、HTTPS エンドポイントを介して関数を簡単に呼び出せるようにします。（後略）
（そもそも上記ドキュメントのタイトルからして「AWS Lambda 関数 URL: Lambda 関数用の組み込み HTTPS エンドポイント」（太字は筆者による加工）となっているのですが…。）
ですのでHTTPでリクエストが来たときには何らかの方法でHTTPSのLambda関数URLが応えられるよう制御してあげる必要がありそうです。
一瞬「HTTPSだけでいいのでは…？」という気持ちが頭をもたげますが、enechange.co.jp自体HTTP→HTTPSの転送を行っていますし流石にケアするべきでしょう。
Lambda関数URLを実戦に投入することはできないのでしょうか？
Lambda関数URLをCloudFront distributionのオリジンに指定する
新しい機能の実戦投入ができず悲嘆に暮れながらブラウジングをしていたところ、一つの光明が見つかります。
以下のAWSのブログ記事ではLambda関数URLをCloudFrontのオリジンにしているようです。
なるほどCloudFront distributionはオリジンにHTTPSのエンドポイントを指定できるんですね。
加えてご存知の通り、CloudFrontはそれ単体でHTTPとHTTPSの両方のリクエストを捌くことができます。
これはつまり、上記のブログ記事の構成を取れば「Lambda関数URLを使う」「HTTPとHTTPS両方をリダイレクトできる」が両立できるのでは…？
ということで早速試してみます。
CloudFront distributionを作成する際に「Lambda関数URLのドメイン」を指定します。関数URLそのものではなく先頭の「https://」と末尾の「/」は除いて設定することになります。
オリジンとなる関数URLはHTTPSのみ受け付けているのでプロトコルは「HTTPSのみ」を指定します。
当初要件の通りCloudFront distribution自体はHTTP/HTTPS両方に対応したいのでビューワープロトコルポリシーは「HTTP and HTTPS」を指定します。
後はこのCloudFront distributionにRoute53でAレコードをあててenechange.comへのHTTP/HTTPSリクエストを流してあげます。
結果検証
cURLでenechange.comにリクエストを送ると正しくhttps://enechange.co.jp/en/へリダイレクトする302レスポンスが返ってきました。
HTTPでリクエストをしても想定通りレスポンスを返してくれているようです。
ということで、シンプルな構成でリダイレクトを実現し、新機能であるLambda関数URLを実戦投入することができました。
最終的な構成は下図の通りです。
まとめ
AWS Lambdaの新機能を使ってシンプルなリダイレクト処理を作成し、（強引ながら）実践で新機能を使うことができました。
これからも新サービス・新機能を見つけたら積極的に実戦投入の機会を探っていこうと思います。
次回コスト編では今回の構成のコストについて比較検討をします。
