Amazon IVSのマニフェストファイルを2023年夏にもういちど眺めてみた

IVSのPlayback URLのレスポンスヘッダに以前はなかったCloudFrontっぽさがあることに気付きました。改めてマニフェストファイルを眺めてみると、トップレベルマニフェストのみCloudFront経由の配信になっていることが伺えました。

清水俊也

2023.07.07

はじめに

清水です。Amazon Interactive Video Service (Amazon IVS)はAWSの提供するマネージドなライブストリーミングサービスです。超低遅延配信ができ、かつ簡単にセットアップできる点が嬉しいですよね。2020年7月にリリースしたサービスですが、リリースから少しした2020年9月に、このAmazon IVSのマニフェストファイル（拡張子.m3u8のファイル）を確認してみるというブログをまとめました。

このブログエントリから3年弱ほど経った先日、ふとこの2020年9月のときと同じようにマニフェストファイルのヘッダ情報を参照してみる機会がありました。そこでトップレベルマニフェストファイルのレスポンスヘッダ情報が変わっていることに気が付きます。具体的にはx-amz-cf-pop: NRT12-C5といった、見慣れた!?AWSのCDNサービスであるAmazon CloudFrontに関連しそうなヘッダが含まれていました。IVSのリリースから3年経ったこの2023年夏に改めてそのマニフェストファイルを眺めてみたところ、トップレベルマニフェストファイル（Playback URL）についてはAmazon CloudFrontからの配信になっているであろうことが垣間見えました。トップレベルマニフェスト以外の配信経路やそのファイルの中身などについては変わりはなさそうです。以下、実際に確認した内容についてまとめてみたいと思います。

Playback URLのレスポンスヘッダ情報が変わっている!?

事の発端は先日まとめていた以下のブログです。

その中でPlayback URL（トップレベルのマニフェストファイル）に対してステータスコードを確認するためレスポンスヘッダ情報をcurlコマンドで参照したところ、以下の情報（赤枠で囲んだところ）が返ってきました。

[update] Amazon IVSでプライベートチャンネルのセッション取り消しが可能になりました！ | DevelopersIO

テキストでも再掲してみます。

% curl -I "https://xxxxxxxxxxxx.ap-northeast-1.playback.live-video.net/api/video/v1/ap-northeast-1.123456789012.channel.KSXXXXXXXXXX.m3u8?token=eyJhXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX7yrQ"

HTTP/2 200
content-type: application/vnd.apple.mpegurl
content-length: 8915
vary: Accept-Encoding
date: Fri, 30 Jun 2023 09:45:51 GMT
access-control-allow-origin: *
x-amzn-trace-id: Root=1-64xxxxxx-xxxxxxxxxxxxxxxxxxxxxx28
x-amzn-trace-id: Root=1-64xxxxxx-xxxxxxxxxxxxxxxxxxxxxx28
x-cache: Miss from cloudfront
via: 1.1 8293xxxxxxxxxxxxxxxxxxxxxxxx9854.cloudfront.net (CloudFront)
x-amz-cf-pop: NRT12-C5
x-amz-cf-id: oHrPxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxJw==

このレスポンスヘッダ情報をみると「おやっ!?」と思いますよね。そうです、CloudFrontを介した配信であるだろうことがレスポンスヘッダ情報から伺えます。

前回、2020年9月末に参照したトップレベルマニフェストファイルは以下のようなレスポンスヘッダ情報でした。

Amazon IVSのマニフェストファイルを眺めてみた | DevelopersIO

こちらもテキストで再掲しておきます。

% curl -I https://XXXXXXXXXXXX.us-west-2.playback.live-video.net/api/video/v1/us-west-2.123456789012.channel.XXXXXXXXsS0f.m3u8
HTTP/1.1 200 OK
Server: nginx/1.14.1
Date: Tue, 29 Sep 2020 10:46:36 GMT
Content-Type: application/vnd.apple.mpegurl
Content-Length: 7828
Access-Control-Allow-Origin: *
Cache-Control: no-cache,no-store

Serverヘッダのnginx/1.14.1が特徴的ではありましたが、CloudFrontに関するヘッダ情報はありませんでした。IVSでは2020年のリリース当時から独自のCDNを内包しているということで、「CloudFrontを使用していない」ということに納得はしていたのですが……

トップレベルマニフェストのレスポンスヘッダ情報を改めて眺めてみる

トップレベルマニフェストファイル（Playback URL）のレスポンスヘッダ情報がこれまでと異なり、CloudFrontを経由して配信されているように見えることがわかりました。発端となったブログエントリでは、プラベートチャンネルを使用して再生時にトークンを使用していたこともあるので、改めて以前マニフェストファイルを確認したときのエントリと同様の環境でトップレベルマニフェストファイルを参照してみましょう。

以前マニフェストファイルを確認したときのエントリ同様、IVSのコントロールプレーンをオレゴンリージョンとしてデフォルト設定のChannelを作成します。Streaming Softwareから映像を打ち上げ、ライブストリーミングを視聴しつつcurlコマンドでトップレベルマニフェストファイル、つまりPlayback URLのレスポンスヘッダ情報を取得してみました。

結果がこちらです。発端となったブログエントリ同様、レスポンスヘッダ情報からCloudFrontを経由した配信であることが伺えます。

% curl -I https://28XXXXXXXXXX.us-west-2.playback.live-video.net/api/video/v1/us-west-2.123456789012.channel.c2XXXXXXXXXX.m3u8
HTTP/2 200
content-type: application/vnd.apple.mpegurl
content-length: 7273
vary: Accept-Encoding
date: Fri, 07 Jul 2023 02:08:42 GMT
access-control-allow-origin: *
x-amzn-trace-id: Root=1-64xxxxxx-xxxxxxxxxxxxxxxxxxxxxx0b
x-amzn-trace-id: Root=1-64xxxxxx-xxxxxxxxxxxxxxxxxxxxxx0b
x-cache: Miss from cloudfront
via: 1.1 3a5axxxxxxxxxxxxxxxxxxxxxxxx3916.cloudfront.net (CloudFront)
x-amz-cf-pop: NRT57-P3
x-amz-cf-id: kEwexxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxiQ==

具体的に2020年9月時点のトップレベルマニフェストファイルのレスポンスヘッダ情報と比べると、以下のようになります。

  • HTTPのバージョンがHTTP/1.1からHTTP/2に変更
  • Server: nginx/1.14.1ヘッダが削除
  • vary: Accept-Encodingヘッダが追加
  • x-amzn-trace-idヘッダが追加
  • CloudFrontを経由していると思われるヘッダの追加
    • x-cache: Miss from cloudfront
    • via: 1.1 3a5axxxxxxxxxxxxxxxxxxxxxxxx3916.cloudfront.net (CloudFront)
    • x-amz-cf-pop: NRT57-P3
    • x-amz-cf-id: kEwexxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxiQ==

発端となったブログエントリでは東京リージョンをコントロールプレーンとしたChannelで確認していたので、こちらも念のためもういちど参照してみましょう。オレゴンリージョンと基本的には変わらない内容ですね。

% curl -I https://62XXXXXXXXXX.ap-northeast-1.playback.live-video.net/api/video/v1/ap-northeast-1.123456789012.channel.03XXXXXXXXXX.m3u8
HTTP/2 200
content-type: application/vnd.apple.mpegurl
content-length: 8643
vary: Accept-Encoding
date: Fri, 07 Jul 2023 02:26:07 GMT
access-control-allow-origin: *
x-amzn-trace-id: Root=1-64xxxxxx-xxxxxxxxxxxxxxxxxxxxxxa6
x-amzn-trace-id: Root=1-64xxxxxx-xxxxxxxxxxxxxxxxxxxxxxa6
x-cache: Miss from cloudfront
via: 1.1 3a96xxxxxxxxxxxxxxxxxxxxxxxxcf6e.cloudfront.net (CloudFront)
x-amz-cf-pop: NRT57-P4
x-amz-cf-id: 0YDCxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxdw==

オレゴンリージョン、東京リージョンのそれぞれをコントロールプレーンとしたChannelで、トップレベルマニフェストファイル（Playback URL）のレスポンスヘッダ情報を確認してみたところ、トップレベルマニフェストファイルはCloudFrontを経由しているように見えることが改めて確認できました。

トップレベルマニフェストがCloudFront経由の配信であることをIPアドレスから確認してみる

トップレベルマニフェストファイルのレスポンスヘッダ情報から、CloudFrontを経由した配信であることが伺えます。しかし（ないとは思いますが）ヘッダ情報を偽装してCloudFrontっぽく配信していることもあるかもしれません!? 配信元となるPlayback URLのドメイン名について名前解決を行い、実際にCloudFront経由の配信であるかどうか確認してみましょう。

Playback URLの名前解決結果はオレゴンリージョン、東京リージョンのPlayback URLドメインでそれぞれ以下のようになりました。

オレゴンリージョンのPlaybackURLドメインの名前解決結果

% dig 28XXXXXXXXXX.us-west-2.playback.live-video.net

; <<>> DiG 9.10.6 <<>> 28XXXXXXXXXX.us-west-2.playback.live-video.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27415
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1220
;; QUESTION SECTION:
;28XXXXXXXXXX.us-west-2.playback.live-video.net.        IN A

;; ANSWER SECTION:
28XXXXXXXXXX.us-west-2.playback.live-video.net. 60 IN A 18.65.206.67
28XXXXXXXXXX.us-west-2.playback.live-video.net. 60 IN A 18.65.206.6
28XXXXXXXXXX.us-west-2.playback.live-video.net. 60 IN A 18.65.206.41
28XXXXXXXXXX.us-west-2.playback.live-video.net. 60 IN A 18.65.206.58

;; Query time: 24 msec
;; SERVER: 24xx:xx:xxxx:xxx:xx:xxxx:xxxx:xxxx#53(24xx:xx:xxxx:xxx:xx:xxxx:xxxx:xxxx)
;; WHEN: Fri Jul 07 16:16:04 JST 2023
;; MSG SIZE  rcvd: 139

東京リージョンのPlaybackURLドメインの名前解決結果

% dig 62XXXXXXXXXX.ap-northeast-1.playback.live-video.net

; <<>> DiG 9.10.6 <<>> 62XXXXXXXXXX.ap-northeast-1.playback.live-video.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50070
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1220
;; QUESTION SECTION:
;62XXXXXXXXXX.ap-northeast-1.playback.live-video.net. IN        A

;; ANSWER SECTION:
62XXXXXXXXXX.ap-northeast-1.playback.live-video.net. 60 IN A 18.65.216.53
62XXXXXXXXXX.ap-northeast-1.playback.live-video.net. 60 IN A 18.65.216.62
62XXXXXXXXXX.ap-northeast-1.playback.live-video.net. 60 IN A 18.65.216.59
62XXXXXXXXXX.ap-northeast-1.playback.live-video.net. 60 IN A 18.65.216.107

;; Query time: 28 msec
;; SERVER: 24xx:xx:xxxx:xxx:xx:xxxx:xxxx:xxxx#53(24xx:xx:xxxx:xxx:xx:xxxx:xxxx:xxxx)
;; WHEN: Fri Jul 07 16:16:08 JST 2023
;; MSG SIZE  rcvd: 144

d12345678.cloudfront.netなドメイン名をCNAMEレコード設定していたらCloudFront経由であることがすぐにわかったのですが、AレコードでIPアドレスを返してきていますね。ただCloudFrontで独自ドメインを使用する場合はCNAMEよりもA ALIASレコードの使用が推奨されています。（Amazon Route 53のALIASレコード利用のススメ | DevelopersIO）今回もCNAMEではなくA ALIASで登録していることは十二分に考えられるでしょう。実際に名前解決して得られたIPアドレスのレンジをCloudFrontのIPアドレスレンジ（list-cloudfront-ips）から確認してみます。（Locations and IP address ranges of CloudFront edge servers - Amazon CloudFront）

% curl -s https://d7uri8nf7uskq.cloudfront.net/tools/list-cloudfront-ips | jq . |  nl
     1  {
     2    "CLOUDFRONT_GLOBAL_IP_LIST": [
     3      "120.52.22.96/27",
     4      "205.251.249.0/24",
        ＜略＞
    68      "54.239.192.0/19",
    69      "18.68.0.0/16",
    70      "18.64.0.0/14",
    71      "120.52.12.64/26",
    72      "99.84.0.0/16",
        ＜略＞
    87      "64.252.64.0/18"
    88    ],
    89    "CLOUDFRONT_REGIONAL_EDGE_IP_LIST": [
    90      "13.113.196.64/26",
        ＜略＞
   146      "44.234.90.252/30"
   147    ]
   148  }

CLOUDFRONT_GLOBAL_IP_LISTに18.64.0.0/14が含まれていることがわかります。18.64.0.0/14は18.64.0.0から18.67.255.255となるので、先ほどPlayback URLのドメインを名前解決して得られたIPアドレスはいずれもこの18.64.0.0/14に含まれていることとなります。つまり、 Playback URLのドメインはCloudFrontのIPアドレスのものであり、トップレベルマニフェストファイルはCloudFront経由で配信されている ことがIPアドレスから実際に確認できました。

トップレベルマニフェストの中身も改めて眺めてみる

ドップレベルマニフェストファイルのヘッダ情報、またそのドメイン名の名前解決結果から、現在IVSのトップレベルマニフェストはCloudFront経由の配信となっていることが確認できました。続いてトップレベルマニフェストの中身についても確認してみましょう。以下、東京リージョンをコントロールプレーンとしたChannelのトップレベルマニフェストファイルの中身となります。

% curl https://62XXXXXXXXXX.ap-northeast-1.playback.live-video.net/api/video/v1/ap-northeast-1.123456789012.channel.03XXXXXXXXXX.m3u8
#EXTM3U
#EXT-X-SESSION-DATA:DATA-ID="NODE",VALUE="video-edge-b01504.tyo03"
#EXT-X-SESSION-DATA:DATA-ID="MANIFEST-NODE-TYPE",VALUE="weaver_cluster"
#EXT-X-SESSION-DATA:DATA-ID="MANIFEST-NODE",VALUE="video-weaver.tyo05"
#EXT-X-SESSION-DATA:DATA-ID="SUPPRESS",VALUE="true"
#EXT-X-SESSION-DATA:DATA-ID="SERVER-TIME",VALUE="1688696790.56"
#EXT-X-SESSION-DATA:DATA-ID="TRANSCODESTACK",VALUE="2023-Transcode-QS-V1"
#EXT-X-SESSION-DATA:DATA-ID="USER-IP",VALUE="[アクセス元IPv4アドレス]"
#EXT-X-SESSION-DATA:DATA-ID="SERVING-ID",VALUE="[32文字のランダムな文字列]"
#EXT-X-SESSION-DATA:DATA-ID="CLUSTER",VALUE="tyo03"
#EXT-X-SESSION-DATA:DATA-ID="ABS",VALUE="false"
#EXT-X-SESSION-DATA:DATA-ID="VIDEO-SESSION-ID",VALUE="[19桁の数字]"
#EXT-X-SESSION-DATA:DATA-ID="BROADCAST-ID",VALUE="[11桁の数字]"
#EXT-X-SESSION-DATA:DATA-ID="STREAM-TIME",VALUE="86.564220"
#EXT-X-SESSION-DATA:DATA-ID="FUTURE",VALUE="true"
#EXT-X-SESSION-DATA:DATA-ID="MANIFEST-CLUSTER",VALUE="tyo05"
#EXT-X-SESSION-DATA:DATA-ID="ORIGIN",VALUE="pdx05"
#EXT-X-SESSION-DATA:DATA-ID="C",VALUE="[1000文字超のランダムな文字列]"
#EXT-X-SESSION-DATA:DATA-ID="CUSTOMER_ID",VALUE="[AWSアカウントID]"
#EXT-X-SESSION-DATA:DATA-ID="CONTENT_ID",VALUE="[12文字のランダムな文字列]"
#EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="chunked",NAME="1080p",AUTOSELECT=YES,DEFAULT=YES
#EXT-X-STREAM-INF:BANDWIDTH=5765474,RESOLUTION=1920x1080,CODECS="avc1.640028,mp4a.40.2",VIDEO="chunked",FRAME-RATE=30.000
https://video-weaver.tyo05.hls.live-video.net/v1/playlist/[800文字超のランダムな文字列1].m3u8
#EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="720p30",NAME="720p",AUTOSELECT=YES,DEFAULT=YES
#EXT-X-STREAM-INF:BANDWIDTH=2373000,RESOLUTION=1280x720,CODECS="avc1.4D401F,mp4a.40.2",VIDEO="720p30",FRAME-RATE=30.000
https://video-weaver.tyo05.hls.live-video.net/v1/playlist/[800文字超のランダムな文字列2].m3u8
#EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="480p30",NAME="480p",AUTOSELECT=YES,DEFAULT=YES
#EXT-X-STREAM-INF:BANDWIDTH=1427999,RESOLUTION=852x480,CODECS="avc1.4D401F,mp4a.40.2",VIDEO="480p30",FRAME-RATE=30.000
https://video-weaver.tyo05.hls.live-video.net/v1/playlist/[800文字超のランダムな文字列3].m3u8
#EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="360p30",NAME="360p",AUTOSELECT=YES,DEFAULT=YES
#EXT-X-STREAM-INF:BANDWIDTH=630000,RESOLUTION=640x360,CODECS="avc1.4D401F,mp4a.40.2",VIDEO="360p30",FRAME-RATE=30.000
https://video-weaver.tyo05.hls.live-video.net/v1/playlist/[800文字超のランダムな文字列4].m3u8
#EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="160p30",NAME="160p",AUTOSELECT=YES,DEFAULT=YES
#EXT-X-STREAM-INF:BANDWIDTH=230000,RESOLUTION=284x160,CODECS="avc1.4D401F,mp4a.40.2",VIDEO="160p30",FRAME-RATE=30.000
https://video-weaver.tyo05.hls.live-video.net/v1/playlist/[800文字超のランダムな文字列5].m3u8

基本的にはこれまで、2020年9月の時点と変わらない内容かと思います。ギョッっとするような長さのランダムな文字も変わりありません。

細かな違いで気になった点を挙げると、#EXT-X-SESSION-DATAのひとつ、DATA-ID="TRANSCODESTACK"がVALUE="2023-Transcode-QS-V1"となっています。2020年9月の時点ではVALUE="2017TranscodeQS_V2"でした。名称からの推測に過ぎませんが、トランスコードまわりについて最新の2023年版にアップデートされているのではないかと思います。

ABRのマニフェストファイルについても確認してみる

続いてトップレベルマニフェストファイルから続く、ABRのマニフェストファイル（child manifest、子マニフェストファイル）についても確認してみます。ビットレート・解像度の一番高いものを採り上げます。まずはレスポンスのヘッダ情報です。

% curl -I https://video-weaver.tyo05.hls.live-video.net/v1/playlist/[800文字超のランダムな文字列1].m3u8
HTTP/1.1 200 OK
cache-control: no-cache, no-store, private
content-type: application/vnd.apple.mpegurl
vary: Accept-Encoding
date: Fri, 07 Jul 2023 02:27:26 GMT
access-control-allow-origin: *

こちらも基本的な内容は2020年9月のときと変わらない認識です。なおトップレベルのマニフェストファイルはHTTP/2での配信でしたが、子マニフェストファイルはHTTP/1.1での配信となっていました。

子マニフェストファイルの中身についても確認してみます。やっぱりギョッとする文字列ですが、整理すると以下のようになります。

% curl https://video-weaver.tyo05.hls.live-video.net/v1/playlist/[800文字超のランダムな文字列1].m3u8
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:77
#EXT-X-NET-LIVE-VIDEO-LIVE-SEQUENCE:77
#EXT-X-NET-LIVE-VIDEO-ELAPSED-SECS:154.000
#EXT-X-NET-LIVE-VIDEO-TOTAL-SECS:186.000
#EXT-X-DATERANGE:ID="playlist-creation-1688696846",CLASS="timestamp",START-DATE="2023-07-07T02:27:26.426Z",END-ON-NEXT=YES,X-SERVER-TIME="1688696846.43"
#EXT-X-DATERANGE:ID="source-1688696817",CLASS="live-video-net-stream-source",START-DATE="2023-07-07T02:26:57.632Z",END-ON-NEXT=YES,X-NET-LIVE-VIDEO-STREAM-SOURCE="live"
#EXT-X-PROGRAM-DATE-TIME:2023-07-07T02:27:41.632Z
#EXTINF:2.000,live
https://video-edge-b01504.tyo03.hls.live-video.net/v1/segment/[900文字超のランダムな文字列1].ts
#EXT-X-PROGRAM-DATE-TIME:2023-07-07T02:27:43.632Z
#EXTINF:2.000,live
https://video-edge-b01504.tyo03.hls.live-video.net/v1/segment/[900文字超のランダムな文字列2].ts
#EXT-X-PROGRAM-DATE-TIME:2023-07-07T02:27:45.632Z
#EXTINF:2.000,live
https://video-edge-b01504.tyo03.hls.live-video.net/v1/segment/[900文字超のランダムな文字列3].ts
#EXT-X-PROGRAM-DATE-TIME:2023-07-07T02:27:47.632Z
#EXTINF:2.000,live
https://video-edge-b01504.tyo03.hls.live-video.net/v1/segment/[900文字超のランダムな文字列4].ts
#EXT-X-PROGRAM-DATE-TIME:2023-07-07T02:27:49.632Z
#EXTINF:2.000,live
https://video-edge-b01504.tyo03.hls.live-video.net/v1/segment/[900文字超のランダムな文字列5].ts
#EXT-X-PROGRAM-DATE-TIME:2023-07-07T02:27:51.632Z
#EXTINF:2.000,live
https://video-edge-b01504.tyo03.hls.live-video.net/v1/segment/[900文字超のランダムな文字列6].ts
#EXT-X-PROGRAM-DATE-TIME:2023-07-07T02:27:53.632Z
#EXTINF:2.000,live
https://video-edge-b01504.tyo03.hls.live-video.net/v1/segment/[900文字超のランダムな文字列7].ts
#EXT-X-PROGRAM-DATE-TIME:2023-07-07T02:27:55.632Z
#EXTINF:2.000,live
https://video-edge-b01504.tyo03.hls.live-video.net/v1/segment/[900文字超のランダムな文字列8].ts
#EXT-X-PROGRAM-DATE-TIME:2023-07-07T02:27:57.632Z
#EXTINF:2.000,live
https://video-edge-b01504.tyo03.hls.live-video.net/v1/segment/[900文字超のランダムな文字列9].ts
#EXT-X-PROGRAM-DATE-TIME:2023-07-07T02:27:59.632Z
#EXTINF:2.000,live
https://video-edge-b01504.tyo03.hls.live-video.net/v1/segment/[900文字超のランダムな文字列10].ts
#EXT-X-PROGRAM-DATE-TIME:2023-07-07T02:28:01.632Z
#EXTINF:2.000,live
https://video-edge-b01504.tyo03.hls.live-video.net/v1/segment/[900文字超のランダムな文字列11].ts
#EXT-X-PROGRAM-DATE-TIME:2023-07-07T02:28:03.632Z
#EXTINF:2.000,live
https://video-edge-b01504.tyo03.hls.live-video.net/v1/segment/[900文字超のランダムな文字列12].ts
#EXT-X-PROGRAM-DATE-TIME:2023-07-07T02:28:05.632Z
#EXTINF:2.000,live
https://video-edge-b01504.tyo03.hls.live-video.net/v1/segment/[900文字超のランダムな文字列13].ts
#EXT-X-PROGRAM-DATE-TIME:2023-07-07T02:28:07.632Z
#EXTINF:2.000,live
https://video-edge-b01504.tyo03.hls.live-video.net/v1/segment/[900文字超のランダムな文字列14].ts
#EXT-X-PREFETCH:https://video-edge-b01504.tyo03.hls.live-video.net/v1/segment/[900文字超のランダムな文字列15].ts
#EXT-X-PREFETCH:https://video-edge-b01504.tyo03.hls.live-video.net/v1/segment/[900文字超のランダムな文字列16].ts

#EXT-X-PREFETCHが使われている点など、子マニフェストファイルの中身についても基本的には2020年9月のときと変わらないかと思います。

トップレベルマニフェスト以外の配信元ドメインの名前解決結果の確認

トップレベルマニフェストはそのドメイン名の名前解決結果、IPアドレスからCloudFront経由であることが確認できました。トップレベルマニフェスト以外、子マニフェストファイルとセグメントファイル（tsファイル）については、CloudFrontを経由しているようすはありませんが、これらのドメイン名についても名前解決結果を確認してみましょう。

なお、これら子マニフェストファイルとセグメントファイル（tsファイル）の配信先ドメイン名（live-video.netのサブドメイン）について、2020年9月のときと同様、アクセス元によってドメインの一部（今回であればtyo03やtyo05となっているところ）が変化する点は変わりません。

以下、名前解決の結果です。

% dig video-weaver.tyo05.hls.live-video.net

; <<>> DiG 9.10.6 <<>> video-weaver.tyo05.hls.live-video.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31930
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;video-weaver.tyo05.hls.live-video.net. IN A

;; ANSWER SECTION:
video-weaver.tyo05.hls.live-video.net. 1510 IN A 45.113.131.14

;; Query time: 20 msec
;; SERVER: 24xx:xx:xxxx:xxx:xx:xxxx:xxxx:xxxx#53(24xx:xx:xxxx:xxx:xx:xxxx:xxxx:xxxx)
;; WHEN: Fri Jul 07 20:52:15 JST 2023
;; MSG SIZE  rcvd: 82
% dig video-edge-b01504.tyo03.hls.live-video.net

; <<>> DiG 9.10.6 <<>> video-edge-b01504.tyo03.hls.live-video.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33079
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1220
;; QUESTION SECTION:
;video-edge-b01504.tyo03.hls.live-video.net. IN A

;; ANSWER SECTION:
video-edge-b01504.tyo03.hls.live-video.net. 300 IN A 99.181.88.159

;; Query time: 24 msec
;; SERVER: 24xx:xx:xxxx:xxx:xx:xxxx:xxxx:xxxx#53(24xx:xx:xxxx:xxx:xx:xxxx:xxxx:xxxx)
;; WHEN: Fri Jul 07 20:52:53 JST 2023
;; MSG SIZE  rcvd: 87

それぞれのドメイン名が1つのAレコードに対応していました。CloudFrontのA ALIASレコードとは異なる挙動かと思います。念のため、先ほどと同様にCloudFrontのIPアドレスレンジ（list-cloudfront-ips）に含まれているかどうか確認してみます。

% curl -s https://d7uri8nf7uskq.cloudfront.net/tools/list-cloudfront-ips | jq . | grep -e "45" -e "99"
    "99.86.0.0/16",
    "120.253.245.128/26",
    "120.253.245.192/27",
    "99.84.0.0/16",
    "52.199.127.192/26",
    "13.124.199.0/24",
    "99.79.169.0/24",

子マニフェストファイルとセグメントファイル（tsファイル）の参照先ドメイン名、live-video.netドメインのものはCloudFrontを経由してはいなさそうです。レスポンスヘッダ情報からもCloudFrontっぽさがないことから、トップレベルマニフェストファイル以外については引き続き、IVSの独自のCDNをつかった配信であるといえるかと思います。

まとめ

Amazon IVSのPlayback URLのレスポンスヘッダにCloudFrontっぽさがあったことを発端に、実際にトップレベルマニフェストファイルだけはCloudFrontを経由して配信しているであろうことを、2023年の夏に再びIVSのマニフェストファイルを眺めることで確認してみました。

前回2020年9月にマニフェストファイルを眺めたころからこの3年ほどの間で、Amazon IVSには様々なアップデートがありました。コントロールプレーンとデータプレーンの分離から個人的には対応すると思っていなかったコントロールプレーンの東京?リージョン対応もその一つですよね。CloudFrontから配信しているPlayback URL、データプレーンはグローバルですがリージョン名がこの一部になっています。そのためこのデータプレーン対応リージョンの拡大時にCloudFront経由の配信になったのかな、などという推測もできますが、たしかな情報はありません。

そしてAmazon IVSの特徴である超低遅延配信ですが、Playback URLがCloudFront経由になっていることでも特に変わらないはずでは、と考えています。Player SDK for Webを用いたページでざっと確認したところ、頻繁に参照される子マニフェストファイルやセグメントファイルと比べて、トップレベルマニフェストファイルはそれほど参照されていない（再生開始などのみ）ということが考えの根拠の一つです。

なお、前回マニフェストファイルを眺めてみたときと同じ注意事項になりますが、今回確認した項目のうち、仕様やドキュメントなどに記載がない項目については、今後変更される可能性があります。（トップレベルマニフェストがCloudFrontを経由して配信されている、なんてのは正にこれですね。）とはいっても、これら（マニフェストファイルの中身や配信経路など）を知らなくても超低遅延なライブストリーミングが手軽に実施できるのがAmazon IVSの魅力ですよね。今後のアップデートにも期待しつつ、また思い出したころにマニフェストファイルを眺めてみたいと!?思います。

AWS

関連記事

Amazon IVSリアルタイムストリーミング機能｜視聴までの処理を見てみよう！

坂齊史奈子

2024.04.19

[UPDATE] Amazon IVS Low-Latency StreamingでSRT ingestをサポートしました！

清水俊也

2024.04.08

Amazon IVS Real-Time StreamingにOBSからWHIPでストリーミングしてみた！

清水俊也

2024.03.15

IVS Low-Latency StreamingのPlayback Restriction PolicyでStrict Origin Enforcement有効時の挙動を確認してみた

清水俊也

2024.03.13