Weekly AWS アップデート情報 - 2025/11/26～来週の re:Invent 開催を目前に多数のアップデート～

分析

Amazon Redshift が、大文字と小文字を区別しない照合順序を持つデータベースで SUPER データ型をサポート
Amazon Redshift は、大文字と小文字を区別しない照合順序を持つデータベースで SUPER データ型をサポートするようになり、半構造化データやネストされたデータの分析が可能になりました。
Amazon Redshift で PartiQL と SUPER データ型を使用すると、構造化 SQL データ (string、numeric、timestamp など) と半構造化 SUPER データ (JSON など) を柔軟かつ簡単に組み合わせて、高度な分析を実行できます。この機能強化により、構造化データと半構造化データの両方の処理ニーズに SUPER データ型を活用できます。
COLLATE 関数を使用することで、SUPER 列の大文字と小文字の区別の設定を明示的に指定できるようになり、大文字と小文字のパターンが異なるデータを扱う際の柔軟性が向上します。これは、大文字と小文字の一貫性が保証されていない JSON ドキュメント、API、またはアプリケーションデータを扱う場合に特に有用です。ユーザー定義の識別子を処理する場合や、複数のソースからデータを統合する場合でも、追加の正規化オーバーヘッドなしで、大文字と小文字を区別するデータと区別しないデータの両方にまたがる複雑なクエリを実行できます。

Amazon Redshift が Apache Iceberg テーブル向けの Just-In-Time (JIT) ANALYZE をサポート
Amazon Redshift で、Apache Iceberg テーブル向けの Just-In-Time (JIT) ANALYZE 機能が一般提供されました。これにより、Redshift データレイク内の Apache Iceberg テーブルに対して、高性能な読み取りおよび書き込み分析クエリを実行できます。
Apache Iceberg オープンテーブルフォーマットは、データレイクに保存され、急速に拡大・変化するテーブルのデータ処理を簡素化するために、多くのお客さまに利用されています。従来のデータウェアハウスとは異なり、データレイクでは基盤となるデータに関する包括的なテーブルレベルおよび列レベルの統計情報が不足していることが多く、クエリエンジンが最適なクエリ実行計画を選択することは困難です。最適ではないクエリ実行計画は、パフォーマンスの低下や予測不能性につながる可能性があります。
JIT ANALYZE は、クエリ実行中に Iceberg テーブルの統計情報を自動的に収集・利用する Amazon Redshift の新機能です。これにより、手動での統計情報収集が不要になり、クエリエンジンが最適なクエリ実行計画を生成するために必要な情報を提供します。このシステムは、インテリジェントなヒューリスティックを用いて統計情報の恩恵を受けるクエリを特定し、軽量なスケッチデータ構造を維持しながら、高品質なテーブルレベルおよび列レベルの統計情報を構築します。
JIT ANALYZE は、事前に計算された統計情報を持つクエリと同等のパフォーマンスを特別な設定なしで実現し、ほかの多くのパフォーマンス最適化の基盤となります。
Apache Iceberg テーブル向けの Amazon Redshift JIT ANALYZE 機能は、Amazon Redshift が利用可能な全ての AWS リージョンで利用できます。この新しいデータレイククエリ最適化を利用するために、ユーザーが変更を加えたり設定を有効にしたりする必要はありません。

Amazon Redshift が Apache Iceberg テーブルへの書き込みをサポート
Amazon Redshift が Apache Iceberg テーブルへの書き込み機能の一般提供を開始しました。これにより、ユーザーは Amazon Redshift 内で、追記専用ワークロードの Apache Iceberg テーブルに対して分析の読み取りおよび書き込みクエリを実行できます。
今回のアップデートにより、Amazon Redshift は SQL DDL (データ定義言語) 操作である Apache Iceberg テーブルの CREATE、テーブル定義 SQL の SHOW、テーブルの DROP、および INSERT などの DML (データ操作言語) 操作をサポートします。
AWS Glue Data Catalog 内の Apache Iceberg テーブルからの読み取りに Amazon Redshift を引き続き使用でき、それらのテーブルへの書き込み操作を実行できます。その間、ほかのユーザーやアプリケーションはテーブルに対して安全に DML 操作を実行可能です。
Amazon Redshift での Apache Iceberg サポートは、Amazon Redshift が利用可能な全ての AWS リージョンで提供されます。

Amazon Redshift Serverless が、大阪など 13 の追加リージョンで最小キャパシティ 4 RPU を提供開始
Amazon Redshift Serverless が 4 Redshift Processing Units (RPUs) という、より低いデータウェアハウスのベースキャパシティ構成が利用開始できるようになりました。
Amazon Redshift Serverless は、データウェアハウスのキャパシティを RPU で測定します。1 RPU で 16 GB のメモリが提供され、料金は実行したワークロードの時間に対してのみ、RPU 時間を基準に秒単位で課金されます。これまで、Amazon Redshift Serverless を実行するために必要な最小ベースキャパシティは 8 RPU でした。今回のアップデートにより、Amazon Redshift Serverless は 1 時間当たり 1.50 ドルという低価格から利用を開始でき、データウェアハウスがアクティブなときに消費するコンピューティングキャパシティに対してのみ料金が発生します。
Amazon Redshift Serverless を使用すると、お客さまはデータウェアハウスクラスターを管理することなく、分析を実行およびスケーリングできます。この新しい低キャパシティ構成は、特にワークロードが必要とするコンピューティングリソースとメモリリソースが最小限の場合に、本番環境と開発環境の両方に適しています。このエントリーレベルの構成は、最大 32 TB の Redshift マネージドストレージを持つデータウェアハウスをサポートし、テーブル当たり最大 100 列、64 GB のメモリを提供します。
この機能は、AWS アジアパシフィック (タイ)、アジアパシフィック (ジャカルタ)、アフリカ (ケープタウン)、アジアパシフィック (ハイデラバード)、アジアパシフィック (大阪)、アジアパシフィック (マレーシア)、アジアパシフィック (台北)、メキシコ (中央)、イスラエル (テルアビブ)、ヨーロッパ (スペイン)、ヨーロッパ (ミラノ)、ヨーロッパ (フランクフルト)、中東 (UAE) で利用可能です。

Amazon Quick Sight のダッシュボードカスタマイズ機能がテーブルとピボットテーブルに対応
Amazon Quick Sight は、ダッシュボードのテーブルとピボットテーブルのカスタマイズ機能を拡張しました。これにより、閲覧者はダッシュボード作成者による更新を必要とせずに、列のソート、並べ替え、表示/非表示、固定によってデータビューをパーソナライズできます。この機能は、さまざまな分析ニーズに合わせてビューを調整し、部門間で共同作業を行う必要があるチームにとって特に価値があります。例えば、営業マネージャーは収益でソートしてトップパフォーマーを特定でき、財務チームは勘定科目列を固定して大規模なデータセットのコンテキストを維持できます。これらの新しいカスタマイズ機能は、サポートされている全ての Amazon Quick Sight リージョンの Amazon Quick Sight Enterprise Edition で利用可能になりました。

Amazon Quick Sight がダッシュボードのテーマカスタマイズを拡張
Amazon Quick Sight は、分析ダッシュボード全体で一貫したブランドアイデンティティーを維持するための、包括的なテーマ設定機能をサポートするようになりました。作成者は、インタラクティブなシートの背景のグラデーション、境界線や不透明度を設定できる高度なカードスタイル、テーマレベルでのタイトルやサブタイトルのタイポグラフィなどを制御できます。
この機能強化は、企業のビジュアルアイデンティティーの維持や、シームレスな埋め込み分析エクスペリエンスの作成といったニーズに対応します。テーマレベルの制御により、組織は部門間で視覚的な一貫性を確保しつつ、埋め込みダッシュボードをホストアプリケーションのスタイルに合わせることができます。このテーマ設定機能は、ダッシュボードがホストアプリケーション内でネーティブのように表示され、プロフェッショナルな外観とユーザーエクスペリエンスが向上するため、特に埋め込み分析シナリオで有用です。
拡張されたテーマ機能は、サポートされている全ての Amazon Quick Sight リージョンで利用可能です。

Amazon OpenSearch Service の OR2 と OM2 が、大阪、東京を含む追加リージョンで利用可能に
Amazon OpenSearch Service は、OpenSearch Optimized インスタンスファミリーである OR2 と OM2 の提供リージョンを拡大しました。
OR2 インスタンスは、従来の OR1 インスタンスと比較して最大 26%、R7g インスタンスと比較して最大 70% 高いインデックススループットを提供します。OM2 インスタンスは、社内ベンチマークにおいて、OR1 インスタンスと比較して最大 15%、M7g インスタンスと比較して最大 66% 高いインデックススループットを提供します。
OpenSearch Optimized インスタンスは、Amazon S3 のようなクラウド技術を活用し、高い耐久性と、インデックス作成負荷の高いワークロードに対して改善された価格性能を提供します。各インスタンスは、コンピューティング、キャッシュ用のローカルインスタンスストレージ、および Amazon S3 ベースのリモートマネージドストレージでプロビジョニングされます。
OR2 と OM2 は、pay-as-you-go 料金とリザーブドインスタンスを提供します。OR2 インスタンスには medium から 16xlarge まで、OM2 インスタンスには large から 16xlarge までのサイズがあります。
OR2 インスタンスファミリーは、米国西部 (北カリフォルニア)、カナダ (中部)、アジアパシフィック (香港、ジャカルタ、マレーシア、メルボルン、大阪、ソウル、シンガポール)、欧州 (ロンドン)、南米 (サンパウロ) を含む世界 11 の追加リージョンで利用可能です。
OM2 インスタンスファミリーは、米国西部 (北カリフォルニア)、カナダ (中部)、アジアパシフィック (香港、ハイデラバード、ムンバイ、大阪、ソウル、シンガポール、シドニー、東京)、欧州 (パリ、スペイン)、中東 (バーレーン)、南米 (サンパウロ) を含む世界 14 の追加リージョンで利用可能です。

Amazon OpenSearch Service が、運用の可視性を向上させる Cluster Insights を発表
Amazon OpenSearch Service に、モニターリングソリューションである Cluster Insights が追加されました。これは単一のダッシュボードでクラスターの包括的な運用可視性を提供し、ログやメトリクスを分析してリスクを特定する複雑さを解消します。
このソリューションは、ノード、インデックス、シャード全体の重要な運用データを自動的に統合し、複雑なトラブルシュートを合理化します。検索クエリの遅延などのパフォーマンス問題を調査する際には、関連するパフォーマンスメトリクス、影響を受けるクラスターリソース、上位N件のクエリ分析、具体的な修正手順を1つの包括的なビューで表示します。OpenSearch UI の回復力のあるアーキテクチャーにより、クラスターが利用不能な場合でもモニターリング機能は維持されます。また、アカウントレベルのクラスターサマリーにより、複数のデプロイメントを効率的に管理できます。
Cluster Insights は、OpenSearch UI が利用可能な全てのリージョンで、OpenSearch バージョン 2.17 以降に追加料金なしで利用できます。

Amazon OpenSearch Serverless がマネジメントコンソール向けに AWS PrivateLink をサポート
Amazon OpenSearch Serverless が、マネジメントコンソールへの安全でプライベートな接続のために AWS PrivateLink をサポートするようになりました。AWS PrivateLink を使用すると、VPC と Amazon OpenSearch Serverless の間にプライベート接続を確立し、パブリックインターネットを使用せずに OpenSearch Serverless リソースを作成、管理、設定できます。
この機能強化により、プライベートネットワーク接続が可能になり、OpenSearch Serverless へのアクセスにパブリックIPアドレスを使用したり、ファイアウォールルールのみに依存したりする必要がなくなります。OpenSearch Serverless の管理操作とデータ操作は PrivateLink を通じて安全にアクセスできますが、コレクションに対するデータの取り込みとクエリ操作には、引き続き OpenSearch Serverless が提供するプライベート接続用の VPC エンドポイント設定が必要です。
PrivateLink 接続は、Amazon OpenSearch Serverless が利用可能な全ての AWS リージョンで使用できます。AWS PrivateLink で VPC エンドポイントを作成すると追加料金が発生します。利用を開始するには、AWS マネジメントコンソール、AWS Command Line Interface (CLI)、AWS Software Development Kits (SDKs)、AWS Cloud Development Kit (CDK)、または AWS CloudFormation を使用して、Amazon OpenSearch Serverless 用の AWS PrivateLink インターフェースエンドポイントを作成します。

Amazon OpenSearch Serverless がデータプレーン API の監査ログを追加
Amazon OpenSearch Serverless は、AWS CloudTrail を介したデータプレーンリクエストの詳細な監査ログをサポートするようになりました。この機能により、お客さまはコレクションに対するユーザーアクションを記録でき、コンプライアンス規制への準拠、セキュリティ体制の向上、セキュリティ調査のための証拠提供に役立ちます。認証試行、インデックスの変更、検索クエリなどのユーザーアクティビティを追跡できます。
お客さまは CloudTrail を使用して、読み取り専用および書き込み専用オプションで OpenSearch Serverless コレクションのフィルターを設定したり、高度なイベントセレクターを使用してログに記録されるデータイベントをよりきめ細かく制御したりできます。全ての OpenSearch Serverless データイベントは Amazon S3 バケットに配信され、オプションで Amazon CloudWatch Events にも配信されるため、包括的な監査証跡が作成されます。API コールがいつ、誰によって行われたかについての可視性が向上したことで、セキュリティチームと運用チームはデータアクセスを監視し、リアルタイムでイベントに対応できます。
CloudTrail で設定すると、監査ログは追加のお客さまの操作を必要とせずに継続的に CloudTrail にストリーミングされ、そこでさらに分析できます。

Amazon OpenSearch Serverless が AWS マネジメントコンソールを介したバックアップと復元をサポート
Amazon OpenSearch Serverless は、AWS マネジメントコンソールを介したバックアップと復元をサポートするようになりました。OpenSearch Serverless は、アカウント内の全てのコレクションとインデックスを1時間ごとに自動的にバックアップし、バックアップを14日間保持します。バックアップは API または AWS Console を使用して復元できます。この機能はデフォルトで有効になっており、設定は不要です。

Amazon MSK コンソールが、新しいパブリック API を使用した Kafka トピックの表示をサポート
Amazon Managed Streaming for Apache Kafka (Amazon MSK) は、Amazon MSK コンソールから直接トピックを表示できるようになりました。これにより、Kafka 管理クライアントをセットアップすることなく、全ての Kafka トピックを簡単に検査できます。クラスター内のトピックの閲覧と検索、レプリケーション設定とパーティション数の迅速な確認、個々のトピックへのドリルダウンによる詳細な設定、パーティションレベルの情報、メトリクスの調査が可能です。
これらのコンソール機能は、3つの新しい MSK API である ListTopics、DescribeTopic、DescribeTopicPartitions によって実現されており、これらはプログラムによるアクセスに直接使用することもできます。ListTopics API はクラスター内の全てのトピックのリストを返し、DescribeTopic と DescribeTopicPartitions API はトピックの詳細な設定とパーティション情報を提供します。3つの API は全て、AWS CLI と AWS SDK を通じて利用可能です。
この MSK トピック表示機能は、Amazon MSK が提供されている全ての AWS リージョンで、Kafka バージョン 3.6 以上を使用する全ての Amazon MSK Provisioned クラスターで利用可能です。これらの機能の使用を開始するには、適切な IAM 権限を設定する必要があります。

Amazon MSK コンソールが AWS Lambda の Kafka イベントソースマッピング統合を発表
Amazon MSK Console で Lambda の Kafka イベントソースマッピング (ESM) 統合が利用可能になり、MSK トピックを Lambda 関数に接続するプロセスが効率化されました。この機能により、MSK Console でトピックとターゲット関数を指定するだけで ESM 設定が自動的に処理され、コンソールを切り替えることなく MSK トピックから Lambda 関数をトリガーできます。
従来、MSK をイベントソースとして設定するには、MSK と Lambda のコンソール間を移動してクラスター詳細や認証方法などを設定する必要がありました。新しい統合エクスペリエンスでは、Lambda の ESM 設定が MSK Console に直接組み込まれ、必須フィールドはターゲット関数とトピック名のみです。
この統合機能は、認証とイベントポーリング設定に最適化されたデフォルト値で ESM を作成し、MSK クラスターアクセスに必要な Lambda 実行ロールの権限を自動的に生成することも可能です。レイテンシーとスループットを最適化し、ネットワーク設定を不要にするため、この統合では ESM の推奨デフォルトとして Provisioned Mode を使用します。これらの改善により MSK と Lambda の統合が効率化され、設定ミスが減るため、MSK と Lambda を使用したアプリケーションを迅速に開始できます。
この機能は、Amazon MSK と AWS Lambda の両方が利用可能な全ての AWS 商用リージョンで一般提供されています。ただし、アジアパシフィック (タイ)、アジアパシフィック (マレーシア)、イスラエル (テルアビブ)、アジアパシフィック (台北)、カナダ西部 (カルガリー) を除きます。標準の Lambda と MSK の料金が適用されます。

Amazon Kinesis Data Streams が最大50の拡張ファンアウトコンシューマーをサポート
Amazon Kinesis Data Streams は、On-demand Advantage ストリームで 50 の拡張ファンアウトコンシューマーをサポートするようになりました。ファンアウトの上限が引き上げられたことで、お客さまはより多くの独立した、低レイテンシー、高スループットのコンシューマーを同じストリームに接続できます。これにより、追加のストリームを作成したり、スループットの競合を引き起こしたりすることなく、並列分析、ML パイプライン、コンプライアンスワークフロー、マルチチームアーキテクチャーを実現できます。
On-demand Advantage はアカウントレベルの設定で、AWS リージョン内の全てのオンデマンドストリームに対して、On-demand Standard と比較して 60% 低い料金体系を提供します。特に高ファンアウトのワークロードでコスト効率が高くなります。
拡張ファンアウトは、コンシューマーがシャード当たり最大 2 MB/秒の専用スループットでレコードを受信できる機能で、ほかのコンシューマーとの競合を回避します。
On-demand Advantage が有効なアカウントでは、既存の Kinesis API RegisterStreamConsumer を使用して、新しい上限である 50 までコンシューマーを登録できます。

Amazon EMR Serverless が Apache Spark 4.0.1 をサポート（プレビュー）
Amazon EMR Serverless が Apache Spark 4.0.1 をサポートするようになりました (プレビュー) 。Spark 4.0.1 を使用すると、ANSI SQL と VARIANT データ型でデータパイプラインをより簡単に構築および保守し、Apache Iceberg v3 テーブル形式でコンプライアンスとガバナンスのフレームワークを強化し、強化されたストリーミング機能で新しいリアルタイムアプリケーションをより迅速にデプロイできます。これにより、チームはデータの正確性と一貫性を確保しながら、技術的負債を削減し、より迅速にイテレーションを行うことができます。
Spark 4.0.1 では、標準の ANSI SQL を使用してデータパイプラインを構築できるため、Python や Scala などのプログラミング言語を知らない、より多くのユーザーが利用できるようになります。また、VARIANT データ型を介して JSON と半構造化データをネーティブにサポートし、多様なデータ形式を処理するための柔軟性を提供します。
Apache Iceberg v3 テーブル形式を通じてコンプライアンスとガバナンスを強化できます。これにより、トランザクションが保証され、データの経時的な変化が追跡されるため、規制要件に必要な監査証跡が作成されます。複雑なステートフル操作の管理やストリーミングジョブの監視をより簡単に行える、改善されたストリーミング制御により、リアルタイムアプリケーションをより迅速にデプロイできます。この機能により、不正検知やリアルタイムパーソナライズなどのユースケースをサポートできます。
Apache Spark 4.0.1 は、China および AWS GovCloud (US) リージョンを除く、EMR Serverless が利用可能な全てのリージョンでプレビュー版として利用できます。

Amazon EMR 7.12 が Apache Iceberg v3 テーブル形式をサポート
Amazon EMR 7.12 が利用可能になりました。このリリースは、Apache Iceberg 1.10 を使用した新しい Apache Iceberg v3 テーブル形式を特長としています。これにより、データ削除時のコスト削減、行レベルの変更追跡の改善によるガバナンスとコンプライアンスの強化、よりきめ細かいデータアクセス制御によるデータセキュリティの向上が可能になります。
Iceberg v3 では、ファイル全体を書き換えることなく削除された行にマークを付けるため、コスト効率よくデータを削除でき、データパイプラインの高速化とストレージコストの削減を実現します。全ての行の作成および変更履歴を自動的に追跡することで、ガバナンスとコンプライアンス機能が向上し、規制要件や変更データキャプチャーに必要な監査証跡が作成されます。テーブルレベルの暗号化によりデータセキュリティを強化でき、最も機密性の高いデータに関するプライバシー規制への準拠に役立ちます。
このリリースに含まれる Apache Spark 3.5.6 を使用して、これらの Iceberg 1.10 の機能を活用し、Amazon S3 上に堅ろうなデータレイクハウスアーキテクチャーを構築できます。また、AWS Lake Formation を使用した Iceberg テーブル全体のデータガバナンス操作もサポートされています。さらに、このリリースには Apache Trino 476 も含まれています。
Amazon EMR 7.12 は、Amazon EMR をサポートする全ての AWS リージョンで利用可能です。

Amazon Athena が Capacity Reservations 向けの自動スケーリングソリューションを開始
Amazon Athena は、ワークロードの需要に基づいてリザーブドキャパシティを動的に調整する、Capacity Reservations 向けの自動スケーリングソリューションを提供するようになりました。
このソリューションは AWS Step Functions を使用して使用率メトリクスを監視し、設定したしきい値と制限に従ってデータ処理ユニット (DPU) をスケールアップまたはスケールダウンします。これにより、クエリパフォーマンスを維持しながらコストを最適化し、手動でのキャパシティ調整が不要になります。
ワークロードのニーズに合わせて、使用率のしきい値、測定頻度、キャパシティの制限を設定することで、スケーリング動作をカスタマイズできます。このソリューションは、Amazon CloudWatch のキャパシティ使用率メトリクスに基づき、Step Functions を使用してアクティブな Capacity Reservation に DPU を追加または削除します。キャパシティは、使用率が高いしきい値を超えると自動的にスケールアップし、低いしきい値を下回るとスケールダウンします。これらは全て、定義した制限に従って行われます。
特定の要件に合わせて Amazon CloudFormation テンプレートを変更することで、ソリューションをさらにカスタマイズできます。
Athena Capacity Reservations 向けの自動スケーリングソリューションは、Capacity Reservations がサポートされている AWS リージョンで利用可能です。

Amazon Athena が Capacity Reservations のコストとパフォーマンス制御機能を追加
Amazon Athena で、Capacity Reservations 上で実行されるクエリの Data Processing Unit (DPU) 使用量を制御できるようになりました。ワークグループまたはクエリレベルで DPU 設定を構成し、コスト効率、同時実行性、クエリレベルのパフォーマンス要件のバランスを取ることができます。
Capacity Reservations は、Athena クエリ専用のサーバーレス処理能力を DPU 単位で提供し、クエリはその複雑さに応じて DPU を消費します。今回のアップデートにより、各クエリに明示的な DPU 値を設定できるようになりました。これにより、小規模なクエリは必要なリソースのみを使用し、重要なクエリは高速実行のために十分なリソースを確保できます。
また、Athena コンソールと API はクエリごとの DPU 使用量を返すようになり、DPU の使用状況を把握して必要なキャパシティを判断するのに役立ちます。これらのアップデートにより、クエリごとのキャパシティ使用量と同時実行性を制御し、過剰なプロビジョニングをなくしてコストを削減し、ビジネスクリティカルなワークロードに一貫したパフォーマンスを提供できます。
コストとパフォーマンスの制御機能は、Capacity Reservations がサポートされている AWS リージョンで利用可能です。

Amazon Athena for Apache Spark が Amazon SageMaker ノートブックで利用可能に
Amazon SageMaker が Amazon Athena for Apache Spark をサポートし、新しいノートブック体験と高速なサーバーレス Spark 体験を統合ワークスペースで利用できるようになりました。データエンジニア、アナリスト、データサイエンティストは、インフラ管理不要かつ秒単位の課金で、データのクエリ、Python コードの実行、ジョブの開発、モデルのトレーニング、データの可視化、AI の操作を 1 か所で簡単に行えます。
Athena for Apache Spark は数秒でスケールし、インタラクティブなクエリからペタバイト規模のジョブまで、あらゆるワークロードをサポートします。AWS 全体で利用可能な高性能 Spark エンジンと同じ Spark 3.5.6 で動作し、Apache Iceberg や Delta Lake などのオープンテーブルフォーマットに最適化されています。また、新しいデバッグ機能、Spark UI でのリアルタイムモニターリング、Spark Connect を介した安全なインタラクティブクラスター通信を提供します。データを操作する際には、AWS Lake Formation で定義されたテーブルレベルのアクセスコントロールが適用されます。
Athena for Apache Spark は、Amazon SageMaker ノートブックで、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド)、欧州 (フランクフルト)、アジアパシフィック (ムンバイ)、アジアパシフィック (東京)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー) で利用可能です。

AWS Glue のゼロETL統合が AWS CloudFormation と AWS CDK をサポート
AWS Glue のゼロETL統合は AWS CloudFormation と AWS Cloud Development Kit (AWS CDK) をサポートするようになり、infrastructure as code を使用して ゼロETL統合を作成できるようになりました。ゼロETL統合は AWS によって完全にマネージドされており、ETL データパイプラインを構築する必要性を最小限に抑えます。
AWS Glue の ゼロETLを使用すると、AWS DynamoDB や、Salesforce、ServiceNow、SAP、Zendesk などのエンタープライズ SaaS ソースから、Amazon Redshift、Amazon S3、Amazon S3 Tables にデータを取り込むことができます。
CloudFormation と CDK がこれらの Glue の ゼロETL統合をサポートすることで、infrastructure as code を使用した ゼロETL統合の作成、更新、管理が簡素化されます。これにより、データエンジニアリングチームは、設定のバージョン管理を維持しながら、複数の AWS アカウントにわたってあらゆる ゼロETL統合を一貫してデプロイできます。
この機能は、現在 AWS Glue の ゼロETLが利用可能な全ての AWS リージョンで利用できます。

AWS Glue がゼロETL統合のソースとして、追加の SAP エンティティをサポート
AWS Glue は、ゼロETL統合を使用して、新しい SAP エンティティのフルスナップショットおよび増分ロードの取り込みをサポートするようになりました。この機能強化により、完全な変更データキャプチャー (CDC) 機能を持たない SAP エンティティのフルスナップショットデータ取り込みや、Operational Data Provisioning (ODP) フレームワークをサポートしない SAP エンティティの増分データロードが可能になります。
これらの新機能は、ODP をサポートする SAP エンティティ向けの既存機能と連携して動作するため、お客さまは多様な SAP 環境全体でゼロETLデータ取り込み戦略を柔軟に実装できます。フルマネージドの AWS ゼロETL統合は、カスタムETLデータパイプラインの構築に伴うエンジニアリングのオーバーヘッドを排除します。
この新しいゼロETL機能により、削除追跡フラグがない、または ODP フレームワークをサポートしない SAP エンティティのシナリオに対応するため、複数の SAP アプリケーションから Amazon Redshift や Amazon SageMaker のレイクハウスアーキテクチャーにデータを取り込むことができます。削除追跡のないエンティティのフルトスナップショット取り込みと、非 ODP システムのタイムスタンプベースの増分ロードにより、ゼロETL統合は運用上の複雑さを軽減し、カスタムデータパイプラインの設計、構築、テストに通常必要となる数週間のエンジニアリング工数を削減します。
この機能は、AWS Glue ゼロETLが現在利用可能な全ての AWS リージョンで利用可能です。

AWS Glue が Spark DataFrame をサポートする Amazon DynamoDB コネクターを発表
AWS Glue が、Apache Spark DataFrames とネーティブに連携する新しい Amazon DynamoDB コネクターをサポートするようになりました。これにより、Spark 開発者は Spark DataFrames を直接使用し、AWS Glue、Amazon EMR、その他の Spark 環境間でコードを簡単に共有できます。
従来は Glue 固有の DynamicFrame オブジェクトを使用する必要がありましたが、この新しいコネクターでは、既存の Spark DataFrame コードを最小限の変更で再利用できるため、AWS Glue へのジョブ移行が合理化され、データパイプライン開発が簡素化されます。また、Spark DataFrame の全操作と最新のパフォーマンス最適化も利用可能になります。
新しいコネクターは、AWS Glue が利用可能な全ての AWS 商用リージョンで利用できます。

アプリケーション統合

Amazon MWAA で Apache Airflow ワークフロー向けのサーバーレスデプロイメントオプションが東京など15のリージョンで利用可能に
Amazon Managed Workflows for Apache Airflow (MWAA) は、サーバーレスデプロイメントオプションの提供を開始しました。これにより、Apache Airflow 環境の管理に伴う運用オーバーヘッドが不要になり、真のサーバーレススケーリングによってコストが最適化されます。この新しいサービスは、データエンジニアや DevOps チームがワークフローをオーケストレーションする際に直面する、運用上のスケーラビリティ、コスト最適化、アクセス管理といった主要な課題に対処します。
Amazon MWAA Serverless は、リソースの自動プロビジョニングとスケーリングにより、シームレスなワークフローオーケストレーションを提供します。ワークフローは YAML 設定または Python ベースの DAGs を使用して定義でき、Apache Airflow v3.0 の 80 を超える AWS Operators をサポートしています。各ワークフローは、個別の AWS Identity and Access Management (IAM) 権限で分離して実行され、AWS サービスとデータへの安全なアクセスを保証します。インフラストラクチャーのスケーリングは全てサービスが自動的に処理し、お客さまはタスクの実行中に使用された実際のコンピューティング時間に対してのみ料金を支払います。
Amazon MWAA Serverless は、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (ムンバイ)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、カナダ (中部)、欧州 (アイルランド)、欧州 (ストックホルム)、欧州 (フランクフルト)、欧州 (ロンドン)、欧州 (パリ)、南米 (サンパウロ)、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン) の 15 の AWS リージョンで利用可能です。
Apache、Apache Airflow、および Airflow は、米国および/またはその他の国における Apache Software Foundation の登録商標または商標です。

Amazon MQ が RabbitMQ バージョン 4.2 をサポート
Amazon MQ が RabbitMQ バージョン 4.2 をサポートしました。このバージョンでは、AMQP 1.0 プロトコルのネーティブサポート、Khepri という名前の新しい Raft ベースのメタデータストア、ローカルシャベル、クォーラムキューのメッセージ優先度が導入されています。RabbitMQ 4.2 には、スループットとメモリ管理に関するさまざまなバグ修正とパフォーマンス改善も含まれています。
RabbitMQ 4.2 の主な特長は、AMQP 1.0 をコアプロトコルとしてサポートしたことです。これにより、コンシューマーが再キューイングやデッドレタリングの前にメッセージアノテーションを変更できる modified outcome や、クライアントアプリケーションが特定のキューから受信したいメッセージ数を動的に調整できる、きめ細かいフロー制御などの拡張機能が提供されます。
Amazon MQ は、RabbitMQ 4.2 ブローカー向けに設定可能なリソース制限も導入しており、アプリケーションの要件に基づいて変更できます。RabbitMQ 4.0 以降、クラシックキューのミラーリングはサポートされなくなりました。非レプリケートのクラシックキューは引き続きサポートされます。クォーラムキューは RabbitMQ 4.2 ブローカーでサポートされる唯一のレプリケートされ永続化されるキュータイプであり、コンシューマー優先度に加えてメッセージ優先度も提供するようになりました。
Amazon MQ で RabbitMQ 4.2 の使用を開始するには、AWS Management console、AWS CLI、または AWS SDKs を通じて m7g インスタンスタイプを使用して新しいブローカーを作成する際に RabbitMQ 4.2 を選択します。Amazon MQ は RabbitMQ 4.2 ブローカーのパッチバージョンのアップグレードを自動的に管理するため、メジャー.マイナーバージョンを指定するだけで済みます。
このバージョンは、Amazon MQ m7g タイプインスタンスが利用可能な全てのリージョンで利用できます。

Amazon MQ が RabbitMQ の LDAP 認証をサポート
Amazon MQ が、利用可能な全ての AWS リージョンで RabbitMQ ブローカーの LDAP (Lightweight Directory Access Protocol) 認証をサポートするようになりました。この特長により、RabbitMQ ブローカーは LDAP をサポートする ID プロバイダーを使用して Amazon MQ ユーザーの認証と認可を行えるようになり、アクセス管理におけるセキュリティと柔軟性が向上します。LDAP サーバーに保存されている認証情報で Amazon MQ ユーザーを認証できるほか、ユーザーの追加、削除、変更や、トピックおよびキューへの権限割り当ても可能です。
LDAP 認証と認可の設定は、AWS Console、AWS CloudFormation、AWS Command Line Interface (CLI)、または AWS Cloud Development Kit (CDK) を使用して行えます。利用を開始するには、LDAP 認証を使用して新しい RabbitMQ ブローカーを作成するか、既存のブローカーの設定を更新して LDAP サポートを有効にします。この機能は標準の RabbitMQ LDAP 実装との互換性を維持しているため、既存の LDAP 対応ブローカーからシームレスに移行できます。

AWS Step Functions が TestState API でローカルテストを強化
AWS Step Functions は TestState API を強化し、ワークフローのローカル単体テストをサポートするようになりました。これにより、AWS アカウントにステートマシンをデプロイすることなく、Map や Parallel ステートなどの高度なパターンを含むワークフローロジックを検証できます。AWS Step Functions は、220以上の AWS サービスから14,000以上もの API アクションをオーケストレーションして、分散アプリケーションやデータ処理ワークロードを構築できるビジュアルワークフローサービスです。
TestState API は、ローカル開発環境でエラー処理パターンを含む完全なワークフローのテストをサポートします。AWS サービスの統合をモックできるようになり、オプションの API コントラクト検証によって、モックされたレスポンスが実際の AWS サービスからの期待されるレスポンスと一致するかを検証できます。これにより、本番環境でワークフローが正しく動作することを保証しやすくなります。TestState API の呼び出しを Jest や pytest などのテストフレームワークや CI/CD パイプラインに統合し、開発プロセスの一部としてワークフローテストを自動化できます。
これらの機能は、ワークフロー定義に関するフィードバックを即座に提供し、ローカル環境でのワークフローの動作検証を可能にし、開発サイクルの早い段階で潜在的な問題を検出することで、開発を加速させます。
強化された TestState API は、Step Functions が利用可能な全ての AWS リージョンで AWS SDK を通じて利用できます。

ビジネスアプリケーション

Amazon Connect のアウトバウンドキャンペーンが、応答がない通話の呼び出し時間の設定をサポート
Amazon Connect のアウトバウンドキャンペーンで、キャンペーンマネージャーは音声通話の呼び出し時間を15秒から60秒の範囲で設定できるようになりました。設定時間を超えると、通話は「応答なし」とマークされ、次のコンタクトに移動します。各コンタクトでは呼び出しの開始時刻と終了時刻も記録されるため、正確なリポート作成とトレーサビリティーが可能です。
呼び出し時間を設定できることで、キャンペーンマネージャーはキャンペーンごとにオーディエンスに合わせてダイヤル動作を調整できます。分析機能を使用して各通話の正確な呼び出し時間を確認し、接続が失敗した箇所を把握することで、パターンの特定、通話戦略の改善、キャンペーン効果の継続的な向上が可能になります。
この機能は、米国東部 (バージニア北部)、米国西部 (オレゴン)、アフリカ (ケープタウン)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (ロンドン) を含む AWS リージョンで利用可能です。

Amazon Connect で、エージェントが Eメールのコンタクトにフォローアップの返信を送信可能に
Amazon Connect で、エージェントが Eメールのコンタクトにフォローアップの返信を送信できるようになりました。これにより、新しいスレッドを開始することなく追加情報を共有したり、お客さまへの支援を継続したりすることが容易になります。この機能は会話の全履歴を保持するため、エージェントはコンテキストを維持し、一貫したシームレスなサポートを提供できます。
Amazon Connect Email は、米国東部 (バージニア北部)、米国西部 (オレゴン)、アフリカ (ケープタウン)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (ロンドン) の各リージョンで利用できます。

Amazon Connect が音声およびチャットボット向けの会話分析を提供開始
Amazon Connect は、音声およびデジタルチャンネルにおけるエンドカスタマーのセルフサービスインタラクション向けの会話分析機能を提供し、お客さまのセルフサービスエクスペリエンスの理解と改善を支援します。これには、PSTN /テレフォニー、アプリ内およびWeb通話、Webおよびモバイルチャット、SMS、WhatsApp ビジネスメッセージング、Apple Messages for Business が含まれます。
今回のアップデートにより、Connect は、人間のエージェントとのインタラクションとエンドカスタマーのセルフサービスインタラクションの両方で、豊富な会話分析を提供するようになりました。カスタマイズしやすいダッシュボードを通じて、お客さまの感情分析、機密データのマスキング、上位のコンタクトドライバーとテーマの発見、コンプライアンスリスクの特定、改善点の積極的な特定など、自動化されたセルフサービスインタラクションの品質を自動的に分析できます。
また、Connect の会話分析では、セマンティックマッチングルールを使用して、お客さまの行動、キーワード、感情、または請求に関する問い合わせやエージェントへのエスカレーションリクエストなどの問題タイプに基づいてインタラクションを分類することもできます。
Amazon Connect は、コンタクトセンターのお客さま、エージェント、スーパーバイザーに単一のシームレスなエクスペリエンスを提供する、AI を活用したアプリケーションです。

Amazon Connect が強化されたインスタンス間通信をサポート
Amazon Connect で、両方の番号がプロビジョニングまたはポートされている場合、同じアカウント内のインスタンス間の通話が、公衆交換電話網 (PSTN) を経由せずに AWS グローバルバックボーンを通じてルーティングされるようになりました。Amazon Connect インスタンス間で通話するお客さまは、同じリージョン内かリージョン間かにかかわらず、AWS のグローバルネットワークインフラストラクチャーのメリットを享受できます。お客さまは、より高い通話品質、簡素化された請求、転送間で通話コンテキストを維持する強化されたコンタクト共有機能といったメリットを享受できます。この機能は、アフリカ (ケープタウン) を除く、Amazon Connect が提供されている全ての商用リージョンで利用可能です。

Amazon Connect がマルチスキルエージェントのスケジューリングをサポート
Amazon Connect で、エージェントの複数の専門スキルに基づいてスケジューリングを最適化できるようになりました。複数のスキルを持つエージェントを予測された需要にインテリジェントにマッチングさせることで、部門、言語、お客さまのティアなど、複数の側面でエージェントの稼働率を最大化できます。また、最も必要なときには、複数のスキルを持つエージェントを価値の高いインタラクションのために確保することもできます。例えば、バイリンガルのエージェントを戦略的にスケジュールすることで、人員不足に陥りがちな価値の高いフランス語キューのピーク時間帯をカバーし、オフピーク時には一般的な問い合わせに対応させることができます。この機能は、Amazon Connect のエージェントスケジューリングが利用可能な全ての AWS リージョンで利用できます。

Amazon Connect がコールバックキューに入っているコンタクトのモニターリングを開始
Amazon Connect で、コールバックのキューに入っているコンタクトをモニターリングできるようになりました。この機能により、Connect UI と API 内で、コールバックのキューに入っているコンタクトを検索し、お客さまの電話番号やキューに入っている時間などの追加の詳細を表示できます。お客さまに伝えられたコールバックの時間を超えるリスクがあるコンタクトを、エージェントに積極的にルーティングできます。また、すでにエージェントとの接続に成功したお客さまを特定し、コールバックキューからクリアして重複した作業をなくすこともできます。この機能は、Amazon Connect が提供されている全てのリージョンで利用できます。

Amazon Connect が、通話処理を高速化する永続的なエージェント接続を提供開始
Amazon Connect で、エージェントと Amazon Connect 間のオープンな通信チャンネルを維持できるようになり、お客さまとの接続にかかる時間を短縮できます。コンタクトセンターの管理者は、エージェントのユーザープロファイルを構成して、会話終了後も永続的な接続を維持できるように設定でき、これにより後続の通話の接続が高速化されます。Amazon Connect の永続的なエージェント接続は、お客さまがエージェントに接続するまでの時間を短縮することで、アウトバウンドキャンペーンの発信において、米国の電話消費者保護法 (U.S. Telephone Consumer Protection Act (TCPA)) などのテレマーケティング法に関するコンプライアンス要件への対応を容易にします。Amazon Connect の永続的な接続は、Amazon Connect が提供されている全ての AWS リージョンで利用可能であり、Amazon Connect サービスの利用料金および関連する電話料金の標準価格に加えて追加料金は発生しません。

クラウド財務管理

Savings Plans と Reserved Instances のグループ共有が一般提供を開始
Reserved Instances and Savings Plans (RISP) Group Sharing の一般提供が開始されました。これは請求とコスト管理の新機能で、お客さまは AWS のコミットメントが組織全体でどのように共有されるかをきめ細かく制御できます。この機能により、お客さまは Reserved Instances と Savings Plans の特典を AWS 組織内の特定のアカウントグループにどのように配分するかを定義でき、コスト削減をビジネス構造や説明責任の要件に合わせることができます。
RISP Group Sharing は、複数の事業部門にまたがる AWS コストを管理するエンタープライズのお客さまが直面する共通の課題、例えば Reserved Instances や Savings Plans がそれを購入したチームに必ずしも利益をもたらすとは限らない、といった課題に対処します。この機能を使用すると、お客さまは AWS Cost Categories を使用して、事業部門、プロジェクト、地理的地域、資金源など、組織の階層を反映したグループを作成できます。
この機能には 2 つの共有オプションがあります。Prioritized Group Sharing は、コミットメントをまず定義されたグループに適用し、その後、未使用のキャパシティを組織全体で共有します。一方、Restricted Group Sharing は、厳密な境界が必要な場合に、コミットメントを定義されたグループ内に限定して完全に分離します。
RISP Group Sharing は、AWS GovCloud (US) リージョンと中国リージョンを除く全ての AWS リージョンで利用可能です。

Get Invoice PDF API が一般利用可能に
AWS は、Get Invoice PDF API の一般提供を発表しました。これにより、お客さまは SDK コールを介して AWS の請求書をプログラムでダウンロードできるようになります。
お客さまは、AWS Invoice ID を入力として API コールを呼び出すことで、個々の請求書 PDF を取得し、AWS の請求書と補足書類を PDF 形式ですぐにダウンロードするための署名付き Amazon S3 URL を受け取ることができます。請求書の一括取得では、まず List Invoice Summaries API を呼び出して特定の請求期間の Invoice ID を取得し、次にその Invoice ID を Get Invoice API の入力として使用して各請求書 PDF をダウンロードできます。
Get Invoice PDF API は US East (N. Virginia) リージョンで利用可能です。(中国リージョンを除く) 全ての商用リージョンのお客さまがこのサービスを利用できます。

AWS が、複数組織にまたがる請求とコスト管理のための Billing Transfer を発表
Billing Transfer は、複数の AWS Organization にまたがる請求を一元的に管理・支払いできる新機能です。これにより、複数の Organization 環境で運用しているお客さまは、単一の管理アカウントを指定して、請求書の収集、支払い処理、詳細なコスト分析を一元化できます。Billing Transfer は、請求とコスト管理 の運用をより効率的かつスケーラブルにする一方、個々の管理アカウントはそれぞれの Organization に対する完全なセキュリティの自律性を維持できます。
独自の価格情報を保護するため、Billing Transfer は AWS Billing Conductor と統合されています。この統合により、請求管理者はコストデータが AWS Organization にどのように表示されるかを制御し、複数の AWS Organization にまたがる高度なコスト配分戦略を実装できます。
Billing Transfer を利用するお客さまが AWS マネージド料金プランを選択した場合、AWS Billing Conductor の利用は無料です。お客さまマネージド料金プランを選択した場合は、AWS Organization ごとに 50 ドルの料金が発生します。AWS は、2026年5月31日まで Billing Transfer の無料トライアルを提供します。この期間中、Billing Conductor の AWS マネージド料金プランとお客さまマネージド料金プランの両方が無料で利用できます。2026年6月1日以降、Billing Transfer を利用するお客さまには、お客さまマネージド料金プランが適用された AWS Organization の数に応じて課金されます。Billing Transfer を使用せずに Billing Conductor を単独で利用する場合、使用する料金プランの種類にかかわらず、引き続き標準のアカウントごとの料金モデルが適用されます。
Billing Transfer は、GovCloud、中国 (北京)、中国 (寧夏) リージョンを除く全てのパブリック AWS リージョンで利用可能です。

AWS が SAP Ariba と Coupa の調達ポータルを使用するお客さま向けに E-Invoice delivery を導入
AWS E-Invoice delivery の一般提供が開始されました。この新機能により、AWS のお客さまは SAP Ariba および Coupa の調達ポータルアカウントを AWS に接続して PO を取得できます。また、PO と照合された AWS の請求書を同日中に調達ポータルに送付することも可能です。
お客さまは AWS 請求とコスト管理 コンソールから AWS E-Invoice delivery 機能の利用を開始できます。利用開始後は、AWS 請求とコスト管理 コンソールと調達ポータルの両方で請求書の配信状況を追跡でき、請求書処理ワークフローの合理化が可能になります。
AWS E-Invoice delivery 機能は、GovCloud (US) リージョン、中国 (北京) リージョン、中国 (寧夏) リージョンを除く全ての AWS リージョンで利用可能です。

AWS Data Exports for FOCUS 1.2 が一般提供を開始
AWS は、AWS Data Exports for FOCUS 1.2 の一般提供を開始しました。FOCUS 1.2 は、複数のソースにわたる Cloud Financial Management を簡素化するための標準化を提供する、オープンなクラウドコストと使用状況の仕様です。AWS Data Exports for FOCUS 1.2 を使用すると、お客さまは FOCUS 1.2 スキーマを使用して AWS のコストと使用状況データを Amazon S3 にエクスポートできます。これにより、お客さまは請求書の照合機能で決算処理を合理化し、キャパシティ予約のステータスを追跡して未使用の予約を特定し、マルチクラウドや SaaS のコスト管理シナリオで仮想通貨サポートを活用できます。
この仕様は、FOCUS 1.0 の標準化された 4 つのコスト列構造 (ListCost、ContractedCost、BilledCost、EffectiveCost) を維持しつつ、追加のエンタープライズユースケースのサポートを拡張しています。これにより、組織はクラウドプロバイダーやソリューションプロバイダー全体でコストリポートを標準化し、財務業務の効率を向上させることができます。
AWS Data Exports for FOCUS 1.2 は US East (バージニア北部) リージョンで利用可能で、AWS GovCloud (米国) リージョンと AWS 中国 (北京および寧夏) リージョンを除く全ての AWS リージョンを対象とするコストと使用状況データが含まれます。

AWS Cost Optimization Hub が、クラウドのコスト効率を測定・追跡する Cost Efficiency メトリックを導入
請求とコストマネジメントコンソールの機能である AWS Cost Optimization Hub は、組織全体のクラウドコスト効率を長期的に測定・追跡するのに役立つ Cost Efficiency メトリックをサポートするようになりました。このメトリックは、適正化、アイドル状態、コミットメントの推奨事項を考慮して、最適化可能なクラウド支出の割合を自動的に計算します。これにより、一貫したコスト削減のベンチマークを設定し、パフォーマンス目標を定め、進捗を追跡して、クラウド投資のROIを最大化できます。
AWS Cost Optimization Hub は、コスト最適化の機会から得られる月間推定削減額の合計を、最適化可能な支出で割ることによって、コスト効率の指標を提供します。組織全体でこのメトリックを長期的に追跡して、コスト効率を把握し、ベンチマークを設定できます。毎日更新されるため、このメトリックは最適化の進捗に関する日々のインサイトを提供し、コスト削減の推奨事項を実装するとスコアが向上し、非効率なリソースがプロビジョニングされるとスコアが低下することを示します。
Cost efficiency は、AWS Cost Optimization Hub がサポートされている全ての AWS リージョンで利用可能になりました。

AWS Cost Explorer が 18カ月の予測と説明可能な AI による予測（プレビュー）を提供
AWS Cost Explorer に3つの主要な改善が加えられました。一般提供の機能強化として、予測期間が従来の12カ月から18カ月に延長され、機械学習モデルが最大36カ月（従来は6カ月）の履歴データを分析して季節パターンや長期的な成長トレンドを特定できるようになりました。さらに、パブリックプレビューとして、予測方法論の透明性を提供するAIによる説明機能が新たに追加されました。
AWS Cost Explorer は、詳細なコストと使用状況リポートおよび予測機能を通じて、お客さまのクラウド支出の分析と管理を支援します。今回の機能強化により、年間の予算計画サイクルに必要な可視性が拡張されます。これにより、財務チームは季節的なパターン、休日のピーク、ビジネスサイクルをより高い精度で考慮し、利害関係者に対してより高い信頼性をもって予測を提示できます。AIによる説明機能は、コスト予測の背後にある主要な要因の理解と伝達を支援し、最適化の機会特定やクラウド投資に対する経営層の賛同を得やすくします。
18カ月の予測期間には、AWS Cost Explorer コンソールまたは GetCostForecast API を通じて直接アクセスできます。AIによる説明機能は、パブリックプレビュー期間中、コンソールでのみ利用可能です。

AWS Cost Anomaly Detection が異常の特定を迅速化
AWS Cost Anomaly Detection に、異常な支出パターンをより迅速に特定できる、改善された検出アルゴリズムが搭載されました。
強化されたアルゴリズムは、24時間のローリングウインドーを使用して AWS の支出を分析し、AWS が更新されたコストと使用状況データを受信するたびに、現在のコストを前日の同等の期間と比較します。
このアルゴリズムは、コストパターン分析における2つの一般的な課題に対処します。
1. 不完全な暦日のコストを過去の日次合計と比較することで生じる異常検出の遅延を解消します。ローリングウインドーは常に完全な24時間期間を比較するため、異常なパターンをより迅速に特定できます。
2. 午前と午後で異なる使用パターンを持つワークロードを考慮し、1日の同様の時間帯のコストと比較評価することで、より正確な比較を提供します。
これらの改善により、誤検知を減らしつつ、より迅速で正確な異常検出が可能になります。
この AWS Cost Anomaly Detection の機能強化は、AWS GovCloud (US) Regions と China Regions を除く全ての AWS リージョンで利用できます。

AWS Cost Anomaly Detection が AWS マネージドモニターリングを拡張
AWS Cost Anomaly Detection では、単一のマネージドモニターで、全てのリンクされたアカウント、コスト配分タグ、またはコストカテゴリーを監視できるようになりました。以前は AWS サービスでのみ利用可能でしたが、この機能により、手動設定なしで AWS 組織全体の異常な支出パターンを特定できます。
組織がスケールするにつれて、説明責任を維持し、異常を迅速に特定するために、個々のアカウント、チーム、またはビジネスユニットのコストに対する可視性が必要になります。例えば、「team」というコスト配分タグを使用して 500 のアプリケーションチームを追跡している場合、以前は 500 の個別のモニターを作成して維持する必要がありました。今回のアップデートにより、各チームの支出を個別に自動追跡する単一のマネージドモニターを作成できます。組織が変化した場合 (例えば「team-mobile」が「team-ios」と「team-android」に分割されるなど)、設定を変更することなく両方の新しいチームが個別に自動監視され、組織の成長に合わせて継続的な異常検出が保証されます。
リンクされたアカウント、コスト配分タグ、コストカテゴリーへの AWS マネージドモニターの拡張は、全ての商用 AWS リージョンで追加料金なしで利用できます。

コンピューティング

第2世代の AWS Outposts ラックが AWS アジアパシフィック (東京) リージョンでサポートされるようになりました
第2世代の AWS Outposts ラックが、AWS アジアパシフィック (東京) リージョンでサポートされるようになりました。Outposts ラックは、AWS のインフラストラクチャー、AWS サービス、API、ツールを、ほぼ全てのオンプレミスのデータセンターやコロケーションスペースに拡張し、真に一貫したハイブリッドエクスペリエンスを実現します。日本国内外のスタートアップから大企業、公共部門までの組織は、この新しいサポート対象リージョンに接続された Outposts ラックを注文できるようになり、レイテンシーとデータレジデンシーのニーズを最適化できます。
Outposts を利用することで、お客さまはオンプレミスシステムへの低レイテンシーアクセスが必要なワークロードをローカルで実行しつつ、アプリケーション管理のためにホームリージョンに接続できます。また、Outposts と AWS サービスを使用して、データレジデンシー要件を満たすためにオンプレミスに保持する必要があるデータを管理および処理することもできます。このリージョン拡大により、お客さまの Outposts が接続できる AWS リージョンの柔軟性が向上します。

Supplementary Packages for Amazon Linux が一般提供を開始
Supplementary Packages for Amazon Linux (SPAL) の一般提供が開始されました。これは、開発者やシステム管理者が Amazon Linux 2023 (AL2023) と互換性のある、ビルド済みの何千もの EPEL9 パッケージに簡単にアクセスできるようにする専用リポジトリです。
Amazon Linux は AWS 上で実行される多くのアプリケーションの基盤ですが、開発者はソースコードからパッケージをビルドする際に時間のかかるプロセスに直面することがよくありました。SPAL は、すぐに使用できるパッケージを提供することでこの課題に対処し、AL2023 環境で作業するチームの開発ワークフローを加速させます。
SPAL を使用すると、開発チームはデプロイ時間を大幅に短縮し、パッケージのコンパイルではなく、コアアプリケーションの開発に集中できます。このソリューションは、ソースからビルドするオーバーヘッドなしに本番ワークロード用の信頼性の高いパッケージを必要とする DevOps エンジニア、システム管理者、開発者にとって特に価値があります。
SPAL パッケージは、コミュニティーによってメンテナンスされている EPEL9 プロジェクトから派生したもので、AWS はアップストリームで利用可能になったセキュリティパッチを提供します。AWS は、Amazon Linux 2023 の GitHub リポジトリを通じてお客さまからのフィードバックに基づき、リポジトリを継続的に拡張していきます。
Supplementary Packages for Amazon Linux (SPAL) は、AWS GovCloud (US) Regions と中国を含む全ての AWS 商用リージョンで利用できます。

EC2 Image Builder が自動バージョニングをサポートし、Infrastructure as Code の体験を向上
Amazon EC2 Image Builder は、レシピの自動バージョニングとコンポーネントの自動ビルドバージョンインクリメントをサポートし、手動でのバージョン管理のオーバーヘッドを削減します。これにより、バージョンを自動的にインクリメントし、手動で更新することなくパイプラインで最新の互換性のあるバージョンを動的に参照できるようになります。
自動バージョニングを使用すると、レシピの新しいバージョンを作成する際に、バージョン番号を手動で追跡してインクリメントする必要がなくなります。バージョン番号の任意の位置に 'x' プレースホルダーを1つ配置するだけで、Image Builder が既存の最新バージョンを検出し、その位置を自動的にインクリメントします。コンポーネントの場合、同じ名前とセマンティックバージョンでコンポーネントを作成すると、Image Builder がビルドバージョンを自動的にインクリメントします。設定でリソースを参照する際、ワイルドカードパターンは指定されたパターンに一致する利用可能な最新バージョンに自動的に解決されるため、パイプラインは常に最新バージョンを使用します。
自動バージョニングは、全ての AWS リージョンで利用できます。EC2 Image Builder コンソール、CLI、API、CloudFormation、または CDK から利用を開始できます。

EC2 Image Builder が柔軟な AMI 配布機能を発表
Amazon EC2 Image Builder で、既存の Amazon Machine Images (AMI) の配布、配布の再試行、カスタム配布ワークフローの定義が可能になりました。配布ワークフローは、既存のビルドおよびテストワークフローを補完する新しいワークフロータイプであり、AMI のコピー操作、アクション待機チェックポイント、AMI 属性の変更といった順次的な配布ステップを定義できます。
強化された配布機能により、完全な Image Builder パイプラインを実行することなく、既存のイメージを複数のリージョンやアカウントに配布できます。AMI と配布設定を指定するだけで、Image Builder がコピーと共有のプロセスを処理します。さらに、配布ワークフローではカスタムステップを定義して配布プロセスをカスタマイズできます。例えば、最初にテストリージョンに AMI を配布し、検証のために一時停止するアクション待機ステップを追加した後、承認を受けてから本番リージョンへの配布を続行できます。これにより、ビルドおよびテストワークフローと同様のステップレベルの可視性と制御が可能になります。
これらの機能は、Sinnet が運営する AWS China (Beijing) Region、NWCD が運営する AWS China (Ningxia) Region、および AWS GovCloud (US) Regions を含む全ての AWS リージョンで、追加費用なしで全てのお客さまにご利用いただけます。

EC2 Image Builder が Lambda と Step Functions をサポート
EC2 Image Builder は、イメージワークフローを通じて Lambda 関数を呼び出し、Step Functions ステートマシンを実行できるようになりました。これにより、複雑なマルチステップのワークフローやカスタム検証ロジックをイメージ作成プロセスに組み込み、イメージの構築・検証方法をより柔軟に制御できます。
これまでは、イメージワークフロー内に Lambda や Step Functions を統合するには、カスタムコードの記述やマルチステップの回避策が必要で、セットアップに時間がかかり、メンテナンスが難しく、エラーが発生しやすい面倒なプロセスでした。今回のアップデートによるネーティブ統合により、Lambda 関数をシームレスに呼び出してカスタムロジックを実行したり、Step Functions ステートマシンをオーケストレーションして複雑なマルチステップのワークフローを実行したりできます。これにより、カスタムコンプライアンス検証、カスタム通知の送信、多段階のセキュリティテストといったユースケースを、全て Image Builder ワークフロー内で実装可能です。
これらの機能は、Sinnet が運営する AWS China (Beijing) Region、NWCD が運営する AWS China (Ningxia) Region、および AWS GovCloud (US) Regions を含む全ての AWS リージョンで、追加費用なしで全てのお客さまにご利用いただけます。

Amazon Lightsail が Nginx ブループリントのサポートを更新し、ブループリントの選択肢を拡大
Amazon Lightsail が新しい Nginx ブループリントの提供を開始しました。この新しいブループリントでは、デフォルトで Instance Metadata Service Version 2 (IMDSv2) が適用され、IPv6 のみのインスタンスをサポートします。
わずか数クリックで、Nginx がプリインストールされた、希望のサイズの Lightsail 仮想プライベートサーバー (VPS) を作成できます。Lightsail のインスタンスバンドルには、希望のOSがプリインストールされたインスタンス、ストレージ、月間データ転送許容量が含まれており、迅速に起動して実行するために必要なものが全て揃っています。
この新しいブループリントは、Lightsail が利用可能な全ての AWS リージョンで利用できます。

Amazon EC2 が、AMI の完全な系統を可視化する AMI 系譜機能を導入
Amazon EC2 は、Amazon マシンイメージ (AMI) の系譜情報を提供するようになりました。これにより、任意の AMI の完全な系統を、直系の親から各世代を経てルート AMI まで遡って追跡できます。この機能は、AMI の出所とリージョン間での伝播方法を完全に可視化します。
従来、AMI の系統追跡は手動プロセスやカスタムタグ付け戦略に依存しており、エラーが発生しやすく、特に AMI が複数のリージョンにコピーされる場合、大規模な維持が困難でした。AMI の系譜機能により、環境内の任意の AMI の世代チェーン全体を完全に把握できます。この機能は、内部ポリシー遵守のための AMI 追跡、祖先チェーンでセキュリティ問題が発見された際の脆弱な可能性のある全 AMI の特定、リージョンをまたいだ AMI の出所の完全な可視性の維持といった重要なユースケースに対応します。
AMI の系統情報は、AWS CLI 、 SDK 、または Console を使用してアクセスでき、AWS China および AWS GovCloud (US) リージョンを含む全ての AWS リージョンで追加費用なしで利用可能です。

Amazon EC2 が Microsoft SQL Server の高可用性デプロイメントのコストを削減
ライセンス込みの SQL Server を実行している Amazon EC2 インスタンスを、高可用性 (HA) クラスターの一部として指定することで、わずか数クリックでライセンスコストを削減できるようになりました。この機能強化は、Always On Availability Groups や Always On failover cluster instances を使用するミッションクリティカルな SQL Server データベースにとって特に有益です。例えば、ライセンス込みの Windows と SQL Server を搭載した 2 つの m8i.4xlarge インスタンスで SQL Server HA を実行する場合、パフォーマンスを損なうことなく、HA の総コストを最大 40% 削減できます。この機能は、全ての商用 AWS リージョンで利用できます。

Amazon EC2 が Microsoft SQL Server 2025 イメージを発表
Amazon EC2 は、ライセンス込み (LI) の Microsoft SQL Server 2025 Amazon Machine Images (AMIs) をサポートし、SQL Server の最新バージョンを迅速に起動できるようになりました。Amazon EC2 上で SQL Server 2025 を実行することで、お客さまは AWS のセキュリティ、パフォーマンス、信頼性と SQL Server の最新機能を活用できます。
Amazon は Microsoft SQL Server 2025 AMIs を作成・管理し、EC2 Windows インスタンス上での SQL Server 2025 のプロビジョニングと管理を簡素化します。これらのイメージは、パフォーマンスとセキュリティを強化するため、デフォルトで Transport Layer Security (TLS) プロトコルのバージョン 1.3 をサポートしています。また、管理を容易にするため、AWS Tools for Windows PowerShell、AWS Systems Manager、AWS CloudFormation、および各種ネットワーク/ストレージドライバーなどのソフトウェアがプリインストールされています。
SQL Server 2025 AMIs は、全ての商用 AWS リージョンおよび AWS GovCloud (US) リージョンで利用できます。

Amazon EC2 Mac インスタンスが Apple macOS Tahoe をサポート
Apple macOS Tahoe (バージョン 26) を Amazon Machine Images (AMI) として Amazon EC2 Mac インスタンスで実行できるようになりました。Apple macOS Tahoe は最新のメジャー macOS バージョンであり、Xcode バージョン 26.0 以降 (iOS、iPadOS、macOS、tvOS、watchOS、visionOS の最新 SDK を含む) の実行など、以前の macOS バージョンに比べて複数の新機能とパフォーマンスの向上が導入されています。
Amazon Elastic Block Store (EBS) を基盤とする EC2 macOS AMI は、EC2 Mac インスタンスで実行される開発者ワークロード向けに、安定性、安全性、パフォーマンスに優れた環境を提供するように設計された、AWS がサポートするイメージです。EC2 macOS AMI には、AWS Command Line Interface、Command Line Tools for Xcode、Amazon SSM Agent、Homebrew が含まれています。AWS Homebrew Tap には、AMI に含まれる AWS パッケージの最新バージョンが含まれています。
Apple macOS Tahoe AMI は Apple silicon EC2 Mac インスタンスで利用でき、Apple silicon EC2 Mac インスタンスが現在利用可能な全ての AWS リージョンで公開されています。お客さまは、AWS Console、Command Line Interface (CLI)、または API を介して macOS Tahoe AMI の利用を開始できます。

Amazon EC2 I7i インスタンスが大阪など4つの追加リージョンで利用可能に
高性能なストレージ最適化 Amazon EC2 I7i インスタンスが、AWS アジアパシフィック (メルボルン、ムンバイ、大阪) および中東 (UAE) リージョンで利用可能になりました。
第5世代 Intel Xeon スケーラブルプロセッサー (全コアターボ周波数 3.2 GHz) を搭載した I7i インスタンスは、前世代の I4i インスタンスと比較して、コンピューティング性能が最大23%、価格性能が10%以上向上しています。第3世代 AWS Nitro SSD により、最大 45TB の NVMe ストレージを提供し、I4i インスタンスと比較してリアルタイムストレージ性能が最大50%向上、ストレージI/Oレイテンシーが最大50%低減、ストレージI/Oレイテンシーのばらつきも最大60%低減します。
I7i インスタンスは、中小規模のデータセット (数TB) にリアルタイムのレイテンシーでアクセスするために、非常に高いランダムIOPS性能を必要とする、I/O集約型でレイテンシーに敏感なワークロードに最適です。また、最大 16KB のブロックサイズで torn write prevention 機能をサポートしており、データベースのパフォーマンスボトルネックを解消できます。
インスタンスは、最大 48xlarge までの9つの仮想サイズと2つのベアメタルサイズを含む11のサイズで利用でき、最大 100Gbps のネットワーク帯域幅と 60Gbps の Amazon Elastic Block Store (EBS) 帯域幅を提供します。

Amazon EC2 Fleet がインスタンスタイプ選択のための新しい暗号化属性を追加
Amazon EC2 Fleet は、Attribute-Based Instance Type Selection (ABIS) の新しい暗号化属性をサポートするようになりました。お客さまは、vCPU コアやメモリなどのリソース要件の指定に加え、RequireEncryptionInTransit パラメーターを使用して、転送中の暗号化をサポートするインスタンスタイプを特定して起動できます。
この新しい暗号化属性は、VPC Encryption Controls を強制モードで使用し、全てのネットワークトラフィックを転送中に暗号化する必要があるお客さまの重要なコンプライアンスニーズに対応します。ABIS で暗号化要件をほかのインスタンス属性と組み合わせることで、お客さまはセキュリティニーズを満たしつつ、より良いキャパシティ確保のためにインスタンスタイプの多様化を実現できます。
さらに、GetInstanceTypesFromInstanceRequirements (GITFIR) を使用すると、指定した暗号化要件に基づいて割り当てられる可能性のあるインスタンスタイプをプレビューできます。
この機能は、全ての AWS 商用リージョンおよび AWS GovCloud (US) リージョンで利用できます。利用を開始するには、CreateFleet または GITFIR API を呼び出す際に、InstanceRequirements の RequireEncryptionInTransit パラメーターを true に設定します。

AWS Parallel Computing Service が Slurm REST API をサポート
AWS Parallel Computing Service (AWS PCS) が Slurm REST API をサポートするようになりました。この新しい機能により、コマンドラインツールに頼ることなく、HTTP リクエストを使用してジョブのプログラムによる送信、クラスターの状態監視、リソース管理が可能になります。AWS PCS は、Slurm を使用して AWS 上でハイパフォーマンスコンピューティング (HPC) ワークロードの実行とスケーリング、および科学技術モデルの構築を容易にするマネージドサービスです。Slurm REST API を使用すると、追加の REST API インフラストラクチャーを維持するオーバーヘッドなしに、クラスター操作を自動化し、HPC リソースを web ポータル、CI/CD パイプライン、データ処理フレームワークなどの既存のシステムやワークフローに統合できます。この機能は AWS PCS が利用可能な全ての AWS リージョンで、追加費用なしで利用できます。

AWS Parallel Computing Service が HIPAA に対応
AWS Parallel Computing Service (AWS PCS) が HIPAA (医療保険の相互運用性と説明責任に関する法律) に対応しました。AWS PCS は、Slurm ワークロードマネージャーを使用して High Performance Computing (HPC) クラスターを構築および管理できるマネージドサービスです。
今回の AWS PCS の HIPAA 認定により、Business Associate Addendum (BAA) を締結している組織は、ゲノムシーケンシング、医療画像分析、臨床研究シミュレーションなどの計算集約的なヘルスケアワークロードに AWS PCS を使用できるようになりました。AWS は、HIPAA 対応サービスが HIPAA の管理的、技術的、物理的な保護措置を確実にサポートするための、標準ベースのリスク管理プログラムを維持しています。
AWS PCS は、利用可能な全ての AWS リージョンで HIPAA に準拠しています。

AWS Lambda が、テナント対応アプリケーションの構築を簡素化する新しいテナント分離モードを発表
AWS Lambda は、Lambda 関数を呼び出す個々のテナントやエンドユーザーのリクエスト処理を分離できる、新しいテナント分離モードを発表しました。これにより、ワークフロー自動化やコード実行のための SaaS プラットフォームなど、Lambda 上のマルチテナントアプリケーションの構築が簡素化されます。
マルチテナントアプリケーションでは、テナントごとに厳格な分離が求められますが、従来はお客さまがテナントごとに専用の Lambda 関数を作成するなどのカスタムソリューションを実装する必要がありました。今回のアップデートにより、カスタムソリューションを構築・運用することなく、厳格なテナント分離要件を満たすことができます。このアップデートは、Lambda の分離境界を単一の関数から、その関数を呼び出す各テナントにまで拡張します。
新しいテナント分離モードを使用するには、Lambda 関数を呼び出す際に一意のテナント識別子を指定します。Lambda はこの識別子を使用してリクエストをルーティングし、特定のテナントに関連付けられた実行環境が、ほかのテナントのリクエスト処理に使用されないようにします。
AWS Lambda の新しいテナント分離モードは、アジアパシフィック (ニュージーランド)、AWS GovCloud (US)、中国を除く全ての AWS リージョンで利用できます。

AWS Lambda が Python 3.14 をサポート
AWS Lambda で Python 3.14 を使用したサーバーレスアプリケーションの作成がサポートされるようになりました。開発者は Python 3.14 をマネージドランタイムとコンテナベースイメージの両方として使用でき、AWS は利用可能になった更新をマネージドランタイムとベースイメージに自動的に適用します。
Python 3.14 は Python の最新の長期サポートリリースです。このリリースにより、Lambda を利用するお客さまは最新の Python 3.14 の言語機能にアクセスできます。
サポートされているリージョンでは、Lambda@Edge で Python 3.14 を使用して、Amazon CloudFront を通じて配信される低レイテンシーのコンテンツをカスタマイズできます。サーバーレスのベストプラクティスを実装し、開発者のベロシティを向上させるための開発者向けツールキットである Powertools for AWS Lambda (Python) も Python 3.14 をサポートしています。
Lambda コンソール、AWS CLI、AWS Serverless Application Model (AWS SAM)、AWS CDK、AWS CloudFormation などの AWS のあらゆるデプロイツールを使用して、Python 3.14 で記述されたサーバーレスアプリケーションをデプロイおよび管理できます。
Python 3.14 ランタイムは、AWS GovCloud (US) リージョンおよび中国リージョンを含む全てのリージョンで利用可能です。

AWS Lambda が Kafka ESM のプロビジョニングモードでコストを最大90%最適化する新機能を発表
AWS Lambda の Kafka イベントソースマッピング (ESM) のプロビジョニングモードに新機能が追加されました。これにより、Kafka ESM をグループ化してイベントポーラーの密度を高めることができ、Kafka ESM のコストを最大 90% 最適化できます。
このコスト最適化機能により、スループット要件が低いものを含む全ての Kafka ワークロードでプロビジョニングモードを使用できるようになります。その際、スループット制御、スキーマ検証、Avro/Protobuf イベントのフィルターリング、低レイテンシーでの呼び出し、強化されたエラー処理といった特長を活用できます。
お客さまは Kafka ESM のプロビジョニングモードを使用して、イベントポーラーと呼ばれるポーリングリソースをプロビジョニングおよび自動スケーリングすることで、ESM のスループットを微調整します。料金は Event Poller Unit (EPU) と呼ばれる課金単位で計算されます。各 EPU は最大 20 MB/s のスループット容量をサポートし、EPU当たりデフォルトで 4 つのイベントポーラーをサポートします。
今回のアップデートにより、各 EPU は低スループットのユースケース向けにデフォルトで 10 個のイベントポーラーを自動的にサポートするようになり、EPU 容量の利用率が向上します。さらに、新しい PollerGroupName パラメーターを設定することで、同じ Amazon VPC 内の複数の Kafka ESM をグループ化して EPU 容量を共有できるようになりました。これらの機能強化により、低スループットのワークロードにおける EPU コストを最大 90% 削減できます。
これらの最適化により、プロビジョニングモードのパフォーマンス上の利点を維持しながら、さまざまなスループット要件を持つアプリケーションのコストを大幅に削減できます。
この機能は、AWS Lambda の Kafka ESM 用プロビジョニングモードが利用可能な全ての AWS 商用リージョンで利用できます。
今回のアップデートにより、既存の Kafka ESM 用プロビジョニングモードは、低スループットのイベントポーラーのパッキング改善による恩恵を自動的に受けられます。ESM のグループ化は、Lambda ESM API、AWS Console、CLI、SDK、CloudFormation、SAM を通じて、PollerGroupName パラメーターを最小および最大のイベントポーラー設定とともに構成することで実装できます。

AWS Compute Optimizer が automation rules を発表
AWS Compute Optimizer に、Amazon Elastic Block Store (EBS) ボリュームを大規模に最適化できる新機能「automation rules」が導入されました。automation rules を使用すると、アタッチされていない EBS ボリュームのクリーンアップや、最新世代のボリュームタイプへのアップグレードプロセスを効率化し、クラウドインフラ全体のコスト削減とパフォーマンス向上を実現できます。
automation rules では、基準に一致した最適化の推奨事項を、定期的なスケジュールで自動的に適用できます。基準として AWS Region を設定して特定の地域をターゲットにしたり、Resource Tags を使用して本番環境と開発環境のワークロードを区別したりできます。ルールを日次、週次、または月次で実行するように設定すると、AWS Compute Optimizer が新しい推奨事項を基準に照らして継続的に評価します。
新しいダッシュボードでは、自動化イベントの経時的な要約、詳細なステップ履歴の確認、達成されたコスト削減額の見積もりが可能です。アクションを取り消す必要がある場合は、同じダッシュボードから直接実行できます。
AWS Compute Optimizer の automation rules は、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ)、アジアパシフィック (大阪)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (ストックホルム)、南米 (サンパウロ) の各 AWS リージョンで利用できます。

コンテナ

Amazon EKS アドオンが AWS Secrets Store CSI Driver provider をサポート
AWS は、AWS Secrets Store CSI Driver provider EKS add-on の一般提供を発表しました。この新しい統合により、お客さまは 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 クラスター用の運用ソフトウェアのインストール、設定、ライフサイクル管理を自動化するキュレーションされた拡張機能であり、クラスターの機能とセキュリティの維持プロセスを簡素化します。
この新しい Amazon EKS アドオンは、全ての AWS 商用リージョンおよび AWS GovCloud (US) リージョンで利用可能です。

Amazon EKS と Amazon ECS がフルマネージド MCP サーバーを発表（プレビュー）
Amazon Elastic Kubernetes Service (EKS) と Amazon Elastic Container Service (ECS) は、開発と運用における AI を活用した体験を可能にする、フルマネージド MCP サーバーをプレビューで発表しました。MCP (Model Context Protocol) は、EKS と ECS クラスターのリアルタイムなコンテキスト知識で AI アプリケーションを強化する標準化されたインターフェースを提供し、開発から運用までのアプリケーションライフサイクル全体で、より正確でカスタマイズされたガイダンスを可能にします。
今回のアップデートにより、EKS と ECS は AWS クラウドでホストされるフルマネージド MCP サーバーを提供するため、ローカルでのインストールとメンテナンスが不要になります。フルマネージド MCP サーバーは、自動更新とパッチ適用、AWS IAM 統合による一元的なセキュリティ、AWS CloudTrail による包括的な監査ログ、AWS の実績あるスケーラビリティ、信頼性、サポートといったエンタープライズグレードの機能を提供します。
フルマネージドの Amazon EKS と ECS の MCP サーバーにより、開発者は Kiro CLI、Cursor、Cline のような AI コーディングアシスタントを簡単に設定し、ガイド付き開発ワークフロー、最適化されたコード生成、コンテキストを意識したデバッグを行うことができます。運用者は、大規模なクラスター管理における豊富な運用経験から得られた、ベストプラクティスとトラブルシューティングガイダンスのナレッジベースにアクセスできます。

Amazon EKS が強化されたコンテナネットワークの可観測性を導入
Amazon Elastic Kubernetes Service (EKS) に、コンテナネットワーク環境へのより深いインサイトを提供する新しいネットワーク可観測性機能が追加されました。これにより、AWSにおけるKubernetesネットワークの理解、監視、トラブルシュートが向上します。
強化されたコンテナネットワークの可観測性により、お客さまはきめ細かいネットワーク関連のメトリクスを活用し、クラスタートラフィック、AZ間のフロー、AWSサービスにわたるプロアクティブな異常検出を改善できます。これらのメトリクスを使用してシステムパフォーマンスを測定し、任意の可観測性スタックでメトリクスを可視化することも可能です。
さらに、EKSはAWSコンソールでネットワーク監視の可視化機能を提供するようになり、正確なトラブルシュートを加速して根本原因の分析を迅速化します。お客さまはこれらの可視化機能を利用して、再送信や再送信タイムアウトを引き起こしている通信量の多いノード (top-talkers) やネットワークフローを特定し、インシデント発生時の死角をなくすことができます。
EKSのこれらのネットワーク監視機能は、Amazon CloudWatch Network Flow Monitor を利用しています。EKSの強化されたコンテナネットワーク可観測性は、Amazon CloudWatch Network Flow Monitor が利用可能な全ての商用AWSリージョンで利用可能です。

Amazon EKS が Provisioned Control Plane を導入
Amazon Elastic Kubernetes Service (EKS) に、新機能 Provisioned Control Plane が導入されました。これは、クラスターのコントロールプレーンのキャパシティを選択することで、要求の厳しいワークロードに対して予測可能で高いパフォーマンスを確保する機能です。
Provisioned Control Plane では、定義済みのスケーリングティアからコントロールプレーンのキャパシティを事前にプロビジョニングすることで、トラフィックの急増や予測不能なバーストに常に対応できます。この新しいスケーリングティアは、クラスターのパフォーマンスとスケーラビリティを大幅に向上させ、単一クラスターで超大規模なワークロードを実行可能にします。
Provisioned Control Plane は、製品の発売やホリデーセールといった需要の高いイベントにおいて、最小限のレイテンシーと高いパフォーマンスが求められるワークロードをサポートします。また、開発、ステージング、本番、災害復旧の各環境で一貫したコントロールプレーンのパフォーマンスを保証するため、テスト時の動作が本番環境やフェイルオーバー時の動作を正確に反映します。
これにより、AI のトレーニング/推論、ハイパフォーマンスコンピューティング、単一クラスターで数千のワーカーノードを必要とする大規模データ処理ジョブなどのワークロードを実行できます。
Amazon EKS Provisioned Control Plane を利用するには、EKS API、AWS コンソール、または Infrastructure as Code ツールを使用して、新規または既存の EKS クラスターで有効化します。

Amazon ECS と Amazon EKS が、コンソールで強化された AI 搭載のトラブルシューティングを提供開始
Amazon Elastic Container Service (ECS) と Amazon Elastic Kubernetes Service (EKS) は、AWS マネジメントコンソールで Amazon Q Developer を通じて強化された AI 搭載のトラブルシューティング体験を提供するようになりました。この新しい体験は、コンソール内のエラーやステータスメッセージの横に状況に応じて表示され、お客さまはワンクリックで問題の根本原因を特定し、緩和策の提案を確認できます。
ECS コンソールでは、新しい「Inspect with Amazon Q」ボタンを使用して、タスクの失敗、コンテナのヘルスチェックの失敗、デプロイのロールバックなどの問題をトラブルシュートできます。クリックすると、Amazon Q は自動的に問題を分析し、関連するログとメトリクスを収集して根本原因の特定を支援し、緩和策を推奨します。
Amazon EKS コンソールは、可観測性ダッシュボード全体に Amazon Q を統合しており、コンテキストに応じた AI の支援を受けて、クラスター、コントロールプレーン、ノードの健全性の問題を調査し、トラブルシュートすることができます。この機能は、アップグレードに関する洞察など、クラスターレベルの知見を深め、潜在的な問題を事前に特定して緩和するのに役立ちます。また、Amazon Q は、問題を示す Pod 上の Kubernetes イベントの調査を支援することでワークロードのトラブルシューティングを効率化し、根本原因の特定と解決を迅速化します。
Amazon ECS および Amazon EKS コンソールにおける Amazon Q の統合は、全ての AWS 商用リージョンで利用可能です。

Amazon ECS が Express Mode を発表
Amazon Elastic Container Service (Amazon ECS) に Express Mode が新機能として追加され、開発者はWebアプリケーションやAPIなどのコンテナ化されたアプリケーションを迅速に起動できるようになりました。Express Mode は、インフラストラクチャーリソースに対する完全な制御を維持しながら、アプリケーションのクラウドアーキテクチャーのオーケストレーションと管理を容易にし、開発者がビジネス価値の提供に集中できるようにします。
全ての Express Mode サービスは、AWSが提供するドメイン名を自動的に受け取るため、追加設定なしでアプリケーションにすぐにアクセスできます。Express Mode を使用するアプリケーションには、AWSの運用上のベストプラクティスが組み込まれており、パブリックまたはプライベートのHTTPSリクエストを処理し、トラフィックパターンに応じてスケールします。
トラフィックは Application Load Balancer (ALB) を通じて分散され、インテリジェントなルールベースのルーティングにより、ALBリソースを効率的に利用しながらサービス間の分離を維持します。また、適切な場合には最大25の Express Mode サービスが単一のALBの背後に自動的に統合されます。Express Mode によってプロビジョニングされた全てのリソースはアカウント内で完全にアクセス可能であり、制御や柔軟性が損なわれることはありません。アプリケーションの要件が変化した場合、実行中のアプリケーションを中断することなく、Amazon ECS および関連サービスの全機能セットを活用して、あらゆるインフラストラクチャーリソースに直接アクセスし、変更できます。
利用を開始するには、コンテナ イメージ を提供するだけで、Express Mode が Amazon ECS にアプリケーションをデプロイし、URLを自動生成します。
Amazon ECS Express Mode は、全てのAWSリージョンで追加料金なしで利用できます。料金は、アプリケーションの実行のために作成されたAWSリソースに対してのみ発生します。新しい Express Mode サービスは、Amazon ECS Console, SDK, CLI, CloudFormation, CDK, Terraform を使用してデプロイできます。

Amazon ECS Managed Instances が設定可能なスケールイン遅延を追加
Amazon ECS Managed Instances (ECS Managed Instances) は、設定可能なスケールイン遅延により、インフラストラクチャーの最適化をより詳細に制御できるようになりました。この機能強化により、特定のワークロードパターンやビジネス要件に基づいてインスタンス管理をきめ細かく調整し、コスト最適化と運用ニーズのバランスを改善できます。
ECS Managed Instances は、ワークロード要件に基づいて適切なサイズの Amazon EC2 インスタンスを自動的にプロビジョニングし、アイドルインスタンスの終了やタスクの統合によってコストを継続的に最適化するフルマネージドのコンピューティングオプションです。ECS は通常、高可用性とコストのバランスを取るためにヒューリスティックな遅延を用いてスケールインを行いますが、この遅延時間はバッチジョブなどの特定の要件には合わない場合がありました。
今回のアップデートにより、`scaleInAfter` 設定パラメーターを最大 60 分まで設定し、インフラストラクチャーの最適化ニーズに合わせることが可能になりました。また、`scaleInAfter` を -1 に設定してインフラストラクチャー最適化ワークフローを無効にすることもでき、これによりインスタンスは 14 日後にパッチが適用されるまで実行され続けます。
ECS Managed Instances キャパシティプロバイダーの作成または更新時に、ECS API、コンソール、SDK、CDK、CloudFormation を使用して `scaleInAfter` パラメーターを設定できます。この機能は、全ての商用 AWS リージョンで利用可能です。

Amazon ECR のデュアルスタックエンドポイントが AWS PrivateLink をサポート
Amazon Elastic Container Registry (ECR) は、デュアルスタックエンドポイントにおける AWS PrivateLink のサポートを開始しました。これにより IPv6 への標準化が容易になり、Amazon Virtual Private Cloud (VPC) と ECR 間の全てのネットワークトラフィックを Amazon ネットワークに限定することで、セキュリティ体制を向上させることができます。この機能は、全ての AWS 商用リージョンおよび AWS GovCloud (US) リージョンで、追加費用なしで利用可能です。

Amazon ECR がマネージドコンテナイメージ署名をサポート
Amazon ECR は、セキュリティ体制を強化し、署名設定の運用オーバーヘッドをなくすためのマネージドコンテナイメージ署名をサポートするようになりました。コンテナイメージ署名により、イメージが信頼できるソースからのものであることを検証できます。マネージド署名では、ECR Console での数クリックまたは単一の API 呼び出しだけでコンテナイメージ署名の設定が簡素化されます。
利用を開始するには、署名の有効期間や、ECR がイメージに署名するリポジトリなどのパラメーターを指定する AWS Signer 署名プロファイルで署名ルールを作成します。設定が完了すると、ECR はイメージをプッシュしたエンティティのアイデンティティーを使用して、プッシュ時にイメージへ自動的に署名します。
ECR は署名操作に AWS Signer を利用し、キーマテリアルと証明書の生成、安全な保管、ローテーションを含むライフサイクル管理を処理します。全ての署名操作は、完全な監査のために CloudTrail に記録されます。ECR マネージド署名は、AWS Signer が利用可能な全ての AWS リージョンで利用できます。

Amazon ECR が、アクセス頻度の低いコンテナイメージ向けのアーカイブストレージクラスを導入
Amazon ECR に、アクセス頻度の低い大量のコンテナイメージのストレージコストを削減するための、新しいアーカイブストレージクラスが追加されました。このストレージクラスは、コンプライアンスと保持要件を満たしつつ、ストレージコストを最適化するのに役立ちます。
ECR のライフサイクルポリシーで最終プル時間に基づいたイメージのアーカイブがサポートされ、使用パターンに応じてイメージを自動的にアーカイブできます。イメージをアーカイブするには、イメージの経過期間、数、最終プル時間などの基準に基づいてライフサイクルルールを設定するか、ECR Console または API を使用して個別にアーカイブします。
アーカイブできるイメージの数に制限はなく、アーカイブされたイメージはリポジトリごとのイメージ数の上限にはカウントされません。アーカイブされたイメージはプルできなくなりますが、ECR コンソール、CLI、または API を介して20分以内に復元でき、復元後は通常どおりプルできます。全てのアーカイブおよび復元操作は、監査のために CloudTrail に記録されます。
新しい ECR アーカイブストレージクラスは、全ての AWS 商用リージョンおよび AWS GovCloud (US) リージョンで利用できます。

データベース

Oracle Database@AWS が Oracle Transparent Data Encryption との AWS KMS 統合をサポート
Oracle Database@AWS は、データベース暗号化キーを管理するために AWS Key Management Service (KMS) と統合されました。KMS は、データの暗号化と署名に使用されるキーを作成および制御するための AWS のマネージドサービスです。この統合により、お客さまは KMS を使用して Oracle Database@AWS の Oracle Transparent Data Encryption (TDE) マスターキーを暗号化できるようになりました。これにより、お客さまは AWS でのデータ暗号化に使用するキーを作成・制御するための一貫したメカニズムを利用でき、セキュリティとコンプライアンスの要件を満たすことができます。
KMS は、中央ポリシーときめ細かいアクセスによる堅ろうなキー管理と制御、AWS CloudTrail による包括的なログ記録と監査、セキュリティを強化するための自動キーローテーションといった特長を備えています。KMS を使用して Oracle TDE マスターキーを暗号化することで、お客さまは Oracle Database@AWS のデータベース暗号化キーに対しても同様のメリットを得られ、AWS 内のデータに一貫した監査およびコンプライアンス手順を適用できます。
TDE との AWS KMS 統合は、Oracle Database@AWS が利用可能な全ての AWS リージョンで利用できます。この機能の利用にあたり、標準の AWS KMS の料金以外に、追加の Oracle Database@AWS の料金は発生しません。

Aurora DSQL が、IAM 認証を簡素化する Python、Node.js、JDBC 用の新しいコネクターを発表
標準の PostgreSQL ドライバーを使用して Aurora DSQL クラスターに接続するお客さま向けに、IAM 認証を簡素化する Aurora DSQL Connectors for Python, Node.js, JDBC がリリースされました。
このコネクターは、IAM トークンの生成を自動的に処理する透過的な認証レイヤーとして機能するため、トークン生成コードの記述や IAM トークンの手動での提供が不要になります。有効な AWS 認証情報と AWS SDK を使用して接続ごとに IAM トークンを自動生成することで、認証を合理化し、従来ユーザーが生成していたパスワードに関連するセキュリティリスクを排除します。
コネクターは、Python 用の psycopg や psycopg2、Node.js 用の node-postgres や Postgres.js、標準の PostgreSQL JDBC ドライバーなど、一般的な PostgreSQL ドライバーとシームレスに連携します。また、既存のワークフロー、接続プーリングライブラリ (JDBC 用の HikariCP や Node.js と Python の組み込みプーリングなど)、Spring Boot のようなフレームワークもサポートしており、既存の PostgreSQL ドライバー機能との完全な互換性を維持します。
このコネクターは、Aurora DSQL が利用可能な全てのリージョンで利用できます。

Amazon RDS が SQL Server Web Edition のMulti-AZ をサポート
Amazon Relational Database Service (Amazon RDS) for SQL Server で、SQL Server Web Edition の Multi-AZ 配置がサポートされるようになりました。SQL Server Web Edition は、公開WebサイトやWebアプリケーションなどをサポートするために特別に設計されており、Webホスティング事業者やWeb付加価値プロバイダー (VAP) によって使用されています。
これらのアプリケーションには高可用性と自動フェイルオーバーが必要ですが、今回のアップデートにより、お客さまは SQL Server Web Edition で Amazon RDS の Multi-AZ 配置オプションを使用して高可用性ソリューションを実現できます。これにより、高可用性のために SQL Server Standard Edition や Enterprise Edition といった、より高価なオプションを使用する必要がなくなります。
この機能を使用するには、Amazon RDS for SQL Server Web Edition インスタンスを Multi-AZ 配置オプションで設定します。Amazon RDS は、異なるアベイラビリティーゾーン (AZ) にスタンバイレプリカを自動的にプロビジョニング・維持し、データを同期的にレプリケートします。プライマリデータベースが利用できなくなった場合、Amazon RDS は自動的にスタンバイレプリカにフェイルオーバーするため、お客さまは管理者の介入なしで迅速にデータベース操作を再開できます。

Amazon RDS for SQL Server が Resource Governor をサポート
Amazon Relational Database Service (Amazon RDS) for SQL Server が、Microsoft SQL Server の機能である resource governor をサポートするようになりました。これにより、お客さまはさまざまなワークロードによるコンピューティングリソースの消費を管理し、データベースのパフォーマンスを最適化できます。
お客さまは RDS for SQL Server Enterprise Edition データベースインスタンスで resource governor を使用して、リソースを大量に消費するクエリが重要なワークロードに影響を与えるのを防ぎ、マルチテナント環境で予測可能なパフォーマンスを実装し、ピーク時のリソース割り当てを効率的に管理できます。
RDS for SQL Server は、リソースプール、ワークロードグループ、分類子関数などの resource governor 設定を実装するためのストアドプロシージャを提供します。これらの機能により、お客さまは単一の RDS for SQL Server インスタンス内で、データベースワークロードごとに CPU、メモリ、I/O リソースを割り当て、制御できます。
resource governor は、Amazon RDS for SQL Server が利用可能な全ての AWS リージョンにおいて、SQL Server Enterprise Edition で利用できます。

Amazon RDS for Oracle が 2025年10月リリースアップデートと Spatial Patch Bundle をサポート
Amazon Relational Database Service (Amazon RDS) for Oracle は、Oracle データベースバージョン 19c および 21c 向けの Oracle 2025年10月リリースアップデート (RU) と、Oracle データベースバージョン 19c 向けの対応する Spatial Patch Bundle をサポートするようになりました。2025年10月 RU には Oracle データベース製品向けの新しいセキュリティパッチが 6 つ含まれているため、アップグレードをおすすめします。Spatial Patch Bundle のアップデートは、Oracle Spatial and Graph 機能に重要な修正を適用し、空間操作において信頼性の高い最適なパフォーマンスを提供します。
2025年10月 RU は、Amazon RDS マネジメントコンソール から数クリックで、または AWS SDK や CLI を使用して適用できます。メンテナンスウインドー中にデータベースインスタンスへ更新を自動的に適用するには、Automatic Minor Version Upgrade を有効にしてください。新しいデータベースインスタンスに Spatial Patch Bundle アップデートを適用するか、AWS Console で「Spatial Patch Bundle Engine Versions」チェックボックスを選択して既存のインスタンスをエンジンバージョン `19.0.0.0.ru-2025-10.spb-1.r1` にアップグレードできます。

Amazon RDS for MySQL が新しいマイナーバージョン 8.0.44 と 8.4.7 をサポート
Amazon Relational Database Service (Amazon RDS) for MySQL は、MySQL コミュニティーによってリリースされた最新のマイナーバージョンである MySQL 8.0.44 と 8.4.7 をサポートするようになりました。以前のバージョンの MySQL の既知のセキュリティ脆弱性を修正し、MySQL コミュニティーによって追加されたバグ修正、パフォーマンスの向上、新機能といった特長を活用するために、新しいマイナーバージョンへのアップグレードを推奨します。
マイナーバージョンの自動アップグレード機能を利用すると、スケジュールされたメンテナンスウインドー中に、データベースをより新しいマイナーバージョンへ自動的にアップグレードできます。また、Amazon RDS Managed Blue/Green デプロイメントを使用して、MySQL インスタンスをより安全、シンプル、かつ迅速にアップデートすることもできます。
Amazon RDS for MySQL は、クラウドでの MySQL デプロイメントのセットアップ、運用、スケールを容易にします。

Amazon RDS for MariaDB がコミュニティー MariaDB のマイナーバージョンをサポート
Amazon Relational Database Service (Amazon RDS) for MariaDB で、コミュニティー MariaDB のマイナーバージョン 10.6.24、10.11.15、11.4.9 がサポートされるようになりました。MariaDB の以前のバージョンに含まれる既知のセキュリティ脆弱性を修正し、MariaDB コミュニティーによって追加されたバグ修正、パフォーマンスの向上、新機能を利用するために、最新のマイナーバージョンにアップグレードすることをおすすめします。
自動マイナーバージョンアップグレードを利用すると、スケジュールされたメンテナンスウインドー中にデータベースをより新しいマイナーバージョンへ自動的にアップグレードできます。また、Amazon RDS Managed Blue/Green デプロイメントを活用すれば、MariaDB インスタンスをより安全、簡単、かつ迅速に更新することが可能です。

Amazon RDS Optimized Reads が R8gd および M8gd データベースインスタンスを東京リージョンなどでサポート
Amazon Relational Database Service (RDS) は、Amazon Aurora PostgreSQL、RDS for PostgreSQL、MySQL、MariaDB の Optimized Reads 用に R8gd および M8gd データベースインスタンスをサポートするようになりました。R8gd および M8gd データベースインスタンスは、価格性能比が向上しています。例えば、Aurora PostgreSQL の場合、R8gd インスタンスでの Optimized Reads は、R6g インスタンスと比較してスループットが最大 165%、価格性能比が最大 120% 向上します。
Optimized Reads は、これらのインスタンスで利用可能なローカル NVMe ベースの SSD ブロックストレージを使用して、一時テーブルなどのエフェメラルデータを保存します。これにより、ネットワークベースのストレージとのデータアクセスが削減され、読み取りレイテンシーとスループットが向上します。その結果、複雑なクエリのパフォーマンスが向上し、インデックスの再構築操作が高速化されます。
I/O-Optimized 設定を使用する Aurora PostgreSQL Optimized Reads インスタンスは、さらにローカルストレージを使用してキャッシュ容量を拡張します。インメモリバッファキャッシュから追い出されたデータベースページはローカルストレージにキャッシュされ、その後のデータ取得を高速化します。
お客さまは、AWS Management Console、CLI、SDK を通じて、既存の Aurora および RDS データベースを変更するか、R8gd または M8gd インスタンスを使用して新しいデータベースを作成することで、Optimized Reads の利用を開始できます。
これらのインスタンスは、米国東部 (バージニア北部, オハイオ)、米国西部 (オレゴン)、欧州 (スペイン, フランクフルト)、アジアパシフィック (東京) リージョンで利用可能です。
料金とリージョンごとの利用可能状況の詳細については、料金ページをご覧ください。これらの DB インスタンスタイプをサポートする特定のエンジンバージョンについては、Aurora および RDS のドキュメントをご覧ください。

Amazon DynamoDB がグローバルセカンダリーインデックスで複数属性の複合キーをサポート
Amazon DynamoDB のグローバルセカンダリーインデックス (GSI) で、最大8つの属性で構成されるプライマリキーがサポートされるようになりました。これまでパーティションキーとソートキーはそれぞれ1つの属性に制限されていましたが、DynamoDB はパーティションキーとソートキーにそれぞれ最大4つの属性をサポートするようになりました。
複数属性キーにより、値を手動で連結して合成キーを作成する必要がなくなります。この作業は、新しいインデックスを追加する前にデータをバックフィルする必要が生じることがありました。代わりに、最大8つの既存の属性を使用してプライマリキーを作成できるため、多様なアクセスパターンのモデル化や新しいクエリ要件への適応が容易になります。
複数属性のパーティションキーは、データの分散と一意性を向上させます。複数属性のソートキーにより、ソートキー属性に左から右へ条件を指定することで、柔軟なクエリが可能になります。例えば、パーティションキーが `UserId` で、ソートキー属性が Country、State、City のインデックスを使用すると、あるユーザーの全ての場所をクエリし、その後 Country、State、または City で結果を絞り込むことができます。
複数属性のパーティションキーとソートキーは、DynamoDB が利用可能な全ての AWS リージョンで追加料金なしで利用できます。これらは AWS マネジメントコンソール、AWS CLI、AWS SDKs、または DynamoDB API を使用して作成できます。

Amazon Aurora MySQL 3.11 (MySQL 8.0.43 互換) が一般提供を開始
Amazon Aurora MySQL - Compatible Edition 3 (MySQL 8.0 互換) は、Aurora MySQL v3.11 を通じて MySQL 8.0.43 をサポートするようになりました。
MySQL 8.0.43 には、いくつかのセキュリティ強化とバグ修正に加え、グループレプリケーションに関する追加のエラーが含まれており、ほとんどの mysql クライアントコマンドを有効または無効にする mysql クライアントの「commands」オプションが導入されています。
Aurora MySQL 3.11 にアップグレードするには、DB クラスターを変更して手動でマイナーバージョンアップグレードを開始するか、DB クラスターの作成または変更時に「Auto minor version upgrade」オプションを有効にします。このリリースは、Aurora MySQL が利用可能な全ての AWS リージョンで利用できます。

Amazon Aurora DSQL データベースクラスターが最大 256 TiB のストレージボリュームをサポート
Amazon Aurora DSQL が最大 256 TiB のストレージ制限をサポートするようになり、以前の 128 TiB という制限から倍増しました。これにより、お客さまは単一のデータベースクラスター内でより大規模なデータセットを保存および管理でき、大規模アプリケーションのデータ管理が簡素化されます。
Aurora DSQL では、お客さまは使用したストレージに対してのみ料金を支払い、ストレージは使用量に応じて自動的にスケールするため、事前にストレージをプロビジョニングする必要はありません。
全ての Aurora DSQL クラスターは、デフォルトで 10 TiB のストレージ制限があります。より高いストレージ制限を持つクラスターを希望するお客さまは、Service Quotas コンソールまたは AWS CLI を使用して制限の引き上げをリクエストできます。
引き上げられたストレージ制限は、Aurora DSQL が利用可能な全てのリージョンで利用できます。

Amazon Aurora DSQL がクエリプランでステートメントレベルのコスト見積もりを提供開始
Amazon Aurora DSQL は、クエリプランでステートメントレベルのコスト見積もりを提供するようになり、開発者は個々のSQLステートメントが消費するリソースを即座に把握できるようになりました。この機能強化により、Distributed Processing Unit (DPU) の使用量見積もりがクエリプランの出力に直接表示され、ワークロードのコスト要因の特定、クエリパフォーマンスのチューニング、リソース使用量の予測改善に役立ちます。
Aurora DSQL は、EXPLAIN ANALYZE VERBOSE プラン出力の最後に、カテゴリー別 (コンピューティング、読み取り、書き込み、マルチリージョン書き込み) および合計の推定DPU使用量を追加します。この機能は、クエリコストに対するきめ細かいリアルタイムの可視性を提供することで CloudWatch メトリクスを補完します。
EXPLAIN ANALYZE VERBOSE プランにおける Aurora DSQL のDPU使用量サポートは、Aurora DSQL が利用可能な全てのリージョンで利用できます。

Amazon Aurora DSQL が、AWS マネジメントコンソールに統合クエリエディターを提供
Amazon Aurora DSQL が、ブラウザーベースの SQL アクセス用の統合クエリエディターを提供するようになりました。今回のアップデートにより、お客さまは外部クライアントをインストールしたり設定したりすることなく、AWS マネジメントコンソール から直接 Aurora DSQL クラスターに安全に接続し、SQL クエリを実行できます。この機能により、開発者、アナリスト、データエンジニアは、クラスター作成後すぐにクエリを開始でき、価値実現までの時間を短縮し、データベース操作を簡素化できます。
Aurora DSQL クエリエディターは、構文のハイライト、オートコンプリート、インテリジェントなコード支援機能を組み込んだ、直感的なワークスペースを提供します。1つのインターフェース内で、スキーマオブジェクトの探索、SQL クエリの開発と実行、結果の表示を迅速に行うことができます。この統合されたエクスペリエンスにより、データの探索と分析が効率化され、ユーザーは Aurora DSQL をより簡単に使い始めることができます。
Aurora DSQL コンソールクエリエディターは、Aurora DSQL が利用可能な全てのリージョンで利用できます。

デベロッパーツール

AWS Device Farm がフルマネージドの Appium エンドポイントを発表
AWS Device Farm は、モバイルおよび Web 開発者が実際のモバイルデバイスやデスクトップブラウザーを使用してアプリをテストできるようにします。今回のアップデートにより、わずか数行のコードでフルマネージドの Appium エンドポイントに接続し、IDE やローカルマシンから直接、複数の物理デバイスでインタラクティブなテストを実行できるようになりました。
この機能は、Appium Inspector (ホスト版とローカル版の両方) などのサードパーティー製ツールともシームレスに連携し、要素のインスペクションを含む全てのアクションに対応します。ライブビデオとログストリーミングのサポートにより、ローカルのワークフロー内でより迅速なテストフィードバックを得ることができます。この機能は、安全な エンタープライズグレード のワークロードを実行するための規模と制御を提供する、既存のサーバーサイド実行を補完するものです。
これにより、Device Farm は IDE、AWS コンソール、その他の環境から、モバイルアプリの作成、インスペクション、デバッグ、テスト、リリースをより迅速に行う機能を提供します。

AWS CLI と SDK の認証にコンソール認証情報が利用可能に
開発者は、既存の AWS マネジメントコンソールのサインイン認証情報を使用して、AWS サービスにプログラムでアクセスできるようになりました。ブラウザーベースの簡単な認証フローの後、AWS は AWS CLI、AWS Tools for PowerShell、AWS SDKs などのローカル開発ツールで機能する一時的な認証情報を自動的に生成します。
この AWS ローカル開発向けのログイン機能により、アカウント登録後すぐに AWS サービスを使った構築を簡単に開始でき、プログラムによるアクセスのために個別のIDやアクセスキーを作成・管理する必要がなくなります。`aws login` CLI コマンドは、自動的にローテーションされる短期的な認証情報を生成するため、長期的なアクセスキーに関連するリスクを軽減し、セキュリティ体制を強化します。
この機能は、全ての商用 AWS リージョンで利用可能です。利用を開始するには、AWS CLI (バージョン 2.32.0 以降) と AWS SDKs を最新バージョンにアップグレードし、ターミナルで `aws login` を実行してください。

エンドユーザーコンピューティング

Amazon WorkSpaces Applications が新しいインスタンスタイプと設定可能なストレージオプションを追加
Amazon WorkSpaces Applications に、コンピューティングと設定可能なストレージボリュームの選択肢を増やす、柔軟性を強化した機能が追加されました。お客さまはカスタム EC2 AMI をインポートして Amazon WorkSpaces イメージを作成することも可能です。これらの新機能により、お客さまはコストを最適化しつつ、リソースを特定のアプリケーション要件により適合させることができます。
このサービスには、汎用、コンピューティング最適化、メモリ最適化、高速化オプションなど、サポートされている全てのインスタンスファミリーで100種類以上のコンピューティングインスタンスタイプとサイズが追加されました。また、ストレージボリュームを200GBから500GBの範囲でカスタマイズしたり、独自の Microsoft Windows Server 2022 AMI を任意のイメージカスタマイズツールと組み合わせて利用したりすることも可能です。
これらの機能強化により、基本的なオフィスアプリケーションから要求の厳しいCADソフトウェアまで、各ユースケースに適したインスタンスタイプを選択できます。また、アプリケーションのニーズに応じてストレージサイズを選択することも可能です。このようなカスタマイズは全て、インフラストラクチャー管理の複雑さを排除するフルマネージドサービスのシンプルさを維持しながら利用できます。
この新機能は、Amazon WorkSpaces Applications がサポートされている全ての AWS リージョンで一般提供されており、標準的な従量課金モデルで提供されます。

Amazon WorkSpaces Applications が IPv6 をサポート
Amazon WorkSpaces Applications が WorkSpaces Applications ドメインと外部エンドポイントで IPv6 をサポートするようになりました。これにより、エンドユーザーは (SAML 認証を除き) IPv6 互換デバイスから IPv6 経由で WorkSpaces Applications に接続できます。
このアップデートにより、お客さまは IPv6 のコンプライアンス要件を満たし、IPv4 と IPv6 間のアドレス変換を処理するための高価なネットワーク機器が不要になります。IPv6 のサポートは、より大きなアドレス空間を提供し、VPC 内で重複するアドレス空間を管理する必要性をなくすことで、ネットワークアーキテクチャーの合理化を支援します。お客さまはアプリケーションを IPv6 ベースにすることができ、フォールバックメカニズムを介してインフラの将来性を確保し、既存の IPv4 システムとの互換性を維持できます。
この機能は、US East (バージニア北部、オハイオ)、US West (オレゴン)、カナダ (中部)、欧州 (パリ、フランクフルト、ロンドン、アイルランド)、アジアパシフィック (東京、ムンバイ、シドニー、ソウル、シンガポール)、南米 (サンパウロ)、AWS GovCloud (米国西部、米国東部) を含む 16 の AWS リージョンで、追加費用なしで利用できます。WorkSpaces Applications は従量課金制の料金体系を提供しています。
この機能をユーザーに対して有効にするには、Windows、macOS 用の最新の WorkSpaces Applications クライアントを使用するか、Webアクセスから直接接続する必要があります。

ウェブとモバイルのフロントエンド

Amazon Location Service が Address Form Solution Builder を発表
AWS は、Amazon Location Service の Address Form Solution Builder を発表しました。これにより開発者は、予測候補、郵便番号などの住所フィールドの自動入力、カスタマイズ可能なレイアウトを備えた住所入力フォームを、コードを書かずに構築できます。
ガイド付きのエクスペリエンスにより、数分ですぐに使えるアプリケーションを生成し、React JavaScript、React Typescript、またはスタンドアロン HTML/JavaScript の開発者パッケージをダウンロードできます。開発者は住所入力フォームを使用することで、ユーザーエクスペリエンスを向上させ、住所情報収集の速度と精度を高めることができます。
予測候補などの特長により、エンドユーザーは数回のキー入力で完全な住所を選択でき、データ入力時間とエラー率を削減できます。統合された地図ビューでは、選択した住所の位置を視覚化し、地図上のピンの位置を調整して特定の入り口を示すことも可能です。住所収集の速度と精度を向上させることで、企業は顧客体験を向上させ、不正を減らし、配送成功率を高めることができます。
Amazon Location Service の Address Form Solution Builder は、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オregon)、アジアパシフィック (ムンバイ)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (ストックホルム)、欧州 (スペイン)、南米 (サンパウロ) の各 AWS リージョンで利用可能です。

Amazon API Gateway が開発者ポータル機能を追加
Amazon API Gateway がポータルを発表しました。これにより、企業はフルマネージドで AWS ネーティブな開発者ポータルを作成できます。このポータルは、AWS インフラストラクチャー全体にわたる REST API などの AWS アセットを検出し、ドキュメント化、ガバナンス、収益化するための中央ハブとして機能します。
ポータルは、アカウントを横断して既存の API を自動検出し、ドキュメントを生成することで、API が断片化する課題を解決します。カスタムドキュメントの作成も可能です。チームは、API を対象者ごとに論理的な製品として整理し、会社のロゴを添付してブランディングをカスタマイズしたり、アクセス制御を設定したり、組織の標準への API コンプライアンスを確保したり、分析機能でユーザーエンゲージメントを把握したりできます。ユーザーは、検出機能と「Try It」ボタンを利用して API を探索できます。
ポータルには、今日の API 管理における課題に対処する3つの特長があります。全ての API 設定を AWS 内に保持し、内外のユーザーにアクセス制御を提供することで、サードパーティーソリューションのセキュリティリスクを排除します。また、ポータルの自動生成と API の進化に合わせたドキュメント更新により、開発者のオンボーディング時間を数週間から数分に短縮します。これにより、数週間かかるインフラ設定が不要になり、開発チーム間での再利用も促進されます。さらに、CloudWatch RUM (Real User Monitoring) を通じて開発者ポータルの使用状況と分析を可視化し、ユーザーエンゲージメントの把握を容易にします。
Amazon API Gateway Portals は、AWS GovCloud (US) および中国リージョンを除く全ての AWS リージョンで利用できます。

Amazon API Gateway が REST API 向けの追加の TLS セキュリティポリシーをサポート
Amazon API Gateway は、API エンドポイントとカスタムドメイン名で強化された TLS セキュリティポリシーをサポートするようになり、API のセキュリティ体制をより細かく制御できます。
REST API とカスタムドメイン名を設定する際に、TLS 1.3 のみを要求するオプション、Perfect Forward Secrecy の実装、連邦情報処理標準 (FIPS) への準拠、Post Quantum Cryptography の活用など、拡張されたセキュリティポリシーのリストから選択できるようになりました。これらのポリシーは、進化するセキュリティ要件やより厳しい規制への準拠、API 接続の暗号化強化を支援し、API セキュリティ管理を簡素化します。また、強化されたポリシーは、ガバナンスを強化するためのエンドポイントアクセス制御もサポートします。
API Gateway の強化された TLS セキュリティポリシーは、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、アフリカ (ケープタウン)、アジアパシフィック (香港)、アジアパシフィック (ハイデラバード)、アジアパシフィック (ジャカルタ)、アジアパシフィック (マレーシア)、アジアパシフィック (メルボルン)、アジアパシフィック (ムンバイ)、アジアパシフィック (大阪)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、カナダ西部 (カルガリー)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (ミラノ)、欧州 (パリ)、欧州 (スペイン)、欧州 (ストックホルム)、欧州 (チューリッヒ)、イスラエル (テルアビブ)、中東 (UAE)、南米 (サンパウロ) の各 AWS 商用リージョンで利用可能です。

Amazon API Gateway が REST API のレスポンスストリーミングをサポート
Amazon API Gateway で、レスポンスペイロードが利用可能になり次第、クライアントに順次ストリーミングできるようになりました。これにより、送信前にレスポンス全体をバッファリングする必要がなくなり、REST API の応答性が向上します。この新機能は、Lambda 関数、HTTP プロキシ統合、プライベート統合など、ストリーミングをサポートするバックエンドで動作します。
レスポンスストリーミングには、time-to-first-byte (TTFB) パフォーマンスの向上、最大15分までの統合タイムアウトの延長、10 MB を超えるペイロードのサポートという3つの主な特長があります。特に生成系AIアプリケーションでは、ユーザーがリアルタイムで応答が段階的に表示されるのを確認できるため、TTFB の向上によるメリットがあります。また、処理に時間がかかる複雑な思考集約型のモデルも、タイムアウトが延長されたことで実行可能になります。さらに、大きなペイロードをサポートすることで、署名付き Amazon S3 URL のような回避策を必要とせず、メディアファイルや大規模なデータセットを直接ストリーミングできます。
Amazon API Gateway のレスポンスストリーミングは、AWS GovCloud (US) リージョンを含む全ての AWS リージョンで利用でき、リージョン、プライベート、エッジ最適化エンドポイントで動作します。

Amazon API Gateway REST API が Application Load Balancer とのプライベート統合をサポート
Amazon API Gateway REST API が Application Load Balancer (ALB) との直接プライベート統合をサポートし、内部 ALB への VPC 間接続が可能になりました。この機能強化は API Gateway の既存の VPC 接続を拡張し、REST API の実装において、より柔軟で効率的なアーキテクチャーの選択肢を提供します。
この ALB との直接統合には、これまで Network Load Balancer 経由で必要だった追加のネットワークホップをなくすことによるレイテンシーの削減、アーキテクチャーの簡素化によるインフラコストの削減、HTTP/HTTPS ヘルスチェック、高度なリクエストベースのルーティング、ネーティブコンテナサービス統合などのレイヤー7機能の強化といった複数の利点があります。引き続き、レイヤー4接続には API Gateway と Network Load Balancer の統合を利用できます。
Amazon API Gateway の ALB とのプライベート統合は、全ての AWS GovCloud (US) リージョンと、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、アフリカ (ケープタウン)、アジアパシフィック (香港)、アジアパシフィック (ハイデラバード)、アジアパシフィック (ジャカルタ)、アジアパシフィック (マレーシア)、アジアパシフィック (メルボルン)、アジアパシフィック (ムンバイ)、アジアパシフィック (大阪)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、カナダ西部 (カルガリー)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (ミラノ)、欧州 (パリ)、欧州 (スペイン)、欧州 (ストックホルム)、欧州 (チューリッヒ)、イスラエル (テルアビブ)、中東 (バーレーン)、中東 (UAE)、南米 (サンパウロ) の各 AWS 商用リージョンで利用できます。

IoT

AWS IoT Core が、IoT rules-SQL を変数設定およびエラー処理機能で強化
AWS IoT Core が IoT rules-SQL で SET 句をサポートするようになり、SQL ステートメント間で変数を設定・再利用できるようになりました。この新機能は SQL の記述を簡素化し、変数を複数回使用する際の一貫性を確保します。加えて、新しい get_or_default() 関数は、データエンコーディングや外部依存関係の問題が発生した際にデフォルト値を返すことで障害処理を改善し、IoT ルールが正常に実行され続けるようにします。
AWS IoT Core は、IoT デバイスのデータをフィルターリング、処理、デコードし、ルーティングするマネージドサービスです。これらの新機能により、複雑な SQL ステートメントが不要になり、IoT rules-SQL の障害管理が容易になります。
このアップデートは、AWS GovCloud (US) および Amazon China Regions を含む、AWS IoT Core が利用可能な全ての AWS リージョンで利用可能です。

人工知能

Automated Reasoning チェックが、自然言語によるテストQ&A生成に対応
Amazon Bedrock ガードレール の Automated Reasoning チェック向けに、自然言語によるテストQ&A生成機能が発表されました。Automated Reasoning チェックは、形式検証技術を使用して生成AIモデル出力の正確性とポリシー準拠を検証します。このチェックは、LLMからの正しい応答を最大99%の精度で検出し、AIのハルシネーション検出において証明可能な保証を提供するとともに、モデル応答の曖昧さ検出も支援します。
今回のアップデートにより、Automated Reasoning チェックは入力ドキュメントのコンテンツを使用して各ポリシーに対して最大N個のテストQ&Aを生成し、初期のポリシー生成から本番環境に対応した洗練されたポリシーへの移行に必要な作業を削減します。
Automated Reasoning チェックのテスト生成機能は、US (バージニア北部)、US (オハイオ)、US (オレゴン)、ヨーロッパ (フランクフルト)、ヨーロッパ (アイルランド)、ヨーロッパ (パリ) の各リージョンで利用可能です。お客さまは Amazon Bedrock コンソールおよび Amazon Bedrock Python SDK を通じてこのサービスにアクセスできます。

Amazon SageMaker が既存データセットのワンクリックオンボーディングを導入、東京など9つのリージョンで利用可能に
Amazon SageMaker に、既存の AWS データセットを Amazon SageMaker Unified Studio へワンクリックでオンボーディングする機能が導入されました。これにより、お客さまは既存の AWS Identity and Access Management (IAM) ロールと権限を使用して、数分でデータ作業を開始できます。
AI エージェントが組み込まれた新しいサーバーレスノートブックを使用し、アクセス可能なあらゆるデータでの作業が可能です。このノートブックは SQL、Python、Spark、自然言語をサポートし、データエンジニア、アナリスト、データサイエンティストに、SQL クエリとコードの両方を開発・実行するための単一の高性能インターフェースを提供します。また、SQL 分析用のクエリエディター、JupyterLab IDE、Visual ETL とワークフロー、機械学習 (ML) 機能など、ほかの多くの既存ツールにもアクセスできます。ML 機能には、中央モデルハブからの基盤モデルの発見、サンプルノートブックによるカスタマイズ、実験のための MLflow の使用、トレーニング済みモデルのモデルハブへの公開、予測のための推論エンドポイントとしてのデプロイなどが含まれます。
お客さまは Amazon SageMaker、Amazon Athena、Amazon Redshift、Amazon S3 Tables のコンソールページから直接開始でき、既存のツールやデータから SageMaker Unified Studio のシンプルなエクスペリエンスへ迅速に移行できます。「Get started」をクリックして IAM ロールを指定すると、SageMaker が特定のポリシー更新を促し、SageMaker Unified Studio にプロジェクトを自動的に作成します。プロジェクトには AWS Glue Data Catalog、AWS Lake Formation、Amazon S3 の既存の全てのデータ権限が設定され、ノートブックとサーバーレスコンピューティングが事前設定されているため、初回利用を迅速化できます。
既存データセットのワンクリックオンボーディングは、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド)、欧州 (フランクフルト)、アジアパシフィック (ムンバイ)、アジアパシフィック (東京)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー) で利用可能です。

Amazon SageMaker が、組み込みAIエージェントを備えたノートブックを発表、東京など9つのリージョンで利用可能に
Amazon SageMaker は、データおよびAIチーム向けに、分析と機械学習 (ML) ジョブのための高性能なサーバーレスプログラミング環境を提供する新しいノートブック体験を導入しました。これにより、お客さまはデータ処理インフラを事前にプロビジョニングすることなく、迅速にデータ作業を開始できます。
新しいノートブックでは、データエンジニア、アナリスト、データサイエンティストが、SQLクエリの実行、Pythonコードの実行、大規模データジョブの処理、MLワークロードの実行、可視化の作成を1か所で行えます。組み込みのAIエージェントは、自然言語プロンプトからコードやSQL文を生成して開発を加速させ、ユーザーのタスクをガイドします。このノートブックは Amazon Athena for Apache Spark を利用しており、インタラクティブなSQLクエリからペタバイト規模のデータ処理まで高性能な結果を提供します。
この機能は Amazon SageMaker Unified Studio の新しいワンクリックオンボーディング体験で利用でき、1つのインタラクティブなワークスペース内でSQL、Python、自然言語を柔軟に組み合わせることが可能です。これにより、ワークロードに応じて異なるツールを切り替える必要がなくなります。例えば、SQLクエリでデータ探索を開始し、Pythonで高度な分析やMLモデルの構築を行ったり、組み込みのAIエージェントを使用して自然言語プロンプトからコードを自動生成したりできます。
SageMaker のノートブック機能は、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド)、欧州 (フランクフルト)、アジアパシフィック (ムンバイ)、アジアパシフィック (東京)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー) の各リージョンで利用できます。

Amazon SageMaker が、分析および AI/ML 開発向けの SageMaker Data Agent を導入
Amazon SageMaker は、データ分析および機械学習 (ML) アプリケーションの開発を加速する組み込み AI エージェント、SageMaker Data Agent を導入しました。このエージェントは Amazon SageMaker Unified Studio の新しいノートブックエクスペリエンスで利用でき、データエンジニア、アナリスト、データサイエンティストが手動のセットアップタスクや定型コードに費やす時間を削減します。
エージェントは自然言語のプロンプトからコードと実行計画を生成し、データカタログやビジネスメタデータと統合して開発プロセスを効率化します。お客さまが自然言語で目的を記述すると、エージェントは複雑な分析や ML タスクを管理可能なステップに分解し、詳細な実行計画と必要な SQL および Python コードを生成します。また、利用可能なデータソースやカタログ情報など、ノートブックのコンテキストを認識することで、データ変換、統計分析、モデル開発といった一般的なタスクを加速します。
Amazon SageMaker Data Agent は、US East (Ohio)、US East (N. Virginia)、US West (Oregon)、Europe (Ireland)、Europe (Frankfurt)、Asia Pacific (Mumbai)、アジアパシフィック (東京)、Asia Pacific (Singapore)、Asia Pacific (Sydney) で利用可能です。

Amazon SageMaker Unified Studio が企業アイデンティティーによる長時間実行セッションをサポート
Amazon SageMaker Unified Studio は、AWS IAM Identity Center の信頼できるアイデンティティー伝播 (TIP) 機能を通じて、企業アイデンティティーを使用した長時間実行セッションをサポートするようになりました。この特長により、データサイエンティスト、データエンジニア、分析の専門家は、ワークフローを中断することなく継続でき、生産性を向上させることができます。
ユーザーは Amazon SageMaker Unified Studio からインタラクティブなノートブックや、Amazon EMR (EC2, EKS, Serverless) および AWS Glue のデータ処理セッションを開始できます。これらのセッションは、ログオフしたりセッションの有効期限が切れたりした場合でも、企業の認証情報を使用してバックグラウンドで実行され続けます。この機能により、リソースを大量に消費する複雑なデータ処理セッションや探索的分析フローを開始し、進行を中断することなくワークステーションから離れることが可能になります。
セッションは、IAM Identity Center の信頼できるアイデンティティー伝播を通じて企業アイデンティティーのアクセス許可を自動的に維持し、実行全体にわたって一貫したセキュリティとアクセス制御を保証します。ネットワークの切断、ノートPCのシャットダウン、認証情報のリフレッシュサイクルが発生してもジョブは持続するため、数時間から数日にわたるワークフローを開始できます。セッションは最大90日間（デフォルトは7日間）実行可能です。これにより、長時間実行プロセスの監視に伴う生産性のボトルネックが解消され、データチーム全体でより効率的なリソース活用が可能になります。
長時間実行セッションは、SageMaker Unified Studio が利用可能な全てのリージョンで利用できます。


Amazon SageMaker Unified Studio が SSO 機能に対応した EMR on EKS をサポート
Amazon SageMaker Unified Studio で、インタラクティブな Apache Spark セッションのコンピューティングリソースとして EMR on EKS がサポートされるようになりました。これにより、自動スケーリングによる大規模分散コンピューティング、コスト最適化、コンテナ化されたワークロードの分離といった EMR on EKS の機能が、Amazon SageMaker Unified Studio 内で直接利用できるようになります。お客さまは、プラットフォーム間でワークロードを移動することなく、インタラクティブな分析と本番レベルのデータ処理ジョブを切り替えることができます。
この機能に基づき、Amazon SageMaker Unified Studio の EMR on EKS は、AWS Identity Center の信頼できるアイデンティティー伝播を通じて、コーポレートアイデンティティーをサポートするようになりました。これにより、EMR on EKS クラスターでのインタラクティブな分析セッションにおいて、シームレスなシングルサインオンとエンドツーエンドのデータアクセスのトレーサビリティーが可能になります。データ実務者は、SageMaker Unified Studio の JupyterLab 環境からコーポレート認証情報を使用して Glue Data Catalog リソースにアクセスでき、管理者はきめ細かいアクセスコントロールと監査証跡を維持できます。この統合により、セキュリティガバナンスが簡素化され、エンタープライズデータワークフローのコンプライアンスが合理化されます。
Amazon SageMaker Unified Studio での EMR on EKS コンピューティングサポートは、既存の全ての SageMaker Unified Studio リージョンで利用できます。

Amazon SageMaker HyperPod が IDE と Notebook の実行をサポート
Amazon SageMaker HyperPod が IDE と Notebook をサポートするようになりました。AI 開発者は JupyterLab や Code Editor を実行したり、ローカル IDE を接続したりして、インタラクティブな AI ワークロードを HyperPod クラスター上で直接実行できます。
AI 開発者は、トレーニングや推論に使用されるのと同じ永続的な HyperPod EKS クラスター上で IDE やノートブックを実行できます。
これにより、開発者は HyperPod CLI のような使い慣れたツールで HyperPod のスケーラブルな GPU 容量を活用しながら、FSx や EFS などのマウントされたファイルシステムを介して IDE とトレーニングジョブ間でデータを共有できます。
管理者は HyperPod Task Governance を使用して、IDE、トレーニング、推論のワークロード全体で統一されたガバナンスを行い、CPU/GPU への投資を最大化できます。
HyperPod Observability は、CPU、GPU、メモリ消費量などの使用状況メトリクスを提供し、コスト効率の高いクラスター利用を可能にします。
この機能は、中国および GovCloud (米国) リージョンを除く、Amazon SageMaker HyperPod が現在利用可能な全ての AWS リージョンで利用可能です。

Amazon SageMaker Catalog が列レベルのメタデータフォームとリッチテキスト記述を導入
Amazon SageMaker Catalog は、列レベルでカスタムメタデータフォームとリッチテキスト記述をサポートするようになり、ビジネス名、説明、用語集の分類に関する既存のキュレーション機能が拡張されました。
データスチュワードは、カスタムメタデータフォームを作成して、ビジネス固有の情報を個々の列に直接キャプチャーできます。列は、包括的なデータドキュメントとビジネスコンテキストのために、Markdown 対応のリッチテキスト記述もサポートします。この機能強化により、組織は、お客さまが定義したメタデータスキーマとフォーマットされたドキュメントを使用して、包括的なビジネスコンテキストを持つ列をキュレーションできます。
アセット所有者は、カスタムのキーと値のメタデータフォームとリッチテキスト記述を定義して、エンタープライズチーム全体でのデータ検出を向上させる詳細な列ドキュメントを提供できます。カスタムメタデータフォームのフィールド値とリッチテキストコンテンツはリアルタイムでインデックス付けされ、検索ですぐに検出可能になります。データアナリストは、既存の列名、説明、用語集の用語に加えて、カスタムフォームのフィールド値とリッチテキストコンテンツを使用して検索できます。
この機能は、Amazon SageMaker がサポートされている全ての AWS リージョンで利用可能です。

Amazon SageMaker Catalog が、アセット公開時の用語に対するメタデータルールの強制を可能に
Amazon SageMaker Catalog が、用語集のメタデータ強制ルールをサポートしました。これにより、管理者はデータアセットの公開時に、承認されたビジネス用語の適用を必須にできます。データ作成者は、公開前に組織の用語集から承認されたビジネス用語でアセットを分類する必要があり、強制ルールによって適切なビジネスコンテキストなしでの公開が防止されます。この機能は、一貫したデータ分類とメタデータ標準を保証し、組織全体のカタログにおける発見可能性を向上させます。
メタデータを標準化し、技術的なデータスキーマをビジネス言語と連携させることで、データガバナンスが強化され、検索の関連性が向上し、ビジネスユーザーは公開されたデータアセットをより簡単に理解し、信頼できるようになります。
用語集のメタデータ強制ルールは、Amazon SageMaker Catalog が利用可能な全ての AWS リージョンで利用できます。

Amazon Q Developer が強化されたコスト管理機能を発表
Amazon Q Developer はコスト管理機能を強化し、お客さまはより広範なクラウド財務管理ドメインにわたって、より高度な分析機能でコストを分析できるようになりました。過去および予測のコストと使用量、最適化の推奨事項、コミットメントカバレッジと使用率、コストの異常、予算、無料利用枠の使用状況、製品属性、コスト見積もりについて、複雑で自由形式の質問が可能です。
Q はデータを探索し、仮説を立て、計算を実行することで、より少ない時間と専門知識でより深い洞察を提供します。これらの機能により、FinOps 担当者、エンジニア、財務専門家は、より多くのコスト分析と見積もりタスクを Q に委任して生産性を向上させることができます。
例えば、「先週、このアプリケーションのコストが増加したのはなぜですか？」といった質問に対し、Q はサービス、アカウント、リソースごとのコストと使用量を取得してデータを探索し、仮説を立て、複数のソースからデータを収集し、単純な期間比較のコスト変動からインスタンス時間当たりの実効コストのようなユニットエコノミクスメトリクスに至るまで、さまざまな計算を実行します。また、Q はデータ取得に使用した各 API 呼び出しとパラメーターの透明性を確保し、お客さまがデータを確認したり、さらに深く掘り下げたりできる対応コンソールリンクも提供します。

Amazon Polly の生成系 TTS エンジンが、対応言語を追加し、東京など 3 つの追加リージョンをサポート
オーストリアドイツ語 (Hannah)、アイルランド英語 (Niamh)、ブラジルポルトガル語 (Camila)、ベルギーオランダ語 (Lisa)、韓国語 (Seoyeon) の5つの表現力豊かな Amazon Polly の生成系音声が一般提供開始されました。このリリースは10月に発表されたオランダ語 (Laura) の生成系音声に続くもので、これにより生成エンジンが提供する音声は20のロケールで合計31種類になります。
さらに、生成エンジンは、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (東京) の3つの新しいリージョンに拡大されました。Amazon Polly は、テキストをリアルな音声に変換するフルマネージドサービスで、開発者やビルダーがアプリケーションで対話型AIや音声コンテンツ作成を可能にします。
新規および既存の全ての生成系音声は、米国東部 (バージニア北部)、欧州 (フランクフルト)、米国西部 (オレゴン)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (東京) リージョンで利用可能です。

Amazon Lex が「待機と続行」機能を10種類の新しい言語でサポート
Amazon Lex は、新たに中国語、日本語、韓国語、広東語、スペイン語、フランス語、イタリア語、ポルトガル語、カタロニア語、ドイツ語の10言語で「待機と続行」機能をサポートし、より自然な会話体験を可能にします。
この機能により、決定論的な音声ボットとチャットボットは、お客さまが追加情報を収集している間は一時停止し、準備ができたらシームレスに再開できます。例えば、支払い詳細を尋ねられたお客さまが、クレジットカードを取り出すために「ちょっと待ってください」と言うと、ボットは続行する前に待機します。
この機能は、Amazon Lex が利用可能な全ての AWS Regions で利用できます。

Amazon Bedrock が Priority および Flex 推論サービスティアを導入
Amazon Bedrock に、さまざまなAIワークロードのコストとパフォーマンスを最適化するための2つの新しい推論サービスティア、Flex と Priority が導入されました。これらは、信頼性の高いパフォーマンスを提供する既存の Standard ティアに加わるものです。
新しい Flex ティアは、モデル評価やコンテンツ要約など、時間に厳密でないアプリケーション向けにコスト効率の高い価格設定を提供します。一方、Priority ティアはミッションクリティカルなアプリケーション向けにプレミアムなパフォーマンスと優先的な処理を提供します。Priority ティアをサポートするほとんどのモデルでは、お客さまは Standard ティアと比較して最大25%優れた OTPS（1秒当たりの出力トークン数）レイテンシーを実現できます。
これらのサービスティアは、組織が AI を大規模に展開する際に直面する主要な課題に対応します。
・Flex ティアは、より長いレイテンシーを許容できる非対話型のワークロード向けに設計されており、モデル評価、コンテンツ要約、ラベリングと注釈付け、複数ステップのエージェントワークフローに最適です。Standard ティアに比べて割引価格で提供され、高需要時にはリクエストの優先度が低くなります。
・Priority ティアは、一貫した高速応答が不可欠なミッションクリティカルなアプリケーション、リアルタイムのエンドユーザーとの対話、インタラクティブなエクスペリエンスに最適です。高需要時には、プレミアム価格でほかのサービスティアよりも優先的に処理されます。
これらの新しいサービスティアは、OpenAI (gpt-oss-20b, gpt-oss-120b)、DeepSeek (DeepSeek V3.1)、Qwen3 (Coder-480B-A35B-Instruct, Coder-30B-A3B-Instruct, 32B dense, Qwen3-235B-A22B-2507)、Amazon Nova (Nova Pro および Nova Premier) を含む、主要な基盤モデルで利用可能です。
この新しいオプションにより、お客さまはコスト効率とパフォーマンス要件のバランスをより細かく制御でき、最も重要なアプリケーションで最適なユーザーエクスペリエンスを確保しながら、AIワークロードを経済的に拡張できます。

Amazon Bedrock Guardrails がコーディングのユースケースをサポート
Amazon Bedrock Guardrails の機能が拡張され、コード関連のユースケースに対応しました。これにより、お客さまは生成系AIアプリケーションの構築中に、コード内の有害なコンテンツから保護できます。
この新機能により、お客さまは Bedrock Guardrails が提供する既存の保護機能（コンテンツフィルター、拒否トピック、機密情報フィルター）を活用して、悪意のあるコードの注入意図の検出、プロンプト漏えいの検出と防止、コード内への個人を特定できる情報 (PII) の混入防止が可能になります。サポートが拡張されたことで、Amazon Bedrock Guardrails は、コメント、変数名、関数名、文字列リテラルなどのコード要素内に含まれる有害なコンテンツに対する保護機能を提供します。
Bedrock Guardrails のコンテンツフィルター（標準ティア）は、テキストやイメージコンテンツの保護と同様の方法で、コード内の有害コンテンツを検出・フィルターリングします。また、標準ティアのプロンプト漏えい検出により保護が強化され、知的財産を侵害する可能性のある、モデル応答内のシステムプロンプトからの意図しない情報開示の検出と防止を支援します。さらに、Bedrock Guardrails の拒否トピック（標準ティア）と機密情報フィルターは、トピック内のコードを利用した脆弱性からの保護や、コード構造内への PII の混入防止に役立ちます。
このコード関連ケース向けの拡張機能は、Amazon Bedrock Guardrails がサポートされている全ての AWS リージョンで利用でき、お客さまは Amazon Bedrock コンソールおよびサポートされている API を通じてサービスにアクセスできます。

Amazon Bedrock Data Automation が音声分析で10の追加言語をサポート
Amazon Bedrock Data Automation (BDA) は、音声分析ワークロードにおいて、既存の英語に加えて、ポルトガル語、フランス語、イタリア語、スペイン語、ドイツ語、中国語、広東語、台湾語、韓国語、日本語の10言語を新たにサポートするようになりました。BDA は Amazon Bedrock の機能で、ドキュメント、イメージ、音声、動画などの非構造化マルチモーダルコンテンツから、生成AIを活用したアプリケーション向けのインサイト生成を自動化します。
今回のアップデートにより、お客さまはこれらの新しい10言語の音声を処理し、検出された言語での文字起こしや、検出された言語または英語での要約といった生成AIによるインサイトを取得できます。さらに、音声ファイルに複数の言語が含まれている場合、BDA はサポートされている全ての言語を自動的に検出し、多言語の文字起こしを作成します。これにより、お客さまとの通話、教育セッション、公共安全に関する通話、臨床での議論、会議など、多言語での会話からインサイトを簡単に抽出できるようになります。例えば、グローバルなソフトウェア企業の営業スーパーバイザーは、多言語の音声会話を分析し、カスタム出力によって提供されるインサイトを活用することで、営業担当者の改善点を特定できます。
音声分析におけるこれら10の新しい言語に対する BDA のサポートは、US West (Oregon)、US East (N. Virginia)、GovCloud (US-West)、Europe (Frankfurt)、Europe (London)、Europe (Ireland)、アジアパシフィック (Mumbai)、アジアパシフィック (Sydney) を含む8つの AWS リージョンで利用可能です。

Amazon Bedrock Data Automation が同期画像処理をサポート
Amazon Bedrock Data Automation (BDA) は、画像向けの同期API処理をサポートするようになり、視覚コンテンツから構造化されたインサイトを低レイテンシーで受け取れるようになりました。画像向けの同期処理は既存の非同期APIを補完し、アプリケーションのレイテンシー要件に基づいて適切なアプローチを柔軟に選択できます。BDA は、GenAI を活用したアプリケーション向けに、ドキュメント、画像、音声、動画などの非構造化マルチモーダルコンテンツからのインサイト生成を自動化します。
同期画像処理により、ユーザーがアップロードした写真をモデレートするソーシャルメディアプラットフォーム、お客さまの画像から商品を特定するeコマースアプリ、ランドマークを認識してコンテキスト情報を提供する旅行アプリケーションなど、インタラクティブな体験を構築できます。これにより、ポーリングやコールバックの処理が不要になり、アプリケーションアーキテクチャーが簡素化され、開発の複雑さが軽減されます。
同期処理は、要約やテキスト抽出などの一般的な画像分析タスク向けの Standard Output と、業界固有のフィールド抽出に Blueprints を使用する Custom Output の両方をサポートします。これにより、応答性の高いユーザーエクスペリエンスを実現する低レイテンシーの応答時間で、BDA に期待される高品質で構造化された結果を得られます。
Amazon Bedrock Data Automation は、ヨーロッパ (フランクフルト)、ヨーロッパ (ロンドン)、ヨーロッパ (アイルランド)、アジアパシフィック (ムンバイ)、アジアパシフィック (シドニー)、米国西部 (オレゴン)、米国東部 (バージニア北部)、AWS GovCloud (米国西部) の8つのAWSリージョンで利用可能です。

Amazon Bedrock Custom Model Import が OpenAI GPT OSS モデルをサポート
Amazon Bedrock Custom Model Import が Open AI GPT OSS モデルをサポートするようになりました。gpt-oss-120b および gpt-oss-20b モデルのカスタムウエートをインポートできます。これにより、カスタマイズした GPT OSS モデルを Amazon Bedrock に持ち込み、インフラやモデルサービングを管理することなく、フルマネージドのサーバーレス環境にデプロイできます。
GPT OSS モデルは、推論、エージェント、開発者タスク向けに設計されたテキストからテキストへのモデルです。大規模な gpt-oss-120b モデルは本番環境、汎用、高度な推論のユースケースに最適化されており、小規模な gpt-oss-20b モデルは低レイテンシーや、データ処理、ドメイン固有の要約などの特化したユースケースに最適です。
GPT OSS モデル向けの Amazon Bedrock Custom Model Import は、US-East (N. Virginia) AWS リージョンで一般提供が開始されました。

AWS HealthImaging がネーティブな JPEG 2000 Lossless をサポート
AWS HealthImaging は、可逆医療画像の保存と取得のための転送構文として JPEG 2000 Lossless の提供を開始しました。これにより、JPEG 2000 Lossless でエンコードされた DICOM データを必要とするアプリケーションと HealthImaging との統合がより簡単になります。
お客さまは、可逆 DICOM データを保存する際に、JPEG 2000 Lossless と High-throughput JPEG 2000 (HTJ2K) から選択できるようになりました。JPEG 2000 Lossless 圧縮を有効にした HealthImaging データストアは、レガシーアプリケーションとの統合が容易になり、クラウドからの低レイテンシーな画像取得パフォーマンスを実現します。
取得時のトランスコーディングによるレイテンシーなしで、画像フレームを JPEG 2000 Lossless (1.2.840.10008.1.2.4.90) 形式で取得できます。
JPEG 2000 Lossless のサポートは、AWS HealthImaging が一般提供されている米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シドニー)、欧州 (アイルランド) の各 AWS リージョンで利用可能です。

管理とガバナンス

タグポリシーを使用して、CloudFormation、Terraform、Pulumi で必須タグを検証および強制
AWS Organizations Tag Policies は、Reporting for Required Tags を発表しました。これは、お客さまの CloudFormation、Terraform、Pulumi のデプロイにビジネス上重要な必須タグが含まれていることをプロアクティブに保証する新しい検証チェックです。
Infrastructure-as-Code (IaC) 操作をタグポリシーに対して自動的に検証し、AWS 環境全体でタグ付けの一貫性を確保できます。タグポリシーで必須のタグキーを指定し、IaC デプロイメントの ガードレール を強制することが可能です。例えば、IaC テンプレート内の全ての EC2 インスタンスに `Environment`、`Owner`、`Application` を必須タグキーとして定義できます。
検証を開始するには、CloudFormation で `AWS::TagPolicies::TaggingComplianceValidator` Hook を有効化するか、Terraform プランに検証ロジックを追加するか、Pulumi で aws-organizations-tag-policies 事前構築済みポリシーパックを有効化します。設定が完了すると、ターゲットアカウント内の全ての CloudFormation、Terraform、Pulumi デプロイメントは、タグポリシーに対して自動的に検証および強制されます。
この機能は、AWS Organizations Tag Policies が利用可能な AWS リージョンで、AWS マネジメントコンソール、AWS Command Line Interface、AWS Software Development Kit を通じて利用できます。

CloudWatch Database Insights がクロスアカウントおよびクロスリージョンでの監視をサポート
Amazon CloudWatch Database Insights が、クロスアカウントおよびクロスリージョンでのデータベースフリート監視をサポートし、AWS データベースインフラストラクチャー全体の一元的な可観測性 を実現します。この機能強化により、DevOps エンジニアやデータベース管理者は、複数の AWS アカウントやリージョンにまたがるデータベースを、単一の統合コンソールから監視、トラブルシュート、最適化できます。チームは、フリート全体のパフォーマンス問題を関連付け、インシデント対応ワークフローを合理化し、複雑なマルチアカウントアーキテクチャー全体で一貫した監視基準を維持できるようになり、運用上のオーバーヘッドを大幅に削減して平均解決時間を短縮できます。この機能は、CloudWatch Database Insights がサポートされている全ての AWS 商用リージョンで利用できます。

Amazon CloudWatch の Application map がインストルメンテーションされていないサービスの検出をサポート
Amazon CloudWatch の Application map が、インストルメンテーションされていないサービスの検出、クロスアカウントビュー、変更履歴をサポートするようになり、SRE および DevOps チームによる大規模分散アプリケーションの監視とトラブルシュートを支援します。Application map は、Application Signals でインストルメンテーションされていないサービスを検出して可視化し、分散環境ですぐに利用できる可観測性を提供します。さらに、複数の AWS アカウントに分散しているアプリケーション、サービス、インフラストラクチャーを単一の統合ビューで提供し、エンドツーエンドの可視性を実現します。また、最近の変更履歴を提供することで、チームは変更が発生したタイミングと、それがアプリケーションの健全性やパフォーマンスの変化とどのように関連しているかを迅速に把握できます。
これらの機能強化により、SRE および DevOps チームは、大規模な分散環境で問題をより迅速にトラブルシュートし、自信を持って運用できるようになります。例えば、レイテンシーやエラー率が急上昇した場合、開発者は単一のマップから最近の設定変更を調査し、複数の AWS アカウントにまたがる依存関係を分析できるようになりました。インシデント後のレビューでは、チームは変更履歴データを使用して何がいつ変更されたかを把握し、長期的な信頼性を向上させることができます。サービス検出、依存関係マッピング、変更履歴を統合することで、Application map は平均解決時間 (MTTR) を短縮し、チームが複雑なシステム全体でアプリケーションの健全性を維持するのに役立ちます。
Application Map の新機能は、全ての AWS 商用リージョン (台北とニュージーランドを除く) で追加費用なしで利用できます。

Amazon CloudWatch が Logs Insights でのスケジュールされたクエリをサポートし、東京、大阪など17のリージョンで利用可能に
Amazon CloudWatch Logs は、ログ分析のために Logs Insights クエリを定期的なスケジュールで自動実行する機能をサポートするようになりました。
スケジュールされたクエリを使用すると、ログ分析タスクを自動化し、クエリ結果を Amazon S3 および Amazon EventBridge に配信できます。これにより、クエリを手動で再実行したりカスタムの自動化を維持したりすることなく、トレンドの追跡、主要な運用メトリクスの監視、異常の検出が可能になります。この機能は、アプリケーションとインフラの継続的な可視性を維持し、運用ワークフローを合理化することで、運用効率を向上させます。例えば、週次の監査リポート用にクエリを設定し、その結果を Amazon S3 に保存して分析したり、Amazon EventBridge を通じてインシデント対応ワークフローをトリガーしたりできます。
この機能は全ての CloudWatch Logs Insights クエリ言語をサポートしており、Amazon CloudWatch コンソール、AWS Command Line Interface (AWS CLI)、AWS Cloud Development Kit (AWS CDK)、および AWS SDK を使用して設定できます。
スケジュールされたクエリは、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ)、アジアパシフィック (大阪)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、ヨーロッパ (フランクフルト)、ヨーロッパ (アイルランド)、ヨーロッパ (ロンドン)、ヨーロッパ (パリ)、ヨーロッパ (ストックホルム)、南米 (サンパウロ) で利用可能です。

Amazon CloudWatch が EC2 上のエージェントをコンソール内で管理する機能を導入
Amazon CloudWatch は、EC2 インスタンス上の Amazon CloudWatch エージェントの自動インストールと設定のためのコンソール内エクスペリエンスを提供するようになりました。Amazon CloudWatch エージェントは、開発者や SRE が EC2 からインフラストラクチャーとアプリケーションのメトリクス、ログ、トレースを収集し、CloudWatch と AWS X-Ray に送信するために使用されます。
この新しいエクスペリエンスでは、EC2 フリート全体のエージェントステータスを可視化し、サポートされているワークロードの自動検出を行い、CloudWatch の可観測性 ソリューションを活用して、検出されたワークロードに基づいたモニターリング設定を推奨します。お客さまは、個々のインスタンスへのワンクリックインストール、またはフリート全体の自動管理のためのタグベースのポリシーを作成することで、CloudWatch エージェントをデプロイできるようになりました。自動化ポリシーにより、auto-scaling によって作成されたインスタンスを含む、新しく起動されたインスタンスが、適切なモニターリング設定で自動的に構成されるようになります。
エージェントのデプロイを簡素化し、インテリジェントな設定推奨を提供することで、お客さまは環境全体で一貫したモニターリングを確保しつつ、セットアップ時間を数時間から数分に短縮できます。
Amazon CloudWatch エージェントは、ヨーロッパ (ストックホルム)、アジアパシフィック (ムンバイ)、ヨーロッパ (パリ)、米国東部 (オハイオ)、ヨーロッパ (アイルランド)、ヨーロッパ (フランクフルト)、南米 (サンパウロ)、米国東部 (バージニア北部)、アジアパシフィック (ソウル)、アジアパシフィック (東京)、米国西部 (オレゴン)、米国西部 (北カリフォルニア)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、カナダ (中部) の AWS リージョンで利用できます。

Amazon CloudWatch RUM が iOS および Android アプリケーションをサポート
Amazon CloudWatch RUM が iOS および Android アプリケーションをサポートし、リアルユーザーモニターリングがWebアプリケーション以外にも拡大されました。開発者と SRE は、画面の読み込み時間、クラッシュ率、API レイテンシーなどのパフォーマンスメトリクスを可視化することで、モバイルアプリケーションの問題を迅速に特定し、エンドユーザーエクスペリエンスを向上させることができます。
モバイル向けの CloudWatch RUM は、OpenTelemetry (OTEL) 標準を使用してスパンとイベントを送信します。このサービスは、アプリケーションの起動時間、画面の読み込み時間、バックエンドのネットワークコールなどのモバイルスパンをキャプチャーします。また、クラッシュや ANRs/AppHangs などのイベントもキャプチャーし、CloudWatch コンソールで豊富なトラブルシューティングのインサイトを提供します。
特定のエラーやクラッシュの影響分析、関連するテレメトリーへのドリルダウン、場所、デバイスタイプ、OS、アプリのバージョンによるフィルターリングを行い、根本原因を迅速に特定できます。モバイルテレメトリーは、CloudWatch Application Signals のアプリケーションメトリクス、トレース、ログ、Web RUM モニターリング、合成モニターリングと統合され、トラブルシュートを迅速化し、アプリケーションの中断を削減します。
iOS と Android 向けの CloudWatch RUM サポートは、Webモニターリングが利用可能な全ての AWS 商用リージョンで利用できます。

Amazon CloudWatch Container Insights が、Amazon EKS 向けに1分未満の GPU メトリクスをサポート
Amazon CloudWatch Container Insights は、Amazon EKS 上で実行される AI および ML ワークロード向けに、1分未満の頻度での GPU メトリクス収集をサポートするようになりました。お客さまはメトリクスのサンプルレートを秒単位で設定でき、GPU リソース使用率をよりきめ細かくモニターリングできます。
この機能強化により、短時間 GPU リソースを消費する ML 推論ジョブなど、60秒未満で実行される GPU 集中型ワークロードを効果的にモニターリングできます。サンプリング頻度を上げることで、お客さまは短時間の GPU ワークロードに対する詳細な可視性を維持できます。1分未満の GPU メトリクスは1分に1回 CloudWatch に送信されます。このきめ細かいモニターリングは、お客さまが GPU リソース使用率を最適化し、パフォーマンスの問題をトラブルシュートし、コンテナ化された GPU アプリケーションの効率的な運用を確保するのに役立ちます。
Container Insights の1分未満の GPU メトリクスは、全ての AWS Commercial Regions と AWS GovCloud (US) Regions で、追加費用なしで利用可能です。

Amazon CloudWatch Container Insights が Amazon EKS 上の Neuron UltraServers をサポート
Amazon CloudWatch Container Insights が Amazon EKS 上の Neuron UltraServers をサポートするようになり、マルチインスタンスノードで大規模かつ高性能な機械学習ワークロードを実行するお客さまの可観測性 が向上しました。この新機能により、データサイエンティストや ML エンジニアは、集約されたメトリクスと簡素化された管理を通じて、コンテナ化された ML アプリケーションを効率的に監視および トラブルシュート できます。
Neuron UltraServers は、AWS Trainium および Inferentia アクセラレータを使用して機械学習ワークロードに最適化された、複数の EC2 インスタンスを結合した単一の論理サーバーユニットです。今回のアップデートにより、Container Insights に EKS 環境の UltraServers 専用の新しいフィルターが導入されました。UltraServer ID を選択すると、サーバー内の全インスタンスにわたる新しい集計メトリクスを表示でき、個々のインスタンスを個別に監視する必要がなくなります。インスタンスごとのメトリクスに加えて、UltraServer グループ全体の統合されたパフォーマンスデータを表示できるため、AWS Neuron で実行される ML ワークロードの監視が効率化されます。
Amazon CloudWatch Container Insights は、全ての商用 AWS リージョンおよび AWS GovCloud (US) で利用可能です。

Amazon CloudWatch Application Signals が GitHub Action と MCP サーバーの改善を追加
新しい GitHub Action と CloudWatch Application Signals MCP サーバーの改善が一般提供されました。これにより、アプリケーションの可観測性が開発者ツールに導入され、問題のトラブルシュートがより迅速かつ便利になります。
これまで、開発者は本番環境の問題をトリアージし、トレースデータを検索し、可観測性のカバレッジを確保するために GitHub を離れる必要があり、コンソール、ダッシュボード、ソースコードを頻繁に切り替えていました。Application observability for AWS GitHub Action は、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 ベースのアプリケーションパフォーマンスモニターリングを設定するのを支援できます。
これらの機能を組み合わせることで、可観測性が開発ワークフローに導入され、コンテキストの切り替えが減り、コードから本番環境までのインテリジェントなエージェント支援によるデバッグが可能になります。

AWS Organizations が組織間の直接アカウント移行を導入
AWS Organizations で、アカウントを現在の組織から削除することなく、直接別の組織に移行できるようになりました。この新機能により、進行中のオペレーションや買収統合プロジェクトの一環であっても、組織間のアカウント移行プロセスが効率化されます。
組織間でアカウントを直接移行できるようになったことで、アカウントを一時的にスタンドアロンアカウントとして運用するという従来の要件が不要になりました。このスタンドアロンのステップがなくなったことで、お客さまは移行の一環としてアカウントの支払い方法、連絡先情報、サポートプランを手動で設定する必要がなくなります。また、アカウントを直接移行することで、移行プロセスの前後で、アカウントが所属する AWS 組織のガバナンス機能や一括請求のメリットへのアクセスを維持できます。
更新されたプロセスはよりシンプルになり、従来と同じ AWS Organizations のコンソールエクスペリエンスと API を使用します。具体的には、組織がアカウントを招待し、アカウントがその招待を承諾する流れです。
組織間のアカウント直接移行は、全ての商用 AWS リージョンおよび AWS GovCloud (US) リージョンで利用可能です。

AWS Organizations が Amazon Aurora と Amazon RDS 向けのアップグレードロールアウトポリシーをサポート
AWS Organizations は、アップグレードロールアウトポリシーのサポートを発表しました。これは、Amazon Aurora (MySQL 互換エディションおよび PostgreSQL 互換エディション) と Amazon Relational Database Service (Amazon RDS) (RDS for MySQL、RDS for PostgreSQL、RDS for MariaDB、RDS for SQL Server、RDS for Oracle、RDS for Db2 を含む) のデータベース全体で、自動アップグレードを段階的に実行できる新機能です。
この機能により、数百のリソースやアカウントにまたがる自動マイナーバージョンアップグレードを手動またはカスタムツールで調整する運用上のオーバーヘッドがなくなります。また、本番環境に展開する前に、まず重要度の低い環境でアップグレードをテストできるため、お客さまは安心して利用できます。
アップグレードロールアウトポリシーを使用すると、アカウントレベルのポリシーまたはリソースタグを通じて適用される簡単な順序 (最初、2番目、最後) を使用して、アップグレードシーケンスを定義できます。新しいマイナーバージョンが自動アップグレードの対象になると、ポリシーによって開発環境からアップグレードが開始され、より重要な環境に進む前に変更を検証できます。各フェーズ間の AWS Health 通知と組み込みの検証期間により、アップグレードプロセス全体の進捗を監視し、安定性を確保できます。問題が検出された場合はいつでも自動進行を無効にでき、アップグレードの過程を完全に制御できます。
この機能は、全ての AWS 商用リージョンおよび AWS GovCloud (US) リージョンで利用でき、Amazon Aurora および Amazon RDS データベースエンジンの自動マイナーバージョンアップグレードをサポートします。アップグレードポリシーは、AWS Management Console、AWS CLI、AWS SDK、AWS CloudFormation、または AWS CDK を使用して管理できます。Amazon RDS for Oracle の場合、アップグレードロールアウトポリシーは、2026年1月以降にリリースされるエンジンバージョンの自動マイナーバージョンアップグレードをサポートします。

AWS License Manager が、ソフトウェア資産の一元管理のためのライセンス資産グループを導入
AWS License Manager は、組織内の AWS リージョンとアカウントにまたがるソフトウェア資産の一元管理を提供し、自動化されたライセンス資産グループを通じてコンプライアンスリスクを低減し、ライセンス追跡を合理化します。お客さまは、ライセンスの有効期限の追跡、監査対応の合理化、商用ソフトウェアポートフォリオの製品中心のビューによるデータに基づいた更新の意思決定が可能になります。
これにより、組織内の複数のリージョンやアカウントにまたがるライセンスを手動で追跡する必要がなくなりました。ライセンス資産グループを使用すれば、カスタマイズ可能なグループ化と自動リポート作成により、商用ソフトウェアの使用状況を組織全体で可視化できます。この新機能は、AWS License Manager が利用可能な全ての商用リージョンで利用できます。

AWS Control Tower がコントロール専用のエクスペリエンスを導入
AWS Control Tower は、AWS の マネージドコントロール を使用して環境を管理および統制する最も簡単な方法を提供します。お客さまは、Control Tower の完全なデプロイを必要とせずに、これらの AWS マネージドコントロール に直接アクセスできるようになりました。この新しいエクスペリエンスでは、750を超える マネージドコントロール が提供され、既存のアカウント構造を維持したまま数分でデプロイできます。
AWS Control Tower v4.0 では Control Catalog への直接アクセスが導入され、お客さまは利用可能な マネージドコントロール を確認し、既存の AWS Organization にデプロイできます。Control Tower は必須の構造を強制しなくなるため、組織構造に対する柔軟性と自律性が向上します。さらに、AWS Config と AWS CloudTrail の統合において S3 バケットと SNS 通知が分離されたことで、リソースと権限管理のクリーン化やコスト属性の改善など、運用が向上します。
このコントロールに焦点を当てたエクスペリエンスは、AWS Control Tower がサポートされている全ての AWS リージョンで利用可能です。

AWS Control Tower が 7 つの新しいコンプライアンスフレームワークと 279 個の追加の AWS Config ルールをサポート
AWS Control Tower は、セキュリティ、コスト、耐久性、運用などのさまざまなユースケースに対応する、279 個の追加のマネージド Config ルールを Control Catalog でサポートするようになりました。これにより、これらの追加ルールを AWS Control Tower から直接検索、発見、有効化、管理し、マルチアカウント環境のより多くのユースケースを統制できます。
また、AWS Control Tower は Control Catalog で 7 つの新しいコンプライアンスフレームワークをサポートします。既存のフレームワークに加えて、ほとんどのコントロールが ACSC-Essential-Eight-Nov-2022、ACSC-ISM-02-Mar-2023、AWS-WAF-v10、CCCS-Medium-Cloud-Control-May-2019、CIS-AWS-Benchmark-v1.2、CIS-AWS-Benchmark-v1.3、CIS-v7.1 にマッピングされるようになりました。関連するルールは、AWS Control Tower コンソールまたは ListControls、GetControl、EnableControl API を使用して直接有効にできます。
コントロール間の関係マッピングも強化され、異なるコントロールがどのように連携して機能するかを理解しやすくなりました。更新された ListControlMappings API は、コントロール間の重要な関係（相互に補完し合うか、代替であるか、相互に排他的であるか）を明らかにします。例えば、Config ルール（検出）と Service Control Policy（予防）が連携して包括的なセキュリティカバレッジを提供できる場合を、簡単に特定できるようになりました。
これらの新機能は、AWS GovCloud (US) を含む、AWS Control Tower が利用可能な AWS リージョンで利用できます。

AWS CloudTrail がセキュリティ監視を簡素化するデータイベント集約機能を追加
AWSは、企業による大規模な CloudTrail データイベントの監視と分析を簡素化する新機能、CloudTrail 集約イベントを発表しました。この機能は、ユーザーが Amazon S3 バケットや AWS Lambda 関数などのリソースにアクセスする際に毎分何千ものイベントを生成する可能性がある CloudTrail データイベントで利用できます。この特長により、セキュリティ、コンプライアンス、運用チームは、大量の個別イベントを処理することなく、高頻度のデータアクセスパターンを効率的に監視できます。
データイベントの集約は、大量の AWS API アクティビティを5分間のサマリーに統合することで、セキュリティ監視を効率化します。このサマリーでは、アクセス頻度、エラー率、最も使用されるアクションなどの主要な傾向が強調表示されるため、チームは必要なときに詳細なイベントへのアクセスを維持しながら、パターンを迅速に特定できます。セキュリティチームは、大量の CloudTrail データイベントをスキャンすることなく、「このユーザーのアクティビティは過去1週間でどのように変化したか？」や「この重要なリソースで実行されている上位のアクションは何か？」といった質問に簡単に答えることができます。
集約は、AWS コンソールまたは CLI を通じてデータイベントをキャプチャーする証跡で有効にでき、API アクティビティ、リソースアクセス、ユーザーアクティビティのサマリー用に事前構築された集約テンプレートから選択できます。集約の料金は、集約を作成するために分析された CloudTrail データイベントの数に基づいて請求されます。
CloudTrail のデータ集約は、全ての商用 AWS リージョンで利用できます。

AWS CloudTrail が、データアクセスの異常を自動的に検出するデータイベント向け Insights を開始
AWS CloudTrail Insights がデータイベントに対応しました。CloudTrail Insights は、AWS アカウントにおける API コールレートや API エラーレートに関連する異常なアクティビティの特定と対応に役立ちます。これまで Insights は、CloudTrail の管理イベントのみを継続的に分析していました。今回のアップデートにより、Insights はデータイベントも分析するようになり、潜在的なセキュリティや運用上の問題を迅速に調査・対応する能力が強化されます。
CloudTrail の証跡で利用可能なデータイベント用 Insights は、Amazon S3 オブジェクト削除 API コールの予期せぬ急増や AWS Lambda 関数呼び出しのエラーレート増加といった、データアクセスアクティビティの異常を自動的に検出します。これにより、検出システムを構築したり、データをサードパーティーツールにエクスポートしたりすることなく、潜在的なセキュリティや運用上の問題を迅速に発見できます。
データイベント用の CloudTrail Insights は、AWS アカウントのデータアクセスパターンの通常のベースラインを確立し、異常を検出した際に CloudTrail イベントを作成することで機能します。異常なパターンが検出されると、CloudTrail は異常期間中の関連データイベントを提供し、異常の原因を正確に調査するのに役立ちます。潜在的な問題が発生した際に自動的に通知されるようにアラートを設定でき、潜在的な脅威や問題への迅速な対応が可能になります。
データイベント用の CloudTrail Insights は、AWS CloudTrail が利用可能な全てのリージョンで利用できます。データイベント用の Insights には追加料金が適用されます。

AWS CloudFormation のドリフト対応変更セットで、設定のドリフトを安全に処理
AWS CloudFormation は、IaC テンプレートとインフラストラクチャーの実際の状態を比較し、ドリフトしたリソースをテンプレート定義に合わせることができる、ドリフト対応変更セットをリリースしました。設定のドリフトは、IaC で管理されているインフラストラクチャーが AWS マネジメントコンソール、SDK、または CLI を介して変更された場合に発生します。ドリフト対応変更セットを使用すると、ドリフトを元に戻し、インフラストラクチャーをテンプレートと同期させ続けることができます。さらに、ドリフトしたリソースへのデプロイの影響をプレビューし、予期しない変更を防ぐことが可能です。
お客さまは、運用上のインシデントをトラブルシュートする際に、IaC の外部でインフラストラクチャーを変更することがあります。これにより、将来の IaC デプロイで予期しない変更が発生するリスクが生じ、インフラストラクチャーのセキュリティ体制に影響を与え、テストや災害復旧のための再現性が損なわれます。標準の変更セットはテンプレートを最後にデプロイされたテンプレートと比較できますが、ドリフトは考慮されません。ドリフト対応変更セットは、新しいテンプレート、最後にデプロイされたテンプレート、およびインフラストラクチャーの実際の状態との間で3者間の差分を提供します。差分によって意図しないドリフトの上書きが予測される場合は、テンプレートの値を更新して変更セットを再作成できます。変更セットの実行中、CloudFormation はリソースのプロパティをテンプレートの値と照合し、IaC の外部で削除されたリソースを再作成します。プロビジョニングエラーが発生した場合、CloudFormation はデプロイ前の実際の状態にインフラストラクチャーを復元します。
利用するには、CloudFormation コンソールから既存のスタックの変更セットを作成し、変更セットの種類として「Drift-aware」を選択します。または、AWS CLI または SDK から CreateChangeSet API に `--deployment-mode REVERT_DRIFT` パラメーターを渡します。
ドリフト対応変更セットは、CloudFormation が利用可能な AWS リージョンで利用できます。

AWS CloudFormation が早期検証とトラブルシューティングの簡素化により、開発・テストサイクルを高速化
AWS CloudFormation に、リソースのプロビジョニング開始前にデプロイエラーを検出し、より効率的に解決する機能が追加されました。変更セットの作成時に、一般的なデプロイエラーに関する早期フィードバックが提供されます。スタックイベントはオペレーションIDでグループ化され、新しい `describe-operation` API を通じてアクセスできるため、デプロイエラーの分析が迅速化されます。これにより、開発者はデプロイサイクルタイムを短縮し、トラブルシュート時間を数分から数秒に短縮できます。
変更セットを作成する際、CloudFormation はテンプレートを以下の3つの一般的なエラー原因に対して検証します。
・無効なプロパティ構文
・アカウント内の既存リソースとのリソース名の競合
・削除操作時の S3 バケットが空であることの制約
検証に失敗した場合、変更セットのステータスは「FAILED」と表示され、検証失敗に関する詳細なステータスが示されます。その後、各失敗の詳細（関連するプロパティパスなど）を確認し、テンプレート内の問題箇所を正確に特定できます。
検証済みの変更セットを実行しても、リソース制限やサービス固有の制約など、リソース固有のランタイムエラーによってデプロイが失敗することがあります。ランタイムエラーのトラブルシュートのために、全てのスタック操作に一意のIDが割り当てられるようになりました。特定の操作のスタックイベントに絞り込み、デプロイ失敗の原因となったイベントをフィルターリングできます。これにより、根本原因を迅速に特定し、トラブルシュート時間を短縮できます。
利用を開始するには、CloudFormation コンソール、CLI、または SDK を通じて変更セットを作成します。オペレーションIDごとのスタックイベントは、CloudFormation コンソールの「イベント」タブまたは `describe-events` API で表示できます。

AWS CloudFormation が IDE でのインテリジェントなオーサリングによりインフラ開発を加速
AWS CloudFormation は、AWS CloudFormation Language Server の提供を開始しました。これは、AWS Toolkit を通じて統合開発環境 (IDE) にインテリジェントなオーサリング、早期検証、トラブルシュート、ドリフト管理機能を提供する新機能です。これにより、開発者はインフラストラクチャーをより迅速に構築し、安全にデプロイできます。
今回のアップデートにより、Visual Studio や Kiro などの互換 IDE を使用する開発者は、Language Server によるコンテキストを認識したオーサリング機能を利用できます。IDE 内で、組み込みのオートコンプリート、スキーマ検証、CloudFormation Guard を使用したポリシーチェック、デプロイ検証が直接提供されます。例えば、無効なリソースプロパティや不足している IAM 権限要件を即座に警告します。また、ドリフトを認識するデプロイメントビューは、テンプレートとデプロイされたインフラストラクチャーの差異を強調表示し、CloudFormation の外部で行われた設定変更の特定を支援します。
これらの機能は、デプロイ前に構文エラー、権限不足、設定の不一致といった問題を特定するのに役立ちます。検証とリアルタイムのフィードバックをオーサリング体験に直接統合することで、インフラストラクチャーのコーディングがシームレスな体験となり、安全性も向上します。この統合された体験により、開発者はコンプライアンスとベストプラクティスを維持しながら、設計からデプロイへの移行を迅速化し、トラブルシュートの時間を削減して構築により多くの時間を費やすことができます。
AWS CloudFormation Language Server は、AWS CloudFormation がサポートされている全ての AWS 商用リージョンで利用可能です。

AWS CloudFormation StackSets がデプロイ順序付けをサポート
AWS CloudFormation StackSets は、自動デプロイモードでのデプロイ順序付けを提供し、アカウントやリージョンをまたいでスタックインスタンスが自動的にデプロイされる順序を定義できるようになりました。この機能により、基盤インフラストラクチャーを依存アプリケーションコンポーネントより先にプロビジョニングする必要がある、複雑なマルチスタックデプロイを調整できます。大規模なデプロイを管理する組織は、手動での介入なしに適切なデプロイ順序を確保できるようになります。
CloudFormation StackSet の作成または更新時に、AutoDeployment 設定の新しい DependsOn パラメーターを使用して、スタックインスタンスごとに最大 10 個の依存関係を指定できます。これにより、StackSets は定義された関係に基づいてデプロイを自動的に調整します。例えば、アプリケーションスタックインスタンスが開始される前に、ネットワークおよびセキュリティスタックインスタンスのデプロイを完了させることで、依存関係の欠落によるデプロイの失敗を防ぐことができます。
StackSets には、循環依存を防ぐための組み込みのサイクル検出機能が含まれており、設定の問題解決に役立つエラーメッセージを提供します。この機能は、CloudFormation StackSets が利用可能な全ての AWS リージョンで、追加費用なしで利用できます。

メディアサービス

AWS Elemental MediaConnect が Router を発表
AWS は、放送事業者やコンテンツプロバイダーが AWS ネットワーク内のソースとデスティネーション間でライブビデオを動的にルーティングできるようにする新機能、AWS Elemental MediaConnect Router の一般提供を開始しました。この新機能は、クラウドでの複雑なライブビデオワークフローの構築・管理方法を変革し、ルーティングのニーズの変化に応じたインフラストラクチャーの再設定を不要にします。
このルーターは、プライマリフィードとバックアップフィードの切り替え、リージョンごとのバリアントの個別ルーティング、包括的なカバレッジのための複数フィードの管理といった複雑なシナリオを可能にします。MediaConnect Router は AWS ネットワーク全体でのコンテンツ配信を最適化し、標準的な転送技術と比較して転送レイテンシーを削減し、パケット配信の信頼性を向上させます。このフルマネージド機能は、サポートされている任意のリージョン内の入力と出力間、およびプライベートエンドポイントとパブリックエンドポイント間のルーティングをサポートし、運用オーバーヘッドと未使用キャパシティコストを排除します。
MediaConnect Router は、MediaConnect コンソール、MediaConnect API、または AWS CDK を通じて利用を開始でき、既存の MediaConnect フローと独立して、または並行して動作します。また、お客さまが最高品質のビデオをグローバル規模で処理、収益化、配信するのに役立つメディアサービスのファミリーである AWS Elemental を使用した、より大規模なビデオワークフローの一部としても利用できます。
MediaConnect Router は、全ての標準 AWS リージョンで利用可能です。

移行と転送

AWS Transform が Landing Zone Accelerator のネットワーク設定を自動化
AWS Transform for VMware で、Landing Zone Accelerator on AWS solution (LZA) に直接インポートできるネットワーク設定を自動生成できるようになりました。この新機能は、AWS Transform の既存の AWS CloudFormation、AWS CDK、Terraform 形式での infrastructure-as-code 生成サポートを基盤としており、VMware のネットワーク環境を LZA 互換のネットワーク設定 YAML ファイルに自動変換します。これらの YAML 設定は LZA のデプロイメントパイプラインを通じて直接デプロイでき、クラウドインフラのセットアッププロセスを効率化します。
AWS Transform for VMware は、VMware ワークロードの検出、計画、移行を自動化するエージェンティック AI サービスであり、インフラのモダナイゼーションを迅速かつ確実に加速させます。Landing Zone Accelerator on AWS solution (LZA) は、AWS のベストプラクティスを用いて、安全なマルチアカウント AWS 環境のセットアップを自動化します。
従来、AWS へのワークロード移行では、運用上およびコンプライアンス上の一貫性を維持しつつ、ネットワーク設定を手動で再作成する必要がありました。このサービスは LZA ネットワーク設定の生成を自動化し、手作業、設定ミスの可能性、デプロイ時間を削減すると同時に、エンタープライズセキュリティ基準への準拠を保証します。
LZA 設定生成機能は、このサービスが提供されている全ての AWS リージョンで利用可能です。

AWS Transfer Family のWebアプリが VPC エンドポイントをサポート
AWS Transfer Family のWebアプリが Virtual Private Cloud (VPC) エンドポイントをサポートし、追加料金なしでWebアプリへのプライベートアクセスが可能になりました。これにより、ユーザーは全てのトラフィックを VPC 内に維持しながら、Webブラウザー経由で Amazon S3 内のファイルに安全にアクセスし、管理できます。
Transfer Family のWebアプリは、Amazon S3 内のデータにアクセスするためのシンプルで安全なWebインターフェースを提供します。今回のアップデートにより、従業員ユーザーは VPC、AWS Direct Connect、または VPN 接続を介して直接接続できます。これにより、VPC で定義済みのセキュリティコントロールとネットワーク構成を活用しつつ、規制対象のドキュメントワークフローや機密データ共有など、厳格なセキュリティコントロールを必要とする社内ユースケースをサポートできます。送信元 IP アドレスに基づくセキュリティグループによるアクセス管理、NACL を介したサブネットレベルのフィルターリング、全てのファイル転送をプライベートネットワーク境界内に留めることなどが可能になり、全てのネットワークトラフィックに対する完全な可視性と制御を維持できます。
Webアプリ用の VPC エンドポイントは、一部の AWS リージョンで追加料金なしで利用できます。

AWS Transfer Family が、転送されたファイルのスキャンを自動化する Terraform モジュールを発表
AWS Transfer Family の Terraform モジュールで、Transfer Family リソースを使用して転送されたファイルの自動マルウェアスキャンワークフローのデプロイがサポートされるようになりました。このリリースにより、Amazon GuardDuty S3 Protection を使用した脅威検出ワークフローの一元的なプロビジョニングが合理化され、転送ファイル内の潜在的な脅威を特定してデータセキュリティ要件を満たすことができます。
AWS Transfer Family は、SFTP、AS2、FTPS、FTP、およびWebブラウザーベースのインターフェースを介して AWS ストレージサービスへのフルマネージドなファイル転送を提供するサービスです。新しいモジュールを使用すると、単一のデプロイで、受信ファイルのスキャン、スキャン結果に基づく動的なルーティング、脅威通知の生成といったワークフローをプログラムでプロビジョニングできます。また、特定の S3 プレフィックスに対してきめ細かく脅威検出を実装し、スキャン後もフォルダー構造を維持することで、検証済みのクリーンなファイルのみがビジネスアプリケーションやデータレイクに到達することを保証します。これにより、手動設定に伴うオーバーヘッドとリスクが排除され、データセキュリティコンプライアンスのためのスケーラブルなデプロイが可能になります。

AWS Transfer Family が、カスタムIDプロバイダーと統合するための Terraform モジュールを発表
AWS Transfer Family の Terraform モジュールが、認証とアクセス制御のためにカスタム ID プロバイダー (IdP) を使用した Transfer Family エンドポイントのデプロイをサポートするようになりました。これにより、既存の ID プロバイダーと統合された Transfer Family サーバーのデプロイを自動化および合理化できます。
AWS Transfer Family は、AWS ストレージサービス向けに、SFTP、AS2、FTPS、FTP、およびWebブラウザーベースのインターフェースを介したフルマネージドのファイル転送を提供します。この新しいモジュールを使用すると、Terraform を使ってカスタム認証システムを利用した Transfer Family サーバーリソースをプロビジョニングでき、手動設定を不要にし、ビジネスニーズに合わせて拡張可能な反復可能なデプロイを実現できます。
このモジュールは、オープンソースの Custom IdP ソリューション上に構築されており、広く使用されている ID プロバイダーとの標準化された統合を提供し、多要素認証、監査ログ、ユーザーごとの IP 許可リストなどの組み込みセキュリティ制御を含んでいます。また、Terraform モジュールには、Amazon Cognito ユーザープールを使用したエンドツーエンドの例が含まれています。

AWS DMS Schema Conversion が、生成 AI を活用して SAP (Sybase) ASE から PostgreSQL への変換をサポート
AWS Database Migration Service (DMS) Schema Conversion は、データベーススキーマを自動的に評価し、AWS のターゲットデータベースサービスと互換性のある形式に変換する、DMS のフルマネージド機能です。
Schema Conversion が Generative AI 機能を活用し、SAP Adaptive Server Enterprise (ASE) データベース (旧 Sybase) から Amazon RDS PostgreSQL および Amazon Aurora PostgreSQL への変換をサポートするようになりました。Schema Conversion を使用すると、SAP (Sybase) ASE ソースのデータベースオブジェクトを、Amazon RDS PostgreSQL および Amazon Aurora PostgreSQL ターゲットに自動的に変換できます。統合された Generative AI 機能は、ストアドプロシージャ、関数、トリガーなど、通常は手作業が必要となる複雑なコード変換をインテリジェントに処理します。
また、Schema Conversion は、移行を効果的に計画および実行するのに役立つ詳細な評価リポートも提供します。

ネットワーキングとコンテンツ配信

Network Load Balancer が重み付けターゲットグループをサポートし、デプロイを簡素化
Network Load Balancer が重み付けターゲットグループをサポートするようになり、設定可能な重みで複数のターゲットグループにトラフィックを分散することで、高度なデプロイ戦略が可能になりました。
この機能は、0から999の範囲で設定可能な重みを持つ複数のターゲットグループを登録し、トラフィック分散を正確に制御することで、Blue-Green や Canary デプロイ、アプリケーション移行、A/B テストなどの主要なユースケースを実現します。Blue-Green および Canary デプロイでは、アプリケーションのバージョン間でトラフィックを段階的に移行させ、アップグレードやパッチ適用時のダウンタイムを最小限に抑えることができます。アプリケーション移行は、本番トラフィックを中断することなく、レガシーから新しいスタックへのシームレスな移行を可能にします。A/B テストは、受信トラフィックを実験環境に分割することを容易にします。
インスタンス、IP アドレス、Application Load Balancer (ALB) ターゲットを含む、全てのターゲットグループタイプがサポートされます。
重み付けターゲットグループのルーティングは、全ての既存および新規の Network Load Balancer で、AWS 商用リージョンおよび AWS GovCloud (US) リージョンにおいて追加料金なしで利用可能です。標準の Network Load Balancer Capacity Unit (LCU) 料金が適用されます。

NAT Gateway がリージョナル可用性をサポート
Amazon Web Services (AWS) は、NAT Gateway のリージョナル可用性モードを発表しました。
今回のアップデートにより、単一の NAT Gateway を作成できるようになりました。この NAT Gateway は、ワークロードの存在に基づいて Virtual Private Cloud (VPC) 内のアベイラビリティーゾーン (AZ) 間で自動的に拡張・縮小し、高可用性を維持しながらセットアップと管理を簡素化します。
NAT Gateway は、プライベートサブネット内のインスタンスが NAT Gateway の IP アドレスを使用して VPC外のサービスに接続できるようにするものです。リージョナル可用性モードでは、NAT Gateway をホストするためのパブリックサブネットは不要です。また、ワークロードが新しいアベイラビリティーゾーンに拡張されるたびに、NAT Gateway を作成・削除したり、ルートテーブルを編集したりする必要もありません。
この機能は、Amazon が提供する IP アドレス、またはお客さま自身が持ち込んだ IP アドレスで使用できます。この機能は、AWS GovCloud (US) リージョンと中国リージョンを除く、全ての商用 AWS リージョンで利用できます。

Application Load Balancer が Target Optimizer の提供を開始
Application Load Balancer (ALB) は、ターゲットへの同時リクエストの最大数を設定できる新機能 Target Optimizer の提供を開始しました。Target Optimizer を使用すると、アプリケーションスタックを微調整して、ターゲットが処理可能なリクエスト数のみを受け取るようにできます。これにより、リクエストの成功率向上、ターゲット使用率の向上、レイテンシーの低減を実現します。この機能は、コンピューティング集約型のワークロードに特に有効です。例えば、複雑なデータ処理や推論を実行するアプリケーションの場合、各ターゲットが一度に1つのリクエストのみを受け取るように設定することで、同時リクエスト数をターゲットの処理能力に見合ったものにできます。
この機能は、ターゲットコントロールポートを持つ新しいターゲットグループを作成することで有効化できます。有効化すると、この機能は、ターゲット上で実行する AWS 提供のエージェントを介して動作し、リクエストの同時実行数を追跡します。ALB ごとに複数のターゲットグループを含むデプロイメントの場合、この機能をターゲットグループごとに個別に設定する柔軟性があります。
Target Optimizer は、AWS マネジメントコンソール、AWS CLI、AWS SDK、および AWS API を通じて有効化できます。ALB Target Optimizer は、全ての AWS 商用リージョン、AWS GovCloud (US) リージョン、および AWS 中国リージョンで利用できます。Target Optimizer を有効にしたターゲットグループへのトラフィックは、通常のターゲットグループよりも多くの LCU を消費します。

Application Load Balancer が Health Check Logs をサポート
AWS Application Load Balancers (ALB) は、詳細なターゲットヘルスチェックのログデータを指定の Amazon S3 バケットに直接送信できる Health Check Logs をサポートするようになりました。このオプション機能は、ターゲットのヘルスチェックステータス、タイムスタンプ、ターゲット識別データ、障害理由を記録します。
Health Check Logs は、ターゲットのヘルスステータスを完全に可視化し、正確な障害診断を提供するため、AWS サポートに問い合わせることなく迅速なトラブルシュートが可能です。これにより、ターゲットのヘルスパターンを時系列で分析し、インスタンスが異常と判断された正確な理由を特定することで、調査にかかる平均解決時間を大幅に短縮できます。
ログは5分ごとに S3 バケットに自動配信され、標準の S3 ストレージコスト以外に追加料金はかかりません。この機能は、Application Load Balancer が提供されている全ての AWS 商用リージョン、AWS GovCloud (US) リージョン、AWS 中国リージョンで利用でき、AWS マネジメントコンソール、AWS CLI、または AWS SDK を使用して有効にできます。

Amazon VPC IPAM が Infoblox IPAM からの IP 割り当てを自動化
Amazon VPC IP Address Manager (IPAM) が、Infoblox Universal IPAM から重複しない IP アドレス割り当てを自動的に取得できるようになりました。この機能は、クラウドとオンプレミスの管理者間の手動プロセスを最小限に抑え、所要時間を短縮します。
オンプレミスの Infoblox Universal IPAM から重複しない IP アドレスを自動的に取得して、最上位の AWS IPAM プールに取り込み、ビジネス要件に基づいてリージョナルプールに整理できます。重複しない IP を取得することで、IP がオンプレミスの IP アドレスと競合しないため、サービス中断のリスクを軽減できます。
これまで、ハイブリッドクラウド環境では、管理者はチケットや電子メールなどのオフライン手段を使用して IP アドレスを要求および割り当てる必要があり、エラーが発生しやすく時間もかかりました。この統合により手動プロセスが自動化され、運用効率が向上します。
この機能は、Amazon VPC IPAM がサポートされている全ての AWS リージョンで利用できますが、AWS China Regions と AWS GovCloud (US) Regions は除きます。

Amazon VPC IPAM が IP 割り当て戦略を適用するためのポリシーをサポート
Amazon Virtual Private Cloud (VPC) IP Address Manager (IPAM) は、希望する IP 割り当て戦略を一元的に設定・適用するためのポリシーをサポートします。これにより、リソースが特定の IPAM プールからパブリック IPv4 アドレスで起動されることが保証され、運用体制が改善し、ネットワークとセキュリティの管理が簡素化されます。
IPAM ポリシーを使用すると、IP 管理者は Network Address Translation (NAT) ゲートウェイや Elastic IP アドレスなどの AWS リソースに対するパブリック IP 割り当てルールを一元的に定義できます。一元的に設定された IP 割り当てポリシーは、個々のアプリケーションチームによって上書きできないため、常にコンプライアンスが確保されます。
この機能により、従来のようにアプリケーション所有者にベストプラクティスの遵守を徹底させる必要がなくなり、運用モデルが大幅に改善されます。また、AWS リソースへのパブリック IPv4 アドレスの割り当てが常に特定の IPAM プールから行われるという確信を持って、アクセスコントロールリスト、ルートテーブル、セキュリティグループ、ファイアウォールなどに IP ベースのフィルターを追加できます。
この機能は、全ての AWS 商用リージョンと AWS GovCloud (US) リージョンで、VPC IPAM の Free ティアと Advanced ティアの両方で利用できます。Advanced ティアを使用すると、お客さまは AWS アカウントと AWS リージョンをまたいでポリシーを設定できます。

Amazon Route 53 が AWS PrivateLink をサポート
Amazon Route 53 が route53.amazonaws.com サービスエンドポイントへの API リクエストで AWS PrivateLink をサポートするようになりました。これにより、AWS ワークロードはパブリックインターネットを使用せずに、ホストゾーン、レコード、ヘルスチェックなどの重要な DNS インフラストラクチャーに変更を加えることができます。
今回のアップデートにより、任意の AWS リージョンにおいて、仮想プライベートクラウド (VPC) と Route 53 API 間のプライベート接続をセットアップできます。この統合は、VPC 内のリソースを Route 53 API にプライベート接続するための複雑なネットワークサービスのセットアップや管理が不要になるため、クラウドアーキテクチャーを簡素化します。お客さまは VPC 内の VPC エンドポイントを使用して、Route 53 API への接続を確立できるようになりました。
米国東部 (バージニア北部) リージョン以外のお客さまは、クロスリージョンインターフェース VPC エンドポイントを使用することで、パブリックインターネット経由でトラフィックを送信したり、VPC ピアリングのようなリージョン間接続を設定したりすることなく、ほかのリージョンから Route 53 にネーティブに接続できます。
Route 53 の AWS PrivateLink サポートは、AWS GovCloud と中国リージョンを除く全てのリージョンで利用可能です。

Amazon Route 53 Profiles が Resolver クエリログ設定をサポート
Amazon Route 53 Profiles で Resolver クエリログ設定がサポートされ、組織内の複数の VPC や AWS アカウントに一括で適用できるようになりました。
Route 53 Profiles は、プライベートホストゾーン、DNS Firewall ルールグループ、Resolver ルールなどの Route 53 設定を、複数の VPC や AWS アカウントで共有できる機能です。以前は、Resolver のクエリログは VPC ごとに手動で設定する必要がありましたが、今回のアップデートにより、単一のプロファイル設定で一元管理が可能になります。
これにより、ネットワークセキュリティチームの管理オーバーヘッドが削減され、全てのアカウントと VPC で一貫した DNS クエリログが提供されるため、コンプライアンス監査も簡素化されます。

Amazon Route 53 DNS サービスが IPv6 API サービスエンドポイントをサポート
Amazon Route 53 は、Route 53 DNS サービス API エンドポイント route53.global.api.aws でデュアルスタックをサポートし、インターネットプロトコルバージョン 6 (IPv6)、Internet Protocol Version 4 (IPv4)、またはデュアルスタックのクライアントからの接続が可能になりました。既存の Route 53 DNS サービス IPv4 API エンドポイントは、後方互換性のために引き続き利用可能です。
インターネットの継続的な成長により IPv4 アドレス空間が枯渇しているため、お客さまは IPv6 アドレスに移行しています。これにより、クライアントは IPv6 経由で Route 53 DNS サービス API エンドポイントに接続できるようになり、組織はコンプライアンス要件を満たし、IPv4 と IPv6 間の IP アドレス変換の複雑さを解消できます。
Route 53 DNS サービス API エンドポイントでの IPv6 サポートは、全ての商用リージョンで追加費用なしで利用できます。この機能は、AWS CLI または AWS Management Console を通じて利用を開始できます。

Amazon Route 53 DNS Firewall が辞書ベースの DGA 攻撃に対する保護機能を追加
Route 53 Resolver DNS Firewall Advanced を有効にすることで、辞書ベースのドメイン生成アルゴリズム (DGA) 攻撃に関連するクエリを監視およびブロックできるようになりました。この攻撃は、事前定義された辞書から単語を疑似ランダムに連結して人間が読める文字列を生成し、検出を回避します。
Route 53 DNS Firewall Advanced は、VPC からクエリされたドメイン名の異常に基づいて DNS トラフィックをリアルタイムで監視・ブロックする保護機能です。これには DNS トンネリングや DGA 攻撃に対する保護が含まれます。今回のアップデートにより、正規のドメイン名を模倣して紛れ込ませることで検出を回避する、DGA 攻撃の亜種である辞書ベースの DGA 攻撃に対する保護も適用できるようになりました。
利用を開始するには、1つまたは複数の DNS Firewall Advanced ルールを設定し、検査対象の脅威として `Dictionary DGA` を指定します。ルールを DNS Firewall ルールグループに追加し、そのルールグループを各 VPC に直接関連付けるか、AWS Firewall Manager、AWS Resource Access Manager (RAM)、AWS CloudFormation、または Route 53 Profiles を使用して VPC に適用できます。
Dictionary DGA に対する Route 53 Resolver DNS Firewall Advanced のサポートは、AWS GovCloud (US) リージョンを含む全ての AWS リージョンで利用可能です。

Amazon CloudFront がオリジン接続における TLS 1.3 をサポート
Amazon CloudFront は、オリジンへの接続時に TLS 1.3 をサポートするようになり、オリジンとの通信におけるセキュリティが強化され、パフォーマンスが向上します。このアップグレードにより、より強力な暗号化アルゴリズム、ハンドシェイクのレイテンシー削減、CloudFront エッジロケーションとオリジンサーバー間のデータ転送における全体的な セキュリティ体制 の向上が実現します。
TLS 1.3 のサポートは、カスタムオリジン、Amazon S3、Application Load Balancer を含む全てのオリジンタイプで自動的に有効になり、お客さま側での設定変更は不要です。TLS 1.3 は、ハンドシェイクプロセス中のラウンドトリップ数を削減することで、より高速な接続確立を実現し、オリジンがサポートしている場合には接続パフォーマンスが最大30%向上します。
オリジンが TLS 1.3 をサポートしている場合、CloudFront は自動的に TLS 1.3 をネゴシエートし、まだアップグレードしていないオリジンに対しては、下位の TLS バージョンとの後方互換性を維持します。この機能強化は、金融サービス、ヘルスケア、機密データを扱うeコマースプラットフォームなど、高いセキュリティ基準を必要とするアプリケーションにメリットをもたらします。
オリジン接続における TLS 1.3 のサポートは、全ての CloudFront エッジロケーションで追加料金なしで利用できます。

Amazon CloudFront が CloudFront Functions の3つの新機能を発表
Amazon CloudFront は、CloudFront Functions の3つの新機能として、エッジロケーションと Regional Edge Cache (REC) のメタデータ、生のクエリ文字列の取得、高度なオリジンオーバーライドをサポートするようになりました。これにより、開発者は CloudFront のインフラストラクチャーに対する可視性を高め、オリジン接続をきめ細かく制御することで、より高度なエッジコンピューティングロジックを構築できます。
CloudFront Functions は、CloudFront エッジロケーションで軽量な JavaScript コードを実行し、ミリ秒未満の実行時間でコンテンツ配信のカスタマイズやセキュリティポリシーの実装を可能にする機能です。エッジロケーションのメタデータには、サービスを提供するエッジロケーションの3文字の空港コードと想定される REC が含まれ、地域固有のコンテンツルーティングやコンプライアンス要件に対応できます。生のクエリ文字列機能により、ビューアーから受信したままの未処理のクエリ文字列にアクセスでき、標準的な解析で変更されうる特殊文字やエンコーディングを保持できます。高度なオリジンオーバーライドは、Server Name Indication (SNI) を含む SSL/TLS ハンドシェイクパラメーターをカスタマイズすることで、複雑なアプリケーションインフラストラクチャーの課題を解決します。例えば、マルチテナント構成で、CloudFront が異なる証明書ドメインを持つサーバーに解決される CNAME チェーン経由で接続する際に SNI をオーバーライドできます。
これらの新しい CloudFront Functions の機能は、全ての CloudFront エッジロケーションで追加料金なしで利用可能です。

Amazon CloudFront が CBOR Web Tokens と Common Access Tokens をサポート
Amazon CloudFront は CBOR Web Tokens (CWT) と Common Access Tokens (CAT) をサポートするようになり、CloudFront Functions を使用して CloudFront のエッジロケーションで安全なトークンベースの認証と認可が可能になりました。CWT は Concise Binary Object Representation (CBOR) エンコーディングを使用し、JSON Web Tokens (JWT) に代わるコンパクトなバイナリ形式を提供します。一方、CAT は CWT を拡張し、URL パターン、IP 制限、HTTP メソッドの制限など、よりきめ細かいアクセスコントロールを追加します。
どちらのトークンタイプも CBOR Object Signing and Encryption (COSE) を使用してセキュリティを強化しており、開発者はミリ秒未満の実行時間で、軽量かつ高性能な認証メカニズムをエッジで直接実装できます。CWT と CAT は、毎秒数百万回の視聴者アクセストークンを検証する必要があるライブビデオストリーミングプラットフォームや、帯域幅効率が重要な IoT アプリケーションなど、パフォーマンスが重要なアプリケーションに最適です。
これらのトークンは、マルチ CDN 展開におけるコンテンツ認証のための単一で標準化された方法も提供し、セキュリティ管理を簡素化し、各 CDN プロバイダーに固有の設定を不要にします。例えば、メディア企業は CAT を使用して、サブスクリプションのティア、地理的な場所、デバイスタイプに基づいて特定のビデオコンテンツへのアクセスを制限するトークンを作成できます。これらのトークンは、アプリケーションのネットワークコールを必要とせず、CloudFront やほかの CDN プロバイダー間で一貫して検証されます。
CWT と CAT のサポートにより、CloudFront Functions 内で受信トークンの検証、新しいトークンの生成、トークンリフレッシュロジックの実装が可能です。この機能は、安全なキー管理のために CloudFront Functions KeyValueStore とシームレスに統合されます。CloudFront Functions での CWT と CAT のサポートは、全ての CloudFront エッジロケーションで追加料金なしで利用できます。

AWS が新しい VPC Encryption Controls を発表し、データ暗号化の基準をさらに引き上げ
AWS は、Amazon Virtual Private Cloud (VPC) 内および VPC 間の通信中の暗号化の監査と強制、および暗号化標準へのコンプライアンス証明を容易にする VPC Encryption Controls をリリースしました。
既存の VPC でこの機能を有効にすると、トラフィックフローの暗号化ステータスを監視し、意図せず平文トラフィックを許可している VPC リソースを特定できます。この機能は、AWS Fargate、Network Load Balancers、Application Load Balancers などの複数の VPC リソース間のトラフィックに対して、ハードウェアベースの AES-256 暗号化を自動的かつ透過的に有効にすることで、さまざまなネットワークパスでの暗号化の強制も容易にします。
HIPAA や PCI DSS のような厳格なコンプライアンス基準を満たすため、お客さまはアプリケーション層の暗号化と、AWS がさまざまなネットワークパスで提供するハードウェアベースの暗号化の両方に依存しています。AWS はすでに、最新の EC2 Nitro インスタンス間、アベイラビリティーゾーンやリージョンをまたぐデータセンター間のトラフィック、VPC Peering や Transit Gateway Peering を使用するリージョン間トラフィックなどを透過的に暗号化しています。
これまでお客さまは、全てのネットワークパスにわたって暗号化を追跡・確認する必要がありました。VPC Encryption Controls により、お客さまは数回のクリックで VPC 内および VPC 間の暗号化を監視、強制、証明できるようになりました。情報セキュリティチームは、この機能を一元的に有効にして、安全でコンプライアンスに準拠した環境を維持し、コンプライアンスとリポート作成のための監査ログを生成できます。
VPC Encryption Controls は、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、米国西部 (北カリフォルニア)、欧州 (アイルランド)、欧州 (フランクフルト)、欧州 (ロンドン)、欧州 (パリ)、欧州 (ミラノ)、欧州 (チューリッヒ)、欧州 (ストックホルム)、アジアパシフィック (シドニー)、アジアパシフィック (シンガポール)、アジアパシフィック (東京)、アジアパシフィック (メルボルン)、アジアパシフィック (香港)、アジアパシフィック (大阪)、アジアパシフィック (ムンバイ)、アジアパシフィック (ハイデラバード)、アジアパシフィック (ジャカルタ)、カナダ西部 (カルガリー)、カナダ (中部)、中東 (UAE)、中東 (バーレーン)、アフリカ (ケープタウン)、南米 (サンパウロ) の各 AWS 商用リージョンで利用可能です。

AWS がWebサイトの配信とセキュリティのための定額料金プランを発表
Amazon Web Services (AWS) は、Webサイトの配信とセキュリティのための超過料金なしの定額料金プランを開始します。
Amazon CloudFront で利用できるこの定額プランは、グローバルコンテンツ配信、AWS WAF、DDoS 保護、Amazon Route 53 DNS、Amazon CloudWatch Logs の取り込み、サーバーレスエッジコンピューティングを、超過料金なしのシンプルな月額料金に統合します。各プランには、ストレージコストを相殺するための月々の Amazon S3 ストレージクレジットも含まれています。
CloudFront の定額プランを利用すると、複数の AWS サービスにまたがるコストを計算することなく、Webサイトやアプリケーションを配信できます。Webサイトやアプリケーションのトラフィックが急増したり、DDoS 攻撃を受けたりした場合でも、超過料金のリスクに直面しません。WAF や DDoS 保護などのセキュリティ機能はデフォルトで有効になっており、追加の設定も簡単に行えます。
AWS アプリケーションをインターネットに直接公開するのではなく CloudFront を通じて提供する場合、定額プランによってアプリケーションと閲覧者間のデータ転送コストがカバーされ、超過料金を心配することなくシンプルな月額料金で利用できます。この簡素化された料金モデルは、各 CloudFront ディストリビューションの従量課金制と並行して利用でき、アプリケーションごとに適切な料金モデルと機能セットを柔軟に選択できます。
プランは、新規および既存の CloudFront ディストリビューション向けに、Free (月額0ドル)、Pro (月額15ドル)、Business (月額200ドル)、Premium (月額1,000ドル) のティアで利用可能です。アプリケーションのニーズに合った機能と使用許容量を持つプランティアを選択してください。

AWS Transit Gateway が Flexible Cost Allocation の一般提供を開始
AWS Transit Gateway で Flexible Cost Allocation の一般提供が開始され、組織全体での Transit Gateway のコスト配分方法が強化されました。これまで Transit Gateway は、送信元アタッチメントアカウントの所有者が全てのデータ使用量関連コストを負担する、送信者支払いモデルのみを使用していました。新機能の Flexible Cost Allocation (FCA) は、中央のメータリングポリシーを通じて、より多様なコスト配分オプションを提供します。
FCA メータリングポリシーを使用すると、Transit Gateway の全てのデータ処理およびデータ転送の使用量を、送信元アタッチメントアカウント、送信先アタッチメントアカウント、または中央の Transit Gateway アカウントに割り当てることができます。FCA メータリングポリシーは、アタッチメントレベルまたは個々のフローレベルの粒度で設定できます。また FCA は、AWS Network Firewall などのミドルボックスアプライアンスでのデータ処理使用量を、元の送信元または送信先のアタッチメント所有者に割り当てることができる、ミドルボックス展開モデルもサポートしています。この柔軟性により、単一の Transit Gateway で複数のコスト配分モデルを実装でき、AWS ネットワークインフラストラクチャー内のさまざまなチャージバックシナリオに対応できます。
Flexible Cost Allocation は、Transit Gateway が利用可能な全ての商用 AWS リージョンで利用できます。これらの機能は、AWS Management Console、AWS Command Line Interface (CLI)、AWS Software Development Kit (SDK) を使用して有効にできます。Transit Gateway で FCA を使用しても追加料金はかかりません。

AWS Site-to-Site VPN が VPN Concentrator を発表
AWS Site-to-Site VPN は、分散型企業のマルチサイト接続を簡素化する新機能 VPN Concentrator を発表しました。VPN Concentrator は、それぞれが低帯域幅 (100 Mbps 未満) を必要とする 25 以上のリモートサイトを AWS に接続する必要があるお客さまに適しています。これまで、多数の低帯域幅リモートサイトを AWS に接続するには、複雑で運用上のオーバーヘッドが大きいソリューションが必要でした。
AWS Site-to-Site VPN は、データセンターやブランチオフィスと AWS リソースとの間に IP Security (IPSec) トンネルを使用して安全な接続を確立できる、フルマネージドサービスです。今回のアップデートにより、お客さまは単一の VPN Concentrator を使用して最大 100 の低帯域幅サイトを接続し、AWS のワークロードにアクセスできるようになりました。
VPN Concentrator は、複数のリモートサイトが AWS Transit Gateway への単一のアタッチメントを介して接続できるようにすることで、マルチサイト接続を簡素化します。また、VPN Concentrator を使用して多数の低帯域幅サイトを集約することで、帯域幅を効率的に利用でき、サイト当たりの VPN コストを削減できます。
この機能は、AWS Site-to-Site VPN が利用可能な全ての AWS 商用リージョンおよび AWS GovCloud (US) リージョンで利用できます。

AWS PrivateLink が AWS サービスへのクロスリージョン接続をサポート
AWS PrivateLink が、AWS サービスへのネーティブなクロスリージョン接続をサポートするようになりました。これまで同一リージョン内の接続のみをサポートしていた Interface VPC エンドポイントを介して、同じ AWS パーティション内のほかのリージョンでホストされている一部の AWS サービスに接続できます。
お客さまは、クロスリージョンピアリングを設定したり、パブリックインターネット経由でデータを公開したりすることなく、Amazon S3、Route53、Elastic Container Registry (ECR) などのサービスにプライベートにアクセスできます。これらのサービスには、VPC 内のプライベート IP アドレスを持つ Interface エンドポイントを通じてアクセスできるため、よりシンプルで安全なリージョン間接続が可能になります。
この機能は、データレジデンシー要件に準拠しながら、PrivateLink を介してサポートされている AWS サービスにアクセスする、グローバルに分散されたプライベートネットワークを構築するのに役立ちます。

AWS Cloud WANが、高度なトラフィック制御と柔軟なネットワーク展開のためのルーティングポリシーを追加
AWS は、Cloud WAN Routing Policy の一般提供を開始しました。これにより、お客さまはグローバルな広域ネットワーク全体で、ルート管理の最適化、トラフィックパターンの制御、ネットワーク動作のカスタマイズをきめ細かく制御できます。AWS Cloud WAN は、AWS クラウド内のリソースとオンプレミス環境を相互接続する、統合されたグローバルネットワークを構築、監視、管理できるサービスです。
新しい Routing Policy 機能を使用すると、お客さまはルートフィルターリングやルート集約などの高度なルーティング技術を実行し、AWS Cloud WAN と外部ネットワーク間で交換されるルートをより適切に制御できます。この機能により、ルート到達可能性のブラスト半径を最小化し、最適でない、または非対称な接続パターンを防ぎ、グローバルネットワークにおける不要なルートの伝播によるルートテーブルの超過を回避できます。さらに、高度な Border Gateway Protocol (BGP) 属性を設定して、個々のニーズに合わせてネットワークトラフィックの動作をカスタマイズし、可用性の高いハイブリッドクラウドネットワークアーキテクチャーを構築することも可能です。また、この機能はルーティングデータベースの可視性を高め、複雑なマルチパス環境でのネットワーク問題の迅速なトラブルシュートを可能にします。
新しい Routing Policy 機能は、AWS Cloud WAN が利用可能な全ての AWS リージョンで利用できます。この機能は AWS マネジメントコンソール、AWS Command Line Interface (CLI)、AWS Software Development Kit (SDK) を使用して有効にでき、追加料金はかかりません。

AWS Application Load Balancer と Network Load Balancer が TLS 向けの耐量子鍵交換をサポート
AWS Application Load Balancer (ALB) と Network Load Balancer (NLB) が、Transport Layer Security (TLS) プロトコル向けの耐量子鍵交換オプションをサポートするようになりました。
このオプトイン機能は、ハイブリッド耐量子鍵合意を持つ新しい TLS セキュリティポリシーを導入します。これは、古典的な鍵交換アルゴリズムと、標準化された Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) アルゴリズムを含む耐量子鍵カプセル化方式を組み合わせたものです。耐量子 TLS (PQ-TLS) セキュリティポリシーは、転送中のデータを「Harvest Now, Decrypt Later」 (HNDL) 攻撃から保護します。HNDL 攻撃とは、攻撃者が現在暗号化されたデータを収集し、将来量子コンピューティングが成熟した際に解読することを意図するものです。この耐量子暗号化により、アプリケーションとデータ送信の長期的なセキュリティが確保され、新たな量子コンピューティングの脅威に対してインフラを将来にわたって保護できます。
この機能は、ALB と NLB で、全ての AWS 商用リージョン、AWS GovCloud (US) リージョン、AWS 中国リージョンにおいて追加費用なしで利用できます。この機能を使用するには、既存の ALB HTTPS リスナーまたは NLB TLS リスナーを明示的に更新して PQ-TLS セキュリティポリシーを使用するか、AWS Management Console 、CLI 、API 、SDK を通じて新しいリスナーを作成する際に PQ-TLS ポリシーを選択する必要があります。
ALB 接続ログまたは NLB アクセスログを使用して、古典的または耐量子鍵交換の使用状況を監視できます。

量子テクノロジー

Amazon Braket が量子プロセッシングユニットの利用上限額設定機能を導入
Amazon Braket が、量子プロセッシングユニット (QPU) のコストを管理するための利用上限額設定をサポートしました。お客さまはデバイスごとに最大利用額のしきい値を定義でき、Amazon Braket は事前に設定された上限を超えないか各タスク送信時に自動的に検証します。残りの予算を超えるタスクは作成前に拒否されます。
この利用上限額設定は、複数のユーザーにまたがる量子コンピューティングの予算を管理する研究機関、授業中の意図しない過剰支出を防ぐ教育環境、量子アルゴリズムを実験する開発チームにとって特に役立ちます。お客さまは要件の変更に応じて、いつでも利用上限額を更新または削除できます。
利用上限額は QPU でのオンデマンドタスクにのみ適用され、シミュレーター、ノートブックインスタンス、ハイブリッドジョブ、または Braket Direct 予約中に作成されたタスクのコストは含まれません。AWS 全体の包括的なコスト管理には、引き続き AWS Cost Management の一部である AWS Budgets 機能を使用する必要があります。
この機能は、Amazon Braket がサポートされている全ての AWS リージョンで追加費用なしで利用できます。

Amazon Braket が Alpine Quantum Technologies (AQT) の新しい量子プロセッサを追加
Amazon Braket で、新しい量子ハードウェアプロバイダーである Alpine Quantum Technologies (AQT) のトラップイオン型量子プロセッシングユニット (QPU) である IBEX Q1 が利用可能になりました。IBEX Q1 は全結合型の 12 量子ビットシステムで、中間の SWAP ゲートを必要とせずに、任意の量子ビットがほかの量子ビットと直接相互作用できます。
AQT のトラップイオン技術にオンデマンドでアクセスして量子プログラムを構築・テストしたり、Hybrid Jobs を介して優先アクセスして変分量子アルゴリズムを実行したりすることが、全て従量課金制で可能になります。また、Braket Direct を利用して、時間的制約のあるワークロード向けにこの QPU のリザーブドキャパシティを時間単位の料金で予約することも可能です。前払いコミットメントは不要です。
IBEX Q1 は、火曜日と水曜日の 09:00 から 16:00 (UTC) まで利用可能で、ヨーロッパのタイムゾーンのお客さまが勤務時間中にアクセスしやすくなっています。IBEX Q1 は、ヨーロッパ (ストックホルム) リージョンからアクセスできます。
認定機関の研究者は、AWS Cloud Credits for Research プログラムを通じて、Amazon Braket での実験をサポートするためのクレジットを申請できます。

セキュリティ、アイデンティティ、コンプライアンス

Amazon Inspector が AWS Organizations ポリシーによる組織全体の管理をサポート
Amazon Inspector が AWS Organizations ポリシーを使用して、組織全体で有効化、設定、管理できるようになりました。この新機能により、Amazon EC2 スキャン、ECR スキャン、Lambda 標準およびコードスキャン、Code Security などのスキャンタイプを、組織内の全てのアカウント、選択した組織単位 (OU)、または個別のアカウントにわたって一元的に設定および管理できます。
AWS Organizations 内の新しい Inspector ポリシータイプは、サービスのオンボーディングと管理を簡素化し、組織全体で一貫した脆弱性スキャンを保証します。この特長は、単一の AWS Organizations ポリシーを通じて Inspector の有効化を自動化することで、統一されたセキュリティベースラインの維持に役立ちます。ポリシーがアタッチされると、対象範囲内の全てのアカウントが組織全体のポリシー定義に自動的に準拠します。組織に参加した新しいアカウントも Inspector の有効化を自動的に継承するため、運用上のオーバーヘッドが削減され、カバレッジのギャップがなくなります。
Amazon Inspector は、Amazon EC2 インスタンス、コンテナイメージ、AWS Lambda 関数、コードリポジトリなどの AWS ワークロードを継続的にスキャンし、ソフトウェアやコードの脆弱性、意図しないネットワークへの公開を検出する脆弱性管理サービスです。
この組織全体での有効化機能は、Amazon Inspector が利用可能な全ての AWS 商用、中国、および AWS GovCloud (US) リージョンにおいて、Amazon Inspector のお客さまに追加費用なしで利用できます。

Amazon GuardDuty Malware Protection for AWS Backup が利用可能に
Amazon GuardDuty Malware Protection for AWS Backup が利用可能になり、Amazon EC2、Amazon EBS、Amazon S3 のバックアップにマルウェア検出が拡張されました。この機能は、追加のセキュリティソフトウェアやエージェントを必要とせずに、バックアップ内のマルウェア検出を自動化します。最後にクリーンであることが確認されたバックアップを特定することで、復旧時のビジネスの中断を最小限に抑えることができます。
マルウェア保護は、新しいバックアップを自動的にスキャンし、既存のバックアップのオンデマンドスキャンを実行し、復元前にバックアップがクリーンであることを検証します。この機能は、アカウントで GuardDuty の基本的なデータソースが有効になっていない場合でも有効にできます。また、バックアップ間の変更されたデータのみを分析する増分スキャンを使用することで、完全なバックアップの再スキャンと比較してコストを削減できます。
Amazon GuardDuty Malware Protection for AWS Backup は、サポートされているリージョンで利用可能です。AWS Backup コンソール、API、または CLI を使用して利用を開始できます。

AWS WAF が Web Bot Auth をサポート
AWS WAF に Web Bot Auth (WBA) のサポートが追加されました。これにより、Web アプリケーションにアクセスする正規の AI エージェントや自動化ツールを認証するための、安全で標準化された方法が提供されます。
Web Bot Auth は、HTTP メッセージ内の暗号署名を利用して、リクエストが自動化されたボットからのものであることを検証する認証方式です。この方式は、検証済みボットおよび署名済みエージェントの検証方法として使用され、2つの有効な IETF ドラフトに基づいています。1つはクローラーが公開鍵を共有できるようにするディレクトリードラフト、もう1つはこれらの鍵を使用してクローラーのアイデンティティーを HTTP リクエストに添付する方法を定義するプロトコルドラフトです。
AWS WAF は、検証済みの AI エージェントのトラフィックを自動的に許可するようになりました。検証済みの WBA ボットは、デフォルトで自動的に許可されます。以前は、Category AI は未検証のボットをブロックしていましたが、この動作は WBA 検証を尊重するように改良されました。
この機能の使用に追加費用はかかりませんが、標準の AWS WAF の料金は引き続き適用されます。この機能は現在、Amazon CloudFront ディストリビューションを保護している AWS WAF のお客さまのみが利用できます。

AWS Security Token Service がインターネットプロトコルバージョン 6 (IPv6) をサポート
AWS Security Token Service (STS) は、新しいデュアルスタックエンドポイント経由で インターネットプロトコルバージョン 6 (IPv6) アドレスをサポートするようになりました。IPv6、IPv4、またはデュアルスタック (IPv4 と IPv6 の両方) のクライアントを使用して、パブリックインターネット経由で STS に接続できます。また、AWS PrivateLink を使用して Amazon Virtual Private Cloud (VPC) から STS エンドポイントにプライベートにアクセスする場合にもデュアルスタックがサポートされ、パブリックインターネットを経由せずに STS API を呼び出すことができます。デュアルスタック STS エンドポイントのサポートは、全ての AWS 商用リージョン、AWS GovCloud (US) リージョン、および中国リージョンで利用可能です。

AWS Security Incident Response が無料利用枠付きの従量課金制を発表
AWS Security Incident Response は、取り込まれたセキュリティ検出結果の数に基づく新しい従量課金モデルを発表しました。これにより、自動セキュリティインシデント対応機能と AWS Customer Incident Response Team (CIRT) の専門家によるガイダンスが、あらゆる規模の組織でより柔軟かつスケーラブルに利用できるようになります。
新しい料金モデルでは、月間最初の10,000件の検出結果をカバーする無料ティアが導入され、セキュリティチームは無料でサービスの価値を検証できます。無料ティアを超えた後は、検出結果1件当たり$0.000676が課金され、利用量が増えるにつれて料金が下がるティア制の割引が適用されます。この消費ベースのアプローチにより、お客さまは事前のコミットメントや最低料金なしで、ニーズの進化に合わせてセキュリティインシデント対応能力を拡張できます。
お客さまは追加費用なしで Amazon CloudWatch を通じて月間の検出結果数を監視でき、無料ティアに対する使用状況や適用される料金を簡単に追跡できます。この新しい料金モデルは、2025年11月21日より、Security Incident Response が利用可能な全ての AWS リージョンに自動的に適用され、お客さま側での対応は不要です。

AWS Security Incident Response がエージェント的なAIを活用した調査機能を提供開始
AWS Security Incident Response は、セキュリティイベントへの準備、対応、復旧をより迅速かつ効果的に行うための、エージェンティックなAIを活用した調査機能を提供します。新しい調査エージェントは、複数の AWS データソースから証拠を自動的に収集し、データを関連付け、明確で実用的な概要として調査結果を提示します。これにより、潜在的なセキュリティイベントの調査と対応に必要な時間が短縮され、ビジネスの中断を最小限に抑えることができます。
Security Incident Response コンソールでセキュリティイベントのケースが作成されると、調査エージェントは直ちにケースの詳細を評価し、潜在的な指標、リソース名、期間などの不足情報を特定します。ケースの提出者に明確化のための質問をしてこれらの詳細を収集します。このプロアクティブなアプローチにより、従来ケースの解決時間を長引かせていたやりとりによる遅延を最小限に抑えることができます。その後、調査エージェントは AWS CloudTrail、AWS Identity and Access Management (IAM)、Amazon EC2、AWS Cost Explorer などのさまざまなデータソースから関連情報を収集します。このデータを自動的に関連付けて包括的な分析を提供することで、手動での証拠収集の必要性を減らし、より迅速な調査を可能にします。セキュリティチームは、全ての調査活動を AWS コンソールから直接追跡し、好みの統合ツールで概要を表示できます。
この機能は、サービスが利用可能な全ての AWS リージョンで、Security Incident Response の全てのお客さまに追加費用なしで自動的に有効化されます。

AWS Secrets Manager が managed external secrets を発表
AWS Secrets Manager は、サードパーティーの Software-as-a-service (SaaS) のシークレットに対し、デフォルトで自動ローテーションを提供する新機能 managed external secrets を発表しました。ローテーション用の Lambda 関数の作成や管理のオーバーヘッドなしに、SaaS プロバイダーがサポートする複数のローテーション戦略から選択できます。
今回のアップデートにより、SaaS プロバイダーが規定する事前定義済みのシークレット形式で、AWS Secrets Manager を使用して SaaS シークレットを保護できます。このローンチには、SaaS プロバイダーがパートナーとして登録されるためのオンボーディングガイドも含まれており、パートナーはシークレット管理に関する規範的なガイダンスをお客さまに提供し、お客さまの管理オーバーヘッドを削減できます。
ローンチ時点では、managed external secrets 機能は Salesforce、BigID、Snowflake の 3 つのパートナーで利用可能です。この機能は、AWS Secrets Manager が利用可能な全ての AWS Regions で利用できます。

AWS Payments Cryptography が、転送中のデータを保護するための耐量子暗号をサポート
AWS Payments Cryptography が、API コールを保護するためのハイブリッド耐量子 (PQ) TLS のサポートを発表しました。今回のアップデートにより、お客さまは ML-KEM 耐量子暗号を使用して、機密データやコマンドの送信を将来にわたって保護できます。
規制の厳しいワークロードを運用する企業は、「今収穫し、後で解読する (harvest now, decrypt later)」という耐量子リスクの軽減を望んでいます。転送中の長期データは現在記録され、将来高性能な量子コンピューターが利用可能になった際に解読される可能性があります。今回のアップデートにより、AWS Payment Cryptography は PQ-TLS をサポートすることで、この懸念に対処する AWS Key Management Service (KMS) などのデータ保護サービスに加わりました。
利用を開始するには、アプリケーションが PQ-TLS をサポートするバージョンの AWS SDK またはブラウザーに依存していることを確認するだけです。お客さまは、コンソールまたは設定済みの CloudTrail トレイルで、対応する CloudTrail イベントの tlsDetails を確認することで、API コールの TLS セッションを保護するために ML-KEM が使用されたことを検証することもできます。
これらの機能は、全ての AWS リージョンで追加費用なしで一般提供されています。

AWS Network Firewall でアクティブ脅威防御がデフォルトで有効に
AWS Network Firewall では、AWS マネジメントコンソールで新しいファイアウォールポリシーを作成する際に、アクティブ脅威防御がデフォルトでアラートモードで有効になります。アクティブ脅威防御は、AWS インフラ全体で観測される動的で継続的な脅威活動に対して、インテリジェンス主導の自動保護を提供します。
このデフォルト設定により、保護対象の脅威活動、インジケーターグループ、タイプ、脅威名を可視化できます。ブロックモードに切り替えて、コマンドアンドコントロール (C2) 通信、埋め込み URL、悪意のあるドメインなどの疑わしいトラフィックを自動的に防止したり、機能を完全に無効にしたりすることも可能です。AWS は脅威インジケーターを検証し、高い精度を確保して誤検知を最小限に抑えます。
アクティブ脅威防御は、AWS GovCloud (US) および中国リージョンを含む、AWS Network Firewall が利用可能な全てのリージョンで利用できます。

AWS Network Firewall が Transit Gateway 経由での柔軟なコスト配分をサポート
AWS Network Firewall が、AWS Transit Gateway のネーティブアタッチメントを介した柔軟なコスト配分をサポートし、データ処理コストを異なる AWS アカウントに自動的に分散できるようになりました。
お客さまはメータリングポリシーを作成することで、全ての費用をファイアウォールの所有者アカウントに集約するのではなく、組織のチャージバック要件に基づいてデータ処理料金を適用できます。
この機能により、セキュリティチームやネットワークチームは、実際の使用量に基づいてアプリケーションチームに料金を分散させることで、一元管理されたファイアウォールのコストをより適切に管理できます。
組織は、一元化されたセキュリティコントロールを維持しつつ、検査コストを適切なビジネスユニットやアプリケーション所有者に自動的に割り当てることができ、カスタムのコスト管理ソリューションは不要になります。
柔軟なコスト配分は、AWS Network Firewall と Transit Gateway アタッチメントの両方がサポートされている全ての AWS 商用リージョンおよび Amazon 中国リージョンで利用できます。このアタッチメントや柔軟なコスト配分を使用しても、AWS Network Firewall および AWS Transit Gateway の標準料金を超える追加料金は発生しません。

AWS IAM が、リージョンベースのアクセス制御のための条件キー aws:SourceVpcArn を発表
AWS Identity and Access Management (IAM) は、新しいグローバル条件キー aws:SourceVpcArn をサポートするようになりました。これにより、お客さまは AWS PrivateLink を介してアクセスされるリソースに対して、リージョンベースのアクセス制御を強制できます。
この条件キーは、VPC エンドポイントがアタッチされている VPC の ARN を返すため、お客さまはリクエストが特定の VPC を経由するかどうかを検証し、同一リージョンまたはクロスリージョンのシナリオでリソースへのプライベートアクセスを制御できます。お客さまはポリシーで aws:SourceVpcArn を使用して、リソースが特定のリージョンの VPC エンドポイントからのみアクセス可能であることを保証し、データレジデンシー要件の施行に役立てることができます。例えば、指定されたリージョンの VPC エンドポイント経由のリクエストにのみアクセスを制限するポリシーを、Amazon S3 バケットにアタッチできます。
aws:SourceVpcArn 条件キーは、全ての商用 AWS リージョンで利用可能です。

AWS IAM が JSON Web Tokens (JWTs) を使用した外部サービスへの ID フェデレーションに対応
AWS Identity and Access Management (IAM) は、アウトバウンド ID フェデレーションを発表しました。これにより、お客さまは有効期間の短い JSON Web Tokens (JWTs) を使用して、AWS ID を外部サービスに安全にフェデレーションできます。
この機能により、お客さまは長期的な認証情報や複雑な回避策を使用することなく、サードパーティーのクラウドプロバイダー、SaaS プロバイダー、セルフホストアプリケーションで AWS ワークロードを安全に認証できます。お客さまは AWS IAM 認証情報を、暗号署名された有効期間の短い JSON Web Tokens (JWTs) に交換できるようになり、AWS ワークロードが外部サービスにアクセスするためのシンプルで安全なメカニズムが提供されます。
これらのトークンには AWS ワークロードに関する豊富なコンテキストが含まれており、外部サービスできめ細かいアクセス制御を実装できます。管理者は IAM ポリシーを使用してトークン生成へのアクセスを制御し、トークンのプロパティ (有効期間、オーディエンス、署名アルゴリズムなど) を強制できます。また、CloudTrail ログを使用してトークンの使用状況を監査することで、組織のセキュリティおよびコンプライアンス要件を満たすことができます。
この機能は、全ての AWS 商用リージョン、AWS GovCloud (US) リージョン、および中国リージョンで利用できます。

AWS Directory Service がプライベート VPC 接続のための AWS PrivateLink をサポート
AWS Directory Service が AWS PrivateLink をサポートするようになりました。これにより、AWS Directory Service への全ての API コールを指定したプライベートネットワーク内に制限できます。
この新機能は、AWS Directory Service API と Directory Service Data API の両方にプライベート接続を提供し、ネットワークパスの高速化、レイテンシーの削減、パブリックインターネット経由のコールパターンを排除します。AWS PrivateLink のサポートにより、インターネットゲートウェイや NAT デバイスを必要とせずにアクセスを制限できるため、ワークロードとパブリックネットワークを厳格に分離する必要がある組織に特に有効です。
これには、ディレクトリーの作成、信頼関係の設定、ユーザーアカウントの管理、グループへのユーザー追加といった全ての主要な操作が含まれます。プライベート接続を確立するには、AWS PrivateLink を利用したインターフェース Amazon VPC エンドポイントを作成します。これにより、Directory Service API トラフィックのエントリーポイントとして機能するネットワークインターフェースが各サブネットに作成されます。
この機能は、AWS Directory Service がサポートされている全ての AWS リージョンで利用可能です。

ストレージ

Recycle Bin が Amazon EBS ボリュームをサポート
誤って削除されたスナップショットや EBS-backed AMI の復旧を支援する Amazon EBS の Recycle Bin が、EBS Volumes をサポートするようになりました。
ボリュームを誤って削除した場合、スナップショットから復元する代わりに Recycle Bin から直接復旧できるようになり、最後のスナップショットと削除の間のデータ損失なしで目標復旧時点を短縮できます。復旧されたボリュームは、スナップショットからのデータダウンロードを待つことなく、すぐに完全なパフォーマンスを発揮できます。
Recycle Bin を使用するには、削除されたボリュームの保持期間を設定し、その期間内であればいつでもボリュームを復旧できます。復旧されたボリュームはすぐに利用可能になり、タグ、アクセス許可、暗号化ステータスといった全ての属性を保持します。保持期間が終了すると、復旧されなかったボリュームは完全に削除されます。保持ルールを作成して、全てのボリュームまたは特定のボリュームに対して Recycle Bin を有効にでき、タグを使用して保護対象のボリュームを指定します。
Recycle Bin 内の EBS Volumes は、EBS Volumes と同じ料金で請求されます。この機能は、全ての AWS 商用リージョン、中国リージョン、および AWS GovCloud (US) リージョンで、AWS Command Line Interface (CLI)、AWS SDKs、または AWS Console を通じて利用可能です。

Amazon S3 が、バケットで使用する暗号化タイプを標準化するための新しいバケットレベル設定を追加
Amazon S3 は、バケットへの全ての書き込みリクエストに対して Amazon S3 マネージドサーバーサイド暗号化 (SSE-S3) または AWS KMS キーによるサーバーサイド暗号化 (SSE-KMS) を強制する、新しいデフォルト暗号化設定をサポートするようになりました。この新しいバケットレベルの設定は、バケットで使用できるサーバーサイド暗号化タイプを標準化するのに役立ちます。PutBucketEncryption API を使用すると、特定のバケットまたは AWS CloudFormation テンプレートで、お客さまが提供するキーによるサーバーサイド暗号化 (SSE-C) を無効にできます。
この PutBucketEncryption API の機能強化は、全ての AWS リージョンで利用可能です。AWS マネジメントコンソール、SDK、API、または CLI を使用して、バケットの暗号化制御を設定できます。

Amazon S3 が S3 エンドポイントで耐量子 TLS 鍵交換をサポート
Amazon S3 は、リージョナル S3、S3 Tables、S3 Express One Zone エンドポイントで耐量子 TLS 鍵交換をサポートするようになり、お客さまは転送中のデータを暗号化するための耐量子暗号化オプションを利用できます。
全てのリージョナル S3、S3 Tables、S3 Express One Zone エンドポイントは、米国国立標準技術研究所 (NIST) が標準化した耐量子暗号アルゴリズムの1つである Module Lattice-Based Key Encapsulation Mechanisms (ML-KEM) をサポートします。この新しいサポートは、AES-256 アルゴリズムを利用した Amazon S3 のデフォルトのサーバーサイド暗号化と組み合わせることで、お客さまに転送中と保管中の両方で耐量子暗号化を提供します。
Amazon S3 はクライアントソフトウェアがサポートする最も高い TLS プロトコルバージョンを自動的にネゴシエートするため、ML-KEM 鍵交換アルゴリズムを使用するように設定された全てのクライアントで、耐量子 TLS 鍵交換のメリットを享受できます。
Amazon S3 の耐量子 TLS 鍵交換は、全ての AWS リージョンの全てのリージョナル S3、S3 Tables、S3 Express One Zone エンドポイントで、追加費用なしでサポートされます。

Amazon FSx for Windows File Server が File Server Resource Manager をサポート
Windows Server 上に構築されたファイルストレージを提供するフルマネージドサービスである Amazon FSx for Windows File Server は、File Server Resource Manager (FSRM) をサポートするようになりました。FSRM は、ファイルデータの管理、統制、監視を行う強力な機能を提供する Windows Server の機能です。
FSRM を使用することで、FSx for Windows ファイルシステム全体でストレージ使用量をより適切に制御し、コンプライアンスを強化し、コストを最適化できます。今回のアップデートにより、ファイル分類とファイルスクリーニングによる機密データの分類、識別、制御、フォルダーレベルのクオータによるストレージ使用量とコストの制御、ストレージリポートによるストレージ使用状況の把握と最適化が可能になります。
FSx for Windows File Server 上の FSRM は、AWS の可観測性サービスと深く統合されています。FSRM イベントを Amazon CloudWatch Logs に直接発行したり、Amazon Kinesis Data Firehose にストリーミングしたりできます。これにより、ログのクエリ、処理、保存、アーカイブ、ファイルイベントに応じた AWS Lambda 関数のトリガー、ファイルデータ管理を自動化するための高度な監視と分析が可能になります。
FSRM サポートは、Amazon FSx for Windows File Server が利用可能な全ての AWS リージョンにおいて、新しいファイルシステムで追加費用なしで利用できます。既存のファイルシステムには、今後のメンテナンスウインドーで FSRM サポートが提供されます。

Amazon FSx for Lustre がディレクトリー一覧表示のパフォーマンスを最大5倍向上
Amazon FSx for Lustre のディレクトリー一覧表示 (ls) パフォーマンスが最大5倍高速化され、ファイルシステムの内容をより効率的に閲覧・分析できるようになりました。
Amazon FSx for Lustre は、機械学習トレーニング、金融分析、ハイパフォーマンスコンピューティングなどの計算集約型ワークロード向けの、高パフォーマンスで費用対効果の高い、スケーラブルなファイルストレージサービスです。今回のパフォーマンス向上により、ホームディレクトリーやソースコードリポジトリなどのインタラクティブなユースケースにおいて、"ls" を使用したディレクトリー内容の一覧表示と分析にかかる時間が短縮されます。
このパフォーマンス向上は、FSx for Lustre が利用可能な全ての AWS リージョンで、最新の Lustre 2.15 クライアントを使用することでサポートされます。

AWS Backup が 論理エアギャップボールトへの直接バックアップをサポート
AWS Backup が、論理エアギャップボールトをプライマリバックアップターゲットとしてサポートするようになりました。バックアッププラン、組織全体のポリシー、またはオンデマンドバックアップで、論理エアギャップボールトをプライマリターゲットとして割り当てることができます。
これまで、論理エアギャップボールトには既存のバックアップのコピーしか保存できませんでした。この機能により、複数のバックアップを保存することなく直接バックアップできるため、論理エアギャップボールトのセキュリティと回復可能性という特長を求めるお客さまのストレージコストを削減できます。
AWS Backup による完全な管理をサポートするリソースタイプは、指定されたエアギャップボールトに直接バックアップされます。完全な管理をサポートしていないリソースタイプの場合、AWS Backup は標準ボールトに一時的なスナップショットを作成し、それをエアギャップボールトにコピーした後、スナップショットを削除します。
この機能は、論理エアギャップボールトをサポートする全ての AWS リージョンで利用できます。

AWS Backup が Amazon S3 バックアップ向けの低コストウォームストレージティアを導入
AWS Backup は、Amazon S3 バックアップデータのコストを最大30%削減できる、低コストのウォームストレージティアを導入しました。
S3 バックアップデータがボールトに60日間（または設定に応じてそれ以上）保管された後、新しい低コストのウォームストレージティアに移動できます。この低コストティアは、ランサムウェア保護、リカバリ、監査など、ウォームストレージティアと同じパフォーマンスと機能を提供します。長期保存が必要なビジネス、コンプライアンス、または規制データのストレージコスト削減に利用できます。
今回のアップデートにより、60日以上の経過期間しきい値を設定することで、アカウント内の全てのボールト、特定のボールト、またはボールト内のバケットにある全ての S3 バックアップに対して自動階層化を設定できるようになりました。階層化を有効にすると、しきい値を超えた既存のバックアップデータは自動的に低コストのウォームティアに移動し、操作不要でパフォーマンスへの影響もなく、すぐにコスト削減が実現します。
この低コストストレージティアは、AWS Backup for Amazon S3 が利用可能な全ての AWS リージョンで利用できます。データが低コストのウォームティアに移動する際には、1回限りの移行料金が発生します。

AWS Backup が Amazon FSx Intelligent-Tiering をサポート
AWS Backup は、Amazon FSx Intelligent-Tiering をサポートするようになりました。これは、ワークロードに応じて自動的にスケールアップおよびスケールダウンする、完全に伸縮自在なファイルストレージを提供するストレージクラスです。FSx Intelligent-Tiering ストレージクラスは、FSx for Lustre および Amazon FSx for OpenZFS ファイルシステムで利用でき、パフォーマンス、従量課金制の伸縮性、自動化されたコスト最適化を単一のソリューションに統合しています。
この統合により、AWS Backup の一元的なバックアップ管理機能を通じて、FSx Intelligent-Tiering を使用する OpenZFS および Lustre ファイルシステムを保護できるようになりました。既存の Amazon FSx バックアッププランをご利用のお客さまは変更を行う必要がなく、スケジュールされた全てのバックアップは引き続き期待どおりに機能します。AWS Backup のサポートは、FSx Intelligent-Tiering が利用可能な全ての AWS リージョンで利用できます。

その他

AWSチャンネルパートナーが Billing Transfer を使用して再販可能に
AWS ソリューションプロバイダーまたはディストリビューションプログラムに参加している AWS チャンネルパートナーは、Billing Transfer を使用して AWS サービスを再販できるようになりました。Billing Transfer を使用すると、パートナーは、お客さまが自身の管理アカウントの完全なコントロールを維持したまま、お客さまの AWS Organizations の金銭的責任を負うことができます。
AWS Partner Central のチャンネル管理と Billing Transfer を併用することで、パートナーは自身の AWS Organization に配信される AWS 請求書に適用されるプログラム特典を受け取ることができます。一方、エンドカスタマーは、自身の別の AWS Organization 内で、パートナーが設定した料金でコストを確認できます。Billing Transfer により、全ての AWS チャンネルパートナーは、単一のパートナー管理アカウントから多数のお客さまの AWS Organizations にわたる請求と支払いを一元管理し、運用を簡素化できます。
また、パートナーは Partner Central の新しい API を使用して、自身のシステムからチャンネルプログラムのリポート作成やインセンティブ資格の管理を行うこともできます。エンドカスタマーは、コスト最適化やサービス管理といったパートナーの付加価値サービスから恩恵を受けつつ、自身の AWS Organizations を独立して管理する自律性を得られます。
Billing Transfer は、AWS GovCloud (US)、中国 (北京)、中国 (寧夏) リージョンを除く、パブリック AWS リージョンで事業を展開する全ての AWS チャンネルパートナーとそのエンドカスタマーが利用できます。

AWS Marketplace が Amazon Bedrock AgentCore Runtime 向けの A2A サーバーをサポート
AWS Marketplace は、Amazon Bedrock AgentCore Runtime 向けに構築されたサードパーティーの AI エージェントとツールに対し、Agent-to-Agent (A2A) サーバーのサポートと合理化されたデプロイを提供するようになりました。
この新機能は、AgentCore コンソールと AWS CLI 命令に必要な環境変数を事前に入力することでデプロイを高速化します。お客さまは AWS Marketplace を通じて AgentCore Runtime 上に A2A サーバーを調達・デプロイでき、AWS パートナーの AI エージェントをより簡単に活用できます。この改善により、ベンダー定義の起動設定を活用してデプロイの複雑さが軽減され、多様なお客さまのニーズに応えるためのプロトコルの柔軟性も向上します。
AWS パートナーは、AWS Marketplace Management Portal で、MCP サーバーや AI エージェントに加えて A2A サーバーを提供できるようになりました。お客さまのオンボーディングを加速するために必要な環境変数を定義したり、API ベースの SaaS 製品に無料価格設定を有効にしたりすることも可能です。これらの機能は、AWS パートナーが新製品を市場に投入し、ビジネスモデルとお客さまのニーズに合った価格戦略を実施するための柔軟性を提供します。

AWS Builder Center でワークショップが利用可能に
AWS Builder Center で、AWS Workshops のカタログにアクセスできるようになりました。このカタログは、AWS の専門家が作成したステップバイステップの手順を提供し、AWS サービスを効果的にデプロイして使用する方法を解説します。
ワークショップは幅広い AWS サービスとユースケースをカバーしており、あらゆるスキルレベルのビルダーが自身の AWS アカウントでガイド付きチュートリアルを実行し、実践的な経験を積むことができます。これにより、特定のビジネスニーズに合わせたソリューション開発が可能になります。
AWS Workshops Catalog には数百のワークショップがあり、カテゴリー (Machine Learning、Security、Serverless)、AWS サービス (EC2、Lambda、S3)、複雑度 (100-Beginner から 400-Expert) による高度なフィルターリング機能を備えています。また、ワークショップのタイトル、説明、サービス、カテゴリーを横断した部分一致によるリアルタイム検索で、関連性の高いコンテンツを簡単に見付けることも可能です。カタログのコンテンツは、Builder Center の言語設定に基づいて自動的にローカライズされます。
Builder Center からワークショップへシームレスに移動し、自身の AWS アカウントでハンズオン形式のガイド付き学習を行えます。

AI と ML ワークロードのための新しい AWS Well-Architected レンズを発表
AWSは、新しい Responsible AI レンズと、更新された機械学習および生成 AIの Well-Architected レンズ をリリースしました。これらのレンズは、責任あるAIの実践、技術的卓越性、専門的なビジネスユースケースを優先するAIワークロードの実装を組織が支援するために設計されています。AIジャーニーのあらゆる段階にある組織に包括的なガイダンスを提供することで、責任ある、セキュアで、信頼性が高く、効率的なAIワークロードを構築するための構造化されたアプローチに対する高まるニーズに対応します。これらのレンズは、AI技術を扱うビジネスリーダー、データサイエンティスト、MLエンジニア、リスクおよびコンプライアンスの専門家にとって特に価値があります。
Responsible AI、生成 AI、機械学習の3つのAIレンズは、連携してAI開発のための包括的なガイダンスを提供します。
・Responsible AI レンズ: 安全で公正、かつセキュアなAI開発をガイドします。ビジネスニーズと技術要件のバランスを取り、実験から本番への移行を効率化するのに役立ちます。
・生成 AIレンズ: お客さまが大規模言語モデル (LLM) ベースのアーキテクチャーを評価するのに役立ちます。今回のアップデートには、Amazon SageMaker HyperPod ユーザー向けのガイダンス、Agentic AI に関する新しい知見、更新されたアーキテクチャーシナリオが含まれています。
・機械学習レンズ: 最新のAIと従来の機械学習アプローチの両方にわたるワークロードを組織が評価する際の指針となります。最近のアップデートでは、強化されたデータとAIの共同ワークフロー、AI支援開発機能、大規模なインフラプロビジョニング、カスタマイズ可能なモデルデプロイメントなどの主要分野に焦点を当てています。
これらの改善は、Amazon SageMaker Unified Studio、Amazon Q、Amazon SageMaker HyperPod、Amazon Bedrock などの主要なAWSサービスによって実現されています。

今週のWeekly AWSは、以上です。

最後までお読みいただき、ありがとうございました。

関連サービス