aws_whats_new_2025-08-02

はじめに

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

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

AWS Directory Service が Managed Microsoft AD のハイブリッド版を開始

投稿日: 2025年8月1日

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

AWS Directory Service for Microsoft Active Directoryに新しく「ハイブリッド版」が登場しました。これにより、既存のオンプレミスのActive DirectoryドメインをAWSに拡張し、マネージドサービスとして利用できるようになります。

何が嬉しいのか

このハイブリッド版は、オンプレミス、AWSクラウド、マルチクラウド環境にまたがるActive Directoryインフラストラクチャを統一的に管理できるため、ADに依存するワークロードのクラウド移行が大幅に簡素化されます。既存のアクセス制御やグループポリシーを再設定することなく、そのまま維持できるのが大きな利点です。

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

• これまで
  • 既存のADをAWSに拡張するには、EC2インスタンス上で自己管理型のADを構築するか、AWS Managed Microsoft ADをスタンドアロンで使用する必要がありました。
• これから
  • ハイブリッド版を利用することで、AWSがAD環境間の複製やメンテナンスを自動的に処理してくれるため、インフラ管理の運用負荷が大幅に削減されます。

具体的なユースケース

• 既存のオンプレミスAD環境を活かしながら、Amazon EC2、Amazon FSx for Windows File Server、Amazon RDSといったAD認証を必要とするアプリケーションをAWSに移行する。
• 複数のAWSアカウントにまたがるAWSサービスとシームレスに統合する。
• AWS Secrets Managerを利用して管理者認証情報を安全に共有し、認証情報が直接参照されるリスクをなくす。

Amazon CloudWatch が OpenSearch PPL と SQL の自然言語クエリ生成を開始

投稿日: 2025年8月1日

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

Amazon CloudWatch Logs Insightsで、OpenSearch PPL（Piped Processing Language）およびSQLクエリ言語に対し、生成AIを活用した自然言語でのクエリ生成機能が利用可能になりました。

何が嬉しいのか

クエリ言語に詳しくなくても、平易な英語で質問するだけでクエリが自動生成されるため、ログ分析にかかる時間が大幅に短縮されます。これにより、エンジニアはより迅速にインサイトを得ることができます。

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

• これまで
  • CloudWatch Logs InsightsでOpenSearch PPLやSQLを利用するには、ユーザー自身がクエリの構文を理解し、手動で作成する必要がありました。
• これから
  • 「1時間あたりのエラーと例外の数を教えて」や「転送バイト数が多い上位100の送信元IPアドレスは？」といった自然言語での問い合わせで、PPLまたはSQLのクエリが自動的に生成されるようになります。

具体的なユースケース

• アプリケーションのパフォーマンス分析時に、複雑なログクエリを手動で作成する代わりに、「レスポンスタイムが遅い上位10件のリクエストを教えて」のように自然言語で問い合わせる。
• セキュリティインシデントの調査において、「特定IPアドレスからのアクセスログを時系列で表示して」といった指示を出すことで、迅速に状況を把握する。

Amazon SES が自動評価ポリシーによるテナント分離を導入

投稿日: 2025年8月1日

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

Amazon Simple Email Service (SES) で、単一のSESアカウント内に分離された「テナント」をプロビジョニングし、自動化された評価ポリシーを適用してメール送信を管理できるようになりました。

何が嬉しいのか

この機能により、顧客や部門ごとにテナントを作成し、それぞれに専用の設定セット、ID、テンプレートを割り当てることができます。配信性の問題が発生した場合、影響を受けるテナントのみを特定・隔離できるため、アカウント全体の送信者評価を保護し、メールの到達率を向上させることができます。

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

• これまで
  • SESアカウント全体の評価は共有されており、一部のメール送信ストリームの問題がアカウント全体の評価に悪影響を与えるリスクがありました。
• これから
  • テナントごとに評価が分離されます。問題が検出された場合、SESは影響を受けるテナントの送信を自動的に一時停止し、他のメールストリームを保護します。この自動化は、「標準」「厳格」「なし」の3つの評価ポリシーから選択できます。

具体的なユースケース

• 複数の顧客にメール送信サービスを提供するSaaSプロバイダーが、各顧客を個別のテナントとして管理し、ある顧客の送信問題が他の顧客に影響を与えないようにする。
• 開発、ステージング、本番環境で異なるテナントを使用し、テスト目的のメール送信が本番環境の送信評価に影響を与えないようにする。

Amazon RDS for MySQL が新しいマイナーバージョン 8.0.43 と 8.4.6 をサポート開始

投稿日: 2025年8月1日

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

Amazon RDS for MySQLが、MySQLの新しいマイナーバージョン8.0.43と8.4.6をサポート開始しました。

何が嬉しいのか

MySQLコミュニティによってリリースされた最新のマイナーバージョンにアップグレードすることで、既知のセキュリティ脆弱性の修正、バグ修正、パフォーマンスの向上、新機能といった恩恵を受けることができます。

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

• これまで
  • ユーザーは以前のマイナーバージョンのMySQLを利用していました。
• これから
  • 最新のマイナーバージョンにアップグレードすることで、より安全で高機能なデータベース環境を構築できます。アップグレードは、自動マイナーバージョンアップグレード機能や、より安全なAmazon RDS Managed Blue/Green Deploymentsを利用して行うことができます。

具体的なユースケース

• データベースのセキュリティを最新の状態に保つために、定期的なメンテナンスウィンドウで自動的にマイナーバージョンをアップグレードする。
• 新しい機能やパフォーマンス改善を享受するために、Blue/Greenデプロイメントを利用して、ダウンタイムを最小限に抑えながら安全にデータベースを更新する。

Amazon S3 アクセスポイントが属性ベースのアクセス制御（ABAC）のためのタグをサポート

投稿日: 2025年8月1日

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

Amazon S3のアクセスポイントで、属性ベースのアクセス制御（ABAC）のためのタグ付けがサポートされるようになりました。

何が嬉しいのか

アクセスポイントにタグを追加し、そのタグに基づいてアクセス権限を管理できるようになります。これにより、IAMポリシーやバケットポリシーを頻繁に更新する必要がなくなり、共有データセットに対するアクセス管理のスケーリングが大幅に簡素化されます。

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

• これまで
  • アクセス制御は主にユーザーやロールに直接関連付けられたポリシーに基づいており、アクセスポイントが増えるたびにポリシーの更新が必要になる場合がありました。
• これから
  • アクセスポイントに付けられたタグを条件としてIAMポリシーを記述できます。例えば、「プリンシパルのタグとアクセスポイントのタグが一致する場合にのみアクセスを許可する」といったルールを一度作成すれば、あとはタグを管理するだけでアクセス制御が可能になります。

具体的なユースケース

• 大規模な組織で、プロジェクトや部門ごとにS3アクセスポイントを作成し、それぞれに project: "phoenix" や department: "research" といったタグを付与する。
• IAMポリシーで、ユーザーのタグとアクセスポイントのタグが一致する場合にのみデータへのアクセスを許可するように設定し、ポリシーを変更することなく、新しいプロジェクトやユーザーに柔軟に対応する。

S3アクセスポイントについてはこちら

https://dev.classmethod.jp/articles/explain-the-good-point-of-s3-access-points/

Amazon EC2 がインスタンスの強制終了をサポート

投稿日: 2025年8月1日

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

Amazon EC2で、shutting-down（シャットダウン中）の状態でスタックしてしまったインスタンスを、強制的に終了できるようになりました。

何が嬉しいのか

OSのフリーズや基盤となるハードウェアの稀な問題によってインスタンスが応答しなくなった場合でも、AWSのサポートを待つことなく、ユーザー自身で迅速にインスタンスを終了させることができます。これにより、インスタンスに紐づくvCPUクォータやElastic IPアドレスなどのリソースを素早く解放できます。

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

• これまで
  • インスタンスがshutting-down状態でスタックした場合、ユーザーはリソースを解放するためにAWSの介入を待つ必要がありました。
• これから
  • EC2コンソールまたはAWS CLIから強制終了を実行できます。この操作は、まず通常のシャットダウンを試み、失敗した場合に強制的なシャットダウンに移行します。ただし、強制シャットダウンではファイルシステムのキャッシュやメタデータがフラッシュされない可能性がある点に注意が必要です。

具体的なユースケース

• 自動化されたワークフローで、インスタンスが正常にシャットダウンせず、後続のプロセスがブロックされてしまう場合に、強制終了機能を使ってワークフローを継続させる。
• 開発・テスト環境で、応答しなくなったインスタンスを迅速にクリーンアップし、関連リソースを解放してコストを節約する。

Amazon Kinesis Video Streams が新たに3つのAWSリージョンで利用可能に

投稿日: 2025年8月1日

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

Amazon Kinesis Video Streams (KVS) が、新たに欧州（スペイン）、アジアパシフィック（マレーシア）、中東（バーレーン）の3つのAWSリージョンで利用可能になりました。

何が嬉しいのか

これらのリージョンで事業を展開する組織は、KVSを利用することで、より高速な応答時間、厳格なデータ所在地の管理、データ転送コストの削減といったメリットを享受できます。

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

• これまで
  • 対象の3リージョンではKVSが提供されておらず、近隣の他リージョンを利用する必要がありました。これにより、レイテンシの増加やデータ主権に関する制約が生じる可能性がありました。
• これから
  • 対象リージョン内で直接KVSを利用できるため、低レイテンシでのビデオストリーミング処理が可能になり、各国のデータガバナンス要件にも準拠しやすくなります。

具体的なユースケース

• スペイン国内で展開するスマートシティプロジェクトにおいて、監視カメラからの映像を低遅延で処理・分析するために、欧州（スペイン）リージョンのKVSを活用する。
• マレーシアの製造業者が、工場の生産ラインの様子をリアルタイムでストリーミングし、Amazon Rekognition Videoと連携させて製品の品質管理を自動化する。
• バーレーン国内のインフラ設備の遠隔監視にKVSを使用し、現地のデータを国内で完結させて処理・保存する。

AWS IoTサービスが欧州（スペイン）とアジアパシフィック（マレーシア）リージョンに拡大

投稿日: 2025年7月31日

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

AWS IoT Core、AWS IoT Device Management、AWS IoT Device Defender、AWS IoT Greengrassといった主要なIoTサービスが、新たに欧州（スペイン）およびアジアパシフィック（マレーシア）リージョンで利用可能になりました。

何が嬉しいのか

これらのリージョンで事業を展開する組織は、IoTデバイスの接続、管理、保護を現地で行えるようになります。これにより、応答時間の短縮、データ所在地の管理強化、データ転送コストの削減といった複数のメリットを享受できます。

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

• これまで
  • 対象リージョンではこれらの主要なIoTサービスが提供されておらず、IoTソリューションを構築する際には近隣の他リージョンを利用する必要がありました。
• これから
  • デバイスの接続から管理、セキュリティ監視、エッジでのソフトウェア実行まで、一連のIoTワークロードを対象リージョン内で完結させることができ、より低遅延で効率的なシステムを構築できます。

具体的なユースケース

• スペインのスマートシティプロジェクトで、市内のセンサーデータを欧州（スペイン）リージョンのIoT Coreでリアルタイムに収集・分析する。
• マレーシアの製造業者が、工場のエッジデバイスにIoT Greengrassをデプロイし、クラウドで学習させた機械学習モデルを使ってローカルで異常検知推論を実行する。

AWS IoT Core が MQTT共有サブスクリプション向けのメッセージキューイングをサポート

投稿日: 2025年7月31日

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

AWS IoT Core が MQTT共有サブスクリプション向けのメッセージキューイングをサポートしました。これにより、ネットワークの切断中にIoTアプリケーションがメッセージ配信の信頼性を維持できるようになります。共有サブスクリプショングループの全メンバーが切断されたり、受信メッセージ量を処理できなかったりする場合、サービスは永続セッションにQoS 1メッセージを自動的にキューイングします。キューイングされたメッセージは、共有サブスクライバーが再接続したとき、またはグループに共有サブスクライバーが追加されたときに自動的に配信されます。

何が嬉しいのか

接続の問題やピーク時の負荷の間でも、重要なデータを保持できます。MQTT v3.1.1 および 5.0 クライアントと完全に互換性があります。

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

• これまで
  共有サブスクリプション向けのメッセージキューイングが組み込まれてなかったため、切断中にデータ損失や配信問題が発生する可能性がありました。
• これから
  キューイングにより、サブスクライバーが再接続したり、新しいサブスクライバーが追加されたりした際にメッセージ配信が保証され、信頼性が向上します。

具体的なユースケース

• ネットワーク接続が不安定な場合でも信頼性の高いメッセージ配信が必要なIoTアプリケーション。
• 一時的にサブスクライバーが利用できなくなった場合にデータ損失を防ぐ必要がある、大量のメッセージを処理するシステム。

Amazon SNS 標準トピックが Amazon SQS の公平キューイングをサポート

投稿日: 2025年7月31日

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

Amazon SNS 標準トピックがメッセージグループIDをサポートするようになり、すべてのサブスクライブされたAmazon SQS標準キューで公平キュー機能が有効になりました。これにより、複数のテナントキューでの「うるさい隣人」の影響を軽減し、あるテナントからの高ボリュームまたは低速処理メッセージが他のテナントからのメッセージを遅延させるのを防ぐことができます。

何が嬉しいのか

メッセージグループIDをAmazon SNS標準トピックに送信するメッセージに含めると、トピックはこれらのIDをすべてのサブスクライブされたAmazon SQS標準キューに自動的に転送し、それらのキュー全体で公平キュー動作をアクティブにします。これは、複数の処理キューにメッセージを配信するためにAmazon SNSを使用するSaaSアプリケーション、複数の顧客にサービスを提供するイベント駆動型アーキテクチャ、およびさまざまなリクエストタイプ間でサービス品質を維持する必要があるマイクロサービスにとって特に価値があります。

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

• これまで
  SNS標準トピックは、SQS公平キューのためのメッセージグループIDを本質的にサポートしていなかったため、単一テナントの高メッセージボリュームが他のテナントに影響を与える可能性がありました。
• これから
  SNS標準トピックにメッセージを送信する際にメッセージグループIDを含めることで、トピックはこれらのIDをサブスクライブされたSQS標準キューに自動的に転送し、公平キュー動作をアクティブにします。

具体的なユースケース

• 複数の処理キューにメッセージを配信するためにAmazon SNSを使用するSaaSアプリケーション。
• 複数の顧客にサービスを提供するイベント駆動型アーキテクチャ。
• さまざまなリクエストタイプ間でサービス品質を維持する必要があるマイクロサービス。

Noisy Neighbor問題とは
Queueが特定のSNSからのメッセージで埋め尽くされてしまい、その他のSNSからのメッセージの処理に遅延が起きること。SNSのメッセージグループIDによるラウンドロビン方式ができるようになるということですね。

さいごに

個人的には Amazon CloudWatch が OpenSearch PPL と SQL の自然言語クエリ生成を開始 が便利だと思いました。 Logs Insights QL の構文がなかなかおぼえられないんですよね。。。

AWS IoT Core が MQTT共有サブスクリプション向けのメッセージキューイングをサポート や Amazon SNS 標準トピックが Amazon SQS の公平キューイングをサポート のメッセージングサービスの進化も、これまで無理やり実装していた仕組みなどが不要になりそうないい感じの追加機能ですね。