こんにちは。
今回は、Lambda@Edgeについて整理してみます。
Lambda@Edgeとは
Lambda@Edgeは、Amazon CloudFrontのエッジロケーションでAWS Lambda関数を実行できるサービスです。
通常のLambdaはAWSリージョンで実行されますが、Lambda@Edgeはユーザーに近いエッジロケーションで処理を実行できます。
例えば、世界中のユーザーがWebサイトへアクセスする場合は次のような構成になります。
ユーザー
│
CloudFront
│
Lambda@Edge
│
S3 / ALB / EC2
ユーザーの近くで処理を実行するため、レスポンス時間の短縮が期待できます。
Lambda@Edgeのデプロイ方法
Lambda@Edgeには、通常のAWS Lambdaとは異なる制約があります。
Lambda関数は必ず米国東部（バージニア北部：us-east-1）リージョンで作成する必要があります。
作成した関数はCloudFrontによって世界中のエッジロケーションへ自動的にレプリケートされます。
us-east-1
│
Lambda@Edge
│
CloudFront
│
世界中のエッジロケーション
そのため、CloudFrontディストリビューションがどのリージョンのリソースを配信していても、Lambda@Edge自体はus-east-1で管理します。
Lambda@Edgeが必要な理由
通常のCloudFrontはコンテンツをキャッシュすることが主な役割です。
しかし、
- リクエストを書き換えたい
- レスポンスヘッダーを追加したい
- 国ごとに表示内容を変更したい
- 認証を行いたい
などの処理は標準機能だけでは対応できません。
そのような処理をエッジロケーションで実行できるのがLambda@Edgeです。
Lambda@Edgeでできること
① リクエストの書き換え
例えば、
/index
へアクセスされた場合に
/index.html
へ書き換えることができます。
② レスポンスヘッダーの追加
例えば
Strict-Transport-Security
Content-Security-Policy
X-Frame-Options
などのセキュリティヘッダーを追加できます。
③ 国ごとの表示切替
CloudFrontには閲覧者の国情報があります。
日本
↓
日本語ページ
アメリカ
↓
英語ページ
のような振り分けができます。
④ 認証処理
オリジンサーバーへ到達する前に
CloudFront
│
Lambda@Edge
│
認証
│
S3
のような処理を実装できます。
Basic認証などで利用されることがあります。
⑤ Cookie・ヘッダーの変更
例えば
Cookie追加
User-Agent判定
Authorization追加
なども可能です。
⑥ 画像の動的リサイズ
Lambda@Edgeでは、画像サイズをアクセス時に動的に変更することもできます。
ブラウザ
│
CloudFront
│
Lambda@Edge
│
画像サイズ変更
│
S3
例えば、
/photo.jpg?width=300
というリクエストを受けると、300pxにリサイズした画像を生成して返すことができます。
このようなネットワークアクセスを伴う処理は、CloudFront Functionsでは実現できません。
Lambda@Edgeが実行されるタイミング
Lambda@EdgeはCloudFrontのイベントに応じて実行されます。
| イベント | 内容 |
|---|---|
| Viewer Request | ユーザーからリクエストを受信した直後 |
| Origin Request | オリジンへ転送する直前 |
| Origin Response | オリジンから応答を受信した直後 |
| Viewer Response | ユーザーへレスポンスを返す直前 |
例えば、
ユーザー
│
Viewer Request
│
CloudFront
│
Origin Request
│
S3
│
Origin Response
│
CloudFront
│
Viewer Response
│
ユーザー
必要なタイミングで処理を追加できます。
イベントごとの特徴
ViewerイベントとOriginイベントでは、実行できる処理の規模が異なります。
-
Viewer Request / Viewer Response
- 軽量な処理向け
- URL書き換え
- ヘッダー追加
- リダイレクト
-
Origin Request / Origin Response
- より高度な処理向け
- 認証
- 画像変換
- オリジンアクセス前後の制御
イベントごとの実行時間やメモリなどの制限値は変更される可能性があるため、最新の内容はAWS公式ドキュメントを確認することをおすすめします。
Lambda@Edge利用時の注意点
Lambda@Edgeでは、$LATESTは利用できません。
CloudFrontへ関連付ける際は、必ず発行済みバージョンを指定します。
Lambda
│
├── $LATEST ×
├── Version 1 ○
├── Version 2 ○
新しいコードを反映したい場合は、新しいバージョンを発行し、そのバージョンをCloudFrontへ関連付けます。
CloudFront Functionsとの違い
| 項目 | Lambda@Edge | CloudFront Functions |
|---|---|---|
| 実行場所 | CloudFrontエッジ | CloudFrontエッジ |
| 実行タイミング | 4種類すべて | Viewer Request / Viewer Responseのみ |
| 実行時間 | 最大30秒（イベントによる） | 数ミリ秒 |
| ネットワークアクセス | ○ | × |
| AWS SDK利用 | ○ | × |
| 主な用途 | 認証・画像変換・高度な処理 | URL書き換え・ヘッダー変更など軽量処理 |
CloudFront Functionsは非常に高速な軽量処理に向いており、Lambda@Edgeは認証や画像変換など、より高度な処理に適しています。
Lambda@Edgeと通常のLambdaの違い
| 項目 | Lambda | Lambda@Edge |
|---|---|---|
| 実行場所 | AWSリージョン | CloudFrontエッジロケーション |
| CloudFront連携 | △ | ◎ |
| レイテンシ | やや高い | 低い |
| 世界中への配信 | △ | ◎ |
通常のLambdaはリージョンで動作します。
一方、Lambda@Edgeはユーザーに近い場所で実行されるため、グローバルサービスとの相性が非常に良いです。
Lambda@Edge 設計・開発時の注意点（落とし穴）
1. 環境変数が使用不可
通常のLambdaと違い、環境変数が使えません。設定値や外部APIのキーなどを動的に管理したい場合は、AWS Systems Manager (SSM) のパラメータストアやSecrets Managerなどから取得する実装が必要です。
2. 開発言語（ランタイム）の制限
Node.js と Python のみがサポートされています。Go、Java、カスタムランタイムなどは利用できません。
3. イベント選定によるコストとパフォーマンスの差
- Viewer Request：キャッシュの有無に関わらず「全アクセス」で起動するため、コストが高くなりやすい（軽量な処理向け）。
- Origin Request：キャッシュがない時（Miss時）だけ起動するため、コストを抑えられる（重い処理、ネットワークアクセス向け）
まとめ
Lambda@Edgeは、CloudFrontのエッジロケーションでLambda関数を実行できるサービスです。
通常のCloudFrontでは実現できないリクエスト・レスポンスの加工や認証処理を、ユーザーに近い場所で実行できるため、低レイテンシかつ柔軟なWebアプリケーションを構築できます。
また、Lambda@Edgeには
- us-east-1で作成する必要がある
- 発行済みバージョンを利用する
- ViewerイベントとOriginイベントで用途が異なる
といった特徴があります。