The architecture in five sentences

Source systems land every payload unchanged in an immutable S3 raw zone with Object Lock, and

Glue standardises and quality-checks it into a curated zone catalogued in Glue and governed by Lake Formation.

AWS Entity Resolution matches those curated tables — exact waterfall rules as the primary

technique, a preset ML model as a second pass — and writes match groups with match IDs to S3.

Custom code does what no AWS service does: resolves match IDs to a stable master identifier

through a crosswalk, replays steward decisions, applies per-attribute survivorship, and writes versioned golden records with attribute-level provenance into Aurora PostgreSQL.

HealthLake holds the FHIR R4 view for interoperability, with its own deterministic resource

matching producing FHIR Linkage resources, and changes publish to consumers via EventBridge, SNS and SQS.

It all runs in a multi-account Control Tower landing zone under one AWS business associate

addendum, with KMS customer managed keys, CloudTrail, the Config HIPAA Security conformance pack and Security Hub CSPM.

Ten likely questions

1. Why not just buy an MDM product? Because the component that historically justified the licence — matching — is now a metered AWS service at $0.25 per 1,000 records. What a licence still buys is the governance surface: a steward workbench, a survivorship rules editor, lineage. If the requirement is a resolved data asset for analytics and interoperability with a few expert stewards, native wins. If the requirement is a business application for many stewards, buy it. I would not recommend native to an organisation that cannot fund a platform team indefinitely.

2. Does AWS Entity Resolution give me a golden record? No. It gives match groups with a match ID, written to S3. The documentation describes a "consolidated data output table"; it never mentions survivorship, trust scores or golden records. Survivorship, the master store, the crosswalk and stewardship are all custom. That is the central honest point of this design.

3. How do you keep the master identifier stable? I mint it myself and never expose a match ID downstream. Entity Resolution does retrieve existing match IDs for records already in a workflow — GenerateMatchId says so, and bulk processing applies "updates to existing matches" — but the glossary defines the match ID as workflow-run output metadata, and nothing documents that a rebuilt workflow, a changed rule set or an ML pass produces the same IDs. The only stability sentence, "a record's match ID is fixed upon its first match", is scoped to transitive matching inside a run. So the crosswalk — source system, source record id, master id, match id, run — is the authoritative mapping. I back it up harder than anything else, journal every mutation into the Object Lock raw zone so it is rebuildable, and derive master_id deterministically where the identifiers allow.

4. Rule-based or ML matching for patients? Rule-based as primary, because healthcare identity rests on scoped identifiers like an MRN plus assigning authority, and rule-based matching supports automatic incremental processing. ML as a periodic second pass for demographic duplicates. Two caveats I would state: rule-based matching is "designed to find exact matches" on normalised values, so it does not absorb typos; and the ML model uses name, email, phone, address and date of birth — no clinical identifier is an input to it.

5. How does this scale? The binding constraint is not compute. It is the quota "Concurrent matching jobs — 1 per Region — Adjustable: No". Four entity types cannot match in parallel in one account and Region, so I serialise with Step Functions and keep the option of a second resolve account to lift effective concurrency. The record ceilings are generous and, importantly, adjustable: 100 million per rule-based workflow, 600 million for ML in the larger Regions. That is the real shape of the constraint — the volume limits move, the concurrency does not.

6. Real-time patient lookup at registration? GenerateMatchId, which processes a record against the workflow's rules, retrieves an existing match ID or generates a new one, and saves results to S3. It is rule-based only, one record per call, 10 requests per second by default, and each call is chargeable. Its default CONSISTENT mode gives highest accuracy with slower response, which is the right trade clinically. GetMatchId at 50 per second is the cheaper retrieval-only path when the record is already matched.

7. Is every service HIPAA eligible? Every component here is covered by the HIPAA eligible services reference — most as their own entry, and PrivateLink by inheritance, since it is a generally available feature of VPC and VPC is listed. Three nuances. The page says "Unless specifically excluded, generally available features ... are also considered HIPAA eligible", which is what makes Glue Data Quality eligible without its own line. HealthLake's resource matching is labelled Preview, which is not generally available — I would raise that with the account team before routing PHI through it. And RDS carries an engine restriction where Aurora, which I use, does not.

8. How do you prove compliance to an auditor? I would start by saying there is nothing to certify: AWS states "There is no HIPAA certification for a cloud service provider (CSP) such as AWS". The evidence is the executed BAA from AWS Artifact, the Config conformance pack Operational-Best-Practices-for-HIPAA-Security with its compliance dashboard, Security Hub CSPM findings, CloudTrail including data events on the PHI buckets in a log archive account the data accounts cannot write to, and my own attribute-level change history. I would not propose Audit Manager: AWS's own documentation now states "AWS Audit Manager is no longer open to new customers", so a new landing zone cannot adopt it. AWS directs customers to Config conformance packs, and both of its HIPAA frameworks map to Operational-Best-Practices-for-HIPAA-Security.

9. How do you handle de-identification? As a customer obligation, and I would start by being precise about terms, because this is where the word is usually misused. A column-filtered analytics view that still carries master_id is pseudonymised PHI, not de-identified data — the code re-identifies every row against the crosswalk — so it stays inside the BAA and the Data OU's controls. A genuinely de-identified extract needs the linking code removed or replaced by a per-extract value whose key is not disclosed, plus suppression, generalisation and date shifting. For free text, Comprehend Medical's DetectPHI detects NAME, AGE, DATE, ADDRESS, ID, PHONE_OR_FAX, EMAIL, URL and PROFESSION; AWS says it "does cover all the relevant identifiers" for unstructured text but that those entities "don't map 1:1 to the list specified by the Safe Harbor method", and recommends human review for compliance use cases. So it is a strong aid, not a de-identification control. Non-production gets synthetic data only.

10. What is the disaster recovery story? AWS Backup covers S3 and Aurora with cross-Region and cross-account copy, Vault Lock for WORM and a logically air-gapped vault; DynamoDB needs AWS Backup advanced features to get cross-account copy and an air-gapped vault at all. HealthLake is not listed on AWS Backup's supported resources, so its recovery is built from scheduled Bulk Data export to another account plus the ability to rebuild from the raw zone — and I would rehearse the rebuild, because an untested one is not a plan. RPO for the master is minutes via Aurora continuous backup; HealthLake's is the export cadence. I would also name availability before being asked: the master sits on a synchronous clinical path, so it runs an Aurora writer with a reader in a second Availability Zone, and registration degrades to GenerateMatchId plus deferred reconciliation rather than blocking if the master is unreachable.

Trade-offs to volunteer unprompted

Raising these before being asked is what distinguishes a designer from a describer.

Trade-off	What to say
One matching job per Region	Serialise with Step Functions, or add a resolve account
Rule-based exactness	Fast and incremental, but blind to typos; ML covers that, at a cost
Aurora Standard vs I/O-Optimized	Standard wins at 500M I/Os; crossover near 650M at this profile
Immutability vs retention	Object Lock compliance mode cannot be reversed except by closing the account
Link vs merge	Both engines link; keeping duplicates visible is right for clinical safety
HealthLake as source or consumer	Both are valid; match first, then write the governed view
Macie scope	$1 per GB inspected dominates if unscoped; target landing and extract prefixes
Preview features	Architect on GA; pilot Preview on synthetic data
Build vs buy for stewardship	The honest reason a licence still sells

Numbers to remember

Fact	Value
Entity Resolution	$0.25 per 1,000 records processed; no free tier
Provider-led matching	$0.10 per 1,000 records, licence required
Concurrent matching jobs	1 per Region, not adjustable
Records per rule-based workflow	100,000,000, and adjustable
Records per ML workflow	600,000,000 in the larger Regions; 150,000,000 in three
Maximum data inputs	20
`GetMatchId` / `GenerateMatchId`	50 and 10 requests per second
ML confidence score range	0.0 to 1.0
HealthLake data store	$0.27 per hour, about $197 per month
HealthLake storage	$0.25 per GB-month Standard, $0.37 Advanced; 10 GB included
HealthLake export / NLP	$0.19 per GB; $0.0010 per 100 characters
Glue	$0.44 per DPU-hour; Data Quality 2 DPU, 1-minute minimum
Glue DQ limits	2,000 rules and 65 KB per ruleset
S3 Standard / Glacier Deep Archive	$0.023 / $0.00099 per GB-month
Aurora Serverless v2	$0.12 per ACU-hour Standard; $0.156 I/O-Optimized
Athena	$5 per TB scanned
KMS	$1 per key per month; 20,000 requests free
Macie	$0.10 per bucket, $0.01 per 100K objects, $1 per GB inspected
Audit Manager HIPAA framework	24 automated, 61 manual controls, 5 control sets
Audit Manager	In maintenance mode; closed to new accounts since 30 April 2026
HealthLake linkage cap	A resource sharing an identifier with more than 100 others
Worked monthly estimate	About $3,735 at the stated scale; $3,110 initial load
Aurora reader for HA	2 ACU averages about $175 per month

Three quotes worth knowing verbatim

HealthLake, on resource matching: "so you can build an accurate, unified view without operating a

master data management system." This is AWS endorsing the pattern.

The same page, on its limit: "It does not perform probabilistic or demographic fuzzy matching on

names, dates of birth, or addresses."

AWS on compliance: "There is no HIPAA certification for a cloud service provider (CSP) such as

AWS."

Three things NOT to claim

1. Do not say AWS Entity Resolution produces golden records or does survivorship. The pages cited in this set describe match groups, match IDs and a consolidated output table. Golden record, survivorship, trust score, merge rule and steward appear nowhere. Say: "it gives me match groups and a match ID; survivorship and the golden record are mine to build."

2. Do not say HealthLake resource matching is HIPAA eligible for PHI today. The eligible services page extends eligibility to generally available features. Resource matching is labelled "available as a preview capability and is subject to change". That is an unresolved question, not a yes. Say: "HealthLake is a HIPAA eligible service; resource matching is in Preview, so I would confirm PHI eligibility with the account team before putting production PHI through it." Framing it as a question you would ask is stronger than an answer either way.

3. Do not claim a licence saving as a number, and never call a master_id-bearing extract de-identified. No vendor list price was read for this set, so any comparison figure would be invented — describe the structural difference (usage-based versus a commitment floor) and say the comparison needs your own quote. And an analytics extract that carries the master identifier is pseudonymised PHI; the difference from de-identified data is legal, not stylistic.

Macie is the other one to get right: its documentation scopes the managed data identifiers to "Amazon Simple Storage Service (Amazon S3) objects", so it is not a scanner for Aurora, DynamoDB, Redshift or HealthLake.

Two smaller ones in the same spirit: do not cite the "Architecting for HIPAA Security and Compliance on AWS" whitepaper, which is archived; and do not enumerate the HIPAA Safe Harbor identifier list from memory — the only figure in this set is AWS's own reference to "a list of 18 identifiers" on the Comprehend Medical page, alongside its warning that its entities do not map to that list one-to-one.

The likely follow-up to question one

"What would you do differently with a bigger budget?" The answer inverts the build-or-buy line exactly where the economics turn: buy the steward workbench, keep the AWS matching and the lake. Matching is metered and cheap; the governance surface is the expensive thing to build and the expensive thing to maintain. Spending on the one component that is months of bespoke PHI-handling application work, while keeping the parts AWS already meters, is a better allocation than either extreme.

If you do not know

Say which page would answer it. "The Entity Resolution quotas page would tell us whether that limit is adjustable" is a better answer than a guess, and it is the habit this whole document set is built on. An architect who distinguishes what they verified from what they assume is more trustworthy than one who sounds certain about everything.