在您的VPC中部署开源区域可用性工具
内容提要
AWS推出两款开源方案，将区域可用性数据部署在自有VPC内。Capability Insights提供每24小时自动刷新的仪表板，覆盖服务、API和CloudFormation资源类型。Workload Analysis扫描CloudTrail日志和CloudFormation堆栈，将200多项服务缩小到账户实际使用的20至30项，把区域扩展差距分析从数周缩短到30分钟。
延伸解读
部署前提与网络配置要点
文章明确列出了部署前需满足的条件：VPC需启用DNS解析和主机名，并准备一个公有子网（用于仪表板和API访问）和一个私有子网（无互联网路由，用于VPC内Lambda）。两个子网都需通过网关VPC端点路由到Amazon S3。此外，需安装配置AWS CLI、Node.js v24.18.0，并有一个用于部署资产的S3桶。若需使用Workload Analysis，还需确保CloudTrail日志已存储在S3桶中。这些前提直接影响部署能否成功，建议提前核对。
两种部署方式的选择
文章提供了自动化与手动两种部署路径。自动化方式通过npm run deploy脚本完成构建、参数提示、堆栈部署、网站上传和初始数据同步，适合快速上手。手动方式则面向仅允许使用原生AWS工具的组织，需手动上传Lambda代码、执行CloudFormation部署命令、同步网站资产并触发初始数据同步。两种方式最终效果一致，选择取决于团队对工具链的管控要求。
Workload Analysis如何缩小分析范围
Workload Analysis通过并行分析CloudTrail日志和CloudFormation堆栈来识别账户实际使用的服务。CloudTrail分析器利用Athena查询最近N天（默认30天）的API调用记录，CloudFormation分析器则检查所有活动堆栈中的资源类型和属性值。两者结果经Usage Decorator与完整目录取交集后，将200多项服务缩小到账户实际运行的20至30项。文章举例说明，原本需数周的差距分析可缩短为30分钟审查，且能追溯到具体堆栈和属性配置。
个性化结果的使用与清理
分析完成后，仪表板可在完整目录与“My Stuff”视图间切换，仅显示账户使用的服务和资源。通过API可获取带使用归因的过滤结果，包括哪些堆栈部署了每种资源类型及使用的属性配置。文章以计划扩展至欧洲（苏黎世）区域为例，说明可查看这28项服务的可用性、计划上线日期或无路线图条目，从而评估等待、绕行或更换区域。清理时需先删除Usage Analysis堆栈，再清空网站桶并删除主堆栈，也可运行npm run teardown一键完成。
Q&A
AWS 区域可用性数据通常怎么获取？为什么还需要部署到自己的 VPC 里？
AWS 在 Capabilities by Region 页面发布区域可用性数据，也可以通过 Amazon S3 集成到流水线，或用 AWS Knowledge MCP server 查询。但这些方式适合探索和自动化，团队希望把数据作为自己拥有的基础设施，按自己的计划刷新、放在自己的网络内、并过滤到自己的工作负载，也就是在 Amazon VPC 中、在自己的治理下运行可用性数据。
Capability Insights for AWS 这个方案具体提供什么功能？
它把区域可用性仪表板部署到你的 VPC 中，每 24 小时自动刷新。仪表板、API 和可用性数据都运行在你自己的账户里，定时刷新是唯一离开账户的调用，用于读取 AWS 发布的数据集。仪表板覆盖服务与功能（可用状态、预计上线日期、扩展计划）、API 操作（每个区域每个服务的 API 动作可用性）以及 CloudFormation 资源类型（每个区域支持哪些资源类型）。
Workload Analysis 是怎么把 200 多项服务缩小到账户实际使用的 20 到 30 项的？
Workload Analysis 作为附加的 CloudFormation 堆栈部署，以 AWS Step Functions 状态机运行三个阶段：CloudTrail Analyzer 创建指向 CloudTrail 日志桶的 Glue Data Catalog 表，再用 Athena 查询最近 N 天（默认 30 天）不同的服务/API/区域/账户组合，识别账户调用过的服务；CloudFormation Analyzer 对账户中每个活跃堆栈调用 ListStacks 和 GetTemplate，提取 AWS:: 资源类型和标量属性值，映射到服务名并记录来源堆栈，识别账户部署了什么；Usage Decorator 在两个分析器完成后，读取主能力目录并与分析器输出取交集，把个性化文件写回桶供仪表板使用。
部署 Capability Insights 需要哪些前提条件？
需要一个有权限部署 CloudFormation 堆栈（包括创建命名 IAM 角色）的 AWS 账户；安装并配置 AWS CLI；一个启用了 DNS 解析和 DNS 主机名的 VPC，包含一个公有子网（路由到互联网网关，用于仪表板和 API 访问）和一个私有子网（无互联网路由，用于 VPC 内 Lambda），两个子网都需要通过网关 VPC 端点路由到 Amazon S3；Node.js v24.18.0（含 npm 和 npx）用于自动化部署；一个用于部署资产的 S3 桶；以及一个活跃的 CloudTrail 配置，将日志存储在 S3 桶中（第二部分需要）。
部署后怎么访问这个自托管仪表板？
解决方案把网站托管在 S3 上，只能从 VPC 内访问，地址形如 http://capability-insights-website-<ACCOUNT_ID>-<REGION>.s3-website-<REGION>.amazonaws.com。因为网站没有公开访问，你需要连接到 VPC，常见方式有：使用组织现有的 VPN 或 AWS Direct Connect；在 VPC 中设置 AWS Client VPN 端点；或者 SSH 到 VPC 内的 EC2 实例并通过它代理浏览器流量。
Workload Analysis 能把区域扩展差距分析从数周缩短到 30 分钟，实际效果是什么样的？
目录覆盖 35+ 区域的 200+ 服务，但扩展规划时你只需要评估账户实际运行的 20–30 项。没有这个过滤，差距分析是数周的项目；有了它，就是 30 分钟的审查。例如一个运行典型 Web 应用的账户，应用组合过滤后从 200+ 服务、数千功能、数百 CloudFormation 资源类型，变成账户使用的 28 项服务，并带有按堆栈的归属信息，显示哪些 CloudFormation 堆栈部署了每种资源类型。
如何清理部署的解决方案？
如果部署了 Workload Analysis，先删除 Usage Analysis 堆栈：aws cloudformation delete-stack --stack-name CapabilityInsightsUsageAnalysis，再等待删除完成。然后清空网站桶（静态资产、能力数据和用量分析输出），再删除堆栈：aws s3 rm s3://capability-insights-website-<ACCOUNT_ID>-<REGION> --recursive，然后 aws cloudformation delete-stack --stack-name CapabilityInsightsForAWS。可选地删除部署资产桶。也可以运行 npm run teardown 一步删除两个堆栈并清空网站桶。
