Networking and Content Delivery

Amazon CloudFront

生成AIアプリのフロントエンド配信とプライベート生成物の配布を担うCDN。AIP-C01ではCDN一般論ではなく、S3オリジンへの署名付きアクセス・地理的制限・エッジでのカスタマイズがGenAIアプリ統合の文脈でどう出るかが対象です。

  • B|実装まわり
  • D2 実装と統合
  • D4 運用効率と最適化

ひとことで言うと

エッジロケーション経由でコンテンツを配信するCDNです。生成AIアプリの文脈では、チャットUIなどの静的アセット配信と、Titan Image GeneratorやBedrock Data Automationが生成した出力をS3に直接触れさせずに配布する用途で出ます。

要するに、S3の前に立つ受付です。生成AIアプリがユーザーごとに画像や文書を生成してS3に保存するとき、S3バケットを直接公開するのは事故のもとです。CloudFrontを前に置き、署名付きURLで「この人はこのファイルを、この時刻までだけ見られる」という受付を挟む。
だから試験の分岐は「配信するコンテンツが誰にでも見せていいものか、ユーザーごとに制限すべきものか」です。前者は静的アセット配信の高速化、後者は署名付きURL/Cookieの出番になります。

何に使うか

用途使い方関連ドメイン
GenAIアプリのフロントエンド配信Amplifyでホストするチャットアプリの静的アセット(HTML/JS/CSS)をエッジから高速配信D2 2.5
生成物のプライベート配布Titan Image GeneratorやBedrock Data Automationの出力をS3に置き、署名付きURL/Cookieで期限付き・IP制限付きに配信D2 2.3 / D4 4.2
データレジデンシー・利用地域制限特定国からのみ生成AIアプリへのアクセスを許可・禁止する地理的制限D2 2.3

試験でどう問われるか

問われ方正解に寄る条件引っかけ
「ユーザーが生成した画像を、本人だけが一定時間だけ見られるようにしたい」個別ファイルへの期限付きアクセス → 署名付きURL(カスタムポリシーならIPアドレス制限や開始時刻も指定可)S3バケットポリシーだけで制御する案(バケットを公開せずCloudFront経由に限定するにはOrigin Access Control(OAC)との組み合わせが必要)
「複数のページ全体に同じアクセス制御をまとめてかけたい」個別ファイルではなくセッション単位のアクセス制御 → 署名付きCookieファイルごとに署名付きURLを発行し続ける案(動くが、ページ内の多数のリソースに対して非効率)
「特定の国からのみ生成AIアプリを提供したい(規制上の理由)」国単位の制限で足りる → CloudFront地理的制限(許可リスト/拒否リスト)サードパーティの位置情報サービスを使う案(国より細かい粒度が必要な場合の選択肢であり、国単位ならCloudFront標準機能で十分)
「S3オリジンへの直接アクセスを防ぎつつCloudFront経由だけを許可したい」Origin Access Control(OAC) をS3オリジンに設定するS3バケットを完全パブリックにしてCloudFrontのキャッシュ効率だけで対応する案

地理的制限の精度は100%ではありません。CloudFrontはサードパーティのデータベースでIPアドレスと国を対応付けており、公式ドキュメントでは直近のテストで全体精度99.8%と案内されています。「規制上、特定国からのアクセスを完全に0件にする」という厳密な要件には、地理的制限だけで応えると仕様上の限界に触れます。

実務でどう使うか

  • AWSオリジン(S3・ALB・API Gateway)からCloudFrontへのデータ転送は無料。 課金されるのはCloudFrontからビューアーへの転送とHTTP/HTTPSリクエストです。生成物の配信コストを試算するときはこの向きを間違えないようにします
  • 署名付きURLは、ダウンロード中に有効期限が切れても進行中の通信は継続します。 ただしTCP接続が切れて再開しようとした時点で期限切れなら失敗します。大きな生成ファイル(動画等)の配信では、有効期限を余裕を持って設定する必要があります
  • 地理的制限はディストリビューション全体に効きます。 一部のコンテンツだけ制限したい場合は、ディストリビューションを分けるか、サードパーティの位置情報サービスと組み合わせる必要があります

証明書検証パス(/.well-known/pki-validation/)は地理的制限の対象外です。CloudFront管理証明書を使う場合、この既定挙動を知らずにWAFのbotルール等で当該パスまで塞ぐと、証明書の検証・更新自体が失敗します。「制限を厳しくしたら証明書が更新できなくなった」はここが原因のことがあります。

取り違えやすいもの

迷う相手切り分けの一言
API GatewayCloudFrontは配信の高速化とアクセス制御が主眼。ストリーミングAPI・WebSocket・SSEといった生成AIの応答をリアルタイムで返す仕組みそのものはAPI Gatewayの領域で、CloudFrontはその前段に置く配信層
Amazon S3 Origin Access Control(OAC)CloudFrontの機能ではなく、S3オリジン側で「CloudFront以外からのアクセスを拒否する」ための設定。署名付きURLと組み合わせて初めて「S3に直接アクセスさせない」が完成する
AWS WAFCloudFrontは配信経路の最適化とキャッシュ。WAFは不正なリクエスト(SQLインジェクション等)をブロックするセキュリティレイヤーで、目的が異なる。地理的制限のWAFルールがPKI検証パスをブロックしないよう注意する記述が公式にある

想起チェック

Q1. ユーザーごとに生成物への個別アクセス制限をかけたいとき、署名付きURLと署名付きCookieはどう使い分けますか?

単一・少数のファイルへのアクセス制限には署名付きURL、複数ページ・複数リソースにまたがるセッション単位のアクセス制御には署名付きCookieが向きます。

Q2. S3を生成AIアプリの出力先にしつつ、直接アクセスさせずCloudFront経由に限定するには何が必要ですか?

S3オリジンにOrigin Access Control(OAC)を設定してS3への直接アクセスを塞ぎ、CloudFront側で署名付きURLまたは署名付きCookieによるアクセス制御を組み合わせます。

出典(AWS公式)