Eclipse Dataspace Components on AWS: Cost optimization strategies

Summary

Deploying Eclipse Dataspace Components (EDC) connectors on AWS presents challenges in forecasting infrastructure expenses without clear benchmarks. Estimated costs differ substantially between business-critical setups and non-critical environments based on compute and database sizing. A business-critical configuration relying on Amazon Aurora PostgreSQL db.r6g.large and standard Amazon ECS with AWS Fargate totals an estimated 387.00 USD monthly in the eu-south-2 region. Sizing down to db.t4g.medium and switching to AWS Fargate Spot lowers the non-critical monthly expense to 164.00 USD, representing a 58% reduction. Core cost drivers remain baseline infrastructure components, while storage, API calls, and data transfers contribute marginally under baseline assumptions.

Context

Organizations deploying Eclipse Dataspace Components connectors on AWS struggle to predict and control infrastructure expenses without baseline benchmarks for sizing, configuration, and long-term planning.

Approach / What changed

Evaluate participant-side EDC connector architectures against business-critical and non-critical workload scenarios, rightsizing Amazon Aurora PostgreSQL instances and leveraging AWS Fargate Spot compute to optimize costs across Well-Architected Framework pillars.

Takeaways

• Amazon Aurora PostgreSQL and Amazon ECS compute represent the primary cost drivers for EDC deployments rather than usage-based charges like API Gateway and S3.
• Using db.t4g.medium and AWS Fargate Spot for non-critical workloads reduces estimated monthly connector infrastructure costs from $387.00 to $164.00, a 58% reduction.
• AWS Graviton-based instances such as r6g and t4g families provide improved price-performance and energy efficiency per watt compared to equivalent x86 instances.

Related reading

• Grab · Jan 6, 2020

  Plumbing At Scale

  Grab's backend services process terabytes of data ingress per hour, generating recurring needs for stream transformations, joins, and time-windowed aggregations across diverse workloads. To support these asynchronous processing patterns across their Go ecosystem, the Coban team developed a managed, NoOps event sourcing and stream processing platform. The architecture packages stateless processing pipelines as Kubernetes deployments on AWS, polling Kafka event logs and using ScyllaDB as a shared metastore for stateful needs like deduplication and windowing. Stream processing pods combine ingestion triggers, a worker pool runtime, and user-provided domain logic plugins with customizable failure handling. This infrastructure scales to handle over 300 billion events weekly while maintaining workload isolation and elastic autoscaling.

  Karan Kamath

• Grab · Jul 24, 2025

  The evolution of Grab's machine learning feature store

  Grab redesigned its initial machine learning feature store, Amphawa, to address high-dimensional data, complex entity retrieval, and versioning challenges during feature updates. The new architecture adopts a feature-table model where data scientists output Parquet datasets to Amazon S3 using Spark, which are then atomically ingested into Amazon Aurora PostgreSQL via a reverse ETL workflow. To prevent noisy-neighbor contention and optimize infrastructure costs, the platform utilizes Aurora's distributed storage to separate reads from writes. Grab pairs Aurora Serverless on writer nodes to scale up during daily batch ingestion with Provisioned instances on read replicas for steady serving traffic.