ITPub博客

首页 > IT基础架构 > 服务器存储 > 在您的VPC中部署开源区域可用性工具 | Amazon Web Services

在您的VPC中部署开源区域可用性工具 | Amazon Web Services

服务器存储 作者:ITPUB社群 时间:1970-01-01 08:33:46 0 删除 编辑

在 AWS 上构建多区域架构时,一个早期就会出现的问题是:“每个 AWS 区域中有哪些服务可用?”答案会影响架构决策,从扩展到哪些 AWS 区域,到如何设计韧性。对于需要应对数据驻留要求和合规报告的团队来说,答错会带来实际后果:部署失败、合规缺口和发布延迟。

AWS 发布区域可用性数据,涵盖所有 AWS 区域中的服务、功能、API(应用程序编程接口) 和 AWS CloudFormation 资源类型。您可以在 AWS Capabilities by Region 页面上浏览这些数据,通过 Amazon Simple Storage Service (Amazon S3) 访问以进行管道集成,或使用 AWS Knowledge MCP server 查询。这些选项非常适合探索和自动化。然而,团队告诉我们,他们需要将这些数据作为自己拥有的基础设施来部署,按自己的计划刷新,在自己的网络内运行,并过滤到自己的工作负载。这意味着要以运行其余技术栈的相同方式运行可用性数据:在您的 Amazon Virtual Private Cloud (Amazon VPC) 中,在您的治理之下。

在本文中,我们介绍两个实现这种所有权的开源解决方案。Capability Insights for AWS 将一个区域可用性仪表板部署到您的 VPC 中,每 24 小时自动刷新。该仪表板、其 API 和可用性数据都在您自己的账户中运行,计划刷新是唯一离开您账户的调用,用于读取 AWS 发布的数据集。Workload Analysis 扫描您的 AWS CloudTrail 日志和 CloudFormation 堆栈,然后将 200 多个服务缩小到您的账户实际运行的 20–30 个,显著缩小了区域差距分析的范围。

结合 Capabilities by Region S3 Access Point,您现在拥有三个级别的控制:从 Amazon S3 消费、部署到您的 VPC,或过滤到您的工作负载。我们将逐步介绍如何部署每个解决方案、运行工作负载分析,并在区域扩展规划期间查看个性化结果。无论您是在构建多区域恢复策略、标准化合规报告,还是加速扩展时间表,这些解决方案都将数据及其驱动的决策置于您的边界之内。

图 1 展示了 Capability Insights for AWS 如何与您现有 AWS 账户中的 VPC 和子网集成。公有子网中的客户端通过 S3 网关端点访问仪表板,并通过 API Gateway VPC 端点调用私有 API。

图 1:Capability Insights for AWS 架构,包括私有仪表板访问和计划区域可用性数据刷新。

Amazon EventBridge 计划每 24 小时调用一次数据获取 Lambda 函数。数据获取函数在您的 VPC 之外运行,因此它通过 AWS 网络读取 AWS 发布的 S3 访问点。该函数从 AWS 发布的 Capabilities by Region S3 存储桶中拉取区域可用性数据,并将其写入您账户内的网站存储桶。仪表板应用程序通过 S3 网关端点从您的 VPC 访问网站内的数据。API Lambda 还可以通过 Lambda VPC 端点按需调用数据获取函数。部署资产存储桶仅在部署期间提供 Lambda 代码。

先决条件

要跟随操作,您需要:

  • 一个具有部署 CloudFormation 堆栈权限的 AWS 账户,包括创建命名 AWS Identity and Access Management (IAM) 角色的权限。在运行时,堆栈创建的角色使用范围权限进行 Amazon S3 对象读写访问、AWS CloudFormation 读取操作、Amazon Athena 查询、AWS Glue 和 AWS Lake Formation 目录访问、AWS Lambda 调用和 AWS Step Functions 执行。有关起始部署策略,请参阅仓库中的 documentation 文件夹。

  • 已安装并配置 AWS Command Line Interface (AWS CLI)。

  • 一个启用了 DNS 解析和 DNS 主机名的 VPC,一个公有子网(路由到互联网网关)用于仪表板和 API 访问,以及一个私有子网(无互联网路由)用于 VPC 内 Lambda 函数。两个子网都需要通过网关 VPC 端点路由到 Amazon S3。

  • Node.js v24.18.0(包含 npm 和 npx)用于自动化部署。

  • 一个用于部署资产的 S3 存储桶。

  • 一个活动的 CloudTrail 配置,将日志存储在 S3 存储桶中(第 2 部分需要)。

第 1 部分:部署自托管仪表板(Capability Insights for AWS)

Capability Insights for AWS 将可搜索的区域可用性仪表板部署到您自己的 AWS 账户中。该解决方案从 AWS Capabilities by Region S3 存储桶拉取数据,将其存储在您的 VPC 内,并通过由 Amazon API Gateway、AWS Lambda 和 Amazon EventBridge 支持的静态网站提供服务。

如果您的组织可以访问公共数据集之外的额外数据源,该解决方案也会将这些数据源纳入其中,为您提供跨您有权访问的所有 AWS 分区的统一视图。如需了解有关访问额外数据的更多信息,请联系您的 AWS 代表。

该仪表板涵盖:

  • 服务和功能:各区域的可用性状态、预期上线日期和扩展计划。

  • API 操作:每个 AWS 服务在各区域的单个 API 操作可用性。

  • CloudFormation 资源类型:各区域支持哪些资源类型。

您需要提供自己的 VPC、子网和 S3 存储桶,以便该解决方案与您现有的基础设施和安全控制集成。

克隆并安装

git clone https://github.com/aws/capability-insights-for-aws.git
cd capability-insights-for-aws
npm install

创建部署资产存储桶

创建一个阻止公共访问的 S3 存储桶,用于在部署期间存储 Lambda 代码包。我们建议将其命名为 capability-insights-assets-

部署堆栈

自动化部署:

npm run deploy

该脚本会构建所有资产、提示输入参数、部署 CloudFormation 堆栈、上传网站,并触发初始数据同步。系统会提示您输入 SourceFolders,即要拉取的数据源的逗号分隔列表。默认值为 public。

要跳过交互式提示,请将所有参数作为标志传入:

npm run deploy -- \
  --private-vpc-id vpc-0abc123 \
  --backend-subnet-id subnet-0abc123 \
  --api-access-subnet-id subnet-0def456 \
  --deployment-assets-bucket-name my-deploy-bucket \
  --source-access-point-arn arn:aws:s3:us-east-1:686591367145:accesspoint/aws-capabilities-public \
  --source-folders public
| 标志 | 描述 |
| --- | --- |
| –private-vpc-id | 启用了 DNS 解析和 DNS 主机名的 VPC ID |
| –backend-subnet-id | 无互联网路由的私有子网。需要通过网关 VPC 端点路由到 Amazon S3。 |
| –api-access-subnet-id | 路由到互联网网关的公有子网(用户访问、API Gateway VPC 端点) |
| –deployment-assets-bucket-name | 用于部署资产的 S3 存储桶 |
| –source-access-point-arn | AWS 发布的按区域划分的公有 Capabilities S3 接入点 ARN。账户 ID 686591367145 标识了托管该公有数据集的 AWS 管理账户。请按原样使用该 ARN。有关该公有数据集的详细信息,请参阅 Building automated AWS Regional availability checks with Amazon S3 。 |
| –source-folders | 逗号分隔的数据源(默认:public) |

如果您的组织要求仅使用原生 AWS 工具进行部署,请从最新版本下载 build-assets.zip 并按照以下步骤操作:

# Upload Lambda code
aws s3 cp lambda/lambdaAssets.zip s3:///lambdaAssets.zip

# Deploy the stack
aws cloudformation deploy \
  --template-file template/capability-insights.template.json \
  --stack-name CapabilityInsightsForAWS \
  --capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM \
  --parameter-overrides \
  PrivateVpcId=\
  BackendSubnetId=\
  ApiAccessSubnetId=\
  DeploymentAssetsBucketName=\
  DeploymentAssetsBucketApiLambdaFunctionCodeZipPath=lambdaAssets.zip \
  SourceAccessPointArn=arn:aws:s3:us-east-1:686591367145:accesspoint/aws-capabilities-public \
  SourceFolders=public

# Upload website assets
aws s3 sync website/ s3://capability-insights-website--/

# Trigger initial data sync
aws lambda invoke \
  --function-name CapabilityInsightsDataFetchLambda \
  --invocation-type Event /dev/null

访问仪表板

该解决方案将网站托管在 S3 上,仅可从您的 VPC 内部访问:

http://capability-insights-website--.s3-website-.amazonaws.com

由于您部署的解决方案在托管网站时不提供公有访问,因此您需要连接到 VPC。常见选项:

  • 现有 VPN 或 AWS Direct Connect :使用您组织现有的连接。

  • AWS Client VPN :在 VPC 中设置 Client VPN 端点。

  • 带 SOCKS 代理的 EC2 实例 :通过 SSH 登录到 VPC 中的实例,并通过它代理浏览器流量。

探索仪表板

连接后,仪表板提供:

  • 搜索和筛选 :按名称跨所有区域查找服务。

  • 可展开的服务详情 :选择任何服务以查看各区域中各项功能的可用性。

  • 状态指示器 :Available、Planning、Not Expanding 以及预计日期(例如,“2026 Q3”)

  • 导出 :将当前视图下载为 JSON 或 CSV,以便共享或进一步分析。

  • 设置 :查看上次同步时间并触发手动数据刷新。

图 2 展示了 Capability Insights for AWS 仪表板及其用于比较各区域服务可用性的控件。

图 2:仪表板概览,展示各区域的服务可用性以及状态指示器和导出选项。

摘要计数显示服务与功能、API 操作、CloudFormation 资源以及区域的覆盖情况。选项卡可在不同目录视图之间切换,而筛选、区域列、状态值以及展开和导出控件可帮助您检查和下载可用性数据。

此时,您已在 VPC 内拥有一个可正常工作的仪表板,每日刷新,且在正常运行期间无外部依赖。

第 2 部分通过将此目录筛选为您账户所运行的特定服务来添加个性化功能。您可以通过仪表板查看工作负载分析结果,也可以通过专用 API 端点访问这些结果。

第 2 部分:通过工作负载分析实现目录个性化

该目录涵盖 35+ 个区域中的 200+ 项服务。当您计划扩展到新区域时,无需评估所有服务,只需评估您账户所运行的 20–30 项服务。没有这一筛选,差距分析是一个耗时数周的项目;有了它,只需 30 分钟的审查。

工作负载分析作为附加的 CloudFormation 堆栈与 Capability Insights 堆栈一同部署。该管道以 AWS Step Functions 状态机的形式运行,包含三个阶段:

  • 并行分析器(两个分支并行运行):CloudTrail 分析器:创建一个指向您 CloudTrail 日志存储桶的 AWS Glue Data Catalog 表,然后运行 Amazon Athena 查询,从最近 N 天(可配置,默认 30 天)中提取不同的服务/API/区域/账户组合。这可以识别您账户调用过的服务。CloudFormation 分析器:对账户中每个活动堆栈调用 ListStacks 和 GetTemplate。提取 AWS:: 资源类型和标量属性值(字符串、数字、布尔值),将其映射到服务名称,并记录每个资源由哪个堆栈贡献。这可以识别您账户部署的内容,而不仅仅是调用的内容。

  • 使用情况装饰器在两个分析器完成后运行。它从网站存储桶读取主要能力目录(products.json、apis.json、cfn_resources.json),将其与分析器输出求交集,并将个性化文件写回存储桶,供仪表板使用。

  • 通过 Amazon EventBridge 规则进行计划执行,每日触发状态机(可配置的计划表达式),无需人工干预即可保持个性化数据的最新状态。

图 3 展示了工作负载分析组件如何协调计划分析和按需分析。

图 3:工作负载分析基础设施组件。

Amazon EventBridge 计划或按需 API 请求会启动 AWS Step Functions 状态机。工作流并行运行两个分支:CloudTrail 分析器使用 Amazon Athena 配合 AWS Glue Data Catalog 和 AWS Lake Formation 目录访问来查询活动,而 CloudFormation 分析器则检查活动堆栈。两个分支完成后,使用情况装饰器将其结果与主要能力目录合并,并将个性化数据写入 Capability Insights 网站存储桶,供仪表板和 API 使用。

部署工作负载分析

验证 CloudTrail 处于活动状态且您的日志存放在 S3 存储桶中。然后使用使用情况分析标志进行部署:

npm run deploy -- \
  --private-vpc-id vpc-0abc123 \
  --backend-subnet-id subnet-0abc123 \
  --api-access-subnet-id subnet-0def456 \
  --deployment-assets-bucket-name my-deploy-bucket \
  --source-access-point-arn arn:aws:s3:us-east-1:686591367145:accesspoint/aws-capabilities-public \
  --source-folders public \
  --enable-usage-analysis \
  --cloudtrail-bucket my-cloudtrail-logs-bucket

这将部署核心 Insights 堆栈和 Usage Analysis 堆栈,然后将它们连接起来,以便 API Lambda 可以触发分析并提供个性化结果。

| 附加标志 | 描述 |
| --- | --- |
| --enable-usage-analysis | 启用 Workload Analysis 管道 |
| --cloudtrail-bucket | 包含您的 CloudTrail 日志的 S3 存储桶 |

首次运行通常在 2–5 分钟内完成,具体取决于账户规模和活跃的 CloudFormation 堆栈数量。

检索 API 端点

使用以下命令从 dashboard 存储桶上的 API 配置文件中检索 API 基础 URL:

aws s3 cp "s3://capability-insights-website-$(aws sts get-caller-identity --query Account --output text)-$(aws configure get region)/api-config.json" - --no-progress

该命令返回类似以下的输出:

{"apiBaseUrl": "https://xxxxxxxxxx.execute-api.us-east-1.amazonaws.com/prod"}

使用 apiBaseUrl 作为专用 API 端点的基础 URL。您必须从 VPC 内部运行 API 请求,因为 API Gateway 端点是私有的。

运行分析

通过 API Gateway 端点调用 POST /analysis 来启动分析:

{
  "scope": "account",
  "analyzers": ["cloudtrail", "cloudformation"],
  "analyzerParams": {
    "cloudtrail": {
      "bucket": "my-cloudtrail-logs-bucket",
      "daysToScan": 30
    }
  }
}

Amazon EventBridge 规则每天触发后续运行。您也可以通过 dashboard 的 Settings 页面触发临时运行。

查看个性化结果

分析完成后,dashboard 会在完整目录和您的个性化 My Stuff 视图之间切换,仅显示您的账户使用的服务和资源。

GET /capabilities?usageFilter=combined&scope=account

响应包含经过筛选的产品、API 和 CloudFormation 资源及其使用归属信息,包括哪些堆栈部署了每种资源类型,以及你使用了哪些属性配置:

{
  "products": [
    {
      "productId": "amzn1.prod.abc123",
      "productName": "Amazon DynamoDB",
      "childProducts": [...],
      "regionalAvailability": { "us-east-1": "Available", "eu-west-1": "Available" }
    }
  ],
  "cfnResources": [
    {
      "serviceName": "DynamoDB",
      "resourceTypes": [
        {
          "resourceTypeName": "Table",
          "regionalAvailability": { ... },
          "usage": {
            "stacks": ["MyAppStack", "DataPipelineStack"],
            "properties": { "BillingMode": ["PAY_PER_REQUEST"] },
            "count": 2
          }
        }
      ]
    }
  ],
  "lastAnalyzedAt": "2026-05-19T08:00:00.000Z"
}

实际示例

假设有一个运行典型 Web 应用程序的账户。在没有 Workload Analysis 的情况下,控制面板会显示跨 35 个区域的 200 多项服务。应用组合筛选条件后:

  • 之前:200 多项服务、数千项功能、数百种 CloudFormation 资源类型。

  • 之后:你的账户使用的 28 项服务,并带有按堆栈归属的信息,显示哪些 CloudFormation 堆栈部署了每种资源类型。

CloudFormation 资源视图会更深入。对于你的堆栈部署的每种资源类型,你可以看到正在使用哪些属性配置,以及哪些堆栈贡献了这些配置。例如,你的 AWS::EC2::Instance 资源可能显示来自应用程序堆栈的 InstanceType: t3.medium,以及来自数据处理堆栈的 InstanceType: m5.xlarge,并且每一项都能追溯到其来源。

这种有针对性的视图意味着你的区域扩展差距分析会聚焦于你关心的 28 项服务,而不是完整目录。例如,如果你计划部署到欧洲(苏黎世)区域(eu-central-2),控制面板会显示这 28 项服务中哪些在该区域可用、哪些已有计划上线日期,以及哪些尚无路线图条目。这些结果会突出显示在区域扩展期间需要考虑的服务可用性差距。在此基础上,你可以评估自己的选项:等待计划上线、围绕不可用功能进行架构设计,或评估其他目标区域。你不再需要针对区域矩阵评估 200 多项服务,而是在浏览一个个性化列表,其中每一行都是你的堆栈会部署的内容。

清理

要删除本演练中创建的资源:

Workload Analysis(如果已部署):先删除 Usage Analysis 堆栈:

aws cloudformation delete-stack --stack-name CapabilityInsightsUsageAnalysis
aws cloudformation wait stack-delete-complete --stack-name CapabilityInsightsUsageAnalysis

自托管控制面板:清空网站存储桶(静态资产、能力数据和使用分析输出),然后删除堆栈:

aws s3 rm s3://capability-insights-website----recursive
aws cloudformation delete-stack --stack-name CapabilityInsightsForAWS

可选地删除你在设置期间创建的部署资产存储桶。此解决方案对 Lambda、S3、API Gateway、Athena 和 Step Functions 使用标准 AWS 服务定价。解决方案本身不收取额外费用。

自动清理:运行 npm run teardown,一步删除两个堆栈并清空网站存储桶。

结论

了解目标区域中有哪些可用服务,是进行韧性设计的第一步。你无法为尚未存在的服务构建多区域恢复策略。借助 Capability Insights for AWS 和 Workload Analysis,你可以在自己的 VPC 内掌握这些数据,按账户实际运行情况进行筛选,并按自己的计划刷新。

  • 克隆 Capability Insights for AWS 仓库并运行 npm run deploy,即可在 10 分钟内部署一个可用的仪表板。

  • 添加 --enable-usage-analysis,根据你账户的实际使用情况个性化定制目录。

  • 有关 CloudFormation 概念和部署指导,请参阅 AWS CloudFormation User Guide 。

  • 如需以零基础设施方式以编程方式访问原始数据,请参阅 Building automated AWS Regional availability checks with Amazon S3 。

  • 如需使用这些数据进行自动化扩展分析,请参阅 Accelerate Region expansion with the AWS Knowledge MCP server 。


转载声明:本文为转载整理,原文版权归原作者及原站点所有。

原文来源:AWS Architecture Blog

原创地址:https://aws.amazon.com/blogs/architecture/deploy-open-source-regional-availability-tools-in-your-vpc/

原文作者:Stefan Janjic;如有侵权,请联系管理员删除。

下一篇: pg_ivm 1.16 发布
请登录后发表评论 登录
全部评论

注册时间:2022-11-21

  • 博文量
    1059
  • 访问量
    546553