How to Get a BAA with AWS: Steps, Requirements, and Covered HIPAA Services

Understanding the BAA with AWS

A Business Associate Addendum (BAA) is the contract that allows you to use Amazon Web Services to create, receive, maintain, or transmit Protected Health Information (PHI) under HIPAA. It defines each party’s obligations and aligns them with AWS’s shared responsibility model so you can securely operate workloads that handle ePHI.

What the Business Associate Addendum (BAA) covers

The BAA supplements your AWS customer agreement and describes permitted uses and disclosures, breach notification duties, and the administrative, physical, and technical safeguards AWS agrees to maintain. You remain responsible for configuring HIPAA Compliance Controls in your environment, while AWS secures the underlying cloud infrastructure.

Steps to obtain the BAA in AWS Artifact

1. Determine scope: confirm you are a HIPAA covered entity or business associate and that your workloads involve PHI.
2. Design for HIPAA: plan to use only HIPAA-eligible services and document your encryption, access control, logging, and backup approaches.
3. Sign in as an authorized account owner and open AWS Artifact.
4. Navigate to Agreements and select the Business Associate Addendum (BAA).
5. Review the terms, specify the correct legal entity, and accept the BAA. Download and retain the executed copy for your compliance records.
6. For multi-account environments using AWS Organizations, use AWS Artifact to accept the BAA at the management account and apply it across member accounts, then track acceptance centrally.
7. Record the acceptance date and map the BAA to your internal HIPAA Compliance Controls, policies, and procedures.

Requirements before you process PHI

• Use only HIPAA-eligible services and features for systems that store or process PHI.
• Encrypt PHI at rest and in transit, preferably using AWS Key Management Service (KMS) with customer-managed keys.
• Implement strong Identity and Access Management (IAM) controls such as least privilege, role-based access, and MFA.
• Enable audit logging (for example, AWS CloudTrail) and define retention to support investigations and compliance audits.
• Establish backup, recovery, and incident response runbooks and test them on a fixed cadence.

HIPAA-Eligible AWS Services

AWS designates specific offerings as “HIPAA-eligible,” meaning they can be used to process PHI when your account has an executed BAA and you configure them appropriately. Not every service or feature is in scope, and eligibility can vary by Region, so you should verify eligibility in AWS Artifact before building.

Commonly used examples

• Compute: Amazon EC2, AWS Lambda, and container services such as Amazon ECS or Amazon EKS (with secure configurations).
• Storage and databases: Amazon S3, Amazon EBS, Amazon EFS, Amazon RDS, and Amazon DynamoDB with encryption enabled.
• Networking and integration: Amazon VPC (including VPC endpoints/PrivateLink), AWS Direct Connect, Amazon API Gateway.
• Security, identity, and compliance: AWS Key Management Service (KMS), AWS CloudHSM, AWS CloudTrail, AWS Config, AWS WAF, and IAM.
• Messaging and queuing: Amazon SNS and Amazon SQS when access controls and encryption are enforced.

Design your architecture so PHI never flows into non-eligible services or into features that might export data outside your control (for example, public logs, dashboards, or previews). Avoid embedding PHI in resource names, tags, or URLs because these may appear in logs.

Service-selection checklist

• Confirm service and feature eligibility in AWS Artifact for each target Region.
• Limit deployments to only the services you need; disable preview features not covered by the BAA.
• Require encryption by default and validate that all data paths use KMS-protected keys.
• Document data flows to ensure PHI cannot traverse non-eligible components.

Encryption Requirements for PHI

Under HIPAA’s Security Rule, you must protect the confidentiality and integrity of PHI. In AWS, that means robust encryption at rest and in transit, coupled with disciplined key management using AWS Key Management Service (KMS) or AWS CloudHSM where required.

Encryption at rest

• Amazon S3: use SSE-KMS with customer-managed keys; enable bucket policies that require KMS encryption and block public access.
• Amazon EBS and Amazon EFS: enable encryption by default for volumes and file systems that store PHI.
• Amazon RDS and Amazon DynamoDB: enable storage encryption and ensure automated backups and snapshots are encrypted with the same or a dedicated KMS key.
• Logs and analytics: encrypt CloudTrail logs, VPC Flow Logs, and application logs; consider S3 Object Lock for immutable retention.
• Backups: use AWS Backup with KMS-encrypted vaults and restrict key usage to backup and restore principals only.

Encryption in transit

• Mandate TLS 1.2+ for all client and service communications; prefer TLS 1.3 where supported.
• Terminate TLS at Application Load Balancers or API Gateway with strong ciphers; re-encrypt traffic to downstream services.
• Use VPC endpoints/PrivateLink to keep service-to-service traffic on the AWS network and reduce exposure.
• Disable plaintext protocols and redirect HTTP to HTTPS; validate certificates and pin where appropriate.

Key management best practices with AWS KMS

• Use customer-managed KMS keys (CMKs) for PHI; separate keys by environment, data class, and account.
• Define tight key policies; use grants for temporary, auditable access instead of broad IAM permissions.
• Enable automatic rotation for symmetric keys and implement procedural rotation for asymmetric or imported keys.
• Segregate duties so no single admin can create, use, and delete keys without oversight; require MFA for key administrators.
• Log all key usage via CloudTrail and alert on anomalous patterns such as unexpected decrypts or key-disable attempts.

Implementing Access Controls

Access control is central to HIPAA Compliance Controls. You should enforce least privilege across identities, networks, and data layers using Identity and Access Management (IAM), resource policies, and network segmentation.

IAM essentials

• Prefer roles over long-lived users; issue short-lived credentials via AWS STS and federate through IAM Identity Center.
• Apply least privilege with managed and customer policies; use permission boundaries and service control policies for guardrails.
• Require MFA for administrators and sensitive actions, including KMS key management and break-glass roles.
• Adopt ABAC (attribute-based access control) with tags to scope access dynamically by environment, project, or data class.
• Continuously analyze policies with IAM Access Analyzer and remove unused permissions based on access findings.

Network and application-layer controls

• Use security groups as default-deny firewalls; restrict ingress/egress to known ports and identities.
• Keep PHI-processing systems private; expose only necessary endpoints through ALB/API Gateway and protect them with WAF.
• Employ VPC endpoints/PrivateLink for S3, KMS, and other services to avoid public internet paths.

Data access controls

• Use resource policies (for example, S3 bucket policies, DynamoDB condition keys) to bind access to specific roles and contexts.
• Prohibit PHI in logs, tags, and URLs; apply redaction at the edge and in application middleware.
• Encrypt application secrets in AWS KMS, and distribute via Secrets Manager or Parameter Store with tight IAM conditions.

Audit Logging and Monitoring

HIPAA requires you to log and monitor access to PHI. Centralize telemetry, preserve integrity, and alert on suspicious behavior so you can investigate and respond quickly.

Log sources to enable

• AWS CloudTrail for management and data events across all accounts and Regions; enable organization trails and log file validation.
• Amazon VPC Flow Logs, load balancer access logs, and API Gateway execution/access logs for network and API visibility.
• Service-specific logs (for example, RDS, Lambda, S3 data events) to trace data access and administrative actions.
• Application logs that exclude PHI but include correlation IDs for end-to-end tracing.

Monitoring and alerting

• Stream logs to a centralized log account; index and create CloudWatch alarms or EventBridge rules for high-risk events.
• Use GuardDuty for threat detection and Security Hub to aggregate and triage findings from multiple services.
• Continuously assess configuration drift with AWS Config and remediate automatically where safe.

Protecting log integrity and retention

• Store logs in S3 with SSE-KMS using a dedicated, tightly scoped key; enable S3 Object Lock for write-once retention when required.
• Restrict delete and overwrite permissions; separate logging, investigation, and admin roles.
• Retain logs per your policy and BAA obligations; validate integrity using CloudTrail digest files.

Backup and Disaster Recovery Strategies

Backups and disaster recovery ensure availability and integrity of PHI. Define recovery targets, automate backups, isolate copies, and test restores so you can meet business and regulatory expectations.

Plan recovery objectives

• Set RTO/RPO targets for each workload that handles PHI and map them to service-level capabilities.
• Identify critical dependencies (KMS keys, IAM roles, VPCs) and include them in recovery plans.

Service-specific recommendations

• Amazon S3: enable versioning and replication; protect buckets with block public access and minimum encryption policies.
• Amazon RDS: enable Multi-AZ, automated backups, and encrypted snapshots; test cross-Region restore.
• Amazon DynamoDB: enable point-in-time recovery; consider global tables for multi-Region resilience.
• Amazon EBS/EFS: schedule encrypted snapshots and backups; validate restores to clean rooms or staging accounts.
• AWS Backup: use centralized backup plans, cross-account/Region copy, and vault locks to prevent tampering.
• Compute: consider AWS Elastic Disaster Recovery for lift-and-shift server failover with runbooks for rehydration.

Bring it all together by enforcing encryption with KMS, implementing IAM least privilege, enabling CloudTrail and complementary monitoring, and practicing restores on a schedule. With an executed BAA, HIPAA-eligible services, and well-governed controls, you can confidently run PHI workloads on AWS.

FAQs

What is a BAA and why is it necessary with AWS?

A BAA is a contract required by HIPAA when a service provider may handle PHI on your behalf. With AWS, the Business Associate Addendum sets security and privacy obligations and enables you to use eligible services for PHI. You still must configure and operate HIPAA Compliance Controls within your environment.

Which AWS services are covered under the HIPAA BAA?

Only services AWS designates as HIPAA-eligible are covered. Common examples include EC2, Lambda, S3, EBS, EFS, RDS, DynamoDB, API Gateway, KMS, CloudHSM, CloudTrail, Config, and IAM. Always confirm current eligibility and Region coverage in AWS Artifact before building.

How does AWS support encryption for HIPAA compliance?

AWS provides encryption at rest and in transit plus key management. You can use AWS Key Management Service (KMS) or CloudHSM for keys, enforce SSE-KMS on S3, enable encryption on EBS, EFS, RDS, and DynamoDB, and require TLS 1.2+ for data in transit through load balancers, API Gateway, and VPC endpoints.

What are best practices for access control under HIPAA on AWS?

Use IAM roles and least-privilege policies, require MFA for sensitive operations, and apply permission boundaries and service control policies for guardrails. Keep PHI-processing systems private, employ VPC endpoints/PrivateLink, protect public APIs with WAF, and log all access with AWS CloudTrail while ensuring no PHI is written to logs.