AWS HIPAA Compliance: Shared Responsibility, HIPAA-Eligible Services, BAA Execution, and Multi-Cloud Architecture

AWS HIPAA compliance refers to the legal, architectural, and operational framework through which Covered Entities, Business Associates, and clinical research institutions store, process, and transmit electronic Protected Health Information (ePHI) on Amazon Web Services (AWS) in accordance with the Health Insurance Portability and Accountability Act (HIPAA) Administrative Simplification Rules (45 CFR Parts 160, 162, and 164). Under guidance issued by the U.S. Department of Health and Human Services (HHS) Office for Civil Rights (OCR), any Cloud Service Provider (CSP) that maintains ePHI on behalf of a Covered Entity or another Business Associate is legally a HIPAA Business Associate—even if the cloud provider stores only encrypted ciphertext and does not possess the decryption keys (a “no-view” cloud service).

Consequently, achieving HIPAA-compliant cloud hosting on AWS, Microsoft Azure, Google Cloud Platform (GCP), or data platforms such as Databricks and Supabase requires three non-negotiable pillars: (1) executing a written Business Associate Agreement / Addendum (BAA) before any ePHI touches the environment, (2) restricting ePHI data flows exclusively to designated HIPAA-Eligible Services, and (3) configuring customer-side technical safeguards under the cloud Shared Responsibility Model.

Does Signing a Cloud BAA Automatically Make an Application HIPAA Compliant?

No. Executing an AWS Business Associate Addendum (AWS BAA)—or a Microsoft Azure, Google Cloud, or Google Workspace HIPAA BAA—satisfies only the contractual requirement under 45 CFR § 164.308(b)(1) and § 164.504(e) that a Covered Entity or upstream Business Associate obtain satisfactory written assurances from its cloud vendor. Signing a BAA does not make a cloud account or application automatically HIPAA compliant.

As detailed in our HIPAA-aware vs. HIPAA-compliant comparison and the HIPAA compliance checklist for research and clinical teams, there is no federal “HIPAA certification” for cloud providers. A cloud environment with a signed BAA immediately violates the HIPAA Security Rule if an engineer leaves an Amazon S3 bucket publicly readable, transmits unencrypted ePHI over plain HTTP, logs patient identifiers into a non-eligible service, or fails to enable audit logging under 45 CFR § 164.312(b).

How Does the Shared Responsibility Model Work for AWS, Azure, and GCP HIPAA Compliance?

Hyperscale cloud providers partition HIPAA Security Rule compliance duties between the Cloud Service Provider (CSP) and the healthcare customer through the Shared Responsibility Model:

• Cloud Provider Responsibility (“Security of the Cloud”): AWS, Microsoft Azure, and Google Cloud are responsible for protecting the physical data centers, biometric facility access controls, hardware lifecycle and media sanitization (aligned with NIST SP 800-88 Rev. 1), hypervisor isolation, and underlying physical network infrastructure, verified through third-party HITRUST CSF, SOC 2 Type 2, and FedRAMP audits.
• Customer Responsibility (“Security in the Cloud”): The healthcare organization or research institution is solely responsible for selecting only BAA-covered HIPAA-eligible services, configuring Identity and Access Management (IAM) least-privilege roles and multi-factor authentication (MFA), enabling encryption at rest and in transit, managing cryptographic keys, isolating virtual networks (VPCs/VNets), capturing immutable audit logs, and conducting regular security risk analyses under 45 CFR § 164.308(a)(1)(ii)(A).

Cloud / Data Platform	How the HIPAA BAA Is Executed	In-Scope Service Boundary	Native Compliance Guardrail Tooling
Amazon Web Services (AWS)	Self-service electronic execution via AWS Artifact (for a single account or across all member accounts in an AWS Organization)	Services listed on the official AWS HIPAA Eligible Services Reference (160+ services)	AWS Config Conformance Packs for HIPAA Security Rule, AWS Security Hub, AWS Control Tower
Microsoft Azure & Microsoft 365	Included automatically by default under the Microsoft Online Services Data Protection Addendum (DPA) for customers with enterprise/licensing agreements	In-scope Azure Core Services, Azure OpenAI Service, and Microsoft 365 / Dynamics 365 Healthcare services	Microsoft Defender for Cloud Regulatory Compliance (HIPAA/HITRUST built-in initiative), Microsoft Purview
Google Cloud (GCP) & Google Workspace	Electronic acceptance by Organization/Domain Administrators in the Google Cloud Console or Google Admin Console	GCP HIPAA Covered Products (Compute Engine, Cloud Storage, BigQuery, Cloud Healthcare API, Vertex AI) & core Workspace apps	GCP Assured Workloads (HIPAA regime folder constraints), Security Command Center
Databricks & Supabase	Requires Enterprise/Team tier contract addendum (Databricks HIPAA Compliance Security Profile; Supabase HIPAA Add-On)	Databricks Lakehouse workspaces with Enhanced Security & Compliance enabled; Supabase dedicated database projects excluding non-covered alpha features	Databricks Compliance Security Profile (CSP) automated cluster hardening; Supabase SOC 2 / HIPAA project controls

What Are AWS HIPAA-Eligible Services?

Under the terms of the AWS BAA, customers may use any AWS service in an account designated as a HIPAA account, but may only process, store, and transmit ePHI using services listed on the AWS HIPAA Eligible Services Reference. Key AWS HIPAA-eligible services used in clinical informatics, EHR data lakes, and genomic/clinical trial pipelines include:

• HIPAA-Compliant Cloud Storage & Databases: Amazon S3 and Amazon S3 Glacier (object storage for DICOM medical imaging, C-CDA documents, and research data lakes), Amazon EBS and Amazon EFS (block and file storage), Amazon RDS and Amazon Aurora (relational databases), Amazon DynamoDB (NoSQL key-value store), and Amazon Redshift (cloud data warehouse).
• Compute & Containers: Amazon EC2, AWS Lambda (serverless functions), Amazon ECS, Amazon EKS (Kubernetes), and AWS Fargate.
• Purpose-Built Healthcare & AI Services: AWS HealthLake (managed FHIR R4 data store and analytics), Amazon Comprehend Medical (clinical NLP entity extraction), Amazon Transcribe Medical (clinical speech-to-text), AWS HealthImaging, AWS HealthOmics, Amazon Bedrock, and Amazon SageMaker.
• Security, Key Management, & Audit Logging: AWS Key Management Service (KMS), AWS CloudHSM, AWS CloudTrail, Amazon CloudWatch, AWS Config, and AWS WAF / Shield.

Mapping the HIPAA Security Rule (45 CFR § 164.312) to AWS Technical Controls

To pass institutional information security reviews and OCR audits, cloud engineers map the five technical safeguard standards of 45 CFR § 164.312 directly to AWS configuration controls:

1. Access Control (§ 164.312(a)(1)): Enforce unique user identification via AWS IAM Identity Center (SSO) federated with an enterprise Identity Provider (IdP), require hardware or virtual MFA for all human users, prohibit root account usage, block public access at the account level on all Amazon S3 buckets (BlockPublicAccess), and encrypt all ePHI at rest using AWS KMS Customer Managed Keys (CMKs) with automatic annual key rotation.
2. Audit Controls (§ 164.312(b)): Enable multi-region AWS CloudTrail management events and S3/Lambda data events writing to a centralized, dedicated security logging account with S3 Object Lock (Write-Once-Read-Many / WORM retention for at least 6 years per 45 CFR § 164.530(j)), paired with VPC Flow Logs and RDS database audit logs.
3. Integrity (§ 164.312(c)(1)): Enable Amazon S3 Versioning, CloudTrail log file integrity validation (SHA-256 digest chaining), and AWS Backup immutable vault policies to prevent unauthorized alteration or ransomware deletion of ePHI.
4. Person or Entity Authentication (§ 164.312(d)): Require short-lived IAM role session tokens (AWS STS) rather than long-lived static IAM access keys, and enforce mutual TLS (mTLS) or OAuth 2.0 / SMART on FHIR authentication on clinical APIs.
5. Transmission Security (§ 164.312(e)(1)): Enforce TLS 1.2 or TLS 1.3 on all Application Load Balancers (ALBs), Amazon API Gateway endpoints, and S3 bucket policies (aws:SecureTransport = true), and route inter-service traffic over private AWS PrivateLink (VPC Endpoints), AWS Direct Connect, or IPSec VPN tunnels so ePHI never traverses the public internet unencrypted.