不懂就承认你接手过一个亚马逊云账号，大概率遇到过这种情况：半夜告警响了，你打开 CloudWatch 一看，发现某台 EC2 的 CPU 飙到 100%，但你这套系统的告警规则明明配的是“状态检查失败”才报警，根本没配 CPU 突增的规则——那这条告警哪来的？再点进去才发现，是 CloudWatch Events 的默认事件把 EC2 的 stopped 状态推给了 SNS，而 SNS 又绑了一个“全量通知”的订阅。而真正该出现的 CloudWatch Logs 里的业务日志报错，反而因为日志组没配指标过滤器，安静得像什么都没发生过。
这就是 Logs 和 Events 这两兄弟最典型的混用现场：你以为你配的是日志告警，实际上跑的是事件推送；你以为事件能帮你汇总日志内容，实际上 Events 里连一行日志正文都看不到。
这个标题是我在给几个代理商客户做账号巡检时被反复问到的主题。很多代理商朋友对 Logs 和 Events 的功能边界模糊，导致报警轰炸、消息漏报、成本失控、排查链路断裂这些事反复发生。这篇就把两者的区别、适用边界、以及怎么把它们串成一条完整的可观测链路讲清楚。
1. 一个记录一个传递：Logs 与 Events 的本质定位
先把最基础的东西说透。CloudWatch 这个服务名义上是一个监控服务，但它内部其实是几套完全不同的子系统的集合：指标（Metrics）、日志（Logs）、告警（Alarms）、事件（Events/EventBridge）、以及后面的 Synthetics、RUM 之类。很多人把它们混为一谈，是因为控制台入口都叫 CloudWatch，但底层设计逻辑完全不同。
CloudWatch Logs 的本质是一个日志聚合与存储系统。
它的职责很简单：把分散在多台 EC2、多个容器、多个 Lambda、多个 RDS 实例上的文本日志，通过 agent 或 SDK 收拢到一个中心化的地方，然后提供查询、过滤、存储、告警能力。你可以在 Logs 里看到一行行的日志原文，可以用 CloudWatch Logs Insights 写查询语句去搜关键字，可以给某个日志组设置保存天数，也可以基于日志内容里的关键字创建指标过滤器，进而触发告警。
注意“基于日志内容”这几个字，这是 Logs 的核心能力：它看的是内容本身。比如你的应用往日志里打了一行 ERROR: payment timeout，Logs 能感知到这里面有 ERROR 这个字符串，能统计过去五分钟内出现这个字符串的次数，然后超过阈值触发告警。
CloudWatch Events（以及它的升级版 Amazon EventBridge）的本质是一个事件路由总线。
它的职责是把 AWS 云上发生的“状态变化”以结构化 JSON 的形式转发给目标端。这里的“事件”不是一个文本字符串，而是一个包含了时间、来源、资源 ARN、事件名、触发细节的 JSON 对象。比如 EC2 从 running 变成 stopped、RDS 发生了一次自动快照、IAM 用户创建了一个 AccessKey、CodePipeline 某个阶段失败了——这些都属于“状态变化事件”，Events 要做的就是感知到这些变化，然后按照你预设的规则把他路由到 SNS、Lambda、SQS、Step Functions 等目标。
用一个不太准确但容易记的类比：Logs 像是一个企业里所有员工每天写的日报，内容是什么都有，需要你自己去翻、去搜；Events 像是一个前台广播系统，它不关心员工具体写什么，只关心谁进了门、谁出了门、谁按了哪个按钮，然后立刻通知相关人员。
这两套东西从一开始就不是为同一件事设计的。Logs 做的是“事后追溯与内容分析”，Events 做的是“实时感知与自动响应”。
如果你要监控的是“应用打印了什么”，走 Logs；如果你要监控的是“云资源发生了什么状态变更”，走 Events。这个基础认知建立不起来，后面所有的规则配置都会变形。
我刚接触亚马逊云的时候，以为 CloudWatch Events 就是把 CloudWatch Logs 里的日志“事件化”，类似把日志流推到 Kinesis 那种感觉，结果配完之后发现 Events 规则根本收不到日志内容，后来才意识到它俩的触发源完全不同，一个是 AWS 服务状态，一个是应用日志文本。这个弯如果绕不过去，后面会一直别扭。
组合使用的核心也建立在这个本质上：Logs 负责把“发生了什么内容”说清楚，Events 负责把“需要谁来处理”这个信号传出去，而两者之间通过告警、通过订阅、通过指标过滤器来衔接。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 容易让人懵的边界地带：日志组、事件模式与资源状态
很多代理商朋友在给客户做方案时被问住，通常不是卡在 Logs 和 Events 本身的功能上，而是卡在几个容易被官方文档带偏的交叉地带。把这些边界理清楚，比背概念有用得多。
2.1 先认清日志流（Log Stream）和日志事件（Log Event）
CloudWatch Logs 内部还有一组“事件”概念，叫 Log Event，即一条独立的日志记录。一个日志流是来自同一个来源（比如某个 EC2 实例上的某个 agent 配置）的一系列日志事件的集合，多个日志流组成一个日志组（Log Group）。
这里有个极易混淆的点：CloudWatch Logs Insights 查询结果里，你看到每一行都叫 “event”，但这个 event 是“日志事件”，不是 CloudWatch Events 里的“事件”。如果一个新手在代理商群里问“CloudWatch 事件里能搜日志吗”，大概率是因为他看到了 Insights 里的事件字段，误以为 Events 服务也能干这事。
所以代理商在给客户培训或交付文档时，建议把三个名词分开：Log Events（日志条目）、CloudWatch Events（事件总线上的事件）、EventBridge 事件（Events 升级版的规则事件）。如果不分开，后续设计监控方案时一定出乱子。
2.2 Events 规则匹配的是“事件模式”，不是日志关键字
CloudWatch Events 规则的核心是事件模式（Event Pattern），它是一段 JSON，用来描述你要匹配什么样的 AWS 服务事件。
举例：
json复制{
"source": ["aws.ec2"],
"detail-type": ["EC2 Instance State-change Notification"],
"detail": {
"state": ["stopped", "terminated"]
}
}
这个规则的含义是：只要 EC2 实例状态变为 stopped 或 terminated，这条事件就会触发，然后路由到你配置的目标。
注意看，这里匹配的是 source、detail-type、detail 里的结构化字段，完全没有“关键字”“日志正文”“ERROR 出现次数”这类概念。Events 根本不看日志内容，也不关心你的应用打印了什么。它只关心 AWS 服务发出的状态通知。
而 Logs 的指标过滤器长这样：
code复制[$ERROR] ERROR
这段过滤器会去日志组里每一条日志文本中匹配字符串 ERROR，然后计数作为指标值。这是两套完全不同的匹配机制。
在给客户设计时，我见过最典型的一个错误：客户想把 ECS 任务启动失败的原因作为告警依据，他去 Events 里创建规则，选了 ECS 的 TaskStateChange 事件，然后给 SNS 发消息。结果消息确实收到了，但里面只有 JSON 状态码和 reason 摘要，没有容器里具体的日志报错，他还得再去 Logs 里查一遍才能定位问题。这就是只用了 Events 没结合 Logs 的结果——能感知到失败，看不到失败原因。
反过来也有个错误：客户把应用日志推到了 Logs，然后订阅了一个 Lambda 专门去解析日志里的 JSON，判断有没有异常，再调用 SNS 告警。这套方案可行，但本质上是用 Logs + Lambda 去模拟一个事件触发链路，完全没有必要。你完全可以直接用 Logs 的 metric filter 生成错误次数指标，再基于指标创建告警，或者通过 Logs 订阅将其送到 Lambda 做更复杂的处理。
2.3 事件总线（EventBridge）与规则的“丢事件”问题
2020 年以后亚马逊云把 CloudWatch Events 的功能演进为 Amazon EventBridge，控制台里的名称也换了。但老客户的历史规则还在 CloudWatch Events 里显示，新规则则可以直接在 EventBridge 里建。功能大同小异，EventBridge 多了与第三方 SaaS 集成的能力，比如把事件推给 Datadog、Zendesk 之类。
在实际使用里，Events 有一个让代理商非常头疼的问题：默认情况下，它不做可靠投递。也就是说如果规则匹配到了事件，但目标 Lambda 调用失败，或者 SNS 发送失败，这个事件可能直接丢失。除非你显式配置了死信队列（DLQ）。这个特性在文档里写得很清楚，但几乎没人看。我们在给客户做方案时，只要涉及 Events 推送，一定会加一个 DLQ 指向 SQS，然后配置云监控告警来看 DLQ 里有没有消息堆积。
为什么这个点对代理商特别重要？因为很多代理商是中间人，客户侧如果某些 AWS 服务的权限边界配置得不合理，Events 规则会经常遇到 “AccessDenied” 导致投递失败。如果没配 DLQ，你连失败记录都找不到，客户只会说“收不到通知”，然后你去排查了半天，最后才发现是目标 Lambda 的执行角色没有 resource-based policy 允许 Events 调用它。这种问题在多账号环境、用 CloudFormation/Control Tower 搭建的 Landing Zone 里尤其常见。
3. 把 Logs 和 Events 串成链路：三个高频组合实战
单独理解 Logs 和 Events 很简单，真正考验代理商能力的是把它们组合成一套“发现问题→感知变化→自动处理→闭环追溯”的链路。这里我拆解三个在亚马逊云客户群里出现频率最高的组合场景，每个都附上了配置要点和为什么这么配的分析。
3.1 场景一：ECS 任务反复失败，既要知道“失败”，也要看到“原因”
这是容器化客户最头疼的问题之一。ECS 任务启动失败可能来自镜像拉取失败、资源不足、健康检查不通过、环境变量配置错误等多种原因。Events 能告诉你“任务失败了”，但很难直接告诉你“为什么失败”；Logs 里有详细原因，但缺一个主动通知你的机制。
组合方案：
- 用 CloudWatch Events 捕获 ECS 的
TaskStateChange事件，筛选出lastStatus为STOPPED且stopCode不是EssentialContainerExited的正常退出任务，然后触发 SNS 告警。 - 同时，ECS 容器标准输出会被 agent 自动推送到 Logs 的
/aws/ecs/containerinsights/{cluster-name}日志组。你在 Logs Insights 里写一条查询，按 task ID 过滤刚才失败任务的日志。
sql复制fields @timestamp, @message
| filter @logStream like /task-id/
| filter @message like /(?i)(error|exception|failed)/
| sort @timestamp desc
| limit 50
为什么这么分工？因为 ECS 任务失败这件事本身是“状态变化”，用 Events 天经地义，而且事件里还带着任务级别的时间戳、期望状态、最后状态，这些信息可以直接用于告警文案拼装。而失败的具体原因，比如 “no space left on device” 还是 “pull access denied”，只有容器日志里才有，走 Logs 是唯一靠谱的方式。
这个场景里最容易出问题的地方是：ECS 事件里 stopCode 字段的含义。很多客户把这当作任务是否异常退出的唯一判断，忽略了 EssentialContainerExited ——如果容器里的主进程正常退出（例如定时任务跑完就退出），ECS 也会发 TaskStateChange 事件，但这不是故障。如果你不加这个过滤条件，运维群会被正常任务的退出通知刷屏。
3.2 场景二：用 Logs 指标过滤器 + CloudWatch 告警做业务级监控
业务级监控的场景通常长这样：你在 API Gateway 后面挂了 Lambda 或 ECS 服务，客户想知道“过去 5 分钟里有多少请求返回了 500”，或者“支付回调超时出现多少次”，然后超过阈值就报警。
这类监控不建议用 Events，因为 API Gateway 不会主动生成“500 数量过多”的 Events 事件，它只会生成关于 API 执行状态的 AccessLog，写到一个 Logs 日志组里。你要做的其实是对日志内容做聚合统计。
步骤拆解：
- 确认 API Gateway 的日志推到了
/aws/apigateway/{api-id}日志组。 - 创建指标过滤器，匹配状态码为 500 的日志记录。API Gateway 访问日志默认格式里带了
responseLatency、status等字段，如果是 JSON 格式，过滤器可以写成：
code复制{ $.status = "500" }
如果是默认的 CLF 格式，写一个简单字符串匹配：
code复制" 500 "
注意这个过滤器必须用双引号包住空格，避免匹配到 5000 这种状态码。
- 创建一个以该指标为数据源的告警，设置阈值为连续 2 个周期内每分钟 ≥ 5 次，触发 SNS 告警。
这套方案的好处在于：你完全不用担心 Logs 和 Events 混淆，核心逻辑就是“对内容计数、对计数告警”。不过有个细节代理商要重点提醒客户：指标过滤器的过滤是增量计算的，不是回溯扫描。也就是说，过滤器创建之前已经存在于日志组里的历史日志不会进入指标统计，它只统计创建之后的新日志。这跟 Logs Insights 查询（可以扫全量）完全是两回事。很多客户创建完过滤器后，发现告警没触发，怀疑是过滤器没用，其实是把“指标统计”和“日志查询”的功能边界搞混了。
另外，指标过滤器的配额上限是每个日志组 100 个，对于高并发业务往往会不够用。这时建议把多个过滤条件合并成一个正则，产出多个指标值，而不是建几十个过滤器。我在实际项目中曾帮一个电商客户把 20 个过滤器压缩成 3 个复合正则，成本和管理复杂度都下来了。
3.3 场景三：安全合规场景里，Logs 是“证据”，Events 是“信号”
安全类客户往往更依赖多账号架构下的审计与合规。AWS CloudTrail 会记录账号里的 API 调用事件，这些事件可以投递到 CloudWatch Logs 的日志组，也可以直接作为 Events 规则的数据源。这时候 Logs 和 Events 的职责要分得非常清晰。
- CloudTrail 日志投递到 CloudWatch Logs：用于事后审计、长期归档、违规操作追溯。这里的日志是完整的 JSON 记录，包含 userIdentity、sourceIPAddress、eventName、requestParameters，是安全事件的“证据链”。
- CloudWatch Events 规则匹配 CloudTrail 事件：用于实时感知高危操作。比如只要检测到
ec2:AuthorizeSecurityGroupIngress，立刻触发 Lambda 去检查是否开放了 0.0.0.0/0 的 22 端口，如果有，自动移除规则或发通知。
这个场景里你用到的可能是同一个 CloudTrail 事件源，但两条链路各干各的，Logs 链路做记录留存，Events 链路做实时干预，不能混。如果你试图在 Logs 里做实时告警，指标过滤器的延迟和误报会很难受；如果你试图用 Events 做长期留存，会一下子收到海量事件且无法回溯，成本高到你怀疑人生。
我当时帮客户做的一个安全方案里，Events 规则配了五条，分别覆盖 IAM 高危操作、安全组变更、S3 存储桶策略变更、KMS Key 删除、Root 账号登录。每条规则的目标都是一个独立的 SNS Topic，方便客户按严重级别做不同的订阅策略。而 CloudTrail 日志则统一进 Logs 日志组，保存 365 天，每天凌晨跑一次 Athena 查询，把前一天的异常操作汇总发到运维邮箱。
配置安全事件的 Events 规则时有一点容易被忽略：事件模式里 detail 字段的值，有些是字符串，有些是数组。比如 CloudTrail 的 eventName 字段，在 detail 里是字符串，但 userIdentity.type 可能因不同类型而缺失，导致规则匹配不到。我在给客户调试时，建议先用 EventBridge 的 “Event Bus → 规则 → 测试” 功能手动构造一个事件样例，把字段结构看清楚了再写匹配模式，不要凭记忆写 JSON。
4. 正式配置实操：从零搭建一条“日志异常 → 事件驱动 → 自动化修复”的完整链路
理论说再多，不如直接动手跑通一条链路。这一节我按实际交付的标准，拆解一个完整可落地的配置过程。目标是：应用在 EC2 上通过 CloudWatch Agent 输出日志，日志中一旦出现 PAYMENT_TIMEOUT 关键字，且 5 分钟内出现 10 次，就触发告警，同时自动调用 Lambda 重启支付服务并通知运维群。
这条链路混合了 Logs 和 Events 的各自优势，是代理商客户群中非常典型的一个自动化运维场景。
4.1 第一步：确认日志顺利进入 CloudWatch Logs
首先确认 EC2 上安装了 CloudWatch Agent，日志路径通常是 /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl，配置里指定要采集的日志文件路径和日志组名称。
json复制{
"logs": {
"logs_collected": {
"files": {
"collect_list": [
{
"file_path": "/var/log/myapp/payment.log",
"log_group_name": "/myapp/payment",
"log_stream_name": "{instance_id}",
"timezone": "UTC"
}
]
}
}
}
}
配置完成后，用 amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json 更新配置。然后在控制台进到 CloudWatch Logs 的 /myapp/payment 日志组，确认能看到日志流。
这一步经常踩的坑是权限问题。给 EC2 的 IAM 角色必须包含 CloudWatch Logs 的写权限：
json复制{
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "*"
}
另外，时区配置也很重要。如果你的应用打印的是本地时间，而 Agent 采集时按 UTC 解析，那你在 Logs Insights 里按 @timestamp 排序查日志会看到时间偏移。建议应用统一打印 UTC 时间，或至少 Agent 配置和日志格式保持一致。
4.2 第二步：创建指标过滤器，把“日志关键词”变成“可告警指标”
进入 /myapp/payment 日志组，创建指标过滤器：
- 过滤模式：
PAYMENT_TIMEOUT - 指标命名空间：
MyApp/Custom - 指标名称：
PaymentTimeoutCount
这个过滤器会统计每条日志里是否包含 PAYMENT_TIMEOUT 字符串。默认情况下，每一条匹配的日志记录增加 1，如果同一行里出现了 3 次，指标值会按出现次数累加。如果你希望“一行只算一次”，可以在过滤器语法里用 { $.event = "PAYMENT_TIMEOUT" }，前提是日志是 JSON 格式且字段可解析。
4.3 第三步：基于指标创建 CloudWatch 告警，告警动作触发 SNS
在 CloudWatch 告警控制台创建告警：
- 选择指标：
MyApp/Custom > PaymentTimeoutCount - 统计周期：1 分钟
- 阈值：连续 5 个周期内，每分钟 PaymentTimeoutCount >= 10
- 触发动作：发送到 SNS Topic
myapp-payment-alert
这个告警触发后，SNS 会发消息。但这里有个问题：告警触发只能通知人，不能直接执行修复动作。所以 SNS 的订阅列表里，除了运维邮箱，还要加一个 Lambda 订阅，让 SNS 消息作为 Lambda 的输入事件，由 Lambda 执行后续动作。
4.4 第四步：Events 规则捕获“自动恢复任务”的状态事件，形成闭环
上面用告警触发了 Lambda，Lambda 去重启了支付服务。但我们需要知道重启是否成功。这一步用 CloudWatch Events 规则捕获 ECS 或 EC2 服务恢复的状态变化，然后发送通知。
如果支付服务跑在 EC2 上并由 Systemd 托管，重启操作可能是 SSH 进去执行 systemctl restart payment。这个操作没法直接产生 AWS 事件，所以你不会在 Events 里看到“支付服务重启成功”。这时候可以让 Lambda 在重启成功后主动调用一个 SNS Topic，发一条“payment service restart done”的消息。这条消息本身不是云事件，但它是你自定义链路里的“结果事件”。
如果支付服务跑在 ECS 上，事情就顺理成章了：你只需要让 Lambda 更新 ECS 服务（比如 aws ecs update-service --force-new-deployment），然后 Events 规则会捕获 ECS 的 SERVICE_DEPLOYMENT_COMPLETED 事件，代表新部署完成。
配置示例：
json复制{
"source": ["aws.ecs"],
"detail-type": ["ECS Deployment State Change"],
"detail": {
"eventType": ["INFO"],
"deploymentStatus": ["PRIMARY_DEPLOYMENT_COMPLETED"]
}
}
这个规则的目标可以是一个 SNS Topic，直接通知运维群“支付服务已自动重启完成”。此时，你从“日志异常 → 指标告警 → 自动化修复 → 修复结果通知”的整条链路就闭环了。
为什么要这么设计？因为这里每一步都有各自最合适的工具：日志内容分析用 Logs，获取状态变化用 Events，执行动作用 Lambda 和 SNS，整条链路既不过度复杂，也没有把任何一步的职责放错位置。
你在实际交付时，建议把这条链路的架构图画成一张简单的时序图给客户。注意不要用 mermaid，画图可以用 draw.io 或直接在文档里写文字描述。
5. 容易翻车的细节与常见坑位排查
这些坑基本都是我们在多个客户项目里实际摸出来的，分享给代理商朋友，有些确实非常隐蔽，排查成本很高。
5.1 “docker logs --since --until 不生效”类问题，本质是日志驱动缓冲
有代理商反映客户在 ECS on EC2 或自建 Docker 上执行 docker logs --since 1h --until 2h，返回结果不对。实际上这跟 CloudWatch Logs 没有直接关系，但它提示了一个重要原则：任何日志采集系统都只能拿到已经落盘或已经推送的日志，拿不到还没产生的日志。Docker 的 json-file 驱动会做日志轮转，如果 log rotation 配置过小，旧日志被清掉，--since 就查不到那些被清理的日志。CloudWatch Logs 也类似，如果 Agent 采集失败、日志组保存期限太短、或者网络抖动导致日志堆积在 agent 本地缓冲没有及时 flush，查询就会漏数据。
排查思路是：先看 Agent 本地缓存目录 /var/log/amazon/amazon-cloudwatch-agent/ 里的日志，确认有没有推送失败的记录；再查日志组里数据的时间分布，确定是时间区段缺失还是全量缺失，最后再判断是 Agent 性能瓶颈、磁盘空间不足还是权限突然失效。
5.2 “AMD external events utility” 引发的联想：硬件事件同样走 Events
搜索热词里出现 “amd external events utility”，这一般指 AMD 平台上的事件工具。在 AWS 上，EC2 实例会定期收到底层维护事件，这些事件对客户是透明的。AWS 会通过 Health 事件（aws.health source）推送到 EventBridge，这些事件与 AMD 平台没有直接挂钩，但它的机制和“外部事件”这个概念很像：Events 的职责就是接收外部或内部产生的事件，然后按规则转发，它不是日志分析工具，也不是可查询的历史数据库。
如果你在跟客户交流时被问到“AMD external events utility 是什么”，可以这样解释：它是 AMD 平台提供的一个工具，用于查看系统级事件（如温度、电压、错误注入等），类似一个硬件事件查看器。这在本地物理服务器运维里很常见，但在 AWS 上，你不需要关心底层硬件事件，AWS 会替你做硬件健康维护，你只需要关注 CloudWatch Health 事件即可。
这个热词对理解 Logs 和 Events 的启发是：几乎所有“事件”系统的本质都类似——产生事件、路由事件、消费事件，而 Logs 系统则完全不同，它关注的是文本内容的留存与分析。 理解了这一点，哪怕以后碰到别的平台、别的事件机制（比如 Kubernetes Events、系统日志），思路也不会乱。
5.3 Events 规则的“静默丢失”与 DLQ 配置
前面提过一次，这里再强调一遍。CloudWatch Events/EventBridge 规则的触发是以“尽力投递”模式工作的，不保证百分百送达。目标端失败，比如 Lambda 并发超限、SNS Topic 权限缺失、SQS 队列不存在，都会导致事件丢失，且默认没有可见记录。
解决办法：
- 给规则添加死信队列：
json复制{
"DeadLetterConfig": {
"Arn": "arn:aws:sqs:us-east-1:123456789012:my-event-dlq"
},
"Targets": [
{
"Id": "MyLambdaTarget",
"Arn": "arn:aws:lambda:us-east-1:123456789012:function:my-function"
}
]
}
- 给 DLQ 本身配置一条告警，基于
ApproximateNumberOfMessagesVisible指标，只要大于 0，就发 SNS 通知。
这个配置在 CloudFormation/Terraform 模板里容易被忽略，因为默认模板生成的 Events 规则目标往往不带 DLQ。我建议在客户的模板里直接把 DLQ 作为标准件加上，不要省。
5.4 权限错误“AccessDenied”排查
Events 规则调用 Lambda 是一个“服务间调用”场景。Lambda 的资源策略必须显式允许 CloudWatch Events 服务主体 events.amazonaws.com 调用。如果漏配，规则会显示“触发成功”但 Lambda 从未执行。
排查方式：打开 Lambda 控制台的 “Configuration → Permissions → Resource-based policy”，确认存在允许 events.amazonaws.com 调用 Function 的策略。如果没有，添加：
json复制{
"Version": "2012-10-17",
"Id": "default",
"Statement": [
{
"Sid": "AllowEventsToInvokeLambda",
"Effect": "Allow",
"Principal": {
"Service": "events.amazonaws.com"
},
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-1:123456789012:function:my-function"
}
]
}
如果是自定义事件总线（Custom Event Bus）跨账号投递，还需要额外的基于事件的权限配置，这种多账号场景下最容易出权限纠缠问题。代理商在多个账号间做集中监控时，建议一开始就规划好跨账号的权限模型，不要等事件丢了再找原因。
5.5 成本问题：Logs 的存储与检索成本比想象力高
最后聊一个代理商一定要给客户提前打预防针的点：CloudWatch Logs 的成本。很多人以为 Logs 只是“存日志”，流式推送的 PutLogEvents、存储费、Insights 查询扫描的数据量、指标过滤器的计算量都要花钱。特别是有大流量访问日志的业务，一个月日志量可能达几百 GB，如果客户选择保存 365 天，成本会高到惊人。
成本优化建议：
- 根据业务需求设置保存周期，比如访问日志存 7 天，错误日志存 30 天，审计日志存 365 天。
- 历史日志归档到 S3（通过 Logs 的导出任务或 S3 订阅），用 S3 Glacier 做长期冷存储。
- 把 Info/Debug 级别的日志直接过滤掉，不推送到 CloudWatch Logs，只在本地文件系统保留，必要时再手动排查。可以用 Agent 的
log_level配置或应用侧日志框架处理。
Events 的成本相对低，但规则数量多、事件量大的时候也不是免费午餐。EventBridge 按事件数量计费，默认每个月免费额度很少，大量 EC2 状态变化、CloudTrail 事件，一个月几千万条很正常。建议只在 Events 规则里精确筛选事件模式，不要用 "prefix": "" 这种匹配全部的模式。
6. 我日常面对这三个概念时的几个习惯
很多代理商朋友问我，有没有什么判断快速对标的方法，能在一个项目里马上判断该用 Logs 还是 Events。我一般给三个判断句子：
- 如果现在的需求是“去看某段时间、某个服务、某个关键字出现了多少次”，就是Logs。
- 如果需求是“当某个资源状态变化的时候，马上通知我或者自动执行某个动作”，就是Events。
- 如果需求是“既要知道状态变化，也要看到具体原因”，就是你俩结合，分两段设计。
这三个句子虽然简单，但在售前设计、客户答疑、方案评审这些场景里非常顶用。客户说不清需求的时候，你用这三个方向去问一轮，基本能把需求边界收敛出来。
在我经手的代理商项目中，一个容易让客户信任你的细节是：交付文档里明确写出“哪条告警是日志内容触发的，哪条告警是事件状态触发的”。很多客户收到告警不知道出处，是因为他们看不到这些信息。你只要把告警的 source 标注清楚，甚至直接在 SNS 的 Subject 里写上 [Logs-Alert] 或 [Event-Alert] 前缀，整个运维团队会立刻受益。
另外建议代理商朋友在每次新客户环境初始化时，把 CloudWatch Logs 和 Events 的默认配置做成一套标准模板，覆盖至少这两个场景：基础 EC2 状态变化通知，以及关键应用日志错误告警。这套模板沉淀下来之后，新客户的搭建时间能从两天压缩到半天，而且稳定性也更有保障。
回到开头那个场景，如果当时客户用了我这套思路，告警其实应该是这样发出去的：Logs 侧的业务报错触发“业务异常”告警，Events 侧的 EC2 状态变化触发“资源变更”通知，两条线互相独立，运维看标题就知道该谁处理，而不是半夜起来面对一条莫名的实例停止通知干瞪眼。这个体验差异，就是理清 CloudWatch Logs 和 Events 区别的价值所在。