エッジコンピューティングの設計 Lambda@Edge・CloudFront Functions・Origin Shieldを使い分ける

SAP-C02では、グローバルに配信するアプリケーションで「処理をどこまでエッジに寄せるか」が問われます。CloudFrontに付随する2種類のエッジ関数とOrigin Shieldは似た文脈で登場するため、実行場所・実行時間・できることの違いから選べるようにします。

覚え方は「軽さ・重さ・盾」の3つ

軽さ＝ヘッダー書き換えやリダイレクトなど1ミリ秒未満の処理はCloudFront Functions、重さ＝外部呼び出しやボディの生成を伴う処理はLambda@Edge、盾＝オリジンへのリクエストを減らして保護するのはOrigin Shield、と覚えます。

CloudFront Functions：超軽量・超大量

CloudFront Functionsは218以上のエッジロケーションで動くJavaScriptの軽量関数で、実行時間はサブミリ秒、ビューワーリクエストとビューワーレスポンスの2つのイベントでのみ動作します。「URLの正規化」「ABテストのためのクッキー判定」「セキュリティヘッダーの付与」「単純なリダイレクト」のような、ネットワークアクセスを伴わない処理に最適で、Lambda@Edgeより大幅に低コストです。KeyValueStoreを使えば小さな設定データの参照もできます。

Lambda@Edge：エッジで本格的な処理

Lambda@Edgeはリージョナルエッジキャッシュで動くLambda関数(Node.jsまたはPython)で、ビューワー側とオリジン側の4つのイベントすべてで動作します。最大数秒の実行時間、外部のAPIやDynamoDBへのアクセス、レスポンスボディの生成が可能です。「ユーザーの位置やデバイスに応じてオリジンを切り替える」「認証トークンを検証してから配信する」「画像をリクエスト時にリサイズする」という要件はLambda@Edgeです。関数はバージニア北部リージョンで作成し、CloudFrontが各エッジへ複製する点、環境変数が使えない点が試験で問われます。

Origin Shield：オリジンを守るもう1段のキャッシュ

Origin Shieldは、リージョナルエッジキャッシュのさらに手前に1つの集約キャッシュ層を置く機能です。世界中のエッジからのキャッシュミスがOrigin Shieldで集約されるため、「ライブ配信や大規模キャンペーンでオリジンへの同一リクエストが集中する」「オリジンの負荷とデータ転送コストを下げたい」という要件に効きます。オリジンに最も近いリージョンを選ぶのが基本で、マルチCDN構成やオンデマンド画像変換のようにオリジン処理が高価な場合に特に有効です。

チェックリスト

• ARRAY(0xa00042578)

まとめ

エッジ処理は「軽さ・重さ・盾」の3つで整理し、ネットワークアクセスの要否とオリジン保護の必要性から選びましょう。 理解度の確認にはクイズが便利です。試験範囲や申し込みの最新情報はAWS認定 公式ページもあわせて確認してください。