developersIO
MediaPackage v2でStatic Headerを使ったCDN認証が正式にサポートされていました

MediaPackage v2でStatic Headerを使ったCDN認証が正式にサポートされていました

MediaPackage v2で静的ヘッダを用いたCDN認証が利用可能になっています。v1のCDN認証と同様に専用のヘッダとSecrets Mangerに保存する認証コードを用います。CloudFront以外のCDN利用時に活用しましょう。
AWS Elemental MediaPackageAWSメディアサービスAWS
FacebookHatena blogX
2025.10.31

はじめに

清水です。AWS Elemental MediaPackage v2でStatic Headerを用いたCDN認証を正式にサポートするアップデートが2025年7月にありました。2025年10月の時点でもまだWhat's New at AWSへのポストは確認できていませんが、AWS CLIの CHANGELOG、バージョン 1.41.7 の記載でアップデートを確認することができます。

  • api-change:mediapackagev2: This release adds support for CDN Authentication using Static Headers in MediaPackage v2.

APIの更新確認に便利なサイトAWS API Changesで確認すると、本アップデートは2025/07/16付けのものだったようです。

MediaPackage v2 User GuideのDocument historyを確認すると、同じく2025/07/16付けでCDN static auth headersについての項目が追加されています。

mc01
引用元: Document history for the MediaPackage User Guide - AWS Elemental MediaPackage v2

アップデートから少し時間が経ってしまっていますが、本エントリではこのMediaPackage v2でのStatic Headerを使ったCDN認証について、実際に確認してみたのでまとめてみたいと思います。

MediaPackageとCDN認証

アップデート本題に入る前に、MediaPackageとCDN認証について簡単に振り返っておきましょう。

MediaPackage v1のCDN認証

まずはMediaPackage v1のCDN認証についてです。MediaPackage v1では今回のMediaPackage v2でサポートしたようなStatic HeaderによるCDN認証が2020年1月のアップデートでサポートされました。

認証コードはSecrets Managerに保存、またMediaPackage v1のEndpointリソースでCDN認証機能を有効にします。CDN側ではオリジンとなるMediaPackage v1にアクセスする際に、ヘッダX-MediaPackage-CDNIdentifierを認証コードを値として付与してアクセスする、というかたちです。MediaPackage v1でCDN認証を行う場合、このStatic Headerによる方法一択となる認識です。（後述するようにCloudFrontならではの機能、Origin Access Control （OAC）などは利用できません。）

MediaPackage v2のこれまでのCDN認証

続いて2023年5月にリリースされたMediaPackage v2のCDN認証についてです。リリース時の特徴の1つであるよりAWSらしいセキュリティ、Endpoint policyを活用することでUser-Agent Headerなどを用いてリリースのタイミングからCDN認証が可能でした。

また2024年4月にはCloudFrontのOACがMediaPackageをサポートします。CloudFrontの機能でよりセキュアにMediaPackageへアクセスすることが可能になりました。ただし、このOACのMediaPackageサポートはMediaPackage v2（MediaPackage Live v2）のみがサポート対象である点に注意しましょう。

MediaPackage v2がStatic Headerを使ったCDN認証を正式サポート

MediaPackageをオリジンとしCDNにCloudFrontを利用するならば、このMediaPackage typeのOACを使うのが現状でもベストな選択肢であることは変わりありません。

MediaPackageをオリジンとしつつCloudFront以外のCDNを使用する場合、このOACが利用できません。従来まではUser-Agent Headerなどを用いるかたちでCDN認証を行ってきました。今回のアップデートで、MediaPackage v2においてX-MediaPackageV2-CDNIdentifierという認証用カスタムHTTPヘッダを正式にサポートしました。従来まではUser-Agent Headerなどで代用するしかなかったのですが、認証用ヘッダが利用できることは嬉しいですよね。また認証コードはMediaPackage v1のときと同様にSecrets Managerにシークレットとして保存します。従来まではEndpoint policyで直接認証コードを埋め込むかたちしか取れなかったので、こちらも嬉しいポイントです。なお、静的なHTTPヘッダの値を用いたCDN認証自体はこれまでも（先述の通り、MediaPackage v2リリース時の段階から）実現自体はできていたので、本エントリでは「正式にサポートした」という表現を用いています。

MediaPackage v2でStatic Headerを使ったCDN認証をやってみた

MediaPackageとCDN認証について振り返りつつ、今回のアップデートであるMediaPackage v2のStatic Header CDN認証のうまみが確認できたところで、実際のこの機能を使ってみたいと思います。

MediaPackage v2 User GuideのSecure MediaPackage content with CDN authorizationの項目を参考にしながら進めました。

認証コードの作成

まずは認証に使うコードを作成します。UUID version4を利用することが推奨されているので、CloudShell上から以下コマンドを実行して作成しました。

CloudShellにて実行
[cloudshell-user@ip-10-133-68-84 ~]$ cat /proc/sys/kernel/random/uuid
0404fdab-b3a4-4518-a2e8-76157df2e38f

本エントリではこの0404fdab-b3a4-4518-a2e8-76157df2e38fを認証コードとして使用します。

認証コードをSecrets Managerに保存

続いて、作成した認証コードをSecrets Managerにシークレットして保存します。MediaPackage側では認証コードの値をこのシークレットで確認します。

Secrets Managerのマネジメントコンソール、Secrets一覧画面から (Store a new secrets) ボタンで進みます。Secret typeではOther type of secretを選択、Key/value pairsのKey（左側）にMediaPackageV2CDNIdentifier、Value（右側）に認証コード0404fdab-b3a4-4518-a2e8-76157df2e38fを入力します。Encryption keyはデフォルトのaws/secretsmanagerで進めました。

mc02

(Next) ボタンで次ページに進みます。Secret nameはプレフィックスにMediaPackageV2/を付与してMediaPackageV2/CDNAuthTestとしました。Descriptionも適切に設定します。

mc03

(Next) ボタンで次ページに進むと、自動ローテーション構成画面になります。自動ローテーションについては設定せず、そのまま (Next) ボタンで進みます。

mc04

Review画面の内容を確認して、(Store) でシークレットを保存します。

mc05
mc06

シークレット保存後、詳細ページにてSecret ARNを確認しておきます。ここではarn:aws:secretsmanager:ap-northeast-1:123456789012:secret:MediaPackageV2/CDNAuthTest-QsXXreですね。

mc07

以上で認証コードのSecrets Managerへの保存は完了です。

MediaPackage v2がSecrets ManagerにアクセスするためのIAMロールの作成

認証コードのSecrets Managerへの保存ができたら、次にMediaPackage v2がこのSecrets Managerのシークレットへアクセスできるよう、IAMロールを作成します。MediaPackage v2のCDN認証機能の設定時に、このIAMロールを指定します。なお、MediaPackage v1のCDN認証の際に使用するIAMロールとの互換性はないようです。MediaPackage v2用に新規に作成しましょう。

MediaPackage v2のUser Guide、Allowing MediaPackage to access other AWS servicesのページを参考に進めていきます。

まずはIAMポリシーの作成です。ポリシーの内容についてはUser Guideの参考ページ、Step 1: Create a policyのSecrets Manager and AWS KMS access for CDN authorizationを踏襲します。IAMのマネジメントコンソール、Policiesの一覧ページから (Create policy) ボタンを押下します。Policy editorでJSONを選択し、以下の内容の[Secret ARN]と[KMS Key ARN]をそれぞれ書き換えた上で入力します。

{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "secretsmanager:GetSecretValue",
                "secretsmanager:DescribeSecret"
            ],
            "Resource": "[Secret ARN]"
        },
        {
            "Effect": "Allow",
            "Action": [
                "secretsmanager:BatchGetSecretValue"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "kms:Decrypt",
                "kms:DescribeKey"
            ],
            "Resource": "[KMS Key ARN]"
        }
    ]
}

[Secret ARN]は先ほど作成した、認証コードを保存したシークレットのARNになります。Secrets Managerのマネジメントコンソールから確認できます。

mc08

[KMS Key ARN]はこのシークレットのEncryption keyを指定します。今回、上記Secrets Managerのマネジメントコンソール画面ではaws/secretsmanagerと表示されています。こちらはエイリアス名となりIAMポリシーステートメントでは指定できないので、KMSのマネジメントコンソールからキー自体のARNを確認しました。AWS managed keysからAliasがaws/secretsmanagerのものを探し、詳細ページ進みます。以下画面のARNが[KMS Key ARN]に該当しますね。

mc09

ポリシー編集画面で以下のように入力して、 (Next) ボタンで次ページに進みます。

mc10

Review and create画面でPolicy nameとDescriptionを適切に設定します。Permissionについても確認し、 (Create policy) ボタンを押下してIAMポリシーを作成します。

mc11

続いて、このIAMポリシーをアタッチするIAMロールを作成します。IAMロール一覧画面から (Create role) ボタンで進みます。Trusted entity typeではAWS Serviceを選択、User caseでは いったん EC2を選択します。（のちほど、信頼関係を編集してMediaPackage v2用に設定します。）

mc12

Add permissionsで先ほど作成したIAMポリシーを選択します。

mc13

Name, review, and create画面でRole nameとDescriptionを適切に設定します。内容を確認して左下 (Create role) ボタンでIAMロールを作成します。

mc14

IAMロールを作成したあと、作成したIAMロール詳細画面に進みます。Trusted entitiesのタブを選択し、 (Edit trust policy)ボタンを押下します。

mc15

Trusted policyの内容として、編集前は以下のようになっています。

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Principal": {
				"Service": "ec2.amazonaws.com"
			},
			"Action": "sts:AssumeRole"
		}
	]
}

"Service": "ec2.amazonaws.com"の箇所を"Service": "mediapackagev2.amazonaws.com"に書き換えます。以下のようになりますね。

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Principal": {
				"Service": "mediapackagev2.amazonaws.com"
			},
			"Action": "sts:AssumeRole"
		}
	]
}

左下の (Update policy) ボタンを押下してTrusted policyの変更を更新します。

mc16
mc17

以上でMediaPackage v2がSecrets ManagerにアクセスするためのIAMロールの作成は完了です。最後に上記ページのARN（このIAMロールのARN、ここではarn:aws:iam::123456789012:role/MediaPackageV2CDNAuthRole）については、後ほどMediaPackage v2のCDN認証設定の際に使用するので控えておきましょう。

CDN認証を有効にしたMediaPackage v2リソースの作成

続いて、今回のアップデートの主役となるMediaPackage v2リソースの作成に入ります。マネジメントコンソールでMediaPackage v2のChannel gropus一覧画面に進みます。

Channel gropuについては以下エントリで作成したものを使用しました。設定の詳細は割愛しますが、Channel group nameとDescriptionのみ設定したものです。（必要に応じてMediaPackage v2のアクセスログを有効にしておきましょう。）

該当Channel gropuの詳細画面に進み、 (Create channel) ボタン押下でChannelを作成するところから進めます。NameとDescriptionを適切に設定します。Input typeはCMAFを選択しました。MQCSやPreferred inputの項目はデフォルトの（いずれもチェックをしない）状態のまま進めます。Channel policyについてもデフォルトのDon't attach a policyで進めました。

mc18

Channelが作成できたら、続いて (Create endpoint) ボタンからOrigin endpointの作成に進みます。NameとDescriptionを適切に入力、Container typeはTSを選択しました。Endpoint settingsのAdditional settingsやSegment settingsの項目、Encryptionの項目はデフォルトのまま進めます。

mc19

Endpoint policyの項目ではAttach a custom policyを選択します。ポリシー内容についてはUser Guideの参考ページにならい、以下内容を入力しました。（"Resource"の値は作成しているChannelのARNが入ります。いちどAttach a public policyを選択して"Resource"の内容をコピーしてしまうのがやりやすいかと思いました。）

{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "AllowGetObjectAccessForAuthorizedRequest",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "mediapackagev2:GetObject",
      "Resource": "arn:aws:mediapackagev2:ap-northeast-1:123456789012:channelGroup/mediapackage-v2-channel-group/channel/mediapackage-v2-cdn-authentication-channel/originEndpoint/cnd-authentication-endpoint",
      "Condition": {
        "Bool": {
          "mediapackagev2:RequestHasMatchingCdnAuthHeader": "true"
        }
      }
    }
  ]
}

CDN identifier secret role ARNでは先ほど作成したMediaPackage v2がSecrets ManagerにアクセスするためのIAMロールARNを入力、またCDN identifier secret ARNには認証コードを保存したシークレットのARNを入力します。

mc20

Manifest definitionsではHLS manifestを追加、各値はいずれもデフォルトのものを使いました。

mc21

(Create) ボタンでOrigin endpointリソースを作成します。

mc23

Origin endpoint作成後にPolicyタグを確認すると、CDN authorization configurationの項目に設定したSecrets role ARNとSecret ARNが確認できますね。

mc22

認証コードをStatic Headerとしてオリジンに送信するCloudFrontを作成

CDN認証を有効にしたMediaPackage v2リソースが作成できました。続いてCDN側リソースとなるCloudFrontを作成していきます。

なお先述の通り、MediaPackageをオリジンとしてCDNにCloudFrontを利用するのであれば、Origin Access Control （OAC）を利用することがベストな選択肢です。今回はあくまで動作検証用途として、認証コードをStatic Headerとしてオリジンに送信してCDN認証を行うCloudFrontリソースを作成します。

なお、MediaPackage v2でのCDN利用についてはUser Guideの以下などに注意点などの記載があります。

今回はCDN認証の検証が目的ですので、コンテンツのキャッシュは行わず、またHost header以外をオリジンに転送する設定としました。本番環境で利用する際は適切な設定を行いましょう。

CloudFrontのマネジメントコンソール、 (Create distribution)ボタンから進みます。従来のCreate Distribution pageとも間もなくお別れなのか、などと感慨深くなりながら、新しいインターフェースで進めます。Distribution nameとDescriptionを適切に設定し、Distribution typeはSingle website or appを選択します。Route 53 managed domainは空欄で(Next)ボタンを押下します。

mc24

Step 2 Specify originのページです。Origin typeについてはElemental MediaPackageを選択することもできますが、今回はあえてOtherを指定してオリジンのドメイン名を直接入力するかたちを採ってみました。

mc25

OriginのCustom origin欄に先ほど作成したCDN認証を有効にしたMediaPackage v2リソースのOrigin endpoint、HLS manifest definitionsのURLをからドメイン部分を抜粋して入力します。MediaPackageのマネジメントコンソールでいうと以下の箇所ですね。

mc26

URLは以下の内容となっています。

  • https://yxxxxx.egress.dxxxxx.mediapackagev2.ap-northeast-1.amazonaws.com/out/v1/mediapackage-v2-channel-group/mediapackage-v2-cdn-authentication-channel/cnd-authentication-endpoint/index.m3u8

このうち、冒頭のドメイン部分yxxxxx.egress.dxxxxx.mediapackagev2.ap-northeast-1.amazonaws.comをCustom originの欄に入力するかたちです。Origin pathについては空欄で進めました。

mc27

Origin settingsではCustom origin settingsを選択、Add custom headerの項目で(Add heaader)ボタンを押下、追加のカスタムヘッダとしてHeader name: X-MediaPackageV2-CDNIdentifier、Value: 認証コード （今回であれば0404fdab-b3a4-4518-a2e8-76157df2e38f）を入力します。その他の項目ではデフォルトのまま進めました。

mc28

Cache settingsについてもCustom cache settingsを選択します。Cache policyはCachingDisabledとしました。動作検証用途のキャッシュを行わない設定ですね。またOrigin request policyではAllViewerExceptHostHeaderを選択します。その他の項目はデフォルトで(Next)ボタンを押下します。

mc29

Enable securityの項目についてはDo not enable security protectionsを選択して(Next)で進みます。

mc30

最後のStep 4 Review and createの画面で内容を確認して(Create distribution)ボタンでCloudFrontディストリビューションを作成します。

mc31

ディストリビューションが作成されDeployingされました。取り急ぎ、Distribution domain nameを確認しておきましょう。

mc32

先ほど確認したCDN認証を有効にしたMediaPackage v2リソースのOrigin endpoint、HLS manifest definitionsのURLのドメイン部分をこのCloudFrontディストリビューションのドメイン名に変更し、CloudFront経由でのEndpoint URLを準備しておきます。

  • https://dt3xxxxxxxxxx.cloudfront.net/out/v1/mediapackage-v2-channel-group/mediapackage-v2-cdn-authentication-channel/cnd-authentication-endpoint/index.m3u8

動作確認用のMediaLiveリソースの作成と配信準備

CDN認証を有効にしたMediaPackage v2ならびにCloudFrontリソースの準備ができました。実際にライブ動画配信を行いながらCDN認証の確認をするため、MediaPackage v2に映像を送信するMediaLiveリソースを作成します。

MediaLiveのマネジメントコンソールから、まずはInputリソースを作成します。Input typeはRTMP (push)、Input classはSINGLE_INPUTとしました。

mc33

続いてChannelリソースの作成です。[Create channel]ボタンから進み、まずは以下のChannel templateをcustom templateとして読み込みました。MediaLiveがMediaPackage v2 endpointをサポートした際に検証したブログエントリで作成したものです。GitHub Gistにて公開しています。

medialive-cmaf-ingest-mediapackage-output-channel-template.json

ついでChannel nameやIAM roleを適切に設定します。Channel classはSINGLE_PIPELINEとしました。

mc34

Input attachmentsで作成済みのInputをアタッチします。Output groupsのcmaf-ingest-mediapackage-output (MediaPackage)に進み、MediaPackage destinationのMediaPackage channel group name、ならびにMediaPackage channel nameでCDN認証を有効にしたMediaPackage v2リソースを指定します。

mc35

[Create channel]ボタンを押下してChannelを作成、リソース作成完了後に[Start]ボタンを押してChannelをRunning状態にしておきます。

MediaLiveに映像を打ち上げるStreaming SoftwareにはOBS Studioを利用しました。ソースとしてメディアソースを作成、ローカルに保存してあるBig Buck Bunnyの動画ファイルをループ再生しておきます。OBS Studio側で[配信開始]ボタンを押下、映像がMediaLiveまで届いていることをマネジメントコンソールのPreview画面で確認しておきましょう。

mc36
mc37

Static HeaderによるCDN認証の確認

MediaLiveからMediaPackageに映像を送信している状態で、実際にStatic HeaderによるCDN認証が動作しているか確認していきます。

MediaPackageのマネジメントコンソール、Endpoint詳細画面のManifest settingsタブ、(Preview)ボタンを押下するとhls.js demoページに遷移し、CDN認証などを行っていない状態であればここでMediaPackageに届いている動画が視聴できます。

mc39

CDN認証を設定した状態だと、このhls.js demoのPreviewページでは動画は視聴できません。Errorの項目にも記載がありますが、マニフェストファイルが読み込めない状況です。

mc38

curlコマンドでHLS manifest definitionsのURLを叩いてみると、以下のようにHTTPステータスコード403が返ってきていることがわかりますね。

% curl -i https://yxxxxx.egress.dxxxxx.mediapackagev2.ap-northeast-1.amazonaws.com/out/v1/mediapackage-v2-channel-group/mediapackage-v2-cdn-authentication-channel/cnd-authentication-endpoint/index.m3u8
HTTP/2 403
date: Fri, 31 Oct 2025 12:36:19 GMT
content-type: application/json
content-length: 28
x-amzn-requestid: 28ca905b-f098-4a12-ae4b-4f4bc84c7d1b
access-control-allow-origin: *
x-amzn-errortype: AccessDeniedException
vary: Origin
access-control-expose-headers: x-amzn-requestid,x-amzn-errortype,x-amzn-mediapackage-last-sequence,x-amzn-mediapackage-last-updated,Content-Encoding,Date
access-control-allow-credentials: true

{"Message":"Access denied."}

MediaPackage v2リソース作成時に、Endpoint policyで認証済みのリクエストのみを許可したため、このようなCDN認証のないリクエストについてはアクセスが拒否される状況です。

続いて、CDN認証を使ったリクエスト、Static Headerを付与するよう設定したCloudFront経由でアクセスしてみます。CloudFrontディストリビューション作成時に確認した、ドメイン部分をCloudFrontのものに置き換えたEndpoint URLをhls.js demoページのURL欄に入力、[Apply]ボタンを押下します。CloudFront経由では動画が視聴できましたね。

mc40

curlコマンドでも確認してみましょう、HTTPステータスコードとして200が返ってきていますね。

% curl -i https://dt3xxxxxxxxxx.cloudfront.net/out/v1/mediapackage-v2-channel-group/mediapackage-v2-cdn-authentication-channel/cnd-authentication-endpoint/index.m3u8
HTTP/2 200
content-type: application/vnd.apple.mpegurl
content-length: 501
date: Fri, 31 Oct 2025 12:41:38 GMT
access-control-allow-credentials: true
x-amzn-requestid: 30xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx4c
cmsd-static: n="MediaPackage:ap-northeast-1:mediapackage-v2-channel-group:mediapackage-v2-cdn-authentication-channel:cnd-authentication-endpoint",st=l,sf=(h),ot=m
x-amzn-mediapackage-endpoint-id: cnd-authentication-endpoint
access-control-allow-origin: *
x-amzn-mediapackage-channel-uniqueid: fbxxxxxxxxxxxxxxxxxxxxxxxxxxxx63
x-amzn-mediapackage-endpoint-uniqueid: 7fxxxxxxxxxxxxxxxxxxxxxxxxxxxxba
vary: Origin
cache-control: max-age=3
access-control-expose-headers: x-amzn-requestid,x-amzn-errortype,x-amzn-mediapackage-last-sequence,x-amzn-mediapackage-last-updated,Content-Encoding,Date
x-amzn-mediapackage-active-input: 1
x-amzn-mediapackage-channel-id: mediapackage-v2-cdn-authentication-channel
x-cache: Miss from cloudfront
via: 1.1 71xxxxxxxxxxxxxxxxxxxxxxxxxxxx66.cloudfront.net (CloudFront)
x-amz-cf-pop: NRT12-P6
x-amz-cf-id: kxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx==

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-INDEPENDENT-SEGMENTS
#EXT-X-STREAM-INF:CODECS="avc1.640028,mp4a.40.2",AVERAGE-BANDWIDTH=5500000,RESOLUTION=1920x1080,VIDEO-RANGE=SDR,FRAME-RATE=29.97,BANDWIDTH=5720000
variant_video_1080p30.m3u8
#EXT-X-STREAM-INF:CODECS="avc1.64001F,mp4a.40.2",AVERAGE-BANDWIDTH=3300000,RESOLUTION=1280x720,VIDEO-RANGE=SDR,FRAME-RATE=29.97,BANDWIDTH=3432000
variant_video_720p30.m3u8
#EXT-X-STREAM-INF:CODECS="mp4a.40.2",AVERAGE-BANDWIDTH=120000,BANDWIDTH=120000
variant_audio_aac.m3u8

このMediaPackage v2のStatic Headerを用いたCDN認証ですが、動作的にはMediaPackageのOrigin endpointアクセス時にX-MediaPackageV2-CDNIdentifierヘッダがあるか、またその値は正しいものか（シークレットに保存されているものと一致するか）をチェックするというものです。CDN（今回でいえばCloudFront）経由でなくても、ヘッダを付与することでリクエストは成功します。具体的にcurlコマンドで確認してみましょう、MediaPackgeへ直接のアクセス、先ほど403が返ってきたURLと同一ですが、-Hオプションでリクエストヘッダを付与しています。ヘッダ名はX-MediaPackageV2-CDNIdentifier、ヘッダの値は認証コードである0404fdab-b3a4-4518-a2e8-76157df2e38fですね。HTTPステータスコード200が返り、マニフェストファイルの中身も確認できます。

% curl -i \
  -H "X-MediaPackageV2-CDNIdentifier:0404fdab-b3a4-4518-a2e8-76157df2e38f" \
  https://yxxxxx.egress.dxxxxx.mediapackagev2.ap-northeast-1.amazonaws.com/out/v1/mediapackage-v2-channel-group/mediapackage-v2-cdn-authentication-channel/cnd-authentication-endpoint/index.m3u8

HTTP/2 200
date: Fri, 31 Oct 2025 12:53:45 GMT
content-type: application/vnd.apple.mpegurl
content-length: 501
x-amzn-requestid: 87xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx76
cmsd-static: n="MediaPackage:ap-northeast-1:mediapackage-v2-channel-group:mediapackage-v2-cdn-authentication-channel:cnd-authentication-endpoint",st=l,sf=(h),ot=m
x-amzn-mediapackage-endpoint-id: cnd-authentication-endpoint
access-control-allow-origin: *
x-amzn-mediapackage-channel-uniqueid: fbxxxxxxxxxxxxxxxxxxxxxxxxxxxx63
x-amzn-mediapackage-endpoint-uniqueid: 7fxxxxxxxxxxxxxxxxxxxxxxxxxxxxba
vary: Origin
cache-control: max-age=3
access-control-expose-headers: x-amzn-requestid,x-amzn-errortype,x-amzn-mediapackage-last-sequence,x-amzn-mediapackage-last-updated,Content-Encoding,Date
x-amzn-mediapackage-active-input: 1
x-amzn-mediapackage-channel-id: mediapackage-v2-cdn-authentication-channel
access-control-allow-credentials: true

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-INDEPENDENT-SEGMENTS
#EXT-X-STREAM-INF:CODECS="avc1.640028,mp4a.40.2",AVERAGE-BANDWIDTH=5500000,RESOLUTION=1920x1080,VIDEO-RANGE=SDR,FRAME-RATE=29.97,BANDWIDTH=5720000
variant_video_1080p30.m3u8
#EXT-X-STREAM-INF:CODECS="avc1.64001F,mp4a.40.2",AVERAGE-BANDWIDTH=3300000,RESOLUTION=1280x720,VIDEO-RANGE=SDR,FRAME-RATE=29.97,BANDWIDTH=3432000
variant_video_720p30.m3u8
#EXT-X-STREAM-INF:CODECS="mp4a.40.2",AVERAGE-BANDWIDTH=120000,BANDWIDTH=120000
variant_audio_aac.m3u8

まとめ

AWS Elemental MediaPackage v2で正式にサポートされていたStatic Headerについて実際に設定、動作を確認してみました。MediaPackage v1のCDN認証と同様、認証用のヘッダと認証コードを用いてアクセスを制御します。認証コードをSecrets Managerへ登録するところはv1のCDN認証と同じですが、認証用ヘッダがX-MediaPackage-CDNIdentifierとX-MediaPackageV2-CDNIdentifierというように微妙に違う点、またv2ではMediaPackageのEndpoint policyでアクセス制御を設定する点に留意しましょう。特に後者のPolicyを使用する点は、CDN認証を設定しつつ特定のIPアドレスからは認証用ヘッダがなくてもアクセスを許可する、といったより柔軟なアクセス制御が実現でき、MediaPackage v2のメリットかと考えます。

なお、本文中でも何度か触れていますがMediaPackage v2をオリジンとしてCDNにCloudFrontを利用するのであれば、Origin Access Control （OAC）を利用するのがベストプラクティスです。CDN認証は使うべきではありません。CloudFront以外のCDNを利用する場合の手段として活用していきましょう。

この記事をシェアする

FacebookHatena blogX

関連記事

MediaLiveに打ち上げた映像からなるべく正確な時刻で動画クリップを切り出す - Harvest Job活用編 -
清水俊也
2025.08.31
[UPDATE] AWS Elemental MediaLiveがMediaPackage v2 endpointをサポートしました！
清水俊也
2024.12.31
[NEW] AWSを使ったライブ動画配信でメディアの品質を考慮した障害対応ができるようになりました！ [Media Quality-Aware Resiliency]
清水俊也
2024.11.29
[UPDATE] AWS Elemental MediaPackage v2でアクセスログがサポートされました！
清水俊也
2024.11.28