HIPAA Infrastructure on AWS, GCP, and Azure

If your startup touches protected health information (PHI), HIPAA compliance on the cloud comes down to four moves: get a Business Associate Agreement (BAA) in place with your provider, keep PHI inside that provider’s HIPAA-eligible services, implement the Security Rule’s technical safeguards yourself (encryption, access control, audit logging, backup/DR), and keep the documentation to prove it. All three major clouds — AWS, GCP, and Azure — support this at no premium price; none of them makes you compliant on their own. This is engineering guidance, not legal advice — pair it with counsel for the Privacy Rule side.

Do you need a BAA with your cloud provider?

Yes — when a cloud provider stores or processes PHI on your behalf, it becomes your business associate under HIPAA, and a BAA is legally required before any PHI lands. All three providers offer one at standard pricing, but the mechanics differ, and the differences matter on day one.

• AWS requires you to accept its BAA (self-service through AWS Artifact) before using HIPAA-eligible services with PHI. Per AWS’s own terms, using eligible services for PHI without a BAA in place is a violation of your agreement.
• GCP has you accept its BAA through the console/support flow. Per Google’s compliance docs, the BAA covers its products across all regions at standard pricing — there’s no restricted “HIPAA region.”
• Azure is the odd one out, in a good way: per Microsoft’s compliance docs, the HIPAA BAA is included by default in the Microsoft Product Terms via the Data Protection Addendum — executing your licensing agreement executes the BAA. There is no separate signature step.

One nuance for health-tech SaaS: your healthcare customers sign a BAA with you, not with your cloud provider. You then need your own BAA chain down to AWS/GCP/Azure as their business associate’s subcontractor.

Which cloud services are HIPAA-eligible?

Not every service in your provider’s catalog may touch PHI. AWS publishes a HIPAA Eligible Services Reference listing roughly 200+ services; Google publishes a similar list of 200+ covered products; Azure scopes its BAA to services in audit scope. The mainstream infrastructure a startup runs on is covered everywhere: EC2/Compute Engine/VMs, S3/Cloud Storage/Blob, RDS and Aurora/Cloud SQL, EKS/GKE/AKS, Lambda/Cloud Run, plus the security plumbing — KMS, CloudTrail, Cloud Audit Logs, and equivalents.

The traps are at the edges:

• Unlisted services must not process PHI. Check the list before adopting anything new — especially AI services.
• Pre-GA and preview products are excluded — Google says this explicitly; treat it as true everywhere.
• PHI leaks into metadata. Google’s guidance calls out resource names, metric labels, dashboard titles, and log fields as places PHI must never appear, because metadata can flow through systems outside BAA coverage. Patient IDs in an S3 object key or a Prometheus label are a real finding.

What encryption does HIPAA actually require?

Here’s the part that surprises engineers: under the Security Rule’s technical safeguards (45 CFR §164.312), encryption is “addressable,” not “required.” Addressable doesn’t mean optional — it means you either implement it or document why an alternative is reasonable. In 2026, there is no defensible alternative, and there’s a practical kicker: HHS’s breach notification rules apply to unsecured PHI, so properly encrypted data that leaks generally doesn’t trigger the same notification obligations.

The defensible baseline for a health-tech stack: KMS/CMEK-backed encryption on every datastore (S3, EBS, RDS; GCS, Cloud SQL; Blob, managed disks — all support it natively, GCP encrypts at rest by default), TLS termination at the edge and in transit internally, and key access logged through CloudTrail/Cloud Audit Logs/Azure Activity Log. It’s cheap, mostly checkbox-level effort on modern clouds, and it’s the first thing anyone reviewing your stack looks for.

How do access controls, audit logging, and backup/DR map to cloud services?

The Security Rule is service-agnostic; your job is mapping each safeguard to something concrete. Three are non-negotiable per §164.312: unique user identification (required), audit controls (required), and person/entity authentication (required). Automatic logoff and integrity verification are addressable. On the administrative side, the contingency plan standard drives your backup and disaster-recovery build, and documentation must be retained six years under §164.316.

Safeguard (45 CFR §164.312)	AWS	GCP	Azure
Unique user IDs, least privilege	IAM + Identity Center, no shared creds	Cloud IAM, per-user accounts	Entra ID, RBAC
Authentication	MFA enforced org-wide	MFA / security keys	Conditional Access + MFA
Audit controls	CloudTrail (all regions) + S3 archive	Cloud Audit Logs → GCS/BigQuery export	Activity Log → Log Analytics
Encryption at rest	KMS on S3/EBS/RDS	Default + CMEK	Key Vault + SSE
Transmission security	TLS via ALB/ACM	TLS via LB certs	TLS via App Gateway
Automatic logoff	SSO session timeouts	Session length controls	Entra session policies
Backup / DR (contingency plan)	AWS Backup, cross-region snapshots	Backup and DR Service	Azure Backup, Site Recovery

Two habits close most gaps: centralize audit logs into an account or project engineers can’t edit, and actually test a restore — a backup you’ve never restored is a hope, not a contingency plan. The mechanics here overlap heavily with our SOC 2 infrastructure checklist; on Kubernetes specifically, the same IAM, logging, and encryption story applies to EKS, GKE, and AKS.

Is there a HIPAA certification, and how does it relate to SOC 2?

There is no HIPAA certification — HHS approves no certifying program, a point AWS, Google, and Microsoft all state plainly. You attest to compliance, keep a risk analysis on file, and prove your safeguards work when a customer or regulator asks. That’s why most health-tech startups pair HIPAA with SOC 2: the audit produces a third-party report you can hand to buyers, and the controls overlap almost entirely — access, logging, encryption, backups, change management. Build once, map twice. See SOC 2 Type 1 vs Type 2 for sequencing, and our SOC 2 infrastructure service for how we run that build.

If you’re staring at a BAA request from your first hospital customer, an infrastructure audit is the fastest way to find the gaps — our audit and packages cover exactly this HIPAA-plus-SOC 2 mapping across AWS, GCP, and Azure.