Minimum Viable Dataspace on AWS

🚀 Deploy complete data space environments on AWS with a single command.

Secure, sovereign sharing of information is emerging as a requirement across industries globally. This project accelerates data space experimentation and use case testing by making mature reference implementations available as single-command deployment blueprints on AWS. It ships two blueprints:

• mvd deploys the Eclipse Minimum Viable Dataspace: two dataspace participants and a credential issuer. This is the default; start here.
• umbrella deploys the Tractus-X Umbrella decentralized-identityhub profile: the Catena-X reference stack, adding BPN-based identity (BDRS) and a Digital Twin Registry.

See Blueprints for a comparison and how to choose.

Quick Start

This project requires the following tools to be installed:

• terraform, aws-cli, kubectl and helm to provision AWS infrastructure and Kubernetes resources
• openssl for the umbrella blueprint

Both blueprints consume upstream container images directly from public registries, pinned by digest.

Deploy a blueprint with a single command:

~ ./deploy.sh up mvd        # Eclipse MVD (default)
# or
~ ./deploy.sh up umbrella   # Tractus-X Umbrella (Catena-X)

Creating Minimum Viable Dataspace on AWS...

Deployment takes 15-20 minutes. External dataspace access is secured with AWS IAM (SigV4) and Amazon API Gateway. When it finishes, the script prints the API Gateway invoke URL.

~ kubectl get pods -A -l app.kubernetes.io/part-of=mvd

NAMESPACE   NAME                              READY   STATUS    RESTARTS   AGE
consumer    controlplane-...                  1/1     Running   0          3m
consumer    identityhub-...                   1/1     Running   0          3m
provider    controlplane-...                  1/1     Running   0          3m
provider    dataplane-...                     1/1     Running   0          3m
provider    identityhub-...                   1/1     Running   0          3m
issuer      issuerservice-...                 1/1     Running   0          3m
mvd-common  keycloak-...                      1/1     Running   0          3m
...

~ kubectl get gateway -A          # all should be PROGRAMMED=True

Each blueprint has an end-to-end walk-through that drives a full data exchange (catalog, contract negotiation, transfer, then data fetch) and doubles as a prototyping starting point: the MVD walk-through and the Umbrella walk-through.

To verify a deployment automatically, run its smoke test: ./templates/mvd/smoke-test.sh or ./templates/umbrella/smoke-test.sh. Each reports PASS/FAIL for every stage of the flow.

The mvd blueprint also deploys the EDC DataDashboard, a browser UI for visual exploration; reach it with kubectl port-forward -n mvd-common svc/data-dashboard 8080:8080 and open http://localhost:8080.

Blueprints

Both blueprints share the AWS substrate; they differ in the dataspace stack deployed onto it.

	mvd	umbrella
Upstream	Eclipse MVD	Tractus-X Umbrella
Best for	learning EDC data exchange	Catena-X prototyping
Identity	DCP, DID-based	DCP + Catena-X BPN/BDRS
Extras	DataDashboard UI	Digital Twin Registry
Delivery	Kustomize overlay	Helm chart overrides
Walk-through	mvd	umbrella

Architecture

Requests enter through Amazon API Gateway and are forwarded over a VPC Link to an internal Network Load Balancer. The NLB targets the Envoy Gateway proxy in Amazon EKS, which routes by host to the connector services. Services persist to a single Amazon Aurora PostgreSQL cluster.

umbrella: adds BDRS and a Digital Twin Registry; CoreDNS resolves the did:web hostnames in-cluster to the Envoy Gateway, and the provider serves data from an in-cluster submodel server.

Learn More

• Dataspace Connector on AWS
• Eclipse Dataspace Components on AWS: Data sharing fundamentals (3-part blog series)
• AWS-specific service integrations for EDC
• Aspect Models for Eclipse Tractus-X Semantic Layer (SLDT)

Configuration

EDC connectors are secured with AWS IAM authorization, requiring every request to be signed with SigV4. Authorization is by default scoped to the deploying AWS account. Any IAM principal whose policy allows execute-api:Invoke can call EDC APIs provisioned by this project. See the mvd walk-through for signed-request examples.

Connectors persist their state in a single Amazon Aurora PostgreSQL cluster, with one logical database per dataspace service. By default, this project creates a new AWS VPC with all required networking components. However, you can optionally deploy into an existing VPC by providing its VPC ID to the deploy.sh script.

Using an Existing VPC

To deploy into an existing VPC, set the VPC_ID variable:

# deploy.sh
VPC_ID="vpc-1234567890abcdef0"

Requirements for Existing VPCs

• Private Subnets: At least 2 private subnets tagged with kubernetes.io/role/internal-elb=1
• Public Subnets: At least 2 public subnets tagged with kubernetes.io/role/elb=1
• Availability Zones: Subnets must be distributed across multiple AZs for high availability

Considerations for Production

The default configuration of this project is not indended for use in a production scenario. It is intended as a starting point for rapid data space and Catena-X experimentation and prototyping, that needs adaptation depending on how it is being used. For design principles and best practices on implementing production-ready workloads on AWS please refer to the AWS Well-Architected Framework.

Security

See CONTRIBUTING for more information.

License

This library is licensed under the MIT-0 License. See the LICENSE file.