HIPAA on AWS: Which Services Are BAA-Eligible

Signing the AWS Business Associate Addendum takes ten minutes in AWS Artifact. You check a box, accept the terms, and your account is designated as a HIPAA Account. That part is straightforward. The part that determines whether you are compliant is everything that comes after.

HIPAA compliance on AWS is not a product you purchase or a setting you enable. It is an ongoing configuration discipline across identity, encryption, networking, logging, and incident response - mapped to specific regulatory requirements under 45 CFR Part 164. The BAA is a legal prerequisite. The architecture is where the real effort is.

We have built and reviewed HIPAA-compliant environments on AWS for healthcare SaaS companies, clinical data platforms, and organizations processing insurance claims. This guide covers the regulatory requirements that matter on AWS, which services are in scope, what configurations are mandatory, and where we see teams fail.

What the HIPAA Security Rule Actually Requires

The HIPAA Security Rule (45 CFR Part 164, Subpart C) defines three categories of safeguards for electronic protected health information (ePHI): administrative (Section 164.308), physical (Section 164.310), and technical (Section 164.312). On AWS, physical safeguards are largely handled by AWS under the shared responsibility model - they secure the data centers, hardware, and physical infrastructure. Administrative and technical safeguards are your responsibility.

The technical safeguards under Section 164.312 are the ones that map directly to AWS service configuration. There are five standards, each with specific implementation specifications that are either Required or Addressable. Addressable does not mean optional - it means you must implement the control or document why an equivalent alternative is reasonable and appropriate for your environment.

• Section 164.312(a) - Access Control. Unique user identification (Required). Emergency access procedure (Required). Automatic logoff (Addressable). Encryption and decryption of ePHI (Addressable).
• Section 164.312(b) - Audit Controls. Record and examine activity in systems that contain ePHI. No implementation specifications listed - the standard itself is required.
• Section 164.312(c) - Integrity. Protect ePHI from improper alteration or destruction. Mechanism to authenticate ePHI integrity (Addressable).
• Section 164.312(d) - Person or Entity Authentication. Verify the identity of anyone seeking access to ePHI (Required).
• Section 164.312(e) - Transmission Security. Integrity controls to ensure ePHI is not modified in transit (Addressable). Encryption of ePHI in transit (Addressable).

The AWS BAA: What It Covers and What It Does Not

The AWS Business Associate Addendum is the contract that makes AWS a business associate under HIPAA. You accept it through AWS Artifact, and it applies to the entire AWS account. AWS agrees to implement safeguards for ePHI processed by HIPAA-eligible services, report security incidents, and ensure subcontractors meet the same obligations.

The BAA has two critical constraints that we see teams misunderstand. First, it only covers services on the HIPAA Eligible Services list. If ePHI touches a service not on the list, the BAA does not apply to that data flow, and you are out of compliance. Second, the BAA is conditional on correct configuration. AWS explicitly states that their compliance obligations depend on the customer enabling encryption, audit logging, and using eligible services as documented. If you misconfigure an eligible service, the BAA may not protect you.

The BAA does not make your application HIPAA-compliant. It does not review your code, validate your access controls, perform your risk analysis, train your workforce, or handle your breach notification obligations under Sections 164.404 through 164.410. Those are covered entity responsibilities. The BAA gives you a compliant infrastructure layer. You are responsible for everything above that layer.

HIPAA-Eligible Services: The Complete Picture

AWS currently lists over 170 HIPAA-eligible services. The list is maintained at aws.amazon.com/compliance/hipaa-eligible-services-reference and is updated regularly as AWS adds new services. The most recent update was in April 2026. Always verify the current list before making architecture decisions - do not rely on any third-party reference, including this one.

Here are the service categories that matter most for a typical healthcare workload, grouped by function:

• Compute - EC2, ECS, EKS, Fargate, Lambda, Batch, Elastic Beanstalk. All eligible. Lambda and Fargate simplify compliance because there is no OS-level patching responsibility.
• Storage - S3, EBS, EFS, S3 Glacier, FSx, Storage Gateway. All eligible. S3 requires server-side encryption enabled (SSE-S3, SSE-KMS, or SSE-C) and bucket policies enforcing HTTPS.
• Databases - RDS (all engines), Aurora, DynamoDB, DocumentDB, ElastiCache, MemoryDB, Neptune, Redshift, Keyspaces, QLDB, Timestream. All eligible. RDS and Aurora require encryption at rest enabled at creation time - you cannot enable it retroactively on an existing instance.
• Networking - VPC, Route 53, CloudFront, API Gateway, Elastic Load Balancing (ALB/NLB), Direct Connect, Global Accelerator, AWS Network Firewall. All eligible.
• Security and Identity - KMS, CloudHSM, Secrets Manager, IAM Identity Center, Cognito, Directory Service, WAF, Shield, Macie, GuardDuty, Inspector, Security Hub, Detective. All eligible.
• Logging and Monitoring - CloudTrail, CloudWatch, CloudWatch Logs, AWS Config, X-Ray. All eligible.
• AI and ML - SageMaker, Bedrock, Bedrock AgentCore, Comprehend, Comprehend Medical, Textract, Transcribe, Translate, Rekognition, Lex, Polly, HealthLake, HealthImaging, HealthOmics, Kendra, Personalize. All eligible with correct configuration.
• Messaging - SNS, SQS, EventBridge, Amazon MQ, Managed Streaming for Kafka. All eligible.
• Management - Organizations, Control Tower, CloudFormation, Systems Manager, AWS Backup, Config, Service Catalog, Audit Manager. All eligible.

Section 164.312(a): Access Control on AWS

Access control under HIPAA requires unique user identification and the ability to grant access only to authorized persons and software programs. On AWS, this maps to IAM policies, IAM Identity Center (SSO), and the principle of least privilege applied to every role, user, and service that can reach ePHI.

Unique user identification (Section 164.312(a)(2)(i)) means every person who accesses systems containing ePHI must have their own identity. Shared credentials are a direct violation. On AWS, enforce this with IAM Identity Center for human access - each engineer gets a named identity, federated through your IdP, with permission sets scoped to their role. For service-to-service access, use IAM roles with short-lived credentials, never long-lived access keys.

Person or entity authentication (Section 164.312(d)) requires verifying the identity of anyone seeking access. This means MFA on every human account. IAM Identity Center supports MFA natively. For the root account, use a hardware MFA token and lock the credentials in a safe. Do not use the root account for daily operations. Under the proposed NPRM, MFA will be explicitly mandatory across all ePHI access points.

• Use IAM Identity Center with an external IdP (Okta, Azure AD, Google Workspace) for all human access to AWS accounts containing ePHI.
• Create permission sets that follow least privilege - scope permissions to specific services, resources, and actions. Never use AdministratorAccess for accounts that process ePHI.
• Use IAM Access Analyzer continuously to identify unused permissions and overly broad policies. Tighten them quarterly.
• Enable SCPs at the OU level to prevent IAM users from being created directly - force all human access through Identity Center.
• For automatic logoff (Section 164.312(a)(2)(iii)), configure session duration limits in Identity Center (we use 1 hour for ePHI accounts) and set application-level session timeouts.

Section 164.312(a)(2)(iv) and 164.312(e): Encryption at Rest and in Transit

Encryption of ePHI is technically Addressable under the current rule, but in practice every auditor and OCR investigation treats unencrypted ePHI as a violation. The proposed NPRM would make encryption Required without exception. Treat it as mandatory now.

For encryption at rest, use AWS KMS with customer-managed keys (CMKs). CMKs give you explicit control over key rotation, access policies, and the ability to revoke access. Every KMS key usage is logged in CloudTrail, giving you a complete audit trail of who decrypted what and when. Enable default encryption on S3 buckets (SSE-KMS), RDS instances (must be set at creation), EBS volumes (enable account-level default encryption), DynamoDB tables, and EFS file systems.

For encryption in transit, enforce TLS 1.2 or higher on every connection. On ALB and NLB, set the security policy to ELBSecurityPolicy-TLS13-1-2-2021-06 or newer. For S3, add a bucket policy with a condition that denies any request where aws:SecureTransport is false. For RDS, enable the rds.force_ssl parameter. For ElastiCache, enable in-transit encryption at cluster creation - it cannot be enabled retroactively.

Section 164.312(b): Audit Controls with CloudTrail, Config, and CloudWatch

Section 164.312(b) requires mechanisms that record and examine activity in information systems containing ePHI. On AWS, this means CloudTrail, CloudWatch Logs, AWS Config, and S3 access logging - configured to be immutable, centralized, and retained long enough to satisfy both HIPAA and your organization's policies.

CloudTrail must be enabled as an organization trail covering all accounts and all regions, with management events and data events (S3 object-level and Lambda invocation) logged. Send CloudTrail logs to a centralized S3 bucket in a dedicated log archive account. Enable log file validation so you can cryptographically verify that logs have not been tampered with. Apply an S3 bucket policy that denies deletion. No one, including administrators, should be able to delete audit logs.

AWS Config should run continuously in every account and region with recording enabled for all resource types. Deploy the HIPAA Security conformance pack, which includes managed rules like s3-bucket-server-side-encryption-enabled, rds-storage-encrypted, cloudtrail-enabled, iam-root-access-key-check, and restricted-ssh. Config evaluates resources against these rules continuously and flags noncompliant resources in near real time.

HIPAA does not specify a retention period for audit logs, but Section 164.530(j) requires documentation to be retained for six years. We apply the same six-year minimum to all audit logs. Use S3 Lifecycle policies to transition older logs to S3 Glacier Deep Archive after 90 days, keeping costs manageable while meeting retention requirements.

Network Architecture: Isolating ePHI Workloads

HIPAA does not use the phrase 'network segmentation' in the current rule, but the proposed NPRM explicitly requires it. Regardless of the final rule, network isolation is a fundamental control for limiting the impact scope of a breach and satisfying the access control and transmission security standards.

The architecture pattern we use for HIPAA workloads on AWS starts with a dedicated OU in AWS Organizations for HIPAA accounts, with SCPs that restrict which services can be used. Inside each HIPAA account, a VPC with private subnets holds all ePHI workloads. No public subnets touch patient data. Application and database tiers run in private subnets. Internet-facing load balancers sit in public subnets with WAF attached. VPC endpoints (PrivateLink) handle all AWS service API calls so traffic to S3, DynamoDB, KMS, and other services stays on the AWS private network and never crosses the public internet.

• Use VPC endpoints (gateway endpoints for S3 and DynamoDB, interface endpoints for everything else) to keep ePHI data plane traffic off the public internet.
• Enable VPC Flow Logs on all subnets and send them to the centralized log archive. Flow Logs prove what network traffic actually occurred - essential for incident investigation.
• Use AWS Network Firewall or security groups to restrict traffic between subnets. Database subnets should only accept connections from application subnets on specific ports.
• Block all outbound internet access from ePHI subnets unless explicitly required. Use a NAT gateway with restrictive security groups or an outbound proxy with URL filtering.
• For engineer access to production ePHI environments, use AWS Systems Manager Session Manager instead of SSH. Session Manager logs every command to CloudWatch Logs and S3, providing a complete audit trail without opening inbound ports.

The SCP Boundary: Preventing ePHI from Reaching Non-Eligible Services

This is the control we consider most important for HIPAA on AWS, and it is the one we see missing most often. Service Control Policies at the OU level should allowlist only HIPAA-eligible services and deny everything else. This prevents an engineer from accidentally launching a non-eligible service and sending ePHI to it.

AWS published a reference approach for this: create an SCP with an explicit Allow for all actions on HIPAA-eligible services, attach it to the HIPAA OU, and detach the default FullAWSAccess policy. The result is that any API call to a non-eligible service is denied at the organization level, regardless of the IAM permissions in the account. Salesforce's open-source aws-allowlister tool can automatically generate these SCPs from the current eligible services list.

When we set up HIPAA accounts, the SCP includes eligible services plus supporting services that do not process ePHI but are needed for operations: IAM, CloudFormation, Organizations, and billing services. The SCP must be updated when AWS adds new eligible services that you want to use. We review and update these quarterly.

Where ePHI Leaks: The Failures We See in Reviews

After reviewing HIPAA environments on AWS for healthcare startups and established health tech companies, these are the patterns that cause compliance failures repeatedly:

• Application logs containing patient identifiers. A developer adds a patient ID to a debug log statement. That log goes to CloudWatch Logs, which is eligible - but then a log-forwarding integration sends it to a third-party observability tool that has no BAA. The ePHI has left the compliant boundary.
• Email notifications with ePHI in subject lines or bodies. SES is eligible, but if your application sends appointment reminders with patient names and diagnosis codes in plaintext email, the message content passes through systems outside AWS's BAA scope once it leaves SES.
• Slack or Teams integrations receiving CloudWatch alarms that contain ePHI. AWS Chatbot and third-party webhook integrations are outside the BAA boundary. If an alarm message includes a patient ID or record count from a failed database query, that is an ePHI disclosure.
• S3 buckets created without encryption. If a developer creates a new bucket in a HIPAA account and does not enable default encryption, any ePHI written to it is unencrypted at rest. Use AWS Config rules (s3-bucket-server-side-encryption-enabled) and SCPs to prevent this.
• RDS instances launched without encryption. Unlike S3, you cannot enable encryption on an existing unencrypted RDS instance. You must create an encrypted snapshot, restore from it, and redirect traffic. We have seen teams discover this months into production with gigabytes of unencrypted ePHI.
• AI/ML services with default configurations. Bedrock and SageMaker are eligible, but specific endpoint configurations and data handling options determine whether ePHI stays within the BAA boundary. Sending ePHI through a model endpoint that is not configured for HIPAA use puts you out of compliance.
• Cross-account data sharing without BAA coverage. If your HIPAA account shares data with a non-HIPAA account (via S3 cross-account access, KMS key sharing, or database replication), the ePHI has left the BAA boundary.

Administrative Safeguards You Must Address

Section 164.308 defines administrative safeguards that are your responsibility regardless of what AWS provides. The most important is the risk analysis requirement under Section 164.308(a)(1)(ii)(A): you must conduct an accurate and thorough assessment of potential risks and vulnerabilities to ePHI. This is Required, not Addressable. OCR has cited failure to conduct a risk analysis in most of its enforcement actions - it is the single most common HIPAA violation.

Other administrative requirements directly affect your AWS environment. These include workforce training on ePHI handling (Section 164.308(a)(5)), an incident response plan with breach determination within 60 days (Sections 164.308(a)(6) and 164.404), a contingency plan covering data backup, disaster recovery, and emergency mode operations (Section 164.308(a)(7)), and periodic technical and nontechnical evaluations triggered by environmental or operational changes (Section 164.308(a)(8)).

Breach notification under Section 164.404 requires notifying affected individuals without unreasonable delay and no later than 60 days after discovery. Breaches affecting 500 or more individuals must also be reported to HHS and the media simultaneously. Breaches affecting fewer than 500 individuals must be reported to HHS annually. Documentation of your breach analysis must be retained for six years.

Threat Detection and Incident Response

HIPAA requires you to identify and respond to suspected or known security incidents (Section 164.308(a)(6)). On AWS, this means GuardDuty, Security Hub, and a documented response runbook are baseline requirements, not optional.

Enable Amazon GuardDuty in every region across all HIPAA accounts. GuardDuty analyzes CloudTrail management and data events, VPC Flow Logs, and DNS logs for indicators of compromise: unauthorized API calls, credential exfiltration, cryptocurrency mining, and unusual data access patterns. Feed GuardDuty findings into Security Hub, which aggregates findings from GuardDuty, Inspector, Macie, and Config into a unified dashboard. Enable the AWS Foundational Security Best Practices standard and the CIS AWS Foundations Benchmark in Security Hub for continuous compliance scoring.

Use Amazon Macie to scan S3 buckets for unencrypted ePHI, publicly accessible buckets, and sensitive data patterns (SSNs, medical record numbers, health plan IDs). Macie uses machine learning classifiers trained on healthcare data patterns. Run Macie discovery jobs on a recurring schedule against every S3 bucket in HIPAA accounts.

For incident response, create EventBridge rules that route critical GuardDuty findings (severity High and Critical) to an SNS topic that pages your on-call team. Do not put ePHI in the notification payload - include only the finding ID, severity, and a link to the Security Hub console. The investigation happens inside the AWS console, not in a Slack channel.

Backup, Disaster Recovery, and the Contingency Plan

Section 164.308(a)(7) requires a contingency plan that covers data backup, disaster recovery, and emergency mode operation. On AWS, use AWS Backup to define backup policies across RDS, DynamoDB, EBS, EFS, and S3 in a single backup plan. Set backup frequency and retention periods based on your RPO. Enable cross-region copy rules so backups survive a regional outage.

For RDS and Aurora, enable automated snapshots and verify point-in-time recovery works by actually restoring a snapshot at least quarterly. For DynamoDB, enable point-in-time recovery (PITR) and on-demand backups. For S3, enable versioning and consider Object Lock for compliance retention on critical ePHI datasets - Object Lock prevents anyone, including root, from deleting or modifying objects during the retention period.

Test your disaster recovery plan. Section 164.308(a)(7)(ii)(D) requires testing and revision procedures. We test quarterly: restore from backup, verify data integrity, measure actual recovery time against your stated RTO, and document the results. The documentation is your evidence that the contingency plan works. Without test documentation, your contingency plan is only a written policy, not a proven capability.

Real-World Enforcement Context

HIPAA enforcement is not theoretical. In 2024, OCR settled 22 enforcement actions totaling $9.9 million in penalties. The Change Healthcare breach in February 2024 exposed data on 192.7 million individuals. It has cost UnitedHealth Group over $2.4 billion so far. The root cause was a compromised credential without MFA on a remote access system - a direct violation of the person or entity authentication standard.

HIPAA penalty tiers range from $141 per violation (Tier 1, no knowledge) up to $2,134,831 per violation (Tier 4, willful neglect not corrected). The maximum annual penalty per violation category is $2,134,831. OCR's most frequent finding across all enforcement actions is failure to conduct a thorough risk analysis under Section 164.308(a)(1). The second most frequent is failure to implement access controls. Both are entirely preventable with proper AWS configuration and organizational process.

Building a HIPAA Account from Scratch

If you are starting a new healthcare workload on AWS, this is the sequence we follow. It takes two to three weeks for a production-ready HIPAA account, depending on the application complexity.

1. Accept the BAA in AWS Artifact for the account. If you use AWS Organizations, accept it at the organization level to cover all member accounts.
2. Create a dedicated HIPAA OU in AWS Organizations. Move the account into it. Attach an SCP that allowlists only HIPAA-eligible services and supporting services.
3. Enable CloudTrail as an organization trail with log file validation. Send logs to a locked S3 bucket in a separate log archive account.
4. Enable AWS Config in all regions with the HIPAA Security conformance pack. Set up auto-remediation for critical rules (unencrypted S3 buckets, public access, missing encryption).
5. Enable GuardDuty, Security Hub, and Macie across all HIPAA accounts. Configure EventBridge rules for high-severity findings.
6. Set up IAM Identity Center with your IdP. Create permission sets with least-privilege policies. Enforce MFA on all identities.
7. Build the VPC: private subnets for application and data tiers, VPC endpoints for AWS services, Network Firewall or restrictive security groups, VPC Flow Logs enabled.
8. Enable account-level defaults: EBS encryption, S3 Block Public Access, and IMDSv2 requirement on all EC2 instances.
9. Deploy the application with encryption at rest (KMS CMKs) and in transit (TLS 1.2+) on all components. Verify with Config rules.
10. Conduct the risk analysis. Document all ePHI flows, identify threats and vulnerabilities, and implement mitigation measures. This is Required under Section 164.308(a)(1).

Compliance Is Configuration, Not Documentation

The pattern we see fail: a team writes HIPAA policies, stores them in a shared drive, and assumes the cloud environment matches what the policies describe. The environment never does. Policies drift from infrastructure within weeks.

The pattern that works: infrastructure defined in Terraform, with Config rules and SCPs that enforce compliance guardrails continuously. Every policy statement maps to a specific AWS configuration that is deployed, monitored, and triggers alerts on violations. When the auditor or OCR investigator asks how you protect ePHI in transit, the answer is not a PDF. It is a Config rule evaluation showing 100% compliant resources, a Terraform module that enforces TLS 1.2+ on every load balancer, and a CloudTrail log showing no exceptions.

As an AWS Advanced Tier Partner, we build HIPAA-compliant environments on AWS as a core part of our compliance process accompaniment. We handle the account architecture, SCP boundaries, encryption configuration, logging pipeline, and Config rules. We also guide you through the risk analysis, policy documentation, and breach response planning that HIPAA requires beyond infrastructure. If you are building on AWS and handling ePHI, we can review your current environment or set up a compliant account from scratch.