Amazon IVSのマニフェストファイルを2023年夏にもういちど眺めてみた
はじめに
清水です。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 cloudfrontvia: 1.1 3a5axxxxxxxxxxxxxxxxxxxxxxxx3916.cloudfront.net (CloudFront)x-amz-cf-pop: NRT57-P3x-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ドメインでそれぞれ以下のようになりました。
% 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
% 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の魅力ですよね。今後のアップデートにも期待しつつ、また思い出したころにマニフェストファイルを眺めてみたいと!?思います。
![[UPDATE] Amazon IVS Low-Latency Streamingでストリームの引き継ぎができるようになりました！ [Stream Takeover]](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-0a6ca0c792a1e10f72f0370a1247876d/bcfc5b39115203c31a0cae7e5d1df84e/amazon-interactive-video-service-1)
