re:Invent 2025: CloudFrontによる大規模ストリーミング配信の監視・セキュリティ・収益化設計
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Streaming at Scale: Advanced Media Delivery with Amazon CloudFront (NET307)
この動画では、AWS SpecialistソリューションアーキテクトのJamie MullanとJohn Councilman、そしてNESNのJess Palmerが、大規模ライブイベントのストリーミング配信について解説しています。Amazon CloudFrontを中心に、監視、セキュリティ、スケーラビリティ、収益化の4つの観点から設計上の決定事項を詳述。CloudWatch、Kinesis、CMCDを活用した可視性の確保、WAF、CloudFront Functions、トークン化によるコンテンツ保護、Embedded POPsやOrigin Shieldによるオリジン負荷軽減、AWS Elemental Media ServicesとMedia Quality Aware Resiliency（MQAR）を用いた自動フェイルオーバー、MediaConnectによる信頼性の高いインジェスト、そしてMediaTailorを使った動的広告挿入まで、実践的なアーキテクチャパターンが網羅されています。NESNの実例も交え、小規模チームでも高品質な配信を実現する方法を示しています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
大規模ストリーミング配信の課題とAmazon CloudFrontの活用
おはようございます。本日はご参加いただきありがとうございます。今回のセッションでは、スケール時のストリーミングについて主にお話しし、その配信に Amazon CloudFront を活用することに焦点を当てます。 私は AWS のスペシャリスト・ソリューションズ・アーキテクトの Jamie Mullan です。同じくスペシャリスト・ソリューションズ・アーキテクトの同僚 John Councilman と一緒にいます。また、NESN の Jess Palmer も参加しており、彼らにとってスケールが何を意味するのかについてお話しいただきます。大規模なイベント、絶対に問題なく配信されなければならない重要なイベント、そして世界中の多くの視聴者がいるイベントについて考えていきます。
簡単ですよね。コントリビューション・フィードがあって、それを処理して、視聴者に配信するだけです。それだけです。他に何が必要ですか？ まあ、実はもう少し複雑なんです。 その配信に影響を与える設計上の決定事項をいくつか見ていきます。 しかし、スケールは顧客によって異なる意味を持つことができます。例えば、数百万の同時視聴者かもしれませんし、数十億分のコンテンツ消費かもしれません。 しかし、スケールがどうであれ、私たちは顧客からよく次のような質問を受けます。配信をどのように監視するのか。エッジでコンテンツをどのように保護するのか。高い稼働率でグローバル・オーディエンスにどのようにスケールするのか。そして最後に、ライブ・コンテンツをどのように収益化できるのか。
イベントを成功させるために、どのようなアーキテクチャ上の決定を下す必要があるのか、と疑問に思われるかもしれません。本日のセッションは正にそのためのものですので、ご安心ください。 しかし、ビデオ・アーキテクトやソリューション・アーキテクト、ビデオ・エンジニアとして、もし私たちが仕事を間違えたらどうなるでしょうか。視聴者はピクセル化を経験したり、視聴体験が低下したり、そして最も イライラさせられるのは、あのくるくる回るバッファー・ホイールです。 本日は、主に Amazon CloudFront を通じたコンテンツ配信に焦点を当てます。CloudFront をご存じない方のために説明すると、CloudFront は私たちのコンテンツ・デリバリー・ネットワーク、つまり CDN です。CloudFront は 750 以上のエッジ・ロケーションを持つ大規模なグローバル・ネットワークです。すべてのエッジ・ロケーションは、AWS リージョンに戻る冗長でプライベートなバックボーン経由で接続されています。
CloudFront は、ビデオ・ファイルや画像ファイル、CSS、JavaScript などの静的アセットなど、あらゆるタイプのアプリケーションを高速化するために使用できます。これらはエッジ・ロケーションにキャッシュされ、エンドユーザーにより近い場所から配信されます。CloudFront は動的なトラフィック・リクエストにも使用できます。本日のトークは、このスチール・スレッド・アーキテクチャを中心に展開され、ワークフロー全体を通じてさまざまな設計上の決定事項を見ていきます。ビデオ関係の皆様への事前通知ですが、今回は下流から始めます。まず、配信を見ていきます。 ご存じのように、OTT プロバイダーの中には、サブスクリプションや従量課金制など、コストをかけてこれらのストリームを配信する企業もあります。ですから、当然のことながら、セキュリティとコンテンツ保護について気になります。
次に、エンコーダー・オリジネーションを見ていきます。 大規模なイベント、特に大規模なスポーツ・イベントの場合、これは本当に重要です。イベントが正常に配信されるようにワークフローを設計したいのです。 そして最後に、インジェストを見ていきます。 シンプルに言えば、フィードがなければ、イベントもないということです。インジェストをより信頼性の高いものにするためのさまざまな方法を探っていきます。しかし、最初に取り組むのは監視であり、イベントが実際に正常に配信されているかどうかをどのように知るのかという質問です。
CloudWatchダッシュボードとリアルタイムログによる監視体制の構築
AWS のソリューションアーキテクトです。ライブイベントがどの程度成功したかを測定する方法を見ていきたいと思います。ここで見ることができるように、私たちのプラットフォームから利用可能なデータがたくさんあります。exit errors、video start failures、rebuffering といったものです。 こうしたデータの多くは、ビデオプレイヤー自体から来ているか、CloudFront から来ています。これはログまたはビーコンとして提示されることもあります。様々な方向から来ています。私たちはたくさんのデータを持っていますが、これは良い面もあれば悪い面もあります。データがたくさんあるんです。では、これらすべてにどう対処するのか。CloudFront のいくつかの機能と他の AWS サービスを見て、実際にすべてを理解する方法を探っていきます。
まず最初に、すべてのイベントには良いデータが必要です。ダッシュボードが必要です。ログへのリアルタイムアクセスが必要で、イベント後に分析できる必要があります。まず、メトリクスについてですが、CloudFront は実は CloudWatch を使ってメトリクスを配信しています。私は CloudWatch ダッシュボードを使うのが好きです。
これを実際の車のダッシュボードのようなものだと考えています。キャンプに行くときは、実はトレーラーを引っ張るんですが、ダッシュボードの 2 つのゲージを常に見ています。燃料レベルを見ています。というのも、私の車は 5 MPG くらいしか出ないので、トランスミッションの温度も見ています。毎日トレーラーを引っ張るわけではないので、問題があれば、何を見るべきかが正確にわかります。温度が高くなりすぎたら、ガスを入れる必要はないんです。実は、トランスミッションのために立ち止まる必要があるんです。
ストリーミングイベントも同じことが言えます。ほとんどのイベントは数時間しか続きません。スポーツイベントの場合、origin に問題があるのか、CloudFront に問題があるのか、それとも DRM や advertising のような何かを使っている場合、 それがストリームに影響を与えているのか、すぐに知る必要があります。ダッシュボードは最初の防衛線なので、どこを見るべきか、どこをさらに深く掘り下げるべきかがわかります。
さらに深く掘り下げるといえば、CloudFront は real-time access logs をサポートしており、ここで見ることができるように、実は Amazon Kinesis を使ってこれを配信しています。 何百万人ものビューアーのためにリアルタイムログを配信することは非常に難しいです。Kinesis はまさにこのために設計されています。CloudFront で real-time logs を設定すると、Kinesis エンドポイントを求められます。Kinesis の良いところは、複数のコンシューマーがそのデータを並行して取得できるということです。つまり、リアルタイムダッシュボードを持つことができます。observability プラットフォーム、analytics プラットフォームを持つことができます。また、このデータをリアルタイムでパートナーと共有することもできます。彼らがリアルタイムで viewership を見ているか、advertising データを見ていて、リアルタイムでその情報が必要な場合です。
このリアルタイムデータを使うことで、問題が大きくなる前に気づくことができて、それに対応することができます。必要に応じてプラットフォームをリアルタイムで調整して、こうした最大規模のイベントに対応することができます。そして最後に、アクセスログはここで見られるようにS3にバッチで保存されます。遅延は通常数分程度です。S3の良いところは、Athenaを連携させることで、これらのログすべてを標準SQLを使ってクエリできるということです。S3バケットにライフサイクルを設定することで、数週間前、あるいは数年前のイベントをアーカイブストレージに保存しておくことができます。そうすることで、以前のイベントと1週間前、あるいは1ヶ月前に行ったイベントを比較して、どれだけ改善されたかを確認し、学んだ教訓を見つけることができます。
事後的にトラブルシューティングを行うことができます。Athenaを使ってレポートも簡単に取得できます。そして最後に、コンソールレポートです。これはCloudFrontコンソールにあります。トレンドやビューアーシップ、イベント間のキャッシュヒット率、月次レポートなどを把握するのに便利です。これもいつでも利用できます。
CMCDによるクライアント情報とCDN情報の統合
CloudFrontとそのログについて多く話してきましたが、通常CloudFrontがアクセスできるのはHTTPヘッダーまたはジオ情報に含まれるもの、例えばユーザーエージェント、クライアントのIPアドレス、ジオリージョン、ASN、キャッシュステータスなどです。これらは常にログに記録されています。リアルタイムログであってもS3ログであっても同じです。しかし、先ほど触れたクライアントについては、スループットのような非常に価値のある情報をたくさん持っています。クライアント、つまりDASH.JSやHLS.JSのようなプレイヤーは、ホームのインターネット帯域幅に基づいてどのビデオビットレートを取得するかについて判断を下しています。セッションIDとコンテンツIDと一緒にそのような情報を持つことは、何が起こっているのかを把握するために非常に価値があります。
しかし、過去には、この情報はサードパーティのSDKを使ってのみ利用可能で、ビーコンを使って他のプラットフォームに送信されていました。つまり、CloudFrontやCDNログが一つのバケットにあり、プレイヤー情報がまた別のバケットにあり、本当にこの二つを結びつける方法がありませんでした。信じてください、それは非常に難しいです。できないわけではありませんが、簡単ではありません。しかし、ビットレートの使用状況、セッションID、どのレンディション、HDか標準画質かといったクライアント情報をすべて組み合わせ、HTTPヘッダー、ユーザーエージェント、IPアドレスといったCloudFrontが知っているすべての情報と組み合わせる方法があったらどうでしょう？
それがまさにCMCD、Common Media Client Dataが解決しようとしているものです。実は、これはCTA Waveによって作成された標準で、CTA Waveは他にも多くの標準を作成しており、Jamieが後で話す予定です。ほぼすべてのCDMがこれに準拠していて、プレイヤーもこれについて知っています。CMCDを使うことで、このすべての情報が同じログ行に保持されます。このすべてのコンテンツID、セッションIDはクエリストリングまたはヘッダーとしてCDNに送信されます。標準化されているので、すでに何をすべきかわかっています。使用しているかもしれない監視プラットフォームのパートナーの多くは、すでにCMCDの扱い方を知っています。
CloudFront は以前から CMCD をサポートしていました。左側を見てください。これはリアルタイムログの設定です。 ご覧の通り、ここに標準的な CMCD フィールドが追加されています。すべて CMCD というプレフィックスが付いています。
クライアントが送信している内容に応じて、これらの中から 1 つ、いくつか、またはすべてを選択できます。これらの情報はすべて、Kinesis に送信されるリアルタイムログに追加されます。多くのパートナーがすでにログプラットフォームでこれをサポートしており、ログ行のこの追加情報を処理する方法を知っているリファレンスサンプルがあります。このサンプルにはリアルタイムダッシュボードがあり、すべてのデータに基づいてリアルタイムで更新され、クライアントと CDN で何が起こっているかを正確に表示します。
ここの QR コードをスキャンするか、「video observability with CMCD and CloudFront」で検索して、自分のディストリビューションで試してみることができます。リファレンスサンプルなので、無料で使用でき、オープンソースなので編集することもできます。CMCD は簡単です。CloudFront のリアルタイムログで見たように、これらの追加フィールドを追加して、それにアクセスする方法を知っているコンシューマーダッシュボードを用意するだけです。
今日使用しているかもしれないプレイヤーの例をいくつか紹介します。これらは 2 つの人気のあるオープンソースプレイヤーです。HLS.JS と DASH.JS です。CMCD の設定は、プレイヤーをインスタンス化するときにいくつかのキーバリューペアを追加するだけです。私がよく知っている HLS.JS の場合、それは単に CMCD 構造です。左側に特に注目してください。セッション ID があります。これは標準的な CMCD フィールドであり、非常に有用です。今日 CMCD を使用していてセッション ID を使用していない場合は、ぜひ使用することをお勧めします。
セッション ID は通常、ユーザーがセッションを開始するときにコンテンツ管理システムからそのユーザーのために取得されます。このセッション ID をフィールドに含めると、特定のユーザーに関連付けられたすべてのログを見つけることができるので、ストリームの再生開始から終了まで、個々のユーザーのジャーニーを確認できます。ビットレートを何回切り替えたか、リバッファリングが何回発生したか、スタールが何回発生したかを確認できます。これにより、個々のユーザーのジャーニーを把握してから、同じ情報を使用してセッション ID に基づいて他のユーザーのジャーニーを見つけることができます。以前はクライアント情報と CDN 情報が別々の場所に保存されていたため、これは不可能でした。だからこれは本当に簡単になりました。
不正ユーザーからコンテンツを守るセキュリティ対策
では、セキュリティ要件についてお話しします。 CloudFront ディストリビューションに可視性を追加しました。すべてのユーザー、つまり正規のユーザーが最高のエクスペリエンスを受け取ることを確認したいのです。しかし、ストリームを盗もうとしたり、コンテンツを削除したり、サービスに害を加えようとしている不正なユーザーにはコンテンツを受け取ってほしくありませんし、他のユーザーが経験しているエクスペリエンスを損なわせたくないのです。
こうしたユーザーはどのような姿をしているのでしょうか。理想的には、完璧な世界では、 CloudFront の背後にオリジンサーバーがあります。CloudFront は標準的な URL、この場合は HLS index.m3u8 を配信し、すべての有料ユーザーまたはサブスクライブしているユーザーがコンテンツをプルします。しかし、ご存知の通り、実際はそうではありません。 コンテンツを再ストリーミングしようとするユーザーが見られます。彼らは特定の IP アドレスからコンテンツをプルしている有料の正規ユーザーであり、その後、おそらく彼らに料金を支払っているユーザーに再ストリーミングしています。明らかに、これは望ましくありません。
その次に、無効なリージョンがあります。 スケーラビリティの目的で別の国で動作するようにインフラストラクチャを設計していないだけでなく、無効なリージョンからのビューアーがいると、統計情報が狂ってしまいます。彼らは悪いエクスペリエンスを受けている可能性があり、イベントが成功したかどうかの分析に影響を与えるでしょう。高レイテンシー数を伴う国外からのビューアーが見られる場合、それはすべてのレポートに影響を与えるでしょう。
コンテンツを契約で指定された特定のリージョンでのみ配信できる国の外に配信することに対して、法的な結果さえあるかもしれません。スポーツイベントの場合は特定の州でのみ配信する権利があるかもしれませんし、特定の国でのみ配信する権利があるかもしれません。過去に Olympics に関わるお客様と対応した経験から、リージョンに関しては契約が非常に具体的であり、そのコンテンツを配信するために必要なセキュリティも同様です。ですから、ライツホルダーは非常に重要です。
そして最後に、CloudFront の制限を何らかの方法で回避して、オリジンに直接アクセスできるようになった未払いのユーザーがいます。明らかに、これは望ましくありません。しかし、オリジンにアクセスできる場合、それはすべての人のエクスペリエンスに影響を与えるでしょう。なぜなら、オリジンは CloudFront の背後で保護されるべきであり、CloudFront がキャッシュからトラフィックの 99 パーセント以上を提供するべきだからです。 オリジンサーバーがコンテンツを直接配信することはあってはならないのです。
では、私たちが利用できるツールには何があるでしょうか？まず、私の息子は7歳なんですが、最近学校から帰宅していて、本来は見てはいけない時間に YouTube をストリーミングする方法を見つけようとするんです。そこで、ホームネットワークのファイアウォールルールを使ってみたんですが、結局のところ、リモコンをオフィスに鍵をかけて保管し、ネットワークをセキュアにしました。これらが私が利用できるツールなんですが、当然のことながら CloudFront では物理的な鍵はありません。しかし、トラフィックを制限する方法はあります。
まず、CloudFront コンソールを使ったことがある人なら、おそらく組み込みの地理的制限に気づいているでしょう。これはコンソール内またはAPI経由でディストリビューションに組み込まれています。これは特定のリージョンを素早く許可または拒否する方法です。例えば、米国でのみコンテンツを配信することが許可されている場合、CloudFront に移動して、米国のみを許可するように地理的制限を素早く追加することができます。または、その中で特定の国をブロックすることもできます。
その上に追加できる次のレイヤーは、私たちのツールキットの次のツールです。AWS Web Application Firewall、つまり WAF です。 WAF を使えば、ヘッダーや IP アドレスなど、入ってくるものすべてをリストに照らし合わせて検査することができます。また、購読できるリストもあるので、マネージドリストがあります。地理的制限で特定のリージョンを許可することはできますが、VPN やプロキシを使ってストリームにアクセスしているユーザーはどうでしょうか？WAF を使えば、実は既知の VPN エンドポイントと既知のプロキシエンドポイントのリストを購読することができます。リストリーマーの場合、例えば彼らの IP アドレスは 1.2.3.4 でした。 イベント中に、その IP アドレスを自分たちのマネージドリストに追加して、リストリーミングしているユーザーをブロックすることができます。WAF はイベントの前、最中、そして後に本当に役立ちます。何か特定のことに気づいたら、次のイベントのためにルールを後から追加することができます。または、リストリーマーの場合のように、実はイベント中に修正することができます。
そして最後に、地理的制限と WAF を超えたもの全てについては、CloudFront Functions があります。 CloudFront Functions は実は JavaScript としてエッジサーバー上で実行されます。これらは非常に低レイテンシーで高パフォーマンスです。CloudFront から、または CloudFront とオリジン間で行き来するリクエストとレスポンスを分析することができます。また、キーバリューストアも追加しました。つまり、API を使ってキーバリューストアにデータを追加し、エッジ関数でそれをクエリすることができます。セキュリティに関してこれが何に使えるかについて、詳しく説明するのは今からです。
オリジンのセキュア化とCloudFront Functionsによるトークン認証
では、オリジンをどのようにセキュアにするのかについてお話しします。ご存知の通り、CloudFront はオリジンに依存しないので、オリジンはどこにでも置くことができます。まず、オリジンがオンプレミスにある場合、ほとんどの場合パブリックサブネット上にあります。当然ながら、ユーザーが直接アクセスするのは避けたいですね。なぜなら、それは全員のエクスペリエンスに影響を与えるからです。最初にできることは、CloudFront でオリジンを設定する際に、オリジンレベルで HTTP ヘッダーを活用することです。シークレットヘッダーをオリジンに送信することができ、オリジンはそれを検証して、これが実際に CloudFront から来ているのかを確認できます。また、CloudFront エッジサーバーの既知の IP アドレスのリストを公開しており、これをオンプレミスまたはオリジン自体のファイアウォールに追加して、CloudFront だけがアクセスできるようにすることができます。
次に、Application Load Balancer や Network Load Balancer のようなものを使用していて、その背後に EC2 インスタンスがあってそれがオリジンになっている場合、CloudFront は VPC origins を活用できるようになりました。皆さんがこれを知っているかどうかはわかりませんが、最近では cross-account VPC origins も導入しました。複数のアカウントを使用している場合、CloudFront は他のアカウントの VPC 上のこれらのオリジンにアクセスできます。それがあなたのアカウントであろうと、パートナーアカウントであろうと、これは本当に大きなことです。なぜなら、オリジンがパブリックサブネット上にない場合、そもそもアクセスできないからです。
そして最後に、メディアを配信する一部のマネージドサービスについては、多くの皆さんが S3 をライブおよびオンデマンドメディア配信に使用しており、AWS Elemental MediaPackage も同様です。これらは Origin Access Control を使用できます。これは CloudFront だけがサインされた URL を使用してそのコンテンツにアクセスできるようにする特定のルールセットです。
CloudFront Functions について言及しましたが、WAF とジオ制限を超えてセキュリティを拡張するためにもっと詳しく説明します。多くのお客様が Functions 内でトークン化を使用してコンテンツをさらにセキュアにしているのを見かけます。トークンは通常 JWT を使用しますが、かなり多くのフォーマットがあります。Functions を使用すれば、柔軟に対応できます。基本的には、JWT であろうと、他の CDN 全体で使用するカスタムトークンであろうと、どのようなメカニズムでも実装できます。 トークンの内側には、基本的にあなたが誰であり、何を見ることができるのか、例えばコンテンツ ID のような情報が記述されています。時間制限もあります。JWT の場合、ライフタイムを設定するのは非常に簡単です。このトークンは 1 時間、2 時間、または丸一日だけ有効です。また、どこで何を見ることができるのかについての指示も提供します。
理想的には、有効なトークンを持つユーザーがすべてのヘッダー情報と IP アドレス情報を CloudFront に送信します。CloudFront で設定されているジオヘッダーを使用してジオ情報を検索でき、トークンには特定の場所、例えば米国の州から見ることができるものについてのすべての情報が含まれています。特定の IP アドレスまたはユーザーエージェントに紐付けられており、関数はこれらすべてをトークンと CloudFront が知っているユーザー情報に対して検証します。すべてが一致し、トークンが転送中に変更されておらず、トークンが期限切れになっていない場合、関数から 200 OK を返します。
次に、無効なトークンを持つユーザーがいます。おそらくトークンを改ざんして自分たちで作成しようとしたが、正しく署名されていないため無効になっているか、あるいは無効な場所からアクセスしているかもしれません。有効なトークンを持って自宅での使用のために署名されたトークンで移動したが、現在はセルラーネットワークにいて新しいトークンを受け取っていないという場合もあります。関数自体から 401 Unauthorized レスポンスを返すか生成して、CloudFront やオリジンサーバーにアクセスする前にそのユーザーを即座に拒否します。
最後に、共有トークンを持つユーザーがいます。これらの例はすべて JWT を使用しており、これは非常に一般的で関数で簡単に実装できます。このユーザーは最初のユーザーから有効なトークンを受け取り、それを再利用しようとしています。同じ近所に住んでいて同じデバイスを使用しているため、何らかの理由で有効になっている可能性があります。このトークンが複数回使用されており、有効ではないことに気付きます。実際にこのトークン値をキーバリューストアに追加することができます。
これはキーバリューストアと関数の良いユースケースです。トークン失効です。何か問題があり、複数回使用されているトークンに気付いたときに、そのトークンをキーバリューストアに挿入することができます。その後、そのトークンがキーバリューストアに含まれている場合、関数は 403 Forbidden を返すことができます。これは JWT トークンを使用したトークン化でよく見られるユースケースです。ただし、re:Invent の直前に CBOR トークンサポートをリリースしたばかりで、これは CTA Wave によって作成された Common Access Tokens に必要です。関数で完全なトークン認証ワークフローを書き出す方法を考え出す代わりに、関数でモジュールとしてサポートされている CBOR に直接結合することができます。コードは非常に最小限で、わずか数行なので、これはネイティブにサポートされています。Common Access Tokens は業界の進む方向のようです。なぜなら、これは標準化されたからです。
AWS でのエッジでのセキュアなメディア配信に関するガイダンスがあります。これは関数で行ったすべての作業を実行してくれます。CloudFront ディストリビューションにこれをデプロイするだけで、JWT トークンサポートをサポートするすべての関数がデプロイされます。自動的に不正に使用されているトークン、複数回使用されているか無効なユーザーからのトークンを失効させることができるステップ関数も利用可能です。ビデオプレイヤーを備えた完全な再生アプリケーションサンプルも追加しました。これを自分のディストリビューションに CloudFormation を使用してデプロイするだけで、オープンソースなので自由に変更できます。コンテンツ管理システム用の SDK も含めて、再生 URL を作成するときにトークンを作成して署名することができます。実は Common Access Tokens のサポートをこの中で本当にすぐに有効にする予定なので、アップデートに注目してください。
Embedded POPsとOrigin Shieldによるラストマイル容量の最適化
これで Jamie にバトンタッチして、ラストマイル容量についてのお話をしてもらいます。大規模なイベントは非常に短い期間にかなりのインターネットトラフィックスパイクを生成でき、視聴者をコンテンツに接続するネットワークリンクに負荷をかけます。ただし、実際にはインターネットエクスチェンジ自体と ISP または小さな都市の間に一定の容量しかないかもしれません。ISP は継続的にネットワークを最適化していますが、これらの最後の瞬間の大きなイベント向けに容量をスケーリングすることは理解できるように困難です。特にその短い期間だけその容量が必要なイベントの場合はそうです。
ネットワークが飽和状態になったり、混雑したりすると、パケット損失と遅延の増加が発生する可能性があり、その結果、視聴者の体験に対しては、画質の低下、再バッファリング、さらには再生失敗といった問題が生じます。先ほど説明されたモニタリングアプローチに頼ることで、こうした問題の一部を特定するのに役立つかもしれません。しかし、ネットワークや基盤となるネットワークを ISP プロバイダーとして所有していない限り、これは実質的にあなたのコントロール外にあるものです。しかし、昨年、私たちは embedded POPs を導入しました。これらはこの課題を克服し、エンドユーザーにより近づくことで、ISP ネットワーク内に直接コンテンツをキャッシュし、視聴者とインターネットエクスチェンジ間のネットワークリンクへの依存性を軽減します。
私たちは 20 か国以上の 100 を超える ISP にまたがる 1,140 以上の場所に embedded POPs を配置しています。エンドユーザーまでの距離を短縮することで、既に embedded POPs を導入している顧客は、パフォーマンスの向上を実現しています。ネットワークへの依存性を軽減できるため、キャッシュ可能性の高いコンテンツに非常に適しています。現在、メディアとエンターテインメント分野に非常に注力していますが、ゲーム配信やソフトウェアダウンロードといったコンテンツにも使用できます。
embedded POPs のオンボーディングの一環として、使用したいワークフローを検証します。それが適切な場合、配信はバックエンドで私たちが有効にします。ただし、クライアントアプリケーションが embedded POPs にルーティングできるようにするために、あなたの側で追加の作業が必要です。これを行うことをお勧めする方法は、クライアントルーティング SDK を URL vending service に統合することです。
では、これはどのように機能するのでしょうか。まず、クライアントルーティング SDK を URL vending service に統合する必要があります。右下の QR コードは、興味があれば確認できる GitHub のそのリンクです。クライアントアプリケーションが vending service に URL をリクエストすると、クライアント IP が URL にエンコードされ、このダイアグラムで CR ラベルとして注釈が付けられます。
その後、クライアントは DNS ルックアップを実行し、Route 53 と CloudFront はその CR ラベルからクライアント IP をデコードできます。CloudFront はその後、クライアント IP に基づいて最適な POP を返します。それが適切な場合は embedded POP であるか、従来の POP であるかのいずれかです。その後、クライアントは CloudFront からコンテンツのフェッチを開始できます。要するに、embedded POPs は ISP ネットワークから直接キャッシュされたコンテンツを配信し、パフォーマンスを向上させ、発生する可能性のあるラストマイル容量の制約を克服します。
embedded POP を活用したいのであれば、ぜひアカウントチームに連絡して、ワークロードが適切かどうかを検証・評価するのをお手伝いしてもらうことをお勧めします。では、次によく見られるボトルネックはオリジンです。私たちの目標は、オリジンからできるだけ多くのトラフィックをオフロードして、大規模なリクエストに対応できる十分な容量を確保することです。これはオリジンが過負荷になって完全に機能停止するのを防ぐためです。
もちろんキャッシングがこれに役立ちますし、CloudFront は階層化されたキャッシングを使用しています。エッジロケーションとリージョナルエッジキャッシュがありますが、Origin Shield と呼ばれるものを使用してさらにオリジンの負荷を軽減することもできます。リージョナルエッジキャッシュが直接オリジンにアクセスする代わりに、Origin Shield を経由してアクセスし、これによってキャッシュヒット率が向上し、オリジンへの需要が減ります。これは特に大規模なイベントがある場合に非常に役立ちます。
AWS Elemental Media Servicesを活用したマルチリージョン冗長化とMQAR
容量とオリジンへの負荷軽減についてカバーしたので、視聴者に素晴らしい体験を提供するために、プラットフォームの残りの部分をどのように設計するかを考える時が来ました。Werner Vogels の言葉を引用すると、すべてのものは常に失敗します。多くのお客様は、どのくらいの可用性を設計したいかを考えることから始めます。しかし、メディアの世界では、例えば 24 時間 7 日のチャネルを設計する場合と、イベントベースのチャネルを設計する場合では、これが大きく異なる可能性があります。
もう一つ重要な部分は、コストと実際に必要な耐障害性のバランスを取ることです。プラットフォームが完全に機能停止すると、ユーザーはコンテンツを視聴できなくなります。これは、カスタマーサポートの増加や財務的な影響など、他の方法でも影響を与える可能性があります。特にライブイベントの場合、本当に二度目のチャンスや後で試すという選択肢はありません。その瞬間は永遠に失われてしまいます。
これまで説明してきたように、物事は悪くなることがあります。ストリームを稼働し続けて、エンドユーザーに配信するためには、冗長性が本当に重要です。Nick の例では、これに対抗するために可用性ゾーンに 2 つの EC2 インスタンスがあります。AWS 内に冗長エンコーダーとオリジンをデプロイするお客様も見かけますが、メディアワークフロー向けのマネージドサービスも提供しています。これらは独自のカスタマイズされたインフラストラクチャを管理する課題を軽減し、少し後で説明する機能と特性を提供します。これらの機能は、視聴者に最高の視聴体験を提供するのに役立ちます。
AWS Elemental Media Services に詳しくない方のために、これは AT&T ストリームの典型的なワークフローです。AWS Elemental MediaConnect があります。これはライブビデオのための安全で信頼性の高いトランスポートサービスです。それが AWS Elemental MediaLive に送られます。これはクラウドベースのブロードキャストグレードのビデオ処理サービスです。その後、AWS Elemental MediaPackage があります。これはジャストインタイムパッケージングとオリジネーションサービスで、DVR のような機能や DRM などを実装できます。そして最後に、Amazon CloudFront があります。これは CDN で、今日は主にこれに焦点を当てています。視聴者は、ストリーミングしたい内容と必要なマニフェストに応じて、MediaPackage から異なるオリジンエンドポイントをプルできます。
これにより、EC2 から AWS Elemental Media Services に移行しました。つまり、基盤となるインスタンスについて心配する必要がなくなり、AWS Elemental Media Services のすべてのメリットが得られます。例えば、MediaLive はクロス AZ 同期とフェイルオーバーシナリオのための冗長性をサポートしています。大規模なイベントを実行している顧客は、通常、1 つのリージョンだけでなく、より多くの冗長性を実装する傾向があります。マルチリージョンアーキテクチャがどのようなものかを見ていきます。これについて説明するために、典型的なフェイルオーバーシナリオを見ていきます。ただし、手動介入が必要になる可能性がある場所に焦点を当てます。
以前と同じアーキテクチャがありますが、当然のことながら Region 1 と Region 2 があり、MediaConnect、MediaLive、MediaPackage があります。また、AWS Elemental Live の追加があります。これはオンプレミスのエンコーディングアプライアンスで、この場合、会場からのコントリビューションエンコーディングを行っています。Region 1 に行くコントリビューションフィードの 1 つに問題が発生したとしましょう。視聴者は現在そこからストリーミングしています。そのフィードに接続している視聴者は、実際のビデオコンテンツの代わりに黒いフレームが表示され始めるかもしれません。ただし、目視で監視しているオペレーションチームがいれば、この問題を早期に発見し、Region 2 への手動フェイルオーバーを実行することを決定するでしょう。問題が発生してから、誰かがそれを発見し、その後、積極的に対処するまでの間に時間遅延があることを忘れないでください。
フェイルオーバーが発生し、視聴者は URL ベンディングサービスに行き、「新しい URL が必要です」と言い、Region 2 用の URL が返されます。しかし、ここで考慮すべきいくつかの課題があります。第 1 に、主に、これを手動で行う必要があり、それを検出してから対処するまでに時間遅延があります。しかし、それだけでなく、視聴者が再度参加するときに、例えば、ストリーム内で視聴していた場所を見つけなければならないのでしょうか。そして、2 つのリージョン間でタイミングがずれているかもしれません。では、どのようにして物事を同期させるのでしょうか。これらのことを自動的にどのように行うのでしょうか。
これについてさらに詳しく探っていきますが、タイムコードから始めます。タイムコードは、各ビデオフレームに埋め込まれた時間参照です。タイムコードはメディア配信の世界で本当に重要です。エンコーダーやパッケージャーなどの下流コンポーネントでの同期に使用し、フレームアキュレートなアラインメントを提供したいのです。タイムコードは答えの一部ですが、実際にはフェイルオーバーシナリオにどのように適用されるのでしょうか。これを管理するのに役立つ機能があります。それは seamless cross-region failover と呼ばれています。
まず AWS Elemental Live エンコーダーのオンプレミス版から始めます。これは同じタイムコードソースを使用するため、両方のリージョンが整列されたコントリビューションフィードを受け取ります。その後、MediaLive は epoch locking で設定され、埋め込まれたタイムコードを使用します。そのタイミングソースは入力クロックです。そして MediaLive の出力から MediaPackage への CMAF ingest があります。 CMAF ingest と epoch locking を組み合わせると、epoch 時間に基づいた規則的なセグメンテーションケイデンスが実現されます。その後、MediaPackage は stateless synchronization を使用して、出力コンテンツを予測可能な方法でパッケージ化するのに役立てることができます。
では、スレート入力、不完全なマニフェスト、DRM キーの欠落など、何か問題が発生した場合はどうなるでしょうか。実は MediaPackage には、そのエンドポイントを 404 にする機能があります。 CloudFront は origin groups と呼ばれるもので設定されており、プライマリとセカンダリを指定し、HTTP ステータスコードに基づいたフェイルオーバー基準も設定します。MediaPackage がそのオリジンエンドポイントの 1 つを 404 にしたことを検出すると、そのトラフィックは自動的にセカンダリに送信されます。しかし、もしそれほど根本的な問題ではなく、例えば、ソースに黒いフレームまたは固定フレームがあり、 それがリージョンの 1 つに入るコントリビューションの 1 つにのみ影響を与えている場合はどうでしょうか。前のアーキテクチャに基づいて、Media Quality Aware Resiliency と呼ばれる機能があります。 これを MQAR と呼びます。実は MediaLive には、MQCS スコアと呼ばれるものを生成する機能もあります。
MQCS は Media Quality Confidence Score の略です。 このスコアは、黒フレーム検出、固定フレーム検出、入力ソース喪失を含む入力パラメータに基づいており、0 から 100 の範囲です。各スコアは独立して独自の入力に基づいています。MediaPackage はこれを 2 つの場所で使用できます。入力で使用して、リージョン内フェイルオーバーを提供できます。 また、CMSD、つまり Common Media Server Data を介して出力で使用します。 CMSD は CTA 仕様の一部でもあります。最後に、CloudFront で origin groups を引き続き使用しますが、 デフォルトのルーティングを使用する代わりに、メディア品質スコアをオリジン選択基準として使用します。その仕組みは、GET リクエストが両方のリージョンに送信され、最終的に視聴者またはクライアントにより良い視聴体験を提供するセグメントを選択するというものです。要するに、AWS メディアサービスと Amazon CloudFront を MQAR、つまり Media Quality Aware Resiliency と共に活用して、ストリームの監視を自動化し、中断イベントの継続時間を最小化することができます。
AWS Direct ConnectとMediaConnectによる信頼性の高いコントリビューション
ストリームをログを使用して分析し、オリジンとエンコーダーが利用可能であることを確認するために講じたこれらすべての対策は、クラウドへのコントリビューションストリームが安定していなければ無意味です。コントリビューションストリームが、エンコーダー、オリジン、CloudFront の残りのチェーンと同じくらい信頼できることを確認する必要があります。 では、ソースが配信と同じくらい信頼できることをどのように確認するのでしょうか。ソースで必要なことのいくつかは、 一貫性、信頼できるソース、イベントが発生する場所でのそのソースのカバレッジ、 そしてセキュリティです。通常、クラウドに入ってくるソースは最高品質の mezzanine フィードだからです。誰もがそれにアクセスできるようにしたくありません。なぜなら、それは最高品質のコンテンツであり、それが間違った手に渡ることを望まないからです。
多くのお客様が使用する解決策があります。それは AWS Direct Connect です。Direct Connect は、一貫性のためにストリームコントリビューション用に頻繁に使用されます。 これはリージョンへの専用接続で、最大 100 ギガビットの接続性を提供します。おそらく多くの皆さんは現在、JPEG XS や ST 2022-7 のような高品質のロスレス形式を使用してコンテンツをコントリビューションしているでしょう。そのようなことをしている場合、Direct Connect は非常に役立ちます。また、信頼性も高いです。Direct Connect を使用して、リージョンへの複数のパスを持つことができます。カバレッジは世界中の 100 以上の場所、30 以上の国にあるため、スタジアムなどの放送元の施設の近くにある可能性があります。繰り返しになりますが、プライベートです。プライベートネットワークであり、その上にメディア暗号化などを追加することができます。これについては次のスライドで説明します。
ここで Media Connect が登場します。Media Connect は AWS Elemental サービスの一つで、ライブメディアをクラウドに取り込むためのエントリーポイントです。Direct Connect を使用している場合でも、インターネット経由での配信を使用している場合でも、どちらの用途でも Media Connect を使用できます。Direct Connect を使用している場合は、おそらく VPC 経由で取り込んでいるでしょう。 インターネット接続を使用している場合は、VPN エンドポイントを使用して、Media Connect 経由で VPC 経由で取り込むこともできます。VPC オリジンと VPC 取り込みを活用することで、メディアワークフロー全体をプライベートにすることができます。CloudFront は VPC からのプルをサポートしており、VPC への取り込みもサポートしています。先ほど暗号化について触れましたが、Media Connect でサポートしているプロトコルの多くは SRT や Zixi、RIST などの暗号化を提供しています。SRT はかなり使用されており、それに対して暗号化を有効にするのは簡単です。SRT を公開しているほぼすべてのエンコーダーが暗号化をサポートしています。ですから、インターネットを使用している場合でも Direct Connect を使用している場合でも、暗号化はオプションとして利用できます。
特にインターネット経由での配信では、パケットロスが懸念事項です。パケットの喪失は起こります。SRT や Zixi、RIST、RTP FEC のようなほとんどのプロトコルは、エラー訂正と ARQ（自動再送要求）をサポートしています。 これらはすべて Media Connect とエンコーダーで調整可能です。インターネット経由で配信を行う場合、信頼性と引き換えに少しのレイテンシーを追加することが Media Connect で利用できます。既知の不安定な接続のために、もう少しエラー訂正を追加することができます。私が言及した Zixi と SRT の両方のプロトコルは、ストリームのフェイルオーバーを可能にします。つまり、複数の ISP が Media Connect 経由で配信でき、ライブイベント中にそのうちの 1 つに問題が発生した場合、自動的に別のものに切り替えることができます。
先ほどメトリクスについて言及しましたが、これらは非常に重要です。イベント前に作成するダッシュボードには CloudFront が含まれているので、CloudFront に問題がないかどうかがわかります。おそらくオリジンサーバーからのメトリクスが含まれており、オリジンのパフォーマンスがどうなっているかがわかります。DRM または広告挿入を使用している場合、これらのメトリクスも利用可能です。ダッシュボードに取り込みメトリクスを追加することもできます。ARQ リカバリーとドロップされたパケットのメトリクスも追加できるので、取り込みに問題があるかどうか、CloudFront なのかオリジンなのかを素早く確認できます。
インターネット経由での取り込みで最も一般的なプロトコルの 1 つである SRT については、Media Connect のダッシュボードで使用されている推奨メトリクスは以下の通りです。これらは、取り込み品質を非常に厳密に監視している最大のライブイベントの顧客が実際に監視しているメトリクスです。次に、New England Sports Network の Jess Palmer が登壇します。彼女は Red Sox の本拠地である NESN から来ており、彼女のプラットフォームについて少し話してくれます。
NESNの事例に学ぶ実践的なストリーミングワークフローと収益化戦略
NESN は最大の RSN ではありませんが、実は 2022 年にダイレクト・ツー・コンシューマーのライブストリーミングアプリを提供した最初の RSN です。 リージョナルスポーツネットワークとして、NESN は小規模なデジタルチームを持っており、ほぼ私と私のボスが成長するユーザーベースにサービスを提供しています。基本的なストリーミング知識を備えて、AWS クラウドサービスを通じてストリームフローを簡単に学習し、管理することができました。 NESN のようなリージョナルスポーツネットワークには、ユニークなストリーミング上の課題があります。高品質で低レイテンシーのライブおよびオンデマンドスポーツコンテンツを配信し、地域放映権を実施し、予測不可能なトラフィックスパイクに対応する必要があります。これらすべてを、強力なセキュリティとコンプライアンスを維持しながら行う必要があります。
さらに、多くの全国的なディストリビューターが SRT フィードを受け取ってから再送信するのとは異なり、NESN ではブロードキャストのあらゆるステップをコントロールしています。まず、ゲームはカメラ で撮影されます。このカメラは私たちのモバイルプロダクションユニット、つまりトラックに接続されています。実際のトラックで、その中に制作機器が入っています。Fenway Park の Red Sox と TD Garden の Bruins のために 4K カメラと HD カメラを配置しています。アウェーゲームの場合は、チームと一緒に移動する独自の HD カメラを持っています。 フィードはトラックから、または相手チームのスタジアムからインターネット経由でボストンのオフィスにあるマスターコントロールに中継されます。
これらのフィードは直接 linear ディストリビューターと共有されるか、ケーブルサブスクリプションを通じて昔ながらの方法でスポーツを視聴しているファンと共有されます。さらに、SRT フィード は AWS ハードウェアエンコーダーを通じて直接 AWS にルーティングされます。Red Sox と Bruins シーズンのゲームの約 50 パーセント がホームゲームで、HD と 4K で提供しています。AWS により、Media Live を使用した transcoding とストリーミング管理のための AWS Elemental エンコーダーを使用して 4K ストリームの可用性を簡単に管理できます。John の助けを借りて AWS Elemental エンコーダーに Media Live Anywhere をインストールしたので、HD および UHD リンクを Media Live ダッシュボードで管理するのと同じ方法でフィードを管理できるようになりました。
4K ソースから、4K、2K、1080p、720p のビデオ出力、ステレオおよびサラウンドオーディオ出力、クローズドキャプション出力を含む Media Live 出力グループを設定しました。一部の OTT プレイヤーで muxing に問題が生じることがわかったため、オーディオとビデオトラックは分離したままにしました。異なるシステムとの互換性のために Media Package V2 チャネルグループを使用して DASH と HLS オリジンエンドポイントを作成しました。これらのオリジンは CloudFront ディストリビューションに使用されます。CloudFront を使用する大きな利点は、トラフィックの変動に対応するために自動的にスケールすることです。たとえば、Sox が Yankees と対戦している場合、エッジキャパシティについて心配する必要はありません。CloudFront がそれを処理してくれます。
また、Fenway Park からのバッティング練習や Bruins 練習アリーナからのモーニングスケートなど、サードパーティのフィードまたは一度限りのダイレクトフィードを取得することもあり、デジタルエクスクルーシブとして提供しています。これらの一度限りのイベント用に HD リンクを使用しています。これらのイベント に対して同じ基本的なフローを使用しています。ライブまたはサードパーティのフィードは HD リンクを通じてルーティングされ、HD フィードは transcoded されます。
CTV とモバイルデバイスに対応するための低い出力層に変換されます。その後、同じ Media Live から Media Package から CloudFront へのフローになります。さらに、すべてのサービス にわたる CloudFront ログは、パフォーマンスの問題を早期に検出し、ストリーム品質を維持し、スムーズな配信を確保するのに役立つメトリクスとアラームを提供します。 これらのログが Log Insights を使用して簡単にアクセスでき、クエリ可能であることは、私たちのようなリーンなデジタルチームにとって不可欠です。要約すると、CloudFront は NESN がすべてのファンに対して信頼性の高い高品質なストリームを配信し、ライブスポーツ のピーク時にシームレスにスケールし、メディア権を保護し、規制コンプライアンスを維持し、視聴者の行動とパフォーマンスについてのリアルタイムインサイトを得ることを可能にします。
ありがとうございます、Jess。本当に素晴らしいですね。Jess がやっていることはいつも大好きです。Jess は先ほどのデモンストレーションで、AWS Elemental MediaTailor について少し話してくれました。AWS Elemental MediaTailor は Elemental の傘下にあるマネージドサービスで、ライブストリームやオンデマンドストリームに対して広告の置き換えと広告挿入を行います。このワークフローでも MediaTailor を使用していますが、他の多くの広告挿入プラットフォームも同様の方法で動作します。ストリームを収益化しようとするときは、まったく新しい一連の課題が生じます。
これは動的広告挿入と呼ばれるものです。名前の通り、動的な要素を追加するわけです。エンドユーザーのマニフェストはすべて個人化されます。なぜなら、ユーザーに向けられた広告があるからです。リニア広告を使用しているか、squeeze back や pause ads のような新しいフォーマットを使用しているかに関わらずです。これまで、スケーリングと CloudFront がオリジンをスケーリングすることについて話してきました。広告挿入について話すときは、オリジンがそれ以上に重要になります。なぜなら、エンドユーザーからのすべてのリクエスト、1000 ユーザーであれ 100 万ユーザーであれ、すべてオリジンに直接行き、オリジンがリアルタイムでマニフェストを修正するからです。
ですから、オリジンがビューアーに応じて適切にスケーリングできることが本当に重要です。CloudFront を広告用に設定するときは、マニフェスト用にもう少し多くの動作を設定することになります。もはやそれらをキャッシュしていません。オリジンサーバーに直接送信し、オリジンサーバーがエンドユーザーに行くすべてのマニフェストを修正します。その後、MediaTailor はアップストリームの広告主、Springserve、FreeWheel、またはそれらの広告プラットフォームのいずれかに呼び出しを行います。これらもスケーリングする必要があります。なぜなら、すべてのリクエストが広告サーバーへのユニークなリクエストになるからです。
ですから、プラットフォームに動的広告挿入を追加するときは、オリジンだけでなく DRM プラットフォームについても検討することが本当に重要です。ご存知の通り、これらは通常 CloudFront の背後にはありません。AWS Elemental MediaTailor は実は最近、広告プラットフォームを支援するための機能を追加しました。なぜなら、すべてのユーザーが同時に広告ブレークに行き、100 万人のビューアーが一度に広告プラットフォームにアクセスすると、その広告プラットフォームが何であれ、それに対応できないからです。実は MediaTailor には、広告ブレーク前に広告をプリフェッチし、広告サーバーへのリクエストをずらす機能があります。
これらは、ライブストリームに収益化を追加するときに検討する必要がある本当に重要な考慮事項です。リニア広告の置き換え、オーバーレイ、squeeze back、または新しいフォーマットのいずれであれ、検討する必要がある考慮事項がたくさんあります。特にオリジンサーバー、つまり広告挿入プロバイダーであるオリジンサーバーについて、多くのことを見直す必要があります。ここで Jamie にバトンタッチして、まとめをしてもらいたいと思います。
では、まとめに入りますが、大規模なイベントを成功させ、スケーラブルに配信するための方法を考えることを目指してこのトークを行いました。次の大規模イベントの計画を始める際に、これらの重要なポイントを覚えておいてください。まず第一に、observability が重要です。ダッシュボード、リアルタイムログと Kinesis を通じたデータ収集など、CMCD や CMSD などの他のデータポイントを活用して observability を向上させる方法を考えてください。
アーキテクチャ設計は、実は incode と origination だけにとどまりません。AWS Elemental とメディアサービスについて説明しましたが、Embedded POPs や Origin Shield などの他のインフラストラクチャを活用してトラフィックの一部を吸収する方法も忘れずに。セキュリティもレイヤード型のアプローチです。すべてに対応する単一のメカニズムはありません。tokenization、IP blocking、GA blocking をカバーし、CloudFront Functions や AWS WAF などのメカニズムを使用した、エンドツーエンドのセキュリティ戦略を考えてください。
そして最後に、monetization は単なるサブスクリプション支払いだけではありません。MediaTailor などのサービスを使用して server-side ad insertion でコンテンツを収益化することができます。今日説明したこれらのトピックについてさらに学びたい、または読み続けたい場合、あるいはサンプルをデプロイしたい場合は、ここにそれらのリンクがあります。そして最後に、ネットワークとコンテンツデリバリーのスキルを向上させることに興味がある場合は、AWS Skill Builder をチェックすることを強くお勧めします。
本日のセッションはこれで終了です。ご参加ありがとうございました。大規模イベントに向けて次に注意すべきことについて考えるのに役立つ情報をお届けできたと幸いです。簡単なリマインダーですが、re:Invent アプリにアクセスして、本日のセッションについてフィードバックを送信してください。そうすることで、セッションの改善に役立てることができます。本日お話しした内容についてご質問があれば、周辺にいますので、ぜひ re:Invent での残りの時間をお楽しみください。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion