AWS Elemental MediaConvertで出力されるS3オブジェクトにJob IDを示すメタデータが付与されるようになっていました
はじめに
清水です。先日MediaConvertに関するブログエントリを執筆していた際、その出力である変換後の動画ファイル(S3に格納されているオブジェクト)を確認していると見慣れないメタデータが付与されていることに気が付きました。どうやらMediaConvertのJobによって出力されたS3上のオブジェクトには、そのJob IDがメタデータとして付与されるようになっていたようです。本エントリではMediaConvertによって出力されたS3オブジェクトに付与されたメタデータ、x-amz-meta-mediaconvert-jobid
について確認してみたのでまとめてみたいと思います。
見慣れぬメタデータ「x-amz-meta-mediaconvert-jobid」
それはAWS Elemental MediaConvertで音量正規化の検証をしていたときの出来事でした。
MediaConvertで変換後の動画ファイル、つまりS3バケット上のオブジェクトをAWSマネジメントコンソールから確認します。CRC64NVME checksumについては割と最近のアップデートだけど、そのほかは見慣れた項目だよな、などと眺めていると、ふとMetadataの箇所に目が留まりました。x-amz-meta-mediaconvert-jobid
とはなんでしょうか!?
ユーザ定義のメタデータですが、私が自分で付与した記憶はありません。名称x-amz-meta-mediaconvert-jobid
から、MediaConvertのJob IDというように読み取れます。(なお、S3のユーザ定義のオブジェクトメタデータはx-amz-meta-
ではじめるよう、S3 User Guideに記載があります。)
このMP4動画ファイルはMediaConvertで変換出力したものなので、名称から推測できるメタデータの意味、MediaConvertのJob IDを示している、という推測は正しそうです。実際にこの動画を出力したMediaConvertのJobを確認してみると、そのIDはS3オブジェクトに付与されているメタデータx-amz-meta-mediaconvert-jobid
の値と同一の1750XXXX8410-k9yijm
というものでした。
名称のとおりではありますが、MediaConvertのJob IDがS3オブジェクトのメタデータとして付与されるようになったようです。
いつからx-amz-meta-mediaconvert-jobidは付与されるようになったのか
MediaConvertで出力したS3オブジェクトにx-amz-meta-mediaconvert-jobid
のメタデータが付与されていること、またこのメタデータの値が実際のMediaConvertのJob IDと一致することを確認しました。最近MediaConvertにこんなアップデートあったかな、と、"x-amz-meta-mediaconvert-jobid"
でGoogle検索してみます。しかし、アップデート情報やAWSの公式情報は見つかりません。
見つかったのは自分が書いたブログエントリ、もしくはHTTPレスポンスヘッダを収集しているようなサイトでした。
改めて自分が書いたブログエントリを確認してみます。2024年5月に執筆した以下のブログエントリですね。
内容はMediaConvertやx-amz-meta-mediaconvert-jobid
のメタデータと直接関連はありませんが、MediaConvertで変換した動画のS3オブジェクトにHTTPアクセスした際、そのレスポンスヘッダ情報にx-amz-meta-mediaconvert-jobid
のメタデータが付与されていることを確認しています。
引用元: MediaTailor Ad insertionで広告付きVOD動画配信をやってみた [2024初夏編] | DevelopersIO
このブログエントリ執筆の時点、2024/05/30の段階でMediaConvertで出力されるファイルにはx-amz-meta-mediaconvert-jobid
のメタデータが付与されていた、ということになります。
では、具体的にいつごろからメタデータx-amz-meta-mediaconvert-jobid
は付与されるようになったのか確認するべく、さらに過去のブログエントリやS3バケット内のKey名称などをもとにMediaConvertで出力したであろういくつかのS3オブジェクトを確認してみます。
2023年11月の時点、具体的には以下のブログエントリの検証を行った際には、まだMediaConvertで出力されたファイルにx-amz-meta-mediaconvert-jobid
のメタデータは付与されていませんでした。
実際のS3オブジェクトの情報を抜粋すると以下となります。Metadata欄にはContent-Type
しかありませんね。
そして2024年4月、以下ブログエントリの検証で扱ったMediaConvertの出力したS3オブジェクトにはx-amz-meta-mediaconvert-jobid
のメタデータが付与されていました。
こちらも実際にS3オブジェクトの情報を抜粋すると以下になります。なお、ブログエントリの公開のタイミングは2024/04/02でしたが、検証(MediaConvertのJob実行)自体は2024/03/31に行っていました。
なお、上記はHLSへの変換結果のうちのm3u8ファイルですが、当然tsファイルにもx-amz-meta-mediaconvert-jobid
のメタデータは付与されています。
2023年11月以降、2024年3月末のどこかのタイミングで、MediaConvertが動画変換結果として出力したS3オブジェクトにはx-amz-meta-mediaconvert-jobid
のメタデータが付与されるようになったようです。
なお、この2023年11月から2024年3月末というタイミングですが、以下のアップデートがあったと推測される時期とも重なります。
もしかしたら、このMediaConvertのアカウント固有のエンドポイントが不要になったことと関係があるのかな、と(タイミングしか根拠はないのですが)個人的に推測しています。
x-amz-meta-mediaconvert-jobidは動画ファイル以外にも付与されているのか
遅くとも2024年3月末ごろには、MediaConvertで変換した動画ファイルにx-amz-meta-mediaconvert-jobid
のメタデータが付与されるようになっていたことが確認できました。
なお「動画ファイル」と記しましたが、上記で確認した通り変換後のHLSアセットうち、実際の動画データが含まれる拡張子tsのセグメントファイルのほか、中身はテキストファイルである拡張子m3u8のインデックスファイルにもx-amz-meta-mediaconvert-jobid
のメタデータが付与されていましたね。
さて、MediaConvertはこのような動画ファイルないし動画アセットのほか、メトリックレポートや音量正規化時のログファイルなどもS3に出力します。これらファイルについても同様にメタデータが付与されているのか、確認してみます。
まずはメトリックレポートです。2025年5月にアップデートされた機能ですね。
上記ブログエントリ執筆の際の検証で実際に出力したメトリックレポートのCSVファイルを確認してみました。メタデータにx-amz-meta-mediaconvert-jobid
がありますね。もちろん、出力動画本体のx-amz-meta-mediaconvert-jobid
の値や、実際のMediaConvertのJob IDとも一致します。
続いて音量正規化の際、Loudness loggingを有効化することで出力されるログファイルの確認です。以下ブログエントリ執筆時に検証したMediaConertの出力ファイルを確認しました。
loudnessのログファイルについてもx-amz-meta-mediaconvert-jobid
のメタデータが付与されていました。
すべての種類のファイルは確認できていませんが、MediaConvertからS3に出力される各種ファイルについて、そのJob IDがメタデータx-amz-meta-mediaconvert-jobid
の値として付与される、と言えるかと思います。
動画配信時にx-amz-meta-mediaconvert-jobidを削除する
いつの間にやらMediaConvertのJobにより出力されたS3オブジェクトにx-amz-meta-mediaconvert-jobid
というJob IDを示すメタデータが付与されていることを確認してきました。
さて、このS3上のオブジェクトに付与されているメタデータですが、これまで確認してきたようにAWSマネジメントコンソール上から確認できるほか、HTTPでアクセスした場合にはそのレスポンスヘッダのひとつとしても確認することができます。
% curl -I https://my-s3-bucket.s3.ap-northeast-1.amazonaws.com/mediaconvert-audio-normalization/IMG_0866-targetlkfs-24.mp4
HTTP/1.1 200 OK
x-amz-id-2: KrgtxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxKeN9
x-amz-request-id: R4P9XXXXXXXX951Y
Date: Fri, 27 Jun 2025 03:56:15 GMT
Last-Modified: Tue, 24 Jun 2025 02:01:39 GMT
ETag: "2b44XXXXXXXXXXXXXXXXXXXXXXXXe5b8-2"
x-amz-server-side-encryption: AES256
x-amz-meta-mediaconvert-jobid: 1750XXXX58410-k9yijm
Accept-Ranges: bytes
Content-Type: video/mp4
Content-Length: 22667773
Server: AmazonS3
レスポンスヘッダの1つとして、x-amz-meta-mediaconvert-jobid: 1750XXXX58410-k9yijm
がありますね。ここで考慮が必要な点として、このメタデータx-amz-meta-mediaconvert-jobid
は公開するべきか否かということが挙げられます。
確認してきた通り、メタデータのx-amz-meta-mediaconvert-jobid
の値はMediaConvertのJob IDを示しています。MediaConvertのJob IDがわかると、Job情報が参照できれば、そのJobの詳細、どんなコーデックや解像度、ビットレートなどで変換したかを確認することができます。しかし通常はJob IDがわかったとしても、Job情報の参照は権限がなければできません。Job IDを公開したとしても、直接的なセキュリティリスクがあるとは言い切れないかと考えます。
しかし、実行したJobを特定するユニークな情報となります。なるべくなら配信時に消しておきたい、という要望もあるかと考えます。(本ブログエントリでも、念のため値の一部をマスクしています。)実現方法は色々と考えられますが、CloudFront + S3の構成でVOD動画配信を行っている、というパターンであれば、現実的な方法の1つはCloudFrontのResponse headers policyを利用したレスポンスヘッダーの削除かと考えます。
以下、この方法について具体的に確認していきましょう。より実際のVOD動画配信に近いかたちということで、HLSアセットのインデックスファイルの配信を例にします。MediaConvertの出力先S3バケットをオリジンとしたCloudFrontディストリビューションを作成します。特に何も意識しないとm3u8ファイルを取得した際のレスポンスヘッダは以下のようになりますね。
% curl -I https://d2xxxxxxxxvhbu.cloudfront.net/mediaconvert-output/202501/inokashira-line.m3u8
HTTP/2 200
content-type: application/vnd.apple.mpegurl
content-length: 369
date: Wed, 02 Jul 2025 08:20:54 GMT
last-modified: Thu, 09 Jan 2025 08:22:41 GMT
etag: "cc01xxxxxxxxxxxxxxxxxxxxxxxxc26c"
x-amz-server-side-encryption: AES256
x-amz-meta-mediaconvert-jobid: 1736XXXX47926-zna03b
accept-ranges: bytes
server: AmazonS3
x-cache: Miss from cloudfront
via: 1.1 307bxxxxxxxxxxxxxxxxxxxxxxxx6550.cloudfront.net (CloudFront)
x-amz-cf-pop: NRT57-P10
x-amz-cf-id: KESwxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx0w==
レスポンスヘッダx-amz-meta-mediaconvert-jobid
に対して、その値としてMediaConvertのJob ID 1736XXXX47926-zna03b
が返されています。
このレスポンスヘッダをCloudFrontで削除するべく、Response headers policyを作成してBehaviorに関連付けていきましょう。CloudFrnotのマネジメントコンソール、Policiesの画面でResponse headersの項目から (Create response headers policy) ボタンを押下します。NameとDescriptionを適切に設定し、Remove headersの項目で (Add header)ボタンを押下、Nameの項目にx-amz-meta-mediaconvert-jobid
を入力してResponse headers policyを作成します。(なお今回は設定していませんが、CORSまわりをResponse headers policyで対応するのもよい方法ですよね。)
作成したResponse haders policyを該当するCloudFrontディストリビューションのBehaviorに関連付けます。
再度、m3u8ファイルを取得時のレスポンスヘッダを確認してみましょう。x-amz-meta-mediaconvert-jobid
ヘッダが削除されていますね。
% curl -I https://d2xxxxxxxxvhbu.cloudfront.net/mediaconvert-output/202501/inokashira-line.m3u8
HTTP/2 200
content-type: application/vnd.apple.mpegurl
content-length: 369
date: Wed, 02 Jul 2025 08:20:54 GMT
last-modified: Thu, 09 Jan 2025 08:22:41 GMT
etag: "cc01xxxxxxxxxxxxxxxxxxxxxxxxc26c"
x-amz-server-side-encryption: AES256
accept-ranges: bytes
server: AmazonS3
x-cache: Hit from cloudfront
via: 1.1 ed37xxxxxxxxxxxxxxxxxxxxxxxxb832.cloudfront.net (CloudFront)
x-amz-cf-pop: NRT57-P10
x-amz-cf-id: mVq-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxeQ==
age: 163
まとめ
AWS Elemental MediaConvertで出力されるS3オブジェクトに、いつの間にやらメタデータx-amz-meta-mediaconvert-jobid
が付与され、その値からMediaConvertのJob IDが確認できるようになっていました。動画ファイルがMediaConvertで出力したものなのかどうかの確認が容易にできますね。また個人的には、MediaConvertで複数のパラメータでJobを作成し比較検証している際などに、変換後の動画ファイルがどのJobで出力されたものなの確認が容易になるところが嬉しいポイントです。(Jobを複製してパラメータを微調整、Destinationを変更せずに出力を上書きしてしまった、なんてときにもJobが特定できそうです……。)注意事項としては本文中でも述べた、ユニークな情報であるJob IDの扱いでしょうか。直接的なセキュリティ上の懸念はないかと考えますが、動画配信時に参照できないようにしたいといった場合にはメタデータやレスポンスヘッダの削除を検討しましょう。