本ブログは 2026 年 10 月 12 日に公開された AWS Blog “ GuardDuty Extended Threat Detection has added five new indicators to surface attack sequences ” を翻訳したものです。 Amazon GuardDuty 拡張脅威検出 は、弱い GuardDuty シグナルの組み合わせが信頼性のしきい値を超えると、それらを相関付けて、重要度が Critical の単一の攻撃シーケンスの検出結果にまとめます。2026 年 5 月 20 日から、攻撃シーケンスに 5 種類の新しいインジケーター ( MALICIOUS_PACKAGE 、 MISCONFIGURATION 、 REACHABILITY 、 SENSITIVE_DATA 、 VULNERABILITY ) が付与されるようになりました。詳細については、「 Document history for Amazon GuardDuty 」および「 Attack sequence finding details 」を参照してください。 これらのインジケーターの情報源は、 Amazon Inspector 、 Amazon Virtual Private Cloud (Amazon VPC) Reachability Analyzer 、 Amazon Macie 、そして AWS Security Hub を通じて提供されるポスチャデータです。これらのサービスを既に別の目的で利用しているお客様もいるでしょう。今回のアップデートにより、拡張脅威検出はこれらのサービスのシグナルを攻撃シーケンスの検出結果に取り込むようになりました。この記事は、前提条件となるサービスを既に利用しているチーム向けの運用ガイドです。新しいインジケーターが検出結果にどのように表示されるか、リリース後のデータから何がわかるか、そしてインシデント対応ワークフローにどう組み込むかについて説明します。これらのインジケーターにより、拡張脅威検出はアカウント内で最も優先すべきシグナルを判断しやすくなります。その結果、 Amazon Elastic Compute Cloud (Amazon EC2) 、 Amazon Elastic Container Service (Amazon ECS) 、 Amazon Elastic Kubernetes Service (Amazon EKS) のランタイムアクティビティをモニタリングするアクティブディフェンス戦略の一環として、ワークロード領域でより信頼度の高い検出結果が得られます。 新しいインジケーターの概要 GuardDuty におけるシグナルとは、GuardDuty が不審なアクティビティを探す際に評価するあらゆるイベントを指します。弱いシグナルとは、それ単体では脅威を明確に示さないシグナルのことで、5 つの新しいインジケーターはこれに該当します。例えば、ホスト上で Common Vulnerabilities and Exposures (CVE) が 1 件検出されたとしても、それは脆弱性が存在することを示すだけで、攻撃者がその脆弱性を悪用していることを示すわけではありません。次の表に示すように、これらの検出結果は、GuardDuty が既に追跡している不審なアクティビティのシグナルと相関付けられることで、初めて価値を発揮します。 インジケーター ソース 示される内容 VULNERABILITY Amazon Inspector Common Vulnerability Scoring System (CVSS) の重要度と Exploit Prediction Scoring System (EPSS) の悪用可能性スコアを含む CVE のリスト。 MALICIOUS_PACKAGE Amazon Inspector Amazon Inspector の MAL-* パッケージインジケーター。Amazon Inspector による脆弱性のスコアリング方法の詳細については、「 Amazon Inspector Security Research 」を参照してください。 REACHABILITY Amazon VPC Reachability Analyzer ホストまたはクラスターがインターネットから到達可能かどうか MISCONFIGURATION AWS Security Hub のコントロール (ポスチャ管理) リソースの設定が、AWS または 業界のベストプラクティス に沿っていないこと。例えば、IMDSv1 が有効なままになっている、管理者ポリシーの権限が過剰である、パブリックにアクセス可能な Amazon Simple Storage Service (Amazon S3) バケットがある、などです。 SENSITIVE_DATA Amazon Macie リソース内で機密データと思われる情報が検出されたこと。 これら 5 つの値は、GuardDuty の AWS マネジメントコンソールで攻撃シーケンスの検出結果を開いたときの [インジケーター] タブと、 GetFindings の JSON ファイルに表示されます。 図 1: 攻撃シーケンスの検出結果の [インジケーター] セクション VULNERABILITY インジケーターには EPSS が含まれるため、ここで EPSS について補足しておきます。「 FIRST EPSS overview 」によると、EPSS スコアは、公開済みの CVE が今後 30 日以内に実際の環境で悪用される確率を 0～1 の範囲で表したものです。EPSS は CVSS を置き換えるものではありません。CVSS が脆弱性本来の重要度を表すのに対し、EPSS は近いうちに悪用される可能性の高さを表すため、インシデント対応ではより役立つ数値となります。 前提条件 インジケーターにデータを反映させるには、次の AWS サービスを有効にしておく必要があります。 Amazon Inspector (Amazon EC2 および Amazon EKS で有効化): VULNERABILITY と MALICIOUS_PACKAGE に対応します。 AWS Security Hub : AWS Foundational Security Best Practices に基づいて MISCONFIGURATION を提供します。 Amazon VPC Reachability Analyzer (本番環境の VPC で有効化): REACHABILITY に対応します。 GuardDuty Runtime Monitoring (Amazon EC2、Amazon ECS、Amazon EKS で有効化): 生成されるすべてのシグナルが、相関付けの起点 (アンカー) になり得ます。 Amazon Macie : SENSITIVE_DATA を提供します。 弱いランタイムシグナルの強化 プロセスの呼び出し、ポッドでの exec、システムコールのパターンなどのランタイムシグナルは、ノイズが多くなることがあります。既知の攻撃ツールのパスに一致しないランタイムシグナルは単体では重要な意味を持たず、リソース状態のコンテキストがなければ、通常は重要度が Critical の攻撃シーケンスとなるしきい値に達しません。 新しいインジケーターは、この欠けていたコンテキストを補います。弱いランタイムシグナルが観測されたホストに、優先度の高いパッチ未適用の CVE、既知の悪意のあるパッケージ、IMDS の設定ミス、インターネットからの到達可能性が併存する場合、拡張脅威検出はそれらをまとめて、高い信頼度で重要度が CRITICAL の単一の攻撃シーケンスに昇格させます。個々の GuardDuty ランタイム検出結果については、ノイズの多さが大きな課題であるというフィードバックをお客様から一貫していただいてきました。このリソース状態のコンテキストを加えることで、弱いシグナルが対応可能なアラートへと変わります。 実際に、ランタイムプロセス領域では新規の攻撃シーケンスの検出結果が大幅に増加し、優先順位付けされたランタイムプロセスの攻撃シーケンスのおよそ 4 件に 1 件を占めるまでになりました。一方、ネットワークベースの侵害の痕跡 (IOC) 領域ではほとんど変化はありませんでした。リリース後 1 週間で、このパターンは多くのお客様のアカウントで確認されています。従来は弱く相互に関連のない複数の検出結果としてばらばらに表示されていた攻撃シーケンスが、重要度が CRITICAL の単一の検出結果として表示されるようになったのです。 例: Amazon EKS で新規に検出された攻撃シーケンス 追加のインジケーターによって拡張脅威検出がどのように改善されたかを説明したところで、これらのインジケーターがどのような価値をもたらすかを具体的な例で見ていきましょう。ここでは、Amazon EKS クラスターで実際に観測されたシナリオを分析します。このアクティビティは 8 日間にわたって発生し、11 件の異なる GuardDuty の検出結果が生成されました。 図 2: 拡張脅威検出がシグナルを相関付ける前の EKS クラスターのアクティビティの概要 図 2 に示すように、GuardDuty が 8 日間にアクティビティ領域で観測したのは、55 件の EKS_AUDIT_LOGS シグナル (ポッドでの exec、ロールの引き受け、 AssumeRoleWithWebIdentity の呼び出し) と、18 件の検出結果レベルのシグナルでした。これらはすべて、198.51.100.69 という単一の外部 IP アドレスから発生していました。この IP アドレスから、同じ EKS クラスターに対して 4 つの異なる AWS Identity and Access Management (IAM) アイデンティティによる認証が行われていました。ワーカーノード上のランタイムアクティビティは、既知の攻撃ツールのパスに一致するプロセスがなく、実行プロファイルのフラグも立たなかったため、ありふれたものに見えました。リリース前の相関ロジックでは、このシーケンスを検出するには EKS_MALICIOUS_PROCESS ルールが発動する必要がありました。このルールの発動には、悪意のある exec パスか、異常で疑わしいツールのプロファイルのいずれかが必要です。今回のアクティビティにはどちらも該当しなかったため、相関付けられた攻撃シーケンスの検出結果は生成されませんでした。 新しい GuardDuty 拡張脅威検出のインジケーターによって、この EKS の例に追加された情報は次のとおりです。 MALICIOUS_PACKAGE (クラスター上): Amazon Inspector の識別子 MAL-2022-4933 が検出されています。 VULNERABILITY (Amazon Inspector の全出力、クラスター上): 合計 42 件の CVE があり、そのうち 33 件が CVSS で CRITICAL と評価されています。 クラスター上: CVE-2022-1471 (SnakeYAML のデシリアライゼーション、EPSS 0.94)、CVE-2024-4577 (PHP-CGI の引数インジェクション、EPSS 0.97)、CVE-2024-34351 (Next.js の SSRF)、CVE-2025-29927 (Next.js の認証バイパス)、CVE-2023-44487 (HTTP/2 Rapid Reset)、CVE-2022-37434 (zlib のヒープオーバーフロー、EPSS 0.92) を含む 12 件の CVE があります。 5 つのワーカーノード全体: 合計 379 件の CVE があり、そのうち 68 件が Amazon Inspector によって CRITICAL と判定されています。 REACHABILITY : クラスターの API エンドポイントがインターネットから到達可能で、5 つのワーカーノードのうち 3 つもインターネットから到達可能です。 MISCONFIGURATION (EC2 IMDS): 5 つのワーカーノードすべてで、引き続き IMDSv1 にアクセスできる状態になっています。 これらの追加インジケーターを考慮すると、この一連のアクティビティは単一の AttackSequence:EKS/CompromisedCluster の検出結果として表示されます。重要度は CRITICAL で、データが反映された 4 つのインジケーターすべてが [インジケーター] タブに表示されます。また、 MITRE ATT&CK® の Initial Access (External Remote Services)、Discovery、Persistence へのマッピングも示されます。 図 3: 攻撃シーケンス内の新しい脆弱性インジケーター この検出結果には、ワーカーノードレベルで 100 件を超える Amazon EC2 の CVE が記載されています。CVSS が CRITICAL のものが 1 件、 HIGH のものも多数ありますが、EPSS スコアが低いため、ほとんどは脆弱性の優先度が LOW です。GuardDuty が優先度の高いものを強調表示するため、100 件を超える検出結果を精査してどれから対処すべきかを判断する必要はなく、最も効果の高い箇所に対応作業を集中できます。 例: 暗号資産マイニングと脆弱なホスト 2 つ目の例では、EC2 インスタンスグループのケースを取り上げます。このケースでは、GuardDuty は暗号資産マイニングを示す有力なネットワークベースの検出結果を既に得ていましたが、新しいインジケーターが修復に役立つ追加のコンテキストを提供したことで、インシデント対応を迅速化できました。 図 4: EC2 インスタンスに対する暗号資産マイニング攻撃 複数の EC2 インスタンスが既知の暗号資産マイニングの宛先と通信しており、この宛先は脅威インテリジェンスによって mining/misc としてフラグ付けされていました。ネットワーク IOC の証拠は、それ単体でも十分に強力なものでした。 新しいインジケーターによって追加された観測内容 : VULNERABILITY により、関与した 3 つのインスタンスのうち 2 つで、EPSS が約 0.9 の CVE-2007-4559 (Python tarfile) が示されました。 結果 : AttackSequence:EC2/CompromisedInstanceGroup の検出結果を基に、「 宛先 IP のブロック 」にとどまらない対応が可能になりました。暗号資産マイニングツールが侵入に悪用したと考えられる脆弱性と、それを修復するパッチが示されるため、アウトバウンド接続を遮断するだけでなく、根本的な侵入経路に対処できます。 GuardDuty は EC2 インスタンスグループで暗号資産マイニングが行われている強力な証拠を得ていたため、この攻撃シーケンス自体は脆弱性のコンテキストがなくても生成されていたはずです。ただし、コンテキストが増えることで、トリアージを迅速に行えます。 リリース後 1 週間のサンプルで観測された侵害の痕跡 次の CVE (EPSS スコアは観測当時の値) は、リリース後の最初の 1 週間に新しい拡張脅威検出のインジケーターが付与されたお客様のアカウントのホストで、各インジケーターの検出結果が生成された時点で観測されたものです。EPSS スコアは特定時点の値であるため、今後の検出結果に表示される CVE の優先度は、ここに示す値ではなく、その時点の EPSS に基づきます。 CVE-2024-4577 – Windows 上の PHP-CGI の引数インジェクション。EPSS 0.97 以上。 CVE-2022-1471 – SnakeYAML のデシリアライゼーション。EPSS 0.94。CVSS は Critical。 CVE-2022-37434 – zlib のヒープバッファオーバーフロー。EPSS 0.92。 CVE-2007-4559 – Python tarfile のパストラバーサル。2026 年時点でも EPSS は 0.9 以上。 CVE-2025-29927 – Next.js の認証バイパス。Node ベースのウェブ層で頻繁に検出。 CVE-2024-34351 – Next.js の SSRF。 CVE-2023-44487 – HTTP/2 Rapid Reset。 ランタイムモニタリングでは、侵害されたホストから回収されたマルウェアやツールのアーティファクトに関連する弱いシグナルが検出されました。 HackTool ファミリーの Linux/frp : Fast Reverse Proxy の亜種で、コマンドアンドコントロールトンネルとして使用されていました。Amazon EKS ワーカーノード上では、多くの場合 kuboard-agent や kuboard-agent-server というバイナリに偽装されていました。また、 /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/.../usr/bin/ 配下で、コンテナスナップショットのパスとの一致も観測されました。frp バイナリはコンテナイメージ内とノード上の両方に存在するため、パッチが適用されていない AMI からノードを再構築するだけでは修復として不十分です。 Burp Collaborator のアウトオブバンドのコールバックホスト名が *[.]oastify[.]com 配下で見つかり、パターン <35-char base32>[.]oastify[.]com に一致していました。これらは同じ EKS シーケンス上で frp と同時に観測されており、共有インフラストラクチャ上で 2 つ目のツールまたは別のアクターが活動していた可能性が高いと考えられます。 Amazon Inspector の悪意のあるパッケージインジケーター MAL-2022-4933 が、Amazon EC2 と Amazon EKS の両方のコンテキストで検出されました。 上記のツール関連のシグナルと相関していたアイデンティティとアクセスのパターンは次のとおりです。 単一の外部送信元 IP から、短期間のうちに Amazon EKS、Amazon ECS、Amazon EC2 の別々の領域にまたがって、人間が使用する複数の異なる IAM アイデンティティによる認証が行われていました。これは、新規に検出されるようになった Amazon EKS プロセス関連のクラスで最も多く見られたアイデンティティのシグネチャです。 これらのインジケーターを活用した攻撃シーケンスへの対応 新しいインジケーターによって、既に発生した攻撃シーケンスに対するインシデント対応のランブックが変わるわけではありません。新しいインジケーターが意味を持つのは新規の検出結果であり、それらの検出結果は、ランタイムモニタリング関連のシグナルが強化された領域に集中しています。新規の検出結果には、次のように対応してください。 シーケンスに緊急に対応してください 。 MALICIOUS_PACKAGE と優先度の高い VULNERABILITY が示されている場合、そのホストは侵害されるリスクにさらされてきただけでなく、現在もさらされています。露出しているリソースを封じ込め、脆弱性を修復してください。また、攻撃者にさらされた可能性があるすべての IAM 認証情報、 インスタンスプロファイル 、 IAM Roles for Service Accounts (IRSA) にバインドされたロール をローテーションしてください。 EPSS で重み付けした優先度に基づいてパッチを適用してください 。CVSS の値だけで判断しないでください。検出結果に含まれる優先度の高い VULNERABILITY リストは、既に EPSS の高い CVE に絞り込まれています。 パブリックなリソースを隔離してください 。 REACHABILITY インジケーターで示されたリソースが対象です。悪用可能な脆弱性があり、インターネットから到達可能なホストは、修復のために隔離する必要があります。 さらに詳しい対応方法については、「 Remediating detected GuardDuty security findings 」の修復手順と、GuardDuty の検出結果とアカウントを AI で分析するセキュリティ分析機能である GuardDuty Investigation を参照してください。 まとめ GuardDuty 拡張脅威検出は、セキュリティチームが特に支援を必要とすることが多いランタイムワークロード領域 (Amazon EC2、Amazon ECS、Amazon EKS) で、信頼度の高い攻撃シーケンスの検出結果をより多く提供できます。これは、GuardDuty のアクティビティシグナルと、他の AWS サービスから得られるリソース状態のコンテキストを組み合わせることで実現しています。個々の GuardDuty ランタイム検出結果については、ノイズの多さが大きな課題であるというフィードバックをお客様から一貫していただいてきました。拡張脅威検出は、こうした弱いシグナルを脆弱性、パッケージリスク、到達可能性、設定ミス、機密データの各インジケーターと相関付けることで、ノイズを、重要度が CRITICAL の対応可能な検出結果に変えます。AWS Security Hub、Amazon Inspector、Amazon VPC Reachability Analyzer、Macie、GuardDuty Runtime Monitoring を既に有効にしている場合、新しいインジケーターは攻撃シーケンスの検出結果に自動的に表示されます。これらのサービスをまだ使用していない場合は、新しい GuardDuty 拡張脅威検出のインジケーターと、各サービス自体が提供する価値を活用するために、ぜひ有効化をご検討ください。 この記事に関する質問がある場合は、 AWS re:Post で新しいスレッドを開始するか、 AWS サポートにお問い合わせください 。 Aman Khare Aman は Amazon GuardDuty のシニアソフトウェア開発者です。 拡張脅威検出 の開発に携わり、AWS インフラストラクチャで検出された悪意のある攻撃チェーンをお客様が正確に特定できるよう支援しています。以前は Amazon OpenSearch のパフォーマンスとレジリエンシーに関する取り組みを主導し、クラスターマネージャーのメモリ使用量の 10 分の 1 への削減や、1,000 ノード規模のクラスターの実現などを達成しました。仕事以外では、旅行、アドベンチャーアクティビティ、読書、ボードゲームを楽しんでいます。 Kyle Koeller Kyle は Amazon GuardDuty チームのセキュリティエンジニアで、脅威検出を専門としています。クラウドの脅威検出とオフェンシブセキュリティに情熱を注いでおり、CompTIA Security+、PenTest+、CompTIA Network Vulnerability Assessment Professional、SecurityX の資格を保有しています。仕事以外では、ジムで過ごしたり、ニューヨーク市を散策したりすることを楽しんでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

みなさん、こんにちは。ソリューションアーキテクトの大久保です。今週から週刊AWS を皆様にお届けする新たなメンバーとして活動させていただきます。どうぞよろしくお願いします！ では今週も 週刊AWS をお届けします。 11 月 5 日 (木) に、オンラインのワークショップ「 開発ライフサイクルで学ぶ Amazon ECS コンテナセキュリティ実践ワークショップ 」を開催します。コンテナのビルドからデプロイ、ランタイムまで、各段階でセキュリティをどう担保するかを座学で整理したうえで、AWS Fargate 上の Amazon ECS を題材に、Amazon Inspector による脆弱性の検知や Amazon GuardDuty Runtime Monitoring による不審な通信の検知をハンズオンで体験できます。今回ご紹介するアップデートにも GuardDuty や AWS Security Hub のものがありますので、コンテナのセキュリティ対策を見直したい方はぜひご参加ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年10月5日週の主要なアップデート 10/5(月) 音声エージェント向けに推論能力を改善した Amazon Nova 2.5 Sonic を発表 AWS は、リアルタイム音声エージェント向け speech-to-speech モデルの最新版である Amazon Nova 2.5 Sonic の一般提供を発表しました。Nova 2 Sonic と比較して推論、指示追従、ツール呼び出し精度が改善され、レイテンシも低減しています。音声エージェントが会話の文脈を保持したまま、注文照会や返品処理といった複数ステップのタスクをツール連携で完了できます。同時に GA となった Strands Bidi Agents と組み合わせることで、少ないコード量で本番向け音声エージェントを構築できます。バージニア北部、オレゴン、ストックホルム、東京の 4 リージョンで利用でき、料金は Nova 2 Sonic と同額です。 AWS Client VPN がデバイスポスチャ評価をサポート AWS Client VPN が、接続元デバイスのセキュリティ状態を検証するデバイスポスチャ評価に対応しました。CrowdStrike、Jamf、JumpCloud をデバイストラストプロバイダーとして設定し、コンプライアンススコア、ディスク暗号化状態、リスクレベルなどのシグナルを Cedar ポリシーで評価して、要件を満たすデバイスだけに接続を許可できます。評価は接続時だけでなくセッション中も 5 分ごとに行われ、非準拠になったデバイスは自動的に切断されます。接続を切断せずログのみ記録するシャドウモード (モニタリングモード) も用意されており、Client VPN が利用できるすべてのリージョンで追加料金なしで利用できます。 Amazon EC2、Amazon Machine Image の共有タグを導入 Amazon EC2 は AMI のタグを共有先アカウントから参照できるようにする AMI タグ共有機能を提供開始しました。タグキーに ec2:SharedTag/ プレフィックスを付けるだけで、個別アカウント共有、AWS Organizations の組織・OU 共有、パブリック共有のいずれでも、共有先の全アカウントがそのタグを参照できます。従来必要だった SNS + Lambda などによるタグ複製ワークフローが不要になります。共有タグは共有先では読み取り専用で、オーナー側の 1 リソースあたり 50 タグのクォータのみを消費します。全リージョンで追加費用なしで利用できます。 AWS Continuum for Penetration Testing が CI/CD パイプラインに統合された継続的ペネトレーションテストに対応 AWS Continuum for Penetration Testing (旧 AWS Security Agent) が、CI/CD パイプラインへの直接統合をパブリックプレビューとして提供開始しました。GitHub Actions、GitLab CI/CD、Bitbucket Pipelines、Azure DevOps Pipelines の 4 つのプラットフォームに対応し、デプロイ後のゲートとしてペネトレーションテストを実行できます。テストは前回クリアしたコミットからの差分に自動的にスコープされ、攻撃対象領域に影響しない変更は遅延なくパイプラインを通過します。設定済みの重大度しきい値 (デフォルトは HIGH) 以上の検出事項があると本番への昇格をブロックし、修正後のプッシュで自動的に再テストが実行されます。 AWS IAM Identity Center が Identity Store のネットワークアクセス制御をサポート AWS IAM Identity Center のユーザー・グループを格納する Identity Store に対して、リクエスト元ネットワークに基づくアクセス制御を設定できるようになりました。Identity Store API には VPC エンドポイント経由の強制、送信元 VPC の限定、許可 IP レンジの指定ができ、SCIM API には許可 IP レンジの指定ができます。設定は UpdateIdentityStore API を AWS CLI または SDK から呼び出して行い、デフォルトでは無効です。IAM Identity Center が提供される全リージョンでご利用可能です。SCIM トークン漏洩時の被害範囲限定や、組織のデータ境界 (data perimeter) 戦略の強化に使えます。 Amazon Redshift が Apache Iceberg マテリアライズドビューの作成とリフレッシュに対応 Amazon Redshift が、結果を Apache Iceberg テーブルとして Amazon S3 または S3 Tables に保存するマテリアライズドビュー (MV) に対応しました。CREATE MATERIALIZED VIEW … USING ICEBERG という SQL で作成でき、結果は AWS Glue Data Catalog に登録されます。Amazon Athena、Apache Spark (Amazon EMR / AWS Glue)、Trino、Snowflake など Iceberg 互換エンジンから追加設定なしで読み取れます。リフレッシュは手動実行で、COUNT / SUM 集計と内部結合については変更分のみを再計算するインクリメンタルリフレッシュが動作します。Redshift Serverless と RG (Graviton) プロビジョンドインスタンスで利用でき、RA3 / DC2 では利用できません。 10/6(火) AWS Batch が Amazon CloudWatch へのジョブメトリクス発行に対応 AWS Batch がジョブのライフサイクルに関するメトリクスを Amazon CloudWatch の AWS/Batch 名前空間へ自動発行するようになりました。追加料金なしで、ジョブキューごとの状態遷移数 (送信、実行中、成功、失敗など) と、状態間の所要時間 (送信から実行可能まで、実行時間など) を確認できます。これまで EventBridge と Lambda を組み合わせて自前で構築する必要があったジョブ監視を、CloudWatch のダッシュボードとアラームだけで構成できます。AWS Batch が利用可能なすべてのリージョンで提供されます。 10/7(水) Claude Haiku 5.5 が AWS で利用可能に Claude 5.5 ファミリーで最速・最も効率的なモデルである Claude Haiku 5.5 の提供を開始しました。Anthropic によると、ほとんどのタスクで Claude Haiku 4.5 より約 75% 低コストで、トークン単価は入力 $0.10 / 100 万トークン、出力 $0.50 / 100 万トークンからです。Haiku として初めて effort パラメータ (low / medium / high / xhigh / max) に対応し、タスクごとにコストと性能のバランスを調整できます。コンテキストウィンドウは 100 万トークン、最大出力は 128K トークンです。アクセス経路は Amazon Bedrock と Claude Platform on AWS の 2 つで、データレジデンシーや AWS 管理機能を重視する場合は Bedrock、Anthropic ネイティブの最新機能を使いたい場合は Claude Platform on AWS を選択します。 AWS Config が 77 の新しいリソースタイプをサポート AWS Config が新たに 77 種類のリソースタイプの記録に対応しました。対象には Amazon Q Business (6 種類)、Amazon S3 Files (4 種類)、AWS PCS (3 種類)、各種メディアサービス、GuardDuty や Inspector などのセキュリティサービスが含まれます。全リソースタイプの記録を有効化している環境では、設定変更なしで新しいリソースタイプの追跡が自動的に始まります。追加されたリソースタイプは Config rules と Config アグリゲーターでも利用できます。記録される Configuration Item (CI) が増えるため、コストへの影響を事前に確認することを推奨します。 10/8(木) Amazon GuardDuty RDS Protection が Aurora および RDS データベースでのデータ流出とデータ破壊を検出可能に Amazon GuardDuty の RDS Protection が拡張され、従来のログイン異常検知に加えて、Aurora PostgreSQL と Amazon RDS for PostgreSQL を対象としたデータ流出 (Exfiltration) およびデータ破壊 (Impact) の検出に対応しました。RDS Protection for data activity として提供され、ML による異常検知と脅威インテリジェンスを組み合わせてデータベースのクエリパターンを継続的に監視します。エージェントや追加インフラ、データベース側の設定変更は不要です。既存の RDS Protection (ログインアクティビティ) のアドオンとして有効化でき、アカウント・リージョンごとに 30 日間の無料トライアルが利用できます。 Amazon RDS for Oracle がマイナーバージョンアップグレードのプリチェックとパッチ適用ダウンタイムを短縮するのに役立つ新しい RDS イベントをサポート Amazon RDS for Oracle で、マイナーバージョンアップグレードの事前チェック (プリチェック) をユーザー自身が任意のタイミングで実行できるようになりました。新しいプロシージャ rdsadmin.rdsadmin_precheck_tasks.precheck_minor_upgrade を使うと、ストレージ不足や無効なトリガーなど、アップグレードを中断させる問題をメンテナンスウィンドウ前に検出して修正できます。あわせて、パッチ適用中に DB インスタンスが接続受付を再開した時点で発行される新イベント RDS-EVENT-0596 が追加されました。残りのメンテナンスタスクはオンラインで完了するため、このイベントを契機にアプリケーションを復帰させることで、パッチ適用時のアプリケーションダウンタイムを短縮できます。本機能は RDS for Oracle が利用可能なすべての AWS 商用リージョンと AWS GovCloud (US) リージョンで追加費用なしに利用できます。 AWS Cost Explorer、Budgets、Dashboards が Amazon Bedrock の product attributes に対応 AWS Cost Explorer、AWS Budgets、AWS Cost Management Dashboards で、Amazon Bedrock のコストを product attributes (製品属性) という新しいディメンションで分析できるようになりました。属性はモデル、モデルプロバイダー、推論タイプ、機能の 4 種類です。Cost Explorer と Dashboards ではこれらの属性によるグループ化とフィルタリング、Budgets では予算のフィルタリングに利用できます。タグの事前設定なしで「どのモデルがいくら使っているか」を標準の請求ツール上で確認できるため、ファイナンスチームやプラットフォームチームの Bedrock コスト管理に役立ちます。追加料金なしで利用できます。 10/9(金) Amazon Quickで、ブランドイメージに沿ったプレゼンテーションやドキュメントを作成するためのブランドテンプレートをサポート Amazon Quick で、組織の承認済みブランドテンプレートをアップロードし、ビジュアルアイデンティティに沿ったプレゼンテーションやドキュメントを生成できるようになりました。ブランドマネージャーが PowerPoint または Word のテンプレートを一度登録すると、Quick が色、フォント、ロゴ、レイアウト、ブランドルールを抽出し、組織全体に公開できます。利用者はチャットのたびにテンプレートファイルを探して添付する必要がなくなります。本機能は Amazon Quick デスクトップアプリで一般提供を開始しており、Enterprise エディションでのみ利用できます。 AWS Lambda がセルフマネージド Apache Kafka イベントソースの OAuth 認証をサポート AWS Lambda のセルフマネージド Apache Kafka イベントソースマッピング (ESM) が、OAuth 2.0 (SASL/OAUTHBEARER) 認証に対応しました。対象は顧客が自前で運用する Kafka クラスターに加え、Confluent Cloud、Aiven、Redpanda などのマネージドサービスです。Amazon Cognito や Okta などのエンタープライズ IdP で Lambda の Kafka コンシューマーを認証できるため、Kafka クラスターと Lambda で同一の ID ガバナンスを適用できます。従来は SASL/PLAIN、SASL/SCRAM、mTLS のみの対応だったため、OAuth 必須の規制産業では ESM を利用できませんでした。セルフマネージド Kafka ESM が利用可能なすべての AWS 商用リージョンで利用できます。 AWS Security Hub が findings の S3 への CSV / JSON 形式エクスポートに対応 AWS Security Hub が、findings を Amazon S3 バケットへ CSV または JSON (OCSF) 形式でエクスポートする機能を発表しました。コンソールの各 findings ページ (All Findings、Threats、Exposure、Vulnerabilities、Posture Management、Sensitive Data) から、適用中のフィルタを引き継いだままオンデマンドでエクスポートを開始できます。コンプライアンスレポートや監査証跡の作成のために、EventBridge などを使った抽出パイプラインを自前で構築・保守する必要がなくなります。本機能は Security Hub が利用可能なすべてのリージョンで提供されています。 それでは、また来週お会いしましょう！ 著者について 大久保 裕太(Yuta Okubo) 流通小売や飲食業界のお客様を中心にクラウド活用の技術支援を行なっているソリューションアーキテクトで、IoT 領域を得意としています。好きな AWS サービスは AWS IoT Core です。最近は、デスクワークによる姿勢の崩れを筋トレで解消しようとしています

はじめに JADOGは、データセンター事業者をはじめ、ユーザー、メーカー、SIer、ネットワーク事業者など、多様な業界のプレーヤーが業界の枠を超えて集まり、建設的な情報共有と活発な議論を行うコミュニティーです。これにより […]