本ブログは 2026 年 8 月 18 日に公開された AWS Blog “ Security Hub Extended adds Supply Chain Security as its tenth category ” を翻訳したものです。 今年 2 月以降、AWS は AWS Security Hub Extended を、9 カテゴリにわたる厳選された 14 パートナーから、10 カテゴリ 23 パートナーへと拡大してきました。今月の Black Hat では、そのうち 14 パートナーが Amazon Web Services (AWS) ブースでライブデモを実施しました。4 パートナーがシアタートークを行い、10 パートナーが SecurityLive のストリーミング配信で紹介されました。また、AWS のリーダーシップとパートナー企業の経営陣が一堂に会し、今後の計画を話し合うパートナーレセプションも開催しました。これらの企業は、AWS とともに、そして次第にパートナー同士でも、エンジニアリングと市場開拓 (GTM) に本格的に投資しています。このモデルが、パートナーが日々接しているお客様から支持されているからです。ブースで最も多く寄せられた質問は、サプライチェーンセキュリティはいつ提供されるのか、というものでした。 その提供が始まりました。サプライチェーンセキュリティはカテゴリとして最も多くのお問い合わせをいただいているため、今回はこの話題を中心にお伝えします。 サプライチェーンセキュリティ: お客様が求め続けてきたカテゴリ ソフトウェアサプライチェーンのリスクは、セキュリティチームの懸念事項から、取締役会レベルの議題へと変わりました。SolarWinds の事例は、ビルドシステムが侵害されると何が起きるかを明らかにしました。Log4j の事例は、たった 1 つの推移的依存関係の脆弱性が世界規模で何を引き起こすかを示しました。xz utils のバックドアの事例は、メンテナーを侵害する攻撃が何年もかけて実行される執拗さを浮き彫りにしました。それぞれが同じ問題の異なる側面を示しており、そのペースは加速しています。攻撃者は、企業が知らず知らずのうちに信頼しているオープンソースパッケージこそが、企業への近道であることを知っています。 Black Hat で話をしたすべてのお客様が、この問題をリスク登録簿に載せていました。しかし、その多くはまだ解決策を運用に落とし込めていませんでした。運用化には、個別のデプロイ、新しい契約、新しいコンソール、そしてセキュリティチームが優先順位を上げられない統合作業が必要だったからです。AWS が取り除こうとしているのは、まさにこうした導入の手間です。 Security Hub Extended では、厳選されたパートナーとして Chainguard と Socket によるサプライチェーンセキュリティの提供を開始しました。サプライチェーンセキュリティは、Extended の他のすべてと同じモデルを採用しています。すべてのオファリングが従量制料金で、請求は 1 つにまとまり、長期契約は必須ではありません。これまでどおりの調達プロセスを継続したい企業向けには、Security Hub Extended のプライベートオファーも利用できます。プライベートオファーは、一定期間の利用をコミットする契約で、より大きな割引が適用され、複数パートナーへの支出を単一の AWS 請求に集約でき、契約期間を通じて月払いと年払いのどちらの支払いオプションも選択できます。お客様の購買プロセスに合った方法を選択できます。 Chainguard の役割 Chainguard は、強化・検証されたビルドプロセスでソースから再ビルドしたオープンソースの依存関係を提供します。これにより、お客様の環境に入ってくるものは、マルウェアに強く、来歴 (プロベナンス) に裏付けられたものになります。 同社の調査 によると、ソースからの再ビルドを行っていれば、既知の悪意あるパッケージの 98% が本番環境に到達するのを防げたとされています。ソースを検証できないものは、Chainguard のリポジトリに一切登録されません。これが、パブリックレジストリと開発者の間のフィルターとなります。 Socket の役割 Socket は、オープンソースパッケージの実際の挙動を分析し、インストール時点で悪意ある依存関係をブロックします。数日から数週間後に CVE (Common Vulnerabilities and Exposures) が公開されるのを待つのではありません。パッケージがお客様の環境に入り込もうとしたその瞬間に、Socket はデータベースの情報ではなくパッケージの挙動そのものに基づいて検知します。さらに、到達可能性分析によって、どの脆弱性がお客様のコードから悪用可能かがわかるため、チームがノイズに埋もれることがありません。料金は、チェックする個別のパッケージ数に基づき、ビルドの実行回数には依存しません。 2 社が連携して機能する理由 Chainguard と Socket を組み合わせることで、重要な 2 つの問いに対応できます。 取り込むものを信頼できるか 悪意あるコンポーネントがアプリケーションに組み込まれる前に阻止できるか Chainguard はコードが構築される基盤の保護を支援し、Socket はそこに取り込むパッケージを保護します。両者は、クラウドでもオンプレミスでも、デプロイ先を問わずソフトウェアサプライチェーンの保護に役立ちます。Security Hub Extended を通じて両方を有効化すると、その検出結果は OCSF (Open Cybersecurity Schema Framework) 形式で他のすべての情報とともに Security Hub に流れ込みます。これにより、サプライチェーンのリスクは、エンドポイント、アイデンティティ、クラウドの各シグナルと並べて相関付けられ、優先順位付けされます。そこから、すでに統合済みの下流ツールへとルーティングされるため、開発者が現在使っているパイプラインにそのまま適合します。 23 パートナー、10 カテゴリ。お客様の要望に基づいて構築 Security Hub Extended のすべてのパートナーは、お客様がその機能を必要としていると伝えてくれたこと、そしてその特定のソリューションがすでにお客様のもとで機能していたことを理由に参加しています。脅威の状況が進化するためカテゴリを追加し、それらの問題をうまく解決している企業をお客様が教えてくれるためパートナーを追加しています。目標はシンプルです。すでにお持ちの AWS との取引関係を通じて、同業他社がすでに成果を上げているセキュリティソリューションの導入を簡素化することです。 現在の対象領域は、エンドポイント、アイデンティティ、E メール、ネットワーク、データ、ブラウザ、クラウド、AI、セキュリティオペレーション、そして新たにサプライチェーンに及びます。23 の厳選されたパートナーは、7AI、Britive、Chainguard、CrowdStrike、Cyera、Island、LayerX、Native Security、Noma、Okta、Oligo、Opti、Palo Alto Networks、Proofpoint、SailPoint、SentinelOne、Socket、Splunk、Sublime、Upwind、Varonis、Zenity、Zscaler です。 AWS が現在注力しているのは、統合を深化させ、有効化にかかる手間を減らすことで、これらのソリューションが個別にではなく連携して機能するようにすることです。そこにこそ、価値が相乗的に高まっていきます。 今後の取り組み ここまで説明してきたことはすべて、販売モデルが機能していることの表れです。つまり、お客様が期待どおりの柔軟性のもとで、AWS との単一の取引関係を通じてベストオブブリードのセキュリティを購入しているということです。しかし、より大きなビジョンは、これらのツールを単に購入しやすくするだけでなく、組み合わせて使うことで実際に効果が高まる統合レイヤーです。 最も注力している統合は、クロスパートナーの相関付けです。エンドポイントソリューション、アイデンティティソリューション、クラウドソリューションからのシグナルを、相互に関連付けられていない 3 つのアラートではなく、1 つのエクスポージャーと 1 つの攻撃パスにまとめます。これと並行して、有効化、デプロイ、統合にかかる手間を大幅に減らし、お客様がサブスクライブしてから価値を実感するまでの時間を数週間ではなく数時間にすることに取り組んでいます。この 2 つの取り組みにより、お客様がすでに信頼している厳選されたソリューションは、個別に使うよりも連携させることで、より大きな成果をもたらします。 これが、AWS がパートナーとともに今まさに加速している取り組みです。re:Invent に向けて、さらに詳しい情報をお届けする予定です。 利用できるオファリングを確認する 本番環境でオープンソースソフトウェアを運用していて、まだサプライチェーンの可視性を確保できていない場合は、そこから始めてください。今すぐ Security Hub コンソールから Chainguard と Socket を有効化できます。複数のセキュリティベンダーとの関係を管理していて、Security Hub Extended による統合がどのようなものかを知りたい場合は、AWS アカウントチームにご相談ください。すべてのパートナーの料金は 料金ページ に公開されており、営業担当への問い合わせは不要です。また、すでにセキュリティ態勢管理と脅威検出に Security Hub を使用している場合、Extended プランは現在お使いのコンソールでそのまま利用できます。 これはまだ始まりにすぎません。 Michael Fuller Michael は AWS に 16 年間在籍し、11 年にわたって AWS セキュリティサービスのプロダクトを率いてきました。業界歴は 29 年で、IBM、Cisco、Amazon においてプロダクトマネジメント、事業開発、ソフトウェア開発のさまざまな役職を歴任してきました。アリゾナ大学でコンピュータ工学の理学士号を、ワシントン大学で MBA を取得しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

はじめに 「This Month in AWS Observability」最新号へようこそ。今回は、この6月に Amazon CloudWatch と AI 駆動型オペレーション全般で発表された新機能をご紹介します。CloudWatch でネイティブな OpenTelemetry メトリクスと PromQL クエリが一般提供（GA）となり、より深い統計・構造化分析のための 23 個の新しい Logs Insights コマンドがローンチされ、CloudWatch RUM に Session Replay が登場し、 AWS DevOps Agent では MCP および Agent-to-Agent プロトコルをサポートするカスタム SRE エージェントがリリースされました。EKS クラスター全体で GPU コストを配賦する場合も、実際のセッション再生でフロントエンドの問題をデバッグする場合も、チームのランブックを自律型 SRE エージェントに組み込む場合も、役立つ情報が見つかるはずです。これらの新機能のデモをご覧になりたい方は、8月11日開催のウェビナー「 I Didn’t Know Amazon CloudWatch Could Do That 」にご登録ください。 OpenTelemetry と Prometheus Amazon CloudWatch は、ネイティブ OpenTelemetry メトリクスと PromQL クエリの一般提供という大きなマイルストーンに到達しました。また、Amazon Managed Service for Prometheus には、高カーディナリティなワークロードのコストと複雑さを削減する機能が追加されました。 ネイティブ OpenTelemetry メトリクスと PromQL クエリ（GA）  Amazon CloudWatch が OpenTelemetry メトリクスをネイティブにサポートし、一般提供が開始されました。チームは OpenTelemetry Protocol（OTLP）経由でメトリクスを直接送信し、Prometheus Query Language（PromQL）でクエリできます。料金は GB あたりの取り込み課金で、15 か月分のストレージが含まれます。これにより、CloudWatch と並行して別途 Prometheus 互換バックエンドを用意する必要がなくなります。数十のラベル（namespace、pod、container、node、deployment）を持つ高カーディナリティメトリクスが CloudWatch に直接流れ込み、チームがすでに慣れ親しんだ PromQL 構文で即座にクエリ可能になります。 CloudWatch Pipelines が OpenTelemetry メトリクスの処理とエンリッチメントをサポート  CloudWatch Pipelines により、カスタムインフラストラクチャやアプリケーション計装の変更なしに、取り込み時に OpenTelemetry メトリクスの処理とエンリッチメントが可能になりました。例えば、ビジネスコンテキストの追加、高カーディナリティラベルの除去、命名規則の強制などが行えます。 Amazon Managed Service for Prometheus のネイティブヒストグラムサポート  ネイティブヒストグラムは、バケット境界ごとに 1 つの時系列を出力する従来の Prometheus ヒストグラムを置き換えるものです。20 個以上のバケット境界を事前定義してメトリクスごとに 20 以上の時系列分のコストを支払う代わりに、ネイティブヒストグラムは分布全体を動的な解像度を持つ単一の時系列に格納します。これにより、レイテンシー、リクエスト時間、値の分布の追跡において正確なパーセンタイル計算を維持しながら、ストレージコストとカーディナリティを削減できます。 OTel と Managed Prometheus による GPU コスト配賦  Amazon Elastic Kubernetes Service 上で AI/ML ワークロードをスケールさせるチーム向けに、OpenTelemetry コレクター、Amazon Managed Service for Prometheus、Amazon Managed Grafana を使用した GPU コスト配賦の新しいリファレンスアーキテクチャが公開されました。namespace、チーム、ワークロードタイプごとに GPU コストを配賦でき、「共有クラスターで最も高価なコンピューティングリソースを消費しているのは誰か」という問いに答えられます。 CloudWatch と OpenTelemetry による Claude Code 利用状況の分析  Claude Code のような AI コーディングエージェントがエンジニアリング組織全体に広がる中、トークン消費量、チームごとのコスト、開発者の生産性の追跡が重要になっています。このパターンでは、CloudWatch OTLP エンドポイントを使用して Claude Code セッションからカスタム OpenTelemetry メトリクスを取り込み、既存ツールでは答えられない問い（どのチームが最も多くのトークンを消費しているか、開発者あたりのコストはいくらか、AI 支援開発が最も価値を発揮しているのはどこか）に答えるダッシュボードを実現します。 ログ分析の進化 Amazon CloudWatch Logs の新しいクエリ・取り込み機能により、ログデータの大規模な分析・検索・ルーティングが容易になります。 23 個の新しい CloudWatch Logs Insights クエリコマンド  CloudWatch Logs Insights に、複数カテゴリにわたる 23 個の新しいクエリコマンドが追加されました。 パースコマンド: 多様なログ形式からの構造化抽出のための parse_json、parse_kv、parse_csv、parse_xml 分析関数: より深い統計分析のための median、percentile_cont、mode、variance、stddev ハッシュ・IP 関数: セキュリティおよびネットワーク調査ワークフローのための md5、sha256、ip_to_int、cidr_match 条件ロジック: より表現力豊かなクエリ構築のための case、coalesce、nullif、if これらの追加により、複雑な調査のためにログを外部分析プラットフォームへエクスポートする必要性が減少します。 Log Analytics 統合コンソール  新しい Log Analytics コンソールは、ロググループ横断のクエリ、自然言語によるログデータの探索、再利用可能なクエリパターンの保存を単一のインターフェースで提供します。従来は複数のコンソールページを行き来する必要があった作業が、単一のワークフローに統合されました。 タグベースのロググループクエリ 個々のロググループ名を指定する代わりに、タグでロググループをクエリできるようになりました。数百〜数千のロググループを持つ組織にとって、クエリのスコープ指定が簡素化されます。チーム、環境、サービス階層でロググループにタグ付けすることで、明示的なリストを維持することなく「決済チームの本番ログすべて」をクエリできます。 マネージド Syslog 取り込み  CloudWatch Logs が、VPC エンドポイント経由で TCP、TLS、UDP を使用したマネージド syslog 取り込みをサポートしました。RFC 5424、RFC 3164、および Cisco FTD や ASA を含むベンダー固有の形式に対応します。syslog メッセージは自動的に構造化フィールドにパースされ、手動での変換なしに Logs Insights で即座にクエリ可能になります。 Elastic Beanstalk ログ統合  AWS Elastic Beanstalk 環境が、ネイティブ統合によりアプリケーションログとプラットフォームログを CloudWatch Logs に直接ストリーミングできるようになりました。カスタムの .ebextensions 設定や、Beanstalk 管理インスタンス上のログストリーミングエージェントは不要です。 大規模なメトリクスとモニタリング 新しいクエリおよびメトリクス機能が拡張され、より大規模で複雑なマルチアカウントアーキテクチャを、より長い保持期間とより深いサービス固有の可視性でサポートします。 クロスアカウントメトリクスの一元化  CloudWatch が、簡素化された設定によるクロスアカウントメトリクスの一元的な収集をサポートしました。組織はモニタリングアカウントを指定し、メンバーアカウントからメトリクスを自動的に集約できます。アカウントごとの手動セットアップなしに、フリート全体のダッシュボードとアラームが実現します。 Metrics Insights の保持期間延長 CloudWatch Metrics Insights クエリが延長された保持期間をサポートし、より長い過去のウィンドウにわたる分析クエリを実行できるようになりました。これにより、外部分析システムへのデータエクスポートを必要とせず、CloudWatch 内で直接トレンド分析、キャパシティプランニング、前年比較が可能になります。 Amazon ElastiCache: 13 個の新しい CloudWatch メトリクス  Amazon ElastiCache が、メモリ断片化、接続チャーン、キー削除（Eviction）パターン、レプリケーションラグの詳細、コマンドレベルのレイテンシー分布をカバーする 13 個の新しい CloudWatch メトリクスを公開しました。これらのメトリクスは、従来は Redis や Memcached インスタンスに直接接続しないと観測できなかった、キャッシュ劣化の早期警告指標を見える化します。 エンドユーザーモニタリングと合成モニタリング 強化されたリアルユーザーの可視性と、より柔軟な合成テストトポロジーにより、モニタリングがエンドユーザーにさらに近づきます。 CloudWatch RUM Session Replay CloudWatch Real User Monitoring（RUM）に Session Replay が追加され、実際のユーザーセッションを発生した通りに記録・再生できるようになりました。顧客から報告された問題を調査する際、エンジニアはユーザーが体験したインタラクション、ページロード、エラー、レイテンシーの正確なシーケンスを見ることができ、フロントエンドデバッグから当て推量を排除します。 Synthetics マルチロケーション Canary  CloudWatch Synthetics に、単一の管理設定のもとで同じ合成テストを複数の AWS リージョンから同時に実行するマルチロケーション Canary が導入されました。各ロケーションは独立して動作します。あるロケーションが失敗を報告し、他が成功している場合、CloudWatch はシグナルを相関させて局所的な問題とグローバルな障害を区別し、誤検知によるアラームノイズを削減します。 AWS DevOps Agent によるインテリジェントオペレーション AWS DevOps Agent は、クラウド環境向けの AI 搭載オペレーションアシスタントとして進化を続けており、自動調査のインテリジェンスとリーチの両方を向上させる新機能が追加されました。 カスタム SRE エージェント  チーム固有の運用ランブックやインフラストラクチャパターンに合わせたカスタム SRE エージェントを構築できるようになりました。カスタムエージェントは、サービスアーキテクチャ、よくある障害モード、推奨される修復手順に関する組織の知見をエンコードし、繰り返し発生する問題の解決時間短縮を可能にします。 MCP および A2A プロトコルサポート  AWS DevOps Agent が Model Context Protocol（MCP）と Agent-to-Agent（A2A）通信をサポートしました。これにより、DevOps Agent はマルチエージェントアーキテクチャの中で他の AI エージェントとオーケストレーションし、外部ツールの呼び出し、ナレッジベースへのクエリ、組織の境界を越えた修復ワークフローの調整が可能になります。 Webhook トリガーと曖昧性解消カード  新しい Webhook ベースのトリガーにより、外部システム（PagerDuty、Datadog、カスタムアラートパイプライン）が DevOps Agent の調査を自動的に開始できるようになりました。調査中に曖昧さに遭遇した場合、曖昧性解消カード（disambiguation cards）が実行を停止させる代わりに構造化された選択肢をオペレーターに提示し、人間のガイダンスを得ながら調査ループを前進させ続けます。 5 つの新リージョンへの展開  AWS DevOps Agent がさらに 5 つの AWS リージョンで利用可能になり、広範なグローバルカバレッジを実現しました。ヨーロッパ、アジアパシフィック、および追加の北米リージョンで運用するチームは、調査をローカルで実行できるようになり、データレジデンシーの懸念を軽減し、リアルタイム運用ワークフローのレイテンシーを改善します。 開発者体験の改善 AWS DevOps Agent には、日常の運用ワークフローの摩擦を減らす、的を絞った QOL（quality-of-life）改善が加えられました。 リリース管理機能（プレビュー） DevOps Agent がリリース管理機能をプレビューとして提供開始しました。コード変更の本番投入準備状況をレビューし、標準からの逸脱、依存関係への影響、Well-Architected への準拠をチェックするとともに、テスト計画を自律的に生成・実行してデプロイ前にリグレッションを検出します。これにより、チームは AWS、マルチクラウド、オンプレミス環境全体で、より速いリリースと MTTR の削減を実現できます。 静的 IP サポート エージェントスペースにアウトバウンドトラフィック用の静的 IP アドレスを設定できるようになりました。IP ベースの許可リストを必要とする外部システム（オンプレミスの ITSM プラットフォーム、パートナー API、レガシーファイアウォール）との統合が可能になります。 自動拡張チャットと完全なコンテキスト保持  DevOps Agent の調査インターフェースに、自動的に広がるチャット入力欄と、調査セッションをまたいだ完全なコンテキスト保持が追加されました。より長く詳細なプロンプトが切り捨てられることなくサポートされ、以前の調査に戻ると会話履歴と調査結果が完全な状態で保持されています。 AWS Cloud Operations Blog の関連記事（2026年6月） 2026年5月〜6月に AWS Cloud Operations Blog で公開された記事は以下の通りです。 2026年6月 Log analysis with facets, correlation, enrichment, and automation in Amazon CloudWatch Log Analytics （6月19日）– Salman Ahmed, Ravi Kumar Amazon CloudWatch と OpenTelemetry による Claude Code 利用状況の分析 （6月17日）– Rodrigue Koffi, Gianluca Cacace, Vadim Omeltchenko GPU Cost Attribution in Amazon EKS Using Amazon Managed Service for Prometheus, Amazon Managed Grafana, and OpenTelemetry （6月12日）– Siva Guruvareddiar Introducing native histogram support in Amazon Managed Service for Prometheus （6月12日）– Vinod Kisanagaram, Priyanka Verma, Rohit Sharma まとめ 過去 2 か月間のオブザーバビリティ関連のローンチは、明確な方向性を示しています。AI 支援オペレーションはプロダクショングレードへの移行を続け、ログ分析は CloudWatch コンソールを離れることなくより強力になり、メトリクスはマルチアカウントのエンタープライズアーキテクチャに対応する規模へスケールし、モニタリングは合成テストとリアルユーザー体験の両レイヤーへさらに深く到達しています。 これらの機能を使い始めるには OpenTelemetry メトリクスを OTLP 経由で CloudWatch に直接送信 し、別途 Prometheus バックエンドなしで PromQL でクエリする 既存のロググループで新しい Logs Insights クエリコマンド を試す   CloudWatch RUM の Session Repla y を有効にして、ユーザーが体験していることを正確に確認する   マルチロケーション Canary を設定して、合成テストのカバレッジを向上させ誤報を削減する AWS DevOps Agent の  カスタムエージェント  を探索し、チームの運用ノウハウをエンコードする 最近のローンチの完全なリストは、Amazon CloudWatch でフィルタリングした AWS What’s New ページ をご覧ください。 さらに詳しく知りたい方へ 8月11日開催のウェビナー「 I Didn’t Know Amazon CloudWatch Could Do That 」に参加して、これらの新機能の実際の動作を確認し、トラブルシューティングの高速化に活用してください。 著者 Dot Ho Dot は AWS Observability 担当の Senior Technical Product Marketing Manager です。WCA 3×3 マルチブラインド（目隠し複数ルービックキューブ）ソルブの記録向上に向けて練習中です。 Joe Alioto Joe は AWS の Cloud Operations 担当の Worldwide Senior Specialist Solutions Architect で、オブザーバビリティ、AI 駆動のオペレーション、集中型オペレーション管理を専門としています。20年以上のオペレーションエンジニアリング経験を持ち、直近2年間は AI と AIOps に注力しています。彼は、アプリケーションパフォーマンス、インフラメトリクス、データベースワークロードを結びつけるインテリジェントなオブザーバビリティ戦略の構築を支援しており、AI エージェントと自動化を活用して平均解決時間 (MTTR) を短縮し、オペレーションチームの大規模な働き方を変革することにますます取り組んでいます。 本ブログは 2026 年 7 月 15 日に公開された This Month in AWS Observability: June 2026 の日本語訳です。翻訳はテクニカルアカウントマネージャーの日平が行いました。

みなさん､こんにちは｡ソリューションアーキテクトの杉山です｡今週も 週刊AWS をお届けします｡ 先週の木曜日､金曜日に AWS Summit Japan 2026 を開催しました｡台風が近づいていた中ではありましたが､多くのお客様にご来場いただきました｡ブースでたくさんのご相談を頂きましたが､AI 活用でどのような利便性があるのか､また､どういった仕組みでガバナンスを担保できるのか､という観点で質問を頂きました｡AWS Summit のセッションは､ オンデマンド視聴 が開始されています｡当日視聴が難しかった方も､キーノート､AWS セッション､お客様事例などをぜひご覧いただき次の一歩につながるヒントを得ていただければ幸いです｡ それでは､先週の主なアップデートについて振り返っていきましょう｡ 2026年6月22日週の主要なアップデート 6/22(月) Amazon Connect Customer が Agentic CX designer (NLX) のプレビュー版を提供開始 Amazon Connect Customer は､AI を活用したセルフサービス体験を設計・展開するためのノーコードキャンバス「Agentic CX designer (NLX)」のプレビュー版を提供開始しました｡ビジネスチームがコードを書かずに､エージェント型 AI と､本人確認や決済処理などの正確なアクションが求められるフローを組み合わせた音声・デジタル体験を構築できます｡また､通話中に顧客の Web/モバイルアプリをリアルタイムで操作できる Live Sync 機能も同時にプレビュー提供されます｡例えば､AI エージェントとホテル予約を通話している中で､会話内容に基づいて画面が同期して移動し､ホテルの予約を自動的に行うことがやりやすくなる仕組みです｡なお、プレビュー期間中は、ご自身のユースケースに合わせて精度などを検証いただくことが可能です｡ AWS Network Firewall がデフォルト drop action を更新し接続信頼性を改善 AWS Network Firewall は､新規作成するすべてのファイアウォールポリシーで､stateful action のデフォルトを “Application drop established (bidirectional)” から “Application drop established (server-directed only)” に変更しました｡この変更により､TCP window updates､keep-alives､resets などの正当なサーバーからクライアントへの TCP 制御パケットが誤ってドロップされることがなくなり､診断が困難だった断続的な接続障害を回避できます｡既存のポリシーには影響がなく､新規ポリシー作成時に自動的に適用されます｡ AWS Lambda MicroVMs で分離実行環境を提供開始 AWS Lambda MicroVMs を発表しました｡これはユーザーや AI が生成したコードを安全に実行するためのサーバーレスコンピューティング環境です｡VM レベルの分離､ほぼ瞬時の起動と再開速度､最大 8 時間の状態保存機能を提供します｡米国東部 (バージニア､オハイオ)､米国西部 (オレゴン)､アジアパシフィック (東京)､欧州 (アイルランド) で利用可能です｡従来の Lambda 関数がリクエストに応じて自動的にスケールするのに対し､MicroVMs は run-microvm API を呼んだ回数だけ MicroVM が 1 個ずつ起動し､各 MicroVM に専用の HTTPS エンドポイントが割り当てられます｡この「1 エンドポイント＝1 台」という特性を活かせば､ユーザーやセッションごとに独立した実行環境を割り当て､起動・サスペンド・終了のライフサイクルをアプリケーション側で自在に制御できるため､AI エージェントのコード実行サンドボックスやインタラクティブな開発環境のように「状態を保ったまま長時間使い続ける」ユースケースにうまくフィットします｡一方で従来の Lambda 関数は短時間・ステートレスなリクエストを大量にさばく用途に強いので､ワークロードの性質に応じて両者を使い分けるのがおすすめです｡なお､クォータは同時実行数ではなくアカウント・リージョンあたりの合計メモリ量で管理され､run-microvm API のレート制限はデフォルトで 5 TPS（バースト 5）です｡多数の環境を一度に立ち上げたい場合は､あらかじめサスペンド状態でプレウォームしておくと安定して払い出せます｡これらのクォータは Service Quotas コンソールから上限緩和を申請できます｡ 6/23(火) Claude Tag が AWS Marketplace の Claude Enterprise でベータ版として利用可能に Anthropic は､Claude Tag のベータ版を AWS Marketplace 経由で Claude Enterprise を利用する顧客向けに提供開始しました｡Claude Tag は､Slack チャネル内で @Claude とタグ付けすることで､チームメンバーが Claude にタスクを委任できる新機能です｡チャネルごとにアクセス権限と予算を設定でき､Claude は接続されたチャネルの文脈を記憶しながら､ツールやデータ､コードベースにアクセスできます｡管理者は Claude 管理コンソールで約 1 時間でエージェント ID をプロビジョニングし､チャネルごとにスコープを設定します｡ Amazon GuardDuty AI-powered investigations で脅威対応を加速 (Preview) Amazon GuardDuty に AI-powered investigations 機能 (Preview) が追加されました｡この機能は GuardDuty の findings とアカウントを自動的に分析し､真の脅威と誤検知を数分で見分けることができます｡過去 90 日間の関連アクティビティ､影響を受けるリソース､脅威インテリジェンスを knowledge graph を使って分析します｡これまで､GuardDuty の findings を手動で調査するには時間がかかり､アラート疲れ (alert fatigue) の原因となっていました｡AI-powered investigations により､数分で自動分析が完了します｡また､CLI コマンドを含む具体的な修復手順を提供してくれるため､対応のアクションが素早くなります｡ Amazon CloudWatch Logs がマネージド syslog 取り込みに対応 Amazon CloudWatch Logs が VPC エンドポイント経由での syslog 直接取り込みに対応しました｡ファイアウォール､ルーター､スイッチ､Linux サーバーからエージェントをインストールせずに syslog メッセージを CloudWatch Logs へ送信できます｡RFC 5424､RFC 3164､Cisco FTD/ASA の各フォーマットに対応し､facility､severity､hostname､appName などの構造化フィールドを自動的に抽出します｡PrivateLink に対応していて､Direct Connect や Site-to-Site VPN の Private 通信も可能となっています｡ 6/24(水) Amazon CloudWatch でダッシュボードのタグ機能をサポート Amazon CloudWatch がダッシュボードのタグ機能をサポートしました｡これにより､ダッシュボードをチーム､プロジェクト､環境などのカテゴリで整理し､タグベースでアクセス制御を実装できます｡PutDashboard API が Tags パラメータに対応したほか､TagResource､UntagResource､ListTagsForResource API がダッシュボード ARN をサポートし､1つのダッシュボードに最大50個のタグを設定できます｡CloudFormation と AWS Resource Explorer にも対応しており､追加コストなしで CloudWatch が利用可能な全リージョンで提供されます｡ Amazon Route 53 Global Resolver が AWS アカウント間での DNS View 共有をサポート Amazon Route 53 Global Resolver が､AWS Resource Access Manager (AWS RAM) を使用して DNS View を他の AWS アカウントと共有できるようになりました｡Route 53 Global Resolver は､リモート拠点やオンプレミス環境から AWS 上の Private Hosted Zone とパブリックドメインの両方を解決できる､インターネット到達可能な DNS リゾルバーです｡この機能により､consumer アカウントは自身の Route 53 Private Hosted Zone を共有された DNS View に関連付けることで､所有権を移譲せずに owner の Global Resolver を通じて全 AWS リージョンで名前解決できます｡DNS View 共有は追加料金なしで､Route 53 Global Resolver がサポートされている全リージョンで利用できます｡ AWS IoT Device SDK for Swift の一般提供開始 AWS IoT Device SDK for Swift が一般提供 (GA) を開始しました｡Swift 開発者は macOS 12+､iOS 16+､tvOS 16+､Linux 上で AWS IoT サービスを利用した IoT アプリケーションをネイティブに構築できるようになります｡SDK は MQTT 5 プロトコルをサポートし､AWS IoT Device Shadow､Jobs､Fleet Provisioning の統合クライアントを提供します｡iOS と tvOS では TLS 1.3 に対応しており､最新のセキュリティ標準でデータを保護します｡Swift Package Manager 経由でインストールできます｡ Amazon EC2､AMI ガバナンス強化のための AMI Watermarks 機能を発表 Amazon EC2 が AMI Watermarks 機能を発表しました｡この機能により､Private AMI にカスタム識別子を埋め込み､AMI の系譜追跡とガバナンスポリシーの実施が可能になります｡ウォーターマークは AMI のコピーや派生 AMI 作成時に自動的に引き継がれ､リージョン間コピーやアカウント共有でも保持されます｡Allowed AMIs 機能と組み合わせることで､承認されたウォーターマークを持つ AMI のみからインスタンスを起動するよう制限できます｡全 AWS リージョンで追加料金なしで利用可能です｡ 6/25(木) AWS Network Firewall が VisionHeight のマネージド脅威インテリジェンスルールをサポート AWS Network Firewall が VisionHeight 社の 2 つの新しいマネージドルールグループをサポートしました｡AWS Marketplace 経由で利用できる Zero-Day Threat Protection と Noisy Scanners and Tor Protection により､公開ブロックリストに掲載される数週間前に悪意ある IP インフラストラクチャを先制ブロックし､Tor 出口ノードや高頻度スキャンソースからの通信を遮断してファイアウォールログのノイズを削減します｡VisionHeight の Pulse テレメトリーに基づく独自の脅威インテリジェンスを活用でき､日次更新により最新の脅威情報を反映します｡ それでは､また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です。