AWS What's New Digest

Appearance

2026年03月21日 ​

[Bedrock] Amazon Bedrock AgentCore Runtime adds WebRTC support for real-time bidirectional streaming ​

概要 ​

Amazon BedrockのAgentCore RuntimeがWebRTCによる双方向リアルタイムストリーミングをサポートしました。これによりブラウザやモバイル向けの低遅延音声／映像エージェントが構築しやすくなります。

変更内容・新機能の詳細 ​

AgentCore Runtimeは従来のWebSocketに加えてWebRTCを第二の双方向ストリーミングプロトコルとしてサポートします。WebRTCはUDPベースでピアツーピアのメディア伝送に最適化されており、音声・映像の双方向ストリーミングで低遅延を実現します。一方、WebSocketはTCP上での永続的かつ全二重の接続によりテキストや音声ストリーミングに適しています。WebRTCはNAT越え／ファイアウォール対策としてTURNリレー（メディア中継）を必要とし、AgentCore Runtimeでは以下の選択肢が提供されます：Amazon Kinesis Video StreamsのマネージドTURN（AWS IAM統合付き）、サードパーティTURNプロバイダー、またはセルフホストのTURN。両プロトコルはAgentCore Runtimeのセッション分離、可観測性（ログ／メトリクス等）、およびスケーリング機構の恩恵を受けます。WebRTCサポートは14リージョンで利用可能です（米東(N. Virginia)、米東(Ohio)、米西(Oregon)、アジア太平洋(ムンバイ/ソウル/シンガポール/シドニー/東京)、カナダ(中部)、欧州(フランクフルト/アイルランド/ロンドン/パリ/ストックホルム)）。ドキュメントにはWebSocket/WebRTC両対応のサンプル（Amazon Nova Sonic + KVS TURN、Pipecatの各種トランスポート、LiveKit、Strands Agents SDK等）が用意されています。なお、WebRTCの接続確立にはSDP/ICEを用いたシグナリングが必要になる点に注意してください。

影響範囲・利用シーン ​

  • 対象ユーザー: 音声エージェント／リアルタイム対話アプリを開発する開発者、SRE、プロダクトチーム
  • 利用シーン: ブラウザやモバイルでの低遅延音声・映像双方向会話（ボイスアシスタント、コールセンターの対話UI、対話型エージェント）
  • 運用効果: レイテンシ低減による自然な会話体験の実現、ピアツーピア接続によりサーバ負荷・遅延が改善される場合がある
  • 制約/注意点: NAT/ファイアウォール環境ではTURNリレーが必要になり、その構成とコストが運用に影響する

技術的な注意点 ​

  • IAM権限: Kinesis Video StreamsのマネージドTURNを利用する場合は該当するIAM権限とロール設定が必要です
  • リージョン制限: WebRTCサポートは14リージョンに限定されます（記事記載のリージョンを参照してください）
  • コスト: TURN経由のメディア中継はデータ転送コスト（アウトバウンド）やTURNサービス利用料が発生する可能性があります
  • TURN構成: KVSマネージドTURN、サードパーティ、セルフホストのいずれかを選択可能。高可用性や帯域要件は設計時に考慮してください
  • シグナリング: WebRTCはSDP/ICEによるシグナリング実装が必要です（AgentCore側のセッションAPIや既存シグナリング基盤との統合を検討してください）
  • プロトコル選択: 低遅延な音声/映像にはWebRTC、テキストやTCPベースの永続ストリームにはWebSocketが引き続き有効です
  • 互換性/運用: AgentCore Runtimeのセッション分離と可観測性は両プロトコルで利用可能。既存WebSocket実装からの移行設計では接続確立フローとメディア経路の違いを確認してください

参考情報 ​

[EKS] Amazon EKS announces 99.99% Service Level Agreement and new 8XL scaling tier for Provisioned Control Plane clusters ​

概要 ​

Amazon EKSがProvisioned Control Planeを対象に99.99%のSLAを提供開始し、Provisioned Control Planeの最大スケーリング階層として新たに8XLを追加しました。ミッションクリティカルなワークロード向けに可用性とAPIサーバ処理能力を強化します。

変更内容・新機能の詳細 ​

Provisioned Control Planeは事前にコントロールプレーン容量を選択できるスケーリング階層を提供する機能で、突発的なトラフィックやバーストに対応できるよう制御プレーンがプロビジョニングされます。本アップデートでは次の点が追加・変更されています。

  • 99.99% SLA: Provisioned Control Planeを利用するクラスターに対して可用性SLAが99.99%に引き上げられました（従来の標準コントロールプレーンでは99.95%）。SLAは1分間隔で測定され、より粒度の細かい可用性保証が提供されます。SLA差分の目安： ・99.95% の場合の想定年間ダウンタイム ≒ 262.8 分（約4.38 時間） ・99.99% の場合の想定年間ダウンタイム ≒ 52.56 分（約0.88 時間） 月単位ではそれぞれ約21.6分→約4.32分となり、月あたり約17分、年あたり約210分（約3.5時間）分の可用性改善が期待できます。

  • 8XL スケーリング階層: 新しい8XLはProvisioned Control Planeの中で最大の階層で、1つ下の4XL階層と比べてKubernetes APIサーバのリクエスト処理能力が2倍になっています。これにより、超大規模なAI/MLトレーニング、HPC、巨大データ処理パイプラインや非常に高いAPI呼び出し量が発生する環境で制御プレーンのボトルネックを緩和できます。

  • 可用性: 99.99% SLAおよび8XL階層は、Amazon EKS Provisioned Control Planeを提供しているすべてのAWSリージョンで利用可能です。

詳細なSLA条件（クレジット対象になる障害条件など）や8XLの料金・性能情報についてはそれぞれEKSのSLA、料金ページ、Provisioned Control Planeのドキュメントを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウドアーキテクト、SRE、プラットフォームエンジニア、AI/ML・HPCワークロード運用チーム
  • 利用シーンまたは効果: ミッションクリティカルなサービス（低遅延かつ高可用性が必須のAPI基盤、超大規模AIトレーニング、HPC、バッチ大規模データ処理）での制御プレーン耐久性向上とAPI処理能力の拡張
  • 運用効果: APIサーバのボトルネック緩和によりスロットリング/タイムアウトの発生頻度低減、ダウンタイム削減によるSLA準拠やSRE負荷の軽減
  • 移行影響: 既存の標準コントロールプレーンからProvisioned Control Planeへ移行する場合は設定や再作成が必要となる可能性があり、事前検証が必要
  • コスト影響: 高い階層（特に8XL）は従来よりコストが上昇するため、トラフィック特性と費用対効果を評価して選択する必要あり

技術的な注意点 ​

  • IAM権限: Provisioned Control Planeの作成・管理にはeks:CreateCluster等のEKS関連IAM権限が必要。組織ポリシーで権限確認を行ってください
  • リージョン制限: 記事では「Provisioned Control Planeを提供しているすべてのリージョンで利用可能」と記載。ただし自アカウントのリージョン対応状況は管理コンソールやドキュメントで確認してください
  • コスト: 8XLなど上位階層は追加料金が発生します。料金テーブルを確認し、予算・コスト管理を行ってください
  • SLA詳細: 可用性クレームやサービスクレジット適用条件はEKS SLA文書を確認のこと（計測方法は1分間隔）
  • 既存クラスター移行: 標準→Provisionedや階層変更の手順、ダウンタイムの有無はドキュメントで確認。必要に応じて検証環境で負荷試験を実施してください
  • 運用上の留意点: APIサーバの処理能力が向上しても、ワーカーノードやアプリケーション側のスケーリング、リソース制限（RBAC、Admission Controllers、サードパーティコントローラ）の影響で全体性能が制約されるため総合的な負荷設計が必要

参考情報 ​

[General] AWS Neuron announces support for Dynamic Resource Allocation with Amazon EKS ​

概要 ​

AWS NeuronがAmazon EKS向けにDynamic Resource Allocation (DRA) ドライバーを発表しました。これにより、Trainiumベースのインスタンス上でKubernetesネイティブなハードウェア認識スケジューリングが可能になります。

変更内容・新機能の詳細 ​

Neuron DRAドライバーは、ノード上のデバイス属性（トポロジー、デバイス数、ネットワーク/NUMA情報など）をKubernetesスケジューラに直接公開します。これによりカスタムスケジューラや大きなマニフェスト変更なしにトポロジー意識のある配置（topology-aware placement）が実現されます。インフラ側ではResourceClaimTemplateとしてデバイストポロジー、割当ポリシー、ネットワーク設定をテンプレート化でき、MLエンジニアはこれを参照するだけでよく、デバイス数や物理配置を考慮せずにPodをデプロイできます。結果として、分散トレーニング、長文コンテキスト推論、分離アーキテクチャなどスケールするワークロードでもインフラ依存を低減し、複数ワークロードの同一ノード共有を効率化します。発表では全てのAWS Trainiumインスタンスタイプをサポートし、Trainiumが利用可能なすべてのAWSリージョンで利用できます。導入ガイド、サンプルテンプレート、実装手順は公式のNeuron DRAドキュメントに掲載されています。

影響範囲・利用シーン ​

  • 対象ユーザー: MLエンジニア、インフラ/プラットフォームチーム、SRE
  • 利用シーン: 分散トレーニングや大規模推論でのハードウェア最適配置、複数AIワークロードのノード共有、Kubernetes上でのAIリソース管理の標準化
  • 運用効果: インフラ設定とモデル開発の分離によりデプロイの反復速度向上、配置ミスによる性能低下の削減、同一ノード上での資源効率向上によるコスト最適化

技術的な注意点 ​

  • 前提条件: Amazon EKSクラスタ上でNeuron DRAドライバーを導入する必要があります。ノードはAWS Trainiumインスタンスを利用する必要があります。詳細は公式ドキュメントを確認してください。
  • Neuronランタイム/ドライバ: Neuronランタイムやカーネルドライバ（Neuron SDK等）のインストール要件があるため、ノードイメージまたは起動時設定で準備が必要です。
  • Kubernetes/EKS互換性: DRA機能や関連APIのサポート状況はEKSのバージョンによります。使用前に対象のEKSバージョンでDRAがサポートされているか確認してください。
  • IAM権限: クラスタ管理者とインフラチームがResourceClaimTemplateやノードのセットアップを行うための適切なIAM権限が必要です。詳細はEKS/Neuronドキュメントを参照してください。
  • リージョン制限: Trainiumが提供されているリージョンでのみ利用可能です。全リージョンでの提供状況はAWSリージョン一覧を確認してください。
  • コスト: 追加のAWSサービス料金は伴わない可能性が高いですが、Trainiumインスタンスの利用コストやノードサイズ最適化の影響があります。リソース割当方針によってはインスタンス数が増減します。
  • 導入上の注意: インフラ側でテンプレート設計（ResourceClaimTemplate）が重要です。テンプレート設計次第でワークロードの共有効率や性能に影響するため、テストを行い最適化してください。

参考情報 ​

AI要約はOpenAI GPT-5-miniによって生成されています。

Copyright © 2026