はじめに
清水です。本エントリでお届けするアップデート情報はこちら！AWSのマネージド型ライブストリーミングソリューションであるAmazon Interactive Video Service (Amazon IVS)のLow-Latency Streamingでポリシーによる再生制限ができるPlayback restriction policiesが利用可能になりました。2024/02/01 16:00 JSTの段階でAWS What's Newなどへのポストはありませんが、Amazon IVS Low-Latency Streaming User GuideのDocument Historyから現地時間2024/01/31付でアップデートがあったことが確認できます。
Document History (Low-Latency Streaming) - Amazon Interactive Video Service
これまでもAmazon IVSのLow-Latency StreamingではJSON Web Token (JWT)を使った再生制限、プライベートチャンネルが利用可能でした。2020年夏のアップデートでしたね。
このプライベートチャンネルでは、再生時（Playback URLアクセス時）に正しいtokenを含んでいるかをもとに制限を行っていました。新たに利用可能になったPlayback restriction policiesではtokenは必要なく、代わりに設定したpolicy内容でIVS Channel側が制限を行います。制限の判断基準は、アクセス元の国（Countries）ならびにアクセス元（プレイヤーを埋め込んだ）のサイト（Origin）です。tokenによる制限よりも厳密ではありませんが、GeoBlockingや意図しないWebサイトへの埋め込み防止などを簡単に実現できます。
本エントリでは、このIVS Low-Latency StreamingのPlayback restriction policiesによる再生制限を実際に試してみたのでまとめてみたいと思います。
Playback restriction policyの作成
Playback restriction policiesによる再生制限の確認、まずはこのPlayback restriction policyの作成から進めます。Amazon IVSマネジメントコンソールにアクセスしましょう。IVSリリース時にくらべて機能がたくさん増えたなぁなどとニヤニヤしつつ、Low-latency streamingの項目、Playback securityにPlayback restriction policiesが増えていますね！
Playback restriction policiesのページに進み、[Create policy]ボタンを押下します。
Create policy画面に進みます。Playback restriction policy nameを適切に入力しましょう。Strict origin enforcementはデフォルトの無効のまま進めました。Allowed countriesではJP Japanを選択、Allowed originsについてもいったん空欄のまま、[Create policy]でPolicyを作成しましょう。
Playback restriction policyが作成できました。
Playback restriction policyをChannelに設定
続いて、IVS Low-latency streamingのChannelを作成します。Setupの項目、Channel nameを適切に入力し、Channel configurationはDefault configurationで進めます。
Restrict playbackの項目でEnable playback restrictionをonにします。Playback restriction policyで先ほど作成したpolicyを選択しましょう。
Channelが作成できました。Channel詳細画面でもPlayback restrictionの項目が追加されていますね。
Playback restriction policyでの再生制限の確認
Playback restriction policyを設定したChannelが作成できました。それでゃ実際にPlayback restriction policyでの再生制限について確認していきましょう。該当Channelに対してIVSマネジメントコンソール経由で検証用のライブストリーミングを開始します。
Allowed countriesによる再生制限の確認
Playback画面で問題なく再生できている（再生が制限されていない）ことをまず確認しておきましょう。なお、マネジメントコンソールには日本国内からアクセスしている状態です。
続いてPlayback URLに対してcurlコマンドを叩きレスポンス内容を確認してみます。こちらも日本国内からPlayback URLにアクセスしています。以下のようにステータスコード200が返り、マニフェストファイルの取得に成功している（=再生ができる）状態ですね。
% curl -I https://62xxxxxxxx2b.ap-northeast-1.playback.live-video.net/api/video/v1/ap-northeast-1.123456789012.channel.uZxxxxxxxx2u.m3u8
HTTP/2 200
content-type: application/vnd.apple.mpegurl
content-length: 6151
vary: Accept-Encoding
date: Thu, 01 Feb 2024 09:53:43 GMT
access-control-allow-origin: *
x-amzn-trace-id: Root=1-65xxxx27-37xxxxxxxxxxxxxxxxxxxx33
x-amzn-trace-id: Root=1-65xxxx27-37xxxxxxxxxxxxxxxxxxxx33
x-cache: Miss from cloudfront
via: 1.1 a2xxxxxxxxxxxxxxxxxxxxxxxxxxxx72.cloudfront.net (CloudFront)
x-amz-cf-pop: NRT57-C1
x-amz-cf-id: 1lsrxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxOg==先ほど作成してこのChannelにアタッチしたPlayback restriction policyでは、日本国内からのアクセスのみ許可する設定でした。日本国外からPlayback URLにアクセスするケースも確認してみましょう、オレゴンリージョン（us-west-2）でCloudShellを実行してアメリカ国内からのアクセスを再現してみました。以下のように、スタータスコード403が返りクエストに失敗していることが確認できます。アクセス元の国による再生制限、GeoBlockingが実現できていますね！
[cloudshell-user@ip-10-136-120-99 ~]$ curl -i https://62xxxxxxxx2b.ap-northeast-1.playback.live-video.net/api/video/v1/ap-northeast-1.123456789012.channel.uZxxxxxxxx2u.m3u8
HTTP/2 403
content-type: application/json
content-length: 167
date: Thu, 01 Feb 2024 09:58:28 GMT
access-control-allow-origin: *
x-amzn-trace-id: Root=1-65xxxx43-7axxxxxxxxxxxxxxxxxxxxec
x-amzn-trace-id: Root=1-65xxxx43-7axxxxxxxxxxxxxxxxxxxxec
x-cache: Error from cloudfront
via: 1.1 a8xxxxxxxxxxxxxxxxxxxxxxxxxxxxdc.cloudfront.net (CloudFront)
x-amz-cf-pop: HIO50-C2
x-amz-cf-id: p6_UxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxRQ==
[{"url":"/api/video/v1/ap-northeast-1.123456789012.channel.uZxxxxxxxx2u.m3u8","error":"Content Restricted In Region","error_code":"content_geoblocked","type":"error"}]なお、上記で確認したケースとは逆にPlayback restriction policyでUS United States of Americaのみを許可とすれば、日本国内からのアクセスは403で再生不可、オレゴンリージョンのCloudShellからPlayback URLに対してcurlコマンドを叩くと200が返る、という結果となります。
Allowed originsによる再生制限の確認
続いてアクセス元のサイト（Originヘッダ）による再生制限についても確認してみましょう。現状、このChannelにアタッチしたPlayback restriction policyではAllowed originsは指定していない状況です。上記のようにマネジメントコンソールからの再生ができるほか、Playback URLのレスポンスヘッダではaccess-control-allow-origin: *が確認できます。
% curl -I https://62xxxxxxxx2b.ap-northeast-1.playback.live-video.net/api/video/v1/ap-northeast-1.123456789012.channel.uZxxxxxxxx2u.m3u8
HTTP/2 200
content-type: application/vnd.apple.mpegurl
content-length: 6140
vary: Accept-Encoding
date: Thu, 01 Feb 2024 10:16:05 GMT
access-control-allow-origin: *
x-amzn-trace-id: Root=1-65xxxx65-10xxxxxxxxxxxxxxxxxxxxfe
x-amzn-trace-id: Root=1-65xxxx65-10xxxxxxxxxxxxxxxxxxxxfe
x-cache: Miss from cloudfront
via: 1.1 38xxxxxxxxxxxxxxxxxxxxxxxxxxxx20.cloudfront.net (CloudFront)
x-amz-cf-pop: NRT57-C1
x-amz-cf-id: Jl2nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx9w==このChannelにアタッチしている、先ほど作成したPlayback restriction policiesの詳細ページ、[Edit]ボタンから進みます。
Allowed originsの項目の[Add origins]ボタンを押下して再生を許可するOriginを追加します。
許可するOrigin（再生を許可するサイトドメイン）として https://ivs.example.net を追加しました。
再生を許可するOriginを追加したあと、マネジメントコンソールのPlayback画面を確認してみます。マネジメントコンソールは再生を許可するサイトに含まれていない状態ですので、再生はできずにPlayback errorが表示されますね。
Allowed originsで追加したドメインのサイト（ここでは https://ivs.example.net ）に埋め込んだIVS Playerからであれば、再生が可能です。
Playback URLに対するレスポンスヘッダについても確認してみましょう。リクエスト時にOriginヘッダがない場合、もしくはAllowed originsで追加したものと同一のOriginヘッダではない場合、リクエストには成功して200は返りますが、レスポンスヘッダにaccess-control-allow-originは含まれません。
% curl -I https://62xxxxxxxx2b.ap-northeast-1.playback.live-video.net/api/video/v1/ap-northeast-1.123456789012.channel.uZxxxxxxxx2u.m3u8
HTTP/2 200
content-type: application/vnd.apple.mpegurl
content-length: 6140
vary: Accept-Encoding
date: Thu, 01 Feb 2024 10:59:02 GMT
x-amzn-trace-id: Root=1-65xxxx76-74xxxxxxxxxxxxxxxxxxxxd2
x-amzn-trace-id: Root=1-65xxxx76-74xxxxxxxxxxxxxxxxxxxxd2
x-cache: Miss from cloudfront
via: 1.1 05xxxxxxxxxxxxxxxxxxxxxxxxxxxxe4.cloudfront.net (CloudFront)
x-amz-cf-pop: NRT57-C1
x-amz-cf-id: yE709xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxw==% curl -H "Origin: https://not-allowed-site.example.net" -I https://62xxxxxxxx2b.ap-northeast-1.playback.live-video.net/api/video/v1/ap-northeast-1.123456789012.channel.uZxxxxxxxx2u.m3u8
HTTP/2 200
content-type: application/vnd.apple.mpegurl
content-length: 6137
vary: Accept-Encoding
date: Thu, 01 Feb 2024 10:59:42 GMT
x-amzn-trace-id: Root=1-65xxxx9e-63xxxxxxxxxxxxxxxxxxxxd9
x-amzn-trace-id: Root=1-65xxxx9e-63xxxxxxxxxxxxxxxxxxxxd9
x-cache: Miss from cloudfront
via: 1.1 d5xxxxxxxxxxxxxxxxxxxxxxxxxxxx8a.cloudfront.net (CloudFront)
x-amz-cf-pop: NRT57-C1
x-amz-cf-id: tG9FxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxSQ==対して、Allowed originsで指定したものと同じOriginヘッダがある場合は、レスポンスヘッダに access-control-allow-origin: https://ivs.example.net と許可したサイトドメインが含まれるかたちです。
% curl -H "Origin: https://ivs.example.net" -I https://62xxxxxxxx2b.ap-northeast-1.playback.live-video.net/api/video/v1/ap-northeast-1.123456789012.channel.uZxxxxxxxx2u.m3u8
HTTP/2 200
content-type: application/vnd.apple.mpegurl
content-length: 6137
vary: Accept-Encoding
date: Thu, 01 Feb 2024 10:26:35 GMT
access-control-allow-origin: https://ivs.example.net
x-amzn-trace-id: Root=1-65xxxxda-57xxxxxxxxxxxxxxxxxxxx96
x-amzn-trace-id: Root=1-65xxxxda-57xxxxxxxxxxxxxxxxxxxx96
x-cache: Miss from cloudfront
via: 1.1 f3c5f4930da878ee6625af13df3ad240.cloudfront.net (CloudFront)
x-amz-cf-pop: NRT57-C1
x-amz-cf-id: TpJIM15WdCmL2YrVNCHIVXjNo2rjswPpbz5GClFgwX7IDeWUhE3h7g==このaccess-control-allow-originヘッダがないとブラウザ上でCORSエラーが発生、プレイヤーで動画再生ができません。アクセス元の（プレイヤーを埋め込んだ）サイトによる再生制限が行われていることが確認できますね。
なお本エントリでは動作確認を省略しますが、User Guideによるとstrict origin enforcementを有効にすることで、このトップレベルマニフェストファイル（multivariant playlist）のaccess-control-allow-originレスポンスヘッダだけではなく、ほかマニフェストファイル（variant playliset）やセグメントファイルに対してもOriginヘッダが合致するかの確認を行うようです。より厳密にアクセス元の制限を行いたい場合はstrict origin enforcementの有効化を検討してみましょう。
まとめ
Amazon Interactive Video Service (Amazon IVS)のLow-Latency Streamingで新たに利用可能になったPlayback restriction policiesを使って、アクセス元の国による再生制限（GeoBlocking）とアクセス元のサイト（プレイヤーを埋め込んだサイト、Origin）による再生制限を試してみました。
これまでのIVS Low-Latency StreamingのPrivate Channel、tokenによる制限よりも厳密ではありませんが、ライブ動画出力にかかるコスト（料金）が視聴者のアクセス元（厳密には接続しているIVSサーバの場所）によって決まることも考えると、サクッとアクセス元の国による再生制限をかけられるのは嬉しいアップデートかと思います。上手に使い分けていきましょう。
9
