KIOXIA(キオクシア) 旧東芝メモリ microSD 256GB EXCERIA PLUS UHS-I U3 V30 Class10 Nintendo Switch動作確認済 microSDXC 最大読出100MB/s 最大書込85MB/s 4K対応 国内サポート正規品 メーカー保証5年 KLMPAE256G
¥3,780 (2025年4月25日 13:08 GMT +09:00 時点 - 詳細はこちら価格および発送可能時期は表示された日付/時刻の時点のものであり、変更される場合があります。本商品の購入においては、購入の時点で当該の Amazon サイトに表示されている価格および発送可能時期の情報が適用されます。)ALLDOCUBE iPlay 60 mini 8.7インチタブレット 90Hz高リフレッシュレート Android 15 デュアルスピーカー Widevine L1 8コアCPU T606 12GB+64GB+512GB拡張 Incell IPSディスプレイ 400ニット輝度 4G LTE デュアルSIM GPS OTG 3.5mmイヤホンジャック 複数のユーザーをサポート
¥15,999 (2025年4月25日 13:05 GMT +09:00 時点 - 詳細はこちら価格および発送可能時期は表示された日付/時刻の時点のものであり、変更される場合があります。本商品の購入においては、購入の時点で当該の Amazon サイトに表示されている価格および発送可能時期の情報が適用されます。)
◾️ はじめに
現在、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 関数を使えば自在に制御できます。
同じような課題に直面している方の参考になれば幸いです!