[解决方案] 使用 CloudWatch Alarms 和 Lambda 捕获异常流量

<!-- AI_TASK_START: AI标题翻译 --> [解决方案] 使用 CloudWatch Alarms 和 Lambda 捕获异常流量 <!-- AI_TASK_END: AI标题翻译 --> <!-- AI_TASK_START: AI竞争分析 --> # 解决方案分析 ## 解决方案概述 该解决方案旨在解决 **AWS Transit Gateway** 网络流量监控中的一个核心痛点：持续开启 **Flow Logs** 会产生高昂的存储和处理成本，而手动在异常发生时开启又往往为时已晚。方案提出了一种 **自动化、事件驱动** 的方法，仅在检测到网络流量异常时动态启用 Flow Logs，并在流量恢复正常后自动禁用，从而在成本效益和问题诊断能力之间取得最佳平衡。 其技术原理是利用 **Amazon CloudWatch Anomaly Detection** 功能，为 Transit Gateway 的流量指标（如 `BytesIn`）自动学习并建立一个动态的“正常”流量基线范围（即“Band”）。当实际流量超出这个基线时，**CloudWatch Alarm** 会被触发。该告警会调用一个 **AWS Lambda** 函数，该函数通过 AWS API 为产生异常的特定 Transit Gateway Attachment 动态启用 Flow Logs，并将日志数据发送到 **Amazon S3** 存储桶。当流量回落到正常范围，告警状态恢复，Lambda 函数会再次被触发以禁用 Flow Logs，从而实现智能化的按需日志采集。 ## 实施步骤 1. **配置监控与告警** - 利用 Transit Gateway 默认推送到 CloudWatch 的网络指标（如 `BytesIn` 和 `BytesOut`）。 - 为目标指标创建一个 CloudWatch 告警，并启用 **Anomaly Detection** 功能。CloudWatch 会自动学习历史数据，生成一个代表正常流量范围的动态“Band”。 2. **优化告警逻辑以避免误报** - 为解决低流量时微小波动导致的“告警疲劳”问题，方案推荐使用 **单个告警结合数学表达式**。 - 告警规则设置为一个逻辑 `AND` 条件：`实际流量 > 预设的最低阈值` **并且** `流量超出 Anomaly Detection 的正常范围`。 - 这种方式比使用复合告警（Composite Alarm）与抑制告警（Suppression Alarm）更为简洁，避免了告警控制台出现不必要的“告警中”状态。 3. **创建自动化响应函数** - 编写一个 **AWS Lambda** 函数（即 `Alarm Handler`），作为 CloudWatch 告警状态变化（从 `OK` 到 `ALARM` 或反之）的目标。 - Lambda 函数需具备幂等性，能够处理并发和重复调用。代码中应包含完整的 `try/except` 错误处理，并通过 **Amazon SNS** 发送通知。 4. **执行动态日志开关** - 当告警触发 Lambda 时，CloudWatch 会在事件负载中传递告警的详细信息，包括触发告警的 Transit Gateway 和 Attachment ID。 - Lambda 函数解析这些信息，并调用相应的 AWS API： - 当告警状态变为 `ALARM` 时，为该 Attachment **启用** Flow Logs。 - 当告警状态恢复为 `OK` 时，**禁用** Flow Logs。 5. **大规模自动化部署** - **方法一（定时轮询）**: 使用一个由 **Amazon EventBridge** 定时触发的 Lambda 函数，定期扫描所有 Transit Gateway Attachments 和已配置的告警，自动创建缺失的告警或删除多余的告警。 - **方法二（事件驱动）**: 集成 **AWS Network Manager**。利用其拓扑变更事件，通过 EventBridge 实时触发 Lambda，在新附件创建或删除时即时更新告警配置。此方法更高效，尤其适用于全球化、多区域的大型网络。 ## 方案客户价值 - **显著的成本优化**: 通过 **按需、动态启用** Flow Logs，替代了持续运行所带来的高昂处理和存储成本。实现了从“始终在线”到“事件驱动”的成本模式转变。 - **提升运维效率与响应速度**: 自动化了从异常检测到数据采集的全过程，消除了人工干预的延迟。确保在流量异常发生时 **第一时间捕获** 关键诊断数据，而不是事后补救。 - **精准告警，降低干扰**: 采用 **组合逻辑告警** 策略，有效过滤了低流量基数下的正常波动，避免了告警风暴和运维人员的“告警疲劳”，使团队能聚焦于真实问题。 - **大规模自动化管理**: 提供了基于 **CloudFormation** 的 IaC 部署模板，并支持两种自动化管理模式：定时轮询或与 **AWS Network Manager** 集成以实现事件驱动的实时配置，极大简化了在大型、多区域网络环境下的管理复杂性。 ## 涉及的相关产品 - **AWS Transit Gateway**: 解决方案的核心监控对象，作为云上网络的中心枢纽。 - **Amazon CloudWatch**: 提供 **Metrics** 监控、**Alarms** 告警及核心的 **Anomaly Detection** 智能基线功能。 - **AWS Lambda**: 作为事件驱动的计算服务，执行自动化启用/禁用 Flow Logs 的核心逻辑。 - **Amazon S3**: 用于存储按需捕获的 Flow Logs，以供后续分析。 - **Amazon EventBridge**: 用于定时触发或捕获 AWS Network Manager 的拓扑变更事件，以驱动自动化配置更新。 - **AWS Network Manager**: (可选，用于高级自动化) 集中管理全球网络，并提供拓扑变更事件源，实现更高效的自动化。 - **AWS CloudFormation**: 用于以基础设施即代码（IaC）的方式部署和管理整个解决方案。 - **Amazon SNS**: 用于在脚本触发或异常时向运维人员发送通知。 ## 技术评估 - **优势**: - **智能化与自适应**: CloudWatch Anomaly Detection 能够基于历史数据动态调整“正常”流量的基线，无需手动设置和维护静态阈值，能更好地适应业务流量的自然增长和季节性变化。 - **成本效益极高**: 方案的核心价值在于将昂贵的诊断功能从“常开”模式转变为“按需”模式，实现了网络可见性与成本控制的最佳平衡。 - **高度自动化与可扩展性**: 提供了从单个 Transit Gateway 到全球网络的完整自动化部署方案。特别是与 Network Manager 的集成，展示了事件驱动架构在网络运维自动化领域的先进性，实现了近乎实时的配置同步。 - **模式通用性强**: 该解决方案（检测->告警->Lambda响应）是一个通用框架，可轻松扩展至其他应用场景，如监控单个 **Amazon EC2** 实例并动态开关 VPC Flow Logs。 - **可能的限制**: - **异常检测学习周期**: Anomaly Detection 功能需要一定时间来学习流量模式并建立可靠的基线。在初始部署阶段或流量模式发生剧变后，其准确性可能暂时下降。 - **合法流量突变**: 对于业务本身具有高度突发性且无规律的场景（例如，大数据批处理、媒体直播等），Anomaly Detection 可能会将合法的业务高峰误判为异常，需要对告警阈值和逻辑进行精细调优。 <!-- AI_TASK_END: AI竞争分析 --> <!-- AI_TASK_START: AI全文翻译 --> # 使用 CloudWatch 警报和 Lambda 捕获异常流量 **原始链接:** [https://aws.amazon.com/blogs/networking-and-content-delivery/using-cloudwatch-alarms-and-lambda-to-catch-exceptional-traffic/](https://aws.amazon.com/blogs/networking-and-content-delivery/using-cloudwatch-alarms-and-lambda-to-catch-exceptional-traffic/) **发布时间:** 2025-08-18 **厂商:** AWS **类型:** BLOG --- 您是否曾想过，“为什么我的网络流量会突然激增？” [AWS Transit Gateway 流日志 (Flow Logs)](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-flow-logs.html) 是回答这个问题的绝佳资源，但持续运行它们可能会产生不必要的处理和存储成本。然而，如果按需运行流日志，当有人收到警报并启用流日志时，流量异常可能早已过去。 幸运的是，AWS 提供了多种工具来自动检测异常流量并能在流量增加期间启用流日志。本文将介绍一种实现方法，即使用 [Amazon CloudWatch 警报 (Alarms)](https://docs.aws.amazon.com/AmazonAmazon%20CloudWatch%0dCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 和 [AWS Lambda](https://aws.amazon.com/lambda/) ，并提供了在整个 AWS 网络中自动化部署的选项。本文中使用的 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 模板和 Python Lambda 代码现已在 [GitHub](https://github.com/aws-samples/sample-cw-lambda-exceptional-traffic) 上提供。 为实现这一目标，我们配置了以下步骤，如图 1 所示： 1. [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/) 默认会自动将指标 (metrics) 发送到 CloudWatch。我们可以选择要使用的指标，但 BytesIn 和 BytesOut 是最常用的。 2. 我们为这些指标创建一个 CloudWatch 警报，使用 [异常检测 (Anomaly Detection)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) 来确定正常水平，这在 CloudWatch 异常检测中被称为一个范围 (band)。 3. 当流量水平超过或返回正常范围时，警报状态会发生变化。警报被配置为每次发生这种情况时都调用我们的警报处理 Lambda 函数。 4. 警报处理程序会进行一次 API 调用，仅在指标处于告警状态时才开启流日志。 5. Transit Gateway 仅在警报处理程序请求时才将流日志发送到 [Amazon S3](https://aws.amazon.com/s3/) 存储桶。  图 1: 告警配置的功能布局 您可以观察一个示例，如下图所示，方法是进入 CloudWatch，选择指标，然后选择 **添加数学** 、**异常检测** 和 **计算范围** 。  图 2: 异常检测范围示例。 当流量超过该范围时，这个异常范围可以触发警报，如下图所示：  图 3: 超出异常检测范围的示例。 超出范围的各个点在指标线上显示为红色，您可以观察到异常范围会随着网络内部条件的变化而随时间推移。 在低使用率水平下，即使是很小的变化也可能触发异常检测警报，因为这些变化在比例上显得很大。这可能是一个先前闲置的连接部署了最初几个资源，或任何其他类似活动。这可能会产生大量由异常检测器引发的误报噪音，因为我们通常不关心一个连接的使用量从零增加到每分钟几兆字节。我们想要捕获的是那些突然从兆字节跃升到千兆字节的连接。 有两种方法可以解决这个问题。第一种是为该指标创建另一个警报，当低于某个敏感度阈值时设置警报。然后，这被用作 [复合警报 (composite alarm) 中的抑制警报 (suppression alarm)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm_Suppression.html) 。下图展示了一个示例，其中一个 **LowBW** 抑制警报正在抑制异常警报：  图 4: 抑制警报生效示例。 抑制警报对于某些应用来说是个不错的功能，但在本例中，它有一个缺点。那些抑制警报处于告警状态，导致聚合的警报计数在没有问题时也显示有问题，如下图所示。  图 5: CloudWatch 警报摘要显示半数警报处于告警状态。 这种行为可能导致告警疲劳 (alarm fatigue)，即操作员习惯于看到大量警报，可能会错过关键警报。 另一种解决方法是使用逻辑运算符将两个标准合并到一个警报中，如下图所示。  图 6: 使用逻辑运算符作为警报触发条件的单一警报配置。 我们感兴趣的指标是 BytesIn，其 ID 为 **m1**。前面提到的异常检测范围的 ID 为 **e1**。最终的逻辑评估 ID 为 **e2**。**e2** 规则对 **m1** 大于我们的最小阈值 (本例中为 10,000,000) 和超出异常检测范围 (因此不会对低于范围的流量发出警报) 进行逻辑与 (AND) 操作。如果两个条件都满足，**e2** 返回 1，否则返回 0。因此，我们对 **e2** 大于 0 设置警报，从而达到我们想要的效果，如下图所示。  图 7: 针对逻辑运算符的告警条件。 至此，我们已经为异常流量变化设置了 CloudWatch 警报。当 CloudWatch 警报状态改变时 (从 **OK** 到 **ALARM** 或反之)，可以触发一个 Lambda 函数。当 Lambda 被调用时，我们可以根据从 CloudWatch 传入的 [事件数据](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-and-eventbridge.html) ，对该事件执行 AWS API 中的任何操作。这些数据包括引发警报的确切指标及其 [维度 (dimensions)](https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-cloudwatch-metrics.html#transit-gateway-dimensions) 。对于本用例，这些维度包括 TransitGateway 和 TransitGatewayAttachment，提供了我们需要启用或禁用监控的 Transit Gateway 和连接的 ID。提供的 alarm_handler.py 脚本包含了随警报状态变化启用和禁用流日志的示例代码。当您编写自己的脚本时，有几个最佳实践需要考虑： - 请记住，您的 Lambda 可能会在短时间内被多次调用 (例如，如果流量是从一个连接到另一个连接)。AWS [建议 Lambda 函数是幂等 (idempotent) 的](https://docs.aws.amazon.com/lambda/latest/dg/concepts-application-design.html#retries-failures) ，能够处理多个并发执行，并处理同一事件的重复触发。这一点在这里需要重点考虑。对于本用例，这意味着在 AWS API 中跟踪状态，并避免使用在 /tmp 文件或其他数据库中存储状态的方法。 - 设置一个 Amazon Simple Notification Service (Amazon [SNS) 主题 (topic)](https://docs.aws.amazon.com/sns/latest/dg/sns-create-topic.html) ，在脚本被触发或因某种原因出现问题时向网络操作员发送电子邮件。确保您有适当的检查来验证这些警报的有效性，以防止因无效警报而导致告警疲劳。 - 始终将您的 Lambda 代码包装在 try/except 代码块中，最外层的代码在遇到问题时发送 SNS 消息。否则，虽然 Lambda 会将事件记录到 CloudWatch Logs，但问题可能会被忽略。 ## 自动化指标设置 一些用户有成百上千个他们希望监控的 Transit Gateway 连接。为每个连接手动创建如前所述的警报会很快变得乏味且容易出错。有两种方法可以自动化这些指标的创建，都使用 Lambda 代码 (提供了一个示例 update_attachments.py)。 第一种是设置一个 [Amazon EventBridge](https://aws.amazon.com/eventbridge/) 计时器规则，让 Lambda 定期启动 update-attachments。该脚本使用 API 获取所有 Transit Gateway 连接和所有当前配置的警报列表。它通过在需要时创建新警报，并删除不再存在的连接的警报来协调两者。这消除了任何人手动管理这些警报的需要。 代码库中提供了一个名为 alarms-and-lambda.yaml 的 CloudFormation 脚本，它为您指定的 Transit Gateway 设置好了一切。 如果您有多个 Transit Gateway，您有两个选择：您可以多次部署单个 CloudFormation，或者使用基于 [AWS Network Manager](https://aws.amazon.com/products/networking/network-operations/) 的自动化。Network Manager 支持 [AWS Cloud WAN](https://aws.amazon.com/cloud-wan/) 和 Transit Gateway，并且它有一个非常适合本用例的功能：[拓扑变更通知事件 (topology change notification events)](https://docs.aws.amazon.com/network-manager/latest/tgwnm/monitoring-events.html) 。设置 EventBridge 来接收这些事件并调用 Lambda，可以让代码在连接状态发生变化时做出反应。Network Manager 可以全局管理您所有的 Transit Gateway，因此它也会将全球网络中每个资源的这些事件发送到一个地方。  图 8: Network Manager 事件功能图。 为了实现此功能，我们在代码库中提供了最后一部分代码 nm_event_handler.py，它已经集成到 CloudFormation 模板 alarms-and-lambda.yaml 中，并且在您指定 CloudWAN 全球网络 ARN 而不是 Transit Gateway ID 时使用。该事件处理程序提供了一个如何处理这种安排的示例，例如管理新的和已删除的连接，以及在检测到新的 [AWS 区域 (Regions)](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) 时将警报处理程序和相关的 S3 存储桶部署到其中。该脚本还处理 CloudFormation 的创建、更新和删除事件。处理这些事件很重要：部署前创建的连接需要创建其警报，更新可以更改一些告警配置，而在删除时，作为最佳实践，它会清理自身。 提供的脚本会自动启用和禁用流日志，并在状态发生变化时向指定的地址或 SNS 主题发送电子邮件通知。一个通知示例： > TransitGatewayAttachment ID tgw-attach-0123456789abcdef0 的流日志记录已启用，目标为 arn:aws:s3::: amzn-s3-demo-bucket/transit_gateway_logs/tgw-attach-0123456789abcdef0。 > > 您可以通过运行以下命令查看收集的日志：aws s3 ls s3:// amzn-s3-demo-bucket/transit_gateway_logs/tgw-attach-0123456789abcdef0/AWSLogs/111122223333/vpcflowlogs/us-west-2/2025/07/15/ > > 警报信息： > 警报：BytesIn-tgw-tgw-attach-0123456789abcdef0-alarms-Alarm > 当前值：每分钟 2.2 GB > 异常检测高范围：每分钟 166.9 MB。 > > 此消息来自 us-west-2 区域的 lambda 函数 alarms_Alarm_Handler。 ## 总结 我们讨论了如何使用 CloudWatch 警报和 Lambda 函数自动检测和响应 AWS Transit Gateway 中的异常网络流量模式。该解决方案不是持续运行昂贵的流日志，而是在出现流量异常时才启用流日志，从而降低成本，同时确保您能捕获重要的网络事件。 通过使用 CloudWatch 异常检测来建立正常的流量基线，我们可以设置警报触发器来调用 Lambda，执行自定义响应。为避免低流量场景下的误报，该解决方案在单个警报中使用逻辑运算符将异常检测与最小阈值要求相结合。虽然本文使用这些技术来启用流日志，但您可以轻松地将相同的模式用于其他警报和其他操作。 与 AWS Network Manager 集成可实现全球、多区域的自动化，用一个工具覆盖您的整个网络。虽然可以监控单个 Transit Gateway，但来自 Network Manager 的事件允许采取基于事件的行动，减少了新网络组件被监控前的时间，并节省了每隔几分钟运行一次 Lambda 来检测变化的成本。 本文在 GitHub 代码库中为该用例提供了完整的 CloudFormation 模板和 Python 代码示例，其编写方式便于您根据自己的环境或其他服务进行轻松更改和调整。 ## 开始使用 请查看公共 GitHub 代码库中发布的 AWS Lambda 脚本和 AWS CloudFormation 模板，了解如何在您自己的网络中部署此解决方案的示例。考虑一下您可能对我们在此讨论的异常范围、EventBridge 和 Network Manager 的组合还有哪些其他用途。这包括使用它来监控单个 [Amazon Elastic Compute Cloud (Amazon EC2)](https://aws.amazon.com/ec2/) 实例并启用 [VPC 流日志 (Flow Logs)](https://aws.amazon.com/vpc/latest/userguide/flow-logs.html) ，使您的 AWS 网络基础设施既更透明又更具成本效益。 ## 关于作者  ### Andrew Gray Andrew Gray 是 AWS 的一名首席解决方案架构师，专注于网络架构和工程。凭借在电信和高等教育领域担任首席网络工程师的经验，Andrew 喜欢运用他的技术专长来开发创新的云解决方案。他热衷于解决网络、基础设施和代码交叉领域的复杂挑战。 <!-- AI_TASK_END: AI全文翻译 -->