はじめに
AWSの基礎力をつけるためにAWS What's Newを毎日目を通す事を始めました。
最初は日本語訳されたものを見ていたのですが、1週間ほど遅れて訳されるようなので、英語の情報を訳して整理することにしました。
本情報が役立つ人もいるかなと思い公開します。
個人的な理解なので、実際の情報は原典をあたってください。
Amazon Managed Service for Prometheus がリソースベースのポリシーをサポート
投稿日: 2025年08月15日
何ができるようになったのか
フルマネージド型のPrometheus互換モニタリングサービスであるAmazon Managed Service for Prometheus (AMP) が、リソースベースのポリシーをサポートするようになりました。これにより、クロスアカウントで動作するアプリケーションの構築が容易になります。
何が嬉しいのか
リソースベースのポリシーを使用すると、どのIdentity and Access Management (IAM) プリンシパルがAMPワークスペースへのデータ取り込みやクエリにアクセスできるかを指定できます。
これまでとどう変わるのか
-
これまで
- クロスアカウントでの取り込みやクエリを行うには、ワークスペース所有者アカウントでIAMロールを引き受ける必要がありました。
-
これから
- AMPワークスペースにリソースベースのポリシーをアタッチし、ワークスペース所有者以外のユーザーがPrometheus互換APIを使用して任意のアクションを実行できるように許可リストに追加することが可能になります。
具体的なユースケース
- クロスアカウントでのPrometheusデータ収集とクエリの簡素化、およびIAMプリンシパルによるAMPワークスペースへのアクセス制御の強化。
AWS Billing and Cost Management コンソールに新しい推奨アクションが追加されました。
投稿日: 2025年08月15日
何ができるようになったのか
AWS Billing and Cost Management コンソールに6つの新しい推奨アクションが追加され、既存の15のアクションと合わせて利用可能になりました。これらのアクションは、支払い方法の期限切れや税務登録番号の無効化など、AWSの支払いおよび税金設定に関する通知を含みます。
何が嬉しいのか
推奨アクションは「クリティカル」「アドバイザリ」「情報」の3つのカテゴリに分類され、請求問題の優先順位付けと迅速な解決を支援します。顧客は、請求や支払いに関する問題を軽減し、コスト削減の機会を特定し、予期せぬ事態を回避できます。各アクションには具体的な行動喚起が含まれており、AWSの利用料金を最適化し、アカウントや請求ステータスの中断を防ぎます。
これまでとどう変わるのか
-
これまで
- 推奨アクションの数が少なかったり、カテゴリ分けがされていなかったため、請求問題の優先順位付けや迅速な解決が難しかった可能性があります。
-
これから
- 今回の追加により、合計21の推奨アクションが「クリティカル」「アドバイザリ」「情報」の3つのカテゴリに分類され、支払い方法の期限切れや税務登録番号の無効化など、より多様な支払いおよび税金設定に関する通知を受け取れるようになります。これにより、請求問題の優先順位付けと迅速な解決が容易になり、コスト削減や予期せぬ事態の回避に役立ちます。
具体的なユースケース
- AWSの支払い方法の期限切れや税務登録番号の無効化などの請求関連の問題を早期に発見し、迅速に対処する。AWSの利用料金を最適化し、アカウントや請求ステータスの中断を防ぐ。
Amazon Connect Cases がケース作成時の自動更新ルールに対応
投稿日: 2025年08月15日
何ができるようになったのか
Amazon Connect Cases に、ケース作成時に自動的にケースを更新するルールが追加されました。これにより、ケースのワークフローが効率化され、手動での作業が削減されます。
何が嬉しいのか
返金ケースを自動的に経理チームに割り当てる。フォローアップが不要なケースを自動的にクローズする。ケースの理由に基づいて優先度を自動設定する。
これまでとどう変わるのか
-
これまで
- これまでは、Amazon Connect Cases でケース作成後の更新を手動で行う必要があり、ワークフローの効率が低下し、手動作業の負担がありました。
-
これから
- 今回の機能追加により、ケース作成時に自動的にケースを更新するルールを設定できるようになり、ワークフローが効率化され、手動での作業が大幅に削減されます。
具体的なユースケース
- 返金ケースを自動的に経理チームに割り当てることで、迅速な対応と担当部署への適切なルーティングを実現する。
- フォローアップが不要なケースを自動的にクローズすることで、オペレーターの負担を軽減し、未処理ケースの蓄積を防ぐ。
- ケースの理由に基づいて優先度を自動設定することで、重要なケースから優先的に処理し、顧客満足度を向上させる。
Amazon Athena が Amazon S3 テーブルでの CREATE TABLE AS SELECT (CTAS) ステートメントをサポートしました。
投稿日: 2025年08月15日
何ができるようになったのか
Amazon Athena が Amazon S3 テーブルでの CREATE TABLE AS SELECT (CTAS) ステートメントをサポートしました。これにより、単一の SQL ステートメントで SELECT クエリの結果を使用して新しいテーブルを作成し、データを投入することが容易になります。S3 テーブルは Apache Iceberg の組み込みサポートを提供し、表形式データのスケーラブルな保存を効率化します。この機能により、Parquet、CSV、JSON、Apache Iceberg、Hudi、Delta Lake などの既存のデータセットを、パフォーマンスとコストのために継続的に最適化されるフルマネージドテーブルに迅速かつ効率的に変換できます。
何が嬉しいのか
CTAS を使用すると、データをオンザフライでパーティション分割できるため、さまざまなユースケースに合わせてクエリパフォーマンスを最適化する柔軟性が得られます。
これまでとどう変わるのか
-
これまで
- これまでは、Amazon Athena で S3 上のデータから新しいテーブルを作成し、データを投入するには、複数のステップや複雑なプロセスが必要でした。また、既存のデータセットを最適化されたフルマネージドテーブルに変換する際も、手動での作業や追加のツールが必要となる場合がありました。
-
これから
- 今回の機能追加により、Amazon Athena で単一の SQL ステートメント (CTAS) を使用して、SELECT クエリの結果から直接 Amazon S3 テーブルに新しいテーブルを作成し、データを投入できるようになりました。これにより、データ変換プロセスが簡素化され、Parquet、CSV、JSON、Apache Iceberg、Hudi、Delta Lake などの既存のデータセットを、パフォーマンスとコストのために最適化されたフルマネージドテーブルに迅速かつ効率的に変換できます。さらに、CTASによるオンザフライでのデータパーティション分割が可能になり、クエリパフォーマンスの最適化が容易になります。
具体的なユースケース
-
既存のS3上のデータから、クエリパフォーマンスを最適化した新しいテーブルを簡単に作成する。
-
異なるフォーマットのデータセットを、Apache Icebergなどのフルマネージドテーブルに変換し、データレイクの管理を効率化する。
-
分析要件に応じてデータを動的にパーティション分割し、クエリの実行速度を向上させる。
Amazon DynamoDB がより詳細なスロットリングエラー例外をサポート
投稿日: 2025年08月15日
何ができるようになったのか
Amazon DynamoDB は、より詳細なスロットリング例外と、それに対応する Amazon CloudWatch メトリクスのサポートを開始しました。この機能強化により、スロットリングイベントの特定のリソースと理由を識別しやすくなり、問題の理解と診断が容易になります。新しいスロットリング例外には、リクエストがスロットリングされた理由のリストと、スロットリングされたテーブルまたはインデックスの Amazon リソースネーム (ARN) が含まれます。
何が嬉しいのか
これにより、スループットの調整、オンデマンドキャパシティモードへの切り替え、データアクセスパターンの最適化といった是正措置を講じることが可能になります。
これまでとどう変わるのか
-
これまで
- これまでは、DynamoDBのスロットリングエラーは詳細な情報を含んでおらず、どのリソースが、どのような理由でスロットリングされたのかを特定するのが困難でした。そのため、問題の診断や適切な是正措置の特定に時間がかかり、運用上の課題となっていました。
-
これから
- 今回の機能強化により、DynamoDBのスロットリング例外に、スロットリングされた理由のリストと、スロットリングされたテーブルまたはインデックスのARNが含まれるようになりました。また、対応するCloudWatchメトリクスも提供されます。これにより、スロットリングイベントの原因をより詳細に特定し、スループットの調整、オンデマンドキャパシティモードへの切り替え、データアクセスパターンの最適化といった具体的な是正措置を迅速に講じることが可能になります。
具体的なユースケース
- DynamoDBアプリケーションで発生するスロットリングエラーの原因を迅速に特定し、パフォーマンスボトルネックを解消する。
- 特定のテーブルやインデックスのスロットリング状況をCloudWatchメトリクスで監視し、キャパシティプランニングやデータアクセスパターンの最適化に役立てる。
- スロットリングエラーに基づいて、自動的にキャパシティを構築する。
Amazon DynamoDB が CloudWatch Contributor Insights のスロットルされたキー専用モードをサポート
投稿日: 2025年08月15日
何ができるようになったのか
Amazon DynamoDB は、CloudWatch Contributor Insights の新しいモードをサポートしました。これにより、スロットルされたキーのイベントのみを選択的に CloudWatch Contributor Insights に出力できるようになり、すべてのアクセスされたキーのイベントを出力することなく、スロットルされたキーを監視できます。
何が嬉しいのか
この新機能により、すべての成功したリクエストイベントに対して料金を支払う必要がなくなり、コストを削減できます。また、トラフィックパターン、最もアクセスされたキーやスロットルされたキーに関する情報を得ることで、アプリケーションの使用状況の理解やスロットリング関連の問題の診断に役立ちます。
これまでとどう変わるのか
-
これまで
- これまでは、DynamoDBのスロットリングされたキーをCloudWatch Contributor Insightsで監視するには、すべてのアクセスされたキーのイベントを出力する必要があり、その分のコストが発生していました。また、スロットリングされたキーのみに焦点を当てた監視が困難でした。
-
これから
- 今回の機能追加により、CloudWatch Contributor Insightsにスロットルされたキー専用モードが導入されました。これにより、スロットルされたキーのイベントのみを選択的に出力できるようになり、すべてのアクセスされたキーのイベントを出力することなく、スロットリングされたキーを効率的に監視できます。結果として、不要なデータ出力によるコストを削減しつつ、スロットリング関連の問題の診断と解決をより迅速に行えるようになります。
具体的なユースケース
- DynamoDBのホットパーティションやアクセス集中によるスロットリング問題を特定し、コストを抑えながら効率的に監視する。
- スロットリングされたキーのパターンを分析し、アプリケーションのデータアクセスパターンを最適化する。
- スロットリングイベントに基づいて、自動的にキャパシティを構築する。
CloudWatch Logs Contributor Insights は、AWS CloudWatch の機能の一つで、ログデータをリアルタイムに解析して「どの要素がログやメトリクスの発生に寄与しているか(contributor)」を可視化する仕組みです。
特徴
- リアルタイム集計: ログストリームを解析し、どのユーザー・IP・API・サービスが最も多くのリクエストやエラーを発生させているかを把握できます。
- 上位寄与者の可視化: 例えば「特定の API を叩いているトップ10の IP アドレス」や「エラーを出しているユーザーID」などをランキング形式で表示。
- メトリクス連携: 解析結果は CloudWatch メトリクスとして出力でき、アラームやダッシュボードで利用可能。
使いどころ
- Lambda / API Gateway / VPC Flow Logs などで「誰がリソースを使っているのか」を突き止めたいとき。
- アクセスのスパイクや不正利用の調査。
- エラー原因の特定(例: どのユーザーが 500 エラーを多発させているか)。
AWS Certificate Manager が AWS PrivateLink をサポート
投稿日: 2025年08月15日
何ができるようになったのか
AWS Certificate Manager (ACM) が AWS PrivateLink をサポートしました。これにより、Amazon Virtual Private Cloud (VPC) からパブリックインターネットを経由せずに ACM API にアクセスできるようになります。
何が嬉しいのか
この機能により、ACM API へのアクセスと利用が AWS ネットワーク内で完結するため、コンプライアンス要件を満たすのに役立ちます。VPC と ACM 間の通信が AWS ネットワーク内で完全に実行され、データのための安全な経路が提供されます。
これまでとどう変わるのか
-
これまで
- VPC から ACM API にアクセスする際に、パブリックインターネットを経由する必要がありました。
-
これから
- AWS PrivateLink を使用することで、VPC から ACM API にパブリックインターネットを経由せずに、AWS ネットワーク内で直接アクセスできるようになりました。
具体的なユースケース
- コンプライアンス要件を満たす必要がある場合。
- Amazon CloudFront、ロードバランシング、ハイブリッドワークロードなどの統合された AWS サービスでトラフィックを安全に終端する必要がある場合。
- VPC 内から ACM API へのセキュアでプライベートなアクセスを確立したい場合。
Amazon RDS for Db2 が暗号化されたデータベースのクロスリージョン自動バックアップをサポート
投稿日: 2025年08月15日
何ができるようになったのか
Amazon Relational Database Service (RDS) for Db2 が、暗号化されたデータベースのクロスリージョン自動バックアップをサポートするようになりました。
何が嬉しいのか
- ミッションクリティカルなDb2ワークロードをリージョン障害から保護するためのデータ保護の追加レイヤーを提供します。
- 暗号化されたデータベーススナップショットをプライマリAWSリージョン外のリージョンに安全にコピーできるようになり、災害復旧が向上します。
これまでとどう変わるのか
-
これまで
- 暗号化されたDb2データベースのクロスリージョン自動バックアップはサポートされていませんでした。
-
これから
- 暗号化されたDb2データベースのクロスリージョン自動バックアップが利用可能になりました。
具体的なユースケース
- リージョン障害からのミッションクリティカルなDb2ワークロードの保護。
- 災害復旧戦略の改善。
Amazon EC2 R8g インスタンスが AWS アジアパシフィック (ジャカルタ) で利用可能に
投稿日: 2025年08月15日
何ができるようになったのか
Amazon EC2 R8g インスタンスが AWS アジアパシフィック (ジャカルタ) リージョンで利用可能になりました。これらのインスタンスは AWS Graviton4 プロセッサを搭載し、AWS Graviton3 ベースのインスタンスと比較して最大 30% 高いパフォーマンスを提供します。
何が嬉しいのか
データベース、インメモリキャッシュ、リアルタイムビッグデータ分析などのメモリ集約型ワークロードに最適です。
これまでとどう変わるのか
-
これまで
- AWS Graviton3 ベースの R7g インスタンス。
-
これから
- AWS Graviton4 ベースの R8g インスタンスは、Graviton3 ベースの R7g インスタンスと比較して、最大 3 倍の vCPU (最大 48xlarge) およびメモリ (最大 1.5TB) を備えた、より大きなインスタンスサイズを提供します。これらのインスタンスは、Web アプリケーションでは最大 30%、データベースでは最大 40%、大規模 Java アプリケーションでは最大 45% 高速です。
具体的なユースケース
- データベース、インメモリキャッシュ、リアルタイムビッグデータ分析。
AWS Managed Microsoft AD がディレクトリ共有の上限を引き上げ
投稿日: 2025年08月15日
何ができるようになったのか
AWS Managed Microsoft AD のディレクトリ共有におけるアカウント共有上限が引き上げられました。標準エディションの上限は 5 から 25 アカウントに、エンタープライズエディションの上限は 125 から 500 アカウントに拡大されました。
何が嬉しいのか
これらの上限引き上げにより、以前の技術的な制約が解消され、組織は AWS 環境全体でディレクトリインフラストラクチャをより効果的に拡張できるようになります。これにより、エンタープライズ顧客は Active Directory インフラストラクチャを統合し、単一の管理ディレクトリからより大きな AWS アカウントフットプリントをサポートすることで、運用上の複雑さを軽減できます。組織は数百のアカウントにわたる認証と管理を一元化できるようになり、複数のディレクトリ展開に伴う複雑な回避策の必要性がなくなります。
これまでとどう変わるのか
-
これまで
- 標準エディションの上限は 5 アカウント、エンタープライズエディションの上限は 125 アカウントでした。
-
これから
- 標準エディションの上限は 25 アカウント、エンタープライズエディションの上限は 500 アカウントになります。
具体的なユースケース
- Active Directory インフラストラクチャの統合、運用上の複雑さの軽減、数百のアカウントにわたる認証と管理の一元化。
Amazon VPC が大規模 IP プール向けの IPv4 入力ルーティングをサポート
投稿日: 2025年08月15日
何ができるようになったのか
Amazon VPC が、大規模なパブリック IP アドレスプール宛てのインバウンドインターネットトラフィックを、VPC 内の単一の Elastic Network Interface (ENI) にルーティングできるようになりました。
何が嬉しいのか
この機能強化により、Telco および IoT のユースケースにおいて、これらのユースケースで必要とされる大規模な IP アドレスプール宛てのインバウンドインターネット接続に対するアドレス変換の必要性がなくなります。顧客は独自のパブリック IP プール (BYOIP) を持ち込み、VPC インターネットゲートウェイを設定して、この BYOIP プールに属するトラフィックを受け入れ、ネットワークインターフェイスにルーティングできます。また、VPC Route Server と共にこの機能を使用し、障害発生時にルートを動的に更新することもできます。
これまでとどう変わるのか
-
これまで
- インターネットゲートウェイは、VPC 内のネットワークインターフェイスに関連付けられたパブリック IP アドレス宛てのトラフィックのみを受け入れていました。インスタンスタイプによっては、ネットワークインターフェイスに関連付けられる IP アドレスの数に制限がありました。顧客は、このような多数の IP アドレスのトラフィックを統合するために、アドレス変換を実行する必要がありました。
-
これから
- 大規模なパブリック IP アドレスプール宛てのインバウンドトラフィックを VPC 内の単一の ENI にルーティングできるようになり、インバウンドインターネット接続に対するアドレス変換の必要性がなくなります。
具体的なユースケース
- Telco および IoT 業界において、許容される上限を超えるパブリック IP プール宛てのインバウンドトラフィックを単一のネットワークインターフェイスにルーティングする必要がある場合。
Amazon Neptune が GenAI アプリケーションのグラフネイティブメモリのために Cognee と統合
投稿日: 2025年08月15日
何ができるようになったのか
Amazon Neptune Analytics と、エージェントのメモリフレームワークである Cognee との統合を発表します。これにより、顧客は Neptune を Cognee のメモリレイヤーの背後にあるグラフストアとして使用でき、エージェント型 AI アプリケーションの長期メモリおよび推論機能を有効にできます。
何が嬉しいのか
この統合により、Cognee ユーザーはメモリグラフを大規模に保存およびクエリできるようになり、AI エージェントが継続的な対話から学習することで、時間の経過とともにパーソナライズされ、より効果的になる高度なユースケースがアンロックされます。Neptune は、グラフ、ベクトル、キーワードのモダリティにわたるマルチホップグラフ推論とハイブリッド検索をサポートしており、Cognee がよりリッチでコンテキストアウェアな AI 体験を提供できるよう支援します。Cognee は自己改善メモリシステムを可能にし、開発者がコスト効率が高くパーソナライズされた生成 AI アプリケーションを構築するのに役立ちます。
これまでとどう変わるのか
-
これまで
- AI エージェントには、長期メモリと推論機能に制限がありました。開発者は、Neptune と統合された Cognee のようなグラフネイティブメモリフレームワークの恩恵なしに、コスト効率が高くパーソナライズされた生成 AI アプリケーションを構築する必要がありました。
-
これから
- Cognee のメモリレイヤーの背後にあるグラフストアとして Neptune を使用することで、エージェント型 AI アプリケーションの長期メモリと推論機能が可能になります。これにより、よりリッチでコンテキストアウェアな AI 体験と自己改善メモリシステムが可能になります。
具体的なユースケース
- AI エージェントが継続的な対話から学習することで、時間の経過とともにパーソナライズされ、より効果的になるようにする。
- コスト効率が高くパーソナライズされた生成 AI アプリケーションを構築する。
Amazon RDS for MariaDB がコミュニティ MariaDB マイナーバージョン 11.4.8、10.11.14、10.6.23 をサポート
投稿日: 2025年08月15日
何ができるようになったのか
Amazon Relational Database Service (Amazon RDS) for MariaDB が、コミュニティ MariaDB のマイナーバージョン 11.4.8、10.11.14、10.6.23 をサポートするようになりました。
何が嬉しいのか
最新のマイナーバージョンにアップグレードすることで、MariaDB の以前のバージョンにおける既知のセキュリティ脆弱性を修正し、MariaDB コミュニティによって追加されたバグ修正、パフォーマンス改善、新機能の恩恵を受けることができます。
これまでとどう変わるのか
-
これまで
- MariaDB の古いマイナーバージョンがサポートされていました。
-
これから
- 新しいマイナーバージョン 11.4.8、10.11.14、10.6.23 がサポートされるようになりました。
具体的なユースケース
- 自動マイナーバージョンアップグレードを活用して、スケジュールされたメンテナンスウィンドウ中にデータベースをより新しいマイナーバージョンに自動的にアップグレードする。
- Amazon RDS Managed Blue/Green デプロイメントを活用して、MariaDB インスタンスをより安全、簡単、迅速に更新する。
さいごに
「Amazon DynamoDB がより詳細なスロットリングエラー例外をサポート」、「Amazon DynamoDB が CloudWatch Contributor Insights のスロットルされたキー専用モードをサポート」等DynamoDBのスロットリング検知が強化されましたね。より安心してDynamoDBを使えるようになりました。