新架构（全面重建）​

我们解构了 v1 的单台 EC2 主机（构建、运维、本地状态全部耦合在一起的架构），重新设计为可独立部署、独立扩展各组件的架构。

焕新的体验​

• 应用内登录 — 在自有 /login 表单中使用邮箱·密码登录。未认证的请求会在边缘被引导至登录页面。
• 3 种主题 — Cobalt（默认）· Teal · Dark 主题选择器。选择会被保存，图表和品牌标识也会随主题变化。
• 移动端响应式 — 通过顶部栏 + 底部 5 个标签 + 滑出式抽屉，在窄屏上也能使用全部功能。
• 命令面板 — 通过 Cmd-K（或 Ctrl-K）直达任意页面·资源，并可切换主题。

AI — 更快、更聪明​

• AI 助手 — 以令牌为单位流式输出回答，并以 Markdown（表格·代码·列表）呈现。问题会自动路由到相应领域（网络·成本·安全等），对话持久化保存，抽屉与全屏视图共享同一份记录。
• AI 诊断 — 以 Light / Mid / Deep 深度生成账户运维状态综合报告，并可导出为 MD · DOCX · PDF。同时提供意图与实际的（不变式）核对，以及与上一份报告对比的变化洞察。

更广的可见性​

• 拓扑 — 由 Route53 → CloudFront → LB → Target Group → 目标构成的请求流图。点击节点可进入聚焦模式 + 详情面板（复制 ARN·向 AI 提问）。
• 资源库存 — 对 EC2·Lambda·RDS·S3·VPC·IAM 等 20 多种资源进行排序·搜索·详情查看。
• EKS / Kubernetes — 集群舰队摘要与节点·Pod·Deployment 的集群内查询（只读），以及 OpenCost 安装指南。
• 成本 — 按服务的成本分解·下钻、月末预测，以及 Bedrock 模型使用量（令牌·延迟·成本·缓存节省）。
• 数据源探索 — 以**原生查询语言（PromQL/LogQL/TraceQL/SQL）**只读查询已连接的可观测性数据源。

只读运维姿态​

AWSops 专注于观察·分析·诊断运维状况，**不会变更 AWS 资源。**对于需要安装·变更的操作，我们提供脚本和指南，供用户自行执行。

使用指南​

各个新页面的使用方法请参阅指南文档：

• AWSops 简介
• 登录 · 页面布局与主题
• 仪表盘 · AI 助手 · AI 诊断

事件预扩容（ADR-010 Phase 1+2）​

为了能在大型流量事件开始之前预热资源，新增了 /event-scaling 管理员页面。从注册到脚本下载分为 4 个步骤：

1. 注册事件 — 事件名称、开始/结束时间、受影响资源标签
2. 采集历史指标 — 如果过去发生过同类事件，则通过 GetMetricData 批量采集该时段的 CloudWatch 指标（ASG·RDS·MSK·EBS·ALB）
3. AI 生成预热计划 — Bedrock Sonnet 4.6 为每种资源生成多阶段预扩容计划，并通过 PLAN_JSON 标记返回结构化结果
4. 下载 bash 脚本 — 按资源类型生成安全脚本（KEDA·HPA、Aurora 添加 Reader、MSK 分区扩展、ASG warm pool、EBS IOPS 提升）

先审后执行（mutation-by-review）​

仪表盘**不会直接执行变更操作。**脚本仅供下载，由运维人员审阅后在合适的环境（kubectl、aws cli）中自行应用。这与 ADR-029（Proposed）的变更操作门禁模型 —「AI 生成的 mutating action 只有在获得明确的人工批准后才可执行」— 保持一致。

相关文件​

Aurora 数据层基础（ADR-030 Phase 1）​

由于构建服务器和运维服务器绑定在同一台 EC2 上，AgentCore Docker 构建时 Next.js 延迟会飙升、Steampipe FDW 查询会超时。为解决此问题，ADR-030 决定转向 ECS Fargate 工作负载 + Aurora 应用状态 + 双 ECR（Dev=Private、Prod=Public）。v1.9.0 仅包含其中的 Phase 1 基础部分。

本次引入的内容​

opt-in 部署​

默认为 off。要启用，需明确指定上下文标志：

cd infra-cdk
npx cdk deploy AwsopsDataStack -c enableAurora=true
# 或使用脚本
../scripts/13-deploy-aurora.sh deploy

如此设置门禁的原因是：(1) Aurora Serverless v2 最低 0.5 ACU 计费（约 $43/月）并不适合所有环境；(2) Phase 1 dual-write 尚未引入，实际数据仍写入 data/*.json。

Steampipe 保持不变​

ADR-030 的微妙之处在于：Steampipe 是 stateless 的。FDW 实时查询 AWS API 并将结果短暂存放在内存中，因此即使容器重启也没有会丢失的「数据」。Aurora 所替代的不是 Steampipe，而是仪表盘自身在 EC2 磁盘上积累的 data/*.json（库存·Cost·内存·alert 记录·event-scaling 计划等）。

下个版本计划（Phase 1 dual-write）​

7 个源文件将获得双写路径。写入同时进入 JSON 和 Aurora 两侧，读取在7 天奇偶校验门禁通过之前继续从 JSON 侧进行：

• resource-inventory.ts、cost-snapshot.ts、agentcore-memory.ts、agentcore-stats.ts、alert-knowledge.ts、event-scaling.ts、report-scheduler.ts

ADR-029：变更操作框架（Proposed）​

事件预扩容以先审后执行的方式引入，是因为 ADR-010 Phase 3（自动执行）的门禁模型尚未确定。ADR-029 将该门禁 —「在什么条件下、以什么权限模型允许执行 AI 生成的变更操作」— 以 Proposed 状态登记，明确其为未来 Phase 3 工作的先决条件。

AI 代码审查工作流​

新增了在 PR 打开或更新时由 Claude 自动执行代码审查的 GitHub Actions 工作流（.github/workflows/claude-review.yml）。审查提示词针对 AWSops 约定（Steampipe pg Pool、basePath、SCP 阻断列等）进行了定制。

僵尸连接清理强化​

src/lib/steampipe.ts 的僵尸清理任务改为使用专用的短生命周期 Client，而不再从池中借用 connection。即使 Cost Explorer/IAM 摘要 FDW 处于 hung 状态导致整个池耗尽，清理也能继续运行。阈值也缩短到了 90 秒。

统计对比​

参考​

• ADR-010: 事件驱动预扩容（Phase 1+2 Accepted）
• ADR-029: 变更操作框架（Proposed）
• ADR-030: ECS Fargate + Aurora + 双 ECR（Accepted，Phase 1 部分实现）

告警触发 AI 诊断（ADR-009）​

当发生严重程度为 critical 的事件（incident）时，会自动执行局部 AI 诊断。

管道流程​

[CloudWatch Alarm] → SNS Topic → SQS Queue
                                    ↓
                            [EC2 Poller (15s)]
                                    ↓
[Alertmanager/Grafana/Generic] → POST /api/alert-webhook
                                    ↓
                            [alert-correlation.ts]
                                    ↓
                         [alert-diagnosis.ts (AI)]
                                    ↓
                          [Slack/SNS 发送]

支持的来源​

关联分析引擎​

src/lib/alert-correlation.ts 将各个告警分组为事件（incident）：

范围受限的自动诊断​

与完整的 15 部分诊断不同，它仅限于触发告警的范围，1~2 分钟内即可完成：

1. 构建 AlertContext — 提取受影响的服务/资源/命名空间、触发时刻（since）
2. 范围受限采集 — 以 since 为基准 ±10 分钟过滤 CloudWatch 指标，仅限相关资源
3. 选择相关部分 — 仅执行 Compute / Network / Container 等 3~5 个部分
4. 变更检测 — 对比 Terraform state / CloudTrail 近期变更
5. Bedrock Sonnet 分析 — 推断根因 + 提出 Next Steps 建议

// src/lib/alert-diagnosis.ts (核心接口)
interface AlertContext {
  services: string[];
  resources: string[];
  namespaces: string[];
  since: Date;     // 触发时刻 − 10 分钟
  until: Date;     // 触发时刻 + 10 分钟
}

Slack 通知（Block Kit）​

按严重程度进行频道路由 + 线程更新：

• 首次告警为主消息，后续事件（追加告警合并、AI 诊断结果、已解决）作为同一线程内的 reply
• Webhook 模式和 Bot Token 模式均支持线程（复用 thread_ts）
• 收到 CloudWatch OK 或 Alertmanager resolved 时发送 ✅ 已解决通知

HMAC 认证​

共享密钥存储在 data/config.json 的 alertWebhookSecret 中：

curl -X POST https://awsops.example.com/awsops/api/alert-webhook \
  -H 'X-Alert-Source: generic' \
  -H "X-Signature-256: sha256=$(printf '%s' "$BODY" | openssl dgst -sha256 -hmac "$SECRET" | awk '{print $2}')" \
  -H 'Content-Type: application/json' \
  -d "$BODY"

告警知识库​

诊断记录会永久保存在 data/alert-diagnosis/ 下：

可在 UI 的 Knowledge Base 标签页中搜索过去的类似事件，当发生新事件时会基于相似度自动推荐。

文档大幅扩充​

新增 ADR 18 篇（011-028）​

将 v1.8.0 中新增功能的设计决策正式化：

新增 Runbook 5 篇​

可在实际运维场景中使用的故障排查/配置指南：

• alert-pipeline-troubleshoot.md — Webhook 收不到时、关联分析无法生成事件时、Slack 不显示时
• cache-warmer-operations.md — 缓存预热器调试、查询的添加/移除
• cognito-auth-troubleshoot.md — Lambda@Edge、HttpOnly Cookie、OAuth2 回调问题
• deploy-flow.md — 11 步部署脚本运维手册
• multi-account-setup.md — Aggregator 配置、跨账户 IAM 角色、验证流程

新增模块 CLAUDE.md 11 个​

将各源码模块的职责/规则/主要文件整理为 Claude 上下文文件：

Web 指南扩充​

在 Docusaurus 指南中反映了 v1.8 的功能：

• monitoring/ai-diagnosis.md — 15 部分诊断、导出格式（DOCX/MD/PDF/PPTX）、调度、成本控制技巧
• monitoring/alerts.md — 告警管道整体流程、HMAC、关联分析、Slack 线程、知识库
• intro.md — 反映 40 页面 / 18 API / 11 AI 路由，新增「AI 综合诊断 & 告警管道」功能块
• faq/troubleshooting.md — Slack 通知失败 / AI 诊断部分失败案例
• 韩语（docs/）+ 英语（i18n/en/docusaurus-plugin-content-docs/current/）双语均已更新

Bug 修复亮点​

主要文件变更​

版本对比​

参考​

• ADR-009: 告警触发 AI 诊断
• ADR-012: SNS 通知策略
• ADR-013: 自动采集调查代理
• ADR-020: HMAC Webhook 认证

外部可观测性集成（7 种）​

在 AWS 数据之外，还可将现有可观测性平台作为数据源对接。

• /datasources — 数据源 CRUD · 连接测试 · 认证配置
• /datasources/explore — 直接执行查询 + AI 查询生成（自然语言 → PromQL/LogQL/TraceQL/SQL）
• AI 助手的 datasource 路由会自动分类外部指标相关问题（AI 路由从 10 → 11 扩展）

AI 综合诊断（15 部分）​

• Bedrock Opus 自动将整个基础设施分析为 15 个部分 — 以成本/安全/稳定性为核心
• DOCX · Markdown · 浏览器 Print-to-PDF 导出
• 每周/双周/每月自动调度（report scheduler）
• 打印用报告页面 /ai-diagnosis/report（A4 分页）

安全（SSRF 防范）​

• datasource-client.ts 的 URL 验证保护包括 AI 路由在内的所有外部 fetch 路径
• 基于 allowlist 的私有网络访问控制 + IPv6 私有/链路本地（fc00::/7、fe80::/10）检测
• 数据源查询和 AI 查询生成仅限管理员使用

其他​

• 多路由合成引入 Converse Stream API + AgentCore 响应打字效果
• 自动清理僵尸 PostgreSQL 连接，通过监控查询时间范围过滤防止 pg pool 耗尽
• EKS Access Entry 状态显示 + kubeconfig 注册、EKS 服务资源标签页

AI 综合诊断焕新​

原 /diagnosis 路径变更为 /ai-diagnosis，整体 UI 焕然一新。

Before / After​

3 种导出格式​

DOCX — 基于 docx 包的 A4 专业报告：

• 封面（标题、健康评分、账户别名、日期）
• 目录（超链接、Heading 1-3）
• 各部分强调色（成本=绿色、安全=红色、网络/EKS=紫色、闲置/MSK=橙色）
• Markdown 解析（标题、表格、列表、引用、行内代码/粗体/斜体）

Markdown — 将所有部分合并为单个 .md 文件导出。

PDF — /ai-diagnosis/report 专用打印页面：

• 白色背景 A4 布局，CSS @media print 分页
• 通过「打印 / 保存为 PDF」按钮使用浏览器 Print-to-PDF

// src/lib/report-docx.ts (主要结构)
const doc = new Document({
  sections: [
    coverPage(title, healthScore, accountAlias, date),
    tableOfContents(),
    ...sections.map(s => sectionPage(s, accentColor)),
  ],
});
const buffer = await Packer.toBuffer(doc);

定时报告​

// src/lib/report-scheduler.ts
type Schedule = {
  enabled: boolean;
  frequency: 'weekly' | 'biweekly' | 'monthly';
  dayOfWeek?: number;   // 0=周日 ~ 6=周六
  dayOfMonth?: number;  // 1~28
  hour: number;         // 以 KST 为准
  language: 'ko' | 'en';
};

在 UI 中切换 ON/OFF、设置频率/星期/时间/语言后，报告会自动生成并上传到 S3。

6 种 Auto-Collect 代理​

用于自动化 AI 综合诊断报告数据采集的专用代理。每个代理从多个来源并行采集数据，并实时流式传输采集状态。

// src/lib/collectors/types.ts
export interface Collector {
  collect(send: SendFn, accountId?: string, isEn?: boolean): Promise<CollectorResult>;
  formatContext(data: CollectorResult): string;
  analysisPrompt: string;
  displayName: string;
}

FinOps MCP Lambda​

Cost Gateway 新增了 5 个 FinOps 工具。

所有工具都支持通过 target_account_id 参数进行跨账户查询。

EKS/K8s UX 大幅改进​

集群访问管理​

新功能​

Bug 修复​

• 修正 external_ip → external_ips 列名（服务 0/0 的 bug）
• 修复 EC2 IAM Role ARN 截断问题（SQL || 运算符与过滤冲突）
• 防止点击 Register 时触发集群过滤切换（stopPropagation）
• 注册后通过轮询确认连接（5 次 × 3 秒）

Benchmark：Powerpipe Exit Code 2 处理​

当基准测试控制项存在告警时，Powerpipe 会以 exit code 2 退出。这是正常行为，但原有代码将其视为异常退出。

# 忽略 exit code，以输出文件的有效性来判断
powerpipe benchmark run ... > "${tmpFile}" 2>"${errorFile}"; \
if [ -s "${tmpFile}" ]; then
  mv "${tmpFile}" "${resultFile}" && echo "done" > "${statusFile}";
else
  echo "error" > "${statusFile}";
fi

基础设施：S3 报告上传 + update-infra 脚本​

S3 策略​

CDK 栈中新增了 EC2 角色的 S3 权限：

// infra-cdk/lib/awsops-stack.ts
ec2Role.addToPolicy(new iam.PolicyStatement({
  actions: ['s3:PutObject', 's3:GetObject'],
  resources: [`arn:aws:s3:::awsops-deploy-${this.account}/reports/*`],
}));

update-infra 脚本​

无需替换 EC2 即可安全更新 CDK 栈的 00-update-infra.sh 脚本：

1. 读取现有栈参数 — 从 CloudFormation 保留当前值
2. 恢复 CDK 上下文 — 从在线基础设施重新提取 VPC、TGW、域名等
3. cdk diff 预览 — 警告是否会替换 EC2
4. 部署 — 使用 --no-rollback 安全部署

版本对比​

主要文件变更​

外部数据源管理​

您可以采用与 Grafana 数据源管理类似的方式，在 AWSops 中直接连接并查询外部可观测性（Observability）工具。

支持的 7 种数据源​

功能详情​

认证配置示例​

支持 4 种认证方式，可根据数据源类型选择合适的方式：

// src/lib/datasource-client.ts
type AuthType = 'none' | 'basic' | 'bearer' | 'custom-header';

// Basic Auth → Authorization: Basic base64(user:pass)
// Bearer Token → Authorization: Bearer <token>
// Custom Header → 自定义头名称: 值

config.json 数据源配置​

通过在 data/config.json 中添加 datasources 数组来管理数据源：

{
  "costEnabled": true,
  "agentRuntimeArn": "arn:aws:bedrock-agentcore:...",
  "datasources": [
    {
      "id": "prom-1",
      "name": "Production Prometheus",
      "type": "prometheus",
      "url": "https://prometheus.example.com:9090",
      "authType": "bearer",
      "authConfig": { "token": "***" },
      "isDefault": true
    },
    {
      "id": "ch-1",
      "name": "Analytics ClickHouse",
      "type": "clickhouse",
      "url": "https://clickhouse.example.com:8443",
      "authType": "basic",
      "authConfig": { "username": "reader", "password": "***" }
    }
  ]
}

安全：SSRF 防护​

在向外部 URL 发送请求之前，会应用一层验证来防止 SSRF（Server-Side Request Forgery，服务器端请求伪造） 攻击。

// src/lib/datasource-client.ts (简化版)
function validateUrl(url: string): void {
  const parsed = new URL(url);
  const hostname = parsed.hostname;

  // 拦截私有 IP 网段
  const privatePatterns = [
    /^10\./,                          // 10.0.0.0/8
    /^172\.(1[6-9]|2\d|3[01])\./,    // 172.16.0.0/12
    /^192\.168\./,                     // 192.168.0.0/16
    /^127\./,                          // Loopback
    /^169\.254\./,                     // Link-local
    /^0\./,                            // Current network
  ];

  // 拦截 Cloud metadata endpoint
  if (hostname === '169.254.169.254') {
    throw new Error('SSRF blocked: cloud metadata endpoint');
  }

  for (const pattern of privatePatterns) {
    if (pattern.test(hostname)) {
      throw new Error(`SSRF blocked: private IP range (${hostname})`);
    }
  }
}

安全：ClickHouse SQL 注入防范​

ClickHouse 查询不会将用户输入直接插入字符串，而是使用参数化查询：

// src/lib/datasource-client.ts — ClickHouse 查询执行

// 危险: 直接字符串插值 (不使用)
// const query = `SELECT * FROM logs WHERE service = '${userInput}'`;

// 安全: 参数化查询
const response = await fetch(`${url}/?param_service=${encodeURIComponent(service)}`, {
  method: 'POST',
  body: `SELECT * FROM logs WHERE service = {service:String}`,
  headers: { 'Content-Type': 'text/plain' },
});

PromQL 查询示例​

在 Prometheus 数据源中使用 PromQL 查询指标的示例：

# 最近 5 分钟的 CPU 使用率 (按 Pod)
rate(container_cpu_usage_seconds_total{namespace="production"}[5m])

# 内存使用量排名前 10 的 Pod
topk(10, container_memory_working_set_bytes{namespace="production"})

# HTTP 请求错误率 (5xx)
sum(rate(http_requests_total{status=~"5.."}[5m]))
  / sum(rate(http_requests_total[5m])) * 100

// 通过 API 执行 PromQL
const response = await fetch('/awsops/api/datasources', {
  method: 'POST',
  body: JSON.stringify({
    action: 'query',
    datasourceId: 'prom-1',
    query: 'rate(container_cpu_usage_seconds_total{namespace="production"}[5m])',
  }),
});

Dynamic VPC CIDR​

CDK 栈中的 VPC CIDR 现在可以通过上下文参数进行配置。

Before / After​

# 默认 VPC CIDR (10.10.0.0/16)
cdk deploy -c newVpcCidr=10.10.0.0/16

# 自定义 VPC CIDR + 多个 TGW 路由
cdk deploy \
  -c newVpcCidr=10.20.0.0/16 \
  -c tgwRouteCidrs=10.10.0.0/16,10.30.0.0/16,172.16.0.0/12

数据源诊断代理​

新增了用于系统化诊断外部数据源连接问题的专用代理。AI 路由中新注册了 priority 11 的 datasource 路由。

诊断代理检查的项目：

• 网络：目标主机是否可达、防火墙/安全组配置
• 认证：凭证有效性、令牌过期、权限不足
• SSL/TLS：证书有效性、过期、证书链问题
• DNS：主机名解析失败、DNS 传播延迟

版本对比​

主要文件变更​

借助 Converse Stream API 实现实时合成​

多路由响应合成从伪分块转换为真正的令牌流式传输。

Before / After​

代码变更​

Before — synthesizeResponses() + simulateStreaming():

// src/app/api/ai/route.ts (v1.7.0)
const synthesized = await synthesizeResponses(
  lastMsg, successful, modelKey, clientLang
);
// 将完成的文本按 50 字符切分做伪流式传输
await simulateStreaming(synthesized, send);

After — synthesizeResponsesStreaming() + ConverseStreamCommand:

// src/app/api/ai/route.ts (v1.7.1)
const synthesized = await synthesizeResponsesStreaming(
  lastMsg, successful, send, modelKey, clientLang
);
// send() 回调在每个 contentBlockDelta 时立即发送 chunk

synthesizeResponsesStreaming() 核心逻辑:

const response = await bedrockClient.send(new ConverseStreamCommand({
  modelId,
  system: [{ text: systemPrompt }],
  messages: [{ role: 'user', content: [{ text: synthesisPrompt }] }],
  inferenceConfig: { maxTokens: 4096 },
}));

for await (const event of response.stream) {
  if (event.contentBlockDelta?.delta?.text) {
    const text = event.contentBlockDelta.delta.text;
    fullContent += text;
    send('chunk', { delta: text });  // 立即发送令牌
  }
}

打字效果（simulateStreaming）​

由于 AgentCore Gateway 会一次性返回完整文本，因此需要模拟打字效果。

// src/app/api/ai/route.ts
const CHUNK_SIZE = 50;     // 每个分块 50 字符
const CHUNK_DELAY_MS = 15; // 分块间 15ms 延迟

async function simulateStreaming(
  text: string,
  send: (event: string, data: any) => void,
): Promise<void> {
  for (let i = 0; i < text.length; i += CHUNK_SIZE) {
    const chunk = text.slice(i, i + CHUNK_SIZE);
    send('chunk', { delta: chunk });
    if (i + CHUNK_SIZE < text.length) {
      await new Promise(r => setTimeout(r, CHUNK_DELAY_MS));
    }
  }
}

应用位置（3 处）：

1. 单个 AgentCore Gateway 响应 — 对完整文本应用打字效果
2. 多路由合成（v1.7.0） — 应用于 synthesizeResponses() 结果（v1.7.1 中已由 Converse Stream 替代）
3. 多路由单一成功 — 仅有 1 个 Gateway 成功的情况

聊天气泡宽度稳定化（PR #8）​

修复了 SSE 流式传输过程中聊天气泡宽度突然变化的问题。

Before — 宽度跳变:

<div class="max-w-5xl rounded-lg px-4 py-3 ...">
  <!-- 内容短时较窄，内容变长时突然变宽 -->
</div>

After — 宽度稳定:

<div class="w-full max-w-5xl rounded-lg px-4 py-3 ...">
  <!-- 从一开始就用 w-full 占满最大宽度，用 max-w-5xl 限制上限 -->
</div>

监控查询时间范围过滤​

修复了没有时间范围限制的监控查询通过 Steampipe API 拉取全部历史数据、占满 pg pool 全部 5 个连接的问题。

3 种流式模式概览​

在 v1.7.1 中，AWSops AI 响应会根据场景使用 3 种流式模式。

多账户架构 (PR #6)​

通过 Steampipe Aggregator 模式在单一仪表板中管理多个 AWS 账户。只需修改 data/config.json 的 accounts[] 数组，无需改动代码即可添加账户。

config.json 结构​

{
  "accounts": [
    {
      "accountId": "111111111111",
      "alias": "Host",
      "connectionName": "aws_111111111111",
      "region": "ap-northeast-2",
      "isHost": true,
      "features": {
        "costEnabled": true,
        "eksEnabled": true,
        "k8sEnabled": true
      }
    },
    {
      "accountId": "222222222222",
      "alias": "Staging",
      "connectionName": "aws_222222222222",
      "region": "ap-northeast-2",
      "isHost": false,
      "features": {
        "costEnabled": false,
        "eksEnabled": false,
        "k8sEnabled": false
      }
    }
  ]
}

安全修复（25 项）​

按三级严重程度分类，修复了 25 项安全问题。

CRITICAL 详情：

HIGH 详情：

实时 Bedrock 流式传输​

以块（chunk）为单位实时发送 Bedrock 响应。

缓存预热​

为改善仪表板加载速度，引入了后台缓存预热。

客户 Logo 自定义​

在 data/config.json 中配置客户 Logo 后，无需重启服务器，1 分钟内即可生效。

{
  "customerLogo": "/logos/customer-logo.png",
  "customerName": "Customer Corp",
  "customerLogoBg": "#ffffff"
}

• 将 Logo 文件放置在 public/logos/ 目录
• 仅通过修改 config 即可切换品牌 — 无需改动代码

版本对比​

多语言支持 (i18n)​

基于 React Context + localStorage，无需 URL 路由即可切换语言。该设计不会与 Next.js 的 basePath: '/awsops' 冲突。

翻译范围：

• 全部 35 个页面的文本
• Header、Sidebar 菜单标签
• AI 状态消息（分析中、Gateway 连接中、完成等）
• DataTable 列标题
• StatsCard 标签

Bedrock 监控（/bedrock）​

通过 CloudWatch 指标和 AWSops 应用自身的 token 追踪来监控 Bedrock 各模型的用量。

Docusaurus 用户指南​

在 web/ 目录中搭建了基于 Docusaurus 的用户指南站点。

版本对比​

AgentCore Memory Store​

引入了按用户保留 365 天对话历史的 Memory Store。存储/检索逻辑在 src/lib/agentcore-memory.ts 中管理。

AgentCore 页面集成：

• 6 个 StatsCard：总调用次数、平均响应时间、各 Gateway 调用比例、各模型 token 用量
• 对话历史搜索：关键词、日期范围、按路由过滤

AI 页面集成：

• 在底部切换面板中查看对话历史
• 可引用之前的问题/响应上下文

新页面（4 个）​

容器成本分析​

新增了分析 ECS 和 EKS 容器成本的 2 个页面和 API。

AI 路由改进​

安全强化​

AgentCore 仪表板（/agentcore）​

可一目了然地掌握 Bedrock AgentCore Runtime 与 8 个 Gateway 状态的专用仪表板。

• Runtime 状态：通过 data/config.json 的 agentRuntimeArn 查询状态
• 8 个 Gateway 卡片：显示各 Gateway 的状态、工具数、主要功能
• 125 个工具完整列表：支持搜索、按 Gateway 过滤
• 架构图：可视化 Runtime → Gateway → Lambda 关系

Sign Out 功能​

在 Header 中添加了退出登录按钮，可安全地终止 Cognito 会话。

CloudWatch 指标表（4 个服务）​

为 4 个服务添加了专用 API 路由和 CloudWatch 指标表。全部采用相同模式（cloudwatch get-metric-data → 进度条 + 数值）。

Resource Inventory (PR #1)​

在 /inventory 页面监控 18 类资源数量的变化趋势。

• 多折线图：各资源数量变化的时间序列
• 成本影响估算：显示资源变化带来的预计费用
• src/lib/resource-inventory.ts：基于快照（data/inventory/），零额外查询
• Cost Explorer 可用性：通过 checkCostAvailability() 自动判别 MSP Payer

S3 / RDS / ElastiCache 强化​

Monitoring 强化​

• 实例详细指标视图：Date Range 选择（1h ~ 30d）
• Resource Topology：Graph/Map View 切换（React Flow）

多路由 AI 架构​

分析复合问题后同时调用最多 3 个 Gateway，并由 Bedrock 合成响应。

仪表板全面重构​

将 18 个卡片以 6x3 布局排列，并与侧边栏菜单 1:1 映射。

• 卡片底部 sub-metrics：以 18 running · 4 stopped 形式显示核心数值
• CIS Compliance Pass Rate：整体基准通过率仪表
• Monthly Cost：本月费用 + 环比（MoM）变化率
• Resource Distribution + K8s Pod Status：使用 Recharts 图表可视化

SSE 流式 AI 响应​

通过实时流式传输 AI 响应改善了 UX。

• status 事件：显示分析中 → Gateway 连接 → 工具调用各阶段
• chunk 事件：实时发送响应文本
• done 事件：最终结果 + 使用的工具 + 响应时间 + token 数
• 新增响应时间显示、剪贴板复制、相关推荐问题功能

新页面（3 个）​

VPC & Network 强化​

• VPC Resource Map：AWS 控制台风格的 4 列布局

  VPC → Subnets → Route Tables → Connections (IGW/NAT/TGW/VPN)
  

• Route Table 标签页：子网关联、路由规则表
• TGW Route Tables：Transit Gateway 路由表详情
• Resource Topology：基于 React Flow 的 Graph View / Map View 切换

EKS & Cost 强化​

EKS 改进：

• K8s Overview 节点卡片：CPU/Memory 进度条
• 节点详情：ENI 卡片 + per-ENI 流量 + Pods 表格
• EKS Explorer：Status/Node 过滤、分页

Cost Explorer 改进：

• 期间/服务过滤、Projected 月末费用、MoM Change
• Monthly Trend 折线图、Cost by Service 饼图

Gateway 拆分：Infra → Network + Container​

v1.1.0 的 Infra Gateway（41 个工具）包含的工具过多，因此将其拆分为网络和容器两个领域。

部署稳定性改进​

在部署脚本中加入了错误处理和自动检测逻辑。

测试结果：104/104 通过​

主要错误修复​

Before / After：Gateway 架构​

7 个基于角色的 Gateway​

每个 Gateway 提供针对特定领域优化的工具集。URL 在 agent.py 的 GATEWAYS 字典中管理。

19 个 Lambda 函数​

在 agent/lambda/ 目录中管理，使用 create_targets.py 批量创建 Gateway Target。

动态路由系统​

在 src/app/api/ai/route.ts 中执行 9 级优先级的关键词路由。

• agent.py：通过 payload.gateway 参数选择网关
• route.ts：9 级优先级关键词路由
• 引入 Sonnet 意图分类器（c56f557）— 关键词未匹配时通过自然语言分析选择最佳 Gateway

AI 测试结果​

为验证 Gateway 拆分的效果，进行了 104 个问题的测试。

架构概览​

用户请求由 CloudFront 接收，经过 ALB 后在 EC2 上运行 Next.js 应用，并通过 Steampipe 以 SQL 实时查询 AWS API。

CDK 基础设施迁移​

从 CloudFormation YAML 模板迁移到 AWS CDK TypeScript，以代码方式管理基础设施。

Cognito 认证​

构建了基于 AWS Cognito 的用户认证系统。

• Lambda@Edge（Python 3.12，us-east-1）— 在 CloudFront viewer-request 中验证 JWT
• 通过 OAuth2 Authorization Code flow 实现安全认证
• 使用 07-setup-cloudfront-auth.sh 脚本自动配置

AgentCore Runtime + Gateway​

基于 Amazon Bedrock AgentCore 的 AI 代理系统。

初始仪表板​

• Recharts 指标可视化 — CPU、Memory、Network 趋势
• React Flow 网络拓扑 — 展示 VPC、Subnet、Route Table 关系
• CIS 合规 — v1.5 ~ v4.0 基准自动检查（Steampipe aws_compliance 表）
• AI 路由 — Code Interpreter → AgentCore → Steampipe+Bedrock → Bedrock Direct

Claude Code 脚手架​

为提升开发效率，搭建了 Claude Code 集成环境。

• Module CLAUDE.md — 各目录的上下文文档（src/lib/CLAUDE.md、src/app/CLAUDE.md 等）
• Auto-Sync Rules — 代码变更时文档自动同步规则
• .claude/hooks/check-doc-sync.sh — 文档同步验证钩子