A worked example of building a healthcare master data management capability — one trustworthy record per patient, provider, organisation and location — from AWS-native services rather than a licensed MDM product, under HIPAA.

The question this set answers is not "can it be done". It is "which parts does AWS supply, which parts are yours, and is the trade sound". The short answer: AWS has productised the hardest algorithmic component and none of the operational ones.

The architecture in five sentences

Source systems land every payload unchanged into an immutable S3 raw zone with Object Lock, and AWS Glue standardises and quality-checks the data into a curated zone registered in the Glue Data Catalog and governed by Lake Formation. AWS Entity Resolution matches records from those curated tables, using exact waterfall rules as the primary technique and a preset ML model as a second pass, writing match groups and match IDs back to S3. Custom code then does the work no AWS service performs: resolving match IDs to a stable master identifier through a crosswalk, replaying steward decisions, applying per-attribute survivorship rules, and writing versioned golden records with attribute-level provenance into Aurora PostgreSQL. AWS HealthLake holds the FHIR R4 view for interoperability, with its own deterministic resource matching producing FHIR Linkage resources, and change events publish to consumers through EventBridge, SNS and SQS. Everything runs in a multi-account Control Tower landing zone under a single AWS business associate addendum, with KMS customer managed keys, CloudTrail, the AWS Config HIPAA Security conformance pack and Security Hub CSPM as the compliance substrate.

Why this is a legitimate pattern

AWS says so itself, in the HealthLake documentation on resource matching:

"When aggregating data from multiple systems, resource matching connects the same entity written as several separate resources so you can build an accurate, unified view without operating a master data management system."

That sentence is the warrant for the whole set. The same page is equally clear about the limits: it links rather than merges, and "does not perform probabilistic or demographic fuzzy matching on names, dates of birth, or addresses".

Reading order

Document	What it settles
00 overview and decision	Why native, and when it is the wrong call
01 reference architecture	End-to-end flow, service roles, accounts
02 identity resolution	The matchers, and the custom core
03 data model and FHIR	HealthLake, FHIR R4, the master schema
04 security and HIPAA	BAA, eligibility table, encryption, audit
05 stewardship and quality	Glue Data Quality; the steward application
06 operations	Quotas, idempotency, backup and DR
07 cost model	Billing dimensions, a worked estimate, savings
08 gaps register	All 24 gaps with severity and effort
09 interview brief	The study sheet and what not to claim

Read 00 then 01 for the shape. Read 02 and 08 if you only have time for two: they carry the verified limits and the honest account of what must be built.

The nine capabilities, and AWS's coverage

Capability	AWS coverage
Ingestion and standardisation	Strong — Glue, Lambda, Kinesis, MSK
Data quality measurement	Strong — Glue Data Quality with DQDL
Identity resolution, matching	Strong — Entity Resolution, HealthLake matching
Survivorship and golden record	No managed equivalent found
Master identifier and crosswalk	No managed equivalent found
Stewardship workflow and UI	No managed equivalent found
Lineage and audit	Partial — CloudTrail, Lake Formation; attribute lineage custom
Publish and subscribe	Partial — EventBridge, SNS, SQS, HealthLake FHIR Subscriptions
Interoperability, FHIR	Strong — HealthLake, a managed FHIR R4 store

Evidence standard used throughout

Every claim about an AWS service in this set is quoted from a page listed in that document's provenance block, each read on 2026-10-21. Three rules were applied:

No invented facts. No service feature, limit, price or compliance status appears unless it was

read on an AWS page.

Silence is recorded as silence. Where documentation does not support a claim, the text says

the cited pages contain no statement, rather than asserting the capability is absent.

Inferences are labelled. The one significant inference in the set — that a Preview feature is

not covered by the eligibility caveat for generally available features — is marked as an inference wherever it appears.

Numbers worth carrying from this set: Entity Resolution at $0.25 per 1,000 records processed; a 100,000,000 record ceiling per rule-based workflow, which is adjustable, against one concurrent matching job per Region, which is not; a HealthLake data store at $0.27 per hour, about $197 per month before storage; Glue at $0.44 per DPU-hour; and GetMatchId at 50 requests per second against GenerateMatchId at 10.

Two things to know before quoting anything here

AWS Audit Manager is no longer open to new customers — its documentation now says exactly that, following a cutoff dated 30 April 2026 that has passed. Its HIPAA frameworks still exist for existing customers. New landing zones should use the AWS Config conformance pack Operational-Best-Practices-for-HIPAA-Security instead, which is AWS's own stated direction.

The "Architecting for HIPAA Security and Compliance on AWS" whitepaper is archived. Its HTML edition returns only a notice pointing to the HIPAA Eligible Services Reference, while the older PDF still serves the full text under an archived watermark — so it looks current and is not. Several AWS pages still link to that PDF. Cite the reference.