AWS DevOps Agent 解析：架构、设置与真实根因演示（CloudWatch + EKS）

Source: Dev.to

什么是 AWS DevOps Agent

AWS DevOps Agent 像一个 24/7 的“待命”工程师。它可以访问大量工具和数据源，从而能够：

• 发现并绘制你的 AWS 资源和应用的拓扑结构。
• 调查事件（例如 CloudWatch 警报、EKS Pod 故障）。
• 提供逐步的根因解释、缓解建议以及防范指导。

该代理 不会自动修复 问题；需要人工操作员执行推荐的操作。

架构

双控制台模型

Agent Spaces

• 定义代理可以访问的 AWS 账户、外部工具和用户的逻辑容器。
• 每个空间使用专用的 IAM 角色，授予最小必要权限。
• 信息在空间之间是隔离的——一个空间的数据对其他空间不可见。

安全

• IAM Identity Center（或外部 IdP）控制对 Web 应用的用户访问，并支持 MFA。
• 管理员可以使用已有会话直接从管理控制台启动 Web 应用。

如何最大化 Agent 的效能

集成更多功能，为代理提供更丰富的上下文：

• 多个 AWS 账户 – 连接跨账户资源。
• CI/CD 流水线 – GitHub、GitLab 等。
• MCP 服务器 – 用于扩展监控。
• 遥测来源 – Datadog、New Relic。
• 工单与聊天 – ServiceNow、Slack。
• EKS 集群 – 用于容器层面的调查。

你还可以预加载 runbooks，为代理提供自定义的调查提示。

资源发现

代理通过两种方式构建其拓扑：

1. CloudFormation 堆栈 – 自动列出所有堆栈及其资源（包括 CDK 生成的资源）。
2. 资源标签 – 通过扫描标签键/值对，发现通过控制台或 Terraform 等方式在 CloudFormation 之外创建的资源。

演示 1：调查 CloudWatch 警报

前置条件

• 能访问 us‑east‑1 区域（代理仅在该区域可用）。
• 单个独立的 AWS 账户（不需要 Organizations）。
• 基础的 CloudFormation 知识。

步骤

1. 部署 CloudFormation 堆栈（创建安全组、SSH 密钥对、运行 CPU 压力测试的 EC2 实例、用于 CPU 利用率的 CloudWatch 警报以及自动关机规则）。

   # Example snippet – replace with the full template you used
   Resources:
     StressTestInstance:
       Type: AWS::EC2::Instance
       Properties:
         InstanceType: t3.micro
         ImageId: ami-0abcdef1234567890
         KeyName: devops‑key
         SecurityGroupIds:
           - !Ref StressTestSG
         UserData: |
           #!/bin/bash
           yum install -y stress
           stress --cpu 2 --timeout 600 &

2. 等待 5–10 分钟，让警报触发（压力测试会导致 CPU 峰值）。

3. 打开 AWS DevOps Agent Web 应用（通过管理控制台或直接的 Operator Access 链接）。

4. 在 Incident Response 中，找到最新的警报并点击 Start Investigation。

   代理会自动填充调查提示，执行分析，并返回 根因（来自 stress 脚本的 CPU 过载）。

观察结果

• 当两次警报在约 40 分钟内发生时，代理有时无法定位根因，需要重新运行。
• 对于用户主动触发的事件，代理可能会省略缓解计划，因为没有可用的自动化修复。
• 代理会标记 调查缺口（例如缺少 SSH 访问或 CloudWatch 日志组），解释为何某些细节不可用。

你可以通过聊天界面用自然语言提出后续问题。

演示 2：调查 EKS Pod 错误

前置条件

• 使用 Terraform 部署的 EKS 集群以及一个故意失败的 NGINX Pod（ImagePullBackOff）。
• Agent Space 的 IAM 角色 ARN（在管理控制台的 View role permissions 中可查）。

步骤

1. 将 Agent Space 角色添加到 EKS 集群，并附加 AmazonEKSAdminViewPolicy。

   # terraform/eks_role.tf
   resource "aws_iam_role_policy_attachment" "agent_access" {
     role       = aws_iam_role.eks_cluster.name
     policy_arn = "arn:aws:iam::aws:policy/AmazonEKSAdminViewPolicy"
   }
   
   # Pass the Agent Space role ARN via a variable
   variable "agent_role_arn" {}

2. 在 terraform.vars 中填入复制的 ARN 并执行 Terraform apply。

3. 使用 Agent Space 所使用的相同标签键/值（例如 DevOps=Demo）为新创建的资源打标签。这样代理才能发现它们。

4. 在 Agent Web 应用 中，进入 Capabilities → Edit，确认标签已被识别。

5. 向代理提问：“导致 NGINX Pod ImagePullBackOff 错误的原因是什么？”

   代理会发现 EKS 资源，识别出缺失的镜像拉取密钥，并返回：

   • 根因 – 缺少镜像拉取密钥。
   • 缓解步骤 – 创建密钥并将其关联到服务账户。
   • 回滚指南 – 如果缓解措施引入新问题，如何恢复原状。

收获

• 代理通过提供精准诊断和可操作的修复建议，显著降低 平均恢复时间 (MTTR)。
• 它还能给出 防范建议（例如强制执行镜像拉取密钥策略），避免类似事件再次发生。

DevOps 工程师视角

• 安全性 – 正确配置后，代理是安全的。管理员通过受限的 IAM 角色精确控制代理可以访问的 AWS 资源和外部服务。
• 工作影响 – 代理是 助理，而非替代品。工程师仍需执行修复、设计基础设施并开发新功能。
• 未来潜力 – 接入更多数据源（如 MCP 服务器）可以进一步丰富代理的上下文，使调查更快、更全面。

AWS DevOps Agent 展示了 AI 辅助工具如何在加速事件响应的同时，将人为专业知识置于修复核心。