The contract comes first

Nothing else here matters without the agreement. "The Business Associate Addendum (BAA) is an AWS contract that is required under HIPAA rules to ensure that AWS appropriately safeguards protected health information (PHI)." It is self-service: review and accept it in AWS Artifact.

The eligible services reference carries the operative restriction verbatim:

"If you are a Covered Entity or Business Associate as defined by the Health Insurance Portability and Accountability Act of 1996 (as amended, "HIPAA"), you agree not to use these HIPAA Eligible Services for any purpose or in any manner involving Protected Health Information (as defined by HIPAA) without first entering into an AWS business associate agreement."

Two corrections to common assumptions follow from the same pages.

There is no certificate. "There is no HIPAA certification for a cloud service provider (CSP) such as AWS." Eligibility is contractual and architectural, so "HIPAA certified on AWS" cannot be true of anyone.

Eligibility constrains where PHI goes, not which services you may use. "Customers may use any AWS service in an account designated as a HIPAA account, but they should only process, store, and transmit protected health information (PHI) in the HIPAA-eligible services defined in the BAA."

One archived source to avoid, in both forms. The HTML edition of "Architecting for HIPAA Security and Compliance on Amazon Web Services" now returns only an archive notice pointing to the HIPAA Eligible Services Reference. The older PDF still serves the full text, watermarked as archived — so it looks current and is not — and other AWS pages, the Audit Manager HIPAA framework page included, still link to that PDF. Cite the reference.

Eligibility, verified service by service

Every row below was confirmed by verbatim transcription of the relevant band of the eligible services reference on 2026-10-21 — A to C, D, Elastic to FSx, Glue to Lambda, Macie to Step Functions, and T to the end. "Listed" means the name appears as its own entry; bracketed caveats are reproduced.

Service	Status on the page	Note
AWS Entity Resolution	Listed, no bracketed exclusion	C2
AWS HealthLake	Listed; its own docs say "This is a HIPAA Eligible Service"	C3
AWS Glue	Listed; Glue DataBrew listed separately	C1
AWS Audit Manager	Listed	C4
AWS Clean Rooms	Listed	C5
Amazon DataZone	Listed	C6
Amazon VPC	Listed as Amazon Virtual Private Cloud (VPC)	C7
Amazon SageMaker AI	Listed, four-part exclusion	C8
Amazon RDS	Listed, engine restriction	C8
Amazon EventBridge	Listed, "[formerly Amazon Cloudwatch Events]"
AWS Security Hub	Listed as AWS Security Hub CSPM
Amazon Macie	Listed	S3-scoped, below
AWS Backup	Listed	Gap, doc 06

Also listed as their own entries: S3, KMS, Lake Formation, Athena, Redshift, DynamoDB, Aurora, Step Functions, Lambda, SQS, SNS, Kinesis Data Streams and Firehose, MSK, CloudTrail, CloudWatch, CloudWatch Logs, Config, Cognito, IAM Identity Center, OpenSearch Service, Comprehend Medical, Control Tower, Organizations, API Gateway, ELB, ECS, EKS and Neptune.

C1 — features inherit. "Unless specifically excluded, generally available features of each of the HIPAA eligible services listed are also considered HIPAA eligible." Glue Data Quality is a generally available feature of Glue, so it needs no separate entry.

C2 — a nuance worth knowing. Entity Resolution's own compliance validation page names PCI DSS and SOC 1/2/3 and never mentions HIPAA. Its eligibility rests on the eligible services reference; cite that.

C3 — the Preview problem, the most important caveat in this set. C1 extends eligibility to generally available features. HealthLake resource matching is "available as a preview capability and is subject to change", and the Data Transformation Agent is also Preview. A Preview feature is not generally available, so the cited pages do not establish that PHI may be processed through those two features under the BAA. That is an inference from the quoted sentences, not an AWS statement, and it is a question for an AWS account team. Until it is answered, run production on AWS Entity Resolution and pilot HealthLake matching on synthetic or de-identified data.

Two companion questions belong on the same list, and the cited pages answer neither: does AWS use customer input to Entity Resolution's preset ML model, and how long are the hashed attributes GetMatchId produces retained? Asking is the right posture; inventing answers is not.

C4 — Audit Manager is closed. Its documentation now carries the banner "AWS Audit Manager is no longer open to new customers. Existing customers can continue to use the service as normal." The dated change behind it — "from April 30th 2026 customers will no longer be able to set up the service in new accounts" — has passed, so a new landing zone cannot adopt it. Its HIPAA Security Rule: Feb 2003 framework has 24 automated, 61 manual controls and 5 control sets, with its own disclaimer that these "aren't intended to verify if your systems are compliant with the HIPAA standard".

C5 — Clean Rooms is listed but is not a healthcare service. Its overview never mentions PHI, HIPAA or healthcare; it is relevant only for cross-organisation analysis with a partner.

C6 — naming. Amazon DataZone is the name on the page; rebranding under the SageMaker Catalog name was not verified here.

C7 — PrivateLink. VPC is listed; AWS PrivateLink is not, so it is covered by C1 as a generally available feature of VPC. HealthLake's documentation independently names AWS PrivateLink as a related service for connectivity "without exposing data to the internet".

C8 — two bracketed caveats to read in full. SageMaker AI is "[formerly Amazon Sagemaker, excludes Studio Lab, Ground Truth Plus, Public Workforce and Vendor Workforce for all features]" — the workforce exclusions rule out a managed human-review workforce for steward tasks. Amazon RDS is "[SQL Server, MySQL, Oracle, PostgreSQL, Db2 and MariaDB engines only]"; Aurora is a separate entry with no bracket, and Aurora is what this pattern uses.

Shared responsibility, concretely

HealthLake "stores encrypted customer content and operates according to the AWS Shared Responsibility Model". In practice:

The generic split — facilities and patching to AWS, IAM and configuration to you — is assumed. The HIPAA-specific half is what matters:

AWS is responsible for	You are responsible for
Making a service HIPAA eligible	Executing the BAA before PHI lands
Encryption primitives	Which services hold PHI, and key policy
Audit log generation	De-identification, minimum necessary, retention

AWS cannot make you compliant; it can only make compliance constructible.

Encryption

Encryption in transit is largely settled by the services. HealthLake: "Connections to HealthLake containing PHI and personally identifiable information (PII) must be encrypted. By default, all connections to HealthLake use HTTPS over TLS." Comprehend Medical says the same and adds: "Amazon Comprehend Medical does not persistently store customer content. Therefore, you do not need to configure encryption at-rest within the service."

At rest, use customer managed KMS keys, one per zone, and treat the key policy as a second independent access control: a principal needs both an IAM grant and a key grant, so a mistaken bucket policy alone does not expose PHI. Keys are $1 per month each, so separation is cheap.

Entity Resolution supports this: it "can operate on encrypted datasets", "equips you with an encryption key for every data input into the service", and if a KMS key ARN is not provided "system will use an AWS Entity Resolution managed KMS key" — so supply your own. It can also hash output with "Secure Hash Algorithm 256-bit (SHA256)", useful where a consumer needs linkage without plaintext identifiers.

Least privilege and access

Lake Formation is the lever: it "provides its own permissions model that augments the IAM permissions model", with permissions "enforced using granular controls at the column, row, and cell-levels" across Athena, Redshift Spectrum, EMR and Glue. Grant analysts a column-filtered view omitting name, address, dates of birth and source identifiers, and use LF-Tags to manage those grants at scale rather than per table.

Be precise about what that view produces, because the terminology carries legal weight. A view retaining master_id is pseudonymised PHI, not de-identified data: master_id re-identifies every row once joined to the crosswalk, and it is by design the enterprise key used for every other purpose. Treat it as PHI — inside the BAA, inside the Data OU's controls, with the crosswalk unreachable from the analytics account. A genuinely de-identified extract is a separate product, needing the linking code removed or replaced by a per-extract value whose key is not disclosed, plus suppression, generalisation and date shifting.

Humans authenticate through IAM Identity Center federated to the corporate identity provider; no long-lived IAM users. Cognito serves patient- or partner-facing applications. Service roles are scoped to specific bucket prefixes and KMS keys.

Audit

Layer	Mechanism
API activity	CloudTrail organisation trail to the log archive account
PHI object access	CloudTrail data events on the raw and curated buckets
Analytics access	Lake Formation "provides comprehensive audit logs with CloudTrail"
Configuration	AWS Config with the HIPAA Security conformance pack
Findings	Security Hub CSPM across accounts
Log integrity	Object Lock on the archive; CloudTrail log file validation
Master changes	Your append-only history table in Aurora

The Config conformance pack is AWS's own recommended route, and carries a disclaimer worth quoting rather than paraphrasing: "Conformance Packs, as sample templates, are not designed to fully ensure compliance with a specific governance or compliance standard. You are responsible for making your own assessment of whether your use of the Services meets applicable legal and regulatory requirements." Its rules include s3-bucket-server-side-encryption-enabled, cloudtrail-enabled, rds-storage-encrypted and vpc-flow-logs-enabled.

The last row is yours: no AWS service records which attribute of a golden record changed, why, and on whose authority.

Two sinks this table omits accumulate PHI nobody governs. CloudWatch Logs: Glue and Lambda logs, and any error path logging a record, carry PHI — suppress record-level logging in production, encrypt log groups with a CMK, set retention, scan any log export bucket. The Athena query-results bucket: every query writes its results to an output location, so it fills with analyst-made PHI extracts outside the curated zone's governance; give it its own CMK, a lifecycle expiry, Lake Formation scoping and Macie coverage. Step Functions execution history is a third — see document 06.

Macie, and what it does not cover

Macie "uses a combination of criteria and techniques, including machine learning and pattern matching, to detect sensitive data in Amazon Simple Storage Service (Amazon S3) objects". Seven types sit in its PHI category, each needing a nearby keyword:

Type	Identifier	Region
DEA Registration Number	`US_DRUG_ENFORCEMENT_AGENCY_NUMBER`	US
Health Insurance Claim Number	`USA_HEALTH_INSURANCE_CLAIM_NUMBER`	US
Health insurance or medical ID	`UK_NHS_NUMBER`, `CANADA_HEALTH_NUMBER`, four more	Several
HCPCS code	`USA_HEALTHCARE_PROCEDURE_CODE`	US
National Drug Code	`USA_NATIONAL_DRUG_CODE`	US
National Provider Identifier	`USA_NATIONAL_PROVIDER_IDENTIFIER`	US
Unique device identifier	`MEDICAL_DEVICE_UDI`	US

PII identifiers matter as much here. NAME is the only personal-information identifier needing no nearby keyword — its "Full name" row reads "Keyword required: No". DATE_OF_BIRTH and USA_SOCIAL_SECURITY_NUMBER require one; ADDRESS and PHONE_NUMBER are "Varies". Several credential and IBAN identifiers also need none, so "only NAME needs no keyword" holds for the personal-information rows, not the whole table.

The scope limit is the honest part. Macie is a control over S3, not a scanner for Aurora, DynamoDB, Redshift or HealthLake. Its best use is detective, on the landing zone and any extract bucket — "did PHI arrive somewhere it should not have" — not inventorying the master.

De-identification

A de-identified copy is the right answer for every non-production environment, and it is a customer obligation. The nearest managed primitive is Comprehend Medical's DetectPHI (entity types in document 03).

Its own page sets the boundary, and this is the sentence to remember: "Amazon Comprehend Medical detects entities associated with these identifiers but these entities don't map 1:1 to the list specified by the Safe Harbor method." Volunteer the counterweight from the same paragraph rather than waiting to be given it — AWS also writes that it "does cover all the relevant identifiers" for unstructured text, so the limit is the mapping to Safe Harbor, not coverage. It recommends "human review or other methods to confirm the accuracy of detected PHI", and it is English-only.

So: a strong aid for free text, not a de-identification control and not a Safe Harbor implementation. Structured de-identification of the master's columns is custom work. The statutory identifier list is not reproduced here; confirm it against HHS directly.

Break-glass

No AWS service here provides an emergency access workflow, so build one and keep it boring. A dedicated role, assumable only after a ticketed, time-boxed approval, never by a standing principal. Every assumption emits an EventBridge event and a Security Hub finding. CloudTrail is the record, written to an account the role cannot reach, and a review follows every use. The same discipline applies to the steward console's override path: a steward who can merge any two patients is a privileged user in the HIPAA sense, with or without an AWS console.