Is AWS HIPAA compliant?
Yes, if you accept the AWS business associate addendum in AWS Artifact and then keep patient data only inside the services on the HIPAA Eligible Services list.
Applies to AWS. Last reviewed against Amazon Web Services's own documentation. Next review December 3, 2026.
Reviewed by Lisa Tran, CISSP — Healthcare Information Security Executive.
What you must do
- Accept the addendum before patient data touches AWS. AWS requires it before using eligible services for any purpose involving patient information.
- Accept it in AWS Artifact: Artifact console → Agreements → Account agreements (or Organization agreements) → select the addendum → Download → accept the Artifact NDA → review → Accept agreement.
- By default only users with administrative privileges can accept. IAM and federated users need explicit Artifact permissions.
- With AWS Organizations you can accept once for every account, and subsequent member accounts are automatically covered.
- Put patient data only in services on the HIPAA Eligible Services Reference. You may run any service in a HIPAA account, but only eligible ones may process it.
- Apply the security configuration the addendum requires and architect access control, logging and backup yourself under the shared responsibility model.
- Re-check the eligible services list before adopting any new AWS service.
Does AWS sign a business associate agreement?
Yes. Amazon Web Services offers one. No special plan or support tier. Self-service for any AWS account, or organization-wide via AWS Organizations. AWS Artifact console → Agreements → Account agreements → Business Associate Addendum → Download → accept the Artifact NDA → review → Accept agreement.
What this means in practice
For most readers this matters because a developer or a billing platform is building on AWS on your behalf. Accepting the addendum is genuinely simple: an administrator opens AWS Artifact, finds the business associate addendum under agreements, accepts the Artifact confidentiality terms and then accepts the addendum. If you run AWS Organizations you can accept once and have member accounts picked up automatically, which is the cleanest option when accounts multiply.
What takes discipline is the eligible services list. You may run anything you like in the account, but only services on that list may touch patient data, and the carve-outs inside otherwise-eligible services are where projects come unstuck. SageMaker excludes Studio Lab, Ground Truth Plus and the public and vendor workforces. CloudFront excludes Embedded Points of Presence. Pinpoint excludes voice messaging and the WhatsApp channel. RDS is eligible only for particular database engines, and some Bedrock foundation models are excluded even though the service itself qualifies.
The habit to build is a check against that list every single time somebody proposes adopting a new AWS service.
How organizations get this wrong
The specific mistakes we see with AWS, not generic advice.
- Assuming an account is covered because a developer clicked through something once, without confirming the addendum shows as accepted in AWS Artifact.
- Reading a service name on the eligible list as blanket approval, when RDS qualifies only for specific engines and SageMaker carves out several components.
- Spinning up a new AWS service for a quick reporting job without re-checking the eligible services list first.
- Accepting on the main account while an older second account quietly holds backups outside any organization-wide acceptance.
What the agreement does not cover
- Any service not on the HIPAA Eligible Services Reference.
- Named carve-outs inside otherwise-eligible services — for example SageMaker AI excludes Studio Lab, Ground Truth Plus and the public and vendor workforces; CloudFront excludes Embedded Points of Presence; Amazon Pinpoint excludes voice messaging and the WhatsApp channel; Amazon RDS is eligible for specific engines only.
- Some Amazon Bedrock foundation models are excluded even though the service is eligible.
Alternatives
Listed on merit. We take no payment for placement and use no affiliate links.
Microsoft Azure
Equivalent cloud where the agreement applies by default through Microsoft's Data Protection Addendum
Google Cloud Platform
Comparable cloud with a click-through agreement and a published covered-services list
Signing the agreement is step one. Proving it is step two.
Once you have the agreement with AWS, someone has to know it exists, where the copy is, when it needs revisiting and who owns it. That register is what a client's security questionnaire is actually asking about, and it is the section of an evidence pack most organizations cannot produce on request.
$79/month, 14-day free trial, no credit card. The checker itself stays free and needs no account.
Sources
Every statement above comes from Amazon Web Services’s own published documentation, read on the date shown.
- HIPAA Compliance — Amazon Web Services. No publication date given. Read July 29, 2026.
- HIPAA Eligible Services Reference — Amazon Web Services. No publication date given. Read July 29, 2026.
- Managing agreements in AWS Artifact — Amazon Web Services. No publication date given. Read July 29, 2026.
Change history
- — First published.
This page is information, not certification and not legal advice. It reflects Amazon Web Services’s published documentation as read on July 29, 2026; vendors change their terms without notice, so confirm anything you rely on directly with the vendor. Whether your own use is compliant depends on your configuration, your executed agreement and how your staff actually work. No company can be “HIPAA certified” — no such designation exists.
Think something here is wrong or out of date? Tell us at support@hipaacompliancesoftware.org — corrections are published with a dated note in the change history above, never silently. See our editorial standards for how entries are researched and re-verified.