LoginSignup
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kiitosu

aws_whats_new_2025-08-15 AWS BatchがAWS FargateでGravitonベースのスポットコンピューティングに対応 他

Posted at

はじめに

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

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

Amazon RDS for PostgreSQLが新しいマイナーバージョンをサポート

投稿日: 2025年08月15日

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

Amazon RDS for PostgreSQLで、新しいマイナーバージョン17.6, 16.10, 15.14, 14.19, 13.22が利用可能になりました。

何が嬉しいのか

  • 以前のバージョンの既知のセキュリティ脆弱性が修正されます。
  • PostgreSQLコミュニティによるバグ修正、パフォーマンス改善、新機能の恩恵を受けられます。
  • pg_repack 1.5.2, oracle_fdw 2.8.0, pgactive 2.1.5 といった便利な拡張機能もアップデートされています。

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

  • これまで
    • 古いマイナーバージョンしか利用できず、最新のセキュリティパッチやバグ修正が適用されていない可能性がありました。
  • これから
    • 最新のマイナーバージョンへアップグレードすることで、より安全で安定したデータベース運用が可能になります。

具体的なユースケース

  • Amazon RDS for PostgreSQLを利用している全てのユーザーが、データベースインスタンスを新しいマイナーバージョンにアップグレードし、セキュリティと安定性を向上させるケース。
  • pg_repackやoracle_fdwなどの拡張機能の最新版を利用したい開発者が、最新バージョンに追随するケース。

拡張機能が成約となってRDSのバージョン更新できないこともあるので助かりますね。

  • pg_repack : 最小限のデータベースロックでテーブルとインデックスの肥大化を削除できる
  • oracle_fdw : PostgreSQLの外部にある様々なデータに対してアクセスするためのOracleデータベース用の外部データラッパー
  • pg_active : 複数のPostgreSQLインスタンス間でアクティブ/アクティブなレプリケーションを実現する

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

投稿日: 2025年08月15日

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

Amazon EC2 I7ieインスタンスが、新たに欧州（ストックホルム）、アジアパシフィック（ジャカルタ）、米国西部（北カリフォルニア）の3つのAWSリージョンで利用可能になりました。

何が嬉しいのか

  • 第5世代Intel Xeonスケーラブルプロセッサーにより、コンピューティング性能が最大40%、価格性能が20%向上します。
  • 第3世代AWS Nitro SSDにより、リアルタイムストレージ性能が最大65%向上し、I/Oレイテンシーが最大50%低減します。
  • これまでI7ieインスタンスが提供されていなかったリージョンでも、大容量ストレージと高いI/O性能を活かせるようになります。

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

  • これまで
    • I7ieインスタンスは、欧州（ストックホルム）、アジアパシフィック（ジャカルタ）、米国西部（北カリフォルニア）のリージョンでは利用できませんでした。
  • これから
    • これらのリージョンでも、高いコンピューティング性能とストレージ性能を持つI7ieインスタンスを利用して、要求の厳しいワークロードを実行できるようになります。

具体的なユースケース

  • 上記3リージョンで、大規模なNoSQLデータベース（例: Cassandra, ScyllaDB）、インメモリデータベース、データ分析ワークロードなど、高いI/O性能と大容量ストレージを必要とするアプリケーションを運用するケース。
  • グローバルに展開するサービスで、各リージョンで一貫したインスタンスタイプを利用したい場合。

SageMaker HyperPodがLLMタスク向けのトポロジー認識スケジューリングに対応

投稿日: 2025年08月15日

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

SageMaker HyperPodで、大規模言語モデル（LLM）のトレーニングやファインチューニングのタスクに対して、トポロジー認識スケジューリング（TAS）が利用できるようになった。

何が嬉しいのか

  • ネットワークトポロジーを考慮してタスクが最適に配置されるため、インスタンス間の通信が削減され、LLMのトレーニング効率が向上する。
  • これにより、トレーニング時間が短縮され、コスト削減につながる可能性がある。

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

  • これまで
    • タスクのスケジューリング時にネットワークトポロジーが考慮されず、インスタンス間の通信が非効率になる場合があった。
  • これから
    • TASによってタスクがインテリジェントに配置され、通信オーバーヘッドが最小化されるため、分散トレーニングのスループットが向上する。

具体的なユースケース

  • 数百または数千のアクセラレータ（GPUなど）を使用して、大規模な基盤モデルをゼロからトレーニングする。
  • 既存のモデルを特定のドメインに適応させるために、大規模なデータセットでファインチューニングを行う。
  • SageMaker HyperPod上で分散トレーニングを実行するあらゆるLLM関連ワークロード。

Amazon WorkSpacesが合理化されたBYOL（ライセンス持ち込み）プロセスを発表

投稿日: 2025年08月15日

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

Amazon WorkSpacesで、BYOL（ライセンス持ち込み）プロセスが合理化され、Windowsイメージのインポートがより効率的かつ迅速になりました。AWSサポートへの連絡なしに、アカウントで直接BYOL機能を有効化できます。

何が嬉しいのか

  • カスタマイズされたVMイメージやWindows ISOファイルを直接インポートすると、WorkSpaces互換イメージが自動で構築されるため、手動での作業が大幅に削減されます。
  • 互換性の問題が自動修正され、解決できない場合でもEC2インスタンス経由で直接対処できるため、イメージの再アップロードが不要になり、トラブルシューティングが容易になります。
  • 結果として、BYOLイメージの利用開始までの時間が短縮され、管理者の労力が最小限に抑えられます。

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

  • これまで
    • BYOLプロセスは手動での手順が多く、AWSサポートへの連絡が必要でした。イメージの互換性問題が発生した場合、修正して再アップロードする必要があり、時間がかかっていました。
  • これから
    • BYOL機能の有効化からイメージのインポート、互換性チェック、修正までが自動化・合理化され、セルフサービスで迅速にBYOLイメージを準備できるようになりました。

具体的なユースケース

  • 既存のWindowsライセンス資産をAmazon WorkSpacesで活用したい企業が、自社でカスタマイズした標準のWindowsイメージを迅速かつ容易に展開するケース。
  • 特定のアプリケーションや設定が含まれたゴールデンイメージを、複数のWorkSpacesに効率的に展開する必要があるIT管理者が利用するケース。

SageMaker HyperPodがコンピュートリソースの細かなクォータ割り当てに対応

投稿日: 2025年08月15日

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

SageMaker HyperPodで、インスタンス内のGPU、Trainiumアクセラレータ、vCPU、vCPUメモリといったコンピュートリソースを、チームごとに細かくクォータとして割り当てられるようになりました。

何が嬉しいのか

  • これまでインスタンス単位でしか割り当てられなかったリソースを、より細かく（GPU単位、vCPU単位など）でチームやユーザーに割り当てられるため、リソースの利用率が向上します。
  • 管理者はコンピューティングリソースを戦略的に割り当て、公平なアクセスを確保し、特定チームによるリソースの独占を防ぐことができます。
  • クラスター全体の利用率が最大化され、コスト効率が向上します。

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

  • これまで
    • リソース割り当てはインスタンス全体で行われており、タスクが必要とするリソースがインスタンス全体より少ない場合でも、インスタンスを丸ごと占有してしまい、無駄が多かったです。
  • これから
    • タスクの要件に応じてGPUやvCPUなどのリソースを細かく割り当てられるため、1つのインスタンスを複数のチームやタスクで効率的に共有できるようになり、クラスターの利用率が向上します。

具体的なユースケース

  • 複数のチームが1つのSageMaker HyperPodクラスターを共有している環境で、各チームの研究開発フェーズや本番推論などの異なるニーズに応じて、GPUやvCPUリソースを公平かつ動的に割り当てるケース。
  • LLMのファインチューニング（少数のGPUが必要）と、大規模な分散トレーニング（多数のGPUが必要）など、異なる規模のタスクを同じクラスター上で効率的に実行するケース。

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

投稿日: 2025年08月15日

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

Amazon RDSのデータベースプレビュー環境で、PostgreSQL 18のベータ3をテストできるようになりました。

何が嬉しいのか

  • PostgreSQL 18の正式リリース前に、新しい機能（複数列インデックスのスキップスキャン、WHERE句処理の改善、GINインデックスの並列ビルドなど）をフルマネージドな環境で評価できます。
  • 新しい可観測性機能（バッファ使用量、I/O使用率メトリックなど）を試し、将来のアプリケーション開発や運用改善に役立てることができます。
  • 本番環境に影響を与えることなく、新しいバージョンとの互換性テストを実施できます。

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

  • これまで
    • PostgreSQLの次期メジャーバージョンの新機能を試すには、自身でサーバーを構築し、PostgreSQLのベータ版をインストール・設定する必要がありました。
  • これから
    • AWSのマネージドサービスであるRDSプレビュー環境で手軽にPostgreSQL 18ベータ版を起動し、新機能の検証や互換性テストに集中できるようになりました。

具体的なユースケース

  • 開発者が、PostgreSQL 18で導入される新しいSQL機能やパフォーマンス改善を、自身のアプリケーションでどのように活用できるか事前に検証するケース。
  • データベース管理者が、既存のデータベースをPostgreSQL 18へアップグレードする際の互換性の問題やパフォーマンスへの影響を事前に評価するケース。
  • 技術ブログやコミュニティで、PostgreSQLの最新機能に関する情報を発信する人が、実際に機能を試して記事を作成するケース。

AWS Cloud Mapがアカウントを横断したサービス検出をサポート

投稿日: 2025年08月15日

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

AWS Cloud MapがAWS Resource Access Manager（AWS RAM）と統合され、異なるAWSアカウント間でサービス（ECSタスク、EC2インスタンスなど）を検出できるようになった。

何が嬉しいのか

  • 複数のAWSアカウントにまたがるアプリケーション環境で、サービスレジストリを一元管理できるため、運用が簡素化される。
  • リソースの重複を減らし、マルチアカウント環境でのリソース共有とサービス検出が容易になる。
  • 組織の成長に合わせて、サービス検出の仕組みを容易にスケールさせることができる。

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

  • これまで
    • サービス検出は同一のAWSアカウント内に限定されており、別のアカウントにあるサービスを検出するには、アカウントごとに個別の設定や複雑な仕組みが必要だった。
  • これから
    • AWS RAMを使ってCloud Mapの名前空間を共有するだけで、複数のアカウント間でシームレスにサービスを検出し、接続できるようになった。

具体的なユースケース

  • 中央の共有サービスアカウントで管理されているマイクロサービスを、複数の開発アカウントや本番アカウントから検出して利用する。
  • プラットフォームチームが管理する共通のサービス（認証、ロギングなど）を、組織内のすべてのAWSアカウントに提供する。
  • 複数のアカウントにまたがるECSクラスタやEKSクラスタで、サービスメッシュを構築し、サービス間の通信を容易にする。

Amazon EC2 R8gインスタンスがAWSアジアパシフィック（ジャカルタ）リージョンで利用可能に

投稿日: 2023年08月15日

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

AWS Graviton4プロセッサを搭載したAmazon EC2 R8gインスタンスが、AWSアジアパシフィック（ジャカルタ）リージョンで利用可能になりました。

何が嬉しいのか

  • Graviton3ベースのR7gインスタンスと比較して、vCPUとメモリが最大3倍に増加し、パフォーマンスが大幅に向上しています（ウェブアプリで最大30%、データベースで最大40%、大規模Javaアプリで最大45%高速）。
  • データベース、インメモリキャッシュ、リアルタイムビッグデータ分析など、メモリを大量に消費するワークロードの性能をジャカルタリージョンでも向上させることができます。

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

  • これまで
    • ジャカルタリージョンでは、Graviton4を搭載した最新のメモリ最適化インスタンスであるR8gを利用できませんでした。
  • これから
    • ジャカルタリージョンでもR8gインスタンスを利用し、メモリ集約型ワークロードのコストパフォーマンスを大幅に改善できるようになりました。

具体的なユースケース

  • ジャカルタリージョンで、高性能なオープンソースデータベース（MySQL, PostgreSQL, MariaDBなど）やインメモリキャッシュ（Redis, Memcachedなど）を運用するケース。
  • ジャカルタリージョンで、HadoopやSparkなどを使用したリアルタイムのビッグデータ分析基盤を構築するケース。
  • 大規模なJavaアプリケーションをジャカルタリージョンで実行し、パフォーマンスを向上させるケース。

Amazon FSx for NetApp ONTAPでSSDストレージ容量の削減が可能に

投稿日: 2025年08月15日

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

Amazon FSx for NetApp ONTAPファイルシステムのSSDストレージ容量を、必要に応じて削減できるようになりました。

何が嬉しいのか

  • これまではストレージ容量を増やすことしかできませんでしたが、削減も可能になったことで、ストレージ使用量の変動に合わせてコストを最適化できます。
  • プロジェクトベースのワークロードなど、一時的に大容量が必要な場合に、ピーク時だけ容量を増やし、不要になったら減らすことで、無駄なコストを削減できます。
  • ストレージ容量の変更がコンソールから数クリックで簡単に行えるため、運用負荷が低いです。

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

  • これまで
    • 一度増やしたSSDストレージ容量を減らすことはできませんでした。そのため、将来の最大容量を見越してプロビジョニングするか、一度大きな容量を確保すると、データ量が減ってもコストを削減できませんでした。
  • これから
    • アクティブなデータ量や性能要件に応じて、SSDストレージの容量を柔軟に増減させ、コスト効率の良い運用が可能になりました。

具体的なユースケース

  • データ分析やメディアレンダリングなど、一時的に大量の高性能ストレージを必要とするプロジェクトで、処理期間中だけSSD容量を増やし、プロジェクト完了後に容量を減らしてコストを節約するケース。
  • 開発・テスト環境で、様々なシナリオを試すために一時的にストレージを拡張し、テスト終了後に元のサイズに戻すケース。
  • データのライフサイクル管理の一環として、アクセス頻度の低いデータを安価なキャパシティプールストレージに移動させた後、空いたSSDストレージを削減してコストを最適化するケース。

AWS Security Incident Responseが組織単位（OU）でのメンバーシップ指定に対応

投稿日: 2025年08月15日

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

AWS Security Incident Responseの対象範囲を、AWS Organization内の特定の組織単位（OU）に限定できるようになりました。

何が嬉しいのか

  • これまで組織全体でしか有効化できなかったサービスを、本番環境のOUや特定の子会社のOUなど、必要な範囲に絞って適用できるため、柔軟な運用とコスト管理が可能になります。
  • まずはパイロットOUでサービスを試用し、その効果や運用を評価した上で、組織全体に展開するといった段階的な導入が容易になります。
  • OUにアカウントを追加・削除するだけで、サービスのカバレッジが自動的に更新されるため、管理が簡素化されます。

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

  • これまで
    • AWS Security Incident Responseを有効化すると、AWS Organization内のすべてのアカウントが強制的に対象となっていました。
  • これから
    • サービスを適用したいOUを選択できるようになったため、より細やかなスコープ管理が可能になりました。

具体的なユースケース

  • 最も重要な本番環境のワークロードが含まれるOUのみを対象として、インシデントレスポンス体制を強化するケース。
  • 特定のコンプライアンス要件を持つ子会社のOUに限定してサービスを適用するケース。
  • 新しいセキュリティサービスを導入する際に、まずIT部門のOUでテスト導入し、問題がないことを確認してから全社展開するケース。

AWS Security Incident Responseとは
AWSにおけるセキュリティイベントに効果的に備え対応し復旧できるように支援する機能で、以下の3つの主要機能を持つ。

  1. セキュリティハブを介したGuardDuty及びサードパーティツールの検出結果の優先順位付けおよびアラート
  2. サードパーティのセキュリティプロバイダを含む社内外の利害関係者とのコミュニケーション機能
  3. 調査ツール及び AWS CIRTによる年中無休のサポート

12TBメモリ搭載のAmazon EC2 High Memory U7iインスタンスがAWS米国東部（オハイオ）リージョンで利用可能に

投稿日: 2025年08月15日

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

12TBのDDR5メモリを搭載したAmazon EC2 High Memory U7iインスタンスが、AWS米国東部（オハイオ）リージョンで利用可能になりました。

何が嬉しいのか

  • 第4世代インテルXeonスケーラブルプロセッサーと12TiBのDDR5メモリにより、非常に高いメモリ性能を要求されるワークロードを実行できます。
  • SAP HANA、Oracle、SQL Serverといったミッションクリティカルな大規模インメモリデータベースのパフォーマンスを向上させることができます。
  • データが急増する環境でも、トランザクション処理のスループットをスケールさせることが可能になります。

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

  • これまで
    • 米国東部（オハイオ）リージョンでは、12TBもの大容量メモリを持つインスタンスは利用できませんでした。
  • これから
    • このリージョンでも、最大級のインメモリデータベースやデータ分析ワークロードを、単一のインスタンス上で高性能に実行できるようになりました。

具体的なユースケース

  • 米国東部（オハイオ）リージョンで、数テラバイト規模のSAP S/4HANAやBW/4HANAなどのインメモリデータベースを運用するケース。
  • 大規模なOracleまたはSQL Serverデータベースを、オンプレミスからAWS上の単一の大規模インスタンスに移行するケース。
  • ゲノム解析や科学技術計算など、膨大なメモリを必要とするハイパフォーマンスコンピューティング（HPC）ワークロードを実行するケース。

12TBのメモリ・・・！？

Amazon OpenSearch UIが新たに7つのAWSリージョンで利用可能に

投稿日: 2025年08月14日

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

Amazon OpenSearch Serviceの最新の運用分析UIが、大阪、ソウル、ハイデラバード、ミラノ、チューリッヒ、スペイン、北カリフォルニアを含む7つの新しいAWSリージョンで利用可能になりました。

何が嬉しいのか

  • これまで最新UIが利用できなかったリージョンでも、マネージドクラスターとサーバーレスコレクションの両方にまたがるデータを単一のエンドポイントから分析できるようになった。
  • チームでのコラボレーションを促進する「Workspaces」機能や、PPL/SQLなど複数クエリ言語に対応した新しい「Discover」機能など、最新の分析機能をこれらのリージョンでも利用できる。
  • OpenSearchのバージョンに依存せず、常に最新のUI機能の恩恵を受けられる。

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

  • これまで
    • 上記7リージョンでは、最新のOpenSearch UIを利用できず、古いUIまたは別の分析ツールを使う必要があった。
  • これから
    • これらのリージョンでも、統一された最新のUIを通じて、より高度で効率的なログ分析やデータ可視化が可能になった。

具体的なユースケース

  • 大阪リージョンで稼働しているシステムのログデータを、最新のOpenSearch UIを使って分析し、ダッシュボードをチームで共有する。
  • グローバルに展開しているアプリケーションで、ソウルやミラノなど複数のリージョンにまたがるログデータを、単一のUIから横断的に分析する。
  • OpenSearch Serverlessを利用している開発者が、北カリフォルニアリージョンで、SQLライクなPPLクエリを使って手軽にログを探索する。

AWS BatchがAWS FargateでGravitonベースのスポットコンピューティングに対応

投稿日: 2025年08月15日

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

AWS Batchで、AWS Fargateのコンピューティング環境として、Gravitonプロセッサ（Armベース）を搭載したスポットインスタンスを利用できるようになりました。

何が嬉しいのか

  • 耐障害性のあるArmベースのバッチ処理アプリケーションを、通常のFargate料金に比べて最大70%という大幅な割引価格で実行できるため、コストを大幅に削減できます。
  • AWSがカスタム設計した高性能かつ高効率なGravitonプロセッサの価格性能比のメリットを、サーバーレスのバッチ処理でも享受できます。

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

  • これまで
    • AWS Batch on Fargateでは、Gravitonベースのスポットインスタンスを選択できませんでした。コストを抑えるためにはEC2スポットを利用する必要があり、サーバーレスのメリットを享受しにくかったです。
  • これから
    • Fargateのコンピューティング環境設定でARM64とFARGATE_SPOTを選択するだけで、簡単にGravitonベースのスポットインスタンスをバッチジョブに利用でき、コスト削減と運用負荷軽減を両立できるようになりました。

具体的なユースケース

  • 大規模なデータ処理、ゲノム解析、メディアエンコーディングなど、中断されても問題ない耐障害性のあるバッチジョブを、コストを抑えながら実行するケース。
  • CI/CDパイプラインの一部として、Armアーキテクチャ向けのアプリケーションのビルドやテストを、低コストなスポットインスタンスで実行するケース。
  • 機械学習モデルのトレーニングや推論のバッチ処理を、価格性能比の高いGravitonプロセッサを搭載したFargateスポットで実行するケース。

これはかなりインパクト大きそうですね！
最大70%割引は熱い。

AWS Systems Manager Automationがランブックの機能強化と無料利用枠の更新を発表

投稿日: 2025年08月15日

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

  • AWS Systems Manager Automationで、ランブックの実行制御と成功率を向上させる3つの新機能（ランブックの再実行、自動リトライ、ネストされたOUの指定）が追加されました。
  • 無料利用枠が更新され、新規顧客への提供が終了し、既存顧客も2025年12月31日で終了となります。

何が嬉しいのか

  • 機能強化:
    • 再実行: パラメータを再入力する手間なく、失敗したランブックや同じ設定のランブックを簡単に再実行できます。
    • 自動リトライ: APIのスロットリングによる一時的なエラーで実行が失敗するケースが減り、ランブックの信頼性が向上します。
    • ネストされたOU指定: より柔軟かつ詳細なターゲット指定が可能になり、大規模なマルチアカウント環境での運用が容易になります。
  • 無料利用枠の変更:
    • （利用者にとっては嬉しくないですが）AWSのサービス提供方針の変更点として認識できます。

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

  • これまで:
    • ランブックを再実行するには、再度パラメータを入力する必要がありました。
    • APIスロットリングが発生すると、ランブックが失敗し、手動で再実行する必要がありました。
    • ターゲット指定は、ネストされたOUを考慮していませんでした。
    • 新規・既存顧客ともに無料利用枠が存在しました。
  • これから:
    • ランブックの実行と管理がより簡単かつ信頼性の高いものになります。
    • 無料利用枠が廃止され、基本的に従量課金制となります（新規顧客は初期クレジットを利用可能）。

具体的なユースケース

  • 多数のEC2インスタンスにパッチを適用するランブックを実行中、一部のAPIコールがスロットリングされても、自動リトライ機能によって実行が継続され、成功率が向上するケース。
  • 特定のプロジェクトに関連するOU（子OUも含む）内のすべてのリソースに対して、一括で設定変更や監査を行うランブックを実行するケース。
  • 開発環境で繰り返し実行するテスト用のランブックを、パラメータを保持したままコンソールからワンクリックで再実行するケース。

AWS Configが10種類の新しいリソースタイプに対応

投稿日: 2025年08月14日

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

AWS Configが、新たに10種類のリソースタイプ（Backup, CloudFront, EC2, KafkaConnect, OpenSearch Serverless, Redshift, Route 53, SSM Incidents, Transfer Family）の設定変更履歴を記録できるようになった。

何が嬉しいのか

  • これまで追跡できなかったリソースの設定変更もAWS Configで管理できるようになり、AWS環境全体の可視性、監査、コンプライアンス評価が向上する。
  • 例えば、AWS::EC2::SecurityGroupVpcAssociationを追跡することで、セキュリティグループとVPCの関連付けの変更を監視し、意図しない変更を検知できる。
  • AWS::SSMIncidents::ResponsePlanを追跡することで、インシデント対応計画の変更履歴を管理し、ガバナンスを強化できる。

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

  • これまで
    • 今回追加された10種類のリソースはAWS Configの追跡対象外であり、これらの設定変更を手動で監視するか、別の方法で追跡する必要があった。
  • これから
    • AWS Configを有効にしていれば、これらのリソースの設定変更も自動的に記録され、設定履歴の確認、コンプライアンス違反の評価、修正アクションの自動化などが容易になる。

具体的なユースケース

  • セキュリティ管理者が、AWS::EC2::VerifiedAccessInstanceやAWS::OpenSearchServerless::SecurityConfigの変更を監視し、組織のセキュリティポリシーに準拠していることを継続的に確認する。
  • 運用チームが、AWS::Backup::RestoreTestingPlanやAWS::Redshift::Integrationの変更履歴を追跡し、データ保護や連携に関する設定が正しく維持されていることを確認する。
  • 開発者が、AWS::KafkaConnect::CustomPluginやAWS::Transfer::Serverの設定変更によって問題が発生した場合に、原因調査のために過去の設定履歴を迅速に確認する。

Amazon Braketがプログラムセットのサポートを開始し、複雑なワークロードを高速化

投稿日: 2025年08月15日

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

Amazon Braketで「プログラムセット」機能が利用可能になり、1つの量子タスクで数百の量子回路をまとめて実行できるようになりました。

何が嬉しいのか

  • 複数の量子回路を1つのタスクとして送信することで、処理のオーバーヘッドが削減され、複雑なワークロードを最大24倍高速に実行できます。
  • 変分量子アルゴリズム（VQA）や量子機械学習など、多数の回路実行が必要な研究開発が効率化されます。
  • Amazon Braket SDK、Qiskit、PennyLaneなど、使い慣れたツールからこの新機能を利用できます。

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

  • これまで
    • 多数の量子回路を実行する場合、それぞれを個別のタスクとして送信する必要があり、オーバーヘッドが大きく、時間がかかっていました。
  • これから
    • 「プログラムセット」機能を使って複数の回路を1つのタスクにまとめることで、オーバーヘッドを大幅に削減し、研究開発のサイクルを高速化できるようになりました。

具体的なユースケース

  • 量子化学シミュレーションや最適化問題の解決のために、変分量子固有ソルバー（VQE）などの変分量子アルゴリグズムを実行する研究者。
  • 量子ビットのエラーを補正するためのエラー緩和技術を開発・評価する際に、多数の異なる回路パターンを効率的にテストする。
  • パラメータ化された量子回路を用いて、量子機械学習モデルのトレーニングを高速に実行する。

Amazon EC2 M8gインスタンスがAWSアジアパシフィック（ソウル）リージョンで利用可能に

投稿日: 2025年08月15日

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

AWS Graviton4プロセッサを搭載した汎用Amazon EC2 M8gインスタンスが、AWSアジアパシフィック（ソウル）リージョンで利用可能になりました。

何が嬉しいのか

  • Graviton3ベースのM7gインスタンスと比較して、最大30%高いパフォーマンスを発揮し、アプリケーションサーバー、マイクロサービス、ゲームサーバーなどの性能を向上させることができます。
  • M7gインスタンスよりも最大3倍多いvCPUとメモリを持つ、より大きなインスタンスサイズが提供されるため、より大規模なワークロードにも対応できます。
  • データベースで最大40%、Webアプリケーションで最大30%、大規模Javaアプリケーションで最大45%高速化されるなど、様々なワークロードでコストパフォーマンスの向上が期待できます。

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

  • これまで
    • ソウルリージョンでは、Graviton4を搭載した最新の汎用インスタンスであるM8gを利用できませんでした。
  • これから
    • ソウルリージョンでもM8gインスタンスを利用し、様々な汎用ワークロードのコストパフォーマンスを大幅に改善できるようになった。

具体的なユースケース

  • ソウルリージョンで、高いパフォーマンスが求められるWebサーバー、アプリケーションサーバー、マイクロサービスを運用するケース。
  • 大規模なマルチプレイヤーゲームのゲームサーバーを、高性能かつコスト効率の高いM8gインスタンスで構築するケース。
  • ソウルリージョンで、中規模のデータストアやキャッシュサーバー（Redis, Memcachedなど）を運用するケース。

Amazon Q Businessが精度と説明可能性を向上させる「Agentic RAG」を発表

投稿日: 2025年08月14日

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

業務用の生成AIアシスタントであるAmazon Q Businessに、新機能「Agentic RAG (Retrieval-Augmented Generation)」が追加されました。

何が嬉しいのか

  • 複雑な質問をAIエージェントが自動で複数の単純なクエリに分解し、並行してデータを検索・統合するため、より精度の高い回答が得られます。
  • AIエージェントが回答を評価・検証し、必要に応じて検索を再試行するため、回答の信頼性が向上します。
  • 矛盾する情報についてユーザーに確認を求めたり、文脈に沿ったフォローアップを行ったりするなど、より自然で直感的な対話が可能になります。

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

  • これまで
    • 複雑な質問に対しては、単一の検索クエリで情報を取得しようとするため、回答の精度が低かったり、情報が不足したりすることがありました。
  • これから
    • Agentic RAGが、人間のように質問を多角的に分析し、複数のステップで情報を収集・統合するため、より網羅的で精度の高い回答を生成できるようになりました。

具体的なユースケース

  • 社内のナレッジベースから「昨年度のプロジェクトAとプロジェクトBのコスト構造を比較し、主な差異の要因を分析して」といった複雑な問い合わせに対して、それぞれのプロジェクト情報を収集・比較し、要点をまとめた回答を得るケース。
  • 複数の製品ドキュメントを横断して、「製品Xのセットアップ手順と、製品Yとの連携における注意点を教えて」といった質問に対し、関連情報を漏れなく抽出し、整理された手順と注意点を提示させるケース。
  • 過去のトラブルシューティング履歴から、「サーバーZで頻発するエラーの原因と、最も効果的だった対処法を教えて」といった問い合わせに対し、複数のインシデントレポートを分析し、最適な解決策を提案させるケース。

Amazon Q Businessがチャットにおける「Response Events」機能をリリース

投稿日: 2025年08月15日

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

Amazon Q Businessのチャット機能において、「Response Events」という新機能が導入され、アシスタントのクエリ処理ステップがリアルタイムで可視化されるようになりました。

何が嬉しいのか

  • Amazon Q Businessがどのようにクエリを処理し、応答を生成するかのプロセスがリアルタイムで可視化されるため、AI生成の応答に対する透明性と信頼性が向上します。
  • 企業固有の知識のためのRAG、チャットセッションでアップロードされたファイル、プラグインとのインタラクションなど、複数のコンポーネントにわたる処理ステップを追跡できるため、監査やトラブルシューティングが容易になります。

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

  • これまで
    • Amazon Q Businessがどのようにクエリを処理し、応答を生成するかの内部プロセスは不透明であり、AI生成の応答を監査し信頼することが困難でした。
  • これから
    • Response Eventsにより、クエリ処理の各ステップが明確になり、ユーザーはより安心してAmazon Q Businessを利用できるようになります。

具体的なユースケース

  • ユーザーがAmazon Q Businessに質問した際、回答が生成されるまでの間に、どのデータソースが参照され、どのプラグインが実行されたかなどをリアルタイムで確認し、回答の根拠を理解するケース。
  • 管理者が、Amazon Q Businessの応答が期待通りでない場合に、Response Eventsのログを分析して問題の原因を特定し、改善策を講じるケース。
  • 開発者が、Amazon Q Businessのカスタムプラグインやデータソースの連携が正しく機能しているかを確認し、デバッグを行うケース。

さいごに

AWS BatchがAWS FargateでGravitonベースのスポットコンピューティングに対応、はかなり熱いニュースなのではないでしょうか。バッチ処理のコスト逓減をしたい人には効果が高そうな気がします。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?