Is AWS HIPAA Compliant? A Beginner’s Guide

You can build HIPAA-ready workloads on Amazon Web Services, but AWS itself is not “HIPAA certified.” Compliance depends on how you design, deploy, and operate your environment, and whether you have a Business Associate Addendum (BAA) in place before handling Protected Health Information (PHI). This guide explains the essentials so you can move from uncertainty to a clear action plan.

Overview of HIPAA Compliance

HIPAA sets rules for protecting PHI across privacy, security, and breach notification. In the cloud, compliance is a continuous program: you must implement safeguards, document decisions, monitor controls, and respond to events. Technology enables those safeguards, but your policies and procedures make them effective.

AWS provides building blocks that support HIPAA requirements—such as Encryption at Rest, Encryption in Transit, logging, and fine-grained identity controls. Using those features correctly, paired with sound governance and Access Control Policies, is what turns infrastructure into a compliant solution.

Business Associate Addendum (BAA) Importance

The Business Associate Addendum (BAA) is mandatory when AWS can process, store, or transmit PHI on your behalf. The BAA defines responsibilities for protecting PHI, sets breach-notification expectations, and restricts use and disclosure. Without a signed BAA, you must not place PHI in AWS.

• The BAA covers only HIPAA-Eligible AWS Services. Use of non-eligible services with PHI is out of scope.
• The BAA does not make an application or workload compliant by itself; your configuration and operations still determine outcomes.
• Subcontractors and downstream service providers that touch PHI also need appropriate agreements and controls.

Sign the BAA before onboarding PHI, inventory who will access the data, and update your training, incident response, and change management to reflect cloud responsibilities.

HIPAA-Eligible AWS Services

AWS maintains a list of HIPAA-Eligible AWS Services that fall within the BAA’s scope. You should verify a service’s eligibility and regional availability before using it with PHI and enable only the features you need within that scope.

Common examples used in HIPAA architectures include:

• Storage and compute: Amazon S3 for object storage, Amazon EC2 with encrypted Amazon EBS volumes for compute and block storage.
• Databases: Amazon RDS and Amazon DynamoDB with encryption features enabled for PHI data stores.
• Security and keys: AWS Key Management Service (KMS) and, when needed, AWS CloudHSM for dedicated hardware key storage.
• Logging and observability: AWS CloudTrail and Amazon CloudWatch as the foundation for Security Event Monitoring and auditing.

Only process PHI in eligible services, and keep non-eligible services outside the PHI boundary. Re-confirm eligibility whenever you adopt new features or regions.

Customer Responsibility for Configuration

Under the shared responsibility model, AWS secures the infrastructure of the cloud; you secure what you build in the cloud. Your tasks include configuration, data governance, user access, and continuous oversight.

Practical checklist to design your PHI boundary

• Define data flows: identify where PHI enters, flows, is stored, and leaves; minimize PHI wherever possible.
• Establish Access Control Policies: apply least privilege, separation of duties, and approval workflows for sensitive actions.
• Segment networks: use VPCs, private subnets, security groups, and endpoint policies to isolate PHI workloads.
• Harden baselines: standardize AMIs, container images, and managed service configurations; patch systems on a schedule.
• Turn on logging by default: enable CloudTrail, VPC Flow Logs, and service logs in a centralized, immutable log archive.
• Backups and recovery: encrypt backups, test restores, and document Recovery Time and Recovery Point Objectives.
• Change control and IaC: manage environments through Infrastructure as Code and peer-reviewed pull requests.
• Risk analysis and documentation: record threats, compensating controls, and residual risk to support audits.

Data Encryption and Access Controls

Encryption at Rest and Encryption in Transit are core to protecting PHI. Enable encryption everywhere and verify it continuously.

Encryption at Rest

• Use KMS-managed keys for S3, EBS, RDS, and DynamoDB; prefer customer-managed keys when you need custom key policies and rotation.
• Restrict key usage with KMS key policies, grants, and conditions; separate “key admins” from “data users.”
• Apply bucket, volume, and database defaults to ensure new assets are encrypted automatically.

Encryption in Transit

• Require TLS 1.2+ for all client and service connections; enforce HTTPS-only access to S3 and APIs.
• Use modern cipher suites and certificate automation; terminate TLS at load balancers or services configured for strong transport security.

Access controls that hold up under audit

• Principle of least privilege via IAM roles and policies; prefer short-lived, role-based credentials over long-lived keys.
• MFA for all privileged accounts, especially the root user, break-glass roles, and administrators.
• Resource policies (for S3, KMS, and VPC endpoints) that restrict access by principal, network path, and encryption requirements.
• Service-level features such as RDS IAM authentication and S3 object ownership controls to align access with your policies.

Monitoring and Security Best Practices

Security Event Monitoring transforms logs into action. Centralize and correlate events so you can detect, investigate, and respond quickly.

• Collect and retain logs: enable CloudTrail (organization-wide), CloudWatch logs and metrics, and VPC Flow Logs; protect archives from alteration.
• Detect threats: use services like GuardDuty for anomaly detection and Security Hub to aggregate findings against baseline controls.
• Enforce configuration: define AWS Config rules for encryption, logging, and access; remediate drift automatically.
• Harden the edge: apply AWS WAF for HTTP-layer protections and rate limits; consider DDoS protections for internet-facing endpoints.
• Manage vulnerabilities: inventory assets, scan regularly, and patch operating systems, containers, and runtimes on a known cadence.
• Prepare for incidents: write runbooks, rehearse containment (for example, isolate an instance, revoke access, rotate KMS keys), and document lessons learned.
• Data lifecycle: define retention and deletion policies for PHI, verify anonymization/pseudonymization where applicable, and track data egress.

Resources for Architecting HIPAA Solutions

Leverage prescriptive frameworks and automation to keep your controls consistent over time. Align your design to the AWS Well-Architected Framework and map safeguards to HIPAA’s administrative, physical, and technical standards.

• BAA and evidence: obtain and manage your BAA, and centralize audit artifacts and control mappings for ready access.
• Guardrails at scale: use AWS Organizations with service control policies, delegated admin for security services, and account vending to separate environments.
• Infrastructure as Code: encode encryption defaults, logging, and network rules in CloudFormation or Terraform; gate changes through CI/CD.
• Reference architectures: start from healthcare blueprints that show PHI boundaries, private connectivity, and zero-trust access patterns.
• Operational playbooks: document backup/restore, key rotation, break-glass access, and incident response steps that fit your environment.

When you combine eligible services, a signed BAA, strong encryption, least-privilege access, and continuous monitoring, you create a resilient foundation for HIPAA-compliant operations on AWS.

FAQs.

What is the role of a Business Associate Addendum in AWS HIPAA compliance?

The Business Associate Addendum (BAA) is the contractual prerequisite for placing PHI in AWS. It defines how AWS, as a business associate, will protect PHI, sets breach-notification terms, and limits use and disclosure. The BAA applies only to HIPAA-Eligible AWS Services and does not itself make your workloads compliant—you still must configure and operate controls correctly.

Which AWS services are eligible for handling PHI?

AWS publishes a list of HIPAA-Eligible AWS Services covered by the BAA. Common examples include Amazon S3, Amazon EC2 with encrypted EBS, Amazon RDS, Amazon DynamoDB, AWS KMS, AWS CloudTrail, and Amazon CloudWatch. Always verify eligibility and regional availability for any service or feature you plan to use with PHI.

How can customers ensure their AWS configurations meet HIPAA standards?

Start by signing the BAA and defining your PHI boundary. Enforce Encryption at Rest and Encryption in Transit, implement least-privilege Access Control Policies with MFA, centralize Security Event Monitoring, and use configuration rules to prevent drift. Document your risk analysis, test backups and incident response, and manage all changes through Infrastructure as Code to keep controls consistent and auditable.