AWS EDGE AUTH 解説

CloudFront Functions と Lambda@Edge — 会員サイトの門番をどこに置くか

『DBを使うならLambda@Edge？』『署名付きCookieで動画は守れる？』を、CloudFrontの入口からNext.js・APIまで一続きの流れで整理する。ポイントは処理の複雑さではなく、判断材料がどこにあるか。

TL;DR

  1. 通常の動的ページとDB処理はNext.js・APIへ置く。
  2. リクエスト内だけで判定できるならCloudFront Functions、複数ファイルの許可なら署名付きCookie。
  3. 外部の認可APIへ問い合わせる判断をCloudFront入口で行うときだけLambda@Edge。

01まず4つの役割を分ける

同じ『振り分け』でも、固定ルール・軽量判断・外部照会・ページ生成は別の仕事。

CloudFront周辺の4層の役割分担図
DBを読む通常業務は右端のアプリ層。Lambda@Edgeは入口で外部照会が必要な特殊な門番。
層判断材料代表的な仕事
CloudFrontビヘイビアURLパスなどの固定設定/static/*はS3、それ以外はAmplify
CloudFront FunctionsURL・ヘッダー・Cookie・JWTリダイレクト、URL書換え、軽いトークン検証
Lambda@Edge上記＋外部API・AWS SDK・リクエストボディエッジで動的認可、接続先変更、複雑な加工
Next.js・バックエンドDB・業務データ・セッション管理画面、受講ページ、一覧取得、通常の認可

DBでページを出し分けるだけならLambda@Edgeではない。通常はNext.jsやAPIがDBを読み、ページを生成する。

02境界は『判断材料がリクエスト内にあるか』

コードが長いか短いかより、外へ問い合わせる必要があるかで決める。

CloudFront FunctionsとLambda@Edgeの選択フロー
JWTに必要な権限が入っていればFunctionsで足りる。現在のDB状態が必要ならLambda@Edge候補。
Cookieなし      → /loginへ         = Functions
JWT plan=premium → /premiumへ       = Functions
現在も契約中？    → 認可APIへ確認     = Lambda@Edge
案件に所属中？    → DBをAPI経由で確認 = Lambda@Edge

『DBを使うシステムだからLambda@Edge』ではない。『CloudFrontの入口でDB由来の最新状態を使わなければならない』場合に限る。

03会員動画は3段階で考える

1本だけ、講座一式、現在の購入状態を都度確認——要件ごとに門番を変える。

会員動画配信の3つの認可方式
HLSは多数のファイルを取得するため、一定範囲を許可する署名付きCookieと相性がよい。
要件最小の選択理由
1本のダウンロードを10分だけ許可署名付きURL対象ファイルが1つ
会員に/videos/course-a/*を許可署名付きCookieHLSセグメントなど複数ファイルを同じURLのまま保護
購入・返金・停止を毎回最新状態で確認Lambda@Edge＋認可APICloudFrontだけではDBの現在値が分からない
管理画面で購入済み講座一覧を表示Next.js・APIこれは通常の動的ページ生成

署名付きCookieは認可処理を軽くできるが、動画のCloudFront転送料そのものを無料にはしない。

04Lambda@Edgeが効く具体例 — 機密ファイル

S3から直接・高速に配信しながら、アプリと同じ細かな権限判定を入口へ持ち込む。

Lambda@Edgeから認可APIとDBを使う機密ファイル配信フロー
Cookieとファイルパスだけでは結論が出ないため、Lambda@Edgeが認可APIへ問い合わせる。
GET /private/company-a/project-x/estimate.pdf
Cookie: session=...

Lambda@Edge → POST /authorize
{
  "path": "/private/company-a/project-x/estimate.pdf",
  "session": "..."
}

200 → S3へ進む
403 → その場で拒否
Lambda@Edgeは会員サイト本体ではなく、S3直配信をアプリ並みの動的認可で守る門番。

05キャッシュの前か後かで実行回数が変わる

アクセス制御では、Viewer RequestとOrigin Requestの違いが安全性に直結する。

CloudFrontのViewer RequestとOrigin Requestの実行タイミング
Origin Requestだけの認可は、キャッシュヒット時に関数が走らない。キャッシュ設定を含めて設計する。
イベント実行タイミング向く処理
Viewer Requestキャッシュ確認前・対象リクエストごと毎回必要な認証、URL・キャッシュキー変更
Origin Requestキャッシュミスでオリジンへ送るときだけ接続先変更、オリジン負荷を抑えたい加工

教材の実例はOrigin RequestにLambda@Edgeを置く。非公開コンテンツの認可として使うなら、キャッシュ無効化など『すべての必要な要求が必ず認可を通る』条件の確認が必要。

06教材を現在のAWS仕様で補正する

概念は有効だが、制限値はAWS公式の最新版を参照する。

項目CloudFront FunctionsLambda@Edge
ネットワークアクセス不可可能
実行時間サブミリ秒最大30秒
メモリ2MBViewer系128MB／Origin系最大10GB
コード＋ライブラリ最大10KB最大50MB
通常の環境変数利用不可利用不可
イベントViewer Request／ResponseViewer＋OriginのRequest／Response

2026-08-15取得。教材の『Lambda@Edgeは環境変数を利用可能』『コード最大1MB』は現在のAWS公式仕様と一致しない。

結論

  1. 通常のDB連動ページはNext.js・APIに任せる。
  2. URL・Cookie・JWTだけで完結する入口処理はCloudFront Functions、複数ファイル配信は署名付きCookieを優先する。
  3. 外部の認可APIへ問い合わせる判断をCloudFront入口で行う明確な理由があるときだけLambda@Edgeを使う。