当您在 Eclipse Dataspace Components (EDC) 连接器部署到 AWS 上时，首先面临的一个挑战是如何预测和控制所需基础设施的成本。如果没有明确的基准，就很难对工作负载规模、环境配置和长期投资做出明智的决定。

本系列博客的第 1 部分介绍了数据空间架构的基础知识以及符合国际数据空间协会 (IDSA) 标准的 EDC。第 2 部分探讨了在 Amazon Web Services (AWS) 上部署 EDC 连接器的生产就绪架构模式，讨论了卓越运营、安全性和可靠性原则。本篇（最后一部分）将介绍 AWS Well-Architected Framework 其余三个支柱：性能效率、成本优化和可持续性。

在本篇中，您将了解在 EDC 连接器部署中哪些 AWS 服务会产生成本，如何估算业务关键型和非关键型工作负载的月度成本，以及如何应用可将支出最多降低 58% 的优化策略。

了解数据空间部署中的成本驱动因素

数据空间是安全且主权的数据环境，支持跨独立组织进行数据共享。借助这些架构，您可以与外部组织协作，同时保持对数据的完全控制并遵守数据主权原则。您的基础设施成本可能会有很大差异。主要因素包括性能和可靠性要求，以及跨网络的数据量和数据速度。区分两种类型的基础设施也很重要。Dataspace Governance Authority (DSGA) 集中建立管理、身份和发现等组件。参与者自行托管其他组件，包括连接器。本博客仅关注与参与者（即数据提供者和数据使用者端）部署 EDC 连接器相关的成本。

虚构的使用假设

在深入探讨具体数字之前，这里有一些技术和操作假设，您可以将其作为自己估算的基准。

技术假设

类别 假设 理由
数据量 每个参与者 5 GB 包含 6 个月的历史数据和备份
网络流量 每个参与者每月 20 GB 参与者之间的数据传输
API 调用 每个参与者每月 100,000 次 目录查询、合同协商和数据传输
OAuth 令牌请求 每个参与者每月 1,000 次 数据平面操作的机器对机器身份验证

表 1：EDC 连接器成本估算的技术假设

操作假设

  • 单个 AWS 区域：西班牙（eu-south-2）
  • 运行时间：24/7/365
  • 增长率：基准估算中未考虑
  • 灾难恢复：仅自动备份（无跨区域复制）

部署架构和场景

图 1 显示了在 AWS 上部署生产就绪 EDC 连接器的参考架构，该架构已在系列第 2 部分中详细介绍。

生产就绪 EDC 连接器部署架构图，展示包括 Amazon ECS、Amazon Aurora、Network Load Balancer 及支持服务的 AWS 服务

图 1：生产就绪 EDC 连接器部署

本文根据工作负载的关键性考虑两种成本场景：

  • 业务关键型工作负载：针对支持关键业务功能的高可用性、性能和可靠性用例而设计。
  • 非关键型工作负载：针对可容忍中断的用例、测试环境或可接受短暂中断的生产工作负载而设计。

两种场景均遵循本系列第 2 部分中描述的架构模式，主要差异在于计算和数据库资源的规模。

成本估算：业务关键型工作负载

注意：这些估算基于上述假设，展示每项服务的相对成本贡献。您的实际成本可能因具体使用模式、数据量和区域定价而有所不同。本文重点介绍哪些组件是最高成本驱动因素，因此具有最高的优化潜力。

AWS 服务 配置 月度成本（美元）
Amazon Aurora PostgreSQL 兼容版 db.r6g.large（2 vCPU，16 GB），20 GB 存储 + 10 GB 备份 276.00
Amazon Elastic Container Service（Amazon ECS）搭配 AWS Fargate 2 vCPU，4 GB RAM，始终运行 83.00
Network Load Balancer 处理 20 GB 数据 20.00
AWS Secrets Manager 10 个密钥 4.00
Amazon Cognito 1K 次机器对机器（M2M）令牌请求 2.25
Amazon Elastic Container Registry（Amazon ECR） 2 GB 存储，10 GB 传输 1.00
Amazon API Gateway 100K 次 REST API 调用 0.40
Amazon Simple Storage Service（Amazon S3） 5 GB 标准层 0.10
总计 387.00

表 2：业务关键型 EDC 连接器部署的月度估算成本

这些估算有助于识别预算去向以及优化效果最显著的环节。在业务关键型场景中，主要成本驱动因素是 Amazon Aurora PostgreSQL。选择 db.r6g.large 配置是因为需要高内存和高性能来支持需要可靠性和速度的持续工作负载。Amazon ECS 搭配 AWS Fargate 是第二大成本贡献者，因为它需要持续运行容器以保持环境可用性。Network Load Balancer 是第三个显著的成本组件，其余服务仅占总成本的一小部分。

成本估算：非关键型工作负载

如果您运行的是开发、测试或实验环境，可以通过调整资源规模和使用 Amazon EC2 Spot 容量将成本最多降低 58%。

AWS 服务 配置 月度成本（美元）
Amazon Aurora PostgreSQL 兼容版 db.t4g.medium（2 vCPU，4 GB），20 GB 存储 + 10 GB 备份 110.00
Amazon ECS 搭配 AWS Fargate Spot 2 vCPU，4 GB RAM，始终运行 26.00
Network Load Balancer 处理 20 GB 数据 20.00
AWS Secrets Manager 10 个密钥 4.00
Amazon Cognito 1K 次 M2M 令牌请求 2.25
Amazon ECR 2 GB 存储，10 GB 传输 1.00
Amazon API Gateway 100K 次 REST API 调用 0.40
Amazon S3 5 GB 标准层 0.10
总计 164.00

表 3：非关键型 EDC 连接器部署的月度估算成本

这些数据表明，非关键型配置可以在保持相同数据吞吐量和 API 容量的同时显著降低成本。成本降低是通过使用更小、更灵活的资源实现的。Amazon Aurora PostgreSQL 仍然是主要成本驱动因素，但更小的实例类型（db.t4g.medium）显著降低了成本。从计算角度来看，使用 Amazon ECS 搭配 AWS Fargate Spot 容量与业务关键型设置相比可降低近 70% 的成本。总体而言，此配置将月度成本降低约 58%，同时保持数据吞吐量、API 调用和存储的相同假设。

成本优化的关键要点

此对比表明，两种场景中的主要成本贡献者是数据库、计算和负载均衡资源，这些属于基础设施基准成本，而非基于使用量的费用。Amazon S3、API Gateway 和数据传输费用在此数据量下对总体成本的贡献很小。这种成本结构表明，该架构可随着使用量的增加而高效扩展。随着您引入更多用例并增加数据量和数据速度，您可以从现有基础设施投资中获得更多价值，而成本不会成比例增加。

Well-Architected 支柱：性能效率、成本优化和可持续性

本系列第 2 部分介绍了 EDC 在 AWS Well-Architected Framework 卓越运营、安全性和可靠性支柱方面的最佳实践。本节介绍其余三个支柱在 EDC 部署中的应用。

性能效率

合理调整计算资源规模：将 Amazon ECS 任务定义与实际工作负载需求匹配。从较小的配置开始，根据观察到的指标进行扩展，而不是从一开始就过度配置。Amazon CloudWatch Container Insights 提供了做出明智规模决策所需的可视性。

利用 Amazon Aurora 的灵活性：对于需求模式可变的工作负载，可以考虑使用 Amazon Aurora Serverless v2，它会根据应用程序需求自动调整数据库容量。这消除了为峰值容量预置的需求，同时在高需求期间保持性能。

优化数据传输模式：设计数据平面操作以尽量减少不必要的数据移动。对于跨地理距离的大规模传输，使用 Amazon S3 Transfer Acceleration，并在适当情况下考虑数据压缩，以减少传输时间和成本。

成本优化

降低容错工作负载的计算成本：使用 AWS Fargate Spot，您可以为可容忍中断的工作负载节省高达 70% 的成本。非关键型环境、批处理和开发工作负载是理想的候选对象。实施优雅关闭处理以有效管理 Spot 中断。

降低长期存储成本：配置 Amazon S3 Lifecycle 策略，自动将不常访问的数据转移到更低成本的存储类，例如 S3 Intelligent-Tiering 或 S3 Glacier Instant Retrieval。对于 EDC 连接器部署，历史传输日志和存档资产是分层存储的良好候选对象。

监控意外成本增加：使用 AWS Cost Explorer 并设置 AWS Budgets 警报，以帮助检测意外成本增加。为 EDC 相关的 AWS 资源一致地打标签，以便准确分配成本并识别优化机会。

为可预测的工作负载锁定更低费率：对于具有可预测、稳定状态用法的业务关键型连接器，Amazon Aurora 和 AWS Fargate 的 Savings Plans 可提供相对于按需定价的显著折扣。

可持续性

优化资源利用率：更高地利用已预置的资源意味着更少的浪费。使用自动扩展策略使容量与需求匹配，并在可能的情况下关闭非生产环境（在非工作时间）。

选择高效的实例类型：AWS Graviton 实例（例如示例中使用的 r6g 和 t4g 系列）与同等的 x86 实例相比，可提供更好的性价比和能效。AWS Graviton 处理器可提高每瓦能耗的性能。

尽量减少数据移动：每次数据传输都会消耗能源。设计数据空间集成以避免冗余传输，使用联合目录在本地缓存对等方的常用目录数据，并在可能的情况下批量处理操作，以减少网络往返的总数。

摘要

通过将 AWS 基础设施合理调整为匹配实际计算和数据库容量需求，数据空间参与者可以在不影响数据安全和主权的前提下实现显著的成本节约，而这些正是数据空间的价值所在。业务关键型和非关键型工作负载配置之间的对比展示了如何有效结合 Amazon Aurora、AWS Fargate Spot 和 Amazon S3 等 AWS 服务，以平衡数据主权、性能和成本效率。

随着数据空间在各行业和地区的采用率不断提高，了解这些成本动态对于规划网络参与变得越来越重要。本系列文章中的模式和估算为规划跨组织数据战略和在 AWS 上的数据空间之旅提供了基础。

要开始使用，请评估工作负载的关键性，以确定业务关键型还是非关键型配置更适合您的需求。然后使用 AWS Pricing Calculator 估算特定数据量、区域和使用模式的成本。如需端到端参考实现，请探索 Dataspace Connector on AWS 项目，该项目将基础设施即代码与自定义 EDC 扩展和 AI 工具集成相结合。

参考资料

关于作者