aws-samples/sample-automated-aws-devops-agent-network-incident-response

# 使用 AWS DevOps Agent 实现自动化网络事件响应 您的值班工程师在凌晨 2 点接到告警。业务工作负载账户中的支付服务无法访问共享服务账户中的共享数据库。[Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 报警在八分钟前触发。工程师首先检查两个账户的路由表、[Amazon Virtual Private Cloud (Amazon VPC)](https://aws.amazon.com/vpc/) 附件状态、[安全组](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html) 规则、[网络 ACL](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) 以及 DNS 解析日志。一小时后，根源问题被确定为 [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/) 路由表关联在当晚稍早的一次网络迁移中被错误地切换到了错误的路由表，悄无声息地丢弃了两个 VPC 之间的所有流量，而其他所有分支节点仍在正常工作。 AWS DevOps Agent 通过自动化整个调查过程来解决此问题。当 CloudWatch 报警触发时，DevOps Agent 通过 Webhook 接收告警，然后关联指标、日志、网络流量数据和 API 变更历史。随后，DevOps Agent 提供一份根因分析以及可直接运行的修复方案，将原本需要一小时的手动关联工作缩短为几分钟的自动化分析。 本文演示了如何将 CloudWatch 监控与 DevOps Agent 集成，以实现对网络故障的自动化事件响应。我们将逐步了解四个常见场景：安全组配置错误、NAT 网关路由问题、VPC 端点策略限制以及接口端点子网问题。我们提供一个可在您自己的账户中部署的 CloudFormation 模板以跟随操作，每个场景展示 DevOps Agent 如何自动调查并生成修复计划，同时保留人工审核。我们随后展示一个复杂的多账户场景，其中 Transit Gateway 路由表配置错误导致跨账户 VPC 之间的流量被阻断，展示 DevOps Agent 如何扩展至企业级环境。模拟工作负载应用程序的完整堆栈在 [aws-samples GitHub 仓库](https://github.com/aws-samples/sample-automated-aws-devops-agent-network-incident-response) 中可用。 ## 模拟工作负载 为了展示 DevOps Agent 的自动化事件响应能力，我们使用一个模拟工作负载：运行在 Amazon Elastic Compute Cloud (Amazon EC2) 上的 Node.js 服务，背后是 Application Load Balancer (ALB)。该应用程序执行循环健康检查并在状态仪表板上显示结果。为了简化说明，应用程序检查四种类型资源的可达性： - 每 5 秒检查一次 Amazon RDS 实例的数据库连接。 - 每 15 秒通过 NAT 网关检查一次出站互联网可达性。 - 每 10 秒通过 VPC 网关端点访问 Amazon Simple Storage Service (Amazon S3)。 - 每 60 秒通过接口 VPC 端点访问 Amazon Bedrock。 当某项检查失败时，应用程序会发布一个自定义的 Amazon CloudWatch 指标，从而触发告警。整个堆栈通过单个 AWS CloudFormation 模板部署。图 1 展示了模拟工作负载的架构图。  *图 1：模拟工作负载架构图，展示 ALB、私有子网中的 EC2 实例、RDS、S3 网关端点、接口 VPC 端点、NAT 网关以及告警管道* 现在您已经了解模拟工作负载以及 DevOps Agent 的功能，接下来让我们设置环境并逐步运行这些场景。 ## 使用 AWS CloudFormation 部署模拟工作负载 从 [GitHub 仓库](https://github.com/aws-samples/sample-automated-aws-devops-agent-network-incident-response) 下载 CloudFormation 模板，然后在 **us-east-1** 区域打开 [AWS CloudFormation 控制台](https://console.aws.amazon.com/cloudformation)。 1. 选择 **Create stack**，然后选择 **With new resources (standard)**。 2. 选择 **Upload a template file**，上传下载的文件，然后选择 **Next**。 3. 输入堆栈名称，勾选任何 IAM 确认框，然后选择 **Submit**。 一旦 CloudFormation 部署完成，导航至 CloudFormation 控制台的 **Outputs** 标签页，您将找到用于访问模拟工作负载应用程序状态页面的链接。状态页面会显示应用程序正常运行，所有检查均通过绿色 **“Connected”** 方框确认。  *图 2：模拟工作负载应用程序状态页面* 现在模拟工作负载应用程序已运行，是时候设置 AWS DevOps Agent 了。创建一个 DevOps Agent Space，配置 Webhook 集成，并验证连接。设置完成后，我们将逐步了解四个网络场景，在这些场景中配置更改会破坏应用程序的部分功能，而 DevOps Agent 会自动进行诊断。 ## 设置 AWS DevOps Agent 1. [创建 DevOps Agent Space](https://docs.aws.amazon.com/devopsagent/latest/userguide/getting-started-with-aws-devops-agent-creating-an-agent-space.html)。 2. [配置 DevOps Agent Webhook](https://docs.aws.amazon.com/devopsagent/latest/userguide/configuring-capabilities-for-aws-devops-agent-invoking-devops-agent-through-webhook.html)。 3. 创建 Webhook 并下载 CSV 文件后，在 AWS 控制台中导航至 **AWS Secrets Manager**（us-east-1 区域），找到名为 `simulated-workload-webhook-credentials` 的密钥，并使用 CSV 文件中的 Webhook URL 和密钥更新这两个值。 4. 在继续之前，通过测试 Webhook 验证集成是否正常工作： a. 在 AWS 控制台中打开 **Lambda**，找到函数 `simulated-workload-DevOpsAgent-Webhook`，并选择 **Test** 标签页。 b. 创建一个名为 **TestAlarm** 的新测试事件，使用以下 JSON： { "Records": [ { "Sns": { "Message": "{\"AlarmName\":\"TEST-webhook-verification\",\"AlarmDescription\":\"[TEST] This is a webhook integration test - not a real incident. No investigation needed.\",\"NewStateValue\":\"ALARM\",\"NewStateReason\":\"[TEST] Manual test to verify webhook connectivity from Lambda to DevOps Agent. Safe to ignore.\",\"Region\":\"us-east-1\"}" } } ] } c. 点击 **Save**，然后 **Test**。确认返回以下内容。 { "statusCode": 200, "body": "{\"message\": \"DevOps Agent investigation triggered\", \"alarmName\": \"TEST-webhook-verification\", \"webhookStatus\": 200}" } d. 在 DevOps Agent Web 应用中确认名为 **"CloudWatch Alarm: TEST-webhook-verification"** 的测试调查出现在 **Incident** 标签下。 图 3 展示了此特定测试在 DevOps Agent Web 应用中的输出结果。  *图 3：手动触发 DevOps 代理运行的输出，确认 Webhook 集成正常工作* ## 从告警到调查的告警管道工作原理 每次故障都会沿相同路径进入 DevOps Agent。应用程序向 Amazon CloudWatch 发布自定义指标。CloudWatch 指标评估后转为 ALARM 状态，告警通知 [Amazon SNS](https://aws.amazon.com/sns/) 主题。Amazon SNS 调用 [AWS Lambda](https://aws.amazon.com/lambda/) 函数，该函数从 [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/) 读取 Webhook 凭证，构建事件负载，使用 HMAC SHA-256 签名，并将其 POST 到 DevOps Agent Webhook。DevOps Agent 验证签名后启动调查。此管道如图 4 所示。  *图 4：告警管道* 图 5 展示了为模拟工作负载配置的四个 CloudWatch 告警。  *图 5：CloudWatch 告警* Amazon SNS 位于 Amazon CloudWatch 和 AWS Lambda 之间，原因有三：在 Lambda 限流时进行重试（支持死信队列）、向订阅方（邮件、聊天工具、事件管理系统）扇出而无需修改告警本身，以及支持跨账户发布，使得来自多个账户的告警可以汇聚到单一操作管道。 ## 场景 1：安全组规则被删除，数据库下线 数据库安全组（`simulated-workload-DB-SG`）允许来自应用安全组（`devops-agent-sample-app-App-SG`）的 MySQL 入站流量（端口 3306）。图 6 显示了该入站规则被删除的过程。  *图 6：安全组入站规则被删除* 当规则被删除后，应用程序在数秒内失去数据库连接。安全组会静默丢弃不匹配任何规则的报文，因此应用的连接尝试得不到响应并超时（状态仪表板上会显示 `ETIMEDOUT`）。其他三项检查（外部连通性、S3 和 Bedrock）保持正常，因为它们不涉及端口 3306。  *图 7：模拟工作负载应用程序状态页面* DevOps Agent 收到 `DatabaseConnectionFailures` 告警并开始调查： 1. **检查 RDS 实例健康状态**——确认数据库可用但连接数为零。 2. **搜索 CloudTrail 日志**——找到 `RevokeSecurityGroupIngress` API 调用，包括执行者和时间（距离告警触发仅 15 秒）。 3. **映射资源关系**——使用其拓扑结构识别 EC2 到 RDS 的连接依赖。 4. **识别根因**——数据库安全组的入站规则被删除，该规则允许来自应用安全组的流量通过 3306 端口访问数据库，导致数据库立即阻断所有 MySQL 连接，而数据库本身仍处于健康状态。 图 8 和图 9 展示了调查时间线和根因分析。查看根因后，您可以生成修复计划以了解如何解决问题。图 10 展示了详细说明修复步骤（AWS CLI 命令）的修复计划。  *图 8：DevOps Agent 调查时间线*  *图 9：DevOps Agent 根因分析*  *图 10：DevOps Agent 修复计划* 应用修复后，模拟工作负载应用程序页面将显示数据库连接状态恢复为绿色 **Connected**。 ## 场景 2：NAT 网关路由被删除，出站互联网丢失 私有路由表（`simulated-workload-Private-RT`）有一条默认路由，将所有非 VPC 流量发送至 NAT 网关。图 11 显示该路由被删除。  *图 11：默认路由从私有路由表中删除* 当此路由被删除后，应用程序无法访问互联网。但数据库仍可工作（VPC 本地路由）、Amazon S3 仍可工作（网关端点拥有独立的路由表项）、Amazon Bedrock 仍可工作（接口端点的 ENI 直接位于子网中）。只有外部连通性检查变红。  *图 12：模拟工作负载应用程序状态页面* DevOps Agent 收到 `ExternalConnectivityFailures` 告警并开始调查： 1. **检查私有路由表**——识别出指向 NAT 网关的默认路由（0.0.0.0/0）已缺失。 2. **确认 NAT 网关健康状态**——验证 NAT 网关本身健康，无容量问题或错误。 3. **搜索 CloudTrail 日志**——找到 `DeleteRoute` API 调用，包括执行者和时间。 4. **映射资源关系**——使用其拓扑结构识别 EC2 到 NAT 网关的依赖。 5. **识别根因**——默认路由从私有路由表中被删除，导致 EC2 实例没有通往互联网的出站路由路径。 图 13 和图 14 展示了调查时间线和根因分析。查看根因后，您可以生成修复计划以了解如何解决问题。图 15 展示了详细说明修复步骤（AWS CLI 命令）的修复计划。  *图 13：DevOps Agent 调查时间线*  *图 14：DevOps Agent 根因分析*  *图 15DevOps Agent 修复计划* 应用修复后，模拟工作负载应用程序页面将显示外部连通性状态恢复为绿色 **Reachable**。 ## 场景 3：VPC 端点策略限制 S3 桶访问 S3 VPC 网关端点（`simulated-workload-S3-Endpoint`）拥有一个允许访问五个应用桶的策略。图 16 显示了该端点策略的修改。  *图 16：修改 VPC 端点策略* 当有人编辑此策略，仅允许访问五个桶中的三个时，另外两个开始返回 `AccessDenied`。这最容易让人困惑，因为 [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/) 策略仍然允许访问全部五个。对于通过网关端点访问 Amazon S3 的流量，必须满足三层策略的一致性：IAM、桶策略和端点策略。如果任意一层拒绝请求，都会得到 HTTP 403 Forbidden 错误。 但其他一切仍可工作： - 数据库正常（VPC 本地路由）。 - Amazon Bedrock 正常（接口端点的 ENI 直接位于子网中）。 - 出站互联网连通性正常（NAT 网关路由完好）。 只有 S3 桶访问检查变红。  *图 17：模拟工作负载应用程序状态页面* DevOps Agent 收到 `S3AccessFailures` 告警并开始调查： 1. **比较策略层**——检查端点策略与 IAM 权限以及应用尝试访问的桶。 2. **识别阻塞层**——确定是端点策略限制了访问。 3. **搜索 CloudTrail 日志**——找到 `ModifyVpcEndpoint` API 调用，包括修改策略的执行者和时间。 4. **映射资源关系**——使用其拓扑结构识别 EC2 到 S3 网关端点的依赖。 5. **识别根因**——VPC 端点策略被修改，仅允许访问五个应用桶中的三个，导致剩余两个桶的访问被阻止。 图 18 和图 19 展示了调查时间线和根因分析。查看根因后，您可以生成修复计划以了解如何解决问题。图 20 展示了详细说明修复步骤（AWS CLI 命令）的修复计划。  *图 18：DevOps Agent 调查时间线*  *图 19：DevOps Agent 根因分析*  *图 20：DevOps Agent 修复计划* 应用修复后，模拟工作负载应用程序页面将显示 S3 桶访问状态恢复为绿色 **All Accessible**。 ## 场景 4：Bedrock 接口端点子网被移除，AI 功能中断 Bedrock Runtime 接口端点（`simulated-workload-Bedrock-Endpoint`）在两个私有子网中创建 ENI。私有 DNS 将 `bedrock-runtime.us-east-1.amazonaws.com` 解析为这些 ENI 的 IP 地址。图 21 显示了子网关联被移除。  *图 21：修改与接口 VPC 端点关联的子网* 当两个子网关联都被移除后，ENI 被删除。端点仍然存在，私有 DNS 仍解析该主机名到端点，但没有实体处理流量。这是一种特别难以手动发现的情况，因为控制台仍显示端点为“可用”，但请求会超时无响应。需要注意的是，两种端点类型存在差异：VPC 网关端点（Amazon S3、Amazon DynamoDB）通过路由表项和端点策略工作，配置错误会返回 HTTP 403 Forbidden 错误；而接口 VPC 端点（Amazon Bedrock 及许多其他服务）通过子网中的 ENI 和其自身的安全组工作，当这些 ENI 被删除时，会出现连接超时而非拒绝。但数据库仍可工作（VPC 本地路由）、Amazon S3 仍可工作（VPC 网关端点拥有独立的路由表项）、出站互联网连通性仍正常（NAT 网关路由完好）。只有 Bedrock AI 检查变红。  *图 22：模拟工作负载应用程序状态页面* DevOps Agent 收到 `BedrockAccessFailures` 告警并开始调查： 1. **检查端点配置**——发现接口 VPC 端点没有子网关联。 2. **搜索 CloudTrail 日志**——找到 `ModifyVpcEndpoint` API 调用，包括移除子网关联的执行者和时间。 3. **映射资源关系**——使用其拓扑结构识别 EC2 到 Bedrock 接口 VPC 端点的依赖。 4. **识别根因**——两个子网关联从 Bedrock Runtime 接口 VPC 端点被移除，导致处理流量的 ENI 被删除，而端点本身仍处于“可用”状态。 图 23 和图 24 展示了调查时间线和根因分析。查看根因后，您可以生成修复计划以了解如何解决问题。图 25 展示了详细说明修复步骤（AWS CLI 命令）的修复计划。  *图 23：DevOps Agent 调查时间线*  *图 24：DevOps Agent 根因分析*  *图 25：DevOps Agent 修复计划* 应用修复后，模拟工作负载应用程序页面将显示 Bedrock AI 状态恢复为绿色 **Connected**。 ## 超越基础：复杂网络场景 本文中的四个场景涵盖了基础网络概念，但实际生产环境更为复杂。请回想开头的场景：支付服务在业务工作负载账户中无法访问共享服务账户中的共享数据库，原因是 AWS Transit Gateway 路由表关联在当晚的一次网络迁移中被错误切换，导致两个 VPC 之间的流量被阻断。上述配置如图 26 所示。  *图 26：DevOps Agent 多账户场景示意图* 配置多账户访问后，DevOps Agent 可以跨多个区域和账户检索运营数据，并以与处理四个简单案例相同的方式进行调查。它会映射 Transit Gateway 拓扑结构，检查路由表的关联和传播状态，并识别指向错误路由表的关联。修复计划会明确告诉您需要重新关联哪个路由表以及在哪个附件上。图 27 显示了识别根因（跨两个账户的 Transit Gateway 路由表关联错误）的过程。图 28 展示了详细说明修复步骤（AWS CLI 命令）的修复计划。  *图 27：DevOps Agent 根因分析*  *图 28：DevOps Agent 修复计划* ## 进一步考虑 在生产环境中，单次基础架构变更可能同时触发多个告警。例如，删除 NAT 网关路由可能同时触发外部连通性、Amazon S3 和 Amazon Bedrock 告警（如果这些服务也依赖出站访问）。在 AWS Lambda 函数中添加关联逻辑（例如，使用 [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) 缓冲告警，设置 60 秒窗口并按应用程序分组）可防止重复调查堆积。 本设计中的 Amazon SNS 主题只有一个订阅者（Webhook Lambda 函数），但您可以添加电子邮件、[Amazon SQS](https://aws.amazon.com/sqs/) 或 HTTP 订阅者，而无需更改任何告警定义。如果您已经拥有使用 CloudWatch 告警和 SNS 主题驱动的现有监控和告警系统，可以将 Webhook Lambda 作为附加订阅者加入，从而在不干扰当前工具链的情况下让 DevOps Agent 获得可见性。对于多账户环境，其他账户中的 CloudWatch 告警可以直接发布到中心 Amazon SNS 主题，为您提供通往 DevOps Agent 的单一管道。 需要再次强调的是，DevOps Agent 生成修复计划，但不会自动更改您的 AWS 环境。任何修复步骤仍需人工操作。在设置期间连接的外部数据源同样适用于调查过程中： - 如果连接了 [遥测源](https://docs.aws.amazon.com/devopsagent/latest/userguide/configuring-capabilities-for-aws-devops-agent-connecting-telemetry-sources-index.html)，DevOps Agent 可以在根因分析中提取指标和跟踪。 - 如果连接了 [CI/CD 管道](https://docs.aws.amazon.com/devopsagent/latest/userguide/configuring-capabilities-for-aws-devops-agent-connecting-to-cicd-pipelines-index.html)，它可以关联最近的部署与故障时间线。 - 如果配置了 [MCP 服务器](https://docs.aws.amazon.com/devopsagent/latest/userguide/configuring-capabilities-for-aws-devops-agent-connecting-mcp-servers.html)，您可以通过模型上下文协议公开内部 API、运行手册数据库或任何自定义数据源。DevOps Agent 在调查过程中会调用这些工具（当数据相关时）。 ## 清理 要移除所有资源，请遵循 [删除堆栈](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-delete-stack.html) 的说明。堆栈删除将移除所有资源，包括 VPC、子网、路由表、安全组、端点、EC2 实例、RDS、ALB、SNS 主题、Lambda 函数和 IAM 角色。 ## 结论 本文逐步介绍了四个网络场景，在这些场景中，AWS DevOps Agent 自动调查故障并生成修复计划，为您的团队提供清晰、可操作的根因分析以及分钟级（而非数小时的手动日志关联）的现成修复方案。每个场景都演示了不同的故障排查模式，因此您可以将相同方法应用于自己的环境。您已经看到 DevOps Agent 如何关联 VPC 流日志与 CloudTrail API 变更以发现被删除的安全组规则，如何映射路由表配置以识别缺失的 NAT 网关路由，如何比较多层策略以隔离 VPC 网关端点限制，以及如何区分端点可用性状态以捕获接口端点子网移除。除了这些基础场景外，DevOps Agent 还可以扩展到具有多账户访问、第三方可观测性集成和自定义 MCP 服务器的复杂环境。 立即按照 [使用 AWS DevOps Agent 的入门指南](https://docs.aws.amazon.com/devopsagent/latest/userguide/getting-started-with-aws-devops-agent.html) 开始自动化您的应急响应。 ## 关于作者 **Salman Ahmed** —— Salman 是 AWS 的资深技术客户经理。他专注于指导客户完成 AWS 解决方案的设计、实施和支持。结合其网络专长与探索新技术的热情，他帮助组织成功踏上云之旅。工作之余，他喜欢摄影、旅行以及观看喜爱的体育团队。 **Ankush Goyal** —— Ankush 是 AWS 企业支持的高级技术客户经理，专注于帮助旅游和酒店行业的客户优化其云基础设施。凭借超过 20 年的 IT 经验，他专注于利用 AWS 网络服务推动运营效率和云采用。Ankush 热衷于交付有影响力的解决方案并赋能客户简化其云运营。

标签：API变更历史, AWS, CloudFormation, CloudWatch 告警, DevOps Agent, DPI, NAT网关, SEO: AWS网络故障, SEO: AWS自动化响应, SEO: CloudWatch 自动化, SEO: DevOps Agent, SEO: 网络事件自动化, SRE, Transit Gateway, VPC, 云端运维, 偏差过滤, 告警自动处理, 多账户网络, 安全组, 接口端点, 根因分析, 漏洞利用检测, 监控与响应, 网络ACL, 网络事件响应, 网络故障排查, 网络流量分析, 网络调试, 自动化, 路由表