メインコンテンツへスキップ

【AWSデイリーアップデート】EventBridgeのSQSフェアキュー対応など

· loading · loading ·
kiitosu
著者
kiitosu
画像処理やデバイスドライバ、データ基盤構築からWebバックエンドまで、多様な領域に携わってきました。地図解析や地図アプリケーションの仕組みにも経験があり、幅広い技術を活かした開発に取り組んでいます。休日は草野球とランニングを楽しんでいます。
目次

AWSの基礎力をつけるためにAWS What’s Newを毎日目を通す事を始めました。 最初は日本語訳されたものを見ていたのですが、1週間ほど遅れて訳されるようなので、英語の情報を訳して整理することにしました。

本情報が役立つ人もいるかなと思い公開します。 個人的な理解なので、実際の情報は原典をあたってください。


本日のアップデート一覧
#

  • Amazon EventBridgeが、Amazon SQSのフェアキュー(Fair Queue)をターゲットとして直接サポートするようになりました。
  • Amazon RDS for PostgreSQLが、PostgreSQLの新しいマイナーバージョン 17.7, 16.11, 15.15, 14.20, 13.23 をサポートしました。
  • Amazon S3テーブルがAmazon CloudWatchメトリクスをサポートし、テーブルのストレージ、リクエスト、メンテナンス操作を監視できるようになりました。
  • 12TBのメモリを搭載したAmazon EC2 High Memory U7iインスタンス(u7i-12tb.224xlarge)が、新たに欧州(ストックホルム)リージョンで利用可能になりました。
  • AWS HealthがAmazon EventBridgeとの連携を強化し、AWS Healthイベントの受信方法に、より高い柔軟性と回復性を提供するようになりました。
  • AWS IoT Core Device Locationが、Amazon Sidewalkネットワークに接続されたIoTデバイスの位置情報を解決する機能を提供するようになりました。
  • AWS Transform for VMwareが、AWS上のLanding Zone Accelerator (LZA)ソリューション向けのネットワーク設定を自動生成する機能を提供するようになりました。
  • AWS Cost and Usage Report (CUR) 2.0に新しい列と粒度が追加され、EC2オンデマンドキャパシティ予約(ODCR)やML向けEC2キャパシティブロックのようなキャパシティ予約のコストと使用状況の可視性が向上しました。
  • Amazon ECS Service Connectが、AWS GovCloud (US)リージョンにおいて、異なるAWSアカウント間のシームレスなサービス間通信をサポートするようになりました。

気になったアップデート一覧
#

Amazon EventBridgeがSQSフェアキューをターゲットとしてサポートしました。マルチテナント環境でnoisy neighbor 問題に悩まされ、EventBridgeが選択肢から外れていた人は再考ですね。

S3テーブルがCloudWatchメトリクスをサポートしました。これでS3テーブルの利用状況を詳細に確認できるようになるので、利用の幅が広がりそうです。

あとは「Amazon ECS Service Connectのクロスアカウントサポート」今回はリージョン拡大の話でしたが、そもそも機能を知りませんでした。 https://aws.amazon.com/jp/about-aws/whats-new/2025/09/amazon-ecs-service-connect-cross-account-workloads/ アカウントをまたいでECS同士を接続できるんですね。


Amazon EC2 G6fインスタンスが追加リージョンで利用可能に
#

投稿日: 2025年11月13日

何ができるようになったのか
#

NVIDIA L4 GPUを搭載したAmazon EC2 G6fインスタンスが、新たに欧州(スペイン)およびアジアパシフィック(ソウル)リージョンで利用可能になりました。

何が嬉しいのか
#

これにより、さまざまなグラフィックスワークロードに対して、より柔軟でコスト効率の高い選択肢が提供されます。特に、GPUを8分の1(3GBのGPUメモリ)という小さなパーティションで利用できるため、要件に応じたリソースの最適化が可能です。

これまでとどう変わるのか
#

  • これまで: G6fインスタンスは限られたリージョンでのみ利用可能でした。
  • これから: 欧州(スペイン)とアジアパシフィック(ソウル)でも利用可能になり、より多くのユーザーがこのインスタンスの恩恵を受けられるようになります。

具体的なユースケース
#

  • メディア&エンターテイメント向けのリモートワークステーション
  • コンピュータ支援エンジニアリング(CAE)
  • 機械学習の研究
  • 空間可視化

Amazon EC2 I7iインスタンスが追加のAWSリージョンで利用可能に
#

投稿日: 2025年11月13日

何ができるようになったのか
#

第5世代Intel Xeonスケーラブルプロセッサを搭載したAmazon EC2 I7iインスタンスが、新たにAWSヨーロッパ(アイルランド)、アジアパシフィック(ソウル、香港)リージョンで利用可能になりました。

何が嬉しいのか
#

I4iインスタンスと比較して、コンピューティングパフォーマンスが最大23%向上し、価格性能比も10%以上改善されています。また、第3世代AWS Nitro SSDにより、リアルタイムストレージ性能が向上し、I/Oレイテンシが低減・安定化するため、I/O集約型でレイテンシに敏感なワークロードに最適です。

これまでとどう変わるのか
#

  • これまで: I7iインスタンスは限られたリージョンでのみ利用可能でした。
  • これから: ヨーロッパ(アイルランド)、アジアパシフィック(ソウル、香港)でも利用可能になり、これらの地域で高性能なストレージI/Oを必要とするワークロードを実行できるようになります。

具体的なユースケース
#

  • I/O集約型でレイテンシに敏感なワークロード
  • 高性能なリレーショナルデータベース
  • NoSQLデータベース
  • データ分析ワークロード

Amazon EC2 I8gインスタンスが追加のAWSリージョンで利用可能に
#

投稿日: 2025年11月13日

何ができるようになったのか
#

ストレージ集約型ワークロード向けに設計されたAmazon EC2 I8gインスタンスが、新たに欧州(ストックホルム)およびアジアパシフィック(大阪)リージョンで一般利用可能になりました。

何が嬉しいのか
#

I4gインスタンスと比較して、リアルタイムストレージ性能が向上し、ストレージI/Oのレイテンシが低減・安定化しています。AWS Nitro System上に構築されており、トランザクションデータベースやリアルタイム分析など、I/Oを多用するワークロードに高いパフォーマンスを提供します。

これまでとどう変わるのか
#

  • これまで: I8gインスタンスは限られたリージョンでのみ利用可能でした。
  • これから: 欧州(ストックホルム)とアジアパシフィック(大阪)でも利用可能になり、これらの地域でストレージ集約型の高性能ワークロードを実行できるようになります。

具体的なユースケース
#

  • トランザクションデータベース
  • NoSQLソリューション
  • リアルタイム分析プラットフォーム
  • データレイクハウス
  • AI/LLMトレーニングのための前処理

Amazon EC2 I8gインスタンスが追加のAWSリージョンで利用可能に
#

投稿日: 2025年11月13日

何ができるようになったのか
#

ストレージおよびI/O集約型ワークロード向けに設計されたAmazon EC2 I8gインスタンスが、新たにアジアパシフィック(ソウル)および南米(サンパウロ)リージョンで一般利用可能になりました。

何が嬉しいのか
#

最新の第3世代AWS Nitro SSDにより、TBあたりのリアルタイムストレージ性能が最大65%向上し、ストレージI/Oのレイテンシが最大50%低減、さらにそのばらつきも最大60%低減します。これにより、データベースやリアルタイム分析などのワークロードで、より高速で安定したパフォーマンスを実現できます。

これまでとどう変わるのか
#

  • これまで: I8gインスタンスは限られたリージョンでのみ利用可能でした。
  • これから: アジアパシフィック(ソウル)と南米(サンパウロ)でも利用可能になり、これらの地域で最高のパフォーマンスを要求するストレージ集約型ワークロードを実行できるようになります。

具体的なユースケース
#

  • トランザクション、リアルタイム、分散データベース(MySQL, PostgreSQL, MongoDBなど)
  • リアルタイム分析プラットフォーム(Apache Sparkなど)
  • データレイクハウス
  • AI/LLMトレーニングのための前処理

Amazon EventBridgeがSQSフェアキューをターゲットとしてサポート
#

投稿日: 2025年11月13日

何ができるようになったのか
#

Amazon EventBridgeが、Amazon SQSのフェアキュー(Fair Queue)をターゲットとして直接サポートするようになりました。

何が嬉しいのか
#

これにより、イベント駆動型アプリケーションの応答性が向上します。特にマルチテナントシステムにおいて、特定のテナント(“noisy neighbor”)が他のテナントのメッセージ処理を妨げる問題を緩和できます。フェアキューはコンシューマーグループ全体にメッセージを均等に分配するため、すべてのテナントで一貫したメッセージ処理時間を維持できます。

これまでとどう変わるのか
#

  • これまで: EventBridgeからSQSにイベントを送信する際、メッセージのグループ化や公平な分配を実現するには、追加のカスタムロジックが必要でした。
  • これから: EventBridgeのルールでSQSフェアキューを直接ターゲットとして指定し、MessageGroupIDを設定するだけで、テナント間の公平なメッセージ処理を簡単に実現できるようになります。

具体的なユースケース
#

  • 複数のチームやサービスがイベントストリームへ公平にアクセスする必要がある、スケーラブルなマルチテナントアプリケーションの構築。
  • SaaSアプリケーションで、特定の顧客のアクティビティが他の顧客の体験に影響を与えないようにする。

Amazon RDS for PostgreSQLがマイナーバージョン17.7, 16.11, 15.15, 14.20, 13.23をサポート
#

投稿日: 2025年11月13日

何ができるようになったのか
#

Amazon RDS for PostgreSQLが、PostgreSQLの新しいマイナーバージョン 17.7, 16.11, 15.15, 14.20, 13.23 をサポートしました。

何が嬉しいのか
#

PostgreSQLコミュニティによって提供されるセキュリティ修正やバグ修正の恩恵を受けることができます。また、バージョン15.15以上では新しい拡張機能 pgcollection が利用可能になり、順序付けられたキーバリューペアを効率的に管理することで、データベースのパフォーマンスを向上させることができます。

これまでとどう変わるのか
#

  • これまで: 古いマイナーバージョンしか利用できず、最新のセキュリティパッチやバグ修正、新機能を利用できませんでした。
  • これから: 最新のマイナーバージョンにアップグレードすることで、セキュリティが強化され、バグが修正され、新しい拡張機能 pgcollection を利用してパフォーマンスを改善できるようになります。

具体的なユースケース
#

  • セキュリティと安定性を重視する本番環境のPostgreSQLデータベースの運用。
  • PostgreSQL関数内で高速なインメモリデータ処理を必要とするアプリケーションで、pgcollection拡張機能を利用する。

Amazon S3テーブルがAmazon CloudWatchメトリクスをサポート
#

投稿日: 2025年11月13日

何ができるようになったのか
#

Amazon S3テーブルがAmazon CloudWatchメトリクスをサポートし、テーブルのストレージ、リクエスト、メンテナンス操作を監視できるようになりました。

何が嬉しいのか
#

S3テーブルを利用するアプリケーションのパフォーマンス追跡、異常検出、運用状態の監視が容易になります。ストレージ使用量、リクエスト数、エラー率、レイテンシなどのメトリクスをCloudWatchで可視化・アラート設定することで、プロアクティブな運用管理が可能になります。

これまでとどう変わるのか
#

  • これまで: S3テーブルの運用状況を詳細に把握するには、ログを分析するなど、追加の仕組みが必要でした。
  • これから: CloudWatchメトリクスがネイティブに提供されるため、S3テーブルの健全性やパフォーマンスを簡単に、かつリアルタイムに近い形で監視できるようになります。

具体的なユースケース
#

  • S3テーブルのストレージ使用量やオブジェクト数を追跡し、コストを最適化する。
  • リクエストのレイテンシやエラー率を監視し、アプリケーションのパフォーマンス問題を特定・解決する。
  • テーブルのメンテナンス(コンパクション)で処理されたデータ量を監視し、運用状況を把握する。
  • 特定のメトリクスにしきい値を設定し、異常が発生した際にCloudWatchアラームで通知を受け取る。

Amazon U7iインスタンスが欧州(ストックホルム)リージョンで利用可能に
#

投稿日: 2025年11月13日

何ができるようになったのか
#

12TBのメモリを搭載したAmazon EC2 High Memory U7iインスタンス(u7i-12tb.224xlarge)が、新たに欧州(ストックホルム)リージョンで利用可能になりました。

何が嬉しいのか
#

SAP HANA、Oracle、SQL Serverなどのミッションクリティカルなインメモリデータベース向けに、大容量メモリと高性能なコンピューティングリソースを提供します。第4世代Intel XeonスケーラブルプロセッサとDDR5メモリを搭載し、高速なデータロードとバックアップのための最大100GbpsのEBS帯域幅、最大100Gbpsのネットワーク帯域幅を備えています。

これまでとどう変わるのか
#

  • これまで: 欧州(ストックホルム)リージョンでは、12TBメモリ搭載のU7iインスタンスは利用できませんでした。
  • これから: このリージョンでも大規模なインメモリデータベースを運用できるようになり、地域に根ざしたデータ処理や低レイテンシのアクセスが可能になります。

具体的なユースケース
#

  • SAP HANAデータベースの実行
  • Oracleインメモリデータベースの運用
  • SQL Serverインメモリデータベースの運用
  • その他、大規模なメモリを必要とするミッションクリティカルなアプリケーション

AWS HealthがAmazon EventBridgeとの連携を強化し、柔軟性と回復性を向上
#

投稿日: 2025年11月13日

何ができるようになったのか
#

AWS HealthがAmazon EventBridgeとの連携を強化し、AWS Healthイベントの受信方法に、より高い柔軟性と回復性を提供するようになりました。

何が嬉しいのか
#

2つの大きなメリットがあります。

  1. 回復性の向上: すべてのHealthイベントが、影響を受けるリージョンとUS West (Oregon)リージョンの両方に同時に送信されるようになりました。これにより、一方のリージョンで問題が発生しても、もう一方のリージョンでイベントを確実に受信できるバックアップ構成を簡単に組むことができます。
  2. 設定の簡素化: US West (Oregon)リージョンに単一のEventBridgeルールを設定するだけで、すべての商用リージョンにまたがるHealthイベントをすべてキャプチャできるようになりました。これにより、各リージョンで個別にルールを設定する手間が省けます。

これまでとどう変わるのか
#

  • これまで: Healthイベントは基本的に影響を受けるリージョンでのみ受信していました。そのため、全リージョンのイベントを監視するには各リージョンに設定が必要で、リージョン障害時の冗長性確保も複雑でした。
  • これから: US West (Oregon)リージョンを中央ハブとして利用することで、設定を簡素化しつつ、マルチリージョンの冗長性を確保したイベント受信アーキテクチャを容易に構築できるようになります。

具体的なユースケース
#

  • 全リージョンのAWS Healthイベントを単一の場所に集約し、一元的に監視・分析する。
  • 重要なHealthイベント(サービス障害など)を見逃さないように、リージョンをまたいだ冗長構成を組んで通知の信頼性を高める。
  • 複数のAWSアカウントやリージョンにまたがる運用自動化のトリガーとして、Healthイベントをより確実に利用する。

AWS IoT CoreがAmazon Sidewalk対応デバイス向けに位置情報解決機能を追加
#

投稿日: 2025年11月13日

何ができるようになったのか
#

AWS IoT Core Device Locationが、Amazon Sidewalkネットワークに接続されたIoTデバイスの位置情報を解決する機能を提供するようになりました。

何が嬉しいのか
#

これにより、低電力デバイスにGPSハードウェアを搭載することなく、アセットトラッキングやジオフェンシングといった位置情報ベースのアプリケーションを構築できます。Wi-FiアクセスポイントやBluetooth Low Energyなどのデータを利用してデバイスのおおよその位置を特定し、その座標データをAWS IoTルールやMQTTトピック経由でバックエンドアプリケーションに連携できます。

これまでとどう変わるのか
#

  • これまで: Sidewalkデバイスで位置情報を利用するには、GPSなどの専用ハードウェアを組み込むか、位置を特定するための複雑なカスタムロジックを自前で実装する必要がありました。
  • これから: AWS IoT Coreが位置解決をサービスとして提供するため、開発者はハードウェアの追加コストや複雑な実装なしに、Sidewalkデバイスの位置情報を簡単に取得し、アプリケーションに活用できるようになります。

具体的なユースケース
#

  • ペットや貴重品に取り付けた低電力トラッカーの位置を追跡する。
  • 特定のエリア(ジオフェンス)へのデバイスの出入りを検知して通知を送信する。
  • 屋外に設置されたセンサーなど、広範囲に分散したIoTデバイスのおおよその位置を把握する。

AWS TransformがLanding Zone Acceleratorのネットワーク設定を自動化
#

投稿日: 2025年11月13日

何ができるようになったのか
#

AWS Transform for VMwareが、AWS上のLanding Zone Accelerator (LZA)ソリューション向けのネットワーク設定を自動生成する機能を提供するようになりました。

何が嬉しいのか
#

この新機能により、既存のVMwareネットワーク環境を、LZAと互換性のあるネットワーク設定YAMLファイルに自動的に変換できます。これにより、クラウドインフラのセットアップが合理化され、ワークロードをAWSに移行する際の手作業が削減されます。

これまでとどう変わるのか
#

  • これまで: VMware環境からAWSのLZAに移行する際、ネットワーク設定は手動でLZAのフォーマットに合わせて作成する必要があり、時間と手間がかかりました。
  • これから: AWS TransformがVMwareのネットワーク構成を分析し、LZA用の設定ファイルを自動生成してくれるため、移行プロセスが大幅に簡素化・迅速化されます。

具体的なユースケース
#

  • オンプレミスのVMware環境からAWSへ、大規模なワークロードを移行する。
  • AWSのベストプラクティスに基づいたセキュアでスケーラブルなマルチアカウント環境(Landing Zone)を迅速に構築する際に、既存のネットワーク構成を再利用したい場合。

AWS CUR 2.0がEC2 ODCRとML向けキャパシティブロックのモニタリングを強化
#

投稿日: 2025年11月12日

何ができるようになったのか
#

AWS Cost and Usage Report (CUR) 2.0に新しい列と粒度が追加され、EC2オンデマンドキャパシティ予約(ODCR)やML向けEC2キャパシティブロックのようなキャパシティ予約のコストと使用状況の可視性が向上しました。

何が嬉しいのか
#

キャパシティ予約の利用率とカバレッジの計算、未使用キャパシティの特定によるコスト最適化、リソース所有者へのコスト配賦が容易になります。CUR 2.0では、キャパシティ予約関連の項目が「予約済み(Reserved)」「使用済み(Used)」「未使用(Unused)」としてラベル付けされるため、カバレッジと使用率の計算が簡素化されます。

これまでとどう変わるのか
#

  • これまで: キャパシティ予約のコストと使用状況を詳細に分析するには、複数のデータソースを組み合わせるなど複雑な処理が必要でした。
  • これから: CUR 2.0のレポートだけで、どのEC2インスタンスのコストと使用量がどのキャパシティ予約によってカバーされているかを、時間単位のリソースレベルで簡単に特定できるようになります。

具体的なユースケース
#

  • 予約したEC2キャパシティが実際にどれだけ使われているかを正確に把握し、無駄な予約を削減してコストを最適化する。
  • 特定のプロジェクトやチームが使用しているキャパシティ予約のコストを正確にチャージバックする。
  • キャパシティ予約のカバレッジ率を監視し、重要なワークロードが必要なキャパシティを常に確保できるようにする。

Service ConnectのクロスアカウントサポートがAWS GovCloud (US)リージョンで利用可能に
#

投稿日: 2025年11月13日

何ができるようになったのか
#

Amazon ECS Service Connectが、AWS GovCloud (US)リージョンにおいて、異なるAWSアカウント間のシームレスなサービス間通信をサポートするようになりました。

何が嬉しいのか
#

AWS Resource Access Manager (AWS RAM)との統合により、AWS Cloud Mapの名前空間を共有することで、クロスアカウントのサービス間通信が簡素化されます。これにより、マルチアカウントアーキテクチャを持つ組織は、リソースの重複を減らし、環境全体で一貫したサービス間通信を促進できます。

これまでとどう変わるのか
#

  • これまで: 異なるアカウントのECSサービス間で通信するには、VPCピアリングやTransit Gatewayなどの複雑なネットワーク設定や、サービスディスカバリのためのカスタムソリューションが必要でした。
  • これから: AWS RAMを使ってCloud Mapの名前空間を共有するだけで、Service Connectがクロスアカウントのサービスディスカバリと接続を管理してくれるため、運用効率が向上し、スケーリングが容易になります。

具体的なユースケース
#

  • 複数のAWSアカウントにまたがるマイクロサービスアーキテクチャで、サービス間の安全で簡単な通信を実現する。
  • 中央の共有サービス(認証サービスなど)を、組織内の複数のアカウントから利用する。
  • 開発、ステージング、本番など、異なるアカウントで管理されている環境間で、一貫したサービスディスカバリメカニズムを確立する。
Reply by Email

関連記事

【AWSデイリーアップデート】Amazon CloudWatch Composite Alarms がしきい値ベースのアラートに対応
· loading · loading
【AWSデイリーアップデート】CloudWatch SyntheticsがマルチチェックCanaryをサポート、API監視を効率化
· loading · loading
【AWSデイリーアップデート】BedrockのAIモデル拡充とStep Functions、Aurora、RDSのAI/ML連携強化
· loading · loading