高度なルーティング

メディア CDN は、トラフィックを特定のエッジ構成と送信元にきめ細かいレベルでマッピングできる高度な HTTP ルーティング機能を提供します。

一致したリクエスト数

Media CDN 構成には一連のルートが含まれます。このルートは、少なくともホストとパスに基づいてリクエストと一致し、トラフィックを送信元に転送します。各ルートでは、独自の CDN 構成、書き換え、リダイレクト、CORS ポリシー、カスタム HTTP ヘッダー、送信元のマッピングを定義できます。ルートでは送信元を共有できます。

たとえば、マニフェストに対するリクエストを特定の送信元にルーティングし、有効期間が短いキャッシュ TTL とネガティブキャッシュポリシーを定義できます。セグメントのリクエストは、ヘッダーとクエリパラメータを使用して特定のマニフェストタイプやユーザーを分割することで、別の送信元に分割できます。

次の例は、特定のヘッダー、クエリパラメータ、パス接頭辞と一致するリクエストをルーティングする方法を示しています。

pathMatchers:
- name: routes
  routeRules:
  - priority: 10
    origin: staging-live-origin
    matchRules:
    - prefixMatch: /vod/
      headerMatches:
      - headerName: "x-staging-client"
        presentMatch: true
      queryParameterMatches:
      - name: "live"
        exactMatch: "yes"
    routeAction:
      cdnPolicy:
        defaultTtl: 5s

パスマッチング

Media CDN は、完全（完全一致）、接頭辞、ワイルドカードパスのマッチングをサポートしています。パスマッチングをホスト、ヘッダー、クエリパラメータベースのマッチングと組み合わせることで、きめ細かいリクエストのルーティングルールを構築できます。

URL パスの照合には、次の 3 つの方法があります。

フィールド説明例

フィールド	説明	例
`matchRules[].fullPathMatch`	`fullPathMatch` 条件は、クエリ文字列を含まない完全な URL パスと一致します。必要に応じて、末尾にスラッシュを指定する必要があります。	`fullPathMatch: "/stream/"` の一致ルールを持つルートは `/stream/` と一致しますが、`/stream`、`/stream/us/hls/1234.ts` とは一致しません。 `fullPathMatch` は明示的な一致です。
`matchRules[].prefixMatch`	`prefixMatch` 条件は URL パス接頭辞と一致します。同じ文字列で始まる URL が一致します。	`prefixMatch: "/videos/"` の一致ルールを持つルートは、両方に `/videos/` 接頭辞が含まれているため、`/videos/hls/58481314/manifest.m3u8` と `/videos/dash` の両方と一致します。
`matchRules[].pathTemplateMatch`	`pathTemplateMatch` 条件ではワイルドカード演算子がサポートされているため、複雑な URL パターンとパスセグメントを照合したり、URL を書き換えるための名前付き変数をキャプチャしたりできます。	一致ルールが `pathTemplateMatch: "/**.m3u8"` のルートは、末尾が `.m3u8` の URL パスと一致します。 `/content/en-GB/13/51491/manifest_193193.m3u8` と `/p/abc/1234/manifest_1080p5000.m3u8` の両方がこのパターンと一致します。その他の例については、パターンマッチングをご覧ください。

matchRules[].fullPathMatch

fullPathMatch 条件は、クエリ文字列を含まない完全な URL パスと一致します。必要に応じて、末尾にスラッシュを指定する必要があります。

fullPathMatch: "/stream/" の一致ルールを持つルートは /stream/ と一致しますが、/stream、/stream/us/hls/1234.ts とは一致しません。

fullPathMatch は明示的な一致です。

matchRules[].prefixMatch

prefixMatch 条件は URL パス接頭辞と一致します。同じ文字列で始まる URL が一致します。

prefixMatch: "/videos/" の一致ルールを持つルートは、両方に /videos/ 接頭辞が含まれているため、/videos/hls/58481314/manifest.m3u8 と /videos/dash の両方と一致します。

matchRules[].pathTemplateMatch

pathTemplateMatch 条件ではワイルドカード演算子がサポートされているため、複雑な URL パターンとパスセグメントを照合したり、URL を書き換えるための名前付き変数をキャプチャしたりできます。

一致ルールが pathTemplateMatch: "/**.m3u8" のルートは、末尾が .m3u8 の URL パスと一致します。

/content/en-GB/13/51491/manifest_193193.m3u8 と /p/abc/1234/manifest_1080p5000.m3u8 の両方がこのパターンと一致します。

その他の例については、パターンマッチングをご覧ください。

たとえば、/stream/ で始まるすべてのリクエストを照合するには、次のようなルートルールを作成します。

name: prod-service
routing:
  hostRules:
  - hosts:
    - media.example.com
    - *.vod.example.com
    pathMatcher: routes
  pathMatchers:
  - name: routes
    routeRules:
    - priority: 1
      matchRules:
      - prefixMatch: /stream/

次の例では、一致ルールの末尾にスラッシュを明示的に含めています。

media.example.com/stream/id/1234/hls/manifest.m3u8 へのリクエストはこのルートと一致します。
media.example.com/stream-eu/id/4567/hls/manifest.m3u8 へのリクエストはこのルートと一致しません。

2 番目のケースでは、別のルートまたはキャッチオールルートが構成されていない限り、Media CDN は HTTP 404 エラーを返します。

類似の接頭辞を持つルートの優先順位の詳細については、ルートの優先度と順序をご覧ください。

パターン（ワイルドカード）マッチング

パターンマッチングを使用すると、単純なワイルドカード構文を使用して、URL の一部（URL の一部と接尾辞を含む）を照合できます。

pathTemplateMatch フィールドの 1 つ以上のパスコンポーネントを名前付き変数に関連付けてから、pathTemplateRewrite フィールドの URL を書き換えるときに、その変数を参照できます。これにより、リクエストが送信元に送信される前に、URL コンポーネントの順序変更や削除を行うことができます。

次の例は、2 つの異なる URL サフィックスを照合する方法を示しています。

# EdgeCacheService.routing.pathMatchers[]
    routeRules:
    - priority: 1
      description: "Match video segments"
      matchRules:
      - pathTemplateMatch: "/**.ts"
      - pathTemplateMatch: "/**.m4s"
      origin: prod-video-storage

サポートされている構文は次のとおりです。

オペレーター	一致する	例
`*`	1 つのパスコンポーネント（次のパス区切り文字まで）に一致します。`/`	`/videos///*.m4s` matches `/videos/123414/hls/1080p5000_00001.m4s`.
`**`	0 個以上のパスセグメントに一致します。存在する場合は、最後の演算子にする必要があります。	`/**.mpd` matches `/content/123/india/dash/55/manifest.mpd`.
`{name} or {name=*}`	1 つのパスセグメントに一致する名前付き変数。 1 つのパスコンポーネント（次のパス区切り文字 `/` まで）と一致します。	`/content/{format}/{lang}/{id}/{file}.vtt` は `/content/hls/en-us/12345/en_193913.vtt` と一致し、`format="hls"`、`lang="en-us"`、`id="12345"`、`file="en_193913"` を変数としてキャプチャします。
`{name=videos/*}`	複数のパスセグメントに一致する名前付き変数。`videos/*` に一致するパスコンポーネントは、名前付き変数としてキャプチャされます。	`/videos/{language=lang/}/` は `/videos/lang/en/video.m4s` と一致し、パス変数 `language` に値 `lang/en` を設定します。
`{name=**}`	0 個以上のパスセグメントに一致する名前付き変数。存在する場合は、最後の演算子にする必要があります。	`/.m3u8` または `/{path=}.m3u8` は、拡張子までのすべてのパスセグメントに一致します。 `/videos/{file=**}` は、拡張機能を含む `/videos/en-GB/def566/manifest.m3u8` と一致し、パス変数 `file="en-GB/def566/manifest.m3u8` を取得します。

注:

URL を書き換えない場合は、より単純な * 演算子と ** 演算子を使用します。
変数を使用してパスコンポーネントをキャプチャする場合、URL の変数でキャプチャされない部分は後続の pathTemplateRewrite で参照できません。例については、パス変数のキャプチャをご覧ください。
同じルートの pathTemplateMatch に存在しない後続の pathTemplateRewrite の変数を参照できません。
変数は大文字と小文字が区別されます。{FORMAT}、{forMAT}、{format} はそれぞれ異なる変数と値を表します。
1 つの一致で最大 5 つの演算子（ワイルドカードまたは変数）を指定できます。pathTemplateMatch フィールドと pathTemplateRewrite フィールドは 256 文字以下にする必要があります。

例: ファイル拡張子を照合する

次の例は、ワイルドカード演算子の一般的なユースケースを示しています。ユースケースは、すべてのパスコンポーネントをサフィックスまで照合します。

この場合、次の操作を行います。

マニフェストの送信元から .m3u8 と .mpd で終わる動画マニフェスト（再生リスト）を取得します。これらのレスポンスは定期的に変更されるので、レスポンスに短い（5 秒間）TTL を適用します。
セグメントの送信元から .ts と .m4s で終わる動画セグメントを取得し、これらのレスポンスにさらに長い（1 日の）TTL を適用します。

このアプローチは、SSAI（サーバー側広告インジェクション）または DAI（ダイナミック広告挿入）サービスを使用する場合や、マニフェストが数秒ごとに更新されるライブ動画の場合によく使用されます。

次の構成は、これをサポートするようにメディア CDN ルーティングを構成する方法を示しています。

name: prod-service
routing:
  hostRules:
  - hosts:
    - media.example.com
    pathMatcher: routes
  pathMatchers:
  - name: routes
    routeRules:
    # the first route only matches video manifests
    - priority: 1
      matchRules:
      - pathTemplateMatch: "/**.m3u8" # "**" matches all path segments
      - pathTemplateMatch: "/**.mpd"
      origin: manifest-origin
      routeAction:
        cdnPolicy:
          cacheMode: FORCE_CACHE_ALL
          defaultTtl: 5s
    # the second route matches video segments, fetches them
    # from a separate origin server, caching them for a longer
    # duration (1 day).
    - priority: 2
      matchRules:
      - pathTemplateMatch: "/**.ts"
      - pathTemplateMatch: "/**.m4s"
      origin: segment-origin
      routeAction:
        cdnPolicy:
          cacheMode: FORCE_CACHE_ALL
          defaultTtl: 86400s

例: パス変数をキャプチャする

次の例は、名前付き変数を使用して 1 つ以上のパスコンポーネントを記述する方法を示しています。

これらの変数は、送信元に送信される前にパスを書き換えたり、複雑な pathTemplateMatch の自己記述を作成したりするために pathTemplateRewrite で使用できます。

routing:
  hostRules:
  - hosts:
    - media.example.com
    pathMatcher: routes
  pathMatchers:
  - name: routes
    routeRules:
    - priority: 1
      matchRules:
      # Matches a request of "/us/en/hls/123139139/segments/00001.ts"
      - pathTemplateMatch: "/{country}/{lang}/{format}/{id}/{file=**}"
      origin: my-origin
      routeAction:
        urlRewrite:
          # Rewrites to "/123139139/hls/segments/00001.ts"
          pathTemplateRewrite: "/{id}/{format}/{file}"

特に、以下の点に注意してください。

各 {name} 変数は、1 つのパスセグメントを取得します。パスセグメントは、URL パス内の / （「スラッシュ」）のペア間のすべての文字です。
{name=**} 変数は、残りのパスセグメントをすべてキャプチャします。この場合、segments/00001.ts と master.m3u8 の両方に一致します。
同じルートの pathTemplateRewrite で、pathTemplateMatch でキャプチャした変数の一部を参照します。{country} 変数と {lang} 変数は、元のディレクトリ構造と一致しないため、明示的に省略します。

この例では、次のようになります。

受信リクエスト URL /us/en/hls/123139139/segment_00001.ts は pathTemplateMatch と一致し、送信元に送信される前に /123139139/hls/segment_00001.ts に書き換えられます。
受信リクエスト URL /us/123139139/master.m3u8 は pathTemplateMatch と一致せず、HTTP 404 (Not Found) レスポンスを受信します。
受信リクエスト URL /br/es/dash/c966cbbe6ae3/subtitle_00001.vtt は pathTemplateMatch とも一致し、送信元に送信される前に /c966cbbe6ae3/dash/subtitle_00001.vtt に書き換えられます。

ワイルドカードマッチングと URL 書き換えの連携については、書き換えセクションをご覧ください。

ホストマッチング

各サービスは複数のホスト名で照合できます。各ホスト名には、独自のルートグループ（パスマッチャー）が含まれています。最も一般的なケースでは、サービスのすべてのホスト名が、単一ホストのリストと単一のパスマッチャーを持つ単一の共有ルートのセットにマッピングされます。

name: prod-service
routing:
  hostRules:
  - hosts:
    - media.example.com
    - *.vod.example.com
    pathMatcher: routes
  pathMatchers:
  - name: routes
    routeRules:
    # list of routes for the configured hosts
    - priority: 999
      matchRules:
      - prefixMatch: /
      origin: DEFAULT_ORIGIN

一致しないホストには、デフォルトの HTTP 404 ページが表示されます。任意のホストを受け入れるには、ワイルドカード文字 * を hostRules[].hosts[] エントリとして含めます。

ルートグループを定義することもできます（国やライブグループによるオンデマンドなど）。各サービスには 1 つのセキュリティポリシーがあるため、通常は、市場（地域）またはワークロードごとに 1 つのサービスを使用することをおすすめします。

注:

ポートを含むホスト（または HTTP/2 :authority）ヘッダーは、構成されたホストと暗黙的に照合されます。ポートを明示的に指定する必要はありません。
リクエストが HTTP 経由の場合、*.vod.example.com の hostRules[].hosts[] エントリは us.vod.example.com と us.vod.example.com:80 に一致します。
リクエストが HTTPS（TLS）経由の場合、*.vod.example.com の hostRules[].hosts[] エントリは us.vod.example.com:443 と一致します。

ヘッダーとクエリパラメータで照合

特定のヘッダーやクエリパラメータ名、およびヘッダー値（プレフィックス、サフィックス、完全一致）の存在と一致するようにルートを構成できます。

クエリパラメータとヘッダーマッチングは論理「AND」です。リクエストがすべてのルートクエリと一致するには、すべてのクエリパラメータとヘッダーキー（および指定された場合は値）と一致する必要があります。

たとえば、特定のヘッダーフィールド名とヘッダー値を含むリクエストを alternate-origin という名前の送信元にルーティングする場合は、routeRules[].matchRules[].headerMatches[] 内で一致条件を構成します。

name: prod-service
routing:
  hostRules:
  - hosts:
    - media.example.com
    pathMatcher: routes
  pathMatchers:
  - name: routes
    routeRules:
    - priority: 1
      origin: alternate-origin
      matchRules:
      - prefixMatch: "/videos/"
        headerMatches:
        - headerName: "x-device-name"
          exactMatch: "roku"

この例では、URL の先頭が /videos/ で、x-device-name: roku ヘッダーがあるリクエストがこのルートと一致します。このヘッダー名が含まれていないリクエスト、または異なる値のリクエストは、このルートと一致しません。

同様に、クエリパラメータと照合するには、次のように 1 つ以上の queryParameterMatches を指定します。

name: prod-service
routing:
  hostRules:
  - hosts:
    - media.example.com
    pathMatcher: routes
  pathMatchers:
  - name: routes
    routeRules:
    - priority: 1
      origin: eu-live-origin-prod
      matchRules:
      - prefixMatch: "/videos/"
        queryParameterMatches:
        - name: "playback_type"
          exactMatch: "live"
        - name: "geo"
          exactMatch: "eu"

この例では、https://cdn.example.com/videos/1234/abcd/xyz.m3u8?playback_type=live&geo=eu のクライアントリクエストがこのルートと一致します。

キャッチオール（デフォルト）ルートを定義する

デフォルトでは、リクエストが構成されたルートと一致しない場合、Media CDN は HTTP 404 (Not Found) エラーを返します。

特定の pathMatcher（ルートのコレクション）に対してキャッチオールルートを構成するには、次の手順に従います。

優先度が最も低い（数値が最も大きい）routeRule を作成します（たとえば、999 は可能な限り低いルート優先度になります）。
matchRule を / という接頭辞の一致で構成します（すべてのリクエストパスに一致します）。
ルートの origin または urlRedirect のいずれかを構成します。

たとえば、一致しないすべてのリクエストをデフォルトの名前の送信元に転送するキャッチオールルートを構成するには、my-origin ）、新しいルートを作成します。priority: 999およびmatchRules[].prefixMatch//次のとおりです。

name: prod-service
routing:
  hostRules:
  - hosts:
    - cdn.example.com
    pathMatcher: routes
  pathMatchers:
  - name: routes
    routeRules:
    - priority: 999
      origin: my-origin
      matchRules:
      - prefixMatch: /

必要に応じて、送信元の取得前に URL を書き換えるか、リクエストを送信元に直接送信するのではなく、デフォルトのページ（ランディングページなど）にリダイレクトできます。

ルートの優先度と順序指定

routeRules[] の配列内の各ルートには、priority が関連付けられている必要があります。

より具体的なルートほど、優先度を高くします（小さい値にします）。優先度 1 の /stream/ という接頭辞と一致するルートの場合、優先度 5 のより具体的なルート /stream/live/eu/ のリクエストは一致しません。

優先度の最も高いルートは「1」で、最小のルートは「999」です。
同じ優先度のルートルールを複数構成することはできません。各ルールの優先度は、0～2147483647 の番号に設定する必要があります。
キャッチオールルートを定義すると、一致しないすべてのリクエストをデフォルトの送信元に送信するか、ランディングページやエンドポイントにリダイレクトできます。

次の例では、/live/ ルートの優先度が高いため、/live/us/ ルートが一致しません。

routeRules:
- priority: 1
  description: "Live routes"
  matchRules:
  - prefixMatch: /live/
  routeAction:
    cdnPolicy:
      defaultTtl: 5s
- priority: 2
  description: "U.S based live streams"
  matchRules:
  # This would never be matched, as the /live/ prefixMatch at priority 1
  # would always take precedence.
  - prefixMatch: /live/us/
  routeAction:
    cdnPolicy:
      defaultTtl: 5s
- priority: 999
  description: "Catch-all route"
  matchRules:
  - prefixMatch: /

これに対処するには、より具体的な（長い）ルートの優先順位を高くします。

routeRules:
- priority: 1
  description: "U.S based live streams"
  matchRules:
  # The more specific (longer) match is at a higher priority, and now
  # matches requests as expected.
  - prefixMatch: /live/us/
  routeAction:
    cdnPolicy:
      defaultTtl: 5s
- priority: 2
  description: "Live routes"
  matchRules:
  - prefixMatch: /live/
  routeAction:
    cdnPolicy:
      defaultTtl: 5s
- priority: 999
  description: "Catch-all route"
  matchRules:
  - prefixMatch: /

これにより、リクエストに一致するように、より具体的なルートを指定できます。接頭辞が /live/eu/ のリクエストは、優先度 2 の /live/ ルートに引き続き送信されます。

パスの正規化

パスの正規化は、Media CDN が URL の複数の表現を特定のシナリオで単一の正規表現に結合する方法を表します。

パスの正規化によりキャッシュヒット率を直接改善するには、同じコンテンツを表すリクエスト URL の数を減らし、正規化されたパスを予期する送信元のエラーの原因を軽減します。

受信リクエストは、次のように正規化されます。

複数のスラッシュは、1 つのスラッシュに統合されます。たとえば、/videos///12345/manifest.mpd という URL パスは /videos/12345/manifest.mpd に正規化されます。
パスセグメントは、RFC 3986 セクション 6.2.2.3 に従って正規化されます。たとえば、パス /a/b/c/./../../g は、RFC 3986 で定義されている「ドットセグメントの削除」アルゴリズムに基づいて、/a/g に正規化されます。この正規化は、キャッシュをチェックしたり、リクエストを送信元に転送したりする前に行われます。
リクエストはパーセントで正規化されません。たとえば、パーセントでエンコードされたスラッシュ文字（%2F）を含む URL は、エンコードされていない形式でデコードされません。

URL の大文字と小文字は区別されません。署名付きリクエストトークンを含む URL など、多くの URL には大文字と小文字が区別される base64 エンコードが含まれています。

書き換えとリダイレクト

次のセクションでは、リクエストを書き換え、リダイレクトを構成する方法の例を示します。

リクエスト URL の書き換え

Media CDN は、ホストとパスの書き換えをサポートします。書き換えると、送信元に送信される URL が変更され、必要に応じてホストとパスを変更できます。ホストとパスの書き換えはルートレベルで行われるため、マッチャーに基づいて、パス、クエリパラメータ、リクエストヘッダーなど、どのリクエストを書き換えるかを定義できます。

リクエストを書き換えるには、次の 3 つの方法があります。

フィールド説明

フィールド	説明
`urlRewrite.pathPrefixRewrite`	リクエストに一致する `prefixMatch` で指定された接頭辞を削除して、パスを書き換えます。 1 つのルートルールに指定できるのは、`pathPrefixRewrite` または `pathTemplateRewrite` のいずれかです。
`urlRewrite.pathTemplateRewrite`	`pathTemplateRewrite` は、同じルート上の対応する `pathTemplateMatch` 一致ルールでのみ使用できます。 1 つのルートルールに指定できるのは、`pathPrefixRewrite` または `pathTemplateRewrite` のいずれかです。
`urlRewrite.hostRewrite`	リクエストが配信元サーバーに送信される前にホストを書き換えます。

urlRewrite.pathPrefixRewrite

リクエストに一致する prefixMatch で指定された接頭辞を削除して、パスを書き換えます。

1 つのルートルールに指定できるのは、pathPrefixRewrite または pathTemplateRewrite のいずれかです。

urlRewrite.pathTemplateRewrite

pathTemplateRewrite は、同じルート上の対応する pathTemplateMatch 一致ルールでのみ使用できます。

1 つのルートルールに指定できるのは、pathPrefixRewrite または pathTemplateRewrite のいずれかです。

urlRewrite.hostRewrite リクエストが配信元サーバーに送信される前にホストを書き換えます。

注:

URL を書き換えてもキャッシュキーは変更されません。キャッシュキーは、クライアントから送信されたリクエスト URL に基づきます。
書き換えは、ルートマッチングと署名付きリクエストの検証の後に行われます。ルートは別の一致ルールと一致しません。

例: パス接頭辞を削除する

たとえば、クライアントのリクエスト URL を /vod/videos/hls/1234/abc.ts から /videos/hls/1234/abc.ts に書き換える（パスから /vod を削除する）には、pathPrefixRewrite 機能を使用できます。

name: prod-service
routing:
  hostRules:
  - hosts:
    - cdn.example.com
    pathMatcher: routes
  pathMatchers:
  - name: routes
    routeRules:
    - priority: 1
      origin: my-origin
      matchRules:
      - prefixMatch: "/vod/videos/"
      routeAction:
        urlRewrite:
          pathPrefixRewrite: "/videos/"

pathPrefixRewrite は、matchRules[].prefixMatch で一致したパスコンポーネント全体を pathPrefixRewrite の値で置き換えることによって機能します。

ホスト名を書き換えるには（たとえば、cdn.example.com を my-bucket.s3.us-west-2.amazonaws.com に書き換える）、次のように構成します。

name: prod-service
routing:
  hostRules:
  - hosts:
    - cdn.example.com
    pathMatcher: routes
  pathMatchers:
  - name: routes
    routeRules:
    - priority: 1
      origin: my-origin
      matchRules:
      - prefixMatch: "/videos/"
      routeAction:
        urlRewrite:
          hostRewrite: "my-bucket.s3.us-west-2.amazonaws.com"

この場合、送信元リクエスト URL は cdn.example.com/videos/* から my-bucket.s3.us-west-2.amazonaws.com/videos/* に変更されます。単一のルート内でホストの書き換えとパスの書き換えの両方を行うこともできます。

例: 変数を使用して URL を書き換える

pathTemplateMatch と pathTemplateRewrite を使用して、受信リクエスト URL の一部を書き換える。変数のキャプチャをご覧ください。

リダイレクトリクエスト

Media CDN は、次の 3 種類のリダイレクトをサポートしています。

ホストリダイレクト。ホスト（ドメイン）のみをリダイレクトし、パスとクエリのパラメータを変更しません。
パスのリダイレクト。パスを完全に置き換えます。
パス接頭辞のリダイレクト。一致する接頭辞のみを置き換えます。

リダイレクトはデフォルトで HTTP 301 (Moved Permanently) になりますが、ルートごとに異なるリダイレクトステータスコードを返すように構成することもできます。

次の構成は、単純な接頭辞ベースのリダイレクトの例です。https://cdn.example.com/on-demand/* にアクセスするユーザーを https://cdn.example.com/streaming/* にリダイレクトします。

name: prod-service
routing:
  hostRules:
  - hosts:
    - cdn.example.com
    pathMatcher: routes
  pathMatchers:
  - name: routes
    routeRules:
    - priority: 10
      origin: my-origin
      matchRules:
      - prefixMatch: "/on-demand/"
      routeAction:
        urlRedirect:
          # The prefix matched in matchRules.prefixMatch is replaced
          # by this value
          prefixRedirect: "/streaming/"
          redirectResponseCode: TEMPORARY_REDIRECT # corresponds to a HTTP 307

この例では、リダイレクトを一時リダイレクトに変更して、クライアント（ブラウザなど）がリダイレクトできないようにしています。これは、近い将来変更する必要がある場合に便利です。

サポートされている redirectResponseCode 値を次の表に示します。

リダイレクトのレスポンスコード	HTTP ステータスコード
`MOVED_PERMANENTLY_DEFAULT`	HTTP 301（恒久的に移動）
`FOUND`	HTTP 302 (Found)
`SEE_OTHER`	HTTP 303（関連情報）
`TEMPORARY_REDIRECT`	HTTP 307（一時的リダイレクト）
`PERMANENT_REDIRECT`	HTTP 308（恒久的なリダイレクト）

注:

ルートは、トラフィックを送信元に転送するか、クライアントにリダイレクトを返すことができます。origin フィールドと routeAction.urlRedirect フィールドの両方を同時に設定することはできません。
HTTPS にリダイレクトするルートでは、少なくとも 1 つの SSL 証明書がサービスに接続されている必要があります。

すべてのリクエストを HTTPS にリダイレクトする

すべてのリクエストを（HTTP ではなく）HTTPS にリダイレクトするには、すべてのクライアントリクエストが自動的に HTTPS にリダイレクトされるように各サービスを構成します。HTTP 経由で接続するクライアントには、http:// ではなく https:// を使用して、Location ヘッダーを同じ URL に設定した HTTP 301 (Permanent Redirect) レスポンスが送信されます。

gcloud

gcloud edge-cache services update MY_SERVICE \
    --require-tls

Request issued for: [MY_SERVICE]
Updated service [MY_SERVICE].

このコマンドは、requireTls が true に設定されたサービスの説明を返します。

  name: MY_SERVICE
  requireTls: true

また、Strict-Transport-Security ヘッダーをレスポンスヘッダーとして設定し、クライアントが常に HTTPS で直接接続するように指示することもできます。

サードパーティのストレージバックエンドを使用する

Media CDN は、Google Cloud の外部にある、到達可能な HTTP エンドポイント（AWS S3 ストレージバケット、Azure Blob Storage、その他のストレージプロバイダ）への接続をサポートしています。これは、マルチクラウドアーキテクチャを使用している場合や、Storage Transfer Service を使用してデータを Cloud Storage にまだ移行していない場合に役立ちます。

AWS S3 で仮想ホスト型バケットを構成する最小限の送信元構成。

name: MY_S3_ORIGIN
originAddress: BUCKET-NAME.s3.REGION.amazonaws.com

EdgeCacheService リソース用に構成されたホスト名と一致するバケット名を使用していない場合は、この送信元に関連付けられたルート用のホスト書き換えも構成する必要があります。それ以外の場合、クライアントリクエストによって設定された Host ヘッダーは、送信元からフェッチするときに使用されます。

たとえば、パス接頭辞が /legacy/ のすべてのリクエストを外部バケットにマッピングするには、送信元リクエストからこの接頭辞を削除するように hostRewrite と pathPrefixRewrite の両方を構成します。

routeRules:
  - description: legacy backend
    matchRules:
    - prefixMatch: "/legacy/"
    routeAction:
      urlRewrite:
        hostRewrite: BUCKET-NAME.s3.REGION.amazonaws.com
        pathPrefixRewrite: /
      cdnPolicy:
        cacheMode: CACHE_ALL_STATIC
        defaultTtl: 3600s

送信元リクエストにホストヘッダーを設定する方法について詳しくは、送信元リクエストヘッダーのドキュメントをご覧ください。

クロスオリジンリソースシェアリング（CORS）

クロスオリジンリソースシェアリング（CORS）ポリシーを使用すると、ルートごとのポリシーに基づいて、Access-Control-Allow-Origins などの CORS ヘッダーを自動的に設定できます。

これらのヘッダーを使用すると、メディア CD サービスへのクロスオリジン呼び出しが可能になります。これらは、ウェブサイトのフロントエンドとは異なるドメイン（オリジン）でホストされている可能性があるため、明示的に許可されないクロスオリジンリクエストが阻止されます。

CORS ポリシーは EdgeCacheService の一部として構成され、ルートごとに設定できます。

CORS の構成

次の表で、CORS ポリシーを構成するフィールドを示します。

フィールド	説明	例
allowOrigins	`Access-Control-Allow-Origins` レスポンスヘッダーを設定します。これにより、ブラウザ環境でクロスオリジンリクエストを作成できる送信元を指定します。たとえば、動画コンテンツの配信先が`https://video.example.com`ユーザー向けポータルは`https://stream.example.com`、次のように追加します `https://stream.example.com` 。	`Access-Control-Allow-Origins: https://stream.example.com`
maxAge	ブラウザクライアントが CORS プリフライトリクエストへのレスポンスをキャッシュに保存する期間を秒単位で指定する `Access-Control-Max-Age` レスポンスヘッダーを設定します。一部のブラウザは、最大値（86400s）が指定されている場合でも、2 時間以下に制限されます。	`Access-Control-Max-Age: 7200`
allowMethods	`Access-Control-Allow-Methods` レスポンスヘッダーを設定します。これにより、リソースへのアクセスを許可する HTTP メソッドを指定します。 Media CDN がサポートするメソッドは、`GET`、`HEAD`、`OPTIONS` のみです。	`Access-Control-Allow-Methods: GET, OPTIONS, HEAD`
allowHeaders	`Access-Control-Allow-Headers` ヘッダーを設定します。これにより、CORS リクエストで送信できるヘッダーが決まります。これは通常、動画プレーヤーで必要になります。プレーヤーはクロスオリジンをリクエストする際に、動画コンテンツのレスポンスヘッダーにアクセスする必要があります。	`Access-Control-Allow-Headers: Content-Type, If-Modified-Since, Range, User-Agent`
exposeHeaders	`Access-Control-Expose-Headers` レスポンスヘッダーを設定します。これにより、クライアント側 JavaScript がアクセスできるヘッダーが決まります。これは通常、動画プレーヤーで必要になります。プレーヤーは、コンテンツのクロスオリジンをリクエストするときに、動画コンテンツの特定のレスポンスヘッダーにアクセスする必要がある場合があります。	`Access-Control-Expose-Headers: Date, Cache-Status, Content-Type, Content-Length`
allowCredentials	`Access-Control-Allow-Credentials` レスポンスヘッダーを設定します。これにより、クライアント側の JavaScript で、認証情報を含むリクエストのレスポンスを検査できます。 false に設定すると、このヘッダーは省略されます。	`Access-Control-Allow-Credentials: true`
disabled	`corsPolicy` を削除せずに無効にします。プリフライトの `OPTIONS` リクエストは送信元にプロキシされます。	該当なし

corsPolicy の例

次の構成例は、基本的な corsPolicy 構成を示しています。

routeRules:
- priority: 1
  matchRules:
  - prefixMatch: /stream/
  routeAction:
    cdnPolicy:
      defaultTtl: 3600s
    corsPolicy:
      allowOrigins:
      - "https://stream.example.com"
      - "https://stream-staging.example.com"
      maxAge: 86400s # some browsers might only honor up to 7200s or less
      allowMethods:
      - "GET"
      - "HEAD"
      - "OPTIONS"
      allowHeaders:
      - "Content-Type"
      - "If-Modified-Since"
      - "Range"
      - "User-Agent"
      exposeHeaders:
      - "Content-Type"
      - "Content-Length"
      - "Date"

CORS の詳細については、web.dev に関する CORS の記事をご覧ください。

ルーティングのトラブルシューティング

一部のリクエストが一致しない、またはエラーが返される場合:

ルートには、prefixMatch、fullPathMatch、pathTemplateMatch のいずれか 1 つのみが定義された matchRule が必要です。これらのフィールドのいずれかが含まれていない場合、API からエラーが返されます。
各ルートの priority が正しく設定されていることを確認してください。より範囲の狭い（長い）ルートは、より広範囲で短いルートの一致よりも優先度が高い必要があります。
GET、HEAD、OPTIONS リクエストのみがサポートされています。他の HTTP メソッドは HTTP 405 (Method Not Allowed) エラーで拒否されます。
本文付きの HTTP GET リクエストやトレーラーを含むリクエストは、HTTP 400 エラーで拒否されます。これは、GET リクエストでリクエスト本文が許可されていないためです。
クエリパラメータとヘッダーマッチングは論理「AND」です。リクエストがすべてのクエリパラメータ/ヘッダーキー（および指定された場合は値）と一致する必要があります。

次のステップ

キャッシュの構成に関するドキュメントを確認する。
さまざまな生成元に接続する方法を理解します。
サービスの TLS（SSL）証明書を設定します。
コンテンツへのアクセスを認証するように署名付きリクエストを構成する。