Is Amazon RDS HIPAA compliant? What the BAA covers and what you still configure

Amazon RDS is HIPAA eligible, which is narrower than HIPAA compliant. AWS lists RDS and Aurora on its HIPAA Eligible Services Reference, so once you have accepted the AWS Business Associate Addendum you may store protected health information in them. Whether your database is compliant depends on how you configure encryption, connections, audit logging, backups and access.

The settings differ by engine, one of them can't be changed after the instance exists, and the audit trail most teams assume they have doesn't record a single query. This guide goes through RDS and Aurora setting by setting, with the AWS documentation behind each one.

Is Amazon RDS HIPAA compliant or HIPAA eligible?

Eligible. AWS is explicit that "there is no HIPAA certification for a cloud service provider (CSP) such as AWS" (AWS HIPAA compliance page). What exists is a Business Associate Addendum, which you review and accept in AWS Artifact, and a list of services AWS agrees to cover under it. You may use any AWS service in an account covered by the BAA, but you should only process, store and transmit PHI in the services on that list.

The same page that lists RDS also says: "Customers still must configure these services consistent with HIPAA requirements." The RDS documentation puts the split the same way: your responsibility "is determined by the sensitivity of your data, your organization's compliance objectives, and applicable laws and regulations" (Amazon RDS User Guide).

So the BAA answers one question: may PHI live here. Everything below is about the second question, whether it is protected once it does. If you haven't accepted the BAA yet, start with our guide to making AWS HIPAA compliant, which covers the agreement and the wider eligible services list.

Which RDS engines and features does the BAA cover?

RDS Proxy, RDS Custom, Aurora Serverless and Performance Insights don't have entries of their own. The reference covers them with a general rule: "Unless specifically excluded, generally available features of each of the HIPAA eligible services listed are also considered HIPAA eligible." If a feature matters to your design, read the current list before you commit to it. The list changes, and entries carry qualifiers, as the RDS one does.

Encryption at rest: the one setting you can't fix later

The HIPAA Security Rule lists encryption at rest as an addressable specification: "Implement a mechanism to encrypt and decrypt electronic protected health information" (45 CFR 164.312(a)(2)(iv)). Addressable means you document a decision, not that you may skip it, and on a managed database there is no defensible reason to decide against it.

On RDS the constraint is timing. "You can only encrypt an Amazon RDS DB instance when you create it, not after the DB instance is created." The documented way out for an existing instance has four steps:

1. Take a snapshot of the unencrypted instance.
2. Create a copy of that snapshot and specify a KMS key, which produces an encrypted snapshot.
3. Restore a new DB instance from the encrypted copy.
4. Point the application at the new endpoint and retire the old instance.

That is a migration with a cutover and a write freeze to plan around.

When encryption is on, it covers "the underlying storage for DB instances, its logs, automated backups, read replicas, and snapshots." Three limits are worth knowing before you pick a key:

• You can't change the KMS key of an encrypted instance after creation.
• A snapshot encrypted with the AWS managed key for RDS can't be shared with another account. If your backup or disaster recovery design copies snapshots to a separate account, you need a customer managed key from the start.
• Copying an encrypted snapshot to another Region requires a KMS key in the destination Region, because KMS keys are Regional.

A customer managed key gives you control over the key policy, rotation and who can use the key. That control is the reason to choose it.

Aurora changed in 2026. All new Aurora clusters created on or after 18 February 2026 are encrypted at rest by default, using an AWS owned key unless you specify your own (Amazon Aurora User Guide). Clusters created before that date without encryption stay unencrypted, and so do the snapshots, clones and replicas made from them. An older Aurora cluster holding PHI deserves a check.

Encryption in transit: enforce TLS in the parameter group

Every RDS engine supports TLS. Supporting it and requiring it are different settings, and the requirement lives in the DB parameter group.

Sources: the SSL/TLS pages for PostgreSQL, SQL Server, MySQL and MariaDB in the Amazon RDS User Guide. Oracle and Db2 configure TLS through their own options; check the engine page.

An instance on PostgreSQL 14 or older, on MySQL, or on SQL Server is unenforced unless someone changed the parameter. A PostgreSQL client on libpq's default sslmode=prefer negotiates TLS whenever the server offers it, so the application is probably encrypted already. Nothing stops a client that asks for a plain connection.

Audit logging: CloudTrail doesn't see your queries

The Security Rule's audit controls standard asks for "mechanisms that record and examine activity in information systems that contain or use electronic protected health information" (45 CFR 164.312(b)). For a database, that means who read or changed which records.

CloudTrail records calls to the RDS API: who created the instance, modified the parameter group, shared a snapshot. It has no view of SQL running inside the database. That layer is configured per engine:

• PostgreSQL: the pgAudit extension. Add pgaudit to shared_preload_libraries in a custom parameter group, reboot, run CREATE EXTENSION pgaudit;, then set pgaudit.log. The default is none, so an instance with the extension installed and nothing else changed logs nothing (Amazon RDS User Guide).
• MySQL and MariaDB: the audit log needs a custom option group with the MARIADB_AUDIT_PLUGIN option.
• Oracle: the audit log depends on the audit_trail parameter, whose default is none.
• SQL Server: only the error and agent logs publish to CloudWatch Logs, so query-level auditing is configured inside the engine and can be streamed out with Database Activity Streams.

Database Activity Streams push activity to a Kinesis data stream in near real time, always encrypted with a KMS key, and AWS designed them for separation of duties: "Amazon RDS DBAs don't have access to the collection, transmission, storage, and processing of the streams." On RDS they exist for Oracle and SQL Server only. They "aren't available" for RDS for Db2, MariaDB, MySQL or PostgreSQL (Amazon RDS User Guide). Aurora is different: both Aurora PostgreSQL and Aurora MySQL support them, and Aurora PostgreSQL adds a synchronous mode that favours the accuracy of the stream over database performance.

Whichever route you take, publish the logs to CloudWatch Logs and set a retention period. CloudWatch keeps log data indefinitely unless you tell it otherwise. One more thing to plan for: audit logs record statement text. If your application sends literal values in its SQL, PHI ends up in the log group, so treat the log group as PHI. Encrypt it with KMS, restrict who can read it, and decide how long it lives.

Backups and snapshots: where PHI leaks out of a well-configured database

Automated backup retention can be set from 0 to 35 days, and 0 turns automated backups off. The default depends on how the instance was created: one day through the API or CLI, seven days through the console. Infrastructure-as-code tools create instances through the API and may apply defaults of their own, so set the value explicitly in your module.

HIPAA's six-year retention rule, 45 CFR 164.316(b)(2)(i), is about retaining the documentation of your policies and procedures. It doesn't by itself set a retention period for database backups. State medical record laws and your own retention policy do that, and the answer is usually delivered with AWS Backup and snapshot copies, not with the 35-day automated window.

Snapshots are the quieter risk. An unencrypted manual snapshot can be shared as public, and AWS's own warning is blunt: "all AWS accounts can restore a DB instance from your manual DB snapshot and have access to your data." (Amazon RDS User Guide) Encrypted snapshots can't be made public at all, which is one more argument for encrypting at creation. The AWS Config rule rds-snapshots-public-prohibited catches the mistake either way.

A backup that has never been restored is an assumption. We wrote about closing that gap in AWS backup restore testing; an encrypted Multi-AZ database with a customer managed key is exactly the resource those tests should cover.

Network and access

• Not publicly accessible. Put the instance in private subnets, set public accessibility to no, and let security groups name the application tier and nothing wider.
• Multi-AZ for production. The Security Rule covers availability of ePHI as well as confidentiality, and rds-multi-az-support is one of the rules in the AWS Config HIPAA conformance pack.
• Short-lived credentials where the engine allows it. IAM database authentication works with MariaDB, MySQL and PostgreSQL, and each token lasts 15 minutes. AWS notes that "CloudWatch and CloudTrail don't log IAM authentication" (Amazon RDS User Guide), so the record of who connected and what they ran still comes from the engine-level audit logging described above.
• Rotated secrets everywhere else. The HIPAA environment we described with AWS on the AWS Partner Network blog uses AWS Secrets Manager with 30-day rotation.

These controls hold better when they are enforced above the account as well as inside it. Organization-level guardrails are covered in our piece on AWS service control policies.

How to check an existing RDS instance

One CLI call answers most of the questions above for every instance in a Region:

aws rds describe-db-instances \
  --query 'DBInstances[].{id:DBInstanceIdentifier,engine:Engine,version:EngineVersion,encrypted:StorageEncrypted,kmsKey:KmsKeyId,public:PubliclyAccessible,multiAz:MultiAZ,backupDays:BackupRetentionPeriod,logExports:EnabledCloudwatchLogsExports,iamAuth:IAMDatabaseAuthenticationEnabled}'

Read it like this. encrypted: false means a rebuild. If aws kms describe-key shows KeyManager: AWS for the kmsKey, the instance uses the AWS managed key and its snapshots can't be shared across accounts. backupDays: 1 usually means nobody chose it. An empty logExports means the database logs never leave the instance. iamAuth: false on MySQL, MariaDB or PostgreSQL means the database still relies on long-lived passwords.

For continuous checking, the AWS Config conformance pack "Operational Best Practices for HIPAA Security" includes rds-storage-encrypted, rds-snapshot-encrypted, rds-snapshots-public-prohibited, rds-multi-az-support and db-instance-backup-enabled. AWS is careful about what the pack is: conformance packs "are not designed to fully ensure compliance with a specific governance or compliance standard" (AWS Config Developer Guide). A passing rule tells you a setting hasn't drifted. Whether your audit logs would answer an investigator's question is outside what it checks.

What it looks like when it's built in from the start

When we built the AWS foundation for rXperius, a US company working with pharma and the FDA, the database layer was Aurora Serverless inside a multi-account organization, with encryption at rest and in transit, Multi-AZ resilience, and GuardDuty, Security Hub and CloudWatch watching the environment. The environment is 100% managed as infrastructure as code, which is what keeps settings like the ones in this article from depending on someone's memory. The details are in the rXperius case study.

Encryption at rest is the only control here that has to be decided when the instance is created. The others (TLS enforcement, audit logging, backup retention, Multi-AZ) can all be changed on an existing instance. For the rest of the environment, our step-by-step guide to becoming HIPAA compliant starts with the account structure.

Conclusion

RDS and Aurora being on the eligible list settles where PHI may live. The configuration stays with you, and the part to get right before anything else is encryption at creation with a key you control.

If you are putting PHI on AWS and want the foundation reviewed or built by people who do this for health-tech teams, see how we work with healthcare companies on AWS.