AWS Elemental MediaLive

解決する課題

ライブ配信を自前で行うには、放送グレードのエンコーダ機材を調達し、データセンターに設置・冗長化し、トラフィックの増減に合わせて運用する必要があります。これは設備投資も運用負荷も大きく、イベント単発の配信には過剰になりがちです。AWS Elemental MediaLive を使うと、カメラやエンコーダからのライブ映像入力をクラウド上でリアルタイムに圧縮・変換し、視聴者向けの配信形式へ変換できます。

• スポーツ・ニュース・コンサートなどのライブイベントをインターネット配信したい
• 24 時間放送のOTT チャンネルやライブ chと同等の配信を運用したい
• 機材を抱えずに、必要な期間だけ放送品質のエンコードをクラウドで行いたい
• 単一機材の故障で放送が止まらない、冗長で止まりにくいライブ配信を構築したい

中心的な価値は、放送局が使うのと同等のエンコード品質と冗長性を、専用機材を所有せずにマネージドサービスとして使える点です。MediaLive 単体は「ライブ動画のエンコード」に特化しており、配信パッケージングやストレージは MediaPackage や S3 などの後段サービスと組み合わせて完成させます。

主要概念と用語

• ライブエンコード: ライブ映像をリアルタイムに圧縮・形式変換する処理。録画済みファイルを処理する VOD トランスコードとは異なり、遅延なく流し続ける必要がある
• チャンネル: MediaLive の中核となる処理単位。入力を受け取りエンコードして出力先へ送る一連の設定をまとめたもの
• インプット（入力）: チャンネルが受け取る映像ソース。エンコーダからの push 型や、ソースを取りに行く pull 型などがある
• インプットセキュリティグループ: push 型入力に対して、接続を許可する送信元 IP 範囲を制御する仕組み
• 出力グループ: エンコード結果の送り先と形式の束。HLS などの ABR ストリーミング向けや、別サービスへの中継向けなど用途ごとに定義する
• ABR（適応ビットレート）: 同じ映像を複数の画質で同時に出力し、視聴者の回線状況に応じて切り替えられるようにする方式
• パイプライン: チャンネル内部のエンコード経路。標準では二重化され、片方に問題が出ても配信を継続できる
• 入力スイッチ: 複数の入力をスケジュールやコマンドで切り替える機能。番組の差し替えやフェイルオーバーに使う

仕様・制限・クォータ

• カメラやハードウェア・ソフトウェアエンコーダからのライブ入力を受け取り、リアルタイムにエンコードする
• 主要なライブストリーミング形式や中継用の出力に対応し、後段の配信・パッケージングサービスへ受け渡せる
• 1 つの入力から複数画質を同時出力する ABR に対応し、視聴環境に応じた配信ができる
• チャンネルは冗長な入力と二重パイプラインを構成でき、片系障害時も配信を継続しやすい
• push 型入力ではインプットセキュリティグループにより送信元 IP を制限できる
• アカウント単位のチャンネル数や入力数などのクォータがあり、引き上げ申請が可能

対応する具体的な入出力プロトコル・コーデック・解像度・上限値は更新されるため、最新の公式ドキュメントで確認してください。

内部の仕組み

利用者から見ると、ライブ入力を受け取り、設定したエンコード処理を行い、指定の出力先へ流し続けるマネージドなエンコーダとして扱えます。

• 入力の受け取り: エンコーダ側から MediaLive へ送る push 型と、MediaLive がソースを取りに行く pull 型がある。push 型は接続先のエンドポイントに対して映像を送信する
• 二重パイプライン: チャンネル内部ではエンコード経路が二重化され、それぞれが独立して同じ出力を生成する。片方のパイプラインに障害が出ても、もう片方が配信を継続する
• 入力フェイルオーバー: 主入力と予備入力を構成し、主入力が途切れた際に予備へ切り替えることで、入力側の障害にも備えられる
• チャンネルの状態: チャンネルは開始すると稼働状態になりエンコードを続け、停止すると課金対象の稼働が止まる。設定変更の多くはチャンネルを停止した状態で行う
• 後段との受け渡し: エンコード結果は出力グループを通じて MediaPackage などのパッケージングや、S3・配信エンドポイントへ送られる

スケーリングや基盤ハードウェアの管理は AWS 側が担い、利用者は入力・エンコード設定・出力の定義に集中できます。

設計パターン / ベストプラクティス

• 入力もパイプラインも冗長化: 重要なライブ配信では、主入力と予備入力を用意し、二重パイプラインを前提に設計して単一障害点を排除する
• MediaLive と MediaPackage の組み合わせ: MediaLive でエンコードし、MediaPackage でパッケージングと配信形式の出力を担わせ、CloudFront で配信する構成が定番
• 配信は CDN を前段に: 視聴者へは MediaLive から直接ではなく CloudFront などの CDN を介して届け、遅延とオリジン負荷を下げる
• 入力スイッチで番組制御: 番組の差し替えやスライド・予備映像への切り替えは入力スイッチのスケジュールで制御し、運用を自動化する
• イベント単発はチャンネルの開始・停止で運用: 常時放送でなければ、配信時間帯だけチャンネルを稼働させてコストを抑える

運用・監視

• チャンネルの稼働状況・入力の有無・エンコード状態は CloudWatch のメトリクスで監視する
• 入力断・パイプライン障害・チャンネル状態変化などのイベントは EventBridge 経由で検知し、通知や自動対応につなげる
• 障害時は通知を SNS などへ流し、運用チームへ即時にアラートする
• 入力が届かない場合は、送信元エンコーダの設定とインプットセキュリティグループの IP 許可範囲を見直す
• API 操作の監査証跡は CloudTrail に記録される

コスト

• 課金は基本的にチャンネルが稼働している時間に対して発生し、入力・エンコード設定や出力数によって単価が変わる傾向がある
• 高解像度・高フレームレートや出力数の多い構成ほど、必要なエンコード処理が増えてコストが上がりやすい
• 常時放送でないイベント配信では、配信時間帯だけチャンネルを稼働させ、終了後に停止することで費用を抑えられる
• データ転送や後段の MediaPackage・CloudFront など、関連サービス側の費用も別途かかる

具体的な単価は変動し、入出力構成によっても異なるため、料金は公式の料金ページで確認し、小さな構成で検証してから本番を見積もるのが安全です。

セキュリティ

• API やリソースへのアクセス制御は IAM で行い、チャンネルや入力の操作に必要な最小権限のみを付与する
• push 型入力ではインプットセキュリティグループで送信元 IP を限定し、想定外の送信元からの接続を防ぐ
• 入力・出力の経路は、対応するプロトコルで暗号化された安全な接続を選び、視聴者向け配信は HTTPS で届ける
• 後段の S3 出力は、バケット側の暗号化（KMS 管理鍵を含む）とアクセスポリシーで保護する
• 限定公開のライブ配信は、CDN 側の署名付き URL や Cookie などと組み合わせて視聴範囲を制御する

Well-Architected の観点

• 信頼性: 冗長な入力と二重パイプライン、入力フェイルオーバーにより、単一障害点を避けて放送に耐える配信を実現する
• パフォーマンス効率: 放送グレードのリアルタイムエンコードと ABR 出力で、視聴環境に応じた低遅延・高品質な配信ができる
• コスト最適化: チャンネルの稼働時間課金を踏まえ、イベント時間帯だけ稼働させ、出力構成を要件に合わせて絞る
• セキュリティ: IAM の最小権限とインプットセキュリティグループ、暗号化された経路で入力から配信までを保護する
• 運用上の優秀性: CloudWatch・EventBridge・SNS と組み合わせて、稼働監視と障害通知・自動対応を仕組み化する

試験で問われるポイント

関連サービス・比較

ライブ配信パイプラインでよく隣に並ぶ MediaPackage と役割を比較します。両者は競合ではなく、エンコードとパッケージングという別の段を担います。

ハンズオン / CLI例

# 既存チャンネルの一覧と状態を確認
aws medialive list-channels \
  --query "Channels[].{Name:Name,Id:Id,State:State}"

# ライブ配信を開始（チャンネルを稼働状態にする）
aws medialive start-channel --channel-id 1234567

# イベント終了後はチャンネルを停止して課金を止める
aws medialive stop-channel --channel-id 1234567