Azure Media Services
Azure Media Servicesは2024年6月30日に退役済み。Storage上に残る媒体を保全し、エンコード・ライブ・配信・DRMをパートナー製品または自社構成へ分解して再構築する。
- Azure Media Servicesは2024年6月30日に退役し、現在は利用できない。
- 媒体ファイルはStorageに残るが、配信URL・ライブ・資産メタデータは削除済み。
- 機能別に代替を選び、プレーヤー・URL・鍵・監視を作り直す。
解決する課題
Azure Media Services(AMS)は、ファイル変換、ライブ処理、HLS・DASH配信、DRMをまとめて提供していました。2024年6月30日に退役し、現在は新規作成も既存API操作もできません。Microsoftは単一の直接後継を提供せず、公式退役ガイドでパートナー製品または他のAzure資源への分解移行を案内しました。
退役時はストリーミング端点とライブイベントが停止し、アカウントは約90日だけ読取専用になった後に削除されました。2026年時点でAMSの資産、変換、配信URL、ライブ、DRM設定をAPIから回収できる前提は置けません。
主要概念と用語
- 媒体ファイル: MP4、ISM、HLS/DASH断片など、顧客のAzure Storageに保存された実データ。AMS退役後もStorage側に残る
- AMS管理情報: 資産メタデータ、変換、ジョブ、配信ロケーター、ストリーミング端点、ライブイベント。退役処理で削除された
- 機能別移行: エンコード、ライブ、配信元、CDN、DRM、分析を別製品へ分けること
- パートナー製品: 公式ガイドが案内したBitmovin、MediaKind、Ravnurなど。現在の提供地域・契約・移行可否は各社で再確認する
- 静的移行: 既存媒体をHLS/DASHとしてStorageから直接配る形へ変換する旧移行手段。URLとプレーヤーの更新、CDN、必要なら鍵配信が別途必要
仕様・制限・クォータ
- 退役日は2024年6月30日。v2・v3 APIとAzure Media Playerも同日に終了した
- 顧客の媒体ファイルは紐づくStorageに残るが、AMSアカウント情報は停止後約90日で削除された
- 既存媒体があるだけでは、旧配信URL、動的包装、ライブ処理、DRM鍵配信は復元されない
- Microsoft管理の直接後継エンコーダはない。パートナー製品またはVM・AKS等でFFmpegなどを運用する
- Azure Video Indexerは映像・音声分析の移行先であり、エンコード・ライブ・配信・DRMの後継ではない
内部の仕組み
横にスクロール
旧AMSでは、Storage上の入力を変換ジョブが処理し、出力資産へ保存しました。ストリーミング端点は要求時にHLS・DASHへ包装し、ロケーターURL、暗号化、DRM鍵配信を組み合わせていました。ライブイベントは入力、変換、ライブ出力を管理していました。
現在の復旧・移行は次の順序で考えます。
- Storageに残る原本、変換済み媒体、マニフェスト、字幕、サムネイルを保全する
- IaC、アプリDB、ログ、バックアップから旧URL、資産ID、DRM・鍵情報を可能な範囲で復元する
- エンコード、ライブ、配信元、CDN、DRM、分析の移行先を個別に選ぶ
- 新URLとプレーヤーを作り、字幕・DRM・広告・端末互換性を並行検証する
- 古いURL・資格情報・DNS・監視を新経路へ切り替える
設計パターン / ベストプラクティス
- VODは原本を不変で保管し、変換結果を再生成できるジョブ定義をコードで残す
- すでにHLS/DASHへ包装済みなら、非公開StorageをFront DoorまたはCDNの配信元にして検証する
- 動的包装・ライブ・DRMが必要なら、対応するパートナー製品を地域、形式、鍵、SLA、移行手段で比較する
- 自社処理はVM・AKS・Batchなどで実装できるが、キュー、再試行、容量、更新、監視を自ら負う
- 旧AMS URLを維持できる前提を置かず、アプリDB、プレーヤー、埋め込み、キャッシュを新URLへ更新する
運用・監視
- Storageの原本・出力・マニフェストを一覧化し、世代管理、保持、復旧試験を行う
- 変換ジョブの待ち時間・失敗、ライブ入力、マニフェスト更新、CDN 4xx・5xx、DRM鍵発行を別指標として追う
- 配信元とCDNのアクセスログで、古いAMSホスト名への要求と更新漏れを特定する
- 旧AMS用のアラーム、Webhook、資格情報、RBAC割り当てを削除する
コスト
移行後は一括料金ではなく、変換計算、ライブ稼働、Storage、配信元、CDN転送、DRM・パートナー契約を合算します。原本と配信用成果物の二重保存、再変換、複数地域、移行中の二重配信も見積もりに含めます。
セキュリティ
- Storage上の媒体が残っていても匿名公開せず、最小権限RBACとネットワーク制限を適用する
- 旧AMS用のサービスプリンシパル、キー、SAS、Webhook署名を棚卸しし、不要なものを失効する
- DRMは鍵・権利・ライセンス発行・プレーヤーを一体で再構築する。Key Vaultだけでは旧鍵配信を代替しない
- CDN署名、トークン、CORS、参照元制限を新しいホスト名で再検証する
- 未公開原本と公開用成果物はStorageアカウントまたはコンテナーを分離する
関連サービス・比較
| 旧AMS機能 | 移行先の例 | 注意点 |
|---|---|---|
| VODエンコード | Bitmovin等のパートナー / FFmpeg自社運用 | 直接のAzure管理後継はない |
| ライブ・動的包装・DRM | MediaKind・Ravnur等のパートナー | 地域・形式・鍵・SLAを確認 |
| 静的HLS/DASH配信 | Storage + Front Door | 既成媒体、URL、認証、CDN設定が必要 |
| 映像・音声分析 | Azure Video Indexer | 配信基盤の後継ではない |
ハンズオン / CLI例
az ams は終了後の棚卸し手段になりません。残存するStorageと配信資源を確認します。
# Storage上に残る媒体コンテナーを確認
az storage container list \
--account-name mymediaaccount \
--auth-mode login \
--query "[].{Name:name,Modified:properties.lastModified}" -o table
# 原本・マニフェスト・字幕を一覧化
az storage blob list \
--account-name mymediaaccount \
--container-name media \
--auth-mode login \
--query "[].{Name:name,Size:properties.contentLength}" -o table
# 現行のFront Door配信先を確認
az afd profile list \
--query "[].{Name:name,Sku:sku.name,Group:resourceGroup}" -o table
Azure Service
Azure Media Servicesを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
メディア
比較で見る軸
クラウド: Azure / カテゴリ: メディア / 難易度: intermediate
導入後に効く点
媒体ファイルはStorageに残るが、配信URL・ライブ・資産メタデータは削除済み。
先に潰すリスク
サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。
- クラウド
- Azure
- カテゴリ
- メディア
- 難易度
- intermediate
- 関連資格
- —
- 設計柱
- operational / cost / security / performance
判断チェックリスト
- 自社の用途が「メディア / operational」に近いか確認する。
- 強みである「Azure Media Servicesは2024年6月30日に退役し、現在は利用できない。」が本当に評価軸になるか確認する。
- 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。