使用 AWS DevOps Agent 加速 AWS Network Firewall 故障排查

当管理员在 AWS Network Firewall 中引入规则更改并且网络连接中断时，要准确定位原因，需要检查流量路径中的多个节点。防火墙为您提供了无状态和有状态的规则引擎、域名规则，以及 Amazon Virtual Private Cloud (Amazon VPC) 内部指向防火墙端点的路由。无论从哪里开始，从工作负载的角度来看，网络中断的表现都是一样的。要查明原因，意味着需要将告警和流日志与防火墙配置、路由表以及 AWS CloudTrail 中可能修改了这些配置的近期 API 调用进行关联。这种手动关联正是 AWS DevOps Agent 的用武之地，它能加速根因分析，让您可以在几分钟而不是几小时内恢复连接。 AWS DevOps Agent 会为您完成这种关联。作为您随时可用的运维团队成员，它能够解决并主动预防跨 AWS、多云和本地环境的运维问题。当 Amazon CloudWatch 告警触发时，它会通过 webhook 到达 Agent。然后，Agent 会通过 AWS API 读取防火墙配置和日志，将数据丢弃与近期的 API 活动关联起来，并返回根因以及缓解计划供您在应用前进行审查。 这篇文章将 CloudWatch 监控与 DevOps Agent 连接起来。它从头到尾演示了三个 Network Firewall 故障。第一个是域名拒绝列表阻止了合法的端点。第二个是无状态规则优先级配置错误。第三个是跨可用区 (AZ) 的非对称路由丢弃。每一个都对应不同的网络层级，因此每一个都会引出不同的调查路径。一个 AWS Cloud Development Kit (AWS CDK) 应用程序会将整个环境部署在您自己的账户中，以便您可以重现每个故障并跟随操作。 ## 示例工作负载 作为此博客文章的一部分，我们提供了一个 CDK 堆栈，它同时部署了 AWS DevOps Agent Space 和一个用于演示三个独立故障排查场景的示例工作负载。受保护子网中的一个 `t3.micro` 实例会持续循环检查其与测试端点的连接，并将结果发布到 CloudWatch。流量通过 Network Firewall、NAT 网关和互联网网关经由互联网出口路径传输，以便防火墙可以拦截或丢弃它。完成此演练后，您可以使用 DevOps Agent 对您自己的 Network Firewall 部署应用相同的故障排查技术。 测试端点运行在由同一个 CDK 应用部署的一个独立 VPC 中。它在端口 443 上提供 HTTPS 服务，在端口 9142 上提供 TCP 服务，从而为每个场景提供了不同的协议层进行测试：场景 1 针对 443 上的 TLS 连接（通过 Server Name Indication 匹配），场景 2 针对 9142 上的 TCP 连接，场景 3 测试整个出口路径。 一个实时状态页面显示了每个场景的卡片以及网络拓扑。整个堆栈由单个 CDK 应用跨两个可用区部署，每个可用区都有一个防火墙端点和 NAT 网关，这正是场景 3 得以实现的基础。 如下图所示，出口数据路径从工作负载出发，通过 Network Firewall 以及 NAT 和互联网网关到达测试端点。告警管道从 CloudWatch 出发，通过 Amazon Simple Notification Service (Amazon SNS) 和 webhook AWS Lambda 函数到达 DevOps Agent。  *图 1：示例工作负载* 要将此解决方案用于您自己的工作负载，您需要一个能检测到连接问题的 CloudWatch 告警，以及将其交付给 DevOps Agent 的 webhook 管道（SNS 主题和 Lambda 函数）。Agent 会通过 AWS API 读取您的防火墙配置、日志和 CloudTrail，因此防火墙端无需额外的检测工具。 ## 前置条件 要跟随本文进行操作，您需要： - 一个 AWS 账户，且拥有部署 Amazon VPC、Network Firewall、Amazon Elastic Compute Cloud (Amazon EC2)、CloudWatch、Amazon SNS、Lambda、Amazon CloudFront 和 AWS Identity and Access Management (IAM) 资源的权限 - 访问 AWS DevOps Agent 的权限，并拥有配置其 webhook 的权限 - 已安装 Node.js 18 或更高版本以及 npm - 已配置好带有凭证的 AWS Command Line Interface (AWS CLI) 2.x - 需要 AWS CDK 2.x。您可以通过项目的 `npx` 依赖项来使用它，或者全局安装它： npm install -g aws-cdk ## 部署示例工作负载 克隆项目并使用一个命令将其部署到 `us-east-1`（设置 `awsRegion` 以使用其他 AWS 区域）。 ``` git clone https://github.com/aws-samples/sample-accelerating-aws-network-firewall-troubleshooting-with-aws-devops-agent cd sample-accelerating-aws-network-firewall-troubleshooting-with-aws-devops-agent bash scripts/deploy.sh ``` 该脚本会检查前置条件，安装依赖项，进行编译和测试，并在需要时引导 CDK。然后，它将从干净的基线部署所有堆栈，并打印输出，包括状态页面的 URL 和登录详细信息。 1. 打开状态页面链接（一个 `https://.cloudfront.net` 地址）。 2. 使用 CDK 输出提供的用户名和密码登录，并确认所有三个卡片都显示绿色的 Healthy 状态。 3. 在运行场景时保持页面打开。 ## 连接 AWS DevOps Agent 将 AWS DevOps Agent 连接到告警管道 1. 在 AWS DevOps Agent 控制台中，打开由 CDK 部署创建的 `nf-devops-agent-space` Agent Space。 2. 配置 DevOps Agent webhook 并下载包含 webhook URL 和签名密钥的 CSV 文件。 3. 在状态页面上，选择 Configure webhook，粘贴 URL 和签名密钥，然后保存。页面会将它们写入 `nf-devops-agent-webhook-credentials` AWS Secrets Manager 密钥中，因此不需要 AWS CLI 或控制台步骤。在您设置好之前，桥接 Lambda 函数会看到一个占位符并跳过交付。 4. 在运行场景之前验证路径。在 Lambda 控制台中，打开 `nf-devops-agent-webhook` 并在此事件中使用 Test 选项卡。 { "Records": [ { "Sns": { "Message": "{\"AlarmName\":\"TEST-webhook-verification\",\"AlarmDescription\":\"...\"}" } } ] } 5. 200 响应确认路径畅通，并且测试调查会出现在 DevOps Agent Operator Web App 视图中。 ## 告警管道的工作原理 每个场景都以相同的方式到达 DevOps Agent。CloudWatch 告警进入 ALARM 状态并通知 SNS 主题。Amazon SNS 调用一个 Lambda 函数。该函数从 Secrets Manager 中读取 webhook URL 和签名密钥，对告警有效载荷进行签名，并将其 POST 到 DevOps Agent webhook（如图 1 所示）。Amazon SNS 还提供交付重试、向其他订阅者扇出以及跨账户发布的功能。 - **预置的 Network Firewall 指标（场景 1）** – Alarm-1 监控 `DroppedPackets` 指标（在有状态流中求和），并在丢包数上升到高于基线阈值时触发。这不需要工作负载或自定义指标，并且可以在已部署的防火墙上运行。但是，它只会告诉您防火墙正在丢弃数据包，而不会告诉您是哪条规则导致的。 - **应用程序健康指标（场景 2 和 3）** – Alarm-2 和 Alarm-3 监控来自连接检查的自定义指标。将其用于与面向用户的影响相关的告警，或用于区分不同的流量路径，这需要运行一个发出该指标的组件。 | 告警 | 来源 | 触发条件 | |-------|--------|---------------| | Alarm-1 | 原生 AWS/NetworkFirewall DroppedPackets | 防火墙的丢包计数上升到高于基线 | | Alarm-2 | 自定义应用程序健康指标 | 指向测试端点的端口 9142 (TCP) 连接检查被丢弃 | | Alarm-3 | 自定义应用程序健康指标 | 跨可用区连接检查被丢弃 | ## 运行场景 按照相同的循环一次完成一个场景的操作：中断网络连接，观察告警触发，让 DevOps Agent 进行调查，应用建议的修复，并在继续之前确认恢复。 状态页面卡片遵循实时的 CloudWatch 告警状态。当其告警解除时，卡片会显示绿点和 Healthy 字样；当其告警触发时，会显示红点和 DROPPED 字样。在 DROPPED 状态下，卡片还会添加一行 Condition: 来描述正在丢弃的内容，这在卡片处于健康状态时是不显示的。Network Firewall 会将更改应用于新流，因此更改会在一两分钟内显现出来。恢复来自于 DevOps Agent 推荐的缓解措施，您需要对其进行审查并应用。 ## 场景 1. 域名拒绝列表阻止了合法端点 在基线状态下，`rg-domain` Suricata 域名规则组仅拒绝一个未使用的占位符，因此测试端点保持可访问。该规则组会检查每个出站连接上的 TLS Server Name Indication (SNI)，并丢弃任何与被拒绝域名匹配的连接。具体的规则语法和控制台步骤如下。 添加域名拒绝规则 1. 转到 Amazon VPC 控制台。 2. 在导航窗格的 Network Firewall 下，选择 Network Firewall rule groups。 3. 选择 `rg-domain` 规则组以打开其详细信息页面。 4. 在 Rules 部分下，选择 Edit。 5. 规则框中已经包含了两条基线占位规则（它们匹配 `blocked.placeholder.invalid`，因此不会拒绝任何实际内容）。保留它们。在部署脚本输出中找到场景 1 的 `` 值（一个 Network Load Balancer (NLB) 的 DNS 名称，例如 `NfTest-AppNl-a1b2C3dEf4G5-1234abcd5678efgh.elb.us-east-1.amazonaws.com`）。在现有规则下方的新行中，添加一条匹配 TLS SNI 上该 DNS 名称的丢弃规则，然后选择 Save。 drop tls $HOME_NET any -> $EXTERNAL_NET any (ssl_state:client_hello; tls.sni; content:...) 6. 保存后，规则框中将包含所有三行。保留这两个占位符，以及针对该端点 DNS 名称的新的丢弃规则（请注意独特的 sid `2000002`）。  *图 2：场景 1 – 阻止连接的防火墙规则更改* 发生的事情。工作负载对测试端点的 HTTPS 检查超时，`AWS/NetworkFirewall DroppedPackets` 指标攀升至基线以上，并且 Alarm-1 进入 ALARM 状态。场景 1 的卡片显示为 DROPPED（条件为 Firewall dropping the monitored domain on its allow/deny rules），而场景 2 和场景 3 的卡片保持 Healthy（图 3）。在拓扑上，从 CloudWatch 经由 Amazon SNS 和 Lambda 到 DevOps Agent 的告警管道，以及工作负载到防火墙的检查线都变成了琥珀色，图例将其定义为 collateral / alarm active，因为数据包现在在防火墙处被丢弃。为了展示由此产生的故障，从互联网网关到测试端点的 HTTPS · SNI 线路显示为红色，图例将其定义为 dropped (root cause)。  *图 3：场景 1 激活 – 流量在防火墙处被阻止* 让 DevOps Agent 进行调查。Agent 会并行运行几条调查线并将它们关联起来： 1. 读取 `DroppedPackets` 指标，并将激增点与通过的数据包同时下降相关联，确认防火墙正在主动阻止流量。 2. 读取 ALERT 日志，发现工作负载到测试端点的 TLS 连接被 S1 域名拒绝列表规则阻止。 3. 将当前状态与基线窗口进行比较，在基线窗口中，同一个端点是可以访问的且没有告警，这表明该阻止是新建的。 4. 搜索 CloudTrail 并找出添加拒绝规则的 `UpdateRuleGroup` 调用，识别出在丢包开始前大约一分钟执行的用户、角色和时间戳。 5. 报告根本原因是该手动规则组更改。建议删除拒绝条目或添加允许例外，并启用 `FirewallPolicyChangeProtection` 以防止未经授权的更改。 6. 将此作为一个供您审查和应用的计划提供，而不是自动更改。 在 DevOps Agent Operator Web App 视图中， 首先重述了 Alarm-1 的触发条件，并确认防火墙丢弃的数据包超过了阈值（图 4）。  *图 4：场景 1 – 故障症状* 接下来，Agent 确定了根本原因：在告警触发前不久，对 `rg-domain` 规则组进行的手动更新添加了一条域名拒绝规则（SID `2000002`），阻止了到 ELB 端点的 TLS 连接（图 5）。  *图 5：场景 1 – 根本原因* 最后，Agent 提出了一个缓解计划，建议您移除有问题的拒绝规则（SID `2000002`）以恢复连接（图 6）。  *图 6：场景 1 – 缓解计划* 确认恢复。应用 Agent 推荐的更改。拒绝条目消失后，`DroppedPackets` 回落到基线，Alarm-1 解除，卡片恢复为绿色。继续进行场景 2。 ## 场景 2. 无状态规则优先级配置错误 在基线状态下，`rg-stateless-priority` 无状态规则组在测试类（TCP 目标端口 9142）中将允许规则保持在优先级 100，将丢弃规则保持在 200。工作负载在此端口上打开与测试端点的 TCP 连接。优先级编号较小的先评估，因此允许规则胜出。此场景使用端口 9142 而不是 443 来演示无状态规则，该规则匹配数据包的 5 元组（协议、端口、地址）而不是应用程序内容。 引入更改。颠倒这两条规则的优先级，以便丢弃规则在允许规则之前进行评估。这是匆忙编辑规则可能会引入的更改类型。 颠倒无状态规则优先级 1. 转到 Amazon VPC 控制台。 2. 在导航窗格的 Network Firewall 下，选择 Network Firewall rule groups。 3. 选择 `rg-stateless-priority` 规则组以打开其详细信息页面。 4. 在 Rules 部分下，选择 Edit。 5. 提高 (Action: Pass) 规则的优先级编号，使其位于 (Action: Drop) 规则之后，然后选择 Save。例如，将 (Action: Pass) 规则从 100 更改为 300（任何大于丢弃规则的 200 的数字都可以）。您只需要移动一条规则，使用 300 可以避免与已经位于 200 的丢弃规则发生冲突。Network Firewall 会首先评估优先级编号最小的规则，因此位于 200 的 (Action: Drop) 规则现在会在此流量类别中胜出，优先于位于 300 的 (Action: Pass) 规则。  *图 7：场景 2 – 阻止流量类别的规则优先级更改* 发生的事情。丢弃规则现在胜出，端口 9142 上到测试端点的 TCP 连接超时，`StatelessRuleFailures` 指标攀升至基线以上，并且 Alarm-2 进入 ALARM 状态。场景 2 的卡片显示为 DROPPED（条件为 Stateless rules dropping the monitored traffic class），而场景 1 和场景 3 的卡片保持 Healthy（图 8）。在拓扑上，从 CloudWatch 经由 Amazon SNS 和 Lambda 到 DevOps Agent 的告警管道，以及工作负载到防火墙的检查线都变成了琥珀色，图例将其定义为 collateral / alarm active，因为数据包现在在防火墙处被丢弃。为了展示由此产生的故障，从互联网网关到测试端点的 TLS :9142 线路显示为红色，图例将其定义为 dropped (root cause)。  *图 8：场景 2 激活* 让 DevOps Agent 进行调查。无状态丢弃发生在流量到达有状态检测引擎之前，因此它不会生成 ALERT 日志条目。Agent 转而查看配置和流日志： 1. 读取无状态规则组状态，发现丢弃规则位于较低的优先级编号（在通过规则之前），因此丢弃规则先进行评估。 2. 读取流日志，发现在更改后的一分钟内通过的数据包降为零。 3. 搜索 CloudTrail 并找出颠倒了优先级的 `UpdateRuleGroup` 调用，识别出在告警发生前大约一分钟执行的用户、角色和时间戳。 4. 报告根本原因是该优先级颠倒。建议删除多余的丢弃规则，并通过基础设施即代码 管理规则组，以防止手动配置错误。 5. 将此作为一个供您审查和应用的计划提供，而不是自动更改。 在 DevOps Agent Operator Web App 视图中，Agent 首先重述了 Alarm-2 的触发条件，并确认由于防火墙的无状态规则正在丢弃出口流量，工作负载连接健康检查失败（图 9）。  *图 9：场景 2 – 故障症状* 接下来，Agent 使用规则组状态和 CloudTrail 确定了根本原因，准确定位了冲突的 DROP/PASS 规则，其中新的 DROP 规则较低的优先级编号使其首先匹配（图 10）。  *图 10：场景 2 – 根本原因* 最后，Agent 提出了一个缓解计划，建议您移除优先级为 200 的冲突 DROP 规则以恢复流量（图 11）。  *图 11：场景 2 – 缓解计划* 确认恢复。应用 Agent 推荐的更改。在允许规则再次位于丢弃规则之前后，Alarm-2 解除，卡片恢复为绿色。继续进行场景 3。 ## 场景 3. 跨可用区的非对称路由丢弃 在基线状态下，每个可用区中的受保护子网通过同一可用区中的防火墙端点路由其出口流量，并且匹配的返回路由使用同一个端点。一个端点可以查看流的双向，因此有状态引擎可以完成握手。工作负载运行在 `us-east-1a` 的受保护子网（CIDR `10.0.4.0/24`）中，因此在基线状态下，其出口和返回都使用 `us-east-1a` 防火墙端点。 引入更改。通过将出口发送到一个可用区端点而返回来自另一个端点，使流变得不对称。这需要进行两次路由编辑，并且两者都是必需的。如果仅进行第一次编辑，流仍然可以完成，因此在两者都保存之前，告警不会触发。它没有更改防火墙策略，这反映了一个真实的跨可用区路由错误。 创建跨可用区的不对称路由 1. 转到 Amazon VPC 控制台并在导航窗格中选择 Route tables。 2. 翻转出口。选择 `NfNetworkStack/SampleVpc/protectedSubnet1` 路由表（运行工作负载的 `us-east-1a` 受保护子网）。在 Routes 选项卡上，选择 Edit routes。其 `0.0.0.0/0` 路由当前指向 `us-east-1a` 防火墙端点。对于目标，选择 Gateway Load Balancer Endpoint 并选择 `us-east-1b` 防火墙端点，然后选择 Save changes。 3. 移动返回路径。选择 `NfNetworkStack/SampleVpc/publicSubnet2` 路由表（出口现在退出的 `us-east-1b` 公有子网）。选择 Edit routes，然后选择 Add route。对于目标，输入工作负载 CIDR `10.0.4.0/24`。对于目标，选择 Gateway Load Balancer Endpoint 并选择 `us-east-1a` 防火墙端点。选择 Save changes。 完成这两项编辑后，流的出口将通过 `us-east-1b` 端点离开，而其返回将被定向到 `us-east-1a` 端点。两个端点都无法查看到完整的流。  *图 12：场景 3 路由更改破坏了流的对称性* 发生的事情。新连接从一个端点离开。其返回到达另一个从未看到连接打开的端点，因此握手失败。与场景 1 和 2 不同，这会影响整个子网，因此所有出口都停止，并且 Alarm-2 和 Alarm-3 都进入 ALARM 状态。`AWS/NetworkFirewall DroppedPackets` 告警 (Alarm-1) 保持安静，因为没有端点做出丢弃决定。由于非对称路由，该流丢失了，而不是被计为防火墙丢弃。这就是为什么监控应用程序连接很重要的原因。路由故障对防火墙自己的丢弃计数器是不可见的。在状态页面上，场景 2 的卡片显示为 DROPPED（条件为 "Stateless rules dropping the monitored traffic class"），场景 3 的卡片显示为 DROPPED（条件为 Return traffic dropped by asymmetric cross-Availability-Zone routing），而场景 1 的卡片保持 Healthy（图 13）。在拓扑上，从 CloudWatch 经由 Amazon SNS 和 Lambda 到 DevOps Agent 的告警管道，以及工作负载到防火墙的检查线都变成了琥珀色，图例将其定义为 collateral / alarm active，而从防火墙通过 NAT 网关到测试端点的出口路径以及 TLS :9142 和 HTTPS · 路由线路都变成了红色，图例将其定义为 dropped (root cause)。  *图 13：场景 3 – 路径范围中断期间的状态页面* 让 DevOps Agent 进行调查。Alarm-2 和 Alarm-3 在同一个数据点触发。DevOps Agent 识别出它们是相关的，并将它们合并为一个调查： 1. 读取流日志，看到双向 TLS 连接突然停止，只剩下单向流量，并且没有流进入 established 状态。 2. 读取防火墙指标，看到在更改的那一刻，接收和通过的数据包从一个可用区转移到了另一个可用区。 3. 调用 `DescribeRouteTables`，发现出口路由指向一个可用区防火端点，而返回路由指向另一个。 4. 搜索 CloudTrail 并找出同一个用户在两个告警触发前大约一分钟执行的 `ReplaceRoute` 和 `CreateRoute` 调用。 5. 报告根本原因是该非对称路由更改。建议恢复同可用区的对称路由，以便出口和返回经过同一个端点。 6. 将此作为一个供您审查和应用的计划提供，而不是自动更改。 缓解计划是供您审查的建议，而不是自动更改，正确的修复取决于预期的设计。恢复对称路由可能意味着将工作负载子网的出口重新通过其自身所在可用区的防火墙端点发送（此示例的架构），或者在不过滤此路径的设计中，通过 NAT 网关发送回去。Agent 会从其可以观察到的内容推断出一个看似合理的目标，因此在应用之前，请对照您的预期拓扑审查其建议的具体路由。（连接您的管道或基础设施即代码（在下一节中介绍）可以让 Agent 推荐与您的设计相匹配的目标。） 在 DevOps Agent Operator Web App 视图中，Agent 重述了 Alarm-3 (`AsymmetricFlowFailures`) 的触发条件，并确认工作负载到受监控端点的出口正被 Network Firewall 阻止（图 14）。  *图 14：场景 3 – 故障症状* 接下来，Agent 确定了根本原因：手动路由表更改创建了通过网络防火墙的跨 AZ 非对称路由，打破了其对称路由要求（图 15）  *图 15：场景 3 – 根本原因* 最后，Agent 提出了一个缓解计划，建议您通过将 `protectedSubnet1` 的默认路由指回同一个可用区防火墙端点来恢复对称路由，以便一个端点可以再次查看流的双向（图 16）。  *图 16：场景 3 – 缓解计划* 确认恢复。在检查路由目标符合您的预期设计后，应用 Agent 推荐的更改。当工作负载子网的出口和返回再次使用同一个可用区防火墙端点时，控制探针将恢复，告警将解除，所有卡片都将恢复为绿色。 ## 进一步的考虑 在生产环境中，如场景 3 所示，单个更改可能会同时触发多个告警。DevOps Agent 会链接相关的调查并将它们作为一个整体进行处理，因此您只需审查一个根因。您可以验证链接的调查结果，或者取消链接某个告警以独立对其进行调查。如果您想在告警到达 Agent 之前合并它们，可以在桥接 Lambda 函数中添加关联逻辑，按防火墙进行缓冲和分组。您还可以向 SNS 主题添加电子邮件、Amazon Simple Queue Service (Amazon SQS) 或 HTTP 订阅者，或者将 webhook Lambda 函数添加到您已经在运行的主题中。DevOps Agent 会生成缓解计划，但不会自行更改您的环境。 您还可以为 Agent 提供更多可处理的信息。DevOps Agent 连接到源代码存储库和 [CI/CD pipelines](https://docs.aws.amazon.com/devopsagent/latest/userguide/configuring-integrations-and-knowledge-connecting-to-cicd-pipelines-index.html)，与 GitHub（包括通过私有连接的 GitHub Enterprise Server 和 GitLab Self-Managed）集成。它可以将 AWS 资源与 AWS CloudFormation、AWS CDK、Amazon Elastic Container Registry (Amazon ECR) 镜像和 Terraform 的部署相关联。结合已部署的配置和最近的部署事件，Agent 会将中断与引入中断的更改相关联，并推荐符合您预期设计的修复方案。对于此示例，这意味着推荐工作负载子网自身所在可用区的防火墙端点，而不是通用的对称路径。 DevOps Agent 还支持主动的事件预防。它分析过去调查的模式，并提供防止类似问题再次发生的建议，包括加强部署流程和管道控制的治理建议。对于 Network Firewall 规则更改，这意味着 Agent 可以根据其已经解决的各类配置错误，为您的 CI/CD pipeline 推荐护栏。您可以通过 DevOps Agent Operator Web App 中的 Improvements 页面访问这些建议。 ## 清理 使用一个命令清理环境。 ``` bash scripts/destroy.sh ``` 它会还原任何活动的场景，对所有堆栈运行 `cdk destroy`，并通过 `Project = nf-devops-agent` 标签扫描残留资源。主要的成本来源是两个 Network Firewall 端点、NAT 网关（主 VPC 中每个可用区一个，测试端点 VPC 中一个）以及测试端点的负载均衡器。只要这些资源被预置，无论是否有流量通过，它们都会按小时费率计费，因此即使处于空闲状态，保持运行的堆栈也会全天候持续产生费用。在同一天内运行场景并销毁堆栈，可将成本限制在几个活跃的小时内，而不是几天的空闲按小时收费。 ## 结论 在这篇文章中，我们向您展示了 AWS DevOps Agent 如何加速排查三个常见的网络防火墙连接问题。第一个是域名拒绝列表。第二个是无状态优先级颠倒。第三个是跨 AZ 非对称路由丢弃。对于每一个问题，DevOps Agent 都会调查丢包情况，并返回根因以及缓解计划，供您在应用前批准。第一个场景是在预置的 Network Firewall 指标上触发的，另外两个是在应用程序健康指标上触发的。这展示了通过一个管道对防火墙问题发出告警的两种方式。 这种模式并非 Network Firewall 独有。相同的流程适用于任何发出 CloudWatch 指标和日志的服务，例如 AWS WAF、安全组和网络 ACL。克隆示例存储库以探索该解决方案，然后将您学到的知识应用到你自己的防火墙、应用程序和告警中。有关更多详细信息，请参阅 [AWS Network Firewall 开发人员指南](https://docs.aws.amazon.com/network-firewall/latest/developerguide/what-is-aws-network-firewall.html) 和 [AWS Network Firewall 定价页面](https://aws.amazon.com/network-firewall/pricing/)。从 [AWS DevOps Agent 入门](https://docs.aws.amazon.com/devopsagent/latest/userguide/getting-started-with-aws-devops-agent.html)指南开始，连接您的第一个 webhook。

标签：AWS CDK, MITM代理, 故障排查, 网络防火墙, 自动化攻击, 自动化运维