今回は、『リダイレクトサーバーを CloudFront + Lambda で用意する』という話題を取り扱います。 AWS 前提で話しますが、他クラウドサービスでも同様のことは実現可能だと思います。

リダイレクトサーバーは保守・運用面で悩みの種

Web サービスを運用していると、以下のような状況でリダイレクトサーバーを用意することが多いと思います。

• ドメインを移行したので、旧ドメインから移動できるようにしたい
  • こちらは原則ドメインだけリダイレクトすればいいのでシンプル
• サイトが閉鎖されるが、後継サービスの該当のページへのリダイレクトだけは残したい
  • こちらは規模次第では複雑なリダイレクトルールを管理する必要がある

しかし、リダイレクトサーバーには以下の悩みがあります。

• リダイレクトのルールが複雑になると、Apache/Nginx + アプリなどで対応する必要がある
  • サーバーを稼働する必要がある
    • 保守作業が生じる
      • 例えば AWS EC2 だと、AWS 都合のマイグレーション対象になるなど
  • CloudFront + CloudFront Function などで対応できるのは簡単なリダイレクトのみ
    • この方法だとキャッシュが効かなくなるので、費用が重なる
    • キャッシュを聞かせるために Origin request 部分で Lambda@Edge を利用すると、それはそれで保守が大変
      • CloudFront ディストリビューションに関連付ける Lambda はバージョンも指定する必要があり、関連付けを更新する度に反映されるまで５分程度かかる
        • 確認できるようになるまで時間がかかる

（本題）リダイレクトを Lambda で実施し、その上に CloudFront でキャッシュを置くことで効率的にリダイレクトさせる

Lambda 関数はレスポンスを返せる上に、2024年12月現在では『URL 発行した Lambda 関数』を CloudFront ディストリビューションのオリジンに設定可能です。つまり、以下の組み合わせで、効率的なリダイレクトサーバーを構築可能です。

• URL 発行済み Lambda を用意する
  • リダイレクトをレスポンスとして返すようにする
    • 具体的な設定は設定ファイルなどに JSON 形式で保存して、アクセスされた URI などに応じて切り替える
  • OriginAccessControl でアクセスを制御する
• CloudFront ディストリビューショのオリジンに Lambda を置く
  • OriginAccessControl で Lambda へのアクセスを許可する

この方法だと、以下利点が得られ、上で出た悩みを解決できます。

• Lambda をデプロイするだけで、最新バージョンが適用される
• OriginAccessControl でアクセス制御しているので、直に Lambda にアクセスされることはない
  • 認証機能のために Lambda に機能を追加したり、API Gateway を噛ませる必要がない
• リダイレクトのレスポンスが CloudFront にキャシュとして保存される
  • キャッシュがある間は即座にレスポンスを返せる
    • リダイレクトルールが変わることは滅多にないので、キャシュ保持期間を１週間以上にしても問題ない
      • リダイレクトルールが変更された時だけキャッシュを削除すればいい
  • 費用もほとんどかからない
    • オリジンにある Lambda 自体が安価な上に、キャッシュが効いている間は実行されない

まとめ

• リダイレクトサーバーを CloudFront + Lambda で用意すると、様々な利点がある
  • 保守・運用コストが減る
  • 金銭面でもコストが減る
  • ある程度複雑なリダイレクトルールにも対応可能

参考元

AWS Lambda 関数 URL オリジンへのアクセスを制限する

https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-lambda.html