何を学ぶか
実務では 何がこの仕組みの入口になるか？ を先に確認する。設定値だけでなく、入力と出力の境界を明確にする。
CloudFrontを安全に運用する設計
キャッシュ・オリジン・エッジ処理・閲覧制御を、リクエストの進行方向に沿って判断する。
TL;DR — この章で学ぶこと
- キャッシュキーとTTLを設計する
- FunctionsとLambda@Edgeを使い分ける
- 署名付きCookieで配信単位を守る
01キャッシュキーとTTLを設計する
何がこの仕組みの入口になるか？ — キャッシュキーとTTLを設計するを、構成図の矢印から読み解く。
02FunctionsとLambda@Edgeを使い分ける
どのサービスが責任を持つか？ — FunctionsとLambda@Edgeを使い分けるを、構成図の矢印から読み解く。
何を学ぶか
実務では どのサービスが責任を持つか？ を先に確認する。設定値だけでなく、入力と出力の境界を明確にする。
03署名付きCookieで配信単位を守る
失敗時にはどこへ戻る／進むか？ — 署名付きCookieで配信単位を守るを、構成図の矢印から読み解く。
何を学ぶか
実務では 失敗時にはどこへ戻る／進むか？ を先に確認する。設定値だけでなく、入力と出力の境界を明確にする。
結論
- 閲覧者リクエストはCloudFrontへ入り、キャッシュmiss時だけオリジンへ進む。キャッシュキーに不要なCookieやHeaderを含めない。
- CloudFront Functionsは軽いviewer request処理、Lambda@Edgeはより重いエッジ処理向け。どちらもオリジンへ行く前の処理を意識する。
- 単一ファイルには署名付きURL、複数ファイル・サイト単位には署名付きCookieを使う。WAFはCloudFrontの前段でリクエストを遮断する。