本日の主なトピック

#

• 次世代開発環境と体験: ブラウザ上で AWS アカウントなしで分散 SQL を試せる「Aurora DSQL Playground」や、AI 駆動型 IDE「Kiro IDE」向けのオブザーバビリティ拡張機能が登場。
• AI ワークフローの強化: Amazon Bedrock がサーバーサイドでのツール実行に対応し、エージェント開発の複雑さを大幅に軽減。
• 最新ハードウェアの拡充: AWS Graviton4 搭載 M8gn/M8gb のベアメタルサイズや、最新ストレージ最適化インスタンス I7ie のリージョン拡大。
• AI トラフィックの可視化: AWS WAF に AI ボット専用のダッシュボードが追加され、650 種類以上の AI ボットを識別・制御可能に。
• セキュリティと運用管理: 複数アカウントにまたがる VPC へのペネトレーションテスト対応や、RDS Custom for SQL Server のセキュリティパッチ適用。

AWS運用入門 改訂第2版 押さえておきたいAWSの基本と運用ノウハウ [AWS深掘りガイド] 単行本（ソフトカバー） – 2025/7/11

¥3,520

Amazonで見る

---

Amazon Aurora DSQL が Playground を発表。AWS アカウントなしで対話的なデータベース操作が可能に

#

投稿日: 2026年02月25日

Amazon Aurora DSQL launches Playground for interactive database exploration

aws.amazon.com

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

#

ブラウザベースの対話型環境「Amazon Aurora DSQL Playground」がリリースされました。これにより、開発者は AWS アカウントを作成することなく、セットアップや設定不要で Aurora DSQL を直接試用できるようになります。ブラウザ上で SQL クエリの実行、スキーマ設計のテスト、PostgreSQL 互換の分散 SQL 機能の体験が可能です。

何が嬉しいのか

#

開発者は、本番環境へのデプロイ前に Aurora DSQL の概念を学び、アプリケーションスキーマのプロトタイプ作成やクエリパターンの検証を即座に行えます。サンプルデータセットも含まれているため、分散ワークロードに最適化されたスキーマ設計のベストプラクティスを迅速に理解できます。

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

#

• これまで: Aurora DSQL を試すには、AWS アカウントを用意し、クラスターの設定を行う必要がありました。
• これから: AWS アカウントや初期設定が一切不要になり、ブラウザから即座にサンドボックス環境で Aurora DSQL の機能を試せるようになります。

具体的なユースケース

#

• 新規プロジェクトでの Aurora DSQL 採用を検討する際の、クエリ実行テスト
• 分散データベースにおけるスキーマ設計の学習と検証
• チーム内での簡単な SQL プロトタイプの共有

---

Amazon Bedrock が AgentCore Gateway を介したサーバーサイドでのツール実行に対応

#

投稿日: 2026年02月24日

Amazon Bedrock now supports server-side tool execution with AgentCore Gateway

aws.amazon.com

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

#

Amazon Bedrock の Responses API において、AgentCore Gateway との統合によるサーバーサイドでのツール実行が可能になりました。開発者は Responses API のリクエスト時に AgentCore Gateway の ARN を指定するだけで、Bedrock が自動的にツールを検出し、モデルの判断に基づいてサーバーサイドでツールを実行、その結果を会話に反映させることができます。

何が嬉しいのか

#

これまでクライアント側で行っていた「モデルによるツール選択 → クライアントでのツール実行 → 結果をモデルに再入力」というオーケストレーションループを、Bedrock 側で完結できるようになります。これにより、アプリケーションの複雑さが軽減され、エージェントワークフローのレイテンシが向上します。また、既存の IAM 権限や AgentCore Gateway の設定でアクセス制御を継続して行えます。

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

#

• これまで: ツール実行を行うには、クライアント側でモデルの応答を解析し、ツールを実行して、その結果を再度 API に送信するループを構築・維持する必要がありました。
• これから: 単一の API コール内で Bedrock がツールの発見、選択、実行、結果の注入をすべて自動で処理します。MCP (Model Context Protocol) サーバーコネクタタイプを使用して、ゲートウェイ ARN を定義するだけで利用可能です。

具体的なユースケース

#

• 複雑なエージェントアプリケーションにおけるバックエンド処理の簡素化
• リアルタイム性が求められる対話型 AI ツール（複数のツール実行を伴うもの）の開発
• MCP を利用した既存の社内ツールや外部 API とのシームレスな統合

---

Amazon EC2 I7ie インスタンスが AWS アフリカ（ケープタウン）リージョンで利用可能に

#

投稿日: 2026年02月24日

Amazon EC2 I7ie instances now available in AWS Africa (Cape Town) region

aws.amazon.com

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

#

ストレージ最適化インスタンスの最新世代である Amazon EC2 I7ie インスタンスが、AWS アフリカ（ケープタウン）リージョンで利用可能になりました。I7ie インスタンスは第 5 世代 Intel Xeon スケーラブルプロセッサを搭載し、大規模なストレージ I/O 集約型ワークロード向けに設計されています。

何が嬉しいのか

#

I7ie インスタンスは、前世代の I3en インスタンスと比較して、計算パフォーマンスが最大 40%、価格パフォーマンスが最大 20% 向上しています。また、最大 120TB のローカル NVMe ストレージを提供し、リアルタイムストレージパフォーマンスが最大 65% 向上、I/O レイテンシが最大 50% 低減されています。これにより、大規模なデータセットへの高速なアクセスが必要なワークロードの効率が大幅に向上します。

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

#

• これまで: ケープタウンリージョンで大容量・低レイテンシのローカルストレージを必要とする場合、前世代のインスタンスを使用する必要がありました。
• これから: 最新の AWS Nitro SSD を搭載した I7ie インスタンスを使用することで、より高いストレージ密度、低いレイテンシ、および優れた価格パフォーマンスを享受できるようになります。

具体的なユースケース

#

• 大規模な NoSQL データベース（Cassandra、MongoDB など）の実行
• 分散ファイルシステムのホスティング
• 大規模なデータウェアハウジングおよび分析ワークロード

---

Amazon EC2 M8gn および M8gb インスタンスに新しいベアメタルサイズ（metal-24xl, metal-48xl）が登場

#

投稿日: 2026年02月25日

Announcing new metal sizes for Amazon EC2 M8gn and M8gb instances

aws.amazon.com

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

#

AWS Graviton4 プロセッサを搭載した Amazon EC2 M8gn および M8gb インスタンスにおいて、新しいベアメタルサイズである metal-24xl と metal-48xl が一般提供されました。これにより、Graviton4 の高いパフォーマンスを、ハードウェアへの直接アクセスが必要なワークロードでも利用可能になります。

何が嬉しいのか

#

M8gn インスタンスは第 6 世代 AWS Nitro Card を採用しており、ネットワーク最適化インスタンスの中で最高クラスの最大 600 Gbps のネットワーク帯域幅を提供します。一方、M8gb インスタンスは最大 300 Gbps の EBS 帯域幅を提供し、高いブロックストレージパフォーマンスを必要とするデータベースなどのワークロードに最適です。ベアメタルサイズの使用により、ハイパーバイザーを介さない性能や、特殊なライセンス要件、ハードウェアレベルのカスタマイズが必要なアプリケーションを、これら最新世代の Graviton4 インスタンスで実行できます。

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

#

• これまで: M8gn や M8gb の Graviton4 インスタンスを使用する場合、仮想化されたインスタンスサイズに限られていました。
• これから: metal-24xl や metal-48xl サイズを選択することで、最大 192 個の vCPU と 768 GiB のメモリを備えた強力な Graviton4 リソースを、ベアメタル環境として利用できるようになります。

具体的なユースケース

#

• M8gn: 高性能ファイルシステム、分散メモリキャッシュ、リアルタイムビッグデータ分析、5G UPF などの通信アプリケーション
• M8gb: 高性能データベース、NoSQL データベースなど、高い EBS パフォーマンスが要求されるワークロード
• 緊密に結合されたクラスター（EFA 利用）での低レイテンシ・ハイパフォーマンスコンピューティング

---

Amazon RDS Custom for SQL Server が最新の GDR アップデート（KB5072936）に対応

#

投稿日: 2026年02月24日

Amazon RDS Custom now supports the latest GDR updates for Microsoft SQL Server

aws.amazon.com

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

#

Amazon RDS Custom for SQL Server において、Microsoft SQL Server の最新の General Distribution Release (GDR) アップデートがサポートされました。これには、SQL Server 2022 の累積更新プログラム（CU）および KB5072936 (16.00.4230.2.v1) が含まれます。

何が嬉しいのか

#

この GDR アップデートには、脆弱性 CVE-2026-20803 への対策が含まれており、データベースのセキュリティと安定性が向上します。RDS Custom ユーザーは、マネージド型の利便性を保ちつつ、基盤となる OS やデータベースエンジンの最新のセキュリティパッチを適用できるようになります。

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

#

• これまで: RDS Custom 環境で最新の SQL Server セキュリティパッチ（KB5072936）を適用するには、パッチの検証や手動適用の手間がかかっていました。
• これから: Amazon RDS マネジメントコンソール、AWS SDK、または CLI を通じて、推奨されるこれらのアップデートを容易に適用できるようになります。

具体的なユースケース

#

• セキュリティコンプライアンス遵守のための定期的なパッチ適用
• SQL Server 2022 環境における既知の脆弱性への迅速な対応
• RDS Custom の柔軟性を活かした、安全なデータベース運用管理

---

Amazon S3 サーバーアクセスログにリクエスト送信元の AWS リージョン情報が追加

#

投稿日: 2026年02月23日

Amazon S3 now provides AWS source region information in server access logs

aws.amazon.com

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

#

Amazon S3 のサーバーアクセスログにおいて、リクエストがどの AWS リージョンから送信されたかを示す「ソースリージョン情報」が含まれるようになりました。これにより、データの取得リクエストがどのリージョンから来ているかを正確に把握できます。

何が嬉しいのか

#

クロスリージョンでのリクエストが発生しているアプリケーションを容易に特定できるようになります。クロスリージョン通信はデータ転送料金が発生し、レイテンシも増加するため、この情報を活用することで、コストの最適化やパフォーマンスの向上のためのアクション（データの配置場所の見直しなど）が可能になります。

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

#

• これまで: リクエストの送信元 IP アドレスなどは記録されていましたが、具体的にどの AWS リージョンからのリクエストであるかを判断するには、IP アドレス範囲のリストと照合するなどの手間が必要でした。
• これから: アクセスログの各エントリの末尾に、ソースリージョン名（例: us-west-2）が自動的に付与されます。追加の設定や費用は不要です。

具体的なユースケース

#

• クロスリージョンでのデータ転送料金が高騰している原因の調査
• レイテンシに敏感なアプリケーションにおいて、物理的に離れたリージョンからアクセスしているクライアントの特定
• リージョンをまたぐ意図しないデータアクセスの監査とセキュリティ強化

---

AWS Compute Optimizer が自動化により作成された EBS スナップショットにタグを自動適用

#

投稿日: 2026年02月24日

AWS Compute Optimizer now applies AWS-generated tags to EBS snapshots created during automation

aws.amazon.com

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

#

AWS Compute Optimizer が、使用されていない（アンアタッチ状態の）Amazon EBS ボリュームを削除する際に作成するスナップショットに対して、AWS 生成タグを自動的に適用するようになりました。具体的には、aws:compute-optimizer:automation-event-id というタグが付与され、その値には作成のきっかけとなった自動化イベントの一意の識別子が記録されます。

何が嬉しいのか

#

自動化プロセスによって作成されたスナップショットの識別と追跡が容易になります。大量のスナップショットがある環境でも、どのスナップショットが Compute Optimizer の最適化（不要ボリュームの削除）の一環として作成されたバックアップなのかを即座に判断でき、リソース管理やガバナンスの向上が図れます。

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

#

• これまで: Compute Optimizer が不要ボリュームを削除する前に作成したスナップショットは、他の通常のスナップショットと見分けがつきにくく、管理や後々の削除判断が困難な場合がありました。
• これから: 自動的に付与されるタグによって、スナップショットのソースと目的が明確になり、自動化イベントに関連付けて管理できるようになります。

具体的なユースケース

#

• Compute Optimizer によって作成されたスナップショットをタグベースで抽出し、一定期間後に自動削除するライフサイクル管理の構築
• 最適化アクション（ボリューム削除）の結果として作成されたバックアップリソースのコスト分析と監査
• 環境内に存在するスナップショットの由来（どの自動化ツールが作成したか）の可視化

---

AWS Observability が Kiro Power として提供開始。AI エージェントによるトラブルシューティングを加速

#

投稿日: 2026年02月24日

AWS Observability now available as a Kiro power

aws.amazon.com

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

#

AI 駆動型 IDE である「Kiro IDE」の拡張機能パッケージ「Kiro Power」の一つとして、AWS Observability が利用可能になりました。このパッケージには、CloudWatch、Application Signals、CloudTrail、および AWS Documentation の 4 つの専門的な MCP (Model Context Protocol) サーバーが含まれており、AI エージェントがこれらのデータに直接アクセスして、インフラやアプリケーションの正常性を調査できるようになります。

何が嬉しいのか

#

開発者は IDE 内で、AI エージェントの支援を受けながら分散アプリケーションのトラブルシューティングを数分で完了できるようになります。アクティブなアラームの調査時には、AI エージェントが CloudWatch や CloudTrail から必要なコンテキストのみを動的に読み込み、迅速な解決策を提案します。また、コードを解析してログ不足や分散トレーシングの欠如を特定する「自動ギャップ分析」機能により、プロアクティブにオブザーバビリティを向上させることも可能です。

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

#

• これまで: トラブルシューティングの際、開発者は AWS マネジメントコンソールと IDE を行き来し、CloudWatch のログやメトリクス、CloudTrail のイベントなどを手動で収集・解析する必要がありました。
• これから: Kiro IDE 上で、AI エージェントが MCP サーバーを通じてオブザーバビリティデータに即座にアクセスし、アラームへの対応、異常検知、SLO 遵守状況の監視、セキュリティ調査などを一貫したワークフローとして実行します。

具体的なユースケース

#

• CloudWatch アラーム発生時の、原因調査と修正案の生成（IDE 内で完結）
• アプリケーションコードにおける計装（ログ、トレースなど）の不足箇所の自動特定と修正
• セキュリティイベント発生時の CloudTrail ログに基づいた迅速な影響範囲の分析

---

AWS Security Agent が複数アカウントをまたぐ共有 VPC へのペネトレーションテストに対応

#

投稿日: 2026年02月25日

AWS Security Agent adds support for penetration tests on shared VPCs across AWS accounts

aws.amazon.com

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

#

AWS Security Agent において、同じ AWS Organizations 内の他アカウントから共有された VPC リソースに対してペネトレーションテストを実行できるようになりました。AWS Resource Access Manager (RAM) を活用することで、サブアカウントの VPC リソースを中央のセキュリティ管理用アカウントに共有し、そこから包括的なセキュリティ評価を実施することが可能です。

何が嬉しいのか

#

複数の AWS アカウントにまたがる分散アーキテクチャを採用している組織において、セキュリティテストの集中管理と効率化が図れます。セキュリティ担当者は、アカウントごとにテスト環境を構築する手間を省き、中央のアカウントから組織全体の共有 VPC リソースに対して一貫したセキュリティアセスメントを行えるようになります。

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

#

• これまで: 他のアカウントと共有されている VPC リソースに対してペネトレーションテストを行うには、各アカウントで個別にテストをセットアップするか、複雑なネットワーク設定が必要でした。
• これから: RAM で共有された VPC を対象に、中央のアカウントで作成した「Agent Space」から直接テストを実行できるため、複雑なマルチアカウント環境でのセキュリティ評価が簡素化されます。

具体的なユースケース

#

• 大規模組織における、共有 VPC を利用した共通基盤への集中ペネトレーションテスト
• 新しく追加されたサブアカウントのネットワークリソースに対する、中央セキュリティチームによる迅速な脆弱性診断
• 複数アカウントにまたがる複雑なアプリケーション構成のセキュリティ境界の検証

---

AWS WAF が AI アクティビティダッシュボードを発表。AI ボットやエージェントのトラフィックを可視化

#

投稿日: 2026年02月24日

AWS WAF announces AI activity dashboard for visibility into AI bot and agent traffic

aws.amazon.com

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

#

AWS WAF において、アプリケーションに到達する AI ボットやエージェントのトラフィックを中央で可視化する「AI アクティビティダッシュボード」が導入されました。また、AWS WAF Bot Control の検出カタログが拡張され、650 種類以上のユニークな AI ボットやエージェント（AI 検索エンジンクローラー、AI データコレクター、LLM 学習用クローラーなど）を識別可能になりました。

何が嬉しいのか

#

急速に増加している AI 関連のトラフィック（RAG システムによるデータ取得、自律型エージェントの API 実行など）が、インフラコストやアプリケーションのパフォーマンスに与える影響を正確に把握できるようになります。ダッシュボードを通じて、最もアクティブなボットや頻繁にアクセスされるパスを特定し、検証済みの AI 検索クローラーは許可しつつ、未検証のエージェントはレート制限したりブロックしたりといった対策を WAF ルールで即座に実行できます。

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

#

• これまで: 一般的なボットと AI 特有のボット（トレーニング用や推論用など）を細かく分類して可視化したり、最新の AI ボットを迅速に特定して制御したりするには、カスタムルールの作成やログの高度な分析が必要でした。
• これから: 専用のダッシュボードで AI トラフィックの傾向を視覚的に分析でき、常に更新される 650 以上のボットカタログを利用して、新たな AI ボットに対しても即座に対応可能になります。

具体的なユースケース

#

• 自社コンテンツがどの AI モデルの学習に使用されているかの可視化と制御
• RAG（検索拡張生成）システムによる頻繁なスクレイピングによるサーバー負荷の軽減
• 公開 API に対する AI エージェントの過剰なアクセスのレート制限

Reply by Email