Category
Amazon GuardDuty 本番運用ガイド（脅威検知／Extended Threat Detection・攻撃シーケンス／EventBridge自動対応(SOAR)／マルチアカウント統制／Runtime Monitoring／EKS Protection／S3マルウェア対策／RDS・Lambda Protection／Detective調査／Security Lake集約／誤検知チューニング／コスト最適化／技術選定）
GuardDutyは『防御』ではなく『検知』のサービスです——攻撃を止めるのではなく、いま危ないことが起きていると知らせる。だから価値は『検知精度 × 検知後の対応速度(MTTR)』で決まります。本クラスタは、GuardDutyを採用した後の『どう本番で運用するか』に集中します——有効化した瞬間に動くエージェントレスの基盤検知(CloudTrail管理イベント/VPC Flow Logs/DNSの独立した複製ストリーム)、資産に合わせて足すS3・EKS・Runtime・Malware・RDS・Lambdaの保護プラン、追加費用ゼロで弱いシグナルを24時間窓で相関し多段攻撃を必ずCriticalな攻撃シーケンスに束ねるExtended Threat Detection、EventBridgeで受けて『通知は広く・封じ込めは許可リストで狭く・破壊は人間承認』の冪等な自動対応へ変えるSOAR設計、委任管理者と自動有効化(ALL)・全リージョンで取りこぼさないマルチアカウント統制、vCPU課金が支配するRuntime Monitoringのエージェント運用、料金の分解とコスト最適化、そしてSecurity Hub/Detective/Inspector/Macieとの役割分担まで——可観測性・回復性・冪等性・最小権限・コスト効率を軸に体系化します。マルチアカウントのサーバーレス決済プラットフォームでIAM・可観測性・DRを横断実装し、本番二重課金0件を冪等性で担保した知見を根拠に、AWS公式ドキュメントに忠実な実コードで解説します。GuardDutyは多層防御の一層であり、WAF(入口の予防)・最小権限IAM・暗号化を代替しません。
13 articles in total
Foundational guide
Foundational guide (start here)
Designing AWS Threat Detection in Production with Amazon GuardDuty: Protection Plans, Extended Threat Detection, Org-Wide Bulk Enablement, and EventBridge Automated Response, in Real Code
An implementation guide to building AWS threat detection in production with Amazon GuardDuty. From agentless foundational detection (CloudTrail/VPC Flow Logs/DNS), choosing among the S3・EKS・Runtime・Malware protection plans, the zero-extra-cost Extended Threat Detection, org-wide bulk enablement, to EventBridge → idempotent automated response — explained with real Terraform/Python code. GuardDuty is a detection layer, not prevention — I design from that premise.
Related practical articles
- セキュリティAWSGuardDutyAmazon Detectiveインシデント対応
GuardDuty × Amazon Detective: The 'Next Step' After Detection—A Workflow to Investigate Root Cause and Blast Radius
GuardDuty raised a Critical—but can you answer 'what happened, and how far did it spread'? Amazon Detective builds a behavior graph from CloudTrail, VPC Flow Logs, GuardDuty findings, and EKS audit logs over up to a year, and visualizes root cause and blast radius. From pivoting off a finding, finding groups, Detective Investigation using IOCs, automated StartInvestigation via CLI/EventBridge, to aligning the organization's delegated administrators—we design the detect→investigate→respond investigation layer in real code based on the official documentation (June 2026).
29 min read - セキュリティAWSGuardDutyFinOpsコスト最適化
Amazon GuardDuty pricing and cost optimization (FinOps): decompose the billing model, cut waste, and predict the bill
Decompose Amazon GuardDuty's pricing per component and identify the dominant drivers (Runtime Monitoring vCPU-hours, CloudTrail management events, VPC Flow Logs). Explained with bash/Terraform: usage visualization with get-usage-statistics, bill prediction from the trial, selection of protection plans, and dispelling the misconception that suppression rules lower cost. Prices vary by region/revision — confirm them.
24 min read - セキュリティAWSGuardDutyEKSKubernetes
GuardDuty EKS Protection: Detecting Control-Plane Threats (Anonymous Access, RBAC Tampering, Privilege Escalation) with Kubernetes Audit Logs
A production-design guide to GuardDuty EKS Protection. We explain the mechanism of detecting control-plane threats — RBAC grants to system:anonymous, cluster-admin tampering, exec in kube-system, privileged-container launches — with EKS audit logs. Because GuardDuty ingests audit logs in an independent stream, enabling EKS control-plane logging (CloudWatch) is unneeded. We organize finding types by ThreatPurpose with MITRE ATT&CK mapping, and show per-ThreatPurpose response, Terraform (EKS_AUDIT_LOGS) enablement, RBAC hardening, and SOAR integration in code. We also clarify the difference from Runtime Monitoring (the data plane).
27 min read - セキュリティAWSGuardDutyEventBridgeインシデント対応
Turning GuardDuty Findings into Automated Incident Response (SOAR) with EventBridge: A Production-Design Overview in Terraform / Step Functions / Python
A production-design guide to turning GuardDuty findings into automated incident response (SOAR) via EventBridge → Step Functions. Numeric severity matching, notify broadly / contain narrowly with an allowlist / human approval for destructive actions, EC2/IAM/S3/EKS playbooks, plus idempotency, DLQ, and least privilege—all explained in real code.
27 min read - セキュリティAWSGuardDuty脅威検知アーキテクチャ設計
A thorough explanation of GuardDuty Extended Threat Detection and attack-sequence findings: reading and responding to weak-signal correlation, the 24-hour window, and Critical multi-stage attacks
A thorough explanation of GuardDuty Extended Threat Detection (ETD) and attack-sequence (AttackSequence) findings. From the weak-signal correlation model, the 24-hour rolling window, the five attack-sequence types of IAM/S3/EKS/ECS/EC2, why they're all Critical (9.0–10.0), the correlation range that widens by protection plan, verification with sample generation, to the trap where a Suppression Rule ignores the archived — read it as a line with a real example of credential compromise → privilege escalation → S3 exfiltration.
26 min read - セキュリティAWSGuardDutyS3マルウェア対策
Auto-Scanning Uploaded Files with GuardDuty Malware Protection for S3: Standalone Operation, Scan-Result Gating, and the Difference from S3 Protection in Real Code
A production design guide for auto-malware-scanning uploaded S3 objects with GuardDuty Malware Protection for S3. Explained with real Terraform / Python / bucket-policy code: the difference from the easily-confused 'S3 Protection (CloudTrail data-event monitoring),' the standalone operation mode used without GuardDuty itself (no detector ID = no finding generated), scan-result tags (GuardDutyMalwareScanStatus) and EventBridge events, and a secure upload pipeline that promotes only NO_THREATS_FOUND to a clean bucket and seals off reads with tag-based access control (TBAC).
26 min read - セキュリティAWSGuardDutyTerraformAWS Organizations
Governing GuardDuty Org-Wide with AWS Organizations: Delegated Administrator, Auto-Enable (ALL), All Regions, and a Terraform Multi-Region Implementation
An implementation guide for governing GuardDuty org-wide with AWS Organizations. In code: why you consolidate to a delegated administrator (a dedicated security account) rather than operating from the management account, migrating from the invitation method, why you set auto_enable_organization_members to ALL, org auto-enablement of protection plans, an all-Regions strategy that doesn't miss global service events, a Terraform multi-region implementation with provider alias / for_each, and the least-privilege boundaries between accounts.
27 min read - セキュリティAWSGuardDutyRDSLambda
GuardDuty RDS Protection and Lambda Protection: Detecting DB Login Anomalies and Serverless Network Threats Agentlessly, with Zero Infrastructure Change
An implementation guide for designing Amazon GuardDuty's RDS Protection and Lambda Protection for production. Directly monitor Aurora/RDS login anomalies (success, failure, brute force, malicious IPs, Tor), and detect crypto mining / C&C communication from the network activity of all Lambda functions (including non-VPC) — both agentless, zero infrastructure change, no code change. Explained per the official docs: supported engines, finding types, the up-to-two-week learning period, pricing and the 30-day free trial, Terraform enablement, and EventBridge automated response.
28 min read - セキュリティAWSGuardDutyEKSコンテナ
Running GuardDuty Runtime Monitoring in production on EKS / ECS-Fargate / EC2: security agent, coverage, cost, troubleshooting
A production-operation guide for GuardDuty Runtime Monitoring. It explains, with Terraform/bash, how the eBPF agent observes OS-level processes, files, and networking from the inside, the three distribution surfaces EKS/ECS-Fargate/EC2 and automatic/manual management, coverage (Healthy/Unhealthy) confirmation, the VPC Flow Logs double-charge exemption, and the discipline of vCPU billing.
24 min read - セキュリティAWSGuardDutySecurity LakeOCSF
Aggregating GuardDuty Findings into Amazon Security Lake: Production Design for Long-Term Retention, Cross-Analysis, and SIEM Integration with OCSF
GuardDuty findings are strong on 'now' but unsuited to compliance long-term retention, cross-queries of finding × CloudTrail × VPC Flow, and SIEM supply. Amazon Security Lake builds a managed data lake of OCSF + Apache Parquet on your own S3, enabling years-span retention, SQL analysis, and SIEM integration. Centered on the decisive accuracy crux — Security Lake has no direct GuardDuty source, and findings are OCSF-ified via 'AWS Security Hub CSPM findings (SH_FINDINGS)' — I run through native sources, rollup Regions, the 2 subscriber types (query/data access), real Athena SQL, and Terraform implementation, based on the official documentation (June 2026).
31 min read - セキュリティAWSGuardDuty運用設計Terraform
Operating GuardDuty to Suppress False Positives and Noise: The Correct Use of Suppression Rules, Trusted IP Lists, and Threat Lists
A tuning implementation guide to suppressing Amazon GuardDuty's noise and false positives at production quality. We use the 3 tools — Suppression Rules (auto-archiving known noise), trusted IP/entity lists (not emitting findings from known legitimate sources), and threat lists (emitting findings from known malicious sources) — by a symptom→correct-tool mapping. A suppressed finding doesn't reach Security Hub/S3/Detective/EventBridge, nor does it become correlation material for Extended Threat Detection — we explain, in real Terraform/CLI code, the trap where too-broad suppression makes a Critical attack sequence wholly invisible, and the reactive, minimal-scope, IaC-centric operational rules.
28 min read - セキュリティAWSGuardDutySecurity Hub技術選定
GuardDuty vs. Security Hub vs. Detective vs. Inspector vs. Macie: the role division and technology selection of AWS security services
GuardDuty (detect), Security Hub (aggregate and standard checks), Detective (investigate), Inspector (vulnerability), and Macie (data classification) are not competitors but complementary layers of defense-in-depth. Based on the official documentation (June 2026), this organizes each service's role, the data it handles, and its lifecycle position, and explains easily-confused differences, a technology-selection frame, and integration design with EventBridge/Security Hub.
21 min read