Amazon Elastic Transcoder
【2025-11-13 提供終了】S3 上の動画・音声を各種デバイス向けに変換したトランスコーディングサービス。後継は AWS Elemental MediaConvert
概要
【提供終了】Amazon Elastic Transcoder は 2025 年 11 月 13 日に提供を終了しました。後継は AWS Elemental MediaConvert です。以下は提供当時の解説です。Amazon Elastic Transcoder は、S3 に保存された動画や音声ファイルを、スマートフォン、タブレット、PC、スマート TV など様々なデバイスで再生可能なフォーマットに変換するクラウドベースのトランスコーディングサービスです。入力ファイルを指定し、プリセット (出力フォーマットの設定テンプレート) を選択するだけで、H.264 や VP8 などのコーデックへの変換、解像度の変更、ビットレートの調整を自動的に行います。パイプラインの概念で処理を管理し、優先度に応じたジョブのキューイングが可能です。HLS (HTTP Live Streaming) 形式への変換にも対応し、アダプティブビットレートストリーミングの配信準備を自動化できます。従量課金制で、変換した動画の分数に基づいて課金されます。
提供終了と移行先
Amazon Elastic Transcoder は 2025 年 11 月 13 日をもって提供終了となりました。AWS の公式告知では「コスト削減とより多くの機能のために AWS Elemental MediaConvert へ」と、後継サービスが明確に指定されています。MediaConvert は H.265 / AV1 などの新しいコーデック、品質定義可変ビットレート (QVBR)、豊富な放送級機能を備え、Elastic Transcoder のパイプライン + プリセットに相当する概念はジョブテンプレートと出力プリセットで再現できます。HLS のアダプティブビットレート配信も Apple HLS 出力グループでそのまま構成可能です。本ページは提供当時の仕様を記録した歴史的資料 + 移行ガイドとして残しています。
パイプラインとプリセットの設計
以下は提供当時 (2025 年 11 月 13 日の提供終了まで) の仕様です。Elastic Transcoder の処理は、パイプライン、ジョブ、プリセットの 3 つの概念で構成されていました。パイプラインは入力 S3 バケットと出力 S3 バケットを紐づける処理チャネルで、用途別 (例: 高優先度の本番用、低優先度のバッチ用) に複数作成できました。プリセットは出力フォーマットの詳細設定をテンプレート化したもので、コーデック、解像度、ビットレート、フレームレート、オーディオ設定などを定義します。AWS 提供のシステムプリセットがデバイスや用途別に用意されており、ListPresets で一覧を取得してジョブから指定できました。カスタムプリセットでは、ビットレートの上限・下限、キーフレーム間隔、プロファイルレベル (H.264 の Baseline/Main/High) まで細かく制御し、画質とファイルサイズのバランスを最適化できました。サムネイル生成も同じプリセットで設定でき、動画の特定時点のフレームを JPEG/PNG として抽出してプレビュー画像に利用できました。MediaConvert へ読み替える場合、パイプラインに相当するのはキューです。ただしキューは特定の S3 バケットに紐づかないため、入力バケットが異なるジョブを同一キューで扱えます。プリセットは Elastic Transcoder では出力ごとに必須で上書きできませんでしたが、MediaConvert では API で個々のエンコードパラメータを上書きでき、プリセットを使わずジョブリクエストに全設定を書くこともできます。入力設定や出力グループ設定まで含めてジョブ全体を再利用したい場合はジョブテンプレートを使い、既定のシステムプリセットとジョブテンプレートも用意されています。
HLS 変換とアダプティブビットレート配信の構築
以下は提供当時の仕様です。Elastic Transcoder の重要な機能の 1 つが、HLS (HTTP Live Streaming) 形式への変換でした。HLS は動画を短いセグメント (通常 10 秒) に分割し、マニフェストファイル (.m3u8) で管理する形式で、iOS、Android、Web ブラウザなど幅広いデバイスで再生できます。アダプティブビットレートストリーミングを実現するには、同一の入力動画から複数のビットレートで HLS 出力を生成し、マスタープレイリストで束ねます。ビットレートの刻みは配信対象の回線品質に合わせて決めるもので、例えば 400 kbps、800 kbps、1.5 Mbps、3 Mbps のように数段階を用意します。視聴者のネットワーク帯域に応じてプレーヤーが最適なビットレートを自動選択するため、バッファリングを最小化しつつ画質を保てます。CloudFront と組み合わせて配信する設計が一般的で、S3 に出力された HLS セグメントを CloudFront でキャッシュ配信します。暗号化オプションとして AES-128 暗号化に対応しており、暗号化キーを別途管理するサーバーと組み合わせることで、コンテンツの不正ダウンロードを防止できました。MediaConvert では同じ構成を CMAF (Common Media Application Format) のフラグメント化 MP4 による HLS / DASH 出力として組み直せます。CMAF 出力の映像コーデックは AVC または HEVC で、HLS プレイリストのバージョンは手動で選ぶのではなく、有効にした機能が要求するバージョンへ自動的に切り替わります。
ジョブ管理とイベント駆動アーキテクチャの設計
以下は提供当時の設計例です。Elastic Transcoder のジョブは非同期で実行され、完了通知を SNS トピックで受け取る設計が標準的でした。パイプラインに SNS トピックを関連付けると、ジョブの開始、完了、エラー、警告の各イベントで通知が発行されます。イベント駆動アーキテクチャでは、S3 への動画アップロードをトリガーに Lambda を起動し、Elastic Transcoder のジョブを自動作成する設計が効果的でした。Lambda 内で入力動画のメタデータ (解像度、長さ) を取得し、適切なプリセットを動的に選択するロジックを組み込めば、様々な入力フォーマットに自動対応できます。ジョブ完了後の SNS 通知を別の Lambda で受け取り、DynamoDB にトランスコード結果のメタデータを保存し、フロントエンドに再生可能な URL を返す一連のパイプラインを構築できました。エラーハンドリングとして、トランスコード失敗時にリトライキュー (SQS) に投入し、一定回数リトライしても失敗する場合はデッドレターキューに移動して手動確認する設計が堅牢です。コスト最適化の観点では、変換時間 (分単位) に基づく課金だったため、不要な高解像度出力を省き、実際に視聴されるデバイスに必要な解像度のみを生成する設計が重要でした。MediaConvert へ読み替える場合、通知の入り口が変わります。MediaConvert はジョブ状態の変化を CloudWatch Events のイベントとして発行し、そこから Lambda、SQS、Step Functions、Systems Manager Automation、EventBridge などへルーティングします。イベントのフィルターパターンを書けるため、ジョブに付けたユーザーメタデータと完了ステータスの組み合わせで対象を絞り込み、特定の Lambda だけを起動するといった制御もできます。
参考資料 (AWS 公式)
本ページの一次情報は AWS 公式サイトおよび公式ドキュメントです。最新の仕様 / 料金は次の公式ページで確認できます。
本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。