Eclipse Dataspace Components on AWS: Cost optimization strategies

Eclipse Dataspace Components on AWS: 成本优化策略 | AWS 架构博客

Eclipse Dataspace Components on AWS: 成本优化策略

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

该系列博客的第 1 部分介绍了数据空间架构的基础知识以及根据国际数据空间协会（IDSA）标准的 EDC。第 2 部分探讨了在亚马逊网络服务（AWS）上部署 EDC 连接器的生产就绪架构模式，讨论了运营卓越、安全性和可靠性原则。本文作为最终篇，将覆盖 AWS 架构设计框架剩余的三个支柱：性能效率、成本优化和可持续性。

在本文中，您将了解哪些 AWS 服务会推动 EDC 连接器部署的成本，如何估算关键业务和非关键工作负载的月度成本，以及如何应用可将支出减少高达 58% 的优化策略。

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

数据空间是安全且具有主权的数据环境，使独立组织之间能够共享数据。通过这些架构，您可以在与外部组织协作的同时，完全控制自己的数据并遵守数据主权原则。您的基础设施成本可能会有很大差异。主要影响因素包括性能和可靠性要求，以及网络中的数据量和传输速度。区分两种类型的基础设施也很重要。数据空间治理机构（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 部分中进行了深入探讨。

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

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

• 关键业务工作负载：专为支持关键业务功能的用例设计，确保高可用性、性能和可靠性。

• 非关键业务工作负载：专为可容忍中断的用例、测试环境或允许短暂中断的生产工作负载设计。

两种场景均遵循本文系列第二部分描述的架构模式，主要差异体现在计算和数据库资源的规模配置上。

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

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

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 内存，持续运行

83.00

网络负载均衡器

处理 20 GB 数据

20.00

AWS Secrets Manager

10 个密钥

4.00

Amazon Cognito

1000 次机器到机器（M2M）令牌请求

2.25

Amazon Elastic Container Registry

（Amazon ECR）

2 GB 存储，10 GB 传输

1.00

Amazon API Gateway

10 万次 REST API 调用

0.40

Amazon Simple Storage Service

（Amazon S3）

5 GB 标准存储

0.10

总计

387.00

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

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

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

如果您正在运行开发、测试或实验环境，通过合理配置资源并使用 Amazon EC2 Spot 容量，可将成本降低高达 58%。

Amazon Aurora PostgreSQL 兼容版

db.t4g.medium（2 vCPU，4 GB），20 GB 存储 + 10 GB 备份

110.00

Amazon ECS 搭配 AWS Fargate Spot

26.00

1000 次 M2M 令牌请求

Amazon ECR

Amazon S3

164.00

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

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

成本优化关键要点

此对比表明，在两种场景中，主要的成本来源都是数据库、计算和负载均衡资源，这些代表了基础架构成本，而非基于使用量的费用。像Amazon S3、API Gateway和数据传输费用等服务，在这些数据量级别对总体成本的贡献相对较小。这种成本结构表明，随着使用量的增加，架构能够高效扩展。当您引入更多用例并提高数据量和处理速度时，可以从现有基础设施投资中获得更高价值，而无需成比例增加成本。

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

该系列文章的第二部分涵盖了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生命周期策略，将不常访问的数据自动转移到低成本存储类别，如S3 Intelligent-Tiering或S3 Glacier Instant Retrieval。对于EDC连接器部署，历史传输日志和归档资产是分层存储的良好候选对象。

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

为可预测的工作负载锁定更低费率：对于具有可预测、稳定使用模式的关键业务连接器，Amazon Aurora和AWS Fargate的节省计划相比按需定价可提供显著折扣。

可持续性

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

选择高效的实例类型：基于 AWS Graviton 的实例（如我们在示例中使用的 r6g 和 t4g 系列）相比同等规格的 x86 实例，能提供更优的性价比和能源效率。AWS Graviton 处理器在每瓦功耗性能方面表现更出色。

减少数据传输：每次数据传输都会消耗能源。设计数据空间集成方案时应避免冗余传输，使用联邦目录（Federated Catalog）将频繁访问的对等方目录数据本地缓存，并尽可能批量操作以减少网络往返次数。

总结

通过将 AWS 基础设施规模调整为与实际计算和数据库需求相匹配，数据空间参与者可以在不牺牲数据安全性和主权等关键价值要素的前提下实现显著成本节约。关键业务负载与非关键业务负载配置的对比展示了如何有效结合 Amazon Aurora、AWS Fargate Spot 和 Amazon S3 等 AWS 服务，实现数据主权、性能和成本效率的平衡。

随着数据空间在各行业和地理区域的普及，理解这些成本动态在规划网络参与时变得越来越重要。本系列文章中的模式和估算为规划跨组织数据战略及在 AWS 上的数据空间实践提供了基础。

要开始实施，首先评估工作负载的关键性，以确定采用关键业务负载配置还是非关键业务负载配置更符合需求。然后使用 AWS 价格计算器根据具体的数据量、区域和使用模式估算成本。如需端到端的参考实现，可探索 AWS 上的 Dataspace Connector 项目，该项目结合了基础设施即代码（Infrastructure-as-Code）、自定义 EDC 扩展和 AI 工具集成。

参考资料

• https://github.com/awslabs/dataspace-connector-on-aws

• https://github.com/awslabs/minimum-viable-dataspace-on-aws

• https://aws.amazon.com/architecture/well-architected/

作者简介

'\"