AWS全场景安全运营体系搭建：Web/APP/IoT告警降噪与自动化响应

如果你手上同时管着Web门户、移动App和一批IoT设备，那么AWS云环境的安全运营往往不是“有没有安全工具”的问题，而是“工具散落一地、告警互相打架、出了事不知道先看哪块”的问题。最近我帮一家客户从0到1搭了一套覆盖Web/APP/IoT全场景的AWS安全运营体系，从账号基线到自动化处置，用了不到两周时间把日均告警量从上千条降到了几十条，而且真正遇到攻击时能直接联动封禁，不用人肉翻日志。这篇文章就把整个搭建过程、选型逻辑和踩过的坑完整写出来，适合正在做云上安全建设的运维、安全工程师和架构师参考。

这个体系不是什么天价商业方案，全部基于AWS托管服务搭建。我会按“底层逻辑 -> 服务选型 -> 账号基线 -> 三类场景落地 -> 运营闭环”的顺序来讲，每一步都给可落地的配置思路和关键参数，也会穿插一些我们实测中踩过的坑。尤其是告警降噪和成本控制这两块，很多人一开始根本不会注意到，但它们恰恰决定了一套安全运营体系能走多远。

1. 安全运营的底层逻辑：为什么零散工具救不了云环境

1.1 从一次凌晨的告警风暴说起

我接手这个项目前，客户的AWS环境已经不是什么都没做的状态。他们有CloudTrail，开了GuardDuty，也买了WAF，看起来该有的都有。但拿到权限一看，GuardDuty在6个region里只开了2个，S3的访问日志没有开对象级写入，CloudTrail的日志全部落在单账户的默认桶里，最糟的是SNS里根本没有任何告警订阅——也就是说，就算GuardDuty发现了问题，也没有人会收到通知。

真实情况比这更戏剧化。客户把Web应用的前端放在一台绑了公网EIP的EC2上，安全组对全互联网开放了22端口，而且有一把长期的access key被开发顺手提交到了开源代码仓库。华为云有人用这个key扫了一整夜，客户第二天看到账单飙升才反应过来。整个排查过程花了将近一天，因为没有任何集中日志，只能在各个控制台之间来回切。

这件事让我意识到，零散启用几个AWS安全服务，跟“运营”完全不是一回事。安全运营的底层不是某几个工具，而是一条从“识别 -> 检测 -> 响应 -> 修复”的闭环链路。少了任何一环，前面的检测能力都等于摆设。

1.2 Web/APP/IoT三类场景，威胁模型完全不同

做体系设计之前，必须先把三类业务场景掰开来看。很多人上来就配WAF和GuardDuty，配完之后发现APP场景的威胁根本没覆盖到，IoT设备的行为异常也检测不出来。我习惯先用一张表把三类场景的差异列清楚，再决定在每个场景上投入什么资源：

Web场景的防护重点在“边界”，App场景的重心在“身份”，IoT场景则在“设备信任”。如果你只靠一套WAF和Security Hub就想覆盖所有场景，那大概率只能覆盖Web那部分，APP和IoT仍然处于裸奔状态。所以体系设计的第一步，不是选工具，而是画清楚你的资产和威胁面。

1.3 用事件时间线反推体系设计

我设计安全运营体系时有个习惯：先假设一个“攻击者正在打你”的事件时间线，反推每一步需要什么数据源和响应动作。比如一个典型的Web入侵过程：

1. 攻击者扫描公网IP，发现暴露的管理后台端口；
2. 对后台发起暴力破解，成功拿到弱口令；
3. 登录后台，上传webshell，横向扫描内网；
4. 拖走数据库，植入挖矿程序，绑定定时任务确认持久化。

现在反推：第一步需要外部扫描感知能力，可以用GuardDuty的Recon、VPC Flow Logs异常检测；第二步需要安全组收敛和失败登录告警；第三步需要CloudTrail和可疑进程检测；第四步需要S3数据访问审计和实例资源监控。有了这条完整的事件时间线，再看应该接哪些数据、配哪些告警，整个架构就会清晰很多。

这套思路放到APP和IoT场景也一样，只要把攻击者当作用户来模拟一遍，你自然就知道该在哪个环节布防了。

2. 选型清单：AWS 安全服务怎么挑、怎么搭才不重叠

2.1 十一个核心服务，各管一段

AWS这家公司的问题从来不是能力不够，而是服务太多太碎，很容易让人陷入“选择困难症”。我的经验是只保留一套最小可用集，避免多个服务做同一件事。

这套组合里，真正24小时需要盯着的是GuardDuty、Security Hub、CloudTrail和Config，其他服务属于“定期用”或者“出事才翻”的类型。理解了各自的分工，后面的配置才不会乱。

2.2 为什么我不建议自己搭一套开源SIEM

很多人一聊安全运营就想着自己搭ELK或者Graylog，把VPC Flow Logs、CloudTrail、WAF日志全部灌进去，再写一堆告警规则。这个方案在只有单账户、几十台实例的场景下还能凑合，一旦账户规模超过三五个，或者有多个region，日志采集agent的维护、索引优化和告警规则调试就会吃掉大量时间。

我的观点很直接：开源自建SIEM适合做数据分析平台的团队，不适合大多数中小型云上业务团队。AWS托管方案的天花板虽然不如定制SIEM高，但它赢在“零维护、默认越权少、跟IAM和Organization深度集成”。GuardDuty和Security Hub能自动获取多账户多region的检测结果，自己的ELK想做到这个程度，至少要花两周时间做权限模型和跨账户日志汇聚。

当然，如果监管要求你必须保留超过一年的日志分析，或者业务有自己的威胁情报模型，那就把S3里的CloudTrail、ALB、VPC Flow Logs作为原始数据源，用Athena按需查询，而不是再起一套永远在烧钱的日志集群。这个方案我后面会具体演示。

2.3 托管服务的分工边界

还有一个很常见的坑：GuardDuty和Security Hub长得有点像，很多人以为开了Security Hub就自动有了威胁检测能力。实际上完全不是一回事。

GuardDuty负责“检测”，它通过分析DNS、VPC Flow Logs、CloudTrail找到异常事件；Security Hub负责“聚合和合规”，它把GuardDuty、Inspector、Config、Macie等发现都收进来，做统一展示和打分。换句话说，GuardDuty是传感器，Security Hub是中控台，两者是上下游关系，不是替代关系。

在我这套体系里，它们的边界非常清楚：

• 检测层：GuardDuty + Inspector + Macie + Config；
• 聚合层：Security Hub；
• 响应层：EventBridge + SNS + Lambda；
• 展示层：Security Hub + 告警通道。

配置的时候不要贪多，一个账号一个region一个角色，按这条链路走完，再复制到其他region，最后在Organization层面做统一管理。

3. 从0到1：先把账号、日志、告警这条地基打通

3.1 组织级CloudTrail：日志不落S3等于白开

CloudTrail是整个体系的“摄像头”，它记录API调用行为，IAM用户登录、Lambda执行、S3删除、EC2启动等全部有迹可循。但很多人的CloudTrail只开在默认region、默认桶，而且没有开启数据事件记录，结果日志形同虚设。

我的建议是，在Organization的Root账户里启用组织级CloudTrail，一条trail覆盖所有成员账户，日志统一投递到一个集中日志账户的S3桶。这个桶必须设置严格的Bucket Policy，只允许CloudTrail写入，并且开启版本控制和MFA Delete，防止攻击者删除日志。

关键配置点：

• 管理事件：勾选read + write，全部开启；
• 数据事件：S3对象级写入和Lambda执行建议开启，但要注意日志量会明显增加；
• 启用Insights事件：用来检测API调用中的异常模式，比如某个IAM用户发生突变式的调用量。
• 日志文件前缀：建议按STS格式分区，方便后续用Athena按时间范围查询。

如果预算紧张，至少要把write事件和S3对象级删除事件打开。read事件太多，日志量大，但对安全排查也有价值，可以根据自己业务权衡。但write事件绝对不能省。

3.2 GuardDuty和Security Hub：检测与聚合要同时启用

GuardDuty是个多region服务，每个region都要启用，否则攻击者在未启用region的流量和API行为就变成了盲区。我一般直接用AWS Organizations批量启用，这样新加入的账户会自动被保护。

GuardDuty启用后，它会自动分析CloudTrail事件、VPC Flow Logs和DNS日志。不需要你做额外采集，这也是我优先推荐它的原因之一。Security Hub则负责把GuardDuty的安全发现聚合到一起，并和CIS AWS Foundations Benchmark做合规检查。

这里有几个容易漏的细节：

• Security Hub也要在每个region分别启用，但可以通过聚合配置把发现集中到主region；
• GuardDuty的发现默认保留90天，建议设置S3自动归档规则，方便后续审计；
• Security Hub和GuardDuty都建议使用中央管理员账户模式，否则每个子账户各看各的，运营效率起不来。

兜底的做法是给Security Hub创建一个自定义的 insight，把“Critical和High级别的GuardDuty发现”固定成一个视图，安全运营同事每天只需看这个列表即可。

3.3 告警通路：EventBridge + SNS + Lambda的轻量编排

检测做完了，最关键的“告警通路”才刚上桌。很多团队开通GuardDuty后就没下文了，直到安全事故复盘才发现“根本没有通知”。这一步我一般是这么搭的：

1. 创建三个SNS Topic：一个给Critical，一个给High，一个给Medium/Low；
2. 在EventBridge里创建规则，监听GuardDuty的Finding事件，按严重级别发送到对应Topic；
3. 用Lambda接收SNS消息，做格式化后推到企业内部的钉钉/企微/邮件；
4. Critical事件额外触发一条自动化Playbook，比如自动隔离异常实例。

EventBridge规则的JSON大致长这样：

{ "source": ["aws.guardduty"], "detail-type": ["GuardDuty Finding"], "detail": { "severity": [8, 9, 10] } }

Lambda里没必要写太复杂的逻辑，格式化消息、丢到指定webhook即可。真正复杂的自动化动作放在后面的Playbook里。这套链路我跑了半年，最稳定，也不需要额外买商业告警平台。

还有一个容易被忽略的点：SNS推送失败时要有兜底。我习惯在SNS Topic里同时加一个邮箱订阅，或者用CloudWatch Alarm监控SNS投递失败率。告警链路自身挂了，比没告警还危险。

4. Web场景落地：入口防护、主机漏洞、日志分析三线并行

4.1 CloudFront + WAF + Shield，把攻击挡在边缘

Web场景最容易看见效果的地方在入口。我的常规配置是CloudFront做CDN和加速，WAF挂在CloudFront前面，Shield Standard自动开启，再叠加Shield Advanced如果有DDoS合规要求。这套组合能过滤掉绝大部分扫描流量和Web层攻击。

WAF的规则组我一般是这么开的：

• AWS托管规则组里的SQL注入规则和XSS规则，直接关联；
• Core Rule Set全部启用，应用层协议异常、恶意UA、畸形请求都会被拦截；
• 自定义Rate-based rule，比如同一个IP 5分钟内超过200次请求就封禁；
• 对登录接口单独加一条“失败次数超过阈值自动Block”的规则。

实际落地时要注意误报问题。WAF拦截后用户会看到类似“Your last request has been blocked for security purposes”的提示页，如果业务有正常的请求模式，比如API接口有高频率轮询，很容易误伤。所以WAF上线后第一周一定要开“Challenge”或“Count”模式，观察云监控里的拦截样本，再把规则从Count切到Block。

4.2 Inspector定时扫主机，别等被攻破才知道有漏洞

主机侧的漏洞扫描，Amazon Inspector是AWS原生方案里最省心的。它可以定时扫描EC2实例上的操作系统和应用程序漏洞，并且能结合网络可达性给风险打分。这个服务的底层扫描引擎不需要装agent（其实是Amazon自有探针），对生产环境侵入性很低。

我的建议配置是：

• 对生产环境EC2启用持续扫描模式，每24小时扫一次；
• 对部署用的AMI镜像做“构建时扫描”，也就是在流水线里跑Inspector扫描，扫描过了再推送到生产；
• 把Inspector发现推送回Security Hub，统一看漏洞趋势。

很多人会问Inspector和第三方漏洞扫描器有什么区别。最大的区别是Inspector知道你的实例是否暴露在公网，它能调出“这台机器根本没绑公网IP，虽然漏洞严重但不可达”这样的结果，优先级自然不同。所以我把Inspector的“网络可达性”作为排序第一维，再结合CVSS评分，优先修复那些“又严重又暴露”的主机。

4.3 从ALB日志到Athena，用SQL查异常流量

光有WAF拦截还不够，安全运营需要能自己查历史流量。ALB的访问日志默认不开启，开之后会写进S3，再通过Athena建表就能用SQL查了。我分享一条我们最常用的查询，统计被WAF拦截的Top IP和路径：

SELECT request_ip, count(*) AS requests FROM alb_logs WHERE elb_status_code = '403' AND date >= current_date - interval '7' day GROUP BY request_ip ORDER BY requests DESC LIMIT 20;

这个查询能快速定位谁在反复触犯WAF规则、有没有集中的扫描源。另外，还有一些非常值得关注的特征：请求路径里带../../、select、waitfor、<script>的，大概率是自动化扫描器在试探。把这些现象沉淀成Athena的常用查询模板，下次排障会快非常多。

4.4 一个SQL注入攻击的处置复盘

有一次客户线上环境大量用户反馈“网页卡死”，打开WAF的Sampled Requests，发现某个源IP对商品搜索接口发起了大量带UNION SELECT的请求。我们的漏斗是这样转的：

1. WAF规则命中，自动把这个IP加入了封禁列表，用户侧立刻看到了block页面；
2. EventBridge触发Lambda，自动把该IP写入WAF的IP Set，并同时发通知给运维群；
3. GuardDuty这边显示同一次攻击中还有大量端口扫描行为，Security Hub把发现合并成一条Critical事件；
4. 我们通过CloudTrail检查该请求对应的API权限，确认没有利用到数据库层，业务无数据泄露。

整个处置过程从发现到封禁，大约3分钟，没有人工介入。这个Playbook是我在Web场景里第一个做的，也是收益最明显的。关键是事先把WAF规则、EventBridge、Lambda之间的链路测通，别等攻击来了才临时写函数。

5. APP场景落地：API网关、身份池与客户端风控的消息闭环

5.1 API Gateway 做唯一入口，绑定WAF和限流

APP场景和Web最大的区别在于，流量不经过浏览器，直接打到API。如果业务方把API直接暴露在公网，安全组和传统WAF很难做细粒度的身份识别。所以我在APP场景里的核心思路是：所有API必须统一走Amazon API Gateway，然后让API Gateway绑定WAF和Usage Plan。

API Gateway有几个安全相关的能力一定要开：

• 开启TLS强制，禁用HTTP明文访问；
• 绑定WAF Web ACL，特别是针对API路径的SQL注入、恶意IP封禁规则；
• 开启Usage Plan，给每个App客户端一个限流配额，防止单个用户把后端拖垮；
• 开启CloudWatch Logs，记录每次请求的API key、来源IP、响应码。

实际上很多所谓的“App安全事件”，比如爆破登录、爬接口数据、薅羊毛，都源于API没有统一网关，直接暴露在公网。加了API Gateway这层“旋转门”之后，至少你能知道谁在什么地方用什么身份频繁访问接口，这是后续风控的基础。

5.2 Cognito 身份池与最小权限 IAM

APP场景的身份体系，我默认用Amazon Cognito。用户池负责注册、登录、找回密码，身份池负责给登录后的用户颁发临时AWS凭证。这里的权限模型是关键：Cognito不是一个万能保险箱，如果身份池的IAM角色配得过大，用户一旦逆向客户端拿到临时凭证，就能调一大堆不该调的API。

我见过最典型的问题：Cognito身份池的Unauthenticated Role被分配了S3:*或DynamoDB:*权限，导致未登录用户也能遍历整个存储桶。这个问题的根源不是Cognito，而是开发者图省事，把角色权限开成了通配符。

正确的做法是：

• 所有Cognito角色都遵循最小权限，只给业务需要的API动作；
• 用条件键aws:SourceIp限制Cognito临时凭证只能在APP使用的出口IP网段内生效；
• 定期用IAM Access Analyzer扫描身份池角色，找出“未使用但已赋权”的策略；
• 对Cognito用户池开启Advanced Security Features，它自带检测被撞库的凭证、异常登录，并返回Block或者Challenge结果，可以联动后续风控逻辑。

5.3 用 Lambda Authorizer 做设备维度的风控

如果只是账密登录，Cognito够用。但APP场景里经常出现“同一个账号在几十台设备上同时登录”“一台设备短期注册了大量账号”这类要基于设备维度的风控需求。API Gateway的Lambda Authorizer很适合干这个事。

思路是：客户端请求时带上用户JWT和设备指纹，Lambda Authorizer校验JWT合法之后，再调用DynamoDB查这个设备指纹有没有被标记异常，最后生成一个允许或拒绝的IAM Policy返回给API Gateway。整个过程对业务无感，但每次请求都被“过了一道风控”。

我给客户落地时，设备指纹用了最简单的方案：取设备型号、系统版本、IDFV等拼接后做哈希，存进DynamoDB。后续如果某台设备指纹关联了3个以上账号，定义为可疑设备，下次请求直接Deny。这个方案用不到第三方风控SDK，成本低，且能挡住大部分撞库和批量注册。

5.4 一次撞库攻击的自动封禁实战

有一次客户APP上线大促，运营数据没异常，但Cognito的“登录失败次数”曲线突然陡增。我们在Lambda Authorizer里加了缓存逻辑，并在WAF里针对/login这个路径加了一条Rate-based Rule，比如5分钟内同一个IP超过30次登录请求就自动封禁24小时。因为撞库通常是用脚本更换大量账号，所以短时间内的失败登录会非常密集。

这个方案上线后，第一次遭遇撞库时效果很有意思：WAF封禁了几十个IP，但攻击者很快换了一批IP继续打。后来我们又在Lambda Authorizer里增加逻辑，把“同一个设备指纹更换超过5个账号”判定为异常，直接拒绝。两层一起生效后，攻击者的成本就很高了，因为他们必须同时换IP和换设备指纹才能继续试。

这里要提醒一句：光靠IP封禁在APP场景根本不够，移动网络下IP经常被NAT，攻击者换IP的代价极低。设备指纹才是APP场景比Web场景多出来的那一层防线。

6. IoT场景落地：设备身份、证书策略与失陷后的快速隔离

6.1 先认清IoT的信任边界：证书即身份

IoT场景和Web/APP最大的区别在于，设备不是人，它没有账密，也没有浏览器指纹。AWS IoT Core采用“证书即身份”的模型，每台设备发一个X.509证书，证书绑定固定的IoT Policy，决定它能发布和订阅哪些Topic。

这里的核心安全原则是：一台设备只能做它该做的事。比如一台温湿度传感器，它的策略应该只能发布device/001/telemetry这个Topic，没有权限订阅控制指令，更没有权限调用IoT Shadow的List或Delete接口。现实中很多团队图省事，给同型号所有设备发同一个全权限策略，结果一台设备被攻破后，攻击者可以伪装成任意设备控制整个车间。

我的IoT设备证书策略，习惯在创建时就用模板生成，每台设备的Topic路径都包含唯一Thing Name，并在策略的Resource字段里限定：

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["iot:Publish"], "Resource": "arn:aws:iot:region:account:topic/device/${iot:ThingName}/telemetry" }, { "Effect": "Deny", "Action": "iot:*", "Resource": "*" } ] }

这样即使证书泄露，攻击者也只能模拟这台设备上报消息，无法横向控制其他设备。

6.2 Device Defender 定义设备行为基线

IoT设备不像服务器可以随时打补丁，很多设备固件一两年都不更新，所以对“行为异常”的检测比对CVE漏洞的检测更重要。AWS IoT Device Defender就是干这个的，它通过Security Profiles定义设备的行为基线，比如：

• 设备每隔多久发一次消息，消息频率不能超过某个阈值；
• 设备正常情况下只和哪些IP通信；
• 设备连接次数、断开次数是否有异常；
• 设备发送的payload大小是否符合业务预期。

我给客户做过一个案例：某工厂的设备每天早上8点到晚上10点正常上报数据，夜间处于低功耗状态。Device Defender设置晚上10点后消息频率为0的基线，某天凌晨3点突然出现连续消息，Security Hub里立刻冒出一条高风险告警。后来排查发现，设备被植入了一个脚本，在偷偷尝试用设备证书连接外部地址。

这种“低慢”型攻击，Web层的扫描器根本看不见，只有基于设备正常行为的基线检测才能捕捉到。IoT场景的安全运营，核心不是防DDoS，而是防仿冒和防被利用。

6.3 设备被薅羊毛或中招后，怎么隔离才干净

设备失陷后，处置动作必须能快速执行，而且要“断得干净”。AWS IoT Core里我常用的隔离方案有三级：

1. 禁用证书：在IoT Core控制台或API把设备的证书状态从ACTIVE改成INACTIVE，这是最快的方式，几秒内设备就失去所有权限；
2. 更新IoT Policy：如果只是怀疑这台设备的某个功能被滥用，可以把它的Policy临时收紧，只保留下线通知类Topic的权限；
3. 移除Thing与证书的映射关系：这是最彻底的方案，相当于注销设备身份，即使证书还在也无法通过认证。

利用EventBridge可以监听设备失陷告警，比如Device Defender发现异常行为时，自动触发Lambda调用UpdateCertificate把证书设为INACTIVE，同时发通知给现场运维。这样从检测到隔离可以做到分钟级。

6.4 一次异常心跳的排查过程

某客户部署了一批共享单车锁，设备每30秒上报一次GPS和电量。一个月后Device Defender告警说其中有台车的心跳频率变成了每2秒一次，流量翻了15倍。我们一开始以为是设备固件bug，后来用IoT Core的日志定位到该设备Topic出现了多个不正常的clientId，而且这些连接使用的证书属于两台不同的设备。

进一步追查发现，攻击者通过网络攻击拿下了某台设备，提取了证书，然后在一个模拟器里伪造了大量连接，想蹭运营商的流量套餐做跳板。处置时我们直接吊销了那台失陷设备的证书，并给IoT Core加上“单证书最大并发连接数限制”，把类似风险一次性堵住。

IoT场景排查跟Web完全不同，关键证据基本都在IoT Core的连接事件和消息记录里。所以这套体系的日志归集也要把IoT Core的CloudWatch Logs纳入进来，不要只顾着传统Web日志。

7. 运营闭环：告警降噪、编排响应与成本控制

7.1 告警分级：不是每条告警都值得半夜爬起来

体系跑起来之后，最大的问题变成了告警疲劳。GuardDuty哪怕在静默网络里每天都会产生大量Low级别的发现，如果不做分级处置，运营人员很快就会麻木，真正的严重告警反而没人理。

我落地时的分级策略是：

• Critical：可能已经在被入侵，比如UnauthorizedAccess:EC2/SSHBruteForce、CryptoCurrency:Runtime/BitcoinTool，要求15分钟内响应；
• High：有明显恶意行为，比如Recon:EC2/PortProbe、S3公开读策略变更，要求2小时内核查；
• Medium：需要人工判断，比如某个IAM用户在新设备登录、GuardDuty检测到可疑DNS请求，要求24小时内核查；
• Low：进入周报汇总，不实时打扰，比如Config的某个合规项漂移。

Security Hub里可以用自定义Insight来分组，再把每个级别的发现对应到不同的SNS Topic。配合上一套Playbook，Critical级别的告警能做到自动处理，真正需要人肉的告警只剩一小部分。

7.2 三个可以照抄的Playbook

自动化Playbook我建议先从三个最常见的场景做起，足够覆盖80%的应急处置需求。

第一个是“隔离异常EC2实例”。当GuardDuty发现某台实例正在对外扫描或连接矿池，Lambda会把实例的Security Group替换为隔离组，并停止它绑定的EIP，同时给运维群发消息。注意隔离组一定要定义成“拒绝所有入站和出站”的安全组，否则隔离不彻底。

第二个是“吊销泄露的IAM凭证”。CloudTrail如果发现某个AccessKey从陌生IP段调用API，并且该Key有高权限策略，EventBridge触发Lambda调用DeleteAccessKey并禁用对应的IAM用户登录。这个动作很激进，所以我在Lambda里加了条件：只处理从未在历史中见过的IP来源，并且在执行前发一条等待审批的企微消息。

第三个是“封禁恶意IP”。这个是WAF场景最常用的，把GuardDuty或WAF发现的恶意IP自动写入某个WAF IP Set，全局封禁24小时。注意设置IP Set的过期清理机制，可以用EventBridge定时触发Lambda，把超过24小时的IP条目移除，避免误伤正常用户。

7.3 成本控制经验：ASG归零不等于不扣费

很多人建安全体系时忽略了成本，结果月度账单比预期高出两三倍。这里我想重点说一个热搜问题：ASG的desired设为0以后，还会扣费吗？

答案是要分两部分看。desired为0之后，Auto Scaling会终止所有由它管理的EC2实例，实例本身的计算费用确实停了。但如果没有同时处理下面这些资源，账单还是会继续走：

• 实例绑定的弹性公网IP，只要是“已分配但未绑定实例”的状态，按小时收费；
• NAT网关按小时和流量计费，跟EC2是否运行无关；
• 负载均衡器（ALB/NLB）也是按小时计费，实例停了它还在跑；
• EBS快照按存储空间收费，而且快照不支持增量覆盖，删除实例不代表快照被清；
• CloudTrail和Config的记录和规则评估也有费用，尤其配置了数据事件后日志量很大。

所以我的习惯是：在安全运营的成本控制里加一条“基建清单”自动化，每天定时检查是否有未关联的EIP、闲置的NAT网关、以及超过30天的EBS快照，发现就直接发告警到成本群。安全体系不能成为账单炸弹，否则老板第二天就让你拆了它。

7.4 我日常的巡检习惯

最后分享几个我一直在用的日常巡检动作，算是这套体系的“保养指南”。

每天早上的第一件事，我只看Security Hub的Critical和High发现，数量超过5条才会翻细节。重点看那些带有CryptoCurrency或UnauthorizedAccess关键词的告警，这两个类型一出现基本是正在进行的入侵。

每周会做一次Config的合规快照导出，看看哪些资源漂移了，比如有人手动改掉了安全组或者删除了CloudTrail的Bucket Policy。绝大多数的配置漂移其实是开发自己图方便，但必须及时纠正，不然安全基线形同虚设。

每月用Athena跑一遍CloudTrail日志，梳理出所有root用户和长期AccessKey的使用情况，把超过90天没使用的key直接轮换。这个动作能明确定期清理“永久凭证”，是防止下次出现access key泄露最有效的一招。

这套体系完整跑下来之后，我最深的体感是：安全运营不是买工具，而是把“检测、通知、响应、修复、复盘”每个环节都用AWS原生的Lambda和EventBridge串起来，让工具之间自动协作，而不是让运维的同事每天给工具当搬运工。你也不需要一次把所有场景全部建成，先打通一条最核心的闭环，再逐步扩展到Web/APP/IoT全场景，完全来得及。