AWS 威胁检测与安全响应实战教程（2026）：GuardDuty + Inspector + Security Hub + Detective 全流程、真实单价与 30 天免费试用攻略

📅 2026-10-02 · ChengziCloud - 一站式云端服务

Meta Description: 2026 最新 AWS 原生安全实战：GuardDuty 威胁检测、Inspector 漏洞扫描、Security Hub 统一态势、Detective 调查、Shield 抗 DDoS 五件套，含真实单价表、CLI 全流程、30 天免费试用避坑与自动化响应配置。

> 关键词：AWS GuardDuty、Amazon Inspector、AWS Security Hub、Amazon Detective、AWS Shield、威胁检测、漏洞扫描、云安全态势、30 天免费试用、AWS 实战教程

前言：先分清「检测、漏洞、态势、调查、抗 DDoS」这五件事

很多人在 AWS 上做完 IAM、WAF、KMS 之后，会觉得「安全已经做完了」。但真正出过事的人会知道：前面那些都是"把门锁好"，今天要讲的是"有人撬门时谁会响、响了之后谁去查"。

AWS 把这件事拆成了五个各管一段的服务，决策口诀如下：

- 想知道"有没有人正在撬门" → GuardDuty（威胁检测，持续分析云审计日志、网络流日志、DNS 日志） - 想知道"我这台机器上有多少个已知漏洞" → Inspector（漏洞管理，扫 EC2 / ECR 镜像 / Lambda / 代码） - 想把上面两件事收进一块仪表盘、并自动处置 → Security Hub（统一态势与自动化响应） - 出事之后想知道"他什么时候进来的、都干了什么" → Detective（调查与行为图谱） - 想把 DDoS 打成"账单不心疼" → Shield（Standard 免费 / Advanced 付费）

一句话记忆：GuardDuty 负责"响"，Inspector 负责"查漏洞"，Security Hub 负责"汇总和动手"，Detective 负责"回头看"，Shield 负责"扛住流量"。

本文把这五个服务从能力边界 → CLI 实操 → 真实单价 → 免费试用 → 自动化响应 → 避坑一次性讲透。所有单价均为 us-east-1（美东弗吉尼亚北部）2026 年 10 月采集的官方口径，并在文中标注是来自定价页算例还是价格清单接口。

先划边界：它和站内已有的安全文章到底有什么区别

AWS 的安全服务极多，读者最容易问的一句是「我不是已经配过 XX 了吗，为什么还要开这个？」下表把站内已有的几篇边界一次划清：

| 站内已有文章 | 它管的是哪一段 | 本文这五个服务管的是哪一段 | |---|---|---| | AWS IAM 权限实战 | 身份与授权：谁能调用什么 API | 不关心权限设计，只关心"有没有人被异常调用" | | AWS KMS 密钥管理实战 | 密钥与静态加密：数据怎么加密、密钥怎么轮换 | 不碰加密，只盯着"加密的资源有没有被异常访问" | | AWS WAF 防火墙实战 | 应用层拦截：SQL 注入、XSS、限速、地域封禁 | WAF 是"拦"，本文是"发现拦不住的行为之后再告警" | | AWS Macie 敏感数据发现 | 数据面：S3 里有没有隐私数据、有没有被公开 | Macie 看"数据是什么"，GuardDuty 看"谁在动数据" | | AWS Config 配置合规审计 | 配置面：资源被改成了什么样、合不合规 | Config 看"状态对不对"，GuardDuty 看"行为对不对" | | AWS Systems Manager（SSM） | 运维通道：免跳板机登录、批量执行、打补丁 | 本文的自动响应最终会调用 SSM Automation 去修 |

关键区别一句话：站内已有文章回答「我的云配得安不安全」，本文回答「有人正在攻击我时，我从哪里知道、多久知道、知道之后怎么办」。

一、五个服务的能力边界：数据源、输出、时点

先把最容易混的一点定死：这五个服务的数据源和输出完全不同，所以它们不是"选一个就行"，而是"按阶段补齐"。

| 服务 | 视角 / 数据源 | 回答的问题 | 时点 | 主要输出 | |---|---|---|---|---| | GuardDuty | 行为面：CloudTrail 管理事件、VPC Flow Logs、DNS 查询日志、EKS 审计日志、运行时活动 | 有没有人正在撬门？ | 事中检测 | Finding（发现项），保留 90 天 | | Inspector | 工作负载面：EC2 实例、ECR 镜像、Lambda 函数、代码仓库 | 这台机器上有多少已知漏洞？ | 事前 + 持续 | 漏洞发现，按 CVSS 排序 | | Security Hub | 汇总面：聚合以上两者的发现 + Config/Inspector 的检查结果 | 我一共欠了多少安全债？先修哪个？ | 全阶段汇总 | 统一仪表盘 + 自动化规则 | | Detective | 调查面：CloudTrail、VPC Flow Logs、EKS 审计日志、各服务 findings | 这个人是什么时候进来的、做了什么？ | 事后调查 | 行为图谱 + 调查时间线 | | Shield | 流量面：L3/L4（Standard）、L3–L7（Advanced） | 被打流量时业务还活着吗、账单会不会爆？ | 事中防护 | DDoS 检测与缓冲保护 |

推荐的开启顺序（这是全文最省钱的一条结论）：

1. 先开 Security Hub Essentials —— 它是一个"地基"，按资源统一计费，并且官方明说它的单价里已经包含了 Inspector 的标准扫描能力与 Config 记录器； 2. 再按需加 Threat Analytics 附加包（由 GuardDuty 的检测引擎驱动），而不是单独开一套 GuardDuty； 3. 真正需要独立调 GuardDuty / Inspector 的 API 做二次开发时，再分别启用； 4. Detective 与 Shield Advanced 属于"出事概率高 / 挨打概率高"才上，不要一开始就买。

> ⚠️ 顺序反了会怎样？先按老思路"GuardDuty + Inspector + Security Hub 三个都独立开"，很可能为同一批资源付两遍钱。原因在第五章「Security Hub」里展开。

二、GuardDuty 实战：从 0 到第一条 Finding

2.1 最重要的一点：你不需要自己开 CloudTrail、VPC Flow Logs、DNS 日志

很多人以为开 GuardDuty 之前要先把 CloudTrail、VPC Flow Logs、Route 53 Resolver 查询日志全配好，再建 S3 桶、再写桶策略。不需要。 官方 FAQ 原文说得很直白：

> GuardDuty pulls independent data streams directly from CloudTrail, VPC Flow Logs, DNS query logs, and Amazon EKS. You don't have to manage Amazon S3 bucket policies or modify the way you collect and store logs.

也就是说 GuardDuty 通过服务关联角色（service-linked role）自己去拉三类基础数据流，你既不用建桶、也不用担心桶策略写错。这也带来一个副作用值得知道：权限不会因为你后来的 IAM 或 S3 策略改动而失效，因为它是独立的服务通道。

三个基础数据源分别是：

1. CloudTrail 管理事件（谁调用了什么控制面 API） 2. Amazon VPC Flow Logs（实例之间的网络流量元数据） 3. DNS 查询日志（域名解析行为，用于识别 DGA 域名、DNS 外传数据）

在这三类之外，GuardDuty 还有一整套保护计划（Protection Plans），需要按需开启：

| 保护计划 | 监控对象 | 典型检测场景 | 备注 | |---|---|---|---| | S3 Protection | CloudTrail S3 数据事件 | 存储桶被批量下载、异常读取 | 新账号默认开启；老账号首次开启有 30 天试用 | | EKS Protection | EKS 审计日志 + 运行时活动 | 集群被异常提权、容器逃逸行为 | 不装 agent 也能分析审计日志 | | EC2 / ECS Runtime Monitoring | 操作系统级行为（文件、网络、进程） | 挖矿进程、反弹 shell | 唯一一个默认不开启的计划 | | Malware Protection for EC2 | 挂载的 EBS 卷数据 | 检出恶意软件 | 只扫 ≤2 TB 的卷；按扫描 GB 计费 | | Malware Protection for S3 | 新上传对象 | 用户上传的恶意文件 | 有每月免费额度（见下） | | Malware Protection for AWS Backup | 备份数据 | 备份里藏着恶意软件 | 无免费试用 | | RDS Protection | Aurora/RDS 登录活动 | 数据库异常登录 | 按 vCPU / ACU 计费 | | Lambda Protection | 函数产生的 VPC Flow Logs | 函数被用于挖矿、外连恶意地址 | 按 GB 计费 | | AI Protection | Bedrock / SageMaker 的 CloudTrail 数据事件 | 模型被滥用、提示词注入 | 新版能力，按 GB 计费 |

> 💡 省钱冷知识：GuardDuty 与 SSM 那篇讲过同一件事——开了 Runtime Monitoring 的实例，它产生的 VPC Flow Logs 不再重复计费。官方原文：instances where the GuardDuty agent is deployed and active 的 VPC Flow Logs 分析费用为 $0，因为是同一份遥测数据。所以对已经全量部署 agent 的环境，"按 GB 计费的网络日志" 那一项会显著下降。

2.2 控制台三步走（第一次开通建议走这里）

1. 进入 GuardDuty 控制台 → 选择区域（建议先选离业务最近的区域，见 2.6 的区域表）→ 点击 Get Started / 启用 GuardDuty。此时会出现"30 天免费试用"提示。 2. 进入 Settings → Protection plans，按上表逐个确认要不要开。Runtime Monitoring 默认不开，需要手动打开。 3. 进入 Settings → Usage，这里有按数据源拆分的费用预估（试用期内是预估，试用期后是实际账单）。这一步不要跳过——它是判断"这个区域值不值得开"的唯一依据。

2.3 CLI 全流程（可直接复制）

先确认身份与区域，再创建检测器。注意 GuardDuty 的检测器每账号每区域只能有 1 个。

`bash // 1. 确认当前身份与默认区域 aws sts get-caller-identity export AWS_DEFAULT_REGION=us-east-1

// 2. 创建检测器（enable=true 表示立即启用） aws guardduty create-detector --enable

// 3. 查看检测器状态与特性开关 aws guardduty list-detectors aws guardduty get-detector --detector-id <DETECTOR_ID>

// 4. 生成一批示例发现项，用来验证告警链路（不产生真实费用） aws guardduty create-sample-findings \ --detector-id <DETECTOR_ID> \ --finding-types "UnauthorizedAccess:EC2/SSHBruteForce" "Recon:EC2/Portscan"

// 5. 查看发现项（按严重程度过滤） aws guardduty list-findings --detector-id <DETECTOR_ID> \ --finding-criteria '{"Criterion":{"severity":{"Gte":7}}}'

// 6. 查看统计：按类型/严重程度聚合 aws guardduty get-findings-statistics --detector-id <DETECTOR_ID> \ --finding-statistic-types COUNT_BY_SEVERITY

// 7. 处置：归档（误报）或标记有用（反馈给模型） aws guardduty archive-findings --detector-id <DETECTOR_ID> --finding-ids <ID1> <ID2> aws guardduty update-findings-feedback --detector-id <DETECTOR_ID> \ --finding-ids <ID1> --feedback USEFUL

// 8. 覆盖率与用量：每月体检必看 aws guardduty get-coverage-statistics --detector-id <DETECTOR_ID> \ --statistics-type COUNT_BY_RESOURCE_TYPE aws guardduty get-usage-statistics --detector-id <DETECTOR_ID> \ --usage-statistic-type SUM_BY_DATA_SOURCE --unit DAYS --max-results 30

// 9. 还剩几天免费试用（写成本预估前先看这个） aws guardduty get-remaining-free-trial-days --detector-id <DETECTOR_ID>

// 10. 自定义威胁情报与可信 IP（把公司出口 IP 加白可显著减少误报） aws guardduty create-ip-set --detector-id <DETECTOR_ID> --name corp-egress \ --format TXT --location s3://my-gd-bucket/trusted-ips.txt --activate aws guardduty create-threat-intel-set --detector-id <DETECTOR_ID> --name my-ioc \ --format TXT --location s3://my-gd-bucket/ioc.txt --activate

// 11. 自定义过滤器：只对高危 + 特定资源类型告警 aws guardduty create-filter --detector-id <DETECTOR_ID> --name high-sev-only \ --finding-criteria '{"Criterion":{"severity":{"Gte":7},"resourceType":{"Eq":["Instance"]}}}' \ --action ARCHIVE `

关于第 11 步的一句话提醒：过滤器（Filter）既是降噪工具，也是省钱工具——把确定不用看的低危类型归档，EventBridge 侧的下游处理量就下来了。每账号每区域最多 100 个过滤器、6 个威胁情报集、1 个可信 IP 集。

2.4 多账号：一个委派管理员收全部发现项

官方支持两种模式，配额差别很大：

- 邀请式成员：每区域每账号最多关联 5,000 个成员账号； - 通过 AWS Organizations 关联：最多 50,000 个成员账号。

配置方式是在管理员账号执行委派管理员注册，再打开组织级自动启用：

`bash // 在委派管理员账号执行 aws guardduty enable-organization-admin-account --admin-account-id 111122223333

// 打开组织级自动启用（新账号加入即自动开启 GuardDuty） aws guardduty update-organization-configuration \ --detector-id <DETECTOR_ID> --auto-enable-organization-members NEW `

> ⚠️ 踩坑预警：通过 Organizations 自动启用的新账号，S3 Protection、EKS Protection、RDS Protection、Runtime Monitoring 都不会自动开，需要你显式打开 "Auto-enable" 开关。这条在官方 FAQ 里反复出现，也是最常见的"以为全组织都覆盖了、其实漏了一半"的根因。

2.5 GuardDuty 真实单价表（us-east-1，2026-10 采集）

GuardDuty 的单价表是按区域动态加载的，但单价本身写在官方 Pricing Examples 的句子里。下表逐条来自官方算例原文（单位已换算成"每百万 / 每 GB / 每 vCPU"）：

| 计费项 | 单价（us-east-1） | 阶梯与备注 | |---|---|---| | CloudTrail 管理事件分析 | $4.00 / 百万事件 | 按量、按比例折算，有量级折扣 | | S3 数据事件分析 | $0.80 / 百万事件（首 5 亿） | 超出部分 $0.40 / 百万 | | EKS 审计日志分析 | $1.60 / 百万条（首 1 亿） | 超出部分 $0.80 / 百万 | | Runtime Monitoring（EC2/EKS/ECS） | $1.50 / vCPU / 月（首 500 vCPU） | 下一档 $0.75 / vCPU（至 4,500 vCPU） | | Lambda 网络日志 / VPC Flow Logs | $1.00 / GB（首 500 GB） | 装了 Runtime agent 的实例不重复计费 | | Malware Protection for EC2（EBS 扫描） | $0.03 / GB | 只扫 ≤2 TB 的挂载卷 | | Malware Protection for S3 | $0.09 / GB + $0.215 / 千对象 | 2025-02-01 起扫描价从 $0.60 降 85%；有每月免费额度 | | Malware Protection for AWS Backup | $0.05 / GB | 增量扫描，只扫新增数据；无免费试用 | | RDS Protection（预置实例） | $1.00 / vCPU / 月 | Aurora Serverless v2 按 $0.25 / ACU / 月 | | AI Protection（Bedrock / SageMaker） | $1.00 / GB（首 500 GB） | 监控 AI 工作负载的 CloudTrail 数据事件 |

官方算例可以拿来校准自己的账单，例如：

- 处理 10 亿条 S3 数据事件：5 亿 × $0.80 + 5 亿 × $0.40 = $600 / 月； - 处理 2 亿条 EKS 审计日志：1 亿 × $1.60 + 1 亿 × $0.80 = $240 / 月； - 200 个 m7g.xlarge EKS 工作负载（800 vCPU）：500 × $1.50 + 300 × $0.75 = $975 / 月； - 3 个 EBS 卷共 540.75 GB 被 Malware 扫描：540.75 × $0.03 = $16.22 / 月； - 4,000 个文件上传（共 350 GB）走 S3 Malware 扫描：350 × $0.09 + 4 × $0.215 = $32.36 / 月。

2.6 区域与配额

官方端点表列出 30 多个区域，且包含 ap-east-1（中国香港），亚太另有东京、首尔、新加坡、悉尼、孟买、大阪、雅加达、墨尔本、台北、泰国、新西兰等。中国大陆区域不可用——这也是"国际版"这个前提最关键的一条。

| 配额项 | 数值 | 可否提额 | |---|---|---| | 检测器（Detector） | 每账号每区域 1 个 | 否 | | 保存的过滤器 | 每账号每区域 100 个 | 否 | | 发现项保留期 | 90 天（到期删除） | 否 | | 威胁情报集 | 每账号每区域 6 个 | 否 | | 可信 IP 集 | 每账号每区域 1 个 | 否 | | 邀请式成员账号 | 每区域每账号 5,000 | 否 | | Organizations 成员账号 | 50,000 | 否 |

> 保留期 90 天是一件必须提前规划的事：想长期留存发现项，必须在开启时就把 EventBridge 规则配好，把 findings 推到 S3 或你的安全数据湖，否则 90 天后连证据都没了。

三、Inspector 实战：把「我有哪些已知漏洞」查清楚

3.1 Inspector 到底扫什么

Inspector 是一款漏洞管理服务，和 GuardDuty 的"行为检测"完全是两件事。它扫五类目标：

| 扫描对象 | 说明 | 计费单位 | |---|---|---| | EC2 实例 | 操作系统软件包漏洞（CVE） | 每实例每月 | | ECR 容器镜像 | 镜像里的软件包漏洞 | 每镜像首次 + 每次重扫 | | Lambda 函数（标准） | 函数依赖的软件包漏洞 | 每函数每月 | | Lambda 函数（代码） | 你自己写的代码漏洞：注入、硬编码密钥 | 每函数每月（附加） | | 代码仓库 | SAST / SCA / IaC 三类扫描 | 每次扫描（按仓库大小） | | CIS Benchmark | 操作系统的 CIS 配置基线（如"是否开了 SSH 密码登录"） | 每实例每次评估 |

> 一句话区别：GuardDuty 回答"有没有人正在打你"，Inspector 回答"你身上有多少个已知的洞"。先知道洞在哪，比被打之后才发现要便宜得多。

3.2 CLI 全流程

Inspector v2 的命令前缀是 inspector2，注意不是 inspector。

`bash // 1. 开启 Inspector（可指定要扫的资源类型） aws inspector2 enable --resource-types EC2 ECR LAMBDA LAMBDA_CODE

// 2. 查看账号状态：每种资源类型是否已启用、免费试用状态 aws inspector2 batch-get-account-status --account-ids <YOUR_ACCOUNT_ID>

// 3. 还剩多少天免费试用、每种资源类型的试用开始与结束时间 aws inspector2 batch-get-free-trial-info --account-ids <YOUR_ACCOUNT_ID>

// 4. 查看当前覆盖率：有多少实例/镜像/函数真的在扫描范围内 aws inspector2 list-coverage --filter-criteria '{"resourceType":[{"comparison":"EQUALS","value":"EC2"}]}'

// 5. 查漏洞发现项：只看高危，按 CVSS 排序 aws inspector2 list-findings \ --filter-criteria '{"severity":[{"comparison":"EQUALS","value":"CRITICAL"}]}' \ --sort-criteria '{"field":"SEVERITY","direction":"DESC"}' --max-results 50

// 6. 直接搜索某个 CVE 或某个镜像 aws inspector2 search-vulnerabilities --filter-criteria '{"componentType":[{"comparison":"EQUALS","value":"boto3"}]}'

// 7. 建一条过滤规则，把"不会修的"（比如仅测试环境的低危）排除掉 aws inspector2 create-filter --name ignore-dev-low \ --action NONE --filter-criteria '{"resourceTags":[{"comparison":"EQUALS","key":"env","value":"dev"}],"severity":[{"comparison":"EQUALS","value":"LOW"}]}'

// 8. 生成 SBOM（软件物料清单）导出到 S3 aws inspector2 create-sbom-export --resource-filter-criteria '{"ecrImageTags":[{"comparison":"EQUALS","value":"latest"}]}' \ --report-format CYCLONEDX_1_4 --s3-destination bucketName=my-sbom-bucket,kmsKeyArn=<KMS_ARN>

// 9. 生成一份完整发现项报告（PDF/CSV），用于交付与合规 aws inspector2 create-findings-report --report-format PDF \ --s3-destination bucketName=my-report-bucket,prefix=inspector

// 10. CIS 基线扫描配置与结果 aws inspector2 create-cis-scan-configuration --schedule '{"scheduleExpression":"cron(0 3 ? *)"}' \ --security-level-ids "level_1" "level_2" --targets '{"accountIds":["<YOUR_ACCOUNT_ID>"]}' aws inspector2 list-cis-scans aws inspector2 get-cis-scan-report --scan-arn <SCAN_ARN> --report-format PDF

// 11. 看本月用量与预估费用 aws inspector2 list-usage-totals --account-ids <YOUR_ACCOUNT_ID> `

3.3 Inspector 真实单价表（us-east-1，2026-10 采集）

单价来自定价页官方算例原文，全部是"每单位每月"口径：

| 计费项 | 单价 | 说明 | |---|---|---| | EC2 实例扫描（基于 SSM Agent） | $1.258 / 实例 / 月 | 按覆盖率小时数按比例折算 | | EC2 实例扫描（无代理 Agentless） | $1.75 / 实例 / 月 | 无法装 agent 的实例用这个 | | ECR 镜像首次扫描 | $0.09 / 镜像 | 推送到 ECR 时触发 | | ECR 镜像重扫 | $0.01 / 次 | 同一镜像反复重扫按次计费 | | Lambda 标准扫描 | $0.30 / 函数 / 月 | 依赖包漏洞 | | Lambda 代码扫描 | 额外 $0.60 / 函数 / 月 | 即标准 + 代码 = $0.90 / 函数 / 月 | | CI/CD 内按需镜像扫描 | $0.03 / 镜像 | Jenkins / TeamCity 等流水线里触发 | | CIS Benchmark 评估 | $0.03 / 实例 / 次 | 按次评估，不含在免费试用内 | | 代码仓库扫描（SAST / SCA / IaC） | $0.15 / 次 / 每种扫描类型 | 每个仓库上限 10 MB，超过按倍数算 | | SBOM 导出 / API 调用 | 同 $0.03 / 次 口径 | 以 SBOM 为输入的漏洞查询 |

三条必须知道的折算规则：

1. 按小时按比例折算：实例只在半个月里存在，就只按半个月计费。官方算例："10 台扫满 30 天 × $1.258 = $12.58；另 10 台只存在 15 天，平均 5 台 × $1.258 = $6.29，合计 $18.87/月"。 2. 代码仓库按 10 MB 切片计费：一个 100 MB 的仓库算 10 个仓库。官方算例：5 个仓库、每周对 3 种扫描类型各扫一次 → 150 次扫描/月 = $1,125/月（这数字比很多人想的高，务必按上面的切片规则先估算）。 3. 免费试用 15 天，但 CIS 评估不包含在内。官方原文：CIS Benchmark assessments are not included in the 15-day free trial。另外接入 Azure 后，Azure 侧有独立的 30 天试用，与 AWS 试用互不影响。

四、Security Hub 实战：把发现项收成一块仪表盘，并自动动手

4.1 2026 的新计费模型：Essentials + 附加包 + Extended

Security Hub 在 2026 年已经改成三层结构，沿用旧的 "Security Hub CSPM 按检查次数计费" 的理解会算错账：

| 层级 | 定位 | 计费方式 | 是否在 30 天免费试用内 | |---|---|---|---| | Essentials（地基） | 安全态势、漏洞管理、威胁检测、风险分析、多云（含 Azure）覆盖 | 按 resource unit 每月 | ✅ 包含 | | Threat Analytics 附加包 | ML 驱动的威胁检测（由 Amazon GuardDuty 引擎驱动） | 按事件量 + 日志 GB + 运行时 vCPU | ❌ 不包含 | | Lambda Code Scanning 附加包 | Lambda 代码漏洞扫描（由 Amazon Inspector 驱动） | 按函数 | ❌ 不包含 | | Extended（全栈） | 23 家精选合作伙伴方案，横跨 10 个安全类别 | 按合作伙伴方案计价（按用户/端点/TB） | ❌ 不包含 |

4.2 resource unit 的折算表（决定你的账单大小）

Essentials 的计费锚点是 EC2 实例，其他资源按比例折算——这张表是本文最该记住的一张：

| 资源类型 | 折算为 resource unit | |---|---| | Amazon EC2 实例 | 1 个 | | Azure VM / GCP VM / OCI VM / 本地 VM | 1 个 | | AWS Lambda 函数 | 1/12 个（12 个函数 = 1 RU） | | Amazon ECR 容器镜像 | 1/18 个（18 个镜像 = 1 RU） | | IAM 用户与角色 | 1/125 个（125 个 = 1 RU） | | Fargate 任务（仅 Sensors） | 1/10 个 | | 其他所有被监控资源 | 免费包含（不额外计费） |

us-east-1 的 Essentials 单价 = $3.75 / resource unit / 月（官方算例：500 台 EC2 × $3.75 = $1,875/月；价格清单接口里 MonitoredEC2 为 $0.0052083/小时 × 720 小时 = $3.75，两处互相印证）。

> 🔴 最容易算错的一点：IAM 用户与角色也要算钱。 一个大账号里有 3,000 个 IAM 资源，就是 3,000 ÷ 125 = 24 个 RU = $90/月，而且这部分很容易被忽略。开 Security Hub 之前，一定先跑一遍 Security Hub Cost Estimator（控制台内置，会读取你账号的真实资源数）。

4.3 最关键的一条：Essentials 的单价里已经包含 Inspector 标准扫描

官方定价页在 Essentials 的能力清单里明确列出，以下能力已包含在 per-resource-unit 价格中：

- 风险分析与暴露面发现、AI 资产清单、网络扫描、未使用权限发现 - 发现项摄取与聚合、Security Hub 自动化规则 - 云安全态势管理（Security Hub CSPM） - EC2 漏洞扫描（Inspector） - ECR 容器镜像扫描（Inspector） - Lambda 标准扫描（Inspector） - CIS Benchmark 评估（Inspector） - 服务关联的 Config 记录器（AWS Config）

这条直接改变了选购姿势：如果你的目标只是"有一块仪表盘 + 标准漏洞扫描 + 合规检查"，那么只开 Security Hub Essentials 就够，不需要再单独订阅一套 Inspector（那会为同一批 EC2/镜像/函数付第二遍钱）。只有当你需要通过 Inspector 的 API 做二次开发、生成 SBOM、做 CI/CD 内按需扫描、或者需要 Inspector 的代码仓库扫描时，才值得把 Inspector 单独打开。

4.4 Security Hub CLI 全流程

Security Hub 已进入 v2 API，注意命令名带 -v2 后缀的是新模型。

`bash // 1. 启用 Security Hub（v2，默认即 Essentials 计划） aws securityhub enable-security-hub-v2 --region us-east-1

// 2. 看当前订阅状态与已启用的能力 aws securityhub describe-security-hub-v2 aws securityhub describe-security-hub

// 3. 按需启用附加能力（例如 Lambda 代码扫描） aws securityhub enable-security-hub-feature-v2 --feature-name LAMBDA_CODE_SCANNING

// 4. 查统一发现项（v2），只看高危 aws securityhub get-findings-v2 \ --filters '{"SeverityId":[{"Value":"CRITICAL","Comparison":"EQUALS"}]}' --max-results 50

// 5. 看趋势：这个月比上个月多了多少高危 aws securityhub get-findings-trends-v2 aws securityhub get-findings --max-results 20

// 6. 自动化规则：高危发现项自动打标签并推给工单系统 aws securityhub create-automation-rule-v2 --rule-name auto-tag-critical \ --rule-order 1 --description "mark critical findings for on-call" \ --criteria '{"SeverityId":[{"Value":"CRITICAL","Comparison":"EQUALS"}]}' \ --actions '[{"Type":"FINDING_FIELDS_UPDATE","FindingFieldsUpdate":{"Note":{"Text":"auto-triaged","UpdatedBy":"secops-automation"}}}]'

// 7. 批量更新发现项（人工确认后统一置为 NOTIFIED / RESOLVED） aws securityhub batch-update-findings-v2 --finding-identifiers <ID1> <ID2> \ --workflow '{"Status":"NOTIFIED"}' --note '{"Text":"已通知值班","UpdatedBy":"secops"}'

// 8. 跨账号聚合：把全组织发现项收进一块仪表盘 aws securityhub create-aggregator-v2 --region us-east-1 --aggregator-region us-east-1 \ --linked-regions ap-southeast-1 eu-west-1 --tags '{"team":"secops"}'

// 9. 合规策略：生成推荐策略并关联 aws securityhub generate-recommended-policy-v2 aws securityhub create-configuration-policy --name baseline-policy

// 10. 免费试用状态（每个账号每个区域独立计算） aws securityhub list-free-trial-statuses-v2

// 11. 资源清单与统计 aws securityhub get-resources-v2 --max-results 50 aws securityhub get-resources-trends-v2 aws securityhub get-finding-statistics-v2 \ --group-by-filters '{"AwsAccountId":[{"Comparison":"EQUALS","Value":"<ACCOUNT_ID>"}]}' `

4.5 Security Hub 真实单价表

| 计费项 | 单价（us-east-1） | 备注 | |---|---|---| | Essentials 计划 | $3.75 / resource unit / 月 | 按资源的实际监控小时数按比例折算 | | Threat Analytics：CloudTrail 管理事件 | $4.00 / 百万事件 | 附加包，与 Essentials 单独计费 | | Threat Analytics：安全数据处理 | $0.55 / GB（首 1,000 GB 档） | 阶梯计价，量大后单价下降 | | Threat Analytics：运行时活动 | $0.25 / vCPU / 月 | 按被监控工作负载的 vCPU 计 | | Extended 计划 | 按合作伙伴方案 | 例：CrowdStrike 服务器 Tier 2 为 $12/端点/月 | | 发现项跨区域摄取 | 有免费额度 | 超出按发现项事件计费 |

官方两个 Essentials 算例（可直接对照自己的规模）：

- 中小账号：1 区域 1 账号，200 万条 CloudTrail 事件 + 800 GB 安全数据 + 500 台 EC2 → $2,323/月（其中威胁检测分析 $8、数据处理 $440、风险分析 500 × $3.75 = $1,875）； - 大型组织：1 亿条 CloudTrail 事件 + 500 TB 安全数据 + 1,000 台 EC2 + 5,000 个 Lambda + 2,000 个镜像 + 3,000 个 IAM 资源 → $61,774.99/月（其中 2,233 个 RU × $3.75 = $8,374.99）。

从这两个算例能读出一条结论：当资源数量上去之后，账单主角是"按 resource unit 计的资源费"，而不是"按事件量计的检测费"。

五、Detective 实战：出事之后的「回头看」

5.1 它解决的是什么问题

GuardDuty 告警的那一刻，值班同学通常会问三个问题：这个人是谁？他什么时候进来的？他都做了什么？ Detective 就是回答这三个问题的。它把 CloudTrail 日志、VPC Flow Logs、EKS 审计日志、以及各服务送进 Security Hub 的 findings 和 GuardDuty findings 汇聚成一张行为图谱，保留最多一年的聚合数据，让你能从一个 IP 或一个 IAM 角色出发，把相关联的行为串起来。

数据源共四类：

1. AWS CloudTrail 日志 2. Amazon VPC Flow Logs 3. Amazon EKS 审计日志 4. 集成服务送入 Security Hub 的 findings + GuardDuty findings

> 注意：Detective 只对已经进入 AWS 日志体系的事件做关联分析，它不抓包、不装 agent。所以如果某类日志你本来就没开（比如某个区域的 VPC Flow Logs），Detective 也无从分析。

5.2 CLI 全流程

`bash // 1. 创建行为图谱（每账号每区域一个图） aws detective create-graph --tags '{"team":"secops"}' aws detective list-graphs

// 2. 管理数据源包（决定接哪些日志进图谱） aws detective list-datasource-packages --graph-arn <GRAPH_ARN> aws detective update-datasource-packages --graph-arn <GRAPH_ARN> \ --datasources '[{"DatasourcePackage":"CLOUD_TRAIL"}]' --datasource-package-ingest-state ENABLED

// 3. 开启调查并查看时间线 aws detective start-investigation --graph-arn <GRAPH_ARN> \ --investigation-arn <INVESTIGATION_ARN> aws detective list-investigations --graph-arn <GRAPH_ARN> aws detective get-investigation --graph-arn <GRAPH_ARN> --investigation-id <INV_ID>

// 4. 更新调查状态（把调查结论沉淀下来） aws detective update-investigation-state --graph-arn <GRAPH_ARN> \ --investigation-id <INV_ID> --status SUCCESSFUL

// 5. 列出指标（是否存在恶意 IP、异常 API、异常地理位置） aws detective list-indicators --graph-arn <GRAPH_ARN> --investigation-id <INV_ID>

// 6. 多账号：把成员账号纳入统一图谱 aws detective create-members --graph-arn <GRAPH_ARN> \ --account-id <ACCOUNT_ID> --email-address [email protected]

// 7. 组织级委派管理员 aws detective enable-organization-admin-account --account-id <ADMIN_ACCOUNT_ID> aws detective update-organization-configuration --auto-enable `

5.3 Detective 真实单价表

Detective 的计费维度只有一个：按摄取的数据量（GB / 账号 / 区域 / 月）。它不对日志源收取额外开通费，也不对存储收额外费用。

| 月摄取量档位（每账号每区域） | 单价 | |---|---| | 首 1,000 GB | $2.00 / GB | | 接下来 4,000 GB（1,000–5,000 GB） | $1.00 / GB | | 接下来 5,000 GB（5,000–10,000 GB） | $0.50 / GB | | 超过 10,000 GB 的部分 | $0.25 / GB |

官方三个算例（本文按阶梯逐档复算，与官方总分完全吻合）：

| 月摄取量 | 分档计算 | 月费用 | |---|---|---| | 500 GB | 500 × $2.00 | $1,000 | | 8,000 GB | 1,000×$2.00 + 4,000×$1.00 + 3,000×$0.50 | $7,500 | | 12,000 GB | 1,000×$2.00 + 4,000×$1.00 + 5,000×$0.50 + 2,000×$0.25 | $9,000 |

> ⚠️ 一个极易踩的坑：Detective 的 $2.00/GB 是按摄取量计费，而很多账号的 CloudTrail + VPC Flow Logs 量本来就很大。开之前一定要跑 Free Trial 期间控制台给出的"预测成本"，它的 30 天免费试用会按账号逐个显示预测费用——这是官方专门为这个场景做的功能，不用白不用。

六、Shield：抗 DDoS 的两档选择

| 项目 | Shield Standard | Shield Advanced | |---|---|---| | 价格 | 免费（所有 AWS 客户自动享有） | $3,000 / 月（每个付款账号，1 年承诺） | | 防护层级 | L3 / L4 网络层 | L3–L7，含应用层 DDoS 防护（AWS Managed Rule 组） | | 适用资源 | 全部 AWS 资源 | EC2、ELB、CloudFront、Global Accelerator、Route 53 | | 数据传出附加费 | 无 | $0.050 / GB（区域/ALB）/ $0.025 / GB（CloudFront） | | WAF 额度 | 无 | 含每月 500 亿次 WAF 请求（超出按 WAF 价计） | | DDoS 成本保护 | 无 | 有（被攻击导致的扩容账单可申请抵扣） | | 响应团队（SRT） | 无 | 需 Business 或 Enterprise 支持计划才能联系 SRT |

官方算例换算出的直觉数字：一个 ALB 每月区域数据传出 1,000 GB，订阅 Shield Advanced 后月费 = $3,000 + 1,000 × $0.050 = $3,050；若前面加一层 CloudFront 并只在 CloudFront 上开 Shield，同样的 1,000 GB 变成 $3,000 + 1,000 × $0.025 = $3,025。

> 判断口诀：Shield Standard 是"默认就有、够用就好"；Shield Advanced 是"业务被打一次就损失超过 $36,000/年"才值得买。 另外别忘了 Advanced 是每个付款账号收一次 $3,000，多账号组织要按付款账号数算，不是按成员账号数。

七、价格总表与三档场景测算

7.1 五件套单价速查（us-east-1，2026-10 采集）

| 服务 | 主要计费维度 | 关键单价 | |---|---|---| | GuardDuty | 按事件量 / GB / vCPU | CloudTrail 管理事件 $4.00/百万；S3 数据事件 $0.80/百万；EKS 审计日志 $1.60/百万；Runtime $1.50/vCPU/月；VPC Flow Logs $1.00/GB | | Inspector | 按实例 / 镜像 / 函数 | EC2 $1.258/实例/月；ECR 首次 $0.09/镜像、重扫 $0.01；Lambda $0.30/函数/月（+$0.60 代码扫描）；仓库 $0.15/扫描/类型 | | Security Hub Essentials | 按 resource unit | $3.75/RU/月（EC2=1、Lambda=1/12、镜像=1/18、IAM=1/125） | | Security Hub 附加包 | 按事件 / GB / vCPU | 威胁分析 $4.00/百万事件 + $0.55/GB + $0.25/vCPU/月 | | Detective | 按摄取 GB | 首 1,000 GB $2.00/GB，之后 $1.00 → $0.50 → $0.25 | | Shield Advanced | 订阅 + 数据传出 | $3,000/月 + $0.050/GB（区域）或 $0.025/GB（CloudFront） |

7.2 三档场景测算（示意算例，非官方报价）

假设 1 个账号、1 个区域（us-east-1）、1 个月。所有数字由脚本按上表单价逐项算出，非官方报价，仅用于建立量级直觉：

| 场景 | 资源规模 | GuardDuty | Inspector | Security Hub | Detective | 合计 / 月 | |---|---|---|---|---|---|---| | A 起步 | 5 台 EC2、5 个 Lambda、10 个镜像、20 个 IAM、10 GB 流日志、100 万 CloudTrail 事件 | $14.00 | $6.29 | $23.00 | 未开 | $43.29 | | B 成长 | 20 台 EC2、60 个 Lambda、180 个镜像、250 个 IAM、50 GB 流日志、500 万事件、5,000 万 S3 数据事件、60 vCPU | $200.00 | $25.16 | $138.75 | 未开 | $363.91 | | C 成长 + 调查 | 同 B + 开 Detective | $200.00 | $25.16 | $138.75 | $100.00 | $463.91 | | D 成长 + 附加包 | 同 C + Security Hub 威胁分析附加包（500 万事件 + 50 GB） | $200.00 | $25.16 | $138.75 + $47.50 | $100.00 | $511.41 |

场景 B 的 GuardDuty 分项值得单独拆开看，因为钱花在哪一项完全反直觉：

| GuardDuty 分项 | 计算 | 金额 | 占比 | |---|---|---|---| | VPC Flow Logs | 50 GB × $1.00 | $50.00 | 25% | | CloudTrail 管理事件 | 5 百万 × $4.00 | $20.00 | 10% | | S3 数据事件 | 5,000 万 × $0.80/百万 | $40.00 | 20% | | Runtime Monitoring | 60 vCPU × $1.50 | $90.00 | 45% | | 合计 | | $200.00 | 100% |

结论：Runtime Monitoring 是 GuardDuty 账单里最大的一项（45%），而它恰恰是唯一默认不开启的计划。 所以「GuardDuty 很便宜」和「GuardDuty 有点贵」都对——差别只在于你有没有开 Runtime Monitoring。

场景 C 的四服务占比也能说明问题：

| 服务 | 金额 | 占比 | |---|---|---| | GuardDuty（含 Runtime） | $200.00 | 43.1% | | Security Hub Essentials | $138.75 | 29.9% | | Detective | $100.00 | 21.6% | | Inspector | $25.16 | 5.4% | | 合计 | $463.91 | 100% |

> 💡 这张表最值钱的一条结论：Inspector 只占 5.4%，而 Security Hub Essentials 占 29.9%。所以在预算有限时，正确顺序是"先砍 Detective 和 Runtime Monitoring，而不是先砍 Inspector"——漏洞扫描是性价比最高的那一项。

八、30 天免费试用怎么用满（含"会踩坑的免费额度"）

这五个服务的"免费"是两种完全不同的东西，混在一起会出大问题：

- 免费试用（Free Trial）：一段时间内全功能免费用，到期自动转付费，不是"永久免费额度"； - 免费额度（Free Tier allowance）：每月固定送一些量，长期有效。

8.1 五个服务的试用与额度对照

| 服务 | 试用时长 | 试用覆盖范围 | 明确不在试用内的部分 | |---|---|---|---| | GuardDuty | 30 天（每账号每区域；未启用过该功能的老账号首次启用同样有 30 天） | 全功能检测 | Malware Protection for S3 无试用；Malware Protection for AWS Backup 无试用；按需（on-demand）扫描无试用 | | Inspector | 15 天 | EC2 / Lambda / ECR / 代码仓库的持续扫描 | CIS Benchmark 评估不含；CI/CD 内按需扫描只给一次性 25 次免费额度；接入 Azure 后有独立的 30 天试用 | | Security Hub | 30 天 | 仅 Essentials 计划能力 | Threat Analytics 附加包、Lambda Code Scanning 附加包、Extended 计划都不含 | | Detective | 30 天 | 全功能，并可查看按账号拆分的预测成本 | 无（试用期本身完整） | | Shield Advanced | 无免费试用 | — | Shield Standard 永久免费，但只有 L3/L4 |

8.2 还有一条常被忽略的月度免费额度

GuardDuty Malware Protection for S3 有一个月度免费额度：每月 1,000 次请求 + 1 GB，在所有启用了该功能的区域都适用。但要注意官方明确写了：

> The Free Tier does not apply to the scan-on-demand API.

也就是说按需扫描（scan-on-demand）永远按标准价计费，只有"新上传对象自动扫描"才吃这个免费额度。

8.3 免费试用与 2026 的「$200 免费计划」是两件事

AWS 在 2025-07-15 之后改了新账号的免费政策：新账号最高 $200 赠金（注册得 $100 + 完成入门操作最多再得 $100），免费计划有效期 6 个月，赠金需在 12 个月内用完；一旦把账号加入 AWS Organizations 或建立 Control Tower landing zone，赠金会立即失效并自动转为付费计划。

这带来一个很现实的冲突：做企业级安全（GuardDuty/Security Hub 多账号）几乎必然要用 Organizations，而用了 Organizations，$200 赠金就没了。 所以如果你是在"先用赠金试水"的阶段，建议先在单账号里把 30 天试用跑完，再决定要不要上 Organizations。

8.4 五步把试用期用满（按顺序做）

1. 第 1 天：先在一两个区域开 GuardDuty + Security Hub Essentials，跑 create-sample-findings 验证告警链路是否通到你的邮箱/Slack。 2. 第 2–3 天：开 Inspector，跑 list-coverage 确认覆盖率——如果覆盖率不足 100%，说明有实例装不上 SSM Agent，那部分永远是盲区。 3. 第 1 周：配置 EventBridge → Lambda 的自动响应规则，并只记录不阻断地跑一周，统计误报率。 4. 第 2 周：打开 EventBridge 的长期留存（把 findings 推到 S3），否则 90 天后证据消失。 5. 到期前 3 天：用 GuardDuty 的 get-usage-statistics、Inspector 的 list-usage-totals、Security Hub 的 Cost Estimator 三处交叉核对，明确算出转付费后的月账单，再决定哪些功能保留。

九、自动响应实战：从"告警"到"动手"

只告警不处置，等于给自己找了一份 24 小时值班的工作。AWS 上的自动化响应链路是：

GuardDuty / Inspector → EventBridge → Lambda（或 SSM Automation / Step Functions）→ 执行动作 + 通知

9.1 七条可直接落地的 Playbook

| 场景 | 触发 | 动作 | |---|---|---| | 发现 EC2 被用于挖矿 | GuardDuty 高危 finding | 打标签隔离 → 摘安全组 → 通知值班 | | 发现 AccessKey 在异地被使用 | GuardDuty IAM 类 finding | 自动禁用该 AccessKey（可逆） | | 发现 S3 桶被设为公共 | GuardDuty S3 / Config 规则 | 自动恢复私有 ACL（可逆） | | 发现实例开放了 22/3389 到 0.0.0.0/0 | Config + GuardDuty | 自动回滚安全组 + 通知 | | 发现审计日志被关闭 | CloudTrail 事件 | 最高等级告警 + 双人复核（不可自动做决定） | | 发现高危 CVE（CVSS ≥ 9） | Inspector finding | 建工单 + 调 SSM 打补丁 | | 发现异常登录后成功 | GuardDuty RDS / 登录类 finding | 强制 MFA 重认证 + 会话吊销 |

9.2 半自动 vs 全自动的边界（这张表比代码更重要）

自动响应最怕"自动化把生产搞挂了"。合理的边界是：

| 动作类型 | 可否全自动 | 理由 | |---|---|---| | 禁用 AccessKey / 吊销会话 Token | ✅ 可以 | 可逆、影响面明确、有恢复路径 | | 收紧安全组 / 把 S3 桶恢复私有 | ✅ 可以 | 只是"变回安全状态"，不损失业务功能 | | 强制 MFA 重认证 | ✅ 可以 | 体验可接受，安全收益最高 | | 隔离实例 / 摘掉流量 | ⚠️ 半自动 | 可能中断业务，需值班一键确认 | | 删除资源 / 删除密钥 | ❌ 不可以 | 不可逆，还会销毁证据 | | 数据导出 / 对外共享 | ❌ 不可以 | 可能构成新的数据出境风险 | | 关闭审计日志 / 改告警规则 | ❌ 不可以 | 攻击者最想要的"致盲"动作，必须人工 + 双人复核 |

一句话原则：可逆的自动做，不可逆的人工做；防"致盲"的动作双人复核。

> 🔴 特别提醒：StopLogging、DeleteTrail 这类 API 名字必须出现在你的告警规则里。攻击者拿到凭证后的第一优先级动作就是关日志，这几条规则的优先级应该高于所有其他规则。

9.3 一条最小可用的 EventBridge 规则骨架

`bash // 订阅 GuardDuty 高危发现项 aws events put-rule --name gd-high-severity \ --event-pattern '{"source":["aws.guardduty"],"detail-type":["GuardDuty Finding"],"detail":{"severity":[{"numeric":[">=",7]}]}}'

// 把事件投递给一个负责处置的 Lambda aws events put-targets --rule gd-high-severity \ --targets Id=1,Arn=arn:aws:lambda:us-east-1:<ACCOUNT_ID>:function:secops-responder

// 同时推一份到 SNS，做人工通知 aws events put-targets --rule gd-high-severity \ --targets Id=2,Arn=arn:aws:sns:us-east-1:<ACCOUNT_ID>:secops-oncall `

十、省钱 6 招

1. 先只开 Security Hub Essentials，别三个服务各开一套。 Essentials 的单价里已经包含了 Inspector 的标准扫描与 Config 记录器，重复订阅是纯浪费。 2. 用 GuardDuty Filter 归档低危类型。 每账号每区域最多 100 个过滤器，把"确定不会看"的类型归档，EventBridge 的下游处理量会同步下降。 3. 给实例装 Runtime Monitoring agent，它产生的 VPC Flow Logs 不再重复计费。 官方原文如此，全量部署 agent 的环境能明显压掉"按 GB 计费"的那一项。 4. 按区域分别评估，不要在没业务的区域开。 GuardDuty、Inspector、Security Hub、Detective 都是按区域独立计费、独立试用的。一个只需要亚太业务的公司，没必要在 10 个区域都开。 5. Inspector 优先扫 ECR 与 Lambda，EC2 用无代理还是代理按需选。 代理由 $1.258、无代理 $1.75，差 39%，能装 agent 就别选无代理。 6. 每季度复查一次总量。 aws guardduty get-usage-statistics、aws inspector2 list-usage-totals、aws securityhub get-resources-trends-v2 三条命令能在一分钟内告诉你"这个季度是不是多花了钱"。

十一、7 大坑

1. Organizations 自动启用不会全开。 通过 Organizations 自动启用的新账号，S3 Protection、EKS Protection、RDS Protection、Runtime Monitoring 都需要你显式打开 Auto-enable，否则"以为全组织覆盖、其实漏了一半"。 2. 试用到期不会自动停。 30 天 / 15 天试用结束后直接转付费，没有"自动关闭"选项。要在日历上提前标记到期日。 3. GuardDuty findings 只留 90 天。 到期即删除，且不可提额。不配 EventBridge 推到 S3，90 天后连取证材料都没有。 4. Security Hub 的 IAM 用户与角色也要钱。 125 个 = 1 个 resource unit。一个大账号 3,000 个 IAM 资源就是 $90/月，很容易在预算表里被漏掉。 5. Inspector 代码仓库按 10 MB 切片计费。 100 MB 的仓库按 10 个仓库算。5 个中型仓库、每周对 3 种类型各扫一次，官方算例就能到 $1,125/月。 6. Shield Advanced 是"每个付款账号" $3,000/月。 不是每个成员账号，但多付款账号的组织要按付款账号数乘。另外联系 SRT（DDoS 响应团队）需要 Business 或 Enterprise 支持计划，只买 Shield Advanced 并拿不到人工应急支持。 7. 免费试用不等于免费额度。 GuardDuty 只有 Malware Protection for S3 有月度免费额度（1,000 请求 + 1 GB），且按需扫描不吃这个额度；其余服务都是"试用期"逻辑，到期即计费。

十二、常见问题 FAQ

Q：开 GuardDuty 之前需要先把 CloudTrail、VPC Flow Logs、DNS 日志都配好吗？

A：不需要。GuardDuty 通过服务关联角色自己直接拉取 CloudTrail 管理事件、VPC Flow Logs 和 DNS 查询日志三类数据流，你不用建 S3 桶、不用写桶策略，也不用担心后续 IAM 策略变更影响它工作。

Q：GuardDuty、Inspector、Security Hub 到底要不要都开？

A：取决于目标。只想"有一块仪表盘 + 标准漏洞扫描 + 合规检查" → 只开 Security Hub Essentials 就够（官方口径：它的 resource unit 价已含 Inspector 的标准扫描与 Config 记录器）。需要调 Inspector API 做二次开发、生成 SBOM、在 CI/CD 里按需扫描、或需要代码仓库扫描 → 再把 Inspector 单独打开。需要自建检测流水线、把 findings 接进自有 SIEM → 再单独开 GuardDuty。

Q：30 天免费试用到期后会怎样？会不会自动扣费？

A：会。试用结束即按标准价计费，没有自动停止机制。试用期内控制台会给出"转付费后的成本预估"（GuardDuty 在 Usage 页、Detective 会按账号列出预测成本），务必在到期前用这些数字做一次取舍。

Q：香港区域可以用吗？

A：GuardDuty 官方端点表明确列出 ap-east-1（中国香港），亚太另有东京、首尔、新加坡、悉尼、孟买、大阪、雅加达、墨尔本、台北、泰国、新西兰等。中国大陆区域不可用，需要国际版账号。

Q：一个月大概要花多少钱？

A：按本文场景测算（us-east-1，1 账号 1 区域）：5 台 EC2 的起步环境约 $43/月；20 台 EC2 + 60 个 Lambda + 180 个镜像 + 250 个 IAM 资源的环境约 $364/月（含 GuardDuty Runtime），加上 Detective 约 $464/月。数字仅供建立量级直觉，真实成本请用 Security Hub Cost Estimator 读取你账号的实际资源数。

Q：Detective 那么贵（$2/GB），能替代吗？

A：如果只是偶尔查一次，可以用 CloudTrail Lake 或自建 OpenSearch 做临时调查，成本更低；但如果你想长期保留一年的行为图谱、并支持从 IP/角色出发一键展开时间线，Detective 的运维成本远低于自建。判断标准是"你一年会做几次调查"。

Q：只开 Security Hub Essentials 会不会漏掉威胁检测？

A：会。Essentials 的定位是态势 + 漏洞 + 风险分析，真正"实时威胁检测"那部分在 Threat Analytics 附加包（由 GuardDuty 引擎驱动）里，按 $4.00/百万事件 + $0.55/GB + $0.25/vCPU/月单独计费。如果预算只够一个，先 Essentials 拿漏洞与合规，再加附加包拿检测。

Q：这些服务和我已有的第三方 SIEM/SOC 冲突吗？

A：不冲突，而且是互补。AWS 这套是"云原生检测层"，负责在云内部产生高保真发现项；第三方 SIEM 负责跨云、跨本地、跨业务的关联。合理架构是：Security Hub 做聚合器 → 通过 EventBridge / 导出到 S3 → 再送进第三方 SIEM。不要在 AWS 侧重复建设一套全量日志存储，那是成本翻倍最快的方式。