AWS HIPAA Eligible Services

Which AWS services are HIPAA eligible?

On AWS the term is HIPAA eligible, not HIPAA compliant, and the difference decides how you build. AWS publishes a list of services that are eligible to create, receive, process, maintain or transmit electronic protected health information. Eligibility means AWS permits that service to handle PHI once you have accepted the AWS Business Associate Addendum. It does not mean the service is compliant on your behalf. AWS says so directly: customers must still configure these services consistent with HIPAA requirements, and customers are responsible for ensuring their own HIPAA compliance. No AWS service makes you HIPAA compliant by itself.

Book a free architecture review →HIPAA on AWS

The three partsALL REQUIRED

Eligible is not compliant.

1. EligibleService on the AWS list

2. BAAAccepted in AWS Artifact

3. ConfigEncryption, access, logging

ThenYour auditor attests

The Eligibility Table

The services HealthTech teams actually ask about.

Every row below is taken from the AWS HIPAA Eligible Services Reference, which AWS last updated on 3 August 2026. This is a working subset, not the full list, which runs to well over a hundred services. Always check the live AWS page before an architecture decision, because AWS adds services to it over time.

AWS service	Eligible under a BAA	What still needs configuring
Amazon RDS	Eligible	SQL Server, MySQL, Oracle, PostgreSQL, Db2 and MariaDB engines only. Encrypt at rest with KMS, force TLS in transit, and remember snapshots inherit the encryption decision.
Amazon Aurora	Eligible	Both the MySQL and PostgreSQL compatible editions. Storage encryption is set at cluster creation and cannot be toggled later.
AWS Lambda	Eligible	Environment variables are not a secret store. Use Secrets Manager or KMS, run in a VPC when reaching private data, and keep PHI out of logs.
Amazon S3	Eligible	Default encryption on, Block Public Access on, versioning and access logging enabled. Most PHI exposure stories start with a bucket policy.
Amazon EC2	Eligible	Encrypt EBS volumes and snapshots, patch to a baseline, and keep instances holding PHI in private subnets.
Amazon ECS	Eligible	Task definitions should pull secrets by reference, not literal values. Container logs are a common accidental PHI sink.
Amazon EKS	Eligible	Encrypt secrets at rest with KMS, keep the API endpoint private where possible, and enable audit logging.
AWS Fargate	Eligible	ECS and EKS engines only, per the AWS reference. Same logging and secrets discipline as the orchestrator above it.
Amazon DynamoDB	Eligible	Encryption at rest is on by default. Use a customer managed key where you need an independent authorization gate.
Amazon ElastiCache	Eligible	Enable encryption in transit and at rest explicitly. Caches holding PHI are easy to forget in an evidence pack.
Amazon CloudFront	Eligible	Excludes content delivery through CloudFront Embedded Points of Presence. Check this before assuming full coverage.
Amazon SES	Eligible	Email carrying PHI needs enforced TLS and careful handling of bounce and complaint data.
Amazon SNS	Eligible	Encrypt topics with KMS. Message bodies and delivery logs both count as places PHI can leak.
AWS KMS	Eligible	The key layer under most of the above. Scope key policies so a misconfigured IAM policy alone is not enough to decrypt.
Amazon CloudWatch Logs	Eligible	Eligible, but treat it as a PHI store if your application logs PHI. Encrypt log groups and set retention deliberately.

Source: AWS HIPAA Eligible Services Reference, the canonical list. One point people miss: a service not on that list is not banned from your account. AWS allows you to use services that are not listed inside a HIPAA account, provided they do not process or store PHI. The boundary is where PHI goes, not which services exist.

Per Service

The three questions we get asked most.

Is Amazon RDS HIPAA compliant?

RDS is HIPAA eligible, not HIPAA compliant, and the AWS reference qualifies it: SQL Server, MySQL, Oracle, PostgreSQL, Db2 and MariaDB engines only. You can store PHI in RDS once your BAA is accepted. What you still owe: encryption at rest with KMS enabled at creation time, TLS enforced for connections rather than merely available, and automated backups and snapshots treated as PHI themselves, because an unencrypted snapshot is exactly the gap an auditor looks for. Enable enhanced logging and ship it somewhere the database team cannot quietly edit.

Is AWS Lambda HIPAA compliant?

Lambda is HIPAA eligible under a BAA. The configuration essentials are specific to how people actually use it: keep credentials in Secrets Manager or KMS rather than environment variables, which are readable by anyone with function read access; run functions in a VPC when they reach private data so PHI does not traverse the public internet; and audit what you log, because a debug line printing a request body is the most common way PHI ends up somewhere nobody classified as a PHI store.

Is Amazon Aurora HIPAA compliant?

Aurora is HIPAA eligible under a BAA, and AWS confirms both the MySQL compatible and PostgreSQL compatible editions. If your BAA is already accepted, no further step is needed to start using it in the covered accounts. The configuration catch worth knowing early: Aurora storage encryption is chosen when the cluster is created and cannot be switched on afterwards, so an unencrypted cluster means a migration rather than a setting change. Pair that with TLS in transit, IAM database authentication where it fits, and audit logging retained long enough to answer an investigation.

The BAA

What a BAA is, and how to get one.

Under HIPAA, a cloud provider handling PHI is a business associate. The Business Associate Addendum is the contract that makes that relationship explicit and limits how AWS may use and disclose PHI.

Step 1

Accept it in AWS Artifact

AWS offers a standard BAA and you accept it yourself through AWS Artifact in the console, for a single account or across an AWS Organization. It is self-service, so there is no sales process and nothing to negotiate.

Step 2

Designate your HIPAA accounts

You may use any AWS service in an account covered by the BAA, but PHI must only be processed, stored and transmitted in the eligible services. Account separation is the cleanest way to keep that boundary provable.

If you are SaaS

Your customers sign with you

A SaaS provider signs the BAA with AWS, and each healthcare customer signs a BAA with the provider rather than with AWS. A covered entity that is also a direct AWS customer may need both.

The BAA is necessary and nowhere near sufficient. AWS is explicit that you agree not to use HIPAA eligible services with PHI without first entering into one, and equally explicit that accepting it does not configure anything for you. It changes what you are permitted to do; it does not change what you have built.

Beyond Eligibility

What a compliant architecture actually needs.

Picking eligible services is the easy part and takes an afternoon. The work that decides whether an audit goes well is everything after it.

The parent compliance page

Our HIPAA on AWS page covers the full picture: BAA, encryption, access controls, audit logging and PHI segmentation, and how those become the evidence your auditors and compliance team need in order to attest.

Find the gaps, then close them

A cloud security audit tells you where the environment actually stands against these controls, and AWS security hardening is the remediation work that closes what it finds and documents each change.

Built for HealthTech specifically

If you are a digital health or clinical SaaS team, our HealthTech on AWS page covers the wider picture, including GDPR Article 9 and NHS DSP alongside HIPAA. Our published UK HealthTech case study covers a 38% AWS cost reduction in 90 days on that kind of estate.

Common Questions

HIPAA on AWS, answered plainly.

This page is engineering guidance, not legal advice. Your auditors and compliance team attest to HIPAA compliance; we build and evidence the infrastructure that lets them.

Does using HIPAA eligible services make us compliant?+

No. Eligibility is a precondition, not a finish line. AWS states that customers must still configure these services consistent with HIPAA requirements, and that customers are responsible for ensuring their own HIPAA compliance when using any AWS service. Eligibility means AWS permits that service to handle protected health information once a Business Associate Addendum is in place. Everything after that is your architecture: encryption at rest and in transit, least-privilege access, audit logging, network isolation, backup handling, and keeping PHI out of services that are not on the list. Your auditors attest to HIPAA compliance; the infrastructure only makes that attestable.

Do we need a BAA with AWS?+

Yes, before any protected health information touches AWS. The Business Associate Addendum is the contract that makes AWS a business associate under HIPAA, and AWS is explicit that you agree not to use HIPAA eligible services with PHI without first entering into one. You review and accept it yourself through AWS Artifact in the console, for a single account or across an organisation, so there is nothing to negotiate. One nuance worth knowing: if you are a SaaS provider, you sign the BAA with AWS and your healthcare customers sign a BAA with you, not with AWS.

Is there an extra cost for HIPAA eligible services?+

AWS does not publish separate HIPAA pricing. The eligible services are the same services at the same published rates, and the BAA is accepted through AWS Artifact rather than sold as an add-on. What does cost more is the architecture HIPAA pushes you toward: encryption everywhere, longer log retention, isolated environments, backups you actually test, and often multi-account separation. Budget for the design, not for a HIPAA surcharge. Check current rates on the AWS pricing pages, since we do not republish AWS prices here.

Is AWS HIPAA certified?+

No, and neither is any other cloud provider. AWS states plainly that there is no HIPAA certification for a cloud service provider. Instead AWS aligns its HIPAA risk management program with FedRAMP and NIST 800-53, which map to the HIPAA Security Rule. That is why nobody can hand you a HIPAA certificate for AWS, and why anyone selling you one is describing something that does not exist. What you can get is a signed BAA, eligible services, correct configuration, and evidence.

Which AWS regions can host PHI?+

AWS does not scope HIPAA eligibility by region on its HIPAA Eligible Services Reference. The list is per service, not per region, so the practical constraints are different ones: whether the service is available in the region you want, and what your own data residency obligations and customer contracts require. In practice most US healthcare workloads sit in US regions for latency and residency reasons rather than because AWS forces it. If residency is contractual for you, pin it with a guardrail rather than a policy document.

Can HAZERCLOUD sign a BAA?+

The BAA that matters for your AWS infrastructure is the one between you and AWS, and you accept that yourself in AWS Artifact. Our role is the architecture and the evidence: designing PHI workloads on eligible services, configuring encryption, access control, logging and network isolation, and documenting each control so your auditors and compliance team can attest. HAZERCLOUD holds ISO 27001:2022, so the team building your environment is audited against a recognised information security standard itself. For any contractual arrangement specific to your engagement, raise it on the call and we will answer directly rather than in a website FAQ.