#
ドキュメント

Document

自分のための備忘録です。

CloudFront

https://d1.awsstatic.com/webinars/jp/pdf/services/20190730_AWS-BlackBelt_Amazon_CloudFront.pdf

Contents Delivery Networkのマネージドサービス。
AWSのEdgeロケーションから提供されるサービスの1つ。

構成

ディストリビューション、オリジン、ビヘイビア

  • ディストリビューションには1つ以上のオリジンを持つ
  • ビヘイビアを使ってパスパターンごとにオリジンを指定できる

目標

  • CloudFrontをカスタムURLで運用する
  • ビヘイビアを理解する
  • キャッシュキーとオリジンリクエストを理解する
    • Controlling the cache key
    • Controlling origin requests
  • キャッシュを確認する

CloudFrontをカスタムURLで運用する

example.comにCloudFrontを導入します。

具体的にはexample.comのAレコードにCloudFrontのディストリビューションドメイン名を指定して、カスタムURLで運用します。 (ディストリビューション名ではなくドメイン名での運用をカスタムURLによる運用と呼びます。)

ref. 代替ドメイン名 (CNAME) を追加することによるカスタム URL の使用

ディストリビューションに代替ドメイン名(example.com)を設定しない場合は、example.comのAレコードにディストリビューションを指定できません。
つまりカスタムURLでの運用するには代替ドメイン(example.com)の設定が必須です。

カスタムURLで運用する手順

  1. ディストリビューションを作成
  2. 代替ドメインexample.com用のACM(カスタム SSL 証明書)を取得
    • 代替ドメインを設定するにはACMが必須(セキュリティ面からドメイン認証によってACMを取得できることをもってドメイン所有者であることを担保)
    • 代替ドメインのACMはus-east-1で取得(us-east-1以外で取得したACMは代替ドメインで使用できないことに注意)
  3. ディストリビューションに代替ドメインをexample.comを設定
  4. Route 53でexample.comのAレコードにディストリビューションドメイン名を設定

ビヘイビアを理解する

キャッシュキーとオリジンリクエストの詳細については次節で説明します。 本章ではビヘイビアで特に注意する点について記載します。

POSTリクエスト

  • CloudFrontはデフォルトではGETとHEADメソッドのみを許可する
  • その他のメソッドを許可するにはビヘイビアで許可する必要がある
CloudFront

クエリ文字列

For distributions, you can choose if you want CloudFront to forward query strings to your origin and whether to cache your content based on all parameters or on selected parameters. Why might this be useful? Consider the following example.

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/QueryStringParameters.html#query-string-parameters-console

  • CloudFrontのデフォルトは、クエリ文字列をオリジンに送りません
  • つまりhttps://example.com/test?foo=barfoo=barはオリジンには送信されません

ビヘイビアの設定を変更することでオリジンにクエリ文字列を送信できます。

※ 下図ではLegacy cache settingsを指定していますが、今後はCache policy and origin request policy (recommended)を使用することが推奨されます。

cache

キャッシュキーとオリジンリクエスト

キャッシュキーとオリジンリクエストはマネージドサービスなCache policy/Origin request policyを使用する方法とLegacy cache settingsを使用する方法がある。
現在は、Cache policy and origin request policyが推奨。

  • Cache policy and origin request policy (recommended)
    • Cache policy(キャッシュポリシー)
    • origin request policy(オリジンリクエストポリシー)
  • Legacy cache settings
    • ヘッダー
    • クエリ文字列
    • cookie
    • オブジェクトキャッシュ

Cache policy and origin request policy (recommended)を使用するメリットは、Cache policyとOrigin request policyを再利用性(使い回す)にある。
Legacy cache settingsは、ビヘイビアごとにヘッダー、クエリ文字列、cookieを設定する必要がある。

Cache policy and origin request policyとLegacy cache settingsの違い

$ aws cloudfront get-distribution-config --id {{ディストーションID}} --profile playground-admin

Legacy cache settings

CloudFront
"ForwardedValues": {
    "QueryString": true,   <--- (2)
    "Cookies": {
        "Forward": "none"  <--- (3)
    },
    "Headers": {
        "Quantity": 0      <--- (1)
    },
    "QueryStringCacheKeys": { <--- 廃止
        "Quantity": 0
    }
},
"MinTTL": 0,              <--- Use origin cache headers (4)
"DefaultTTL": 86400,      <--- Use origin cache headers (4)
"MaxTTL": 31536000        <--- Use origin cache headers (4)

Cache policy and origin request policy

Legacy cache settingsの各値が以下のCachePolicyIdに対応する。

CloudFront
"CachePolicyId": "xxxxx-xxxx-xxxxx"           <--- (1)
"OriginRequestPolicyId": "xxxxx-xxxx-xxxxx"
  • Cache policy:CachePolicyId
  • Origin Request Policy:OriginRequestPolicyId

Legacy cache settingsに対応するのはCache policy。マネージド方法はLegacy cache settingsでは設定できなかった内容についてorigin request policyで設定できるようになっった。

Cache policyの例
CloudFront
origin request policyの例
CloudFront
Cache policyとOrigin Request Policyの違い

オリジンリクエスト設定は、CloudFrontがオリジンリクエストに含めるビューアリクエストの値を指定します。これらの値には、HTTPヘッダー、URLクエリ文字列、およびクッキーが含まれることがあります。

オリジンリクエストの設定により、URLクエリ文字列、HTTPヘッダー、クッキーなど、視聴者リクエストから一部の情報をオリジンで受信することができます。例えば、分析または遠隔測定のためのデータを収集するために、この設定を行うことができます。

オリジンリクエストに含める値は、キャッシュキーには含まれません。キャッシュ・キーに値を含めるには、キャッシュ・ポリシーを使用します。キャッシュポリシーの値は自動的にオリジンリクエストに含まれるため、オリジンリクエストポリシーでそれらの値を再度指定する必要はありません。

Cache policyを取得。

$ aws cloudfront get-cache-policy --id {{Cache policy id}}

Origin Request Policyを取得。

$ aws cloudfront get-origin-request-policy --id {{Origin Request Policy id}}
Ref.
  • Controlling the cache key
  • Controlling origin requests
  • https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/controlling-origin-requests.html?icmpid=docs_cf_help_panel#origin-request-understand-origin-request-policy-settings
  • https://michimani.net/post/aws-about-cache-spec-of-cloudfront/

Controlling the cache key

cache key

With Amazon CloudFront, you can control the cache key for objects that are cached at CloudFront edge locations. The cache key is the unique identifier for every object in the cache, and it determines whether a viewer request results in a cache hit. A cache hit occurs when a viewer request generates the same cache key as a prior request, and the object for that cache key is in the edge location’s cache and valid. When there’s a cache hit, the object is served to the viewer from a CloudFront edge location

Amazon CloudFrontでは、CloudFrontのエッジロケーションにキャッシュされるオブジェクトのキャッシュキーを制御することができます。キャッシュキーは、キャッシュ内のすべてのオブジェクトの一意な識別子であり、ビューアリクエストがキャッシュヒットにつながるかどうかを決定するものです。キャッシュヒットは、ビューワーリクエストが前のリクエストと同じキャッシュキーを生成し、そのキャッシュキーのオブジェクトがエッジロケーションのキャッシュ内にあり、有効である場合に発生します。キャッシュヒットした場合、CloudFrontのエッジロケーションからオブジェクトがビューアーに提供される。 -- DeepLで翻訳

ref. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/controlling-the-cache-key.html

TTL

ref. https://dev.classmethod.jp/articles/introduction-to-max-ttl-on-cloudfront/

Controlling origin requests

ref. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/controlling-origin-requests.html

CloudFrontはキャッシュが存在しない場合、オリジンにリクエストを送りオブジェクト(レスポンス)を取得する。 オリジンにリクエストする際に以下の情報を渡す

  • The URL path (the path only, without URL query strings or the domain name)

  • The request body (if there is one)

  • The HTTP headers that CloudFront automatically includes in every origin request, including Host, User-Agent, and X-Amz-Cf-Id.

デフォルトではクエリ文字列、ヘッダー、cookiesはオリジンに送らない。

オリジンリクエストで上記情報を付与するためにorgin request policyを使用する。

  • orgin request policiesはcache policiesから分離されている
  • cache policyはcatch keyをコントロールする

上記によってcache hit ratioを高く維持することができる。

Although the two kinds of policies are separate, they are related. All URL query strings, HTTP headers, and cookies that you include in the cache key (using a cache policy) are automatically included in origin requests.

cache policyでキャッシュキーにクエリ文字列やヘッダーおよびcookiesを含むように設定した場合、自動的にorigin requests policyにも含まれる。

origin request policyの定義

Use the origin request policy to specify the information that you want to include in origin requests, but not include in the cache key.

-- https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/controlling-origin-requests.html?icmpid=docs_cf_help_panel

クエリ文字列、ヘッダー、cookiesをoriginに対するリクエストに含めたいが、キャッシュキーに含めたくない場合は、orgin request policyを使用します。

キャッシュを確認する

HTTPレスポンスヘッダーのviaにCloudFrontが設定されていれば良い。

Lisket(リスケット)__リスティング広告のレポート自動作成とリアルタイム予算管理が月額1万円から!

技術的詳細

引用元: https://d1.awsstatic.com/webinars/jp/pdf/services/20190730_AWS-BlackBelt_Amazon_CloudFront.pdf

p.23

HTTP/1.0, HTTP/1.1, HTTP/2, WebSocket 対応 • HTTP/2 使用時はクライアントが TLS 1.2 以降と SNI (Server Name Identification) サポート必要

デフォルトでは「xxxx.cloudfront.net」が ディストリビューション のドメイン名とし て割り当てられる • CNAME エリアスを利用して代替 (独自) ドメイン名の指定が可能 • 有効な SSL/TLS 証明書の対象であることが必要 • CNAME エリアスのワイルドカード指定もサポート (例: *.example.com など) • Route53 と組み合わせた Zone Apex (例: example.com など)が利用可能

p.24

HTTP / HTTPS 対応 • GET, HEAD, OPTION(選択可能) (Cacheモード) • PUT, POST, DELETE, OPTION, PATCH (Proxyモード)

どうもCacheぜずに単にオリジンにフォワードすることをProxyモード読んでいる。 (たしかにオリジンのProxyといえばそういえる)

p.26

フォワードオプション機能による動的ページ配信 • Header / Cookie / Query Strings

p.33

クエリ文字列パラメータの値をオリジンへ転送 • オリジンに任意のクエリ文字列を転送することで動的なページ生成にも対応 • CloudFront は指定されたクエリ文字列パラメータと値をセットでキャッシュ • 全てのクエリ文字列をフォワードするとキャッシュ効率が大幅に低下するため 必要最小限のクエリ文字列を指定することを推奨

p.39

データ保護関連

p.40

SSL関連

p.56

CloudFront Reports & Analytics

運用例

CloudFrontのカスタムドメイン名:example.com レンタルサーバ:rental-example.com

rental-example.comでHTTPをHTTPSにリダイレクトしている場合には、オリジンのプロトコルでHTTPSのみを設定しないとhttps://rental-example.comにリダイレクトされてしまう。

CloudFront

Ref.