本日の主なトピック #
- AI連携の加速: Amazon Quick と New Relic の統合、および Amazon WorkSpaces での AI エージェントによるデスクトップアプリ操作（プレビュー）が発表されました。
- オブザーバビリティの進化: CloudWatch RUM でのセッションリプレイ対応や、CloudWatch Logs Insights でのタグベースクエリなど、調査効率を高める機能が追加されました。
- インフラと運用の強化: RabbitMQ 4 へのインプレースアップグレード対応、IAM の各種クォータ緩和、EKS バックアップの10倍高速化など、大規模運用の利便性が向上しました。
- リージョン拡大: Amazon FSx がニュージーランドリージョンで、EC2 I8ge インスタンスが東京リージョンを含む複数のリージョンで利用可能になりました。
¥3,520 Amazonで見る![AWS運用入門 改訂第2版 押さえておきたいAWSの基本と運用ノウハウ [AWS深掘りガイド] 単行本（ソフトカバー） – 2025/7/11](https://m.media-amazon.com/images/I/61ftnZ09WvL._SY522_.jpg)
AWS運用入門 改訂第2版 押さえておきたいAWSの基本と運用ノウハウ [AWS深掘りガイド] 単行本（ソフトカバー） – 2025/7/11
Amazon CloudWatch Logs Insights がロググループタグによるクエリに対応 #
投稿日: 2026年05月04日
何ができるようになったのか #
Amazon CloudWatch Logs Insights のクエリ言語において、ロググループ名だけでなく、ロググループに付与された「タグ」を指定してクエリを実行できるようになりました。
何が嬉しいのか #
これまでは複数のロググループを横断して分析する場合、対象のロググループ名を明示的にリストアップする必要がありました。今回のアップデートにより、「Environment: Production」や「Application: PaymentService」といった共通のタグを持つすべてのロググループに対して、一括でクエリを実行できるようになります。ロググループが追加・削除されてもタグに基づいて自動的にクエリ対象に反映されるため、運用負荷が軽減されます。
これまでとどう変わるのか #
- これまで: 複数のロググループをクエリする場合、コンソールで手動選択するか、API/CLIでロググループ名を列挙する必要があった。
- これから: 特定のタグ（キーと値のペア）を指定するだけで、そのタグを持つすべてのロググループを動的にクエリ対象に含めることができる。
具体的なユースケース #
- 特定のマイクロサービス（例:
App: Checkout）に関連するすべてのコンポーネントのログを、ロググループ名を気にせず一括分析する。 - 本番環境（例:
Stage: Prod）の全ロググループに対して、エラーレートの統計を一括で取得する。
Amazon CloudWatch RUM が Web アプリケーションのセッションリプレイに対応 #
投稿日: 2026年05月01日
何ができるようになったのか #
Amazon CloudWatch RUM (Real User Monitoring) に「セッションリプレイ」機能が追加されました。これにより、Web アプリケーション上でのユーザーの操作（クリック、スクロール、ページの遷移など）をビデオのようなプレイバック形式で確認できるようになります。
何が嬉しいのか #
フロントエンドの開発者やアプリケーションオーナーは、ユーザーがブラウザ上で直面したエラーや不具合を、自身の環境で再現させる手間なく、視覚的に診断できるようになります。サーバー側のログだけでは特定が困難な、UI要素の反応の悪さやナビゲーションフローの不備といったユーザー体験（UX）上の問題を迅速に特定し、根本原因を突き止めることが可能です。
これまでとどう変わるのか #
- これまで: クライアント側のパフォーマンスメトリクスやエラーデータは収集できたが、具体的なユーザー操作の文脈までは視覚化されていなかった。
- これから: ユーザーの操作をそのまま再現再生できるため、何が原因で離脱やエラーが発生したのかを直感的に把握できる。
具体的なユースケース #
- ユーザーから報告された「フォームが送信できない」という問題に対し、リプレイを確認して特定のブラウザでのみボタンが押せていないことを確認する。
- コンバージョン率が低いページのナビゲーションパターンを分析し、ユーザーがどこで迷っているかを特定する。
RUMは「Real User Monitoring」の略です。 実際のユーザーによるアプリケーション利用状況をリアルタイムに監視する手法です。 主な特徴は以下の通りです。
- クライアントサイドでの実際のユーザー体験を計測。
- ブラウザ、デバイス、地理的場所などの属性に基づいた分析が可能。
Amazon Connect Cases がカスタマープロファイルの ID 解決に対応 #
投稿日: 2026年05月05日
何ができるようになったのか #
Amazon Connect Cases において、重複するカスタマープロファイルが統合（マージ）された際に、関連付けられていたケースも自動的に再構成されるようになりました。
何が嬉しいのか #
一人の顧客が異なるチャネルから連絡してきたり、異なる連絡先情報を提供したりすることで複数のプロファイルが作成されてしまう場合があります。Amazon Connect Customer Profiles の「ID解決（Identity Resolution）」機能でこれらが統合されると、今回のアップデートにより、紐付いていた過去のケース履歴もすべて一つの統合されたプロファイルの下に集約されます。エージェントは手動で履歴を繋ぎ合わせる必要がなくなり、常に顧客の完全な履歴を確認しながら対応できます。
これまでとどう変わるのか #
- これまで: プロファイルが統合されても、それぞれのプロファイルに紐付いていたケース履歴が自動で集約されない場合があり、エージェントの確認作業を妨げていた。
- これから: プロファイルの統合に追従してケース履歴も一元化されるため、顧客との過去のやり取りをシームレスに把握できる。
具体的なユースケース #
- 電話とチャットで別々に問い合わせてきた顧客が、システム上で同一人物だと判定された後、エージェントがその顧客の電話での履歴とチャットでの履歴を一つの画面で同時に確認する。
Amazon ElastiCache にネットワーク容量計画とエンジン診断のための13の新しい CloudWatch メトリクスが追加 #
投稿日: 2026年05月05日
何ができるようになったのか #
Amazon ElastiCache（ノードベースのクラスター）において、ネットワークスロットリング、メモリの断片化、接続の枯渇などを検知するための13種類の新しい Amazon CloudWatch メトリクスが利用可能になりました。
何が嬉しいのか #
ノードに対して個別に INFO コマンドを実行したり、生のバイトカウンターから基準値を算出したりすることなく、CloudWatch コンソールから直接、ホストレベルおよびエンジンレベルの診断が可能になります。特筆すべきは「インスタンスのベースラインに対するネットワーク利用率」が割合（%）で報告されるようになったことで、インスタンスタイプを変更してもそのまま有効なアラームを設定できるようになりました。
これまでとどう変わるのか #
- これまで: ネットワークスロットリングの兆候（バーストクレジットの消費など）やメモリ断片化の状態を把握するには、複雑な計算や個別ノードへのコマンド実行が必要な場合があった。
- これから: CloudWatch メトリクスとして標準提供されるため、可視化やアラーム設定が容易になり、キャパシティプランニングの精度が向上する。
具体的なユースケース #
- インスタンスタイプを変更した際、既存のネットワーク利用率アラームの設定値を変更せずに、引き続きスロットリングの予兆を監視する。
AllocatorFragmentationRatioを監視し、メモリ断片化が著しい場合にactivedefragパラメータの調整を検討する。RejectedConnectionsが 0 を超えた際に、クライアント側のコネクションプール漏れやmaxclients制限の緩和を調査する。
Amazon FSx が AWS アジアパシフィック（ニュージーランド）リージョンで利用可能に #
投稿日: 2026年05月04日
何ができるようになったのか #
フルマネージドなファイルシステムサービスである Amazon FSx が、AWS アジアパシフィック（ニュージーランド）リージョンで利用可能になりました。
何が嬉しいのか #
ニュージーランド国内で低レイテンシかつ高性能なファイル共有ストレージを必要とするアプリケーションを構築できるようになります。Amazon FSx が提供する4つの主要なファイルシステム（NetApp ONTAP, Windows File Server, Lustre, OpenZFS）を、ハードウェアのプロビジョニングやパッチ適用などの運用負荷なしに、最適なコストで利用可能です。
これまでとどう変わるのか #
- これまで: ニュージーランドリージョンで AWS を利用する顧客は、ファイルストレージとして他のリージョンの FSx を利用するか、自前でファイルサーバーを運用する必要があった。
- これから: ローカルリージョンでフルマネージドな FSx を直接利用でき、パフォーマンスと運用の利便性が大幅に向上する。
具体的なユースケース #
- ニュージーランド国内のユーザー向けに提供する Windows ベースのアプリケーションで、標準的な SMB ファイル共有として
FSx for Windows File Serverを使用する。 - ニュージーランドリージョンの EC2 インスタンスで実行する機械学習ワークロードの高速なデータ供給に
FSx for Lustreを活用する。
Amazon MQ が RabbitMQ 4 へのインプレースメジャーバージョンアップグレードに対応 #
投稿日: 2026年05月05日
何ができるようになったのか #
Amazon MQ において、RabbitMQ ブローカーのインプレースメジャーバージョンアップグレードが可能になりました。これにより、新しいブローカーを作成したりデータを手動で移行したりすることなく、既存のブローカーを RabbitMQ 3.13 から 4.2 へ直接アップグレードできます。
何が嬉しいのか #
ブローカーの設定、キュー、エクスチェンジ、バインディング、ユーザー、ポリシーを保持したままアップグレードが完了するため、移行の手間とリスクが大幅に軽減されます。RabbitMQ 4.2 では、メタデータストアが Mnesia から Khepri に変更されるなどの重要な改善が含まれています。
これまでとどう変わるのか #
- これまで: メジャーバージョンのアップグレードには、新しいブローカーの作成と、データやクライアント接続の移行作業が必要だった。
- これから: コンソール、CLI、API から数クリックでインプレースアップグレードを実行できる（アップグレード中は一時的にブローカーが利用不可になる）。
具体的なユースケース #
- 現在運用中の RabbitMQ 3.13 ブローカーを、最新の RabbitMQ 4 系の機能やパフォーマンス改善を享受するために最小限のダウンタイムでアップグレードする。
RabbitMQ 4.2 へのアップグレードにはいくつかの前提条件があります。 主な条件と注意点は以下の通りです。
- ブローカーが M7G (Graviton) インスタンスタイプで実行されていること。
- クラシックミラーキュー（Classic Mirrored Queues）を使用していないこと（クォーラムキューへの移行が必要）。
- アップグレード実行中はブローカーがオフラインになる。
Amazon OpenSearch Service が「未使用インデックス」などの新しいクラスターインサイトを追加 #
投稿日: 2026年05月05日
何ができるようになったのか #
Amazon OpenSearch Service の「クラスターインサイト（Cluster Insights）」機能が拡張されました。すべての OpenSearch バージョンおよび Elasticsearch 6.8 以上をサポートしたほか、新たに「未使用インデックス（Unused Index）」を特定するインサイトが追加されました。
何が嬉しいのか #
新しいインサイトにより、過去30日間に検索やインデックス作成のアクティビティが全くなかったインデックスを自動で特定できます。これにより、不要なストレージコストを削減するための具体的なアクション（UltraWarm や Cold ストレージへの移行、または削除）を容易に判断できるようになります。
これまでとどう変わるのか #
- これまで: クラスターインサイトの対応バージョンが限られていた。また、どのインデックスが使われていないかを判断するには、手動でメトリクスを調査する必要があった。
- これから: 幅広いバージョンでプロアクティブな健全性チェックが可能になり、コスト最適化の機会をシステムが自動で提案してくれる。
具体的なユースケース #
- 大規模な OpenSearch クラスターにおいて、作成したまま忘れ去られた古いログインデックスを発見し、低コストなストレージ層へ移動させてコストを最適化する。
- クラスターのパフォーマンスや安定性に影響が出る前に、システムから通知される推奨事項に基づいて設定を修正する。
Amazon Quick が New Relic と統合し、オブザーバビリティ駆動の AI エージェントをサポート #
投稿日: 2026年05月05日
何ができるようになったのか #
仕事用 AI アシスタントである Amazon Quick が New Relic の AI エージェントと統合されました。オンコールエンジニアや SRE は、Amazon Quick のチャット画面から直接、New Relic のデータを使ってインシデント調査、根本原因分析 (RCA) の作成、タスクの生成が行えるようになります。
何が嬉しいのか #
コンテキストスイッチ（画面の切り替え）を最小限に抑えつつ、自然言語で New Relic へのクエリ（NRQL）を実行したり、アラートの洞察を得たり、ログ分析を行ったりできます。さらに、Amazon Quick 内に保存された社内のランブック（手順書）やアーキテクチャ図などの知識と、New Relic のライブなテレメトリデータを組み合わせて、組織の文脈に即した回答を得ることが可能です。
これまでとどう変わるのか #
- これまで: インシデント調査の際、New Relic のダッシュボードと社内ドキュメントツールを行き来して情報を集約する必要があった。
- これから: AI アシスタントを通じて、リアルタイムの監視データと社内知識を統合した高度な分析とドキュメント作成を単一のインターフェースで完結できる。
具体的なユースケース #
- インシデント発生時に、「直近1時間の特定のエラーの根本原因を分析して、RCAドキュメントを作成して」と依頼し、調査結果をメールで関係者に送付する。
- Quick Flows を使用して、特定のアラートが発生した際のリポジトリ調査やエスカレーションワークフローを自動化する。
Amazon VPC Lattice がプライベートドメイン名のターゲットに対応 #
投稿日: 2026年05月04日
何ができるようになったのか #
Amazon VPC Lattice のリソース設定において、ネットワーク内部でのみ解決可能な「プライベートドメイン名（FQDN）」をターゲットとして指定できるようになりました。これを他の AWS アカウントと共有することで、プライベートにホストされたリソースへの安全なクロスアカウントアクセスが可能になります。
何が嬉しいのか #
パブリックに解決可能な DNS エントリを作成することなく、VPC 内の DNS 設定を使用してプライベートなリソースへのルーティングが行えるようになります。これにより、セキュリティを維持したまま、組織内の異なるアカウント間でサービスを接続しやすくなります。
これまでとどう変わるのか #
- これまで: リソース設定（Resource Configurations）を介して共有できるドメイン名ターゲットは、パブリックに解決可能なものに限られていた。プライベートな DNS サーバーを使用している顧客はこの仕組みを利用できなかった。
- これから: リソースゲートウェイのプロパティを
IN_VPCに設定することで、VPC 内の DNS 設定を利用した解決が可能になり、プライベートドメイン名の共有が実現する。
具体的なユースケース #
- 社内のプライベート DNS（Route 53 Private Hosted Zone など）で管理されている社内サービスのドメイン名を、VPC Lattice を通じて別アカウントの開発チームに安全に公開する。
Amazon WorkSpaces Applications がホストからクライアントへの URL リダイレクトに対応 #
投稿日: 2026年05月04日
何ができるようになったのか #
Amazon WorkSpaces Applications において、ストリーミングセッション内（ホスト側）で開こうとした URL を、ユーザーの手元のデバイス（クライアント側）のローカルブラウザで自動的に開く「URL リダイレクト」機能がサポートされました。
何が嬉しいのか #
管理者は許可または拒否する URL パターンを設定できます。これにより、セキュリティが重要な機密性の高い Web アプリケーションはセッション内で実行し続け、一方でリソース消費の激しい動画ストリーミングなどはローカルデバイスにオフロードして実行させることができます。結果として、ストリーミングインフラの負荷（帯域幅や CPU）を軽減し、コスト削減に繋げつつ、ユーザー体験を損なわない運用が可能になります。
これまでとどう変わるのか #
- これまで: セッション内でクリックしたリンクはすべて仮想デスクトップ環境上のブラウザで開かれ、高負荷な Web サイトの閲覧はセッションのパフォーマンス低下やコスト増を招いていた。
- これから: 特定の URL をローカルブラウザに自動で逃がすことができ、リソースの最適化が図れる。
具体的なユースケース #
- Microsoft Word や Outlook 内のリンクをクリックした際、社内システムは仮想環境で、YouTube などの動画サイトは自動的に自分の PC のブラウザで開くように設定する。
- 帯域幅の消費を抑えるため、特定の重い Web コンテンツをローカルブラウザでの実行に誘導する。
AWS Backup が Amazon EKS クラスターのバックアップパフォーマンスを大幅に向上 #
投稿日: 2026年05月05日
何ができるようになったのか #
AWS Backup for Amazon EKS において、クラスターの状態（ステート）のバックアップが最大10倍高速化されました。
何が嬉しいのか #
多数のネームスペースや Kubernetes リソースを持つ大規模なクラスターであっても、バックアップ時間を大幅に短縮できます。これまで数日かかっていたような巨大なクラスターのバックアップウィンドウが、数時間にまで短縮されます。これにより、バックアップ処理がクラスターの運用や他のバッチ処理に与える影響を最小限に抑えられます。
これまでとどう変わるのか #
- これまで: リソース数が多い大規模な EKS クラスターのバックアップには非常に長い時間がかかっていた。
- これから: パフォーマンス改善が自動的に適用され（追加コストなし）、バックアップが迅速に完了する。
具体的なユースケース #
- 数千のリソースが稼働するマルチテナントな EKS クラスターにおいて、毎日のフルバックアップを短時間で確実に完了させる。
- コンプライアンス要件により頻繁なバックアップが必要な環境で、運用への影響を抑えつつバックアップ頻度を維持する。
AWS IAM がロール、管理ポリシー、インスタンスプロファイルなどのクォータを緩和 #
投稿日: 2026年05月05日
何ができるようになったのか #
AWS IAM において、以下の6つのリソースの最大クォータ（上限）が引き上げられました。
- アカウントあたりのカスタマー管理ポリシー: 5,000 → 10,000
- アカウントあたりのインスタンスプロファイル: 5,000 → 10,000
- ロールあたりの管理ポリシー数: 20 → 25
- ロールの信頼ポリシーの長さ: 4,096 → 8,192 文字
- アカウントあたりのロール数: 5,000 → 10,000
- アカウントあたりの OpenID Connect プロバイダー数: 100 → 700
何が嬉しいのか #
AWS 環境が拡大し、多数のワークロードやマイクロサービスを運用する際に直面しがちだったスケーリングの制約が大幅に緩和されます。よりきめ細かな IAM 制御をカスタマイズしたり、大量の IAM リソース作成を必要とする新しいワークロードを柔軟にサポートできるようになります。
これまでとどう変わるのか #
- これまで: 大規模なマルチアカウント運用や複雑な権限設計を行っている場合、ロール数や信頼ポリシーの長さの上限に達してしまい、設計の変更を余儀なくされることがあった。
- これから: 上限が倍増（またはそれ以上）されたことで、大規模環境でも余裕を持った設計・運用が可能になる。
具体的なユースケース #
- 多数のマイクロサービスごとに専用の IAM ロールを割り当てる大規模なプラットフォーム。
- 非常に多くの条件（Condition）を含む複雑な信頼ポリシーを必要とする高度なセキュリティ設計。
- 多数の外部 ID プロバイダーと連携する認証基盤の構築。
AWS IoT Core Device Location に信頼レベル設定と測定タイプ支援が追加 #
投稿日: 2026年05月05日
何ができるようになったのか #
AWS IoT Core for Device Location において、位置解決の「信頼レベル（Confidence Level）」を 50% から 99% の範囲で指定できるようになりました。また、解決された位置情報のメタデータに、どのように位置が特定されたかを示す「測定タイプ（Measurement Type）」フィールドが追加されました。
何が嬉しいのか #
開発者は、用途に応じて「正確さ」と「確実性」のバランスを調整できるようになります。高い信頼レベル（例: 95%）を設定すると、デバイスがその範囲内に存在する確実性は高まりますが、報告される精度半径は大きくなります。逆に低いレベル（例: 50%）にすると半径は小さくなります。また、測定タイプ（GNSS, Wi-Fi, BLEなど）が明示されることで、データの品質評価やトラブルシューティングが容易になります。
これまでとどう変わるのか #
- これまで: 位置解決の信頼性の度合いを細かく制御できなかった。また、どの技術を使って位置が特定されたかをプログラムから把握しにくかった。
- これから: HTTP ベースの位置解決において信頼レベルを数値で指定でき、結果のメタデータから測位の背景を詳細に把握できる。
具体的なユースケース #
- 物流トラッキングにおいて、「多少範囲が広くても確実にそのエリアにいること」を重視して高い信頼レベルを設定する。
- 屋内測位において、Wi-Fi と BLE のどちらで位置が特定されたかに基づいて、位置情報の信頼性を動的に判断する。
AWS SAM CLI がコンテナイメージ形式の Lambda 関数ビルドに BuildKit をサポート #
投稿日: 2026年05月05日
何ができるようになったのか #
AWS SAM CLI において、コンテナイメージ形式でパッケージ化された Lambda 関数のビルド時に Docker の「BuildKit」を使用できるようになりました。sam build コマンドに --use-buildkit フラグを付けて実行することで利用可能です。
何が嬉しいのか #
BuildKit の先進的な機能を利用して、より高速で効率的なイメージビルドが可能になります。具体的には、マルチステージビルドによる最終イメージの軽量化、キャッシュの改善によるビルド時間の短縮、ビルドステップの並列実行などが可能になります。また、x86_64 と arm64 (Graviton2) のクロスアーキテクチャビルドや、ビルド中の Docker secrets の利用（機密情報をイメージレイヤーに残さない）もサポートされます。
これまでとどう変わるのか #
- これまで: SAM CLI は BuildKit の機能を直接サポートしていなかったため、BuildKit 特有の Dockerfile 構文（マウントやシークレットなど）を使用したビルドが制限されていた。
- これから: SAM CLI から直接 BuildKit を呼び出せるようになり、開発ワークフローを近代化できる。
具体的なユースケース #
- CI/CD パイプラインにおいて、キャッシュを最大限活用して Lambda 用コンテナイメージのビルド時間を短縮する。
- 開発マシンと異なるアーキテクチャ（例: Mac M1 から x86_64 向け）の Lambda イメージを簡単に作成する。
- ビルド中にのみ必要な認証情報を Docker secrets を使って安全に渡す。
AWS SAM が Amazon API Gateway の WebSocket API をサポート #
投稿日: 2026年05月05日
何ができるようになったのか #
AWS Serverless Application Model (AWS SAM) において、Amazon API Gateway の WebSocket API を定義できるようになりました。AWS::Serverless::WebSocketApi という新しいリソースタイプを使用して、最小限の記述で WebSocket 基盤を構築可能です。
何が嬉しいのか #
チャットアプリやリアルタイムダッシュボード、AI/LLM のストリーミング応答、IoT デバイス連携などに不可欠な双方向通信を、SAM テンプレートで簡単に管理できます。これまで WebSocket API を構築するには生の CloudFormation リソースを複雑に組み合わせる必要がありましたが、SAM が IAM 権限やルートの統合設定などを自動的に処理してくれるため、開発効率が飛躍的に向上します。
これまでとどう変わるのか #
- これまで: WebSocket API の構築には、ルート、統合、ステージ、デプロイメントなどの CloudFormation リソースを個別に定義する必要があり、記述量が多くエラーも発生しやすかった。
- これから: SAM の抽象化されたリソース（
WebSocketApi）により、$connect,$disconnect,$defaultといった主要なルートと Lambda 関数の紐付けを簡潔に記述できる。
具体的なユースケース #
- サーバーレスで構築したチャットアプリケーションのバックエンドを、SAM を使って迅速にデプロイ・管理する。
- リアルタイムでデータを更新し続けるダッシュボード向けのプッシュ通知基盤を構築する。
Amazon Bedrock AgentCore が AWS GovCloud (US-West) で提供開始 #
投稿日: 2026年05月05日
何ができるようになったのか #
エンタープライズグレードのエージェント型 AI 基盤である Amazon Bedrock AgentCore が、AWS GovCloud (US-West) リージョンで利用可能になりました。これにより、政府機関や規制の厳しい業界においても、高いコンプライアンス基準を維持しながら AI エージェントの構築・デプロイ・運用が可能になります。
何が嬉しいのか #
インフラを自前で管理することなく、セキュリティが確保されたスケール可能な AI エージェントプラットフォームを利用できます。AgentCore Runtime によるセッションの分離、AgentCore Gateway による既存 API のツール化（MCP経由）、既存の ID プロバイダーとの連携、および本番環境でのオブザーバビリティと評価機能が含まれており、プロトタイプから本番への移行を加速させます。
これまでとどう変わるのか #
- これまで: GovCloud 上で高度な AI エージェントを構築するには、セキュリティや分離の要件を満たすために多大なインフラ構築・管理コストがかかっていた。
- これから: AgentCore を利用することで、マネージドなサービスとして政府レベルのセキュリティ要件を満たす AI エージェントを迅速に展開できる。
具体的なユースケース #
- 政府機関において、機密性の高い公文書データを安全に参照し、市民からの複雑な問い合わせに回答する AI エージェントを構築する。
- 規制対象のワークロードにおいて、承認済みの既存システム（API）と連携して特定の事務処理を自動化するエージェントを運用する。
Amazon EC2 Instance Store CSI ドライバが EKS アドオンとして一般提供開始 #
投稿日: 2026年05月05日
何ができるようになったのか #
Amazon EKS において、Amazon EC2 インスタンスストア CSI ドライバを EKS アドオンとしてコンソールや CLI から直接管理できるようになりました。
何が嬉しいのか #
EC2 の「インスタンスストア（ローカル NVMe ストレージ）」を、Kubernetes の永続ボリューム（Persistent Volume）としてより簡単に利用できるようになります。インスタンスストアはホストコンピューターに物理的にアタッチされているため、非常に低レイテンシで高速なブロックレベルのストレージを提供します。これを標準的な Kubernetes のストレージ管理手法で扱えるようになります。
これまでとどう変わるのか #
- これまで: インスタンスストアを EKS で利用するには、手動で設定を行うか、独自の管理手法が必要だった。
- これから: 公式の CSI ドライバが EKS アドオンとして提供されるため、インストールやアップデートが簡単になり、運用のベストプラクティスに則った利用が容易になる。
具体的なユースケース #
- 一時的なデータ（テンポラリファイルやキャッシュ）を大量に扱うデータ分析ワークロードにおいて、EBS ではなく高速なローカルインスタンスストアを活用してパフォーマンスを最大化する。
- 分散データベースや分散ファイルシステムにおいて、ノードローカルな高速ストレージとしてインスタンスストアを Kubernetes 経由で割り当てる。
インスタンスストアは「エフェメラル（一時的）」なストレージであることに注意が必要です。 主な特徴は以下の通りです。
- ホストに物理的に付随しているため、ネットワーク経由の EBS より高速。
- インスタンスが停止または終了すると、保存されているデータは失われる。
- 永続性が必要なデータには適さないが、キャッシュや一時的な高速処理には最適。
Amazon EC2 I8ge インスタンスが東京リージョンを含む複数のリージョンで利用可能に #
投稿日: 2026年05月04日
何ができるようになったのか #
AWS Graviton4 プロセッサを搭載したストレージ最適化インスタンス「Amazon EC2 I8ge」が、アジアパシフィック（東京、ソウル、香港、タイ）および欧州（パリ）のリージョンで一般提供開始されました。
何が嬉しいのか #
I8ge インスタンスは、前世代の Graviton2 ベースのインスタンスと比較して、計算パフォーマンスが最大 60% 向上しています。また、第3世代の AWS Nitro SSD を採用しており、リアルタイムストレージパフォーマンスが最大 55% 向上、ストレージ I/O レイテンシが最大 60% 低減されています。大規模なデータセットへの高速アクセスが必要なワークロードに最適です。
これまでとどう変わるのか #
- これまで: 最新の Graviton4 ストレージ最適化インスタンスを利用できるリージョンが限られていた。
- これから: 東京リージョンを含む多くのリージョンで、120TB までのローカル NVMe ストレージを備えた高性能な I8ge インスタンスを利用可能になる。
具体的なユースケース #
- 高速なローカルストレージが必要な NoSQL データベース（MongoDB, ScyllaDB など）を、Graviton4 による高いコストパフォーマンスで東京リージョンにて実行する。
- リアルタイムでのデータインデックス作成やログ分析ワークロードを、低レイテンシな Nitro SSD を活用して高速化する。
Amazon WorkSpaces が AI エージェントによるデスクトップアプリ操作に対応（プレビュー） #
投稿日: 2026年05月05日
何ができるようになったのか #
Amazon WorkSpaces において、AI エージェントが安全にデスクトップアプリケーション（メインフレーム接続ソフト、ERP、独自ツールなど）にアクセスし、操作できるようになりました。
何が嬉しいのか #
多くの企業では、モダンな API を持たないレガシーなデスクトップアプリケーション上で重要なビジネスプロセスが実行されており、これが AI による自動化のボトルネックとなっていました。今回のアップデートにより、AI エージェントが人間と同じようにデスクトップを「見て、クリックして、操作する」ことが可能になります。これにより、アプリケーションの近代化を待たずに、既存のツールを使った業務の自動化をスケールさせることができます。
これまでとどう変わるのか #
- これまで: AI エージェントによる自動化は主に Web API が提供されているシステムに限られていた。GUI 操作が必要なデスクトップアプリの自動化は RPA 等の別技術が必要で、AI との統合も複雑だった。
- これから: Model Context Protocol (MCP) を通じて AI エージェントが WorkSpaces に接続でき、中央集中型の権限管理・ロギング・監査体制の下でデスクトップアプリを直接操作できるようになる。
具体的なユースケース #
- 請求処理において、AI エージェントが WorkSpaces 上のレガシーな ERP ソフトを操作してデータを入力し、完了後にスクリーンショットを添えて報告する。
- 金融サービスのバックオフィス業務で、複数のデスクトップツールを跨いでデータを照合し、不整合があれば修正する。
オブザーバビリティとガバナンスも考慮されています。 主な特徴は以下の通りです。
- AI エージェントの活動は、人間と同様の WorkSpaces 環境として一元管理される。
- エージェントの操作画面のスクリーンショットやメトリクスを記録し、監査が可能。