AWS Elemental MediaConnect

解決する課題

放送局や映像制作者がライブ映像を拠点間や AWS へ運ぶには、衛星回線や専用線、専用機材といった高コストな伝送手段が必要でした。これらは調達と運用に時間とコストがかかり、配信ルートの追加や切り替えも柔軟ではありません。一方で、通常のインターネットはパケットロスや遅延の変動が起きやすく、そのままでは放送品質のライブ映像伝送には向きません。AWS Elemental MediaConnect は、エラー訂正と暗号化を備えた映像トランスポートをマネージドで提供し、インターネット越しでも放送に耐える品質でライブ映像を運べるようにします。

• 放送局や中継現場から AWS へ、ライブ映像を信頼性高く取り込みたい
• 衛星や専用線に代わる、柔軟でコスト効率の良い映像伝送経路が欲しい
• 1 本のソース映像を複数の配信先・パートナーへ同時に配る必要がある
• インターネット経由でもパケットロスや改ざんに強い安全な伝送を実現したい

中心的な価値は、専用機材や衛星を持たずに、放送グレードの信頼性と暗号化を備えた映像トランスポートをクラウド上で構築できる点です。MediaConnect 自体はエンコードやパッケージングを行わず、あくまで「ライブ映像を安全に運ぶ」層に特化しており、MediaLive などのエンコードサービスと組み合わせて配信パイプラインを完成させます。

主要概念と用語

• フロー: MediaConnect の中核となる処理単位。1 つのソース入力を受け取り、エラー訂正や暗号化を施して 1 つ以上の出力へ送る一連の設定をまとめたもの
• ソース（入力）: フローが受け取る映像の入り口。送信側から送り込む方式と、MediaConnect 側が取りに行く方式がある
• 出力（アウトプット）: フローからエンコーダや別フロー、外部の受信先へ映像を送る送出口。1 つのフローから複数の出力先へ同時に配れる
• エンタイトルメント: あるアカウントのフローの出力を、別の AWS アカウントへ受信許可として共有する仕組み。コンテンツ提供者と受信者の関係を安全に結ぶ
• FEC（前方誤り訂正）: 受信側で欠落パケットを再構成できるよう冗長情報を付加し、再送なしでパケットロスに耐える方式
• SRT / Zixi / RIST: インターネット越しのライブ映像伝送に使われる、損失や遅延変動に強いトランスポートプロトコル群
• 冗長性ゾーン構成: ソースや出力を複数の経路で二重化し、片系の障害でも伝送を継続できるようにする構成
• ブリッジ: オンプレミスの拠点と AWS の間で映像をやり取りするための接続単位として用いられる仕組み

仕様・制限・クォータ

• 放送向けのライブ映像トランスポートに特化し、エンコードやトランスコードは行わない
• パケットロスに強いエラー訂正付きのトランスポートプロトコルに対応し、インターネット経由でも安定した伝送を行える
• 1 つのソースから複数の出力へ同時配信でき、配信先ごとに設定を分けられる
• 暗号化に対応し、伝送中の映像を保護できる
• 別アカウントへ出力を共有するエンタイトルメントにより、組織をまたいだ映像配信ができる
• ソース・出力の冗長化により、片系障害時も伝送を継続しやすい
• アカウント単位のフロー数や出力数などのクォータがあり、引き上げ申請が可能

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

内部の仕組み

利用者から見ると、ライブ映像のソースを受け取り、エラー訂正や暗号化を施して、指定した出力先へ運び続けるマネージドな伝送ハブとして扱えます。

• ソースの受け取り: 送信側から MediaConnect のエンドポイントへ送り込む方式と、MediaConnect が指定したソースを取りに行く方式がある。プロトコルに応じたエラー訂正で、欠落パケットを補いながら受信する
• ファンアウト配信: 受け取った 1 本のソースを、複数の出力へ同時に複製して送出できる。配信先ごとにプロトコルや暗号化、宛先を個別に設定する
• アカウント間共有: エンタイトルメントを用いると、自アカウントのフロー出力を別アカウントが受信できる。提供側が許可を出し、受信側がその許可をもとに自分のフローのソースとして取り込む
• 冗長伝送: ソースや出力を複数経路で構成すると、片方の経路に障害が出ても、もう片方が伝送を継続する
• フローの状態: フローは開始すると稼働状態になり伝送を続け、停止すると課金対象の稼働が止まる。多くの設定変更はフローを停止した状態で行う

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

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

• ソースも出力も冗長化: 重要なライブ伝送では、ソースと出力を複数経路で構成し、片系障害が配信断につながらないよう設計する
• MediaConnect から MediaLive へ受け渡す: MediaConnect で安全に取り込んだ映像を MediaLive のソースとして渡し、エンコードとパッケージングを後段に担わせる構成が定番
• 複数配信先はファンアウトで集約: 同じソースを複数のパートナーや配信先へ送る場合は、出力を複数定義して 1 つのフローから配り、ソース側の負荷を増やさない
• アカウント間配信はエンタイトルメントで: 別組織への映像提供は IP や認証情報を直接共有せず、エンタイトルメントで受信許可を管理する
• 常時運用でなければフローを開始・停止: 配信イベントの時間帯だけフローを稼働させ、終了後に停止してコストを抑える

運用・監視

• フローの稼働状況・ソースの受信状態・パケットロスや伝送品質は CloudWatch のメトリクスで監視する
• ソース断やフロー状態の変化などのイベントは EventBridge 経由で検知し、通知や自動対応につなげる
• 障害時は通知を SNS などへ流し、運用チームへ即時にアラートする
• 映像が届かない場合は、送信元の設定、宛先 IP やポート、暗号化鍵の整合、許可された送信元範囲を見直す
• API 操作の監査証跡は CloudTrail に記録される

コスト

• 課金は基本的にフローが稼働している時間と、フローに紐づく出力の数や帯域に応じて発生する傾向がある
• インターネットや別リージョン・別アカウントへのデータ転送量に応じた費用も別途かかる
• 出力先が多いほど、また高帯域な構成ほどコストが上がりやすいため、必要な配信先に絞る
• 常時運用でないイベント伝送では、配信時間帯だけフローを稼働させ、終了後に停止することで費用を抑えられる

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

セキュリティ

• API やリソースへのアクセス制御は IAM で行い、フローや出力の操作に必要な最小権限のみを付与する
• 伝送中の映像は暗号化を有効にして保護し、鍵は KMS や Secrets Manager と組み合わせて安全に管理する
• 送信側から送り込む方式では、許可する送信元の範囲やポートを限定し、想定外の送信元からの接続を防ぐ
• 別アカウントへの配信は IP や鍵を直接共有せず、エンタイトルメントで受信許可を管理して共有範囲を制御する
• ネットワーク経路は VPC やプライベート接続と組み合わせ、公開範囲を必要最小限にとどめる

関連サービス・比較

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

ハンズオン / CLI例

# 既存フローの一覧と状態を確認
aws mediaconnect list-flows \
  --query "Flows[].{Name:Name,Status:Status,Arn:FlowArn}"

# ライブ伝送を開始（フローを稼働状態にする）
aws mediaconnect start-flow --flow-arn arn:aws:mediaconnect:ap-northeast-1:111122223333:flow:1-ExampleFlow

# イベント終了後はフローを停止して課金を止める
aws mediaconnect stop-flow --flow-arn arn:aws:mediaconnect:ap-northeast-1:111122223333:flow:1-ExampleFlow