HIPAA on AWS: what Amazon covers and what's still on you

The short answer

AWS is a perfectly good — arguably the easiest — place to run a HIPAA workload. Amazon will sign a Business Associate Addendum (BAA) with you for free, and it designates a long list of services as HIPAA-eligible, meaning you're contractually permitted to process protected health information (PHI) in them.

But here's the part that trips up every team the first time: under the shared responsibility model, AWS handles security of the cloud — physical data centers, hardware, the hypervisor — while you handle security in the cloud. For HIPAA specifically, that means the overwhelming majority of the Security Rule's safeguards are still yours: encryption configuration, IAM, audit logging, access reviews, application security, workforce training, the risk analysis, policies, and breach response. The BAA gets you a contract; it does not get you compliance.

So the honest framing is: AWS solves your physical safeguards and gives you the building blocks for the technical ones. Everything else is your program. If you want to know what "everything else" includes, our free HIPAA checklist for SaaS walks through the full safeguard list — including the AWS-relevant items in this guide.

AWS BAA

Self-service in AWS Artifact, free, takes minutes. Required before any PHI enters the account.

HIPAA-eligible services

100+ services including EC2, S3, RDS, Lambda, DynamoDB, CloudFront. PHI may only touch eligible services.

What AWS covers

Physical safeguards, hardware, hypervisor, the underlying network — security OF the cloud.

What you cover

Encryption config, IAM, logging, app security, policies, training, risk analysis, breach response — security IN the cloud, plus the entire administrative side of HIPAA.

Step one: accept the AWS BAA in Artifact

HIPAA requires a business associate agreement with any vendor that handles PHI on your behalf (§164.308(b), §164.502(e)) — and AWS, hosting your PHI, is exactly that. AWS handles this through AWS Artifact, its self-service compliance portal:

1. In the AWS console, open Artifact → Agreements.
2. Find the Business Associate Addendum (BAA) and accept it. It's a click-through — no negotiation, no sales call, no fee.
3. If you use AWS Organizations, accept the organization-level BAA from the management account so it covers your member accounts.
4. Download and archive the acceptance confirmation. Customers and auditors will ask for proof, and "it's in Artifact" is a fine answer only if you can produce it.

Do this before the first byte of PHI lands in the account. PHI processed before the BAA is in place is a HIPAA violation regardless of how secure the infrastructure was. If you're fuzzy on what a BAA actually obligates each party to do, read our BAA guide — the AWS BAA follows the same structure as the ones you'll sign with customers.

What "HIPAA-eligible" actually means

The AWS BAA doesn't bless your whole account — it covers only services AWS has designated as HIPAA-eligible. The rule is simple and absolute: PHI may only be created, stored, processed, or transmitted in HIPAA-eligible services. Using a non-eligible service for PHI puts that data outside your BAA, which is a compliance failure even if nothing leaks.

The eligible list is long (100+ services) and covers what most SaaS stacks need. Commonly used eligible services include:

• Compute: EC2, Lambda, ECS, EKS, Fargate
• Storage: S3, EBS, EFS, Glacier
• Databases: RDS (all major engines), Aurora, DynamoDB, ElastiCache, Redshift
• Networking and delivery: VPC, ELB/ALB, CloudFront, API Gateway, Route 53
• Security and ops: KMS, CloudTrail, CloudWatch, GuardDuty, Secrets Manager

Two operational warnings. First, the list changes — AWS adds services regularly, and new or preview services are often not yet eligible. Always check the official AWS HIPAA Eligible Services Reference before adopting any service in a PHI path; bookmark it and make it part of your architecture review. Second, eligibility is about where PHI goes, not which services you may use at all. You can use a non-eligible service freely for anything that doesn't involve PHI — the discipline is making sure PHI can't reach it, which is an architecture problem, not a paperwork one.

Shared responsibility, HIPAA edition

The shared responsibility model maps onto the HIPAA Security Rule like this:

Notice the pattern in the middle rows: AWS provides the mechanism, you own the configuration. Every AWS-related HIPAA breach you've read about — exposed S3 buckets, over-permissive IAM, unencrypted snapshots shared publicly — happened in the customer's half of the table. AWS's half basically never fails; yours fails constantly without discipline.

Reference architecture: the checklist that passes audits

Here's the configuration baseline that satisfies the Security Rule's technical safeguards (§164.312) and survives customer security reviews. Treat it as a literal checklist:

• KMS encryption at rest, everywhere PHI lives. S3 default encryption (SSE-KMS), RDS/Aurora storage encryption enabled at creation (it can't be enabled later without a snapshot-restore dance), EBS encryption by default at the account level, DynamoDB encryption with customer-managed keys where buyers demand key control.
• TLS for everything in transit. TLS 1.2+ on all public endpoints, bucket policies that deny non-HTTPS access (aws:SecureTransport), TLS on internal hops too — auditors increasingly ask about service-to-service encryption, not just the edge.
• VPC isolation for PHI workloads. Databases and PHI-processing compute in private subnets with no public IPs; security groups scoped to specific sources, not 0.0.0.0/0; VPC endpoints for S3/DynamoDB so PHI traffic stays off the public internet.
• CloudTrail on, multi-region, with 6-year retention. HIPAA's documentation retention requirement is six years (§164.316(b)(2)(i)); apply it to audit logs via S3 lifecycle rules to Glacier. Enable log file integrity validation.
• GuardDuty enabled in every region you operate, with findings routed somewhere a human sees them. It's the cheapest credible answer to "how do you detect malicious activity?" (§164.308(a)(6)).
• S3 Block Public Access at the account level. Not per-bucket — account level, so a future bucket can't be born public. Pair with access logging on PHI buckets.
• RDS hardening: encryption at rest, automated backups (test the restore — §164.308(a)(7) requires a tested contingency plan, and an untested backup is a hope, not a plan), no public accessibility flag, IAM or Secrets Manager-based credentials rotated on schedule.
• No PHI in CloudWatch logs or error messages. Scrub identifiers at the application layer, log opaque internal IDs, and make sure stack traces and 500-page responses never echo request bodies containing PHI. This is the one item on this list that's pure application discipline — no AWS checkbox enforces it for you.

For the deeper application-layer requirements behind several of these items — unique user identification, automatic logoff, integrity controls — see our HIPAA technical safeguards guide.

Common mistakes

PHI in logs

The most common leak in otherwise-solid architectures. A developer logs a request body for debugging, an exception handler dumps a payload, an access log captures a URL with a patient identifier in the query string — and now PHI is in CloudWatch, shipped to a third-party log tool without a BAA, and sitting in a Slack debugging thread. Treat logs as a PHI-free zone by policy, scrub at the framework level, and grep your log output for identifiers as part of code review.

PHI in non-eligible services

A new AWS service launches, a team adopts it, nobody checks the eligibility list. Now PHI flows through a service your BAA doesn't cover. Make the eligibility check a standing item in design review, and keep the data architecture narrow enough that "where can PHI physically go?" has a short, known answer.

Public S3 buckets

Still, after all these years, the canonical cloud health-data breach. Account-level Block Public Access eliminates the entire category. If you ever genuinely need public objects (marketing assets, say), serve them from a separate account or via CloudFront — never from an account holding PHI with public access "carefully" enabled.

Assuming the BAA equals compliance

The big one. Teams sign the Artifact BAA, use eligible services, and tell customers they're "HIPAA compliant on AWS." Then a security review asks for their risk analysis (§164.308(a)(1)(ii)(A)), training records, breach notification procedures, and access review evidence — and there's nothing. The BAA covers exactly one of the dozens of things a compliance program needs. The administrative safeguards — the unglamorous policy-and-process half of HIPAA — don't live in AWS at all. Start with the HIPAA compliance guide for the full program, and the HIPAA glossary entry for how the rules fit together.

One account for everything

Production PHI, staging, dev experiments, and the marketing site in a single AWS account means one over-broad IAM grant or one experiment gone wrong exposes everything. Separate accounts (under AWS Organizations, with the org-level BAA) put a hard blast-radius boundary around PHI for essentially zero extra cost.

Related reading

• HIPAA checklist for SaaS — free interactive assessment covering the full safeguard list, AWS items included
• HIPAA technical safeguards — §164.312 in depth: access control, audit, integrity, transmission security
• HIPAA compliance: the practical guide — the complete program around the infrastructure
• Business Associate Agreements explained — what the AWS BAA (and yours with customers) actually obligates
• HIPAA compliance cost — what the whole program costs, including the cloud line items
• HIPAA explained — glossary entry

Common questions

Does the AWS BAA make me HIPAA compliant?

No. The BAA covers AWS's obligations as your business associate — it says nothing about yours. You still own the risk analysis, policies, training, breach notification procedures, encryption configuration, IAM, logging, and application security. The BAA is the first checkbox in a long list, not the list.

Is S3 HIPAA compliant?

S3 is HIPAA-eligible, which means you may store PHI in it under your AWS BAA — if you configure it correctly. That means default encryption enabled, Block Public Access on at the account level, bucket policies enforcing TLS, access logging or CloudTrail data events enabled, and tightly scoped IAM. A misconfigured public S3 bucket holding PHI is a reportable breach, BAA or not.

Can I use CloudFront with PHI?

Yes — CloudFront is on AWS's HIPAA-eligible list. Use TLS end to end (viewer and origin), use signed URLs or signed cookies for any PHI content, and think hard before caching PHI at edge locations at all; many teams configure CloudFront to pass PHI responses through without caching. Also keep PHI out of CloudFront access logs (e.g., never put identifiers in URLs or query strings).

Is AWS Lambda HIPAA eligible?

Yes, Lambda is HIPAA-eligible and widely used for PHI processing. The usual pitfalls are operational: PHI leaking into CloudWatch Logs via debug statements or unhandled exception traces, and PHI passed through environment variables. Sanitize logging, encrypt environment variables with KMS, and scope each function's execution role tightly.

Do I need a dedicated VPC or dedicated instances for HIPAA?

No. AWS once required Dedicated Instances for PHI on EC2, but that requirement was dropped years ago — standard multi-tenant infrastructure is fine under the current BAA. You should still use a VPC with private subnets and security groups to isolate PHI workloads, but that's good architecture, not a dedicated-hardware requirement.

How do I sign the AWS BAA?

Through AWS Artifact, in the AWS console: Artifact → Agreements → accept the Business Associate Addendum. It's self-service, takes minutes, and is free. For AWS Organizations, accept it at the management account level to cover member accounts. Do this before any PHI touches the account, and keep the acceptance record — auditors and customers ask for it.

What happens if I put PHI in a non-eligible AWS service?

The BAA only covers HIPAA-eligible services, so PHI in a non-eligible service sits outside your business associate agreement with AWS — a compliance violation even if nothing is ever breached, and a likely reportable breach if the data is exposed. Check the current eligible-services list before adopting any new AWS service in a PHI path, and architect so PHI physically can't reach non-eligible services.

Can PHI go in CloudWatch Logs?

CloudWatch is HIPAA-eligible, so it's contractually permitted — but deliberately logging PHI is bad practice and most teams treat logs as a PHI-free zone. Logs sprawl: they get shipped to third-party tools, shared in debugging sessions, and retained in places nobody audits. Scrub identifiers at the application layer, log opaque record IDs instead of names or details, and audit log output as part of code review.

Does AWS config get checked in a HIPAA audit?

Yes — there's no routine OCR audit, but customer security reviews, SOC 2 auditors examining HIPAA mappings, and OCR breach investigations all probe your cloud configuration: encryption settings, IAM policies, logging coverage, public exposure. Your risk analysis under §164.308(a)(1)(ii)(A) must cover your AWS environment, and tools like AWS Config rules and Security Hub make the evidence collection continuous instead of a scramble.

How long do I need to keep CloudTrail logs for HIPAA?

HIPAA requires documentation to be retained for six years from creation or last effective date (§164.316(b)(2)(i)). Audit logs that serve as compliance documentation are commonly held to that standard, so the safe pattern is CloudTrail delivering to an S3 bucket with lifecycle rules transitioning to Glacier and a 6-year retention policy. Storage is cheap; recreating missing audit history is impossible.

Last updated: June 11, 2026 · Reviewed by the LukaGRC compliance team