◾️ はじめに

　現在、CDKを使用し、インフラを構築する中で、各アプリケーションごとに異なるAPIパスが定義されていました。しかし、管理画面側では統一されたパスで管理したいという要件があり、CloudFront単体ではルーティングの柔軟性に限界があることがわかりました。

そこで登場するのがLambda@Edgeです。
これを活用することで、CloudFront経由のリクエストパスを書き換えることが可能になります。

本記事では、Lambda@Edgeの概要から、実際の構成・コード例、設定方法までをまとめています。

ぜひ最後まで一読していただけますと幸いです。

◾️ Lambda@Edgeとは？

Lambda@Edgeは、CloudFrontのリクエスト処理に直接介入できるグローバル実行のLambda関数です。

もう少し具体的に言うと、CloudFrontは、世界中に配置された「エッジロケーション」でリクエストを処理する仕組みを持っていますが、CloudFront 単体では以下のような処理ができません...

パスの書き換え
ヘッダーの追加/検証
Cookieによる制御

このような制限を補う形で登場するのがLambda@Edgeです！！

Lambda@Edgeは、CloudFrontの以下4つのフェーズで任意の処理を挟むことができます。

フェーズ名	タイミング	主な用途
Viewer Request	ブラウザ → CloudFront	リクエスト書き換え、認証など
Origin Request	CloudFront → オリジン	パスの調整、ヘッダー追加など
Origin Response	オリジン → CloudFront	レスポンス加工、キャッシュ制御など
Viewer Response	CloudFront → ブラウザ	Cookie・ヘッダー追加、カスタムレスポンスなど

通常のLambdaとの違い

では、通常のLambdaと何が違うのかを具体的にまとめました。

特徴	通常のLambda	Lambda@Edge
実行される場所	特定リージョン（例：東京）	世界中のCloudFrontエッジ
レイテンシ	距離によって変動	超低レイテンシ（近いエッジで実行）
CloudFrontとの連携	❌ できない	⭕️ 完全統合
使用例	API処理、バッチ処理など	CloudFrontパス制御、動的ルーティング、認証など

これまでの説明で分かる通り、普通のLambdaではCloudFrontのリクエスト処理の前に介入できないということです。

Lambda@Edgeで関数を作成する際に、注意点があります⚠️
Lambda@Edgeの関数は必ず us-east-1（バージニア北部） にデプロイする必要があります。
これは「グローバルにコピーされる」仕様のため、デプロイ元が us-east-1 に限定されているためだそうです。

◾️ 今回のケース

今回取り上げるのは、以下のようなパスリライトです。

変換例：/api/{project名}/create → /api/create

背景：URLにプロジェクト名が含まれているが、実際に呼び出すAPIは共通のエンドポイントを使用したい。

目的：CloudFront側で見せかけのパスだけを変えて、APIの内部ロジックは共通化する。

◾️ Lambda@Edge のCDKでの定義

const rewriteApiPathFunction = new experimental.EdgeFunction(this, `RewriteApiPathFn`, {
  functionName: `cloudFront-rewrite-api-path`,
  runtime: lambda.Runtime.NODEJS_22_X,
  handler: 'rewriteApiPath.handler',
  code: lambda.Code.fromAsset(path.join(__dirname, 'rewriteApiPath'))
})

◾️ 実際の作成する関数内容（例：viewer-request）

exports.handler = async (event) => {
　// HTTP リクエストオブジェクト
  const request = event.Records[0].cf.request;
  request.uri = request.uri.replace(/^\/api\/{project名}/, '/api');
  return request;
};

◾️ CloudFrontに組み込み

書き換えたいパスに対応するBehaviorに、作成したEdgeFunctionを設定します。
今回は、リクエストをオリジンに送る前に書き換えたいので、Origin Requestに割り当てます。

実際にリライトを行いたいAPIを叩いて、APIが関数で指定したパスに書き換わっていたら完了です✨

◾️ デバッグ・ログのコツ

console.log() は CloudWatch Logs（us-east-1）に出力されます。
エラーや期待通りに動かない場合、まずはログを確認してみてください！

✅ 注意点

デプロイ後の反映に時間がかかる場合があります。
us-east-1限定デプロイに注意（他リージョンでは設定できません）

◾️ まとめ

　最後までご覧いただきありがとうございました！
CloudFront のルーティングに柔軟性を持たせたいときは、Lambda@Edge の活用が非常に有効です。
通常の CloudFront では難しいパスの書き換えや条件分岐も、Lambda 関数を使えば自在に制御できます。
同じような課題に直面している方の参考になれば幸いです！