ドキュメント

Document

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

CloudFront

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

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

構成

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

ディストリビューションはドメイン毎に存在
ディストリビューションは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で運用する手順

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

ビヘイビアを理解する

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

POSTリクエスト

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

クエリ文字列

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=bar の foo=bar はオリジンには送信されません

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

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

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

キャッシュキーとオリジンリクエストはマネージドサービスな 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

"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 に対応する。

"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の例

origin request policyの例

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

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（リスケット）__リスティング広告のレポート自動作成とリアルタイム予算管理が月額１万円から！

技術的詳細

引用元： 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にリダイレクトされてしまう。

Ref.

代替ドメイン名 (CNAME) を追加することによるカスタム URL の使用 https://aws.amazon.com/jp/premiumsupport/knowledge-center/migrate-ssl-cert-us-east/