はじめに

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

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

気になったアップデート

Amazon Managed Service for PrometheusがAWS Service QuotasとCloudWatchを介したクォータの可視化を追加
そもそも AWS Service Quotas を知りませんでした。クォータを一覧で見られて便利ですね。
ECS ExecがAWSマネジメントコンソールで利用可能に
ECS Exec も知りませんでした。マネジメントコンソールで利用可能ということで、簡単にデバッグができていいですね。

音声解説

AWS Clean RoomsがPySparkジョブのコンピューティングサイズ設定をサポート

投稿日: 2025年9月4日

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

AWS Clean RoomsでPySpark（Apache SparkのPython API）を使用する際に、コンピューティングリソースのサイズを設定できるようになりました。具体的には、分析ジョブの実行時に、インスタンスタイプとクラスターサイズを指定できます。

何が嬉しいのか

パフォーマンス、規模、コストの要件に応じて、PySparkジョブを実行するためのリソースを柔軟にカスタマイズし、割り当てることができます。これにより、複雑なデータセットの分析には大規模なインスタンス構成を使用してパフォーマンスを確保し、コストを最適化したい場合には小規模なインスタンスを使用するなど、状況に応じた最適なリソース選択が可能になります。

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

これまで
- PySparkジョブを実行する際のコンピューティングリソースは、柔軟に設定できませんでした。
これから
- ジョブごとにインスタンスタイプやクラスターサイズを柔軟に指定できるようになり、パフォーマンスやコストの要件に応じた最適なリソース割り当てが可能になります。

具体的なユースケース

大規模で複雑なデータ分析を行う際に、高性能なインスタンスを割り当てて処理時間を短縮する。
コストを抑えたい小規模な分析プロジェクトで、より小さなインスタンスを選択してコストを最適化する。
複数のパートナーと共同でデータ分析を行う際に、それぞれの分析要件に応じてコンピューティングリソースを個別に調整する。

Amazon EC2、AMIの使用状況をより良く監視するためのAMI使用状況を発表

投稿日: 2025年9月4日

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

Amazon EC2に「AMI Usage」という新機能が導入されました。これにより、複数のAWSアカウントにわたってAMI（Amazonマシンイメージ）の利用状況を追跡し、特定のアカウント内のリソースがどのAMIに依存しているかを特定できるようになりました。

何が嬉しいのか

この機能により、AWSインフラ全体でのAMIの利用パターンを可視化し、AMIの登録解除を安全に管理できます。結果として、AMIのライフサイクル管理が改善され、コストの最適化にも繋がります。

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

これまで
- 複数のアカウントやリソースにまたがるAMIの使用状況を追跡するには、カスタムスクリプトを作成する必要があり、運用上の負担が大きかった。
これから
- AMI Usageを使い、特定のAMIを使用しているEC2インスタンスや起動テンプレートを持つアカウントのレポートを簡単に生成できます。また、インスタンス、起動テンプレート、Image Builderのレシピ、SSMパラメータなど、アカウント内の様々なリソースでのAMI使用状況を確認できます。

具体的なユースケース

AMIの安全な廃止: 古いAMIを廃止する前に、そのAMIに依存しているインスタンスや起動テンプレートがないかを確認し、影響範囲を特定する。
利用状況の監視: 複数のアカウントで共有しているカスタムAMIが、どのアカウントで、どの程度利用されているかを一元的に把握する。
コスト最適化: 使用されていないAMIを特定し、不要なAMIを整理することでコストを削減する。

Amazon Elastic Container Registry (ECR) が AWS GovCloud (US) リージョンでリポジトリ作成テンプレートをサポート開始

投稿日: 2025年09月04日

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

Amazon Elastic Container Registry (ECR) が、AWS GovCloud (US) リージョンでリポジトリ作成テンプレートをサポートするようになりました。これにより、プルスルーキャッシュやレプリケーション操作中にECRが自動で作成する新しいリポジトリの設定を、テンプレートを用いて定義できるようになります。

何が嬉しいのか

リポジトリ作成テンプレートを使用することで、新しく作成されるリポジトリに対して、暗号化、ライフサイクルポリシー、アクセスポリシー、タグの不変性といった設定を自動的に適用できます。プレフィックスに基づいてテンプレートが適用されるため、コンテナレジストリ全体で一貫した設定を容易に維持でき、管理の手間が省けます。

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

これまで
- AWS GovCloud (US) リージョンでは、プルスルーキャッシュやレプリケーションによって自動作成されたリポジトリの設定は、個別に手動で設定する必要がありました。
これから
- リポジトリ作成テンプレートを定義しておくことで、指定したプレフィックスに一致する新しいリポジトリが作成される際に、暗号化やライフサイクルポリシーなどの設定が自動的に適用されるようになります。

具体的なユースケース

政府機関や規制の厳しい業界でAWS GovCloud (US) を利用している組織が、コンテナイメージを管理する際に、セキュリティポリシー（例：すべてのリポジトリで特定の暗号化を有効にする）や運用ポリシー（例：古いイメージを自動的に削除するライフサイクルポリシー）を一貫して、かつ自動で適用したい場合。

CloudFormation Hooksがマネージドコントロールとフックアクティビティサマリーを追加

投稿日: 2025年09月04日

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

AWS CloudFormation Hooksが、AWSによって管理されるプロアクティブなコントロールをサポートするようになりました。これにより、ユーザーはAWS Control Towerのコントロールカタログからコントロールを選択し、CloudFormationの操作中にリソース設定を検証できます。また、CloudFormationコンソールに新しい「Hooks呼び出しサマリー」ページが導入され、Hooksのアクティビティ履歴を一元的に確認できるようになりました。

何が嬉しいのか

ガバナンス適用の簡素化: カスタムロジックを記述することなく、AWSのベストプラクティスに基づいたリソース設定の検証が可能になり、セットアップ時間が短縮され、手動エラーが削減されます。
柔軟なテスト: コントロールを「警告モード」で実行できるため、デプロイをブロックすることなく、本番環境に適用する前にコントロールの動作を評価できます。
可視性の向上: 新しいサマリーページにより、どのコントロールが呼び出され、その結果（成功、警告、失敗）がどうだったかを簡単に追跡でき、コンプライアンスレポートの作成や問題解決が迅速化します。

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

これまで
- プロアクティブなリソース検証を行うには、ユーザー自身がカスタムのHooksロジックを作成し、維持する必要がありました。
- Hooksの実行履歴が分散しており、監査やコンプライアンスの確認が煩雑でした。
これから
- AWSが提供・管理するコントロールを選択するだけで、簡単にプロアクティブなガバナンスを適用できるようになります。
- Hooksの呼び出し履歴、実行詳細、結果をすべて一元化されたビューで確認でき、コンプライアンスとトラブルシューティングが容易になります。

具体的なユースケース

開発チームが、本番環境に影響を与えることなく、新しいガバナンスポリシー（例：特定のEC2インスタンスタイプのみを許可する）を警告モードでテストする。
セキュリティチームが、暗号化されていないS3バケットの作成を禁止するなどのポリシーを、CloudFormationを通じたすべてのプロビジョニングにわたって一貫して適用する。
監査担当者が、Hooks呼び出しサマリーページを利用して、インフラストラクチャの変更が組織のコンプライアンス要件を満たしているかを迅速に確認し、レポートを作成する。

Q. そもそも適切なポリシーが付与されていればプロアクティブなリソース検証は不要なのでは？

A. IAMポリシーなどで事前に適切な権限を制御することは、セキュリティとガバナンスの基本です。CloudFormation Hooksによるプロアクティブな検証は、それらの既存のガードレールを置き換えるものではなく、補完するものと位置づけられています。

両者の主な違いは、問題を検知するタイミングにあります。

IAMポリシーなど（リアクティブな制御）
- リソースを作成・変更するAPIが実行される瞬間に評価されます。
- このため、開発者はデプロイを試みて、APIの実行が失敗した段階で初めてポリシー違反に気づくことになります。
CloudFormation Hooks（プロアクティブな制御）
- CloudFormationがリソースを作成する前の段階で、定義された設定がコンプライアンスに準拠しているかを検証します。
- これにより、開発者はデプロイを開始した直後や、変更セットの作成時点で問題を検知でき、API実行の失敗を待つ必要がありません。

この「より早い段階で問題を検知する」アプローチ（シフトレフト）には、以下のようなメリットがあります。

フィードバックの迅速化: 開発者はデプロイの失敗という手戻りを待つことなく、インフラのコードが組織のポリシーに違反していることを早期に知ることができます。
デプロイの安定化: 不正な設定によるデプロイの失敗や、その後のロールバックといった手間を防ぎます。
より複雑なルールの実装: Hooksはリソースのプロパティを詳細に検査できるため、IAMポリシーの条件キーだけでは表現が難しい、より具体的で複雑なルール（例：特定の命名規則とタグの組み合わせを強制する）を定義できます。

結論として、IAMポリシーが「最後の砦」としてAPIレベルでリソース作成を強制的にブロックするのに対し、CloudFormation Hooksは「インフラコードの静的解析ツール」のように、より開発プロセスの早い段階で問題を検知し、開発体験とガバナンスの両方を向上させる役割を担っています。

AWS HealthOmicsがアジアパシフィック（ソウル）リージョンで利用可能に

投稿日: 2025年9月4日

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

AWS HealthOmicsのプライベートワークフローが、アジアパシフィック（ソウル）リージョンで利用可能になりました。これにより、韓国のヘルスケアおよびライフサイエンス分野の顧客は、フルマネージドのバイオインフォマティクスワークフローを利用できるようになります。

何が嬉しいのか

顧客はインフラ管理に煩わされることなく、科学的発見に集中できます。これにより、研究、創薬、農業科学といった分野での価値実現までの時間が短縮されます。また、既存のパイプラインの移行が容易になり、データ来歴の完全な追跡とコンプライアンス要件を維持しながら、新しいゲノムワークフローの開発を加速できます。

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

これまで
- 韓国の顧客は、AWS HealthOmicsのプライベートワークフローを自国内のリージョンで利用できませんでした。
これから
- アジアパシフィック（ソウル）リージョンで直接サービスを利用できるようになり、Nextflow、WDL、CWLなどの使い慣れた言語でゲノムデータ分析パイプラインを構築・拡張できます。

具体的なユースケース

ヘルスケアおよびライフサイエンス分野における、大規模なゲノムデータ分析パイプラインの構築と実行。
創薬や農業科学における研究開発の迅速化。
データ主権やコンプライアンスの要件を満たしながら、韓国内でバイオインフォマティクスワークフローを実行する。

Amazon Neptuneデータベースが、開発アクセスを簡素化するパブリックエンドポイントをサポート開始

投稿日: 2025年09月04日

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

フルマネージドグラフデータベースサービスであるAmazon Neptune Databaseがパブリックエンドポイントをサポートしました。これにより、開発者は複雑なネットワーク設定を行うことなく、自身の開発用デスクトップから直接Neptuneデータベースに接続できるようになります。

何が嬉しいのか

VPCの外部からNeptuneデータベースに安全にアクセスできるため、VPN接続、踏み台ホスト、その他のネットワーク設定が不要になります。これにより、IAM認証、VPCセキュリティグループ、転送中の暗号化といった既存の制御を通じてセキュリティを維持しつつ、開発プロセスが効率化されます。

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

これまで
- 開発者のデスクトップなど、VPCの外部からNeptuneデータベースに接続するには、VPNや踏み台ホストといった複雑なネットワーク構成を準備する必要がありました。
これから
- パブリックエンドポイントを有効にするだけで、開発者は自身のマシンから直接Neptuneデータベースに接続できるようになり、開発のセットアップが大幅に簡素化されます。

具体的なユースケース

開発者が自身のローカル開発環境から、アプリケーションのテストやデバッグのために、手間をかけずに直接Neptuneデータベースに接続してクエリを実行する。

Amazon Connectが通話のトラブルシューティングを改善するため、詳細な切断理由を追加

投稿日: 2025年9月4日

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

Amazon Connectで、コンタクトセンターからのアウトバウンドコールが接続に失敗した理由を、より詳細に把握できるようになりました。この機能は、標準的な電気通信（テレコム）のエラーコードに基づいており、通話に関する深い洞察を提供し、トラブルシューティングを迅速化します。

何が嬉しいのか

迅速な問題解決: 通話失敗の原因が詳細にわかるため、問題を素早く特定し解決できます。
サポートへの依存低減: 失敗理由を自己解決できるため、AWSサポートへ問い合わせる手間が省けます。
レポート機能の向上: 詳細な切断データを利用して、より精度の高いレポートを作成できます。
リアルタイム監視: コンタクトトレースレコード（CTR）を通じて、通話の切断パターンをリアルタイムで効果的に監視できます。

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

これまで
- アウトバウンドコールの接続失敗理由は限定的で、詳細な原因を特定するためにはサポートへの問い合わせが必要な場合がありました。
これから
- 標準的なテレコムエラーコードに基づく詳細な切断理由が提供されるため、コンタクトセンター側で迅速に原因を特定し、トラブルシューティングを行えるようになります。

具体的なユースケース

コンタクトセンターの管理者が、特定のアウトバウンドキャンペーンで通話の接続失敗率が高い原因を調査する際に、新しい詳細な切断理由（例：「宛先が話中」「番号が存在しない」など）を確認し、キャンペーンリストの品質改善や再ダイヤル戦略の調整に役立てる。

ECS ExecがAWSマネジメントコンソールで利用可能に

投稿日: 2025年9月4日

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

Amazon ECSコンソールがECS Execをサポートし、AWSマネジメントコンソールから直接、実行中の任意のコンテナへの安全な対話型シェルアクセスを開くことができるようになりました。

何が嬉しいのか

インバウンドポートを開けたり、SSHキーを管理したりすることなく、実行中のコンテナへ簡単かつ安全にアクセスできます。これにより、コンソール上でのトラブルシューティングのワークフローが効率化されます。

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

これまで
- ECS ExecはAWS API、CLI、またはSDKを介してのみ利用可能でした。そのため、コンソールでトラブルシューティングを行う際には、別のインターフェースに切り替える必要がありました。
これから
- AWSマネジメントコンソールから直接、実行中のコンテナに接続できるようになり、シームレスなトラブルシューティングが可能になります。

具体的なユースケース

アプリケーションのデバッグや実行中のプロセスを調査するために、ECSで稼働しているコンテナに直接アクセスする。

AWS Systems ManagerでSAPのベストプラクティス準拠を検証

投稿日: 2025年09月04日

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

AWS Systems Manager Configuration ManagerがSAP HANAをサポートするようになりました。これにより、AWS上で稼働するSAP HANAデータベースが、AWS Well-Architected Framework SAP Lensで定義されたベストプラクティスに準拠しているかを自動的にテストできるようになりました。

何が嬉しいのか

設定ミスを事前に特定し、具体的な修正手順を推奨してくれるため、ビジネス運用に影響が出る前に必要な変更を加えることができます。また、設定チェックはスケジュール実行またはオンデマンドで実行できるため、運用の柔軟性が向上します。

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

これまで
- SAP管理者は、AWS、SAP、OSベンダーなど複数の情報源から最新のベストプラクティスを常に収集し、手動で設定をチェックして準拠状況を確認する必要がありました。
これから
- AWS Systems Manager Configuration ManagerがSAPアプリケーションをベストプラクティスに照らして自動的に評価し、設定ミスを事前に特定して修正手順を推奨してくれます。

具体的なユースケース

AWS上でSAP HANAシステムを運用している企業が、自社環境がAWSのベストプラクティスに準拠しているかを継続的かつ自動的に監査し、システムの安定性とコンプライアンスを維持する。

Amazon Managed Service for PrometheusがAWS Service QuotasとCloudWatchを介したクォータの可視化を追加

投稿日: 2025年9月4日

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

Amazon Managed Service for Prometheusのワークスペースに適用されているクォータ（上限値）とその使用率を、AWS Service QuotasとAmazon CloudWatchを通じて表示できるようになりました。

何が嬉しいのか

クォータ管理の簡素化: ワークスペース全体のクォータ使用率を包括的に把握できます。
迅速な上限緩和: AWS Service Quotasを利用して、適用されているクォータ値を素早く確認し、数クリックで上限の引き上げをリクエストできます。
プロアクティブな監視: CloudWatchメトリクスを使い、クォータ上限に近づいた際に通知するアラームを作成したり、ダッシュボードで利用状況を視覚化したりすることが可能です。

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

これまで
- クォータの使用状況を簡単に可視化したり、上限に近づいた際のアラートを設定したりする組み込みの仕組みがありませんでした。
これから
- AWS Service QuotasとCloudWatchを通じて、クォータの使用状況の可視化、アラート設定、上限緩和のリクエストがコンソール上から簡単に行えるようになります。

具体的なユースケース

Prometheusワークスペースのクォータ使用率を監視し、上限に近づいた際にCloudWatchアラームで通知を受け取り、サービス停止のリスクを未然に防ぐ。
複数のワークスペースのクォータ使用状況を単一のCloudWatchダッシュボードで一元的に可視化し、リソース管理を効率化する。
サービスの利用量が増加した際に、Service Quotasコンソールから迅速にクォータの引き上げをリクエストする。

Amazon BedrockのAPIキーを管理するための3つの新しい条件キーのサポートを追加

投稿日: 2025年09月04日

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

AWSは、Amazon BedrockのAPIキーを管理するための3つの新しいIAM条件キーを導入しました。これにより、管理者はAPIキーの生成、有効期限、許可される種類をより細かく制御できます。
新しい条件キーは以下の通りです。

iam:ServiceSpecificCredentialServiceName: IAMサービス固有の認証情報を作成する際に、対象となるAWSサービスを制限できます。
iam:ServiceSpecificCredentialAgeDays: Bedrockの長期APIキーを作成する際の最大有効期間を制御できます。
bedrock:BearerTokenType: APIキーが短期か長期かに基づいて、Bedrockへのリクエストを許可または拒否できます。

何が嬉しいのか

これにより、Amazon BedrockのAPIキーに対するガバナンスが強化され、セキュリティが向上します。例えば、Bedrock用の長期APIキーの作成は許可しつつ、AWS CodeCommitやAmazon Keyspacesといった他のサービスの認証情報作成は禁止する、といった詳細なアクセスコントロールが可能になります。

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

これまで
- Bedrock APIキーの生成、有効期限、種類に関して、IAMポリシーで詳細な制御を行うことが困難でした。
これから
- 新しい3つの条件キーを利用することで、APIキーのライフサイクルや種類に応じた、きめ細やかなアクセス制御ポリシーを定義できるようになります。

具体的なユースケース

企業や組織のセキュリティポリシーとして、特定のプロジェクトでは有効期限が短い（例: 12時間以内）Bedrock APIキーのみ作成を許可する。
本番環境では長期APIキーの使用を許可し、開発環境では短期APIキーのみに制限するなど、環境に応じたアクセス制御を実装する。
Bedrock以外のサービスでIAMサービス固有の認証情報が誤って作成されるのを防ぎ、意図しないアクセス権限の付与を防止する。

PostgreSQL 18 Beta RC1がAmazon RDSデータベースプレビュー環境で利用可能に

投稿日: 2025年9月4日

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

PostgreSQL 18のリリース候補版であるRC1が、Amazon RDSデータベースプレビュー環境で利用可能になりました。これにより、正式リリース前のPostgreSQL 18をAmazon RDS for PostgreSQLのフルマネージド環境で評価できます。

何が嬉しいのか

PostgreSQL 18の新機能（複数列B-treeインデックスの「スキップスキャン」サポート、OR/IN句の処理改善、GINインデックスの並列ビルド、結合操作の更新、クエリ実行中のバッファ使用量やインデックス参照の可観測性向上など）を、本番環境に影響を与えることなく、事前にマネージドデータベースとしてテストできます。

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

これまで
- PostgreSQL 18のプレリリース版を試すには、自身でサーバーを構築・管理する必要がありました。
これから
- フルマネージドサービスであるAmazon RDSのプレビュー環境で、手軽にPostgreSQL 18 RC1をデプロイし、新機能の評価や互換性テストを行えるようになります。

具体的なユースケース

開発者が、自社アプリケーションを次期PostgreSQL 18リリースに対応させるための互換性テストを行う。
データベース管理者が、「スキップスキャン」や並列インデックスビルドといった新機能が、実際のワークロードに対してどの程度のパフォーマンス向上をもたらすかを評価する。
将来のデータベース移行計画の一環として、新機能や潜在的な問題をマネージド環境で事前に把握する。