Is AWS HIPAA Compliant? Requirements and Setup

Is AWS HIPAA Compliant? The Short Answer

Yes, with three conditions:

1. A signed BAA. AWS calls it the Business Associate Addendum, and you accept it in your AWS account.
2. Eligible services only. ePHI may only be processed, stored or transmitted in services on AWS’s HIPAA-eligible list.
3. Your configuration. The safeguards HIPAA requires, from access control to audit logs, are set up and run by you.

Miss any one of the three and the environment isn’t compliant, however secure AWS’s own infrastructure is.

Introduction

AWS is one of the most common homes for healthcare apps, whether teams run it themselves or through vendors like us. AWS signs a BAA and makes many of its services eligible for ePHI. But the question teams ask, “is AWS HIPAA compliant?” hides the harder one: which parts are now ours?

This guide answers that for AWS specifically: what the BAA covers, which services are eligible, how to set up each safeguard, and where patient data ends up in a real healthcare app. For the requirements that apply to any host, see what HIPAA-compliant hosting requires.

The AWS Business Associate Addendum

AWS signs a BAA, which it calls the Business Associate Addendum. You review and accept it yourself in AWS Artifact, in the AWS Management Console. There are two versions:

• Account agreement: covers the AWS account that accepts it.
• Organization agreement: accepted from the management account of an AWS organization; it covers the member accounts in that organization, including accounts added later.

The BAA sets out what AWS is responsible for under HIPAA. It doesn’t transfer your responsibilities to AWS. For what a BAA does and doesn’t do, see What Is a Business Associate Agreement (BAA)?

Which AWS Services Are HIPAA Eligible?

AWS publishes its current list on its HIPAA Eligible Services Reference and updates it regularly. AWS says customers should only process, store and transmit PHI in the services the BAA defines as eligible. These are the ones healthcare teams ask about most:

Eligibility list last checked: [date at publication]. Before using any service with ePHI, check it against AWS’s current list.

Is Amazon RDS HIPAA compliant?

RDS is HIPAA eligible. You still need to enable encryption when you create the database, restrict network access, and set up backups and audit logging.

Is AWS Lambda HIPAA compliant?

Lambda is HIPAA eligible. The usual risk is logging: anything a function prints goes to CloudWatch Logs, so keep patient data out of log statements and encrypt the log groups.

Is Amazon Bedrock HIPAA compliant?

Bedrock is HIPAA eligible. Before sending ePHI, check AWS’s current reference for any excluded features or models and the terms of the model you use, and store prompts and outputs that contain PHI with the same controls as other ePHI.

Shared Responsibility on AWS

AWS describes its split as security of the cloud (AWS) and security in the cloud (you). How much falls on you depends on the type of service:

• Infrastructure services such as EC2: you’re responsible for the operating system, patching, firewall rules, applications, and data.
• Managed services such as RDS and Aurora: AWS patches the database engine; you configure encryption, access, backups, and network exposure.
• Serverless and storage services such as Lambda and S3: AWS runs the platform; you control permissions, encryption settings, logging, and what you put in them.

What follows is the AWS side of your share.

How to Set Up a HIPAA-Compliant AWS Environment

These are common configuration steps on AWS, not a complete compliance program. Which you need, and how, depends on your architecture and risk analysis, and HIPAA’s administrative safeguards, policies and incident procedures sit alongside them. The safeguards themselves are explained in What Are HIPAA Technical Safeguards?

1. Control access

Use AWS IAM to give each person and service only the permissions they need. Require multi-factor authentication for people, and keep the root user for account-level tasks only.

2. Encrypt ePHI

Use AWS KMS to encrypt databases, storage and backups that hold ePHI, and TLS for data in transit. For RDS, Aurora and EBS volumes, encryption is chosen when the resource is created, so decide it up front. Encryption is addressable under HIPAA, but on AWS it’s usually the straightforward choice.

3. Log activity at two levels

AWS CloudTrail records actions in your AWS accounts. Turn on data events for storage holding ePHI where you need to know who accessed specific files. Your application also needs its own audit log, because AWS logs show which service role fetched a record, not which clinician or patient asked for it. AWS Config can flag resources that drift from your chosen settings, but it checks configuration; it doesn’t establish compliance.

4. Back up and test restores

Back up every ePHI store, using AWS Backup where it supports the service and service-native backups elsewhere. Keep copies separate from production, in another Region only where your data-residency requirements allow, and test restores on a schedule.

5. Limit network exposure

Run application servers and databases that handle ePHI in private subnets of an Amazon VPC, restrict traffic with security groups, and use VPC endpoints so traffic to AWS services stays off the public internet.

6. Watch for threats

Turn on Amazon GuardDuty and AWS Security Hub, and make sure someone acts on their findings.

7. Manage sessions

Keep AWS console and credential sessions short. Separately, build an inactivity timeout into your own application; the two are different controls.

8. Retain and dispose of data deliberately

Use lifecycle and retention settings to delete ePHI when your retention policy says it’s no longer needed. Don’t delete encryption keys as a disposal shortcut: retire a KMS key only after confirming that no backups, snapshots, or records are still under retention depending on it.

AWS’s whitepaper Architecting for HIPAA Security and Compliance on Amazon Web Services covers service-by-service configuration in more depth.

Where PHI Lands in a Healthcare Communication App on AWS

Most AWS HIPAA guides stop at the database. In a healthcare communication app, PHI spreads into storage, logs, and services that teams don’t think of as holding patient data. The list below is illustrative, showing where these stores typically live on AWS:

• Messages and conversation history, for example in RDS or Aurora: encrypted, with access limited to the application.
• Attachments such as photos, lab results, and insurance cards, for example, in S3: private buckets, encryption, and access logging.
• Call recordings and transcripts: retention rules, so recordings aren’t kept forever by default.
• Application and server logs, for example, in CloudWatch Logs: message content and patient identifiers kept out of log lines.
• Push notifications, sent through Apple’s and Google’s services: notification text that says only that a new message is waiting.
• AI prompts and summaries, for example, in Bedrock: checked against AWS’s reference and stored under the same controls as messages.
• Backups and snapshots: encrypted, access-restricted, and covered by the same retention policy.

Common Mistakes on AWS

The BAA covers one account, but ePHI lives in several. A staging, analytics, or new account needs its own acceptance unless an organization agreement already covers it.

A non-eligible service is added after launch. A logging, search, or AI service added months later is the one most often missed in eligibility checks.

Encryption is left for later. RDS, Aurora, and EBS encryption is set when the resource is created. Encrypting an existing unencrypted database means copying it to a new one.

PHI in logs. Debug logging in Lambda functions and application servers can write message content straight into CloudWatch.

Relying on AWS logs alone. CloudTrail shows what happened in your AWS accounts, not which user of your app opened which record. You need both.

Real patient data in development. Test environments rarely have production’s controls. Use synthetic or de-identified data.

If you’d rather not run this yourself, our guide to managed or self-hosted hosting for HIPAA apps covers when each makes sense.

QuickBlox on AWS

QuickBlox runs chat, video calling, and AI agents for healthcare apps on AWS in two ways:

• Our HIPAA cloud: a managed environment on AWS with a signed BAA, where we operate the infrastructure under the agreed service.
• Your own AWS account: an Enterprise deployment we install, monitor, and support in your account, so ePHI stays in infrastructure you control.

In both, messages, files and call data are encrypted at rest and in transit, with role-based access control. See our HIPAA-compliant hosting options, or talk to our team about running on AWS.

AWS gives healthcare teams compliant building blocks: a BAA, eligible services, and strong security tooling. Compliance comes from how you assemble them. Sign the BAA for every account that holds ePHI, keep ePHI inside eligible services, set up each safeguard deliberately, and map every place patient data lands, not just the database.

Sources

• AWS: HIPAA Compliance (BAA accepted in AWS Artifact, account and organization agreements, eligible-services rule, no HIPAA certification for cloud providers)
• AWS: HIPAA Eligible Services Reference
• AWS whitepaper: Architecting for HIPAA Security and Compliance on Amazon Web Services