Map repository and registry responsibilities to AWS services
The cleanest AWS translation of XDS.b preserves the same logical split as the profile itself: object storage for payloads, a metadata persistence layer for the registry, and a query surface that can answer document discovery requests efficiently.
Reference AWS pattern for XDS.b services
Loading diagram...
Logical actor to AWS service mapping
| IHE concern | Common AWS choice | Why |
|---|---|---|
| Repository payload storage | Amazon S3 | Durable object storage with lifecycle policies and encryption at rest |
| Metadata transaction logic | AWS Lambda | Event-driven parsing, validation, and transformation of XDS envelopes |
| Registry persistence | Amazon Aurora PostgreSQL or Amazon DynamoDB | Choose based on relational query richness vs scale and access-pattern stability |
| Rich document discovery | Amazon OpenSearch Service | Supports multi-field and text-oriented metadata search beyond simple key lookups |
Modernizing SOAP with API Gateway and Lambda
AWS guidance for wrapping or transforming SOAP workloads without rewriting clients immediately.
Read the AWS patternWhy large MTOM payloads usually become an event-driven ingestion flow
Large ITI-41 submissions are one of the main reasons XDS.b feels awkward in a purely REST-and-Lambda mindset. The payload often contains large binary attachments, and synchronous function invocation limits can become the wrong bottleneck.
Asynchronous ITI-41 ingestion pattern
Loading diagram...
Architectural trade-off
This pattern preserves clinical compatibility while shifting the expensive binary handling out of the synchronous request path. The cost is more moving parts, stronger idempotency requirements, and clearer event correlation.
AWS Lambda quotas
Official Lambda limits that influence when synchronous payload handling stops being practical.
Review Lambda quotasThe ingress boundary must absorb payload-size and certificate realities
XDS traffic design on AWS often fails at the ingress boundary first, not in the registry. ITI-41 packages can be large, partner-specific certificates may be mandatory, and the transport façade has to decide whether the request stays synchronous or is handed off to an asynchronous workflow quickly.
Choosing the AWS ingress pattern for XDS traffic
Loading diagram...
Ingress choices and the trade-offs they imply
| Pattern | Best fit | Watch-out |
|---|---|---|
| API Gateway with mTLS | Smaller control messages, certificate validation, and modern policy enforcement at the edge | Payload quotas make it a poor fit for very large MTOM submissions |
| S3 landing zone with async workers | Large ITI-41 packages where parsing should not block the request path | You must solve idempotency, correlation IDs, and retry-safe registration |
| ALB or NLB to ECS/EKS integration service | Partner-specific transports, longer parsing paths, or heavyweight SOAP stacks | Operational burden is higher than a pure serverless edge |
The practical AWS limit that changes the shape
API Gateway request bodies have service quotas, and synchronous Lambda invocation has separate payload limits. Once MTOM packages get large, the design usually shifts toward direct object landing or containerized ingress rather than pretending the traffic is a normal JSON API.
API Gateway mutual TLS
Official AWS documentation for trust stores in Amazon S3 and client-certificate validation at the API boundary.
Read the mTLS docsAPI Gateway quotas
Official quotas that influence how much payload and header material can stay in the synchronous API path.
Review API Gateway quotasChoose registry storage and resilience patterns deliberately
Aurora PostgreSQL often feels natural when the registry must behave like a relational metadata system with many joins and strict association logic. DynamoDB becomes attractive when access patterns are tightly designed and write or replication scale is the primary concern. OpenSearch commonly complements either option for richer metadata queries.
Registry implementation decision tree on AWS
Loading diagram...
Registry implementation trade-offs
| Option | Strength | Watch-out |
|---|---|---|
| Aurora PostgreSQL | Relational joins fit ebRIM-like metadata models well | You must plan for scaling, indexing, and multi-region strategy carefully |
| DynamoDB | Predictable low-latency writes and global-table replication | Ad hoc multi-attribute querying is limited without complementary indexing |
| OpenSearch sidecar | Powerful search over document metadata and codes | Index mapping and synchronization discipline matter |
For disaster recovery, the same logic applies: binary documents, metadata, and query surfaces must fail over together. Architects commonly pair S3 replication with DynamoDB global tables or Aurora global databases, then route access through Route 53 health-aware patterns.
This AWS diagram is not XDS-specific, but it is the right resilience mental model. The repository, registry, and search layers may differ from a web application stack, yet the regional routing and replicated authoritative-state problems are the same.
Do not hide the conflict model
DynamoDB global tables use last-writer-wins reconciliation. That can be acceptable for derived search projections, but clinical registry designs still need a clear application rule for replacement, immutable audit history, and operator investigation when concurrent updates occur.
DynamoDB zero-ETL to OpenSearch
Official guidance for pushing DynamoDB changes into OpenSearch without custom synchronization code.
Read the zero-ETL guidanceDynamoDB global tables design considerations
Official AWS guidance on global tables, replication behavior, and last-writer-wins conflict semantics.
Read the global tables guidanceAWS multi-site active-active disaster recovery
AWS reference material for active-active regional resilience patterns.
Review the DR patternKnowledge Check
Test your understanding with this quiz. You need to answer all questions correctly to mark this section as complete.