规划 AWS 跨区域扩展时，真正棘手的并不是获得一张“服务支持哪些区域”的大表，而是回答一个更具体的问题：目标区域是否支持当前工作负载实际依赖的服务与能力？
Capability Insights for AWS 将区域可用性数据和分析界面部署到自己的 VPC，并按日刷新；Workload Analysis 则进一步读取账户中的实际工作负载，把无关服务从比较范围中剔除。两者结合后，区域差距分析不再是一份庞大的通用清单，而是一张与当前系统直接相关的迁移风险表。
两层数据解决两个不同问题
Capability Insights 关注的是 AWS 能力目录，可以把它理解为区域能力分析的基础数据层。它适合回答：
- 某项服务或能力在哪些区域可用；
- 源区域与目标区域之间存在哪些差异；
- 区域能力数据最近一次是什么时候刷新；
- 团队能否在不依赖外部托管控制台的情况下查询这些数据。
Workload Analysis 解决的是范围问题。假设目录中有数百项服务，而你的账户只运行了 EC2、RDS、Lambda、SQS 和少量托管分析服务，那么区域扩展评审没有必要逐项检查整份目录。更有效的计算方式是：
需要评估的差距 = 当前工作负载使用的能力 ∩ 目标区域缺失或存在差异的能力
这一步能明显减少噪声，但也要注意：“发现了某项服务”不等于“识别了所有功能依赖”。例如，同一服务中的特定实例类型、引擎版本、API 功能或配额可能仍存在区域差异。因此，自动分析适合生成候选风险清单，不能完全替代上线前验证。
自托管的价值不只是多一个仪表盘
将工具运行在 VPC 内，意味着团队可以自己控制网络入口、身份认证、日志保存和数据生命周期。对于包含账户资源清单、区域部署情况或内部系统名称的数据，这种边界尤其重要。
一个典型部署可以拆成四部分：
- Web 仪表盘：只通过内部负载均衡器、VPN、零信任网关或堡垒访问。
- 每日刷新任务：同步最新区域可用性数据，并更新本地存储。
- 工作负载扫描器：使用只读 IAM 角色查看指定账户和区域中的资源。
- 持久化存储：保存能力目录、扫描结果、差异报告及刷新时间。
自托管并不意味着完全不需要出站网络。刷新任务和扫描器通常仍要访问 AWS API。部署前应确认流量是经过 NAT、代理还是相应的 VPC Endpoint，并把允许访问的目标限制到实际需要的范围。
可以这样落地：容器化部署与每日刷新
下面是一个可改造的 Docker Compose 模板。这里明确做两个假设：项目镜像提供 serve 和 refresh 子命令，并把数据写入 /data。实际部署时，应根据项目文档替换镜像名称、命令和环境变量。
先创建 .env：
cat > .env <<'EOF'
CI_IMAGE=registry.example.com/capability-insights:latest
AWS_REGION=us-east-1
DASHBOARD_PORT=8080
EOF
再创建 compose.yaml：
services:
dashboard:
image: ${CI_IMAGE}
command: ["serve", "--listen", "0.0.0.0:8080", "--data-dir", "/data"]
restart: unless-stopped
environment:
AWS_REGION: ${AWS_REGION}
ports:
- "127.0.0.1:${DASHBOARD_PORT}:8080"
volumes:
- capability-data:/data
read_only: true
tmpfs:
- /tmp
daily-refresh:
image: ${CI_IMAGE}
entrypoint: ["/bin/sh", "-c"]
command:
- |
while true; do
refresh --data-dir /data
sleep 86400
done
restart: unless-stopped
environment:
AWS_REGION: ${AWS_REGION}
volumes:
- capability-data:/data
read_only: true
tmpfs:
- /tmp
volumes:
capability-data:
启动并检查日志：
docker compose up -d
docker compose ps
docker compose logs --tail=100 daily-refresh
示例将端口绑定到 127.0.0.1，避免直接暴露到 VPC 或公网。可以通过 SSH 隧道进行初始验证：
ssh -L 8080:127.0.0.1:8080 ec2-user@YOUR_PRIVATE_HOST
随后在本机打开 http://127.0.0.1:8080。生产环境更适合使用内部负载均衡器，并接入企业身份认证，而不是长期依赖 SSH 隧道。
运行 Workload Analysis 时，不要直接复用管理员凭证。可以为扫描任务创建专用只读角色，并从一个较小的账户和区域集合开始。建议记录每次扫描的账户、区域、时间和角色 ARN，以便解释报告来源。
把分析结果变成可执行的扩展计划
仪表盘真正有价值的输出，不应只有红黄绿状态。团队可以为每个差距补充以下字段：
- 当前依赖该能力的应用和负责人；
- 目标区域中的替代方案；
- 是否需要降级、重构或等待服务上线；
- 数据迁移和灾难恢复要求；
- 验证该差距的日期与证据；
- 对 RTO、RPO、成本和性能的影响。
采用时可以按以下顺序推进：
- 先用单个非生产账户验证资源发现的完整性；
- 将 IAM 权限收缩到只读且确实需要的 API；
- 检查每日刷新失败是否会触发告警；
- 在报告中显示数据更新时间，避免把旧数据当成当前事实；
- 对关键服务继续核查实例类型、版本、配额和功能级差异；
- 将最终差距清单纳入架构评审和区域上线门禁。
这类工具最适合充当“持续缩小范围的分析层”：它先用区域目录建立全景，再用真实工作负载过滤噪声。团队仍需对关键依赖做人工确认，但评审会从漫无目的的目录搜索，转变为围绕实际部署展开的工程决策。