HIPAA-Eligible AWS Services

Definition

HIPAA-eligible AWS services are services AWS designates as capable of processing, storing, or transmitting Protected Health Information (PHI) when configured correctly and covered under a signed Business Associate Agreement (BAA) with AWS. Eligibility is not compliance: you must still implement encryption, access controls, audit logging, backup, and operational procedures required by HIPAA Security and Privacy Rules. AWS publishes an authoritative eligible-services list; using a non-eligible service for PHI violates your compliance boundary even if the underlying technology seems similar to an eligible one.

When to use it

• Building or migrating healthcare applications (EHR integrations, patient portals, clinical workflows) on AWS under a signed BAA
• Selecting services for workloads that store or process PHI — start from the eligible services reference, not general AWS marketing pages
• Architect reviews where auditors ask “which AWS services touch PHI?” — map each data flow to an eligible service with documented controls
• Combining eligible compute (EC2, Lambda, Fargate), data (RDS, Aurora, DynamoDB, HealthLake), and security (KMS, CloudTrail, Config) into a bounded account structure

When not to use it

• Assuming eligibility equals HIPAA compliance without customer-side controls — AWS covers the cloud layer; you own application and administrative safeguards
• Using non-eligible services (many edge, legacy, or preview services) for PHI because “it’s encrypted anyway”
• Skipping the BAA — contractual coverage is a prerequisite, not optional paperwork
• Treating the eligible list as static — review AWS updates before adopting new services in PHI paths

Tips

• Maintain an internal allowed-services register synced to AWS’s published list; block non-eligible services via SCPs in PHI accounts
• Encrypt PHI at rest with KMS CMKs and in transit with TLS 1.2+; default encryption alone is not a complete safeguard story
• Centralize CloudTrail and access logging for every PHI account; auditors expect demonstrable access review evidence
• Use HealthLake when FHIR R4 clinical data at scale is the domain model — it is purpose-built for healthcare interoperability
• Segment PHI workloads into dedicated accounts with least-privilege IAM and no shared “general purpose” Lambda roles

Gotchas

Serious

• Eligible ≠ compliant: Teams pass architecture review on paper but fail audit because application logging prints PHI to non-eligible destinations.
• Shadow integrations: SaaS webhooks, analytics SDKs, and third-party support tools outside the BAA boundary invalidate the design.
• Stale service choices: A service removed from eligibility or never listed (common with previews) creates retroactive compliance exposure.

Regular

• Confusing HIPAA eligibility with HITECH or state privacy laws — additional state rules may constrain data residency and breach notification.
• Over-broad IAM roles on Lambda functions that process PHI — one overly permissive role spans the entire compliance boundary.
• Backup and disaster recovery copies of PHI must meet the same controls as primary stores — snapshot sharing across accounts needs explicit policy.

Official references

• HIPAA eligible services reference — authoritative AWS list of eligible services
• Architecting for HIPAA on AWS — security and compliance whitepaper

Related FactualMinds content

• HIPAA on AWS: Complete Compliance Checklist
• AWS Cloud Security for Healthcare