2026/5/5 9:00:00 ~ 2026/5/6 9:00:00 (JST)

最近の発表

AWS Elemental MediaTailor now provides automatic secure server-to-server integration with Google’s ad platforms

AWS Elemental MediaTailor が Google アドマネージャー (GAM)、Google キャンペーンマネージャー (GCM)、Google ディスプレイ&ビデオ 360 (DV360) とのサーバー間接続を自動的に認証するようになりました。これにより、Google の広告プラットフォームを使用するお客様にシームレスな統合体験を提供できます。\n MediaTailor にはサーバーサイド広告挿入（SSAI）機能があり、動画ストリーム内の広告をパーソナライズできます。Google では、広告リクエストや広告トラッキングイベントの発生時に、SSAI プロバイダーに安全で認証された接続の確立を義務付けています。以前は、MediaTailor のお客様は AWS サポートケースを通じてこの統合の有効化をリクエストし、許可リストに追加する必要がありました。今回の更新により、MediaTailor は Google の広告サーバー宛のリクエストを自動的に検出し、必要な安全な接続を確立します。お客様による操作は不要です。具体的には:

Google アドマネージャー（GAM）: Google のサイト運営者向け広告サーバーへのサーバー側広告リクエストは自動的に保護されます。認定購入者（Google のリアルタイム広告販売マーケットプレイスと広告交換）にアクセスするにはこのセキュリティが必要です。

Google キャンペーンマネージャー（GCM）と DV360: サーバー側のインプレッショントラッキングリクエストは Google の認証済みエンドポイントを経由して自動的にルーティングされ、セキュリティが強化されます。これにより、これらのプラットフォームでキャンペーンを実施する広告主は、より正確なレポートが得られ、拒否されるインプレッションが少なくなります。

その他すべての広告リクエスト:変更なしで引き続き機能します。

AWS Elemental MediaTailor のサーバー間 Google の自動統合は、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、アフリカ (ケープタウン)、アジアパシフィック (ハイデラバード、マレーシア、メルボルン、ムンバイ、大阪、ソウル、シンガポール、シドニー、東京)、カナダ (中部)、ヨーロッパ (フランクフルト、アイルランド、ロンドン、パリ) など、MediaTailorが利用可能なすべてのAWSリージョンで利用できます。ストックホルム）、中東（UAE）、南米（サンパウロ）。この機能に追加料金はかかりません。詳細については、AWS Elemental MediaTailor のドキュメントをご覧ください。

AWS SAM CLI adds BuildKit support for AWS Lambda functions packaged as container images

AWS サーバーレスアプリケーションモデルコマンドラインインターフェイス (SAM CLI) は、Dockerfiles からコンテナイメージを構築するための BuildKit をサポートするようになりました。これにより、コンテナイメージとしてパッケージ化された Lambda 関数のコンテナイメージをより迅速かつ効率的にビルドできるようになりました。\n SAM CLI は、AWS クラウドにデプロイする前に、サーバーレスアプリケーションをローカルで構築、テスト、デバッグ、およびパッケージ化するためのコマンドラインツールです。Lambda 関数をコンテナイメージとしてパッケージ化する開発者は、イメージを本番用に最適化するために BuildKit が提供する高度なビルド機能を必要とすることがよくあります。ただし、SAM CLI は以前は BuildKit 機能をサポートしていませんでした。SAM CLI で BuildKit がサポートされるようになったため、マルチステージビルドを利用して、開発に依存することなくより小さな最終イメージを作成できるようになりました。また、キャッシュが改善されて再構築時間が短縮され、ビルドステップの並列化が改善されました。BuildKit ではクロスアーキテクチャビルドも可能になるため、x86_64 と arm64 (AWS Graviton2) の両方の命令セットアーキテクチャを対象とするコンテナイメージを同じ開発マシンから構築できます。また、ビルド中に Docker シークレットを使用して、認証情報や API キーなどの機密データを最終的なイメージレイヤーから除外することもできます。

開始するには、SAM CLI をダウンロードまたはバージョン 1.159.0 以降に更新し、sam build で–use-buildkit フラグを使用してください。この機能は、SAM CLI で Docker と Finch のどちらを使用しているかに関係なく機能し、BuildKit のすべての機能を活用できます。

詳細については、SAM CLI 開発者ガイドをご覧ください。

AWS SAM now supports WebSocket APIs for Amazon API Gateway

AWS サーバーレスアプリケーションモデル (AWS SAM) は Amazon API ゲートウェイ用の WebSocket API をサポートするようになりました。これにより、SAM テンプレートで最小限の設定で完全な WebSocket API を定義できるようになりました。\n AWS SAM は、サーバーレスアプリケーションの構築と管理を容易にするオープンソースツールのコレクションです。WebSocket API は、チャット、ライブダッシュボード、AI/LLM ストリーミング、IoT などのリアルタイムアプリケーションにとって重要です。ただし、SAM は以前は WebSocket API をサポートしていなかったため、AWS CloudFormation の基盤となるすべてのリソースを手動で設定する必要がありました。そのため、Lambda 関数の IAM 権限がないなどの一般的な問題のデバッグが困難でした。現在、SAM はこれらすべてを自動的に処理し、必要なリソースと権限をテンプレートから生成します。新しいリソースは、IAM や Lambda の認証、カスタムドメイン、ルート設定、モデル、ステージ変数など、API Gateway WebSocket API と同等の機能を提供します。グローバルサポートにより、複数の WebSocket API 間で共通の設定を共有できます。

はじめに、AWS:: Serverless:: WebSocketAPI リソースタイプを SAM テンプレートに追加してください。アプリケーションに必要なカスタムルートとともに、$connect、$disconnect、および $default ルートの Lambda 関数ハンドラーを指定してルートを定義します。SAM は各ルートのインテグレーションと権限を自動的に接続します。また、認証、ステージ設定、カスタムドメインをリソース定義内で直接設定することもできます。

詳細については、SAM 開発者ガイドをご覧ください。

Amazon ElastiCache adds thirteen new Amazon CloudWatch metrics for network capacity planning and engine diagnostics

Amazon ElastiCache のお客様は、ノードベースのクラスター用の 13 個の新しい Amazon CloudWatch メトリックスを使用して、ネットワークスロットリング、メモリ断片化、および接続枯渇を検出できるようになりました。個々のノードで INFO コマンドを実行したり、未加工のバイトカウンタからベースラインを計算したりしなくても、ホストレベルとエンジンレベルのこれらの診断を CloudWatch から直接モニタリングできます。\n

ネットワーク容量:ネットワークベースライン使用率、ネットワークベースライン使用量アウトパーセンテージ、ネットワークベースライン最大使用率パーセンテージ、およびネットワークベースライン最大使用量アウトパーセンテージは、インスタンスベースラインに対するネットワーク使用率を報告します。これにより、インスタンスタイプが変更されても有効なポータブルアラームが可能になります。100% を超える値は、ホストがバーストクレジットを消費していることを示します。これは、持続的なワークロードが最終的にクレジットの枯渇とスロットリングにつながることを示す先行指標です。最大値をキャプチャするバリアントでは、メトリクスを平均化すると隠れる可能性のある 1 秒あたりのバーストが報告されます。

メモリヘルス:UsedMemoryDataSet には、エンジンオーバーヘッドを除いた実際の保存データによって消費されたメモリが表示されます。AllocatorFragmentationBytes と AllocatorFragmentationRatio は、アクティブデフラグパラメーターで対処できるフラグメンテーションを分離します。MajorPageFaults は、エンジンが処理しきれないメモリ負荷を示す OS レベルのページフォールトをキャプチャします。

接続の状態:ブロックされた接続と拒否された接続は、ブロックしているコマンドを待っている接続を表示し、最大クライアント数の制限に達すると接続を拒否されます。拒否された接続数が 0 以外の場合は、最大クライアント数を増やすか、クライアント側の接続プールリークを診断してください。

Pub/Sub ワークロード:PubSubChannels と PubSubShardChannels は、各ノードでアクティブなクラシックチャンネルとシャードチャンネルを公開します。クラシックチャンネル数が利用率とともに増加している場合は、シャーディングされた Pub/Sub に切り替えて水平方向にスケーリングすることを検討してください。

コマンドスループット:ProcessedCommands は、すべてのコマンドタイプにわたるコマンドスループットの合計を提供します。

これらのメトリクスは、すべての商用 AWS リージョン、および ElastiCache がサポートされている AWS 中国および AWS GovCloud (米国) リージョンのノードベースのクラスターで、追加料金なしで利用できます。 はじめに、ElastiCache コンソールのモニタリングタブまたは CloudWatch コンソールの AWS/ElastiCache 名前空間で新しいメトリクスを確認してください。詳細については、「ホストレベルのメトリクスと Valkey と Redis OSS のメトリクス」を参照してください。

Amazon WorkSpaces now lets AI agents operate desktop applications (Preview)

AWS の完全マネージド型クラウドデスクトップサービスである Amazon WorkSpaces により、AI エージェントはマネージド WorkSpaces 環境を通じてデスクトップアプリケーションに安全にアクセスして操作できるようになりました。多くの企業が、最新の API がないデスクトップアプリケーション (メインフレーム、ERP システム、プロプライエタリツール) で重要なビジネスプロセスを実行しているため、AI エージェントにとって「ラストマイルの課題」が生じています。WorkSpaces により、組織はエンタープライズグレードのガバナンスとコンプライアンスを完全に維持しながら、日常のワークフローを大規模に自動化できるようになりました。\n あらゆるフレームワーク上に構築され、クラウドホスト、オンプレミス、ハイブリッドなど、あらゆる場所で稼働している AI エージェントが、業界標準のモデルコンテキストプロトコル (MCP) 統合を使用して、最小限のコードでビジネスアプリケーションに接続できるようになりました。IT管理者が人間の WorkSpaces 環境と同様、一元化された権限、ロギング、監査制御を維持できる一方で、開発者は新しいインフラストラクチャを構築しなくても短期間で価値を生み出すことができます。スクリーンショットやメトリクスを含むエンタープライズオブザーバビリティ機能により、エージェントのアクティビティを完全に可視化できます。組織は、金融サービス、医療、その他の規制対象業界にわたる請求処理、取引決済、候補者のスクリーニング、バックオフィス業務にまたがるワークフローを自動化できます。これらはすべて、アプリケーションの最新化を必要としません。

WorkSpaces は、エージェントが人間と同じようにデスクトップアプリケーションを指差したり、クリックしたり、操作したりできる安全な環境を提供します。AWS のグローバルインフラストラクチャ上に構築された従量課金制の料金体系と柔軟な拡張性により、企業は IT のオーバーヘッドを削減すると同時に、人と AI が連携することで実現できることの幅を広げることができます。詳細については、WorkSpaces のドキュメントをご覧ください。

AWS IoT Core for Device Location adds Confidence Level Configuration and Measurement Type support

AWS IoT Core for Device Location は、開発者が位置の解決をより細かく制御できるようにする 2 つの機能強化と、解決されたデバイス位置のより豊富なメタデータをサポートするようになりました。\n Cell ID、Wi-Fi、Cell+Wi-Fi ソルバーを使用するお客様は、デバイスの位置を解決する際に 50% ～ 99% の間で希望する信頼度を指定できるようになりました。信頼水準は、実際のデバイス位置が報告された精度の範囲内にあるという統計的確率を表します。信頼度が高いほど (たとえば 95%)、デバイスが報告された半径内にあるという確実性は高くなりますが、精度半径は大きくなります。信頼水準が低い (たとえば 50%) と、半径は小さくなり、確実性は低くなります。お客様はこの値を設定して、特定の要件に基づいて精度と信頼性のバランスを取ることができるようになりました。この機能は現在 HTTP ベースのロケーション解決でサポートされています。 このアップデートでは、解決された位置情報メタデータに測定タイプフィールドも導入され、開発者はGNSS、Wi-Fi、BLEのロケーションリゾルバーのいずれを使用しても、各デバイスの位置がどのように決定されたかをより詳細に把握できるようになりました。これにより、位置データの品質評価や測位に関する問題のデバッグが容易になり、各位置の決定方法に基づいてより多くの情報に基づいた意思決定を行うことが容易になります。 これらの更新は、AWS IoT Core for Device Location がサポートされているすべての AWS IoT Core リージョンで利用できます。詳細なガイダンスと実装手順については、AWS IoT Core デバイスロケーションと IoT ワイヤレス開発者ガイドをご覧ください。

Amazon MQ now supports in-place major version upgrades for RabbitMQ 4

Amazon MQ は RabbitMQ ブローカーのインプレースバージョンアップグレードをサポートするようになりました。これにより、新しいブローカーを作成したり、データを移行したりすることなく、ブローカーを RabbitMQ 4 にアップグレードできます。RabbitMQ 3.13 から 4.2 へは、Amazon MQ コンソール、AWS CLI、または API から直接アップグレードできるようになりました。\n インプレースアップグレードでは、ブローカーの設定、キュー、エクスチェンジ、バインディング、ユーザー、ポリシーが維持されます。RabbitMQ 4.2 では、従来のミラーキューの削除や Mnesia から Khepri メタデータストアへの移行など、重大な変更が導入されています。ブローカーがアップグレードの対象となるには、M7G (Graviton) インスタンスタイプで実行されていなければならず、クラシックミラーキューがあってはなりません。キュー移行ツールを使用して、アップグレード前にクラシックミラーキューをクォーラムキューに変換できます。メジャーバージョンアップグレード中は、Amazon MQ がアップグレードを実行している間、ブローカーは使用できません。 ブローカーをアップグレードするには、AWS マネジメントコンソール、AWS CLI、または AWS SDK を使用してバージョンとして RabbitMQ 4.2 を選択するだけです。Amazon MQ では RabbitMQ 4.2 ブローカーのパッチバージョンアップグレードが自動的に管理されるため、指定する必要があるのはメジャー.マイナーバージョンのみです。RabbitMQ 4.2 とアップグレードプロセスの詳細については、Amazon MQ リリースノートと Amazon MQ 開発者ガイドを参照してください。この機能は、現在 RabbitMQ 4 インスタンスが利用可能なすべてのリージョンで利用できます。

Amazon Quick now integrates with New Relic for observability-driven AI agents

仕事用の AI アシスタントである Amazon Quick が New Relic の AI エージェントと統合され、オンコールのエンジニア、SRE、エンジニアリングリーダーが Amazon Quick ワークスペースを離れることなく、インシデントの調査、根本原因分析ブリーフの作成、追跡タスクの作成が可能になりました。\n New Relicのリモートモデルコンテキストプロトコル（MCP）サーバーに接続すると、アラートインサイト、ユーザー影響分析、ログ分析、トランザクション診断、自然言語NRQLクエリなど、Quickの会話プロンプトからNew RelicのAIエージェントを直接呼び出すことができます。1回のチャットで、オブザーバビリティデータ全体でインシデントを調査し、エビデンスリンクを含む根本原因分析（RCA）ドキュメントを生成し、電子メールに添付して送信できます。クイックフローでは、New Relic AI エージェントを呼び出して、定期的なトリアージランブックやエスカレーションワークフローを自動化することもできます。Quickは、ランブック、アーキテクチャ文書、オンコールポリシーなど、Spacesに保存されている企業知識とともに回答を表示するため、すべての回答にはライブテレメトリと組織のコンテキストの両方が反映されます。

New Relic と Amazon Quick の統合は、Amazon Quick が利用できるすべての AWS リージョンで利用できます。

Amazon Quick を使い始めるには、ウェブサイトにアクセスして数分でサインアップしてください。New Relic インテグレーションの詳細については、New Relic インテグレーションガイドを読み、インテグレーションページでその他のクイックインテグレーションをご覧ください。

EC2 Instance Store CSI driver now generally available in EKS add-ons

Amazon Elastic Kubernetes Service (Amazon EKS) では、Amazon EKS コンソールと AWS コマンドラインインターフェイス (CLI) を使用して Amazon エラスティッククラウドコンピューティング (EC2) コンテナストレージインターフェイス (CSI) ドライバーをインストールおよび管理できるようになりました。今回の起動により、EC2 ローカルインスタンスストアを EKS クラスターに簡単にアタッチできるようになりました。\n Amazon EC2 インスタンスストア CSI ドライバーは Kubernetes が EC2 インスタンスストアボリュームを使用できるようにするプラグインです。インスタンスストアボリュームは、ホストコンピュータに物理的に接続された一時的なブロックレベルのストレージを提供します。ドライバーはこれらの NVMe ストレージボリュームのライフサイクルを管理し、Kubernetes 永続ボリュームとして使用できるようにします。

この機能はすべての商用地域で使用できます。使用を開始して詳細については、Amazon EKS のドキュメントをご覧ください。

Amazon Connect Cases now supports customer profile identity resolution

Amazon Connect Cases では、重複する顧客プロファイルが統合されると、ケースが自動的に再関連付けられるようになりました。これにより、エージェントは常に各顧客の完全なケース履歴を確認できます。同じ顧客が複数のプロフィールを持っている場合 (たとえば、異なるチャネルから連絡があったり、異なる連絡先情報を提供したりする場合)、Amazon Connect の顧客プロフィールの ID 解決がそれらの重複を検出して統合し、ケースは関連するすべてのケースを統一されたプロファイルの下にまとめるようになりました。エージェントが複数のプロファイルを検索したり、顧客の履歴を手動でまとめたりする必要はもうありません。\n Amazon Connect Cases は、米国東部 (バージニア北部)、米国西部 (オレゴン)、カナダ (中部)、ヨーロッパ (フランクフルト)、ヨーロッパ (ロンドン)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、アフリカ (ケープタウン) の AWS リージョンで利用できます。詳細を確認して使用を開始するには、Amazon Connect ケースのウェブページとドキュメントをご覧ください。

Amazon Bedrock AgentCore is now available in AWS GovCloud (US-West)

Amazon Bedrock AgentCore は、AWS GovCloud (米国西部) リージョンのコンプライアンスニーズが高いワークロードに、エンタープライズグレードのエージェンシー AI 機能をもたらします。AgentCore は、インフラストラクチャを管理することなく、AI エージェントを大規模に安全に構築、デプロイ、運用するためのプラットフォームです。AgentCore を使用すれば、組織は政府や規制対象のワークロードに必要なセキュリティとコンプライアンス管理を維持しながら、あらゆるフレームワークやモデルを使用してエージェントをプロトタイプから本番稼働まで加速できます。\n AgentCore は、連携または独立して機能する構成可能なサービスを提供します。AgentCore Runtime はセッションを完全に分離してエージェントをデプロイし、長時間実行されるワークロードをサポートします。AgentCore Gateway は、モデルコンテキストプロトコル (MCP) を通じて既存のアプリケーションプログラミングインターフェイス (API) と Lambda 関数をエージェント対応ツールに変換し、エージェントが企業のデータやサービスに安全にアクセスできるようにします。AgentCore Identity は既存の ID プロバイダーと統合して認証と権限委任を自動化し、AgentCore のオブザーバビリティと評価機能により本番環境におけるエージェントのパフォーマンスをリアルタイムで監視し、継続的な品質評価を行います。 Amazon Bedrock AgentCore の詳細については、AgentCore 製品ページをご覧ください。AWS GovCloud (米国) の AgentCore の詳細については、GovCloud のドキュメントを参照してください。

AWS Backup improves performance for Amazon EKS cluster backups

AWS Backup for Amazon EKS では、クラスター状態のバックアップが最大 10 倍速く完了するようになりました。このパフォーマンスの向上により、多数の名前空間と Kubernetes リソースを含む Amazon EKS クラスターのバックアップ時間が大幅に短縮され、大規模なクラスターのバックアップウィンドウが数日から数時間に短縮されました。AWS Backup は、コンピューティング、ストレージ、データベースにまたがる他の AWS サービスとともに Amazon EKS のデータ保護を一元化および自動化できる、ポリシーベースの完全マネージド型で費用対効果の高いソリューションです。パフォーマンスの向上は、Amazon EKS の AWS Backup サポートが利用できるすべての AWS リージョンで、追加料金なしで自動的に有効になります。\n Amazon EKS の AWS バックアップサポートは、すべての AWS 商用リージョンと AWS GovCloud (米国) リージョンでご利用いただけます。リージョンの提供状況と料金の詳細については、AWS Backup の料金表ページをご覧ください。

Amazon EKS 用 AWS Backup の詳細については、製品ページと技術文書をご覧ください。開始するには、AWS Backup コンソールにアクセスしてください。

Amazon OpenSearch Service expands Cluster Insights with a new insight

Amazon OpenSearch Service では、クラスターインサイトの可用性を OpenSearch のすべてのバージョンと Elasticsearch バージョン 6.8 以降に拡張し、コンソールを通じてクラスターの状態とパフォーマンスをプロアクティブに可視化できるようになりました。さらに、新しい「未使用インデックス」インサイトは、OpenSearch クラスター内で過去 30 日間に検索やインデックス作成のアクティビティがまったく行われていないインデックスを特定するのに役立ち、コストを最適化するための実用的な推奨事項を提示します。\n Cluster Insightsがサポートするバージョン範囲が拡大しました。OpenSearch 1.0以降、およびElasticsearch 6.8以降を実行しているお客様は、パフォーマンスと安定性のリスクがワークロードに影響する前に簡単に特定して解決できます。さらに、新しい Unused Index Insight は、検索またはインデックス作成アクティビティのないインデックスを検出し、コストを最適化するためにウォームストレージ層またはコールドストレージ階層への移行を推奨します。これらのインサイトは、コンソール、OpenSearch サービス通知、OpenSearch UI、Amazon EventBridge を通じて利用できるため、ユーザーはクラスターの状態を即座に把握できるとともに、安定性やパフォーマンスに影響が出る前に問題を防ぐための実行可能な推奨事項を提示できます。 クラスターインサイトは、Amazon OpenSearch サービスが利用できるすべてのリージョンで追加料金なしで利用できます。サポートされているリージョンの全リストは、こちらでご覧ください。Cluster Insights の詳細については、当社の技術文書を参照してください。

AWS IAM now provides higher maximum quotas for roles, role trust policies, instance profiles, managed policies, and identity providers

AWS ID およびアクセス管理 (IAM) は、次の 6 つのリソースの最大割り当て量を増やしました。\n

アカウントあたりのカスタマー管理ポリシー (5,000 ～ 10,000)

アカウントあたりのインスタンスプロファイル (5,000 ～ 10,000)

ロールあたりの管理ポリシー (20 ～ 25)

ロールトラストポリシーの長さ (4,096 ～ 8,192 文字)

アカウントあたりのロール数 (5,000 から 10,000 まで)

アカウントあたりの OpenID コネクトプロバイダー (100 から 700)

これらのアップデートは、AWS 環境の拡大に伴ってお客様が直面する一般的なスケーリング制約に対処します。このように上限クォータが高くなると、お客様はより柔軟に IAM コントロールをカスタマイズし、IAM リソースの作成を必要とする追加のワークロードをサポートできるようになります。

お客様は IAM と AWS STS のクォータドキュメントで最新の IAM クォータを確認できます。AWS 商用地域のアカウントのクォータ増加をリクエストするには、米国東部 (バージニア北部) のサービスクォータを使用してください。AWS GovCloud (米国) および中国リージョンでは、お客様は AWS サポートを通じて増加をリクエストできます。詳細については、『サービスクォータユーザーガイド』の「クォータ増加のリクエスト」を参照してください。

AWS Blogs

AWS News Blog

Containers

AWS Database Blog

AWS for Industries

Artificial Intelligence

AWS Security Blog

Open Source Project

AWS CLI

Amplify for JavaScript

Amplify for iOS

AWS Load Balancer Controller