AWS Glossary
HIPAA-Eligible AWS Services
AWS services certified to handle Protected Health Information (PHI) under HIPAA regulations.
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
Need help with this topic?
Our AWS-certified team implements, audits, and optimizes these services in production — from Bedrock RAG pipelines to multi-account landing zones.