--- title: "AWSとOBSでライブ配信基盤を構築する手順｜IVSとMediaLiveの選び方・東京リージョンの料金試算" url: "https://www.issoh.co.jp/tech/details/5663/" published: 2025-03-05 updated: 2026-09-23 categories: ["AWS"] publisher: "株式会社一創" --- # AWSとOBSでライブ配信基盤を構築する手順｜IVSとMediaLiveの選び方・東京リージョンの料金試算 OBS Studioで作った映像をAWSへ送る経路は、Amazon IVSに直接送る道と、AWS Elemental MediaLiveで受けてMediaPackage v2から配信する道の2つに分かれます。どちらを選ぶかで、OBS側に入れる取り込みURLもビットレートの上限も、月々の請求の形も変わります。この記事では、AWS公式ドキュメントで確認した設定値と、AWS Price List APIから取得した東京リージョンの単価をもとに、2つの経路の組み方と選び分けを示します。 ## まとめ 結論として、標準料金で比べる限りAmazon IVSが安く収まる範囲は広く、MediaLive + MediaPackage v2を選ぶ理由はDRM・SCTE-35ベースの広告ワークフロー・自社CDNへの接続といった機能要件です（広告挿入そのものはIVSもMediaTailor連携で行えます）。CloudFrontの無料枠を除外した後述の試算では、1080p配信で単一トラック入力という条件のとき、視聴者が少ないうちはMediaLive構成のほうが安くなります。 - OBS Studio 30.2以降ならサービス欄に`Amazon IVS`プリセットがあり、ストリームキーを貼るだけでRTMPS配信できます。チャネルタイプごとの入力上限を超える設定では、接続が即座に切れる可能性があります。 - MediaLiveのRTMP入力はRTMPSを受け付けません。ポートも443ではなく1935です。IVSからMediaLiveへ乗り換えるときの最初のつまずきどころになります。 - OBSのエンコード設定で最初に合わせるのは、キーフレーム間隔2秒とレート制御CBRの2つです。IVSはVBRを明確に非推奨としています。 - 東京リージョンの配信側時間課金は、IVS STANDARDが単一トラック入力で2.00 USD、マルチトラック入力なら0.50 USD、MediaLiveのシングルパイプライン（HD入力＋HD/SD2出力）が1.3644 USDです。 - CloudFrontの無料枠を使わず後述のビットレートと初段単価で比べると、720pではIVS ADVANCED\_HDが配信側も視聴者側もMediaLive構成より安く、分岐点はありません。1080pかつ単一トラック入力の条件でのみ、平均同時視聴8人前後でIVSが追い越します。 - MediaLiveはチャネルを停止しても課金がゼロになりません。アイドル状態のチャネルとプッシュ入力に、東京で1時間あたり0.01 USDが発生します。 - AWS Elemental MediaStoreは2025年11月13日にサポート終了済みです。MediaStoreをオリジンに置く手順を載せた解説記事は、そのままでは動きません。 以下では、経路の選択基準、OBSの設定値、MediaLive構成の設定判断、料金試算、遅延とトラブルの切り分けを順に示します。 ## AWSでライブ配信を組む2つの経路と選択基準 AWSのライブ配信サービスは数が多く、名前だけを並べた比較表では選べません。EC2上にnginx-rtmpのような配信サーバーを自前で立てる道や、S3を単純なオリジンにする道もありますが、この記事ではマネージドサービスを使う2つの経路を扱います。 ### Amazon IVSで足りる条件 Amazon IVSは、取り込み・トランスコード・配信・プレイヤーまでを1サービスで引き受けるマネージドサービスです。チャネルを1つ作れば取り込みURLと再生URLが同時に払い出されるため、OBSの配信設定を書き換えるだけで配信が始まります。CDNの設計もパッケージングの設定も出てきません。 取り込みプロトコルはRTMP、RTMPS、SRTの3つに対応し、遅延はAWS公式ドキュメントで**low latencyが5秒未満**と明記されています。サービスの全体像は[Amazon Interactive Video Service（IVS）とは何か？特徴と概要を徹底解説](/tech/details/9696/)で整理しています。 コントロールプレーンは東京を含む7リージョンで提供されています。チャネルは作成したリージョンでしか管理できませんが、取り込みと視聴のデータプレーンはグローバルに動くため、東京でチャネルを作って海外から配信しても問題ありません。 ### MediaLive + MediaPackage v2を選ぶ条件 MediaLive + MediaPackage v2は、後述の料金試算に加えて次の機能要件で選びます。DRMによる暗号化、SCTE-35を使った広告挿入、HLSとDASHとMSSの同時出力、自社契約のCDNへの接続、入力の二重化。ここで広告だけは切り分けが要ります。**IVSにもサーバーサイド広告挿入（SSAI）があり、MediaTailorと連携して広告判断・ターゲティングを行えます。**ミッドロールは`InsertAdBreak` APIで手動、ポストロールは配信終了時に自動で挿入され、広告は映像へ直接スティッチされます。したがってMediaLive構成が要るのは、広告の有無ではなくSCTE-35のマーカーを自前のワークフローで扱う場合です。暗号化・出力形式・CDN・入力の二重化の要件が残る案件では、引き続きMediaLive構成を採ります。 CDNについては、制御できないというより明示的に禁じられています。AWSのドキュメントはIVSが再生用のカスタムドメインに対応していないと述べたうえで、**再生URLを自社ドメインでプロキシしてはならない、動作しないうえ問題を起こす**と書いています。CloudFrontを挟んで配信経路を自前で握る構成は、IVSでは最初から選択肢に入りません。 逆に言えば、社内イベントの配信や小規模なサービスの検証で「とりあえずAWSでライブ配信を」という段階なら、MediaLive構成は運用の手間に見合いません。入力セキュリティグループ、チャネルクラス、MediaPackageのチャネルグループとオリジンエンドポイント、CloudFrontのビヘイビアと、設定する対象が4層に増えます。 ### MediaStoreのサポート終了と既存構成の読み替え 日本語で「AWS ライブ配信」を検索したときに上位へ出てくる手順記事には、MediaLiveの出力先にAWS Elemental MediaStoreを置く構成がまだ残っています。**MediaStoreは2025年11月13日にサポートが終了しました。**AWSは[サービス終了の告知](https://aws.amazon.com/blogs/media/support-for-aws-elemental-mediastore-ending-soon/)で、この日を過ぎるとMediaStoreとその機能を一切使えなくなると書いています。コンソールもコンテナもサービス機能も、それ以降は使えません。 AWSは移行先として、単純なライブ配信ワークフローならAmazon S3、クロスリージョンのフェイルオーバーや低遅延要件があるならMediaPackageを案内しています。ただしオリジン名を置き換えれば済む話ではありません。MediaLive側の出力グループの宛先とパッケージング設定、CDNのオリジン設定と認証方式、再生URLの発行元が一緒に変わります。MediaStoreをオリジンに置いた手順を参照するときは、公開日にかかわらず、オリジン層から下流の設定を移行先に合わせて読み替えてください。 ## OBS StudioからAmazon IVSへ配信する手順 IVS経路は、チャネルを1つ作ってストリームキーをOBSへ移し、ビットレートと解像度がチャネルタイプの上限に収まっているかを確認すれば配信できます。OBS Studioの入手元が公式かどうかは事前に確かめてください。2026年にはフォーラム配布のプラグインが改ざんされた事例があり、[OBS Studioは安全か？公式サイトの見分け方とプラグイン改ざん事件の影響範囲【2026年】](/tech/details/11319/)で影響範囲をまとめています。 ### チャネル作成と取り込みURLの形式 チャネルはコンソールでもCLIでも作れます。`create-channel`のレスポンスには`channel.ingestEndpoint`と`streamKey.value`が両方入っているため、通常は1コマンドで足ります。2つ目の`get-stream-key`は、既存チャネルのキーを取り直すときに使います。ARNの部分は`create-channel`が返した`streamKey.arn`に置き換えてください。 ``` aws ivs create-channel --name obs-live --type STANDARD --latency-mode LOW --region ap-northeast-1 aws ivs get-stream-key --arn arn:aws:ivs:ap-northeast-1:123456789012:stream-key/abcdEFGH1234 --region ap-northeast-1 ``` 払い出される取り込みURLはRTMPSの場合、次の形です。AWSはアウトバウンドのTCP 443を使わせるために、取り込みサーバーの指定へ`:443`を含めるよう案内しています。平文のRTMPで送るときは、スキームを`rtmp://`に変えてこの`:443`を外すだけでなく、チャネル側で非セキュアな取り込みを有効にしておく必要があります。RTMP系のプロトコルで送る場合、既定のチャネルが受けるのは暗号化されたRTMPSだけです。SRTの条件は次に示します。 ``` rtmps://a1b2c3d4e5f6.global-contribute.live-video.net:443/app/ ``` SRTで送る場合はポート9000で、ストリームキーとパスフレーズをクエリに載せます。チャネル側で非セキュアな取り込みを有効にしていない限り、パスフレーズは必須です。 ``` srt://a1b2c3d4e5f6.srt.live-video.net:9000?streamid=&passphrase= ``` ### OBSの配信設定に入れる値 OBS Studio 30.2以降では、設定のサービス欄に`Amazon IVS`のプリセットが用意されています。RTMPSで送るならこれを選び、ストリームキー欄に`sk_`で始まるIVSのストリームキーを貼るだけで完了します。サーバー欄の入力は要りません。チャネルをマルチトラック入力で作ってある場合は、同じ画面の`Enable Multitrack Video`を有効にします。チャネル側は`containerFormat`を`FRAGMENTED_MP4`にし、`multitrackInputConfiguration`（`enabled`／`policy`／`maximumResolution`）を設定する必要があり、前掲のCLI例にはこの2つを含めていません。 SRTで送る場合だけは扱いが変わります。サービス欄に`Custom`を選び、サーバー欄に前掲のSRT URLを丸ごと入れたうえで、ストリームキー欄は空のままにします。ストリームキーはURLの`streamid`に含まれているためです。RTMPSで`Failed to connect to server`が出る場合、AWSのドキュメントはまずOBS Studioのバージョンが古い可能性を挙げています。 ### チャネルタイプ別の入力上限 IVSのチャネルタイプは4種類あり、受け付ける入力ビットレートの上限が違います。上限を超えた場合の挙動について、AWSのクォータ表は「ストリームはおそらく即座に切断される」と書いています。警告や自動ダウンコンバートで吸収される設計ではないため、上限を超える設定のまま配信を始めない前提で値を決めてください。以下は単一トラック入力の場合の値です（マルチトラック入力を有効にしたSTANDARDチャネルは上限が15 Mbpsになります）。 | チャネルタイプ | 入力上限 | 処理方式 | 最大出力解像度 | 入力料金(1時間) | | ------------- | -------- | -------- | ------- | --------- | | STANDARD | 8.5 Mbps | トランスコード | 1080p | $2.00 | | ADVANCED\_HD | 8.5 Mbps | トランスコード | 720p | $0.85 | | ADVANCED\_SD | 8.5 Mbps | トランスコード | 480p | $0.50 | | BASIC(480p以下) | 1.5 Mbps | トランスマックス | 入力と同じ | $0.20 | | BASIC(480p超) | 3.5 Mbps | トランスマックス | 入力と同じ | $0.20 | 解像度にも別の上限があります。単一トラック入力の場合、総画素数2.1メガピクセル、1辺あたり1920画素までです。1920×1080はこの範囲に収まり、縦向きの1080×1920も同じ条件を満たします。トランスコードされるSTANDARDとADVANCEDは複数画質のラダーを自動生成しますが、トランスマックスのBASICは入力をそのまま1画質で配信するため、視聴者の回線が細い場合の逃げ道がありません。 ## OBS側のエンコード設定値 AWS側の受け口を作っても、OBSの出力設定が噛み合っていなければ映像は乱れます。[IVSのストリーミング設定ドキュメント](https://docs.aws.amazon.com/ivs/latest/LowLatencyUserGuide/streaming-config.html)が推奨値を数値で示しているため、まずそこへ合わせるのが最短です（以下の値は2026年9月23日時点）。 ### 解像度別のビットレートとフレームレート | 解像度 | ビットレート | フレームレート | キーフレーム間隔 | | ----------------- | ------------ | --------- | -------- | | 480p (852×480) | 1500 kbps まで | 30 | 2秒 | | 720p (1280×720) | 4500 kbps まで | 30 または 60 | 2秒 | | 1080p (1920×1080) | 8500 kbps まで | 30 または 60 | 2秒 | 映像コーデックはH.264、音声はAAC（LC）です。H.264のプロファイルはMain、色差サンプリングはYUV420P、色空間はBT.709、CABACは有効が推奨されています。音声は96〜320 kbps、サンプリングレートは44.1 kHzまたは48 kHz、チャンネルは最大2の範囲に収めます。縦向き配信では表の解像度を縦横反転して読み替えます。 ### キーフレーム間隔2秒と、1秒に詰めたときのトレードオフ キーフレーム間隔は遅延に直結します。IVSのドキュメントによると、**2秒に設定した場合のストリーム開始遅延は約6〜7秒、1秒なら約3〜4秒**です。視聴者に映像が出るのも、S3への自動録画が始まるのも、この開始遅延を過ぎてからになります。 ただし1秒に詰めると副作用があります。セグメントが小さくなる分、プレイヤーのアダプティブビットレート判定が頻繁に走り、画質の切り替わりが増えます。視聴者の回線がセグメントを取り切れない場合はバッファリングも増えます。ライブコマースのように数秒の差が体験を左右する用途でなければ、2秒のままで問題ありません。 逆に5秒を超える値は避けてください。開始遅延が伸びるうえ、再生用に生成される全セグメントの先頭がキーフレームになる保証が失われます。AWSは、キーフレームで始まらないセグメントは視聴開始時や画質切り替え時にデコードエラーや映像の乱れを引き起こす可能性があると書いています。 ### CBR固定とVBVの制約 レート制御はCBRに固定します。AWSは「CBRのみを使うことを強く推奨する」と書いており、VBRを使うとシーンの複雑さに応じてビットレートが跳ね、**映像がAWSに届く前にフレームが落ちる**か、プレイヤー側でバッファリングが起きると説明しています。x264の設定が触れる環境なら、zerolatencyチューニングも併せて有効にします。 もう1つ見落としやすいのがVBVバッファサイズです。平均ビットレートを超えないように設定する必要があります。OBSでは出力モードを`詳細`にすると、配信タブでレート制御とビットレート、キーフレーム間隔を個別に指定できます。カスタムx264オプション欄に書き足す場合、OBSは入力を空白で区切って1項目ずつ`名前=値`として解釈するため、FFmpegの`-x264opts`で使うコロン区切りをそのまま貼ると1つの値として読まれます。区切りは空白にしてください。 ## MediaLive + MediaPackage v2構成の設定判断と落とし穴 DRMやSCTE-35による広告制御などの要件を比較したうえでMediaLive構成を採る場合、作業は入力セキュリティグループの作成、入力の作成、MediaPackage v2のチャネルグループとチャネルとオリジンエンドポイントの作成、MediaLiveチャネルの作成と出力先の接続、CloudFrontのディストリビューション作成、チャネル起動と再生確認、の順に進みます。ここではこのうち、手順書どおりに進めても引っかかりやすい入力・チャネルクラス・パッケージングの3点を扱います。 ### RTMPプッシュ入力と入力セキュリティグループ 最初に効いてくる制約があります。**MediaLiveはRTMPSプロトコルの入力をサポートしません。**[AWSの入力形式一覧](https://docs.aws.amazon.com/medialive/latest/ug/inputs-supported-formats.html)は、RTMP Pull、パブリックのRTMP Push、VPC内のRTMP Pushのいずれの行にも同じ一文を書いています。IVSへはRTMPSで送れるという前提のままMediaLiveへ乗り換えると、ここで止まります。取り込み先は`rtmp://:1935//`の形で、ポートは443ではなく1935です。経路の暗号化が要件に入っているなら、RTMPではなくSRTリスナー入力かMediaConnect経由を検討してください。 MediaLiveのプッシュ入力は、入力セキュリティグループでソースIPを制限します。グループはCIDRブロックのリストで、1つのグループに最大10ルールまで登録できます。OBSを動かすマシンがNATの内側にある場合、指定するのはプライベートIPではなく、公衆網に出たときのグローバルIPです。次のコマンドの`203.0.113.10`はドキュメント用の例示アドレスなので、配信拠点の実際のグローバルIPに置き換えてください。 ``` aws medialive create-input-security-group \ --whitelist-rules Cidr=203.0.113.10/32 \ --region ap-northeast-1 aws medialive create-input \ --name obs-rtmp-push \ --type RTMP_PUSH \ --input-security-groups \ --destinations StreamName=live/obs-primary \ --region ap-northeast-1 ``` `` には1つ目のコマンドが返す `SecurityGroup.Id` を入れます。EC2やVPCの `sg-` 形式とは別物です。入力クラスを直接指定する引数は`create-input`にありません。[AWSのクラス解説](https://docs.aws.amazon.com/medialive/latest/ug/class-channel-input.html)はスタンダードクラスの入力がパイプラインを2本、シングルクラスの入力が1本を持つと定義しており、宛先を1つだけ指定した上の例はシングルクラスの入力になります。2本を使うなら、`--destinations` は1回だけ書き、その後に `StreamName=live/obs-primary StreamName=live/obs-secondary` のように宛先を空白区切りで2つ渡します。スタンダードチャネルはすべての入力がスタンダードクラスである必要があるため、入力を作る時点でどちらにするか決めてください。OBS側はサービス欄に`Custom`を選び、払い出されたURLを2つに分けます。`StreamName`を`live/obs-primary`にした場合、サーバー欄は`rtmp://<払い出しIP>:1935/live`、ストリームキー欄は`obs-primary`です。URL全体をサーバー欄に貼ったうえでキー欄にも末尾を入れると、末尾が二重になって接続できません。 許可IPの運用も先に決めておきます。回線が切り替わってグローバルIPが変わるとその瞬間に弾かれますが、CIDRを広げる対処は不要な送信元まで通してしまいます。配信拠点に固定の出口IPを用意するか、配信前にルールを更新する手順を運用へ組み込むほうが確実です。 ### チャネルクラスの選択 MediaLiveのチャネルクラスは2つです。スタンダードクラスは異なるアベイラビリティーゾーンに2本のパイプラインを持ち、シングルパイプラインクラスは1本だけです。料金は入力も出力もクラスごとに別単価が設定されており、シングルパイプラインはスタンダードのちょうど60パーセントです。 冗長性が要らない社内配信や検証環境でスタンダードを選ぶ意味はありません。ここは迷わずシングルパイプラインで構いません。クラスはチャネルを停止した状態であれば後から双方向に変更できます。 ただし上げ方には差があります。シングルパイプラインからスタンダードへ変える際、入力をスタンダードクラスで作ってあれば出力グループごとに第2の宛先アドレスを足すだけで済みます。シングルクラスの入力で作っていた場合は、チャネルから入力を切り離し、入力を1本ずつスタンダードクラスへ変換して第2ソースを追加し、クラスを変更してから再接続する手順になります。将来の冗長化が視野にあるなら、チャネルはシングルパイプラインでも入力だけはスタンダードクラスで作っておくと後が楽です。 ### MediaPackage v2の入出力形式とv1からの非互換 MediaPackageは2023年5月にv2が出ており、現行のユーザーガイドはv2向けに書かれています。注意点は互換性です。AWSのドキュメントは**v1からv2へリソースを移行する自動処理は存在しない**と明記しています。ARNやURLには`mediapackagev2`という文字列が入り、v2のCLIやAPIからv1のリソースは一切操作できません。v1時代のCloudFormationテンプレートやTerraformコードは、そのままでは流用できないと考えてください。 入力はHLSとCMAFをHTTPSでプッシュする形式です。出力はマニフェスト形式ごとに4通りあります。 | エンドポイント種別 | マニフェスト | コンテナ | 映像コーデック | | --------- | ------ | -------------- | ------------------- | | TS | HLS | TS | H.264 / H.265 | | ISM | MSS | fragmented MP4 | H.264 / H.265 | | CMAF | HLS | CMAF | H.264 / H.265 / AV1 | | CMAF | DASH | CMAF | H.264 / H.265 / AV1 | AV1を使えるのはCMAFエンドポイントだけです。AV1のストリームを含むチャネルにTSエンドポイントを設定しても、そのストリームはエンドポイントに現れません。また入力には映像トラックが最低1本必要で、音声のみの入力は受け付けません。 配信の前段にCloudFrontを置く場合、MediaPackage v2のオリジン保護に使うのはオリジンアクセスコントロール（OAC）とエンドポイントポリシーです。AWSの推奨設定は、オリジンタイプに`MediaPackage V2`、オリジンプロトコルに`HTTPS only`、署名動作に`always`を指定する組み合わせです。ALBやEC2をプライベートのまま公開するVPCオリジンとは適用対象が違うので混同しないでください。VPCオリジン側の使いどころは[CloudFront VPCオリジンとは？ALB・EC2をプライベートのまま公開する設定と制約](/tech/details/4767/)にまとめています。 ## 東京リージョンの料金試算 ここからは、AWS Price List APIから取得した東京リージョン（ap-northeast-1）のオンデマンド単価で試算します。MediaLiveとMediaPackageの数値は2026年9月11日版の価格ファイルから抽出したもので、IVSとCloudFrontは公開料金ページの値です（いずれも2026年9月23日確認）。料金は改定されるため、金額を意思決定に使う前に必ず最新の公式料金ページ（[Amazon IVS](https://aws.amazon.com/jp/ivs/pricing/)／[MediaLive](https://aws.amazon.com/jp/medialive/pricing/)／[MediaPackage](https://aws.amazon.com/jp/mediapackage/pricing/)／[CloudFront](https://aws.amazon.com/jp/cloudfront/pricing/pay-as-you-go/)）で確認してください。 ### 配信側の時間課金 MediaLiveは1080p30を6 Mbpsで受け、HDとSDの2画質を出す構成の合算です。IVSは入力料金だけで、画質の本数はチャネルタイプ側で決まります。**同一構成の比較ではありません。**BASICもHDやフルHDを配信できますが、トランスマックスのため画質は入力と同じ1本だけで、ABRラダーは作られません。ADVANCED\_SDの出力上限は480pです。ここでは複数画質（ABR）への対応を比較条件に置くため、HD配信の候補はSTANDARDとADVANCED\_HDになります。残り2つは要件を落とせる場合の参考単価です。なおBASICの上限解像度は公式2ページで表記が食い違い（クォータ表は「1080p未満」、チャネルタイプ表は「1080p30/60以下」）、BASICで1080pを流す前提は置かないほうが安全です。 | 構成 | 内訳 | 1時間 | 2時間イベント | | ----------------------- | -------------------- | ------- | ------- | | IVS BASIC | 入力のみ | $0.2000 | $0.40 | | IVS STANDARD(マルチトラック入力) | 入力のみ | $0.5000 | $1.00 | | IVS ADVANCED\_SD | 入力のみ | $0.5000 | $1.00 | | IVS ADVANCED\_HD | 入力のみ | $0.8500 | $1.70 | | IVS STANDARD(単一トラック) | 入力のみ | $2.0000 | $4.00 | | MediaLive シングル | 0.2484+0.7452+0.3708 | $1.3644 | $2.73 | | MediaLive スタンダード | 0.4140+1.2420+0.6180 | $2.2740 | $4.55 | 目を引くのはIVS STANDARDの2つの行です。OBSのマルチトラックビデオで複数画質をそのまま送ると、IVS側でトランスコードする必要がなくなり、入力単価は2.00 USDから0.50 USDへ下がります。単一トラックで送ってIVSに画質を作らせる構成は、4倍払ってトランスコードを買っていることになります。 MediaLiveのシングルパイプラインが1.3644 USDなので、配信側だけを見れば、単一トラックのIVS STANDARD（2.00 USD）よりは安く、ADVANCED\_HD（0.85 USD）よりは高い位置です。視聴者側を足さないと大小は決まりません。以下は配信処理とデータ転送だけの概算で、CloudFrontのHTTP(S)リクエスト料金、音声やコンテナによる転送量の増分、ログ保存などは含めていません。 ### 視聴者1人あたりの単価と損益分岐 MediaLive構成では、視聴者に届く転送量に対してCloudFrontの料金（日本向けは月間最初の10 TBまで1 GBあたり0.114 USD、毎月1 TBの無料枠あり）がかかり、それとは別に、CloudFrontがオリジンへ取りに行った分だけMediaPackageの生成・パッケージング料金（1 GBあたり0.06 USD）がかかります。この2つは同じ量ではありません。AWS自身の試算例では**キャッシュヒット率99パーセント**を置いており、視聴者へ26,367.19 GB配信したケースでMediaPackageが生成するのは263.67 GBです。以下も99パーセントで計算しますが、これは平均視聴者1万人の例の数字で、**視聴者が数人から数十人の規模ではヒット率はもっと下がります**。ただし90パーセントまで落としてもMediaPackageの生成料金は視聴者側合計の数パーセントに収まるため、以降の比較の向きは変わりません。転送量の換算はAWSの試算例と同じ式にそろえます。公式例はビットレートを1024で割る式（逐語で「3/1024 x 60 x 120 x 10,000/8 = 26,367.19 GB」）を使っており、この式なら公式が示す取り込み量4.175 GB/時（9.5 Mbps）も再現できます。同じ式で計算すると、720pを平均3 Mbpsで1時間見た1人あたりの転送量は約1.32 GBです。単純な10進換算では1.35 GBとなり、金額は2%ほど上振れします。なおIVSの出力単価は月間最初の10,000時間に対する値で、それを超えた分は段階的に下がります。以下の表は最初の段階の単価です。 | 費目(視聴者1人・1時間) | 720p(約3Mbps) | 1080p(約5Mbps) | | ------------------------ | ------------ | ------------- | | IVS 出力(日本) | $0.0920 | $0.1840 | | CloudFront 転送(日本) | $0.1503 | $0.2505 | | MediaPackage 生成(ヒット率99%) | $0.0008 | $0.0013 | | MediaLive構成の視聴者側小計 | $0.1511 | $0.2518 | 視聴者側はどの解像度でもIVSが安く、差は720pで1人1時間あたり0.0591 USDです。配信側は構成によって向きが変わるため、必要な画質で場合分けします。MediaLive側の配信側費用には、MediaPackageの取り込み料金（出力ラダーの合計ビットレートぶん。720p運用ならHD 3 Mbps＋SD 1 Mbpsで1時間あたり約1.76 GB、0.044 USD/GBで0.0773 USD）を足しています。 ### 720p要件での料金比較（無料枠を除外した前提） 720pが上限でよいなら、IVSの選択肢はADVANCED\_HDです。配信側は0.85 USD対MediaLive構成の1.4417 USD、視聴者側は0.0920 USD対0.1511 USDで、**無料枠を除外し前掲のビットレートと初段単価で計算するこの条件では、両側ともIVSが安く、分岐点は現れません。**この試算条件のもとでMediaLive + MediaPackage v2を選ぶ理由は機能要件です。CloudFrontの無料枠に収まる規模なら、費用の優劣は改めて計算し直してください。 ### 1080p・単一トラック入力での損益分岐と試算条件 フルHDまで配信するならIVS側はSTANDARDになります。単一トラック入力の場合、配信側はIVSが2.00 USD、MediaLive構成が1.4804 USD（出力ラダーが合計6 Mbpsになるため取り込みは約2.64 GB分の0.1160 USD）で、差は0.5196 USDです。視聴者側の差は1080pで0.0678 USDなので、割ると約7.7になります。**平均同時視聴が8人前後でIVSが追い越します。**ここは換算方法に敏感で、10進換算で計算し直すと約7.0人になります。人数の境界そのものより、自社の実測転送量で計算し直す手順を残してください。 ただしOBSのマルチトラックビデオを使えるなら、IVS STANDARDの入力は0.50 USDに下がります。そうなると配信側でもIVSがMediaLive構成を下回るため、1080pでも分岐点は消えます。 これらの数字は前提に依存します。CloudFrontの従量課金には毎月1 TBの無料枠があり、その枠内に収まる規模なら転送料金が計上されず、MediaLive構成が相対的に有利になります。無料枠の数え方には注意が要ります。AWSのFAQは、一括請求（コンソリデーティッドビリング）を使っていても**各組織につき1つの無料利用枠だけ**と明記しており、アカウントを増やして枠を増やすことはできません。無効化やLambda@Edge、Origin Shield、オリジンへのデータ転送は無料枠の対象外です。キャッシュヒット率を下げれば分岐点は手前へ、CloudFrontの単価交渉が効けば奥へ動きます。**数字そのものより、必要な画質と視聴規模を決めてから両方を計算し直す、という順番を守ってください。**費用の考え方は[動画配信システムとは？仕組み・配信方式と、ASP/自社開発の選び方を受託開発目線で解説](/column/details/15267/)でも整理しています。 ### 停止中でも止まらないアイドル課金 MediaLiveで見落とされやすいのがアイドル課金です。AWSのドキュメントは、実行中でないチャネルに対する「アイドルチャネル料金」と、チャネルに接続されていないプッシュ入力、およびチャネルに接続されていても当該チャネルが実行中でないプッシュ入力に対する「アイドルプッシュ入力料金」が発生すると明記しています。プル入力にアイドル料金はかかりません。 課金の刻みも押さえておきます。稼働リソースの所要時間は最低10分で、それ以降は1分単位に切り上げられます。5分だけ試したつもりでも10分として請求されるため、短いテストを何度も回す使い方ではここが効きます。東京リージョンのアイドル単価は、チャネル側もプッシュ入力側も1時間あたり0.01 USDです。単価は小さいものの、検証用のチャネルと入力を消さずに残すほど積み上がるため、使い終わったら削除まで済ませる運用にしてください。 実行中の課金にも独特の規則があります。出力料金は、ユーザーが一時停止した出力に対しても発生します。入力料金も、チャネルに接続されていれば現在アクティブでない入力や、コンテンツを受信していない入力に対して発生します。「使っていないから課金されない」は成り立ちません。 ## 遅延を詰める設計と配信トラブルの切り分け 配信が始まった後に出る問題のうち、ここでは遅延、ドロップフレーム、音ズレの3つを扱います。原因の層が違うので、切り分けの順番を決めておきます。 ### 取り込みプロトコルの選択 OBS Studio 32.2.2（2026年8月14日リリース）から**IVSのチャネル**へ送る場合、公式に挙げられている取り込みプロトコルはRTMP、RTMPS、SRTの3つです。SRTは不安定な回線でのジッターやパケットロスに強い設計で、モバイル回線や長距離の中継で効きます。安定した有線環境ならRTMPSで十分です。 OBSは30.0.0（2023年11月12日）でWHIP/WebRTC出力を追加し、32.1.0（2026年3月11日）ではWebRTCのサイマルキャストにも対応しました。WHIPの送り先になるのはチャネルではなく**IVSのステージ**で、AWSはOBSからステージへWHIPで配信する手順を別途公開しています。300ミリ秒未満の双方向配信が要件ならこちらです。プロトコルごとの違いは[ストリーミングとは？仕組み・種類・配信を支える技術をわかりやすく解説](/column/details/8331/)で全体像を押さえられます。 ### 遅延の内訳と現実的な着地点 IVSのチャネル配信で到達できる遅延は5秒未満です。遅延は配信構成と再生環境で変わります。ここで重要な条件が1つあります。**この低遅延を得るにはAmazon IVSプレイヤーを使う必要があります。**AWSは性能を保証できるプレイヤーはIVSプレイヤーだけだと明記しており、サードパーティのプレイヤーでもBASICとSTANDARDのチャネルなら、AWSが示す設定で**約10秒までは短縮できるとされています**。その設定とは、エンコーダーのキーフレーム間隔を2秒以下にし、RTMP(S)のURLへ`?keyframeInterval=2`を付ける組み合わせです（URL側の値はエンコーダーの設定値以上で、2から6の整数。ADVANCEDのチャネルではこの指定は不要で、キーフレーム間隔は自動生成されます）。iOS Safariの場合は、IVSプレイヤーをサービスワーカー構成で使うと約6〜8秒まで下がる、というのが公式の目安です。サードパーティのプレイヤーを使う前提なら5秒未満は見込まず、AWSが示す約10秒を目安に置いて実機で遅延を測ってください。あわせてAWSは、第三者の再配信サービスや転送サービスを経由してIVSへ送らないよう強く推奨しています。中継を挟むと、その分の遅延が素直に上乗せされるためです。 MediaLive構成で遅延を詰めるなら、MediaPackage側のエンドポイントをLL-HLSにします。AWSのドキュメントは、標準のHLSが一般に18〜30秒の遅延になるのに対し、LL-HLSは3〜5秒まで下げられるとしています。ただしLL-HLSでは`EXT-X-PROGRAM-DATE-TIME`が任意ではなく必須になり、低遅延拡張に対応したプレイヤーが要ります。プレイヤー側の制約を確認せずにエンドポイントだけ切り替えても効果は出ません。 1秒を切る体験が必要な場合、チャネル配信の調整では届きません。300ミリ秒未満を狙うならIVSのステージを使う設計に切り替えます。自前で低遅延配信基盤を組む選択肢を検討する段階なら、[動画配信システムのオープンソース8製品｜ライセンス条件と自前運用の限界を実装目線で判定](/tech/details/16500/)で運用負荷の見積もりと併せて比較してください。 ### ドロップフレームと音ズレの切り分け OBSの統計にドロップフレームが出ている場合、映像がAWSに届く前に失われています。最初に確認するのは次の3点です。 - レート制御がVBRになっていないか。VBRはビットレートのスパイクを起こし、AWSへ到達する前のフレーム落ちの原因になります。 - 上り帯域が足りているか。AWSは必要最小帯域の1.5倍を確保するよう推奨しています。6 Mbpsで送るなら9 Mbpsの上りが目安です。 - 無線を使っていないか。WiFiとLTEは干渉やパケットキューの優先制御によって遅延が増えるため、AWSは有線接続を推奨しています。 配信そのものが落ちる場合は、切れるまでの時間が手がかりになります。IVSはエンコーダーからのデータが途絶えると30秒待ち、その間に何も届かなければ切断します。回線の瞬断が原因ならこの30秒が目安です。接続直後に落ちるときは入力ビットレートや解像度が上限を超えていないかを先に疑い、チャネルタイプの制限値と突き合わせてください。長時間配信では別の上限もあり、IVSのストリームは48時間で終了して切断されます。 音声と映像のズレは、入力機器、OBSのエンコード、ネットワーク、再生側のどこでも起こります。OBSの音声詳細プロパティにある同期オフセットで補正できますが、当てる前に切り分けてください。まずローカル録画でズレが出るかを見ます。録画にもOBSの取り込みとエンコードが含まれるため、これで切り分けられるのは「OBSまでで既にズレているか」までです。録画は正常で配信だけズレる場合も、OBSは録画と配信で別のエンコーダー設定を持てるので、配信側の設定差と配信経路の両方を疑います。あわせて音声のサンプリングレートが44.1 kHzか48 kHzのどちらかに揃っているかを確認します。オフセットは原因を特定してから当てないと、環境が変わるたびに調整し直すことになります。 ## よくある質問 ### OBSからAWSへ送るとき、RTMPとRTMPSのどちらを使うべきですか？ 送り先によって答えが変わります。Amazon IVSへはRTMPSです。AWSは検証済みの特定のユースケースがない限りRTMPSを使うよう推奨しており、取り込みにはTLS 1.2以降とポート443が必要です。一方でMediaLiveのRTMP入力はRTMPSを受け付けません。MediaLive構成で経路の暗号化が必要なら、SRTリスナー入力かMediaConnect経由へ切り替えることになります。 ### AWSのライブ配信はどのくらい遅延しますか？ Amazon IVSのチャネル配信で5秒未満、ステージを使った双方向配信で300ミリ秒未満です。ただし5秒未満はAmazon IVSプレイヤーを使うことが前提で、サードパーティのプレイヤーではBASICとSTANDARDのチャネルで約10秒、iOS Safariではサービスワーカー構成で約6〜8秒が公式の目安です。従来型のOTT配信は最大30秒に達することがあるため、同じHLSベースでも設計次第で大きく変わります。実際の遅延は配信者と視聴者の地理的な距離、回線の種類と速度、配信経路の各コンポーネント、使用するプロトコルと出力形式によって変動します。 ### 配信中にドロップフレームが出るときはどこを見ますか？ OBSの統計でネットワーク起因のドロップかどうかを確かめたうえで、本文の「CBR固定とVBVの制約」と「ドロップフレームと音ズレの切り分け」の順に設定と回線を当たってください。 ### 1回の配信を複数のプラットフォームへ同時に流せますか？ MediaLive構成なら可能です。1つのチャネルに複数の出力グループを設定し、MediaPackageへのHLS出力と外部プラットフォームへのRTMP出力を併存させます。ただしMediaLiveは出力ごとに課金されるため、出力を1本増やすと時間単価がその分上がります。東京リージョンで10 Mbps未満・30fps以下・標準品質のHD出力を1本足すと、シングルパイプラインで1時間あたり0.7452 USDの加算です。外部プラットフォームへ直接送る場合は、これとは別にインターネットへのデータ転送料金がかかります。 ### 縦型（ポートレート）配信はAWSで扱えますか？ 扱えます。IVSの解像度上限は総画素数2.1メガピクセル、1辺あたり1920画素で定義されているため、1080×1920の縦向きもこの条件を満たします。ビットレートとフレームレートの推奨値は横向きの表を縦横反転して読み替えます。ただしビットレート上限はチャネルタイプ側の制約が別にかかるため、STANDARDなら8.5 Mbps、BASICの480p超なら3.5 Mbpsを超えないようにしてください。 ## 関連記事 - [Amazon Interactive Video Service（IVS）とは何か？特徴と概要を徹底解説](/tech/details/9696/) - [OBS Studioは安全か？公式サイトの見分け方とプラグイン改ざん事件の影響範囲【2026年】](/tech/details/11319/) - [動画配信システムのオープンソース8製品｜ライセンス条件と自前運用の限界を実装目線で判定](/tech/details/16500/) - [動画配信システムとは？仕組み・配信方式と、ASP/自社開発の選び方を受託開発目線で解説](/column/details/15267/) - [ストリーミングとは？仕組み・種類・配信を支える技術をわかりやすく解説](/column/details/8331/) --- 出典: [AWSとOBSでライブ配信基盤を構築する手順｜IVSとMediaLiveの選び方・東京リージョンの料金試算]()（株式会社一創）