AWS makes HIPAA on the cloud very doable — but “we run on AWS” and “we’re HIPAA-ready on AWS” are two different things. AWS gives you a compliant foundation; the controls that pass an audit are the ones you configure on top. Here’s the concrete setup: sign the BAA, stay on eligible services, encrypt with KMS, lock down access, and log everything.
Informational, not legal advice — validate your specific setup with counsel and, ideally, an auditor.
Sign the AWS BAA — and understand what it covers
AWS will sign a Business Associate Addendum, self-serve through AWS Artifact. Once accepted, it applies across your AWS accounts. But the BAA only covers PHI processed on HIPAA-eligible services. AWS publishes this list, and it’s long — EC2, S3, RDS, EKS, Lambda, DynamoDB, CloudTrail, KMS, and most of the core stack are eligible. Some newer or niche services are not.
The operative rule: PHI may only touch HIPAA-eligible services. If you route PHI through a non-eligible service — even briefly, even in a log — you’re outside the BAA’s coverage for that data. Keep an internal list of which services in your architecture handle PHI and confirm each is eligible. This is exactly the kind of thing an auditor will ask you to demonstrate.
Shared responsibility is the mental model: AWS secures the cloud; you secure what you put in it. The BAA covers the former. Everything below is the latter.
Encryption: in transit and at rest, backed by KMS
Encryption is the control that comes up first in every review, and it’s cheap to get right.
In transit: TLS everywhere. Terminate at the ALB with ACM certificates, enforce HTTPS-only (redirect or reject HTTP), and require TLS for internal service-to-service traffic that carries PHI. Enforce TLS on S3 with a bucket policy that denies aws:SecureTransport = false.
At rest: encrypt every store that holds PHI with KMS — RDS, EBS, S3, DynamoDB, EFS, and your backups/snapshots. Practical guidance that separates a passing setup from a hand-wave:
- Use customer-managed KMS keys (CMKs), not just the default AWS-managed keys, where you want control over key policy and rotation.
- Enable automatic key rotation on those CMKs.
- Scope key policies tightly — only the roles that need to decrypt PHI should have
kms:Decrypt. - Turn on default encryption at the bucket/volume level so nothing lands unencrypted by accident.
Encrypting at rest with a per-workload key and a tight key policy is what turns “we use encryption” into “we can show you exactly who can decrypt what.”
Access controls: least privilege, enforced
The Security Rule wants unique identity, least privilege, and no standing access you can’t justify.
- No IAM users for humans. Federate through SSO/IAM Identity Center so every person has a unique identity and MFA. Kill long-lived access keys.
- Roles, not shared credentials. Services assume scoped IAM roles; humans assume roles for the least privilege needed.
- MFA everywhere, and hard-block root account usage for daily work.
- Network isolation. PHI workloads in private subnets, security groups scoped to specific ports/sources, and VPC endpoints for S3/DynamoDB so PHI traffic to AWS services never traverses the public internet.
- Segregate environments. Production PHI does not live in the same account or VPC as dev/test. Separate AWS accounts under Organizations is the clean pattern.
The test an auditor applies: pick a random engineer and ask what PHI can this person reach, and why? You want a short, defensible answer.
Audit logging: prove who did what
HIPAA requires you to record and examine access to systems with PHI. On AWS that means:
- CloudTrail enabled in all regions, logging management and relevant data events, delivered to a dedicated, locked-down logging account.
- S3 access logging or CloudTrail data events on PHI buckets so object-level access is recorded.
- VPC Flow Logs for network-level visibility.
- CloudWatch / GuardDuty / Security Hub for monitoring and anomaly detection — and alarms that actually notify a human.
- Tamper resistance: log buckets with versioning, MFA-delete or Object Lock, and access restricted so the accounts being audited can’t quietly erase their own trail.
Two things trip teams up. First, retention — keep logs long enough to satisfy your policy and any customer BAA (multi-year is common). Second, PHI in logs — application logs, error trackers, and debug output routinely leak PHI. Scrub it at the source; a PHI-filled log stream is both a breach risk and an audit finding.
Backups, recovery, and the paper trail
- Encrypted, automated backups (RDS automated backups/snapshots, AWS Backup) with the same KMS discipline as primary data.
- Test your restores. An untested backup is a hope, not a control, and contingency planning is an explicit Security Rule requirement.
- Retention and deletion policies that match your BAA commitments — including secure deletion when a customer offboards.
- Document it. The config above only “passes audit” if you can produce the artifacts: the signed BAA, your KMS key policies, IAM/SSO setup, CloudTrail configuration, and a written risk analysis tying it together.
A minimal reference shape
Put together, a HIPAA-ready AWS baseline looks like: a multi-account Organization with a dedicated logging account; PHI workloads in private subnets on HIPAA-eligible services; SSO-federated access with MFA and scoped roles; KMS CMKs with rotation and tight key policies on every PHI store; TLS enforced end to end; CloudTrail + Flow Logs + GuardDuty flowing to tamper-resistant storage; and encrypted, tested backups. None of it is exotic — it’s disciplined defaults, configured on purpose and written down.
The founder takeaway
AWS hands you a compliant foundation the moment you sign the BAA — but the audit is passed or failed by your configuration: eligible services only, KMS everywhere, least-privilege access, and tamper-resistant logs you can produce on demand. Build the baseline once and every future security review gets shorter.
What are HIPAA-eligible services on AWS?
AWS designates a specific list of HIPAA-eligible services — the ones you’re permitted to process PHI on under the BAA — and it covers most of the core stack you’d actually build on. The mainstays are eligible: EC2, S3, RDS, Aurora, DynamoDB, EKS, ECS, Lambda, EFS, CloudTrail, CloudWatch, KMS, ELB/ALB, API Gateway, SNS, SQS, and AWS Backup, among many others. AWS maintains the authoritative list and updates it regularly, so treat the published list as the source of truth rather than memory.
The rule that matters: PHI may only touch HIPAA-eligible services. If PHI flows through a non-eligible service — even transiently, even in a log line — that data falls outside the BAA’s coverage. Two habits keep you safe. First, keep an internal inventory of which services in your architecture handle PHI and confirm each against the current eligible list. Second, watch the edges — a newer or niche service you adopt for convenience may not be eligible yet, and analytics, notification, or AI/ML services are common places PHI leaks somewhere it shouldn’t. Auditors will ask you to demonstrate that PHI stays within eligible services, so build that inventory before they do.
How do I sign the AWS BAA?
Signing is refreshingly self-serve. AWS provides the Business Associate Addendum through AWS Artifact in the console — you accept it online, and once accepted it applies across the AWS accounts in your organization. There’s no sales call or manual contract negotiation required for the standard addendum. A few practical notes:
- Accept it before PHI lands in the account. The BAA governs PHI processing; get it in place first.
- It applies org-wide, but eligibility is per-service. Signing the BAA doesn’t magically make every service safe for PHI — it only covers PHI on eligible services, configured correctly.
- Keep a copy of the accepted BAA as an audit artifact. When a customer’s security team or an assessor asks for proof, you want to produce it immediately, alongside your KMS key policies, IAM/SSO setup, and CloudTrail configuration.
Remember the shared responsibility model throughout: the BAA and AWS’s controls secure the cloud; your configuration secures what you put in it.
Frequently asked questions
Does signing the AWS BAA make my startup HIPAA compliant? No. The BAA is necessary but not sufficient. It covers AWS’s responsibility for the security of the cloud on HIPAA-eligible services — but your compliance depends on how you configure things in the cloud: eligible services only, KMS encryption, least-privilege access, tamper-resistant audit logs, tested backups, and the written documentation tying it together.
How do I sign the AWS BAA? Accept the Business Associate Addendum through AWS Artifact in the AWS console. It’s self-serve, requires no sales negotiation for the standard addendum, and applies across the accounts in your AWS Organization once accepted. Sign it before any PHI enters the account, and keep a copy as an audit artifact.
Which AWS services are HIPAA-eligible? Most core services are — EC2, S3, RDS, Aurora, DynamoDB, EKS, ECS, Lambda, EFS, CloudTrail, KMS, ALB, API Gateway, and AWS Backup, among many others. AWS publishes and regularly updates the authoritative list; check it rather than assuming, because PHI may only touch eligible services.
Do I have to use customer-managed KMS keys for HIPAA? HIPAA doesn’t name KMS specifically — it requires reasonable encryption. In practice, customer-managed KMS keys (CMKs) with automatic rotation and tightly scoped key policies are what turn “we use encryption” into “we can show exactly who can decrypt what,” which is what reviewers want to see. Encrypt every store holding PHI: RDS, EBS, S3, DynamoDB, EFS, and backups.
How long do I need to keep HIPAA audit logs on AWS? Long enough to satisfy your own retention policy and any customer BAA commitment — multi-year retention is common. Deliver CloudTrail, S3 access logs, and VPC Flow Logs to a dedicated, locked-down logging account with versioning and Object Lock or MFA-delete so the accounts being audited can’t erase their own trail.
How do I keep PHI out of my logs? Scrub it at the source. Application logs, error trackers, and debug output routinely leak PHI — a patient email or visit reason in a log stream is both a breach risk and an audit finding. Filter PHI before it’s written, and confine any logs that could contain PHI to eligible services covered by your BAA.
If you’d rather not assemble this from AWS docs under deadline, my HIPAA Readiness Sprint stands up this exact baseline and leaves you with the config and documentation an auditor asks for.