ひとことで言うと
CloudFrontのリクエスト/レスポンス経路上でNode.js・Pythonのコードを実行する仕組みです。GenAIの推論そのものをここで行う設計は成立しません。 30秒のタイムアウトとVPC非対応という制約が、FM呼び出しをエッジに置く発想をそもそも塞いでいます。
要するに、玄関先の受付です。建物（オリジン）に来客が着く前に、受付でヘッダーを確認したり、行き先を振り分けたりします。
受付は電話（ネットワーク呼び出し）を1本かけられますが、30秒しか待てません。FMへの推論リクエストのように数秒〜数十秒かかる重い用件を、受付だけで完結させる設計は無理があります。
なぜ生まれたか
GenAIアプリの多くはCloudFrontを前段に置きます。静的なフロントエンドの配信、API Gatewayへのルーティング、WAFとの連携がその理由で、Lambda@Edgeが出てくるとしたら「その経路の途中で何かを差し込みたい」場面です。ヘッダーの付与・書き換え、地域ごとのルーティング振り分け、認証トークンの検証などが典型です。
AIP-C01のIn-Scopeサービス表ではCompute区分にLambda@Edgeが載っていますが、スキル文の側にGenAI固有の用途は明記されていません。「載っているが主役として名指しされていない」サービスは、正しい使い方と誤った使い方を見分けさせる出題に回りやすい位置づけです。
| GenAIアプリの経路 | Lambda@Edgeが差し込める場所 |
|---|---|
| CloudFront → API Gateway → Bedrock | リクエスト前段のヘッダー付与・認証トークン検証 |
| CloudFront → 地域別バックエンド | origin requestでのルーティング振り分け |
| CloudFront → 静的フロントエンド | viewer responseでのセキュリティヘッダー付与 |
何に使うか
| 用途 | 使い方 | 関連ドメイン |
|---|---|---|
| GenAIチャットUIの配信最適化 | 静的フロントエンドをCloudFrontで配信し、ヘッダー付与・A/Bルーティングをviewer requestで行う | D2 |
| 地域ごとのバックエンド振り分け | origin requestでリクエストの送り先（リージョン別APIエンドポイント）を書き換える | D4 |
| 軽量な認証・トークン検証 | viewer requestでトークンを検証し、不正なリクエストをFM呼び出しの前段で弾く | D3 |
| レスポンスヘッダーの付与 | セキュリティヘッダー・キャッシュ制御をviewer responseで付与する | D4 |
試験でどう問われるか
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| 「グローバルユーザー向けにFM推論のレイテンシを下げたい」 | 推論はリージョンの計算資源が要る → Bedrock Cross-Region InferenceやAPI Gatewayのレイテンシ最適化で対応 | Lambda@Edgeでモデル呼び出し自体をエッジに置く（30秒制約・VPC非対応で成立しない） |
| 軽量なリクエスト加工（ヘッダー付与・単純な書き換え）をどこでやるか | ネットワーク呼び出しが不要な軽処理 → CloudFront Functions（サブミリ秒・~2MB制約） | ネットワーク呼び出しが要らない処理にわざわざLambda@Edgeを使う（オーバースペック） |
| 認証サービスへの問い合わせを伴う検証をエッジでやりたい | ネットワーク呼び出しが必要 → Lambda@Edge（30秒まで） | CloudFront Functionsで済ませようとする（外部ネットワーク呼び出し不可） |
CloudFront Functionsとの取り違えが最大の落とし穴です。CloudFront Functionsは外部ネットワーク呼び出しができずメモリも2MBに切り詰められていますが、サブミリ秒で動きます。Lambda@Edgeはネットワーク呼び出しができる代わりに立ち上がりが重く、最大30秒までしか待てません。「ネットワーク呼び出しが要るか」が両者を分ける唯一の実務上の分岐です。
実務でどう使うか
- デプロイリージョンはUS East（N. Virginia）固定。 関数はここに作成し、CloudFrontが世界中のエッジに複製します。他リージョンで作った通常のLambdaをそのまま流用することはできません
- VPCアクセス不可。 VPC内のBedrockインターフェースエンドポイントやプライベートなAPIには到達できません。パブリックエンドポイント経由の呼び出しに限られます
- 環境変数・レイヤー・コンテナイメージ・arm64・プロビジョンドコンカレンシーはすべて非対応。 通常のLambda運用でGenAIアプリ向けに整えた構成（レイヤーで依存を共有する、コンテナイメージでデプロイする等）はそのまま持ち込めません
- origin request/response以外ではCloudFrontが追加したヘッダーが見えません。 リクエスト元の情報（国コード等）を使ってルーティングを分岐する処理は、viewer requestではなくorigin request側に置く必要があります
| 制約 | 値 | GenAIアプリで踏みやすい場面 |
|---|---|---|
| デプロイリージョン | US East (N. Virginia)固定 | 他リージョンの既存Lambdaをそのまま流用しようとする |
| VPCアクセス | 非対応 | VPC内のBedrockインターフェースエンドポイントに到達しようとする |
| レスポンスサイズ | 40KB（viewer）/ 1MB（origin） | ストリーミング応答やドキュメントをエッジ経由で返そうとする |
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| CloudFront Functions | 外部呼び出し不要・サブミリ秒の軽処理はCloudFront Functions。ネットワーク呼び出しが要る／30秒までの重さが要るならLambda@Edge |
| 通常のLambda | 同じ実行環境ではない。VPC非対応・環境変数不可・コンテナイメージ不可など制約が大きく別物として扱う |
| API Gateway＋Lambda | エッジでの前処理はLambda@Edge。アプリのビジネスロジック（FM呼び出し本体）はAPI Gateway＋通常のLambda／Bedrockが受け持つ。役割が競合しない |
| Bedrock Cross-Region Inference | どちらも「地理的な距離」を扱うが、Cross-Region Inferenceは推論そのものの配置、Lambda@Edgeはリクエストの前処理。混同すると設計が破綻する |
想起チェック
Q1. 「エッジでFM推論のレイテンシを短縮したい」という要求に、Lambda@Edgeが正解にならない理由は？
30秒のタイムアウトとVPC非対応という制約があり、実質的なFM推論の実行環境として使えないためです。レイテンシ対策はBedrock Cross-Region Inferenceやリージョン側の最適化で行います。
Q2. CloudFront FunctionsとLambda@Edgeを分ける、実務上ただ一つの基準は？
外部へのネットワーク呼び出しが必要かどうかです。不要な軽処理はCloudFront Functions、認証サービスへの問い合わせなどネットワーク呼び出しを伴う処理はLambda@Edge（最大30秒）です。