AWSの基礎力をつけるためにAWS What’s Newを毎日目を通す事を始めました。 最初は日本語訳されたものを見ていたのですが、1週間ほど遅れて訳されるようなので、英語の情報を訳して整理することにしました。
本情報が役立つ人もいるかなと思い公開します。 個人的な理解なので、実際の情報は原典をあたってください。
¥3,520 Amazonで見る![AWS運用入門 改訂第2版 押さえておきたいAWSの基本と運用ノウハウ [AWS深掘りガイド] 単行本（ソフトカバー） – 2025/7/11](https://m.media-amazon.com/images/I/61ftnZ09WvL._SY522_.jpg)
AWS運用入門 改訂第2版 押さえておきたいAWSの基本と運用ノウハウ [AWS深掘りガイド] 単行本（ソフトカバー） – 2025/7/11
「Amazon CloudWatch Application SignalsがGitHub ActionとMCPサーバーの改善を追加」CloudWatch APplication Signalsは追加したほうがいいのかなー。
Amazon WorkSpaces Applications が IPv6 をサポート #
投稿日: 2025年11月21日
何ができるようになったのか #
Amazon WorkSpaces Applications は、WorkSpaces Applications ドメインおよび外部エンドポイントで IPv6 をサポートするようになりました。これにより、エンドユーザーは IPv6 対応デバイスから IPv6 経由で WorkSpaces Applications に接続できるようになります（SAML 認証を除く）。
何が嬉しいのか #
IPv6 コンプライアンス要件への対応を支援し、IPv4 と IPv6 間のアドレス変換を処理するための高価なネットワーク機器が不要になります。インターネットの成長により IPv4 アドレスが急速に消費される中、WorkSpaces Applications が IPv6 をサポートすることで、お客様はネットワークアーキテクチャを合理化できます。このサポートにより、はるかに大きなアドレス空間が提供され、VPC 内で重複するアドレス空間を管理する必要がなくなります。お客様は IPv6 上にアプリケーションを構築できるようになり、フォールバックメカニズムを介して既存の IPv4 システムとの互換性を保ちつつ、インフラストラクチャの将来性を確保できます。
これまでとどう変わるのか #
- これまで: WorkSpaces Applications は IPv6 をサポートしていなかったため、IPv6 対応デバイスからの接続や IPv6 コンプライアンス要件への対応が困難でした。また、IPv4 と IPv6 間のアドレス変換のために高価なネットワーク機器が必要となる場合がありました。
- これから: WorkSpaces Applications が IPv6 をサポートするようになり、IPv6 対応デバイスから直接接続できるようになりました。これにより、IPv6 コンプライアンス要件を満たしやすくなり、ネットワークアーキテクチャの簡素化とアドレス変換機器の不要化が実現します。
具体的なユースケース #
- IPv6 コンプライアンス要件を満たす必要がある場合。
- ネットワークアーキテクチャを簡素化し、運用コストを削減したい場合。
- VPC 内で重複する IPv4 アドレス空間の管理を避けたい場合。
- 将来を見据え、IPv6 ベースのアプリケーションインフラストラクチャを構築したい場合。
Amazon Aurora DSQL データベースクラスターが最大 256 TiB のストレージ容量をサポート #
投稿日: 2025年11月21日
何ができるようになったのか #
Amazon Aurora DSQL が最大ストレージ容量 256 TiB をサポートするようになりました。これにより、以前の 128 TiB から倍増しました。お客様は、単一のデータベースクラスター内でより大規模なデータセットを保存および管理できるようになり、大規模アプリケーションのデータ管理が簡素化されます。
何が嬉しいのか #
Aurora DSQL では、お客様は使用したストレージに対してのみ料金を支払い、ストレージは使用量に応じて自動的にスケーリングされるため、事前にストレージをプロビジョニングする必要がありません。
これまでとどう変わるのか #
- これまで: 最大ストレージ容量が 128 TiB でした。
- これから: 最大ストレージ容量が 256 TiB になりました。
具体的なユースケース #
- 大規模アプリケーションのデータ管理を簡素化する。
- より大規模なデータセットを単一のデータベースクラスター内で保存および管理する。
Amazon Aurora DSQL が AWS マネジメントコンソールに統合されたクエリ エディタを提供開始 #
投稿日: 2025年11月21日
何ができるようになったのか #
Amazon Aurora DSQL は、ブラウザベースの SQL アクセスを可能にする統合クエリ エディタを提供するようになりました。このリリースにより、お客様は外部クライアントをインストールまたは設定することなく、AWS マネジメントコンソールから直接 Aurora DSQL クラスターに安全に接続し、SQL クエリを実行できます。
Aurora DSQL クエリ エディタは、組み込みの構文ハイライト、オートコンプリート、インテリジェントなコードアシスタンスを備えた直感的なワークスペースを提供します。単一のインターフェース内で、スキーマオブジェクトの迅速な探索、SQL クエリの開発と実行、結果の表示が可能です。
何が嬉しいのか #
この機能により、開発者、アナリスト、データエンジニアはクラスター作成後すぐにクエリを開始でき、価値実現までの時間を短縮し、データベース操作を簡素化できます。この統合されたエクスペリエンスは、データ探索と分析を効率化し、ユーザーが Aurora DSQL をより簡単に使い始めることを可能にします。
これまでとどう変わるのか #
- これまで: ユーザーは SQL アクセスのために外部クライアントをインストールおよび設定する必要がありました。
- これから: 外部クライアントのインストールや設定なしに、AWS マネジメントコンソールから直接 Aurora DSQL クラスターに安全に接続し、SQL クエリを実行できるようになりました。
具体的なユースケース #
- 開発者、アナリスト、データエンジニアがクラスター作成後すぐにクエリを開始し、価値実現までの時間を短縮する。
- スキーマオブジェクトを迅速に探索し、SQL クエリを開発・実行し、結果を単一のインターフェースで表示する。
- データ探索と分析を効率化し、Aurora DSQL の利用開始を容易にする。
Amazon Bedrock が追加リージョンで利用可能に #
投稿日: 2025年11月19日
何ができるようになったのか #
本日より、アフリカ (ケープタウン)、カナダ西部 (カルガリー)、メキシコ (中央)、中東 (バーレーン) リージョンで Amazon Bedrock を利用できるようになりました。これにより、様々な基盤モデル (FM) や強力なツールを使用して、生成 AI アプリケーションを簡単に構築・拡張できます。
何が嬉しいのか #
Amazon Bedrock は、生成 AI アプリケーションやエージェントを構築するための包括的で安全なサービスです。主要な基盤モデル (FM) やエージェントをデプロイ・運用するためのサービスに接続することで、実験段階から実際のデプロイメントへと迅速に移行できます。
これまでとどう変わるのか #
- これまで: これらのリージョンでは Amazon Bedrock が利用できませんでした。
- これから: アフリカ (ケープタウン)、カナダ西部 (カルガリー)、メキシコ (中央)、中東 (バーレーン) リージョンで Amazon Bedrock が利用可能になりました。
具体的なユースケース #
- 生成 AI アプリケーションを構築し、スケールさせる
- 生成 AI エージェントをデプロイし、運用する
Amazon Braket、Alpine Quantum Technologies (AQT) の新しい量子プロセッサを追加 #
投稿日: 2025年11月20日
何ができるようになったのか #
Amazon Braket は、Alpine Quantum Technologies (AQT) が提供するトラップドイオン量子処理ユニット (QPU) である IBEX Q1 へのアクセスを提供するようになりました。IBEX Q1 は、オールツーオール接続を備えた 12 量子ビットシステムで、中間 SWAP ゲートを必要とせずに、任意の量子ビットが他の任意の量子ビットと直接相互作用できます。
何が嬉しいのか #
お客様は、AQT のトラップドイオン技術にオンデマンドでアクセスして量子プログラムを構築およびテストでき、Hybrid Jobs を介して変分量子アルゴリズムを実行するための優先アクセスも利用できます。これらはすべて従量課金制です。また、Braket Direct を介して、時間単位の料金で前払いなしで、時間制約のあるワークロード向けにこの QPU の専用キャパシティを予約することもできます。ヨーロッパのタイムゾーンのお客様は、勤務時間中に便利なアクセスが可能です。
これまでとどう変わるのか #
- これまで: お客様は Amazon Braket 上で AQT の IBEX Q1 QPU に直接アクセスできませんでした。
- これから: お客様は Amazon Braket 上で AQT の IBEX Q1 QPU にオンデマンドおよび優先的にアクセスできるようになり、オールツーオール接続と柔軟な料金オプションを利用できます。
具体的なユースケース #
- 量子プログラムの構築とテスト
- 変分量子アルゴリズムの実行
- 時間制約のある量子ワークロード
Amazon Braketが量子処理ユニットの利用制限機能を開始 #
投稿日: 2025年11月20日
何ができるようになったのか #
Amazon Braketが利用制限（spending limits）機能を導入しました。これにより、お客様は量子処理ユニット（QPU）の利用に上限を設定し、コストを管理できるようになります。利用制限を設定すると、デバイスごとに最大利用額のしきい値を定義でき、Amazon Braketは各タスクの送信が事前に設定された制限を超えないことを自動的に検証します。残りの予算を超えるタスクは、作成前に拒否されます。
何が嬉しいのか #
利用制限機能は、複数のユーザー間で量子コンピューティングの予算を管理する研究機関、コースワーク中の意図しない過剰な利用を防ぐ教育環境、および量子アルゴリズムを実験する開発チームにとって特に価値があります。お客様は、要件の変化に応じていつでも利用制限を更新または削除できます。
これまでとどう変わるのか #
- これまで: タスクが予算を超える可能性があり、全体的なコスト管理はAWS Budgetsに依存する必要がありました。
- これから: Amazon Braketが各タスクの送信が事前に設定された制限を超えないことを自動的に検証し、残りの予算を超えるタスクは作成前に拒否されます。
具体的なユースケース #
- 複数のユーザー間で量子コンピューティングの予算を管理する研究機関
- コースワーク中の意図しない過剰な利用を防ぐ教育環境
- 量子アルゴリズムを実験する開発チーム
Amazon CloudFrontがCloudFront Functionsの3つの新機能を発表 #
投稿日: 2025年11月20日
何ができるようになったのか #
Amazon CloudFrontは、CloudFront Functions向けに3つの新機能をサポートしました。これにより、開発者はCloudFrontのインフラストラクチャに対する可視性を高め、オリジン接続をより正確かつきめ細かく制御できるようになり、より洗練されたエッジコンピューティングロジックを構築できます。
新機能は以下の通りです。
- エッジロケーションおよびRegional Edge Cache (REC) メタデータ: サービスを提供するエッジロケーションの3文字の空港コードと、予期されるRECが含まれます。
- 生のクエリ文字列の取得: ビューアから受信した完全な未処理のクエリ文字列にアクセスでき、標準的な解析中に変更される可能性のある特殊文字やエンコーディングが保持されます。
- 高度なオリジンオーバーライド: Server Name Indication (SNI) を含むSSL/TLSハンドシェイクパラメータをカスタマイズできるようになり、複雑なアプリケーションインフラストラクチャにおける重要な課題を解決します。
何が嬉しいのか #
これらの新機能により、開発者はCloudFrontのインフラストラクチャに対する可視性が向上し、オリジン接続をより正確かつきめ細かく制御できるようになります。CloudFront Functionsは、CloudFrontエッジロケーションで軽量なJavaScriptコードをサブミリ秒の実行時間で実行し、コンテンツ配信をカスタマイズしたり、セキュリティポリシーを実装したりすることを可能にします。
これまでとどう変わるのか #
- これまで: CloudFrontのインフラストラクチャに対する可視性が低く、オリジン接続の制御が限定的でした。標準のクエリ文字列解析では特殊文字が変更される可能性があり、SSL/TLSハンドシェイクパラメータのカスタマイズも限られていました。
- これから: CloudFrontのインフラストラクチャに対する可視性が向上し、オリジン接続を正確かつきめ細かく制御できます。完全な未処理のクエリ文字列にアクセスでき、SNIを含むSSL/TLSハンドシェイクパラメータをカスタマイズできるようになりました。
具体的なユースケース #
- エッジロケーションメタデータ: クライアントのロケーションに基づいて、ヨーロッパのユーザーをGDPR準拠のオリジンに誘導するなど、地域固有のコンテンツルーティングやコンプライアンス要件に対応できます。
- 生のクエリ文字列の取得: 特殊文字や特定のエンコーディングを含むクエリ文字列を、変更せずに処理する必要がある場合に利用できます。
- 高度なオリジンオーバーライド: 異なる証明書ドメインを持つサーバーに解決されるCNAMEチェーンを介してCloudFrontが接続するマルチテナント設定など、複雑なアプリケーションインフラストラクチャでSNIをオーバーライドするなど、SSL/TLSハンドシェイクパラメータをカスタマイズする場合に役立ちます。
Amazon CloudFront が CBOR Web Tokens と Common Access Tokens に対応 #
投稿日: 2025年11月20日
何ができるようになったのか #
Amazon CloudFront が CBOR Web Tokens (CWT) と Common Access Tokens (CAT) に対応しました。CWT は Concise Binary Object Representation (CBOR) エンコーディングを使用する JSON Web Tokens (JWT) のコンパクトなバイナリ代替手段であり、CAT は CWT を拡張し、URL パターン、IP 制限、HTTP メソッド制限を含むきめ細かなアクセス制御を追加します。どちらのトークンタイプも、セキュリティ強化のために CBOR Object Signing and Encryption (COSE) を使用します。これにより、CloudFront のエッジロケーションで CloudFront Functions を使用したセキュアなトークンベースの認証と認可が可能になり、サブミリ秒の実行時間で軽量かつ高性能な認証メカニズムをエッジで直接実装できます。
何が嬉しいのか #
ライブビデオストリーミングプラットフォームのように毎秒数百万回のビューアアクセストークン検証が必要なパフォーマンス重視のアプリケーションや、帯域幅効率が重要な IoT アプリケーションに最適です。また、マルチ CDN デプロイメント全体でコンテンツ認証のための単一の標準化された方法を提供し、セキュリティ管理を簡素化し、各 CDN プロバイダに固有の設定が不要になります。
これまでとどう変わるのか #
- これまで: エッジでのトークンベースの認証と認可は、特にマルチ CDN 環境において、より複雑でパフォーマンスが低く、カスタムソリューションが必要となる場合がありました。
- これから: CloudFront Functions が CWT と CAT を使用して、セキュアで高性能なトークンベースの認証と認可を直接処理できるようになり、マルチ CDN のセキュリティ管理が簡素化されます。
具体的なユースケース #
- メディア企業は CAT を使用して、サブスクリプションティア、地理的ロケーション、デバイスタイプに基づいて特定のビデオコンテンツへのアクセスを制限するトークンを作成できます。これらは、アプリケーションのネットワーク呼び出しを必要とせずに、CloudFront および他の CDN プロバイダ全体で一貫して検証されます。
- 開発者は、CloudFront Functions 内で受信トークンの検証、新しいトークンの生成、およびトークン更新ロジックの実装を行うことができ、CloudFront Functions KeyValueStore とシームレスに統合してセキュアなキー管理を実現します。
Amazon CloudFrontがオリジン接続でTLS 1.3をサポート開始 #
投稿日: 2025年11月20日
何ができるようになったのか #
Amazon CloudFrontがオリジンへの接続でTLS 1.3をサポートするようになりました。これにより、オリジン通信のセキュリティが強化され、パフォーマンスが向上します。このアップグレードは、より強力な暗号化アルゴリズム、ハンドシェイクのレイテンシーの削減、およびCloudFrontエッジロケーションとオリジンサーバー間のデータ転送における全体的なセキュリティ体制の向上を提供します。TLS 1.3のサポートは、カスタムオリジン、Amazon S3、Application Load Balancerを含むすべてのオリジンタイプで自動的に有効になり、設定変更は不要です。
何が嬉しいのか #
TLS 1.3は、ハンドシェイクプロセス中のラウンドトリップ数を削減することで、より高速な接続確立を実現し、オリジンがサポートしている場合は接続パフォーマンスを最大30%向上させます。CloudFrontは、オリジンがTLS 1.3をサポートしている場合に自動的にTLS 1.3をネゴシエートし、まだアップグレードしていないオリジンとの下位TLSバージョンとの後方互換性も維持します。この機能強化は、金融サービス、ヘルスケア、機密データを扱うeコマースプラットフォームなど、高いセキュリティ基準を必要とするアプリケーションに利益をもたらします。
これまでとどう変わるのか #
- これまで: CloudFrontはオリジン接続でTLS 1.3をサポートしておらず、下位のTLSバージョンを使用していました。
- これから: CloudFrontはオリジン接続でTLS 1.3をサポートし、オリジンが対応していれば自動的にTLS 1.3をネゴシエートします。
具体的なユースケース #
- 金融サービス、ヘルスケア、機密データを扱うeコマースプラットフォームなど、高いセキュリティ基準を必要とするアプリケーション。
Amazon CloudWatch Application Mapが未計測サービスの検出をサポート #
投稿日: 2025年11月20日
何ができるようになったのか #
Amazon CloudWatchのApplication Mapが、未計測サービスの検出、クロスアカウントビュー、および変更履歴をサポートするようになりました。これにより、SREおよびDevOpsチームは、大規模な分散アプリケーションの監視とトラブルシューティングをより効率的に行えるようになります。Application Mapは、Application Signalsで計測されていないサービスを検出して可視化し、分散環境でそのまま利用できるオブザーバビリティを提供します。また、複数のAWSアカウントに分散されたアプリケーション、サービス、インフラストラクチャに対して単一の統合ビューを提供し、エンドツーエンドの可視性を実現します。さらに、最近の変更履歴を提供することで、変更がいつ発生し、アプリケーションの健全性やパフォーマンスの変化とどのように関連しているかを迅速に把握するのに役立ちます。
何が嬉しいのか #
これらの機能強化により、SREおよびDevOpsチームは、大規模な分散環境において、より迅速に問題をトラブルシューティングし、高い信頼性で運用できるようになります。Application Mapは、サービス検出、依存関係マッピング、および変更履歴を統合することで、平均復旧時間 (MTTR) を短縮し、複雑なシステム全体でアプリケーションの健全性を維持するのに貢献します。
これまでとどう変わるのか #
- これまで: Application Signalsで計測されていないサービスは、Application Mapで自動的に検出・可視化されませんでした。また、複数のAWSアカウントにまたがるアプリケーションのビューは統合されておらず、変更履歴も関連付けられていませんでした。
- これから: Application Mapは、Application Signalsで計測されていないサービスも検出・可視化し、クロスアカウントの統合ビューと変更履歴を提供することで、分散環境全体のエンドツーエンドの可視性とトラブルシューティング能力を向上させます。
具体的なユースケース #
- レイテンシーやエラー率が急増した場合、開発者は単一のマップから最近の構成変更を調査し、複数のAWSアカウントにわたる依存関係を分析できます。
- インシデント後のレビューでは、チームは履歴変更データを使用して、何がいつ変更されたかを理解し、長期的な信頼性を向上させることができます。
Amazon CloudWatch Application SignalsがGitHub ActionとMCPサーバーの改善を追加 #
投稿日: 2025年11月21日
何ができるようになったのか #
AWSは、アプリケーションの可観測性を開発者ツールに統合し、問題のトラブルシューティングをより迅速かつ便利にする新しいGitHub Actionと、CloudWatch Application Signals MCPサーバーの改善の一般提供を発表しました。これにより、GitHubワークフロー内でSLO違反や重大なサービスエラーを検知できるようになります。さらに、KiroのようなAIコーディングエージェントでCloudWatch Application Signals MCPサーバーを使用し、レイテンシー、エラー、またはSLO違反の原因となっている正確なファイル、関数、コード行を特定できるようになりました。包括的な可観測性カバレッジを確保するためのインストゥルメンテーションガイダンスも提供されます。
何が嬉しいのか #
この新しいGitHub Actionにより、開発者はGitHub Issuesで「チェックアウトサービスで高レイテンシーが発生しているのはなぜですか？」のようなプロンプトとともに@awsapmをメンションするだけで、コンソールを切り替えることなく、可観測性に基づいたインテリジェントな応答を受け取ることができ、時間と労力を節約できます。また、CloudWatch Application Signals MCPサーバーの改善により、「サービスでレイテンシーの急増を引き起こしたコード行はどれですか？」といった質問も可能になりました。インストゥルメンテーションが不足している場合、MCPサーバーはInfrastructure-as-Code（例: CDK、Terraform）を変更して、ECS、EKS、Lambda、およびEC2向けにOTelベースのアプリケーションパフォーマンスモニタリングをコーディング作業なしで設定するのに役立ちます。これらの機能は、可観測性を開発ワークフローに統合し、コンテキストスイッチングを減らし、コードから本番環境までのインテリジェントなエージェント支援デバッグを可能にします。
これまでとどう変わるのか #
- これまで: 開発者は、本番環境の問題をトリアージし、トレースデータを検索し、可観測性カバレッジを確保するためにGitHubを離れる必要があり、多くの場合、コンソール、ダッシュボード、ソースコードを切り替えていました。
- これから: Application observability for AWS GitHub Actionは、GitHubワークフロー内でSLO違反や重大なサービスエラーを検知するのに役立ちます。AIコーディングエージェント（Kiroなど）でCloudWatch Application Signals MCPサーバーを使用し、レイテンシー、エラー、またはSLO違反の原因となっている正確なファイル、関数、コード行を特定できます。開発者はGitHub Issuesでプロンプトとともに@awsapmをメンションするだけで、コンソールを切り替えることなく、可観測性に基づいたインテリジェントな応答を受け取ることができます。MCPサーバーは、インストゥルメンテーションが不足している場合にInfrastructure-as-Codeを変更して、OTelベースのアプリケーションパフォーマンスモニタリングを設定できます。
具体的なユースケース #
- GitHubワークフロー内で直接、SLO違反や重大なサービスエラーを検知する。
- AIコーディングエージェント（Kiroなど）とCloudWatch Application Signals MCPサーバーを連携させ、レイテンシー、エラー、またはSLO違反の原因となっている正確なファイル、関数、コード行を特定する。
- GitHubを離れることなく、GitHub Issuesで「チェックアウトサービスで高レイテンシーが発生しているのはなぜですか？」のようなプロンプトに対して、可観測性に基づいたインテリジェントな応答を受け取る。
- MCPサーバーに「サービスでレイテンシーの急増を引き起こしたコード行はどれですか？」といった質問をする。
- インストゥルメンテーションが不足している場合に、Infrastructure-as-Code（CDK、Terraform）を自動的に変更し、ECS、EKS、Lambda、およびEC2向けにOTelベースのアプリケーションパフォーマンスモニタリングを設定する。
Amazon Connect がキューに登録されたコールバック連絡先のモニタリングを開始 #
投稿日: 2025年11月21日
何ができるようになったのか #
Amazon Connect で、コールバックのためにキューに登録されている連絡先をモニタリングできるようになりました。この機能により、Connect UI および API 内で、コールバックのためにキューに登録された連絡先を検索し、顧客の電話番号やキューに登録されている期間などの詳細情報を表示できます。
何が嬉しいのか #
顧客に伝えられたコールバック期限を超えるリスクのある連絡先を、プロアクティブにエージェントにルーティングできるようになります。また、すでにエージェントと正常に接続された顧客を特定し、コールバックキューから削除して重複作業をなくすこともできます。
これまでとどう変わるのか #
- これまで: コールバックのためにキューに登録された連絡先の詳細なモニタリングが困難でした。
- これから: Connect UI および API を通じて、コールバックのためにキューに登録された連絡先を検索し、顧客の電話番号やキューに登録されている期間などの詳細情報を確認できます。
具体的なユースケース #
- 顧客に伝えられたコールバック期限を超えるリスクのある連絡先を、事前にエージェントにルーティングする。
- すでにエージェントと正常に接続された顧客を特定し、コールバックキューから削除して重複作業をなくす。
Amazon Connect アウトバウンドキャンペーンが応答なしコールの呼び出し時間設定に対応 #
投稿日: 2025年11月19日
何ができるようになったのか #
Amazon Connect アウトバウンドキャンペーンで、キャンペーンマネージャーが音声コールの呼び出し時間を15秒から60秒の間で設定できるようになりました。これにより、コールが「応答なし」とマークされ、次の連絡先に移行するまでの時間を調整できます。各連絡先については、呼び出しが開始および終了した時刻も記録され、正確なレポート作成と追跡が可能になります。
何が嬉しいのか #
呼び出し時間を設定できるようになったことで、キャンペーンマネージャーは各キャンペーンの対象顧客に合わせてダイヤル動作を調整し、各コールがどれだけ長く鳴ったかを分析で確認し、接続が失われた場所を把握できるようになります。この可視性により、パターンを特定し、発信戦略を洗練させ、キャンペーンの効果を継続的に向上させることができます。
これまでとどう変わるのか #
- これまで: 呼び出し時間が固定されている場合、企業は発信効率と顧客到達率のバランスを取るのに苦労していました。呼び出し時間が短すぎると、応答に時間がかかる顧客を逃す可能性があり、長すぎるとキャンペーン全体の進行が遅れていました。この制御の欠如は、一貫性のないコンタクト率とエージェントの生産性低下につながっていました。
- これから: キャンペーンマネージャーは、音声コールの呼び出し時間を15秒から60秒の間で設定できるようになり、コールが「応答なし」とマークされ、次の連絡先に移行するまでの時間を調整できます。各連絡先については、呼び出しが開始および終了した時刻も記録され、正確なレポート作成と追跡が可能になります。
具体的なユースケース #
- キャンペーンマネージャーは、各キャンペーンの対象顧客に合わせてダイヤル動作を調整し、分析を使用して各コールがどれだけ長く鳴ったかを正確に確認し、接続が失われた場所を理解することで、パターンを特定し、発信戦略を洗練させ、キャンペーンの効果を継続的に向上させることができます。
Amazon Connect がより迅速な通話処理のための永続的なエージェント接続を提供開始 #
投稿日: 2025年11月20日
何ができるようになったのか #
Amazon Connect が、エージェントと Amazon Connect 間でオープンな通信チャネルを維持する機能を提供するようになりました。これにより、顧客との接続確立にかかる時間を短縮できます。コンタクトセンター管理者は、会話終了後も永続的な接続を維持するようにエージェントのユーザープロファイルを構成でき、その後の通話がより迅速に接続されるようになります。
何が嬉しいのか #
この機能により、顧客との接続にかかる時間が短縮されるため、通話処理が高速化されます。また、米国電話消費者保護法 (TCPA) のようなテレマーケティング法への準拠を容易にし、アウトバウンドキャンペーンでの顧客接続時間の短縮に貢献します。
これまでとどう変わるのか #
- これまで: エージェントは通話ごとに新しい接続を確立する必要があり、接続に時間がかかる場合がありました。
- これから: 会話終了後も永続的な接続を維持できるため、後続の通話がより迅速に接続されます。
具体的なユースケース #
- 米国電話消費者保護法 (TCPA) などのテレマーケティング法に準拠するため、アウトバウンドキャンペーンでの顧客接続時間を短縮する。
Amazon EC2 Auto Scaling がインスタンスリフレッシュによるルートボリューム置換をサポート #
投稿日: 2025年11月20日
何ができるようになったのか #
Amazon EC2 Auto Scaling は、インスタンスリフレッシュ内に新しい戦略「ReplaceRootVolume」を発表しました。この機能により、お客様は EC2 インスタンスを停止または終了することなくルートボリュームを更新でき、他の関連するインスタンスリソースを保持できます。
何が嬉しいのか #
この機能は、運用上の複雑さを軽減し、ソフトウェアパッチ適用を簡素化し、破損したルートボリュームからの復旧を効率化します。組織は、キャパシティ管理を心配することなく、OS レベルの更新やセキュリティパッチをより効率的に実装できるようになります。ステートフルなアプリケーションを使用しているお客様は、新しい ReplaceRootVolume 戦略により、インスタンスのデータ、メタデータ、アタッチメント（ネットワークインターフェースや Elastic IP など）が保持されるため、より安心してフリートをリフレッシュできます。
これまでとどう変わるのか #
- これまで: 従来、このプロセスでは、古いインスタンスを終了し、新しいインスタンスを制御された方法で起動する必要がありました。
- これから: 新しい ReplaceRootVolume 戦略は、EC2 Auto Scaling サービスが実行中のインスタンスのルート Amazon EBS ボリュームを停止することなく置換できるようにすることで、お客様が Auto Scaling グループ (ASG) 内のインスタンスライフサイクルとソフトウェア更新を管理する方法を変革します。
具体的なユースケース #
- OS レベルの更新やセキュリティパッチの適用
- Mac や GPU インスタンスのような特殊なインスタンスタイプを使用するワークロードの管理
- ステートフルなアプリケーションのフリート更新時におけるデータ、メタデータ、アタッチメントの保持
Amazon EC2 C7i インスタンスがアジアパシフィック (メルボルン) リージョンで利用可能に #
投稿日: 2025年11月20日
何ができるようになったのか #
本日より、カスタムの第4世代 Intel Xeon Scalable プロセッサ (コードネーム Sapphire Rapids) を搭載した Amazon Elastic Compute Cloud (Amazon EC2) C7i インスタンスが、アジアパシフィック (メルボルン) リージョンで利用可能になりました。C7i インスタンスは、AWS のみで利用可能なカスタム Intel プロセッサによって強化されており、他のクラウドプロバイダーが利用する同等の x86 ベースの Intel プロセッサと比較して、最大15%優れたパフォーマンスを提供します。
C7i インスタンスは、C6i インスタンスと比較して最大15%優れた価格性能を提供し、バッチ処理、分散分析、広告配信、ビデオエンコーディングなどのあらゆるコンピューティング集約型ワークロードに最適な選択肢です。C7i インスタンスは、最大48xlargeのより大きなインスタンスサイズと、2つのベアメタルサイズ (metal-24xl、metal-48xl) を提供します。これらのベアメタルサイズは、データ操作の効率的なオフロードと高速化を促進し、ワークロードのパフォーマンスを最適化するために使用される、組み込みの Intel アクセラレーター (Data Streaming Accelerator、In-Memory Analytics Accelerator、QuickAssist Technology) をサポートしています。
C7i インスタンスは、CPU ベースの ML などのアプリケーション向けに行列乗算操作を高速化する新しい Intel Advanced Matrix Extensions (AMX) をサポートしています。お客様は、C6i インスタンスの最大28個に対し、C7i インスタンスには最大128個の EBS ボリュームをアタッチできます。
何が嬉しいのか #
C7i インスタンスは、C6i インスタンスと比較して最大15%優れた価格性能を提供し、コンピューティング集約型ワークロードのコスト効率を向上させます。カスタム Intel プロセッサにより、他のクラウドプロバイダーの同等プロセッサよりも最大15%優れたパフォーマンスを実現します。ベアメタルインスタンスで利用可能な Intel アクセラレーターは、データ操作を効率的にオフロードおよび高速化し、ワークロードのパフォーマンスを最適化します。Intel AMX のサポートにより、CPU ベースの機械学習アプリケーションにおける行列乗算操作が高速化されます。また、より多くの EBS ボリュームをアタッチできるため、大量のデータを処理し、ワークロードをスケールし、C6i インスタンスよりもパフォーマンスを向上させることができます。
これまでとどう変わるのか #
- これまで: アジアパシフィック (メルボルン) リージョンでは、C7i インスタンスは利用できませんでした。EBS ボリュームの最大アタッチ数は28個でした。特定の Intel アクセラレーターや Intel AMX は利用できませんでした。
- これから: アジアパシフィック (メルボルン) リージョンで C7i インスタンスが利用可能になり、C6i インスタンスと比較して最大15%優れた価格性能を提供します。最大128個の EBS ボリュームをアタッチでき、Intel Data Streaming Accelerator、In-Memory Analytics Accelerator、QuickAssist Technology、Intel AMX などのアクセラレーターが利用可能になります。
具体的なユースケース #
- バッチ処理、分散分析、広告配信、ビデオエンコーディングなどのコンピューティング集約型ワークロードの実行。
- CPU ベースの機械学習アプリケーションでの行列乗算操作の高速化。
- 大量のデータを処理し、ワークロードをスケールする必要があるアプリケーション。
- データ操作の効率的なオフロードと高速化を必要とするワークロード。
Amazon EC2 Fleet がインスタンスタイプ選択に新しい暗号化属性を追加 #
投稿日: 2025年11月21日
何ができるようになったのか #
Amazon EC2 Fleet は、属性ベースのインスタンスタイプ選択 (ABIS) 向けに新しい暗号化属性をサポートするようになりました。お客様は、vCPU コアやメモリなどのリソース要件に加えて、RequireEncryptionInTransit パラメータを使用して、転送中の暗号化をサポートするインスタンスタイプを具体的に起動できるようになります。
何が嬉しいのか #
この新しい暗号化属性は、VPC Encryption Controls を強制モードで使用し、すべてのネットワークトラフィックが転送中に暗号化されることを要求するお客様の重要なコンプライアンスニーズに対応します。ABIS で暗号化要件と他のインスタンス属性を組み合わせることで、お客様はセキュリティニーズを満たしながら、より良いキャパシティ確保のためにインスタンスタイプの多様化を実現できます。さらに、GetInstanceTypesFromInstanceRequirements (GITFIR) を使用すると、指定した暗号化要件に基づいてどのインスタンスタイプが割り当てられるかをプレビューできます。
これまでとどう変わるのか #
- これまで: 属性ベースのインスタンスタイプ選択 (ABIS) において、転送中の暗号化をサポートするインスタンスタイプを明示的に指定する属性がありませんでした。
- これから:
RequireEncryptionInTransitパラメータを ABIS で使用することで、vCPU コアやメモリなどのリソース要件に加えて、転送中の暗号化をサポートするインスタンスタイプを具体的に起動できるようになりました。
具体的なユースケース #
- VPC Encryption Controls を強制モードで使用し、すべてのネットワークトラフィックが転送中に暗号化されることを要求する環境で、コンプライアンス要件を満たすインスタンスを起動する。
CreateFleetまたはGITFIRAPI を呼び出す際に、InstanceRequirementsでRequireEncryptionInTransitパラメータをtrueに設定し、暗号化対応インスタンスタイプのみをターゲットにする。
Amazon EC2 High Memory U7i インスタンスが追加リージョンで利用可能に #
投稿日: 2025年11月20日
何ができるようになったのか #
Amazon EC2 High Memory U7i インスタンスが以下の追加リージョンで利用可能になりました。
- 16TBメモリ (u7in-16tb.224xlarge) の U7i インスタンスが AWS 欧州 (アイルランド) リージョンで利用可能。
- 12TBメモリ (u7i-12tb.224xlarge) の U7i インスタンスが AWS アジアパシフィック (ハイデラバード) リージョンで利用可能。
- 8TBメモリ (u7i-8tb.112xlarge) の U7i インスタンスがアジアパシフィック (ムンバイ) および AWS GovCloud (米国西部) リージョンで利用可能。
これらのインスタンスは、カスタムの第4世代 Intel Xeon Scalable プロセッサ (Sapphire Rapids) を搭載し、DDR5 メモリを提供します。
何が嬉しいのか #
急速に成長するデータ環境において、顧客はトランザクション処理スループットを拡張できるようになります。これにより、より多くのリージョンでミッションクリティカルなインメモリデータベースのワークロードを効率的に実行できます。
これまでとどう変わるのか #
- これまで: EC2 High Memory U7i インスタンスは、これらの追加リージョンでは利用できませんでした。
- これから: EC2 High Memory U7i インスタンスが、欧州 (アイルランド)、アジアパシフィック (ハイデラバード)、アジアパシフィック (ムンバイ)、および AWS GovCloud (米国西部) リージョンで利用可能になり、より広範な地域で高性能なインメモリワークロードをサポートできるようになりました。
具体的なユースケース #
- SAP HANA、Oracle、SQL Server のようなミッションクリティカルなインメモリデータベースの実行。
Amazon EC2 MacインスタンスがApple macOS Tahoeをサポート #
投稿日: 2025年11月20日
何ができるようになったのか #
Amazon EC2 Macインスタンスで、Apple macOS Tahoe (バージョン26) をAmazon Machine Image (AMI) として実行できるようになりました。macOS Tahoeは最新のメジャーmacOSバージョンであり、Xcode 26.0以降 (iOS、iPadOS、macOS、tvOS、watchOS、visionOSの最新SDKを含む) の実行など、以前のmacOSバージョンと比較して複数の新機能とパフォーマンスの向上が導入されています。
何が嬉しいのか #
開発者は、Amazon EC2 Macインスタンス上で最新のmacOS環境を利用して、Apple製デバイス向けのアプリケーションを構築およびテストできます。Amazon Elastic Block Store (EBS) に支えられたEC2 macOS AMIは、AWSがサポートするイメージであり、開発ワークロード向けに安定した、安全で高性能な環境を提供します。これらのAMIには、AWS Command Line Interface、Xcode用コマンドラインツール、Amazon SSM Agent、およびHomebrewが含まれており、すぐに開発を開始できます。
これまでとどう変わるのか #
- これまで: macOS Tahoe以前のバージョンがAmazon EC2 Macインスタンスで利用可能でした。
- これから: 最新のmacOS Tahoeが利用可能になり、最新のXcodeやSDKを利用した開発が可能になります。
具体的なユースケース #
- 最新のApple製デバイス向けアプリケーションの開発とテスト。
- macOS Tahoeの新機能やパフォーマンス向上を活用した開発ワークロードの実行。
- Xcodeの最新バージョンとSDKを必要とするCI/CDパイプラインの構築。
Amazon ECR がマネージド型コンテナイメージ署名をサポート #
投稿日: 2025年11月21日
何ができるようになったのか #
Amazon ECR がマネージド型コンテナイメージ署名をサポートするようになりました。これにより、セキュリティ体制を強化し、署名設定の運用上のオーバーヘッドを排除できます。コンテナイメージ署名により、イメージが信頼できるソースからのものであることを検証できます。マネージド署名を使用すると、ECR コンソールでの数クリックまたは単一の API コールで、コンテナイメージ署名の設定が簡素化されます。開始するには、署名の有効期間や ECR がイメージに署名するリポジトリなどのパラメータを指定する AWS Signer 署名プロファイルを使用して署名ルールを作成します。設定が完了すると、ECR はイメージがプッシュされる際に、プッシュするエンティティの ID を使用して自動的にイメージに署名します。ECR は署名操作に AWS Signer を活用し、キーマテリアルと証明書のライフサイクル管理（生成、安全な保存、ローテーションを含む）を処理します。すべての署名操作は CloudTrail を通じてログに記録され、完全な監査可能性が確保されます。ECR マネージド署名は、AWS Signer が利用可能なすべての AWS リージョンで利用できます。
何が嬉しいのか #
セキュリティ体制が強化され、署名設定の運用上の負担がなくなります。イメージが信頼できるソースからのものであることを検証できるようになり、ECR コンソールでの数クリックまたは単一の API コールで簡単に設定できます。
これまでとどう変わるのか #
- これまで: コンテナイメージ署名を設定するには、手動での設定やキー管理など、運用上のオーバーヘッドが発生していました。
- これから: Amazon ECR がマネージド型コンテナイメージ署名をサポートし、ECR コンソールまたは単一の API コールで簡単に設定でき、イメージプッシュ時に自動的に署名されるようになります。
具体的なユースケース #
- 特定の ECR リポジトリにプッシュされたコンテナイメージに、自動的に署名を行う。
- 署名の有効期間を設定し、イメージの信頼性を管理する。
- イメージのプッシュ元エンティティの ID を使用して、イメージの出所を検証可能にする。
Amazon ECS および Amazon EKS がコンソールで強化された AI 搭載のトラブルシューティングを提供開始 #
投稿日: 2025年11月21日
何ができるようになったのか #
Amazon Elastic Container Service (ECS) および Amazon Elastic Kubernetes Service (EKS) は、Amazon Q Developer を介して、AWS マネジメントコンソールで強化された AI 搭載のトラブルシューティングエクスペリエンスを提供するようになりました。新しい AI 搭載のエクスペリエンスは、コンソール内のエラーメッセージやステータスメッセージと合わせてコンテキストに応じて表示され、顧客がワンクリックで問題の根本原因を特定し、軽減策の提案を確認できるよう支援します。
ECS コンソールでは、「Inspect with Amazon Q」ボタンを使用して、失敗したタスク、コンテナのヘルスチェックの失敗、デプロイのロールバックなどの問題をトラブルシューティングできます。タスクの詳細、タスク定義の詳細、またはデプロイの詳細ページでステータス理由をクリックし、ポップオーバーから「Inspect with Amazon Q」をクリックすると、問題のコンテキストがエージェントに提供され、トラブルシューティングを開始できます。クリックすると、Amazon Q は適切な AI ツールを自動的に使用して問題を分析し、関連するログとメトリクスを収集し、根本原因を理解し、軽減策を推奨します。
Amazon EKS コンソールは、オブザーバビリティダッシュボード全体に Amazon Q を統合し、コンテキストに応じた AI アシスタンスにより、クラスター、コントロールプレーン、ノードのヘルスに関する問題を調査およびトラブルシューティングできるようにします。問題を示すテーブルから直接「Inspect with Amazon Q」をクリックするか、問題をクリックして詳細を表示し、その後「Inspect with Amazon Q」を選択して調査を開始できます。Q を活用したエクスペリエンスは、アップグレードのインサイトなど、クラスターレベルのインサイトを深く理解し、潜在的な問題をプロアクティブに特定および軽減するのに役立ちます。Amazon Q はまた、問題を示す Pod 上の Kubernetes イベントを調査することで、ワークロードのトラブルシューティングを効率化し、根本原因の特定と解決を加速します。
何が嬉しいのか #
顧客はワンクリックで問題の根本原因を特定し、軽減策の提案を確認できます。また、根本原因の特定と解決を加速します。
これまでとどう変わるのか #
- これまで: 手動でログやメトリクスを分析し、問題の根本原因を特定し、軽減策を検討する必要がありました。
- これから: コンソール内でエラーやステータスメッセージにコンテキストに応じて表示される AI 搭載のトラブルシューティング機能により、Amazon Q が自動的に問題を分析し、関連するログやメトリクスを収集し、根本原因を理解し、軽減策を推奨します。
具体的なユースケース #
- 失敗したタスク、コンテナのヘルスチェックの失敗、デプロイのロールバックなどの問題をトラブルシューティングする。
- クラスター、コントロールプレーン、ノードのヘルスに関する問題をコンテキストに応じた AI アシスタンスで調査およびトラブルシューティングする。
- アップグレードのインサイトなど、クラスターレベルのインサイトを深く理解し、潜在的な問題をプロアクティブに特定および軽減する。
- 問題を示す Pod 上の Kubernetes イベントを調査することで、ワークロードのトラブルシューティングを効率化し、根本原因の特定と解決を加速する。
Amazon EKS アドオンが AWS Secrets Store CSI Driver プロバイダーをサポート開始 #
投稿日: 2025年11月21日
何ができるようになったのか #
本日、AWS は AWS Secrets Store CSI Driver プロバイダー EKS アドオンの一般提供を発表しました。この新しい統合により、お客様は AWS Secrets Manager からシークレットを、AWS Systems Manager Parameter Store からパラメーターを取得し、Amazon Elastic Kubernetes Service (Amazon EKS) 上で実行されている Kubernetes クラスターにファイルとしてマウントできるようになります。このアドオンは、Secrets Store CSI Driver 用の AWS プロバイダーをインストールおよび管理します。
何が嬉しいのか #
新しい Amazon EKS アドオンにより、お客様は自動化を使用して新規および既存のクラスターを迅速かつ簡単にセットアップし、AWS Secrets Manager および AWS Systems Manager Parameter Store を活用することで、セキュリティを強化し、シークレット管理を簡素化できます。Amazon EKS アドオンは、Kubernetes クラスターの運用ソフトウェアのインストール、設定、およびライフサイクル管理を自動化する厳選された拡張機能であり、クラスターの機能とセキュリティを維持するプロセスを簡素化します。
これまでとどう変わるのか #
- これまで: AWS Secrets Store CSI Driver プロバイダーを Amazon EKS クラスターに手動でセットアップし、管理する必要がありました。
- これから: Amazon EKS アドオンが AWS Secrets Store CSI Driver プロバイダーのインストール、設定、およびライフサイクル管理を自動的に処理します。
具体的なユースケース #
- データベースの認証情報や API キーなどのシークレットを安全に保存および管理し、それらを Amazon EKS クラスターで利用する。
- Amazon EKS クラスターで AWS Secrets Manager および AWS Systems Manager Parameter Store を活用し、シークレット管理を簡素化する。
Amazon Kinesis Data Streams が最大 50 の拡張ファンアウトコンシューマーをサポート #
投稿日: 2025年11月20日
何ができるようになったのか #
Amazon Kinesis Data Streams が、On-demand Advantage ストリーム向けに最大 50 の拡張ファンアウトコンシューマーをサポートするようになりました。
何が嬉しいのか #
ファンアウトの上限が引き上げられたことで、顧客はより多くの独立した低レイテンシー、高スループットのコンシューマーを同じストリームにアタッチできるようになります。これにより、追加のストリームを作成したり、スループットの競合を引き起こしたりすることなく、並列分析、ML パイプライン、コンプライアンスワークフロー、およびマルチチームアーキテクチャを実現できます。On-demand Advantage は、On-demand Standard と比較してデータ使用量が 60% 低価格で提供され、データ取り込みが $0.032/GB、データ取得が $0.016/GB、拡張ファンアウトデータ取得が $0.016/GB となっています。高ファンアウトのワークロードは、On-demand Advantage で最も費用対効果が高くなります。
これまでとどう変わるのか #
- これまで: 拡張ファンアウトコンシューマーの数がより少なく、多数のコンシューマーを使用する際にスループットの競合が発生する可能性がありました。
- これから: 最大 50 の拡張ファンアウトコンシューマーをサポートし、コンシューマーごとに専用のスループット（シャードあたり最大 2 MB/秒）が提供され、自動的にスケーリングします。これにより、他のコンシューマーとの競合なしにデータを受信でき、On-demand Advantage を利用することでコスト効率も向上します。
具体的なユースケース #
- 並列分析
- ML パイプライン
- コンプライアンスワークフロー
- マルチチームアーキテクチャ
Amazon LexがWait & Continue機能を10の新しい言語に拡張 #
投稿日: 2025年11月21日
何ができるようになったのか #
Amazon Lexが、中国語、日本語、韓国語、広東語、スペイン語、フランス語、イタリア語、ポルトガル語、カタロニア語、ドイツ語の10の新しい言語でWait & Continue機能に対応しました。この機能により、決定論的な音声およびチャットボットが、顧客が追加情報を収集している間に一時停止し、準備ができたときにシームレスに会話を再開できるようになります。
何が嬉しいのか #
この機能により、より自然な会話体験が可能になり、顧客が情報を準備する間、ボットが待機することで、会話の中断なくスムーズなやり取りが実現します。
これまでとどう変わるのか #
- これまで: Amazon LexのWait & Continue機能が対応していなかった言語では、顧客が追加情報を収集する際にボットが一時停止できず、会話が中断される可能性がありました。
- これから: 10の新しい言語でWait & Continue機能が利用可能になり、顧客が情報を準備する間、ボットが一時停止し、準備ができたときにシームレスに会話を再開できるようになりました。
具体的なユースケース #
- 支払い詳細を尋ねられた際、顧客がクレジットカードを取り出すために「ちょっと待って」と言うと、ボットは会話を続ける前に待機します。
Amazon Location Service が Address Form Solution Builder を導入 #
投稿日: 2025年11月21日
何ができるようになったのか #
AWS は本日、Amazon Location Service の Address Form Solution Builder を発表しました。これにより、開発者はコードを記述することなく、予測候補、郵便番号などの住所フィールドの自動入力、およびカスタマイズ可能なレイアウトを備えた、ユーザーが住所を入力するのに役立つカスタマイズされた住所フォームを構築できるようになりました。このガイド付きエクスペリエンスにより、開発者は数分ですぐに使用できるアプリケーションを生成し、React JavaScript、React Typescript、またはスタンドアロンの HTML/JavaScript で開発者パッケージをダウンロードできます。
何が嬉しいのか #
開発者は住所フォームを使用して、ユーザーからの住所情報収集のユーザーエクスペリエンス、速度、および精度を向上させることができます。予測候補などの機能は、エンドユーザーが数回のキーストロークで完全な住所を選択できるようにし、データ入力時間とエラー率を削減します。統合された地図ビューにより、ユーザーは選択した住所の位置を視覚化し、地図上のピンの配置を調整して特定の入り口を示すことができます。住所収集の速度と精度を向上させることで、企業は顧客体験を向上させ、詐欺を減らし、配送成功率を高めることができます。
これまでとどう変わるのか #
- これまで: 開発者は、予測候補、自動入力、カスタマイズ可能なレイアウトなどの機能が不足している可能性のある住所フォームを構築するためにコードを記述する必要がありました。
- これから: 開発者は、予測候補、自動入力、カスタマイズ可能なレイアウト、統合された地図ビューなどの機能を備えたカスタマイズされた住所フォームをコードを記述することなく構築できます。数分で、すぐに使用できるアプリケーションを生成できます。
具体的なユースケース #
- ユーザーエクスペリエンスの向上
- 住所収集の迅速化と精度の向上
- データ入力時間とエラー率の削減
- 選択した住所の地図上での視覚化とピン配置の調整
- 顧客体験の向上
- 詐欺の削減
- 配送成功率の向上
Amazon MQ が RabbitMQ バージョン 4.2 をサポート #
投稿日: 2025年11月20日
何ができるようになったのか #
Amazon MQ が RabbitMQ バージョン 4.2 のサポートを開始しました。このバージョンでは、AMQP 1.0 プロトコルのネイティブサポート、Khepri と呼ばれる新しい Raft ベースのメタデータストア、ローカルシャベル、および Quorum queues のメッセージ優先度が導入されています。また、スループットとメモリ管理に関する様々なバグ修正とパフォーマンス改善も含まれています。
RabbitMQ 4.2 の主要なハイライトは、AMQP 1.0 のコアプロトコルとしてのサポートです。これにより、コンシューマが再キューイングまたはデッドレタリングの前にメッセージアノテーションを変更できる「modified outcome」や、クライアントアプリケーションが特定のキューから受信したいメッセージ数を動的に調整できる「granular flow control」などの強化された機能が提供されます。
さらに、Amazon MQ は RabbitMQ 4.2 ブローカー向けに設定可能なリソース制限を導入しており、アプリケーションの要件に基づいて変更できます。
何が嬉しいのか #
AMQP 1.0 プロトコルのサポートにより、メッセージ処理の柔軟性が向上し、コンシューマはメッセージアノテーションをより細かく制御できるようになります。また、きめ細かなフロー制御により、クライアントアプリケーションはメッセージの受信量を動的に調整できるため、リソース利用の最適化とアプリケーションの応答性向上が期待できます。
Khepri メタデータストア、ローカルシャベル、Quorum queues のメッセージ優先度、そしてスループットとメモリ管理の改善により、RabbitMQ ブローカーの信頼性、パフォーマンス、および管理性が向上します。
設定可能なリソース制限により、アプリケーションの特定のニーズに合わせてブローカーを最適化し、コスト効率とパフォーマンスのバランスを取ることが可能になります。
Amazon MQ がパッチバージョンアップグレードを自動的に管理するため、ユーザーはメジャー.マイナーバージョンのみを指定すればよく、運用上の負担が軽減されます。
これまでとどう変わるのか #
- これまで: RabbitMQ 4.2で導入されたAMQP 1.0プロトコルのネイティブサポート、Khepriメタデータストア、ローカルシャベル、Quorum queuesのメッセージ優先度、設定可能なリソース制限などの機能は利用できませんでした。RabbitMQ 4.0以降、クラシックキューのミラーリングはサポートされていませんでした。
- これから: Amazon MQでRabbitMQ 4.2が利用可能になり、AMQP 1.0プロトコル、Khepriメタデータストア、ローカルシャベル、Quorum queuesのメッセージ優先度、設定可能なリソース制限などの新機能が利用できます。Quorum queuesはレプリケートされ永続的なキュータイプとしてサポートされ、コンシューマ優先度に加えてメッセージ優先度も提供されます。非レプリケートのクラシックキューは引き続きサポートされます。
具体的なユースケース #
- AMQP 1.0 の「modified outcome」機能を使用して、メッセージを再キューイングまたはデッドレタリングする前に、コンシューマがメッセージアノテーションを動的に変更する。
- AMQP 1.0 の「granular flow control」機能を利用して、クライアントアプリケーションが特定のキューから受信するメッセージ数を動的に調整し、バックプレッシャーを管理する。
- Quorum queues のメッセージ優先度を活用して、重要なメッセージが優先的に処理されるようにキュー内のメッセージ順序を制御する。
- アプリケーションの特定の要件に合わせて、RabbitMQ 4.2 ブローカーのリソース制限を設定し、パフォーマンスとコストを最適化する。
- AWS Management Console、AWS CLI、または AWS SDK を使用して、m7g インスタンスタイプで RabbitMQ 4.2 ブローカーを新規作成する。
Amazon MSK Serverless が南米 (サンパウロ) リージョンに提供地域を拡大 #
投稿日: 2025年11月20日
何ができるようになったのか #
Amazon MSK Serverless が南米 (サンパウロ) AWS リージョンで利用可能になりました。これにより、Apache Kafka アプリケーションをこのリージョンで Amazon MSK Serverless に接続できるようになります。
何が嬉しいのか #
Amazon MSK Serverless は、Apache Kafka を実行する際にクラスター容量の管理やスケーリングが不要になります。コンピューティングリソースとストレージリソースを自動的にプロビジョニングおよびスケーリングするため、オンデマンドで Apache Kafka を利用できます。
これまでとどう変わるのか #
- これまで: 南米 (サンパウロ) リージョンでは Amazon MSK Serverless が利用できませんでした。
- これから: 南米 (サンパウロ) リージョンで Amazon MSK Serverless を利用できるようになり、Apache Kafka アプリケーションを接続できます。
具体的なユースケース #
- 南米 (サンパウロ) リージョンで Apache Kafka を利用するアプリケーションを、サーバーレスで運用できるようになりました。これにより、インフラ管理の負担を軽減し、必要な時に必要なだけリソースを利用できます。
Amazon OpenSearch Serverless が AWS マネジメントコンソールからのバックアップと復元をサポート #
投稿日: 2025年11月19日
何ができるようになったのか #
Amazon OpenSearch Serverless が、AWS マネジメントコンソールを介したバックアップと復元をサポートするようになりました。OpenSearch Serverless は、アカウント内のすべてのコレクションとインデックスを1時間ごとに自動的にバックアップし、バックアップを14日間保持します。バックアップはAPIまたはAWSコンソールのいずれかを使用して復元できます。この機能はデフォルトで有効になっており、設定は不要です。
何が嬉しいのか #
この新機能により、OpenSearch Serverless のデータ保護が強化され、運用が簡素化されます。自動バックアップと簡単な復元プロセスにより、データの安全性と可用性が向上し、手動での介入なしに重要なデータを保護できます。設定不要で利用開始できるため、すぐにメリットを享受できます。
これまでとどう変わるのか #
- これまで: OpenSearch Serverless のバックアップと復元は、AWS マネジメントコンソールから直接、または設定なしで利用できる機能としては提供されていませんでした。
- これから: AWS マネジメントコンソールから直接、OpenSearch Serverless のコレクションとインデックスのバックアップと復元が可能になります。バックアップは自動的に行われ、14日間保持されます。
具体的なユースケース #
- 誤って削除または破損した OpenSearch Serverless のコレクションやインデックスを、過去の時点に復元する。
- 災害発生時やデータ損失の際に、迅速にデータを復旧し、ビジネスの継続性を確保する。
- 特定の時点のデータを取得して分析やテストに利用する。
Amazon OpenSearch Serverless が管理コンソール向けに AWS PrivateLink を追加 #
投稿日: 2025年11月20日
何ができるようになったのか #
Amazon OpenSearch Serverless が、管理コンソールへのセキュアでプライベートな接続のために AWS PrivateLink をサポートするようになりました。これにより、Virtual Private Cloud (VPC) と Amazon OpenSearch Serverless の間にプライベート接続を確立し、パブリックインターネットを使用せずに OpenSearch Serverless のリソースを作成、管理、設定できます。
何が嬉しいのか #
この機能強化により、パブリック IP アドレスを使用したり、ファイアウォールルールのみに依存したりすることなく、OpenSearch Serverless にアクセスできるようになります。PrivateLink を介して OpenSearch Serverless の管理操作とデータ操作に安全にアクセスできます。
これまでとどう変わるのか #
- これまで: OpenSearch Serverless の管理コンソールへのアクセスには、パブリックインターネット経由でのアクセスや、複雑なファイアウォールルールの設定が必要でした。
- これから: AWS PrivateLink を使用して、VPC 内からパブリックインターネットを経由せずに、管理コンソールへのセキュアでプライベートな接続が可能になります。
具体的なユースケース #
- VPC 内から OpenSearch Serverless のリソースを安全に作成、管理、設定する。
- OpenSearch Serverless の管理操作およびデータ操作にプライベートにアクセスする。
Amazon OpenSearch Service OR2 および OM2 インスタンスが追加リージョンで利用可能に #
投稿日: 2025年11月21日
何ができるようになったのか #
Amazon OpenSearch Service の OR2 および OM2 OpenSearch Optimized インスタンスファミリーが、追加のリージョンで利用可能になりました。OR2 インスタンスは、以前の OR1 インスタンスと比較して最大 26% 高いインデックススループットを、R7g インスタンスと比較して 70% 高いインデックススループットを提供します。OM2 インスタンスは、内部ベンチマークにおいて、OR1 インスタンスと比較して最大 15% 高いインデックススループットを、M7g インスタンスと比較して 66% 高いインデックススループットを提供します。
何が嬉しいのか #
OpenSearch Optimized インスタンスは、Amazon S3 のようなクラス最高のクラウドテクノロジーを活用し、高い耐久性と、インデックススループットの向上による優れた価格性能を提供するため、インデックス処理の負荷が高いワークロードに適しています。インスタンス、ローカルインスタンスストレージ、および S3 ベースのマネージドストレージに対して、従量課金制とリザーブドインスタンスの両方でシンプルな時間単位料金が提供されます。
これまでとどう変わるのか #
- これまで: OR2 および OM2 インスタンスは、より少ないリージョンでのみ利用可能でした。
- これから: OR2 インスタンスファミリーは、米国西部 (北カリフォルニア)、カナダ (中部)、アジアパシフィック (香港、ジャカルタ、マレーシア、メルボルン、大阪、ソウル、シンガポール)、欧州 (ロンドン)、南米 (サンパウロ) を含む 12 の追加リージョンで利用可能になりました。OM2 インスタンスファミリーは、米国西部 (北カリフォルニア)、カナダ (中部)、アジアパシフィック (香港、ハイデラバード、ムンバイ、大阪、ソウル、シンガポール、シドニー、東京)、欧州 (パリ、スペイン)、中東 (バーレーン)、南米 (サンパウロ) を含む 14 の追加リージョンで利用可能になりました。
具体的なユースケース #
- インデックススループットと価格性能が向上したため、インデックス処理の負荷が高いワークロードに最適です。
Amazon Quick Sight がダッシュボードのテーマカスタマイズを拡張 #
投稿日: 2025年11月20日
何ができるようになったのか #
Amazon Quick Sight は、分析ダッシュボード全体で一貫したブランドアイデンティティを維持できる包括的なテーマ機能に対応しました。作成者は、インタラクティブなシートの背景をグラデーションカラーと角度でカスタマイズしたり、設定可能な境界線と不透明度で洗練されたカードスタイルを実装したり、テーマレベルでビジュアルのタイトルとサブタイトルのタイポグラフィを制御したりできます。
何が嬉しいのか #
これらの機能強化により、企業は企業ビジュアルアイデンティティの維持や、シームレスな組み込み分析エクスペリエンスの作成といった重要なニーズに対応できます。テーマレベルのコントロールにより、組織は部門全体で視覚的な一貫性を確保しつつ、組み込みダッシュボードをホストアプリケーションのスタイルに合わせることができます。これにより、ダッシュボードがホストアプリケーション内でネイティブに見えるようになり、全体的なプロフェッショナルな外観とユーザーエクスペリエンスが向上します。
これまでとどう変わるのか #
- これまで: ダッシュボードのテーマカスタマイズにおいて、グラデーション背景、カードのスタイル設定、タイトルやサブタイトルのタイポグラフィのテーマレベルでの詳細な制御が限定的でした。
- これから: グラデーションカラーと角度によるインタラクティブなシート背景のカスタマイズ、設定可能な境界線と不透明度による洗練されたカードスタイリング、テーマレベルでのビジュアルタイトルとサブタイトルのタイポグラフィ制御が可能になりました。
具体的なユースケース #
- 企業全体のビジュアルアイデンティティを維持する。
- シームレスな組み込み分析エクスペリエンスを作成する。
- 部門間で視覚的な一貫性を確保する。
- 組み込みダッシュボードをホストアプリケーション内でネイティブに見せる。
Amazon RDS for Oracle、アジアパシフィック (台北) リージョンでOracle Database Standard Edition 2 (SE2) ライセンス込みインスタンスの提供を開始 #
投稿日: 2025年11月21日
何ができるようになったのか #
Amazon Relational Database Service (Amazon RDS) for Oracleが、アジアパシフィック (台北) リージョンでOracle Database Standard Edition 2 (SE2) ライセンス込みのR7iおよびM7iインスタンスの提供を開始しました。
何が嬉しいのか #
Amazon RDS for Oracle SE2 ライセンス込みインスタンスを利用することで、Oracle Databaseのライセンスを別途購入する必要がなくなります。AWS Management Console、AWS CLI、またはAWS SDKsを通じてAmazon RDS for Oracleインスタンスを起動するだけで、ライセンス料やサポート料が別途発生することはありません。AWSブログ「Rethink Oracle Standard Edition Two on Amazon RDS for Oracle」を参照して、Amazon RDS Oracle SE2 ライセンス込みインスタンスを使用することで、Oracleデータベースのコストを削減し、運用を簡素化する方法をご確認ください。
これまでとどう変わるのか #
- これまで: ユーザーはOracle Databaseのライセンスを別途購入する必要がありました。
- これから: ライセンスが込みで提供されるため、調達が簡素化され、別途料金が発生しません。
具体的なユースケース #
- Oracleデータベースのコストを削減し、運用を簡素化したい場合。
Amazon RDS が SQL Server Web Edition の Multi-AZ をサポート #
投稿日: 2025年11月20日
何ができるようになったのか #
Amazon Relational Database Service (Amazon RDS) for SQL Server が、SQL Server Web Edition の Multi-AZ デプロイをサポートするようになりました。お客様は、Amazon RDS for SQL Server Web Edition インスタンスを Multi-AZ デプロイオプションで設定するだけで、Amazon RDS が異なるアベイラビリティーゾーン (AZ) にスタンバイレプリカを自動的にプロビジョニングおよび維持し、2つのAZ間でデータを同期的にレプリケートします。
何が嬉しいのか #
ウェブホスターやウェブ付加価値プロバイダー (VAP) が使用するウェブアプリケーションは、ハードウェアやデータベースの障害から復旧するために高可用性と自動フェイルオーバーを必要とします。この新機能により、お客様は高可用性のために SQL Server Standard Edition や Enterprise Edition のような高価なオプションを使用する必要がなくなります。プライマリデータベースが利用できなくなった場合、Amazon RDS は自動的にスタンバイレプリカにフェイルオーバーするため、お客様は管理者の介入なしに迅速にデータベース操作を再開できます。
これまでとどう変わるのか #
- これまで: 高可用性が必要な場合、SQL Server Web Edition のアプリケーションでは、SQL Server Standard Edition や Enterprise Edition のような高価なオプションを使用する必要がありました。
- これから: Amazon RDS Multi-AZ デプロイオプションを SQL Server Web Edition で利用できるようになり、より費用対効果の高い高可用性ソリューションが提供されます。
具体的なユースケース #
- ウェブホスターやウェブ付加価値プロバイダー (VAP) が、パブリックおよびインターネットからアクセス可能なウェブページ、ウェブサイト、ウェブアプリケーション、ウェブサービスをサポートする際に、高可用性と自動フェイルオーバーが必要な場合。
詳細は原典をご確認ください。
Reply by Email