Sovereign Data Spaces: Architecting Cost-Effective EDC on AWS

We still under‑estimate the operational cost of “sovereign” data sharing. The conversation often stops at security and compliance – but when a consortium of organisations actually runs connectors and catalogs, predictable, optimised infrastructure matters just as much for adoption.

What changed (the signal)
A recent analysis of deploying data‑space connectors on a public cloud compared production and non‑critical configurations and called out three big cost drivers: the managed database, continuously running compute, and load‑balancing/networking. It showed material savings are possible through rightsizing, spot/interruptible compute, and lifecycle policies for storage.

What this means for enterprise architecture
The core lesson is simple but easily missed: architecture choices that preserve data sovereignty still have to be cost‑engineerable. Data‑space patterns (central governance, participant‑hosted connectors) protect policy – but they also push variability and cost to each participant. For CTOs and architects that implies three pragmatic trade‑offs:

• Stability vs cost: Always‑on containers and a provisioned relational store give predictable latency and availability, but they become the fixed monthly bill. If your use case truly needs 24×7 low latency, factor that as a deliberate business decision – otherwise consider burstable or autoscaling database and compute models.
• Operational complexity vs savings: Spot/interruptible compute and serverless DBs can reduce bills dramatically – but they add orchestration and resilience requirements (graceful shutdown, connection pooling, retry strategies). Don’t chase raw savings without investing in the operational runbook.
• Sovereignty vs centralisation: Keeping connector runtime at participant edge preserves control but multiplies resources to manage. For federations with many small participants, offering a hardened, optional managed participant runtime (operated by the DSGA or a trusted provider) can reduce total ecosystem cost while preserving policy enforcement.

Actionable architecture patterns

• Treat the database as the primary cost and risk surface: design for connection pooling, smaller instance classes initially, and evaluate autoscaling or serverless capacity for spiky contract negotiations. Move cold data and audit logs to lower‑cost, tiered storage with retention policies.
• Make compute transient by design: shift non‑critical flows (batch ingests, analytics, test environments) to interruptible instances or serverless containers; implement fast, idempotent shutdown and restart semantics.
• Instrument for economics: tag everything, export fine‑grained metrics, and set budget alerts. Use telemetry to correlate business transactions (catalog queries, contracts, transfers) with infrastructure cost so architects can justify capacity changes with data.
• Bake sustainability into design: higher utilisation often means lower energy per transaction. Select efficient CPU families and batch transfers where latency allows – those decisions reduce both cost and carbon.

A note for Indian practitioners
For Indian consortia and DPI initiatives, the tension is familiar: stringent data control plus limited budgets. Small and medium participants in India (including in the Northeast) benefit from patterns that keep per‑participant cost modest – shared governance, optional managed runtimes, and clear operational templates (IaC, CI/CD, runbooks). These reduce onboarding friction for MSMEs and educational institutions while preserving sovereignty.

Key takeaways

• Identify the few services that drive most cost (managed DB, always‑on compute, load balancing) and prioritise optimisations there.
• Start small, measure, then rightsise – don’t over‑provision for imagined peaks.
• Use interruptible compute and serverless capacity for non‑critical work, but invest in resilient shutdown/recovery patterns.
• Tag, monitor, and align budgets to business units and transaction types to make optimisation decisions defensible.
• Consider shared ecosystem offerings to lower per‑participant operational overhead while keeping governance separate.

Closing thought
Building sovereign, cross‑organisational data infrastructure is as much an economics problem as it is a technical one – the architectures that win will be those that balance control, resilience, and sustainable cost.

---

About the Author: Sanjeev Sarma is the Founder Director and Chief Software Architect at Webx Technologies. With a core focus on Generative AI integration, Cloud-Native Scalability, and Enterprise Software Architecture, he has spent over two decades driving digital transformation across Northeast India and beyond. Beyond his corporate leadership, Sanjeev is deeply invested in shaping the future of the IT industry. He serves as an Industry Expert on the Board of Studies for Assam Don Bosco University’s School of Technology, advises state technology committees, and actively mentors emerging tech startups at STPI. He brings a unique, dual perspective of high-level enterprise execution and future-ready academic curriculum development.