A HIPAA compliant cloud is not a product you buy. It is a cloud environment you build and operate: a signed Business Associate Agreement with your provider, a set of eligible services configured correctly, documented safeguards, continuous monitoring, and organizational discipline. No cloud vendor sells a toggle that makes your workload compliant the moment you flip it on.
If you are planning a healthcare application, data platform, or clinical workflow that will store or process electronic protected health information (ePHI), the hosting decision is really a series of architecture and operations decisions. This article walks through the ones that matter, gives you a practical checklist, and helps you avoid the mistakes that create real risk.
What a HIPAA Compliant Cloud Actually Means
The phrase "HIPAA approved cloud" appears in a lot of marketing copy, but it is misleading. HHS does not certify or approve cloud providers. What the regulation requires is that any cloud service provider that creates, receives, maintains, or transmits ePHI on behalf of a covered entity or business associate is itself a business associate and must sign a BAA before any ePHI touches the environment. That is true even if the provider stores data in encrypted form and cannot view it.
A BAA is necessary but not sufficient. The HIPAA Security Rule requires administrative, physical, and technical safeguards to protect the confidentiality, integrity, and availability of ePHI. Your cloud provider handles some of those safeguards (physical security of data centers, for example), but you own the rest: access controls, encryption configuration, logging, incident response, workforce training, and application-level security.
This is the shared responsibility model. Google Cloud states it plainly: HIPAA compliance is a shared responsibility, customers need a BAA, and customers remain responsible for configuring their environment and applications. The same principle applies across AWS, Azure, and Google Cloud.
So when someone asks "Is AWS HIPAA compliant?" the accurate answer is: AWS offers a BAA, publishes a list of HIPAA eligible services, and provides the infrastructure controls to support compliant workloads. Whether your workload is actually compliant depends on what you build and how you operate it.
The Architecture Decisions That Matter Before Provider Choice
Before you compare AWS to Azure to GCP, get clear on six architecture areas. These decisions shape your compliance posture more than the provider logo on the invoice.
Data Classification and ePHI Boundary
Map every data element your system will handle. Identify what qualifies as ePHI and where it will be created, stored, processed, and transmitted. Draw a clear boundary around ePHI workloads. Everything inside that boundary gets the full set of HIPAA controls. Everything outside it does not need the same overhead, which saves cost and complexity.
This sounds obvious, but skipping it leads to two problems: either you apply expensive controls to non-sensitive workloads, or you accidentally process ePHI in a service that is not covered by your BAA.
Identity and Access Model
Decide how clinicians, administrators, developers, and automated services will authenticate and what permissions each role needs. Use the principle of least privilege. Plan for multi-factor authentication on any account that can reach ePHI. Document who can grant access and how access is reviewed and revoked.
Encryption and Key Ownership
Encrypt ePHI at rest and in transit. That is a baseline, not a differentiator. The real decision is key management: will you use provider-managed keys, customer-managed keys in the provider's key management service, or bring your own keys from an external HSM? Customer-managed keys give you more control and a cleaner audit story, but they add operational responsibility.
Audit Logging and Retention
Every access to ePHI needs to be logged. Every administrative action on the infrastructure needs to be logged. Decide where logs are stored, how long you retain them, who can read them, and whether anyone can modify or delete them. Immutable log storage is worth the cost.
Backup, Recovery, and Incident Response
The Security Rule requires you to maintain the availability of ePHI. That means tested backups, documented recovery procedures, and a defined recovery time objective. It also means an incident response plan that covers breach detection, containment, notification, and post-incident review.
Network Segmentation and Private Connectivity
ePHI workloads should run in isolated network segments. Use private subnets, VPC peering or private endpoints, and restrict internet-facing surfaces to the absolute minimum. If your application integrates with EHR systems or labs, plan for VPN or private interconnect rather than routing patient data over the public internet.
AWS, Azure, or Google Cloud: How to Choose
All three major providers can support HIPAA compliant cloud workloads. AWS states that covered entities and business associates can use AWS to process, maintain, and store PHI and publishes a list of HIPAA eligible services. Microsoft describes the business associate relationship explicitly and offers a BAA as part of its Online Services Terms. Google Cloud offers a BAA and a compliance guide covering configuration responsibilities.
Do not pick a provider based on who has the best compliance marketing page. Pick based on these factors:
Existing stack and team skills. If your engineering team already operates on AWS and your CI/CD, monitoring, and infrastructure-as-code are built around AWS services, switching to Azure for a healthcare project introduces risk and ramp-up time. Compliance is easier when your team knows the platform deeply.
Healthcare-native services. AWS has HealthLake and Comprehend Medical. Azure has the Azure Health Data Services with FHIR, DICOM, and MedTech connectors. Google Cloud has the Cloud Healthcare API. If your product needs EHR integration or FHIR-based data pipelines, evaluate which provider's managed services reduce the custom code you need to write and maintain. The ONC describes HL7 FHIR Bulk Data Access as a standard route for large-scale health data export, and your cloud provider's FHIR tooling can simplify that integration.
Data and analytics needs. If your product involves population health analytics, ML on clinical data, or real-time streaming from wearables, compare the data engineering ecosystem on each provider. BigQuery, Redshift, and Synapse have different pricing models, performance profiles, and integration patterns.
Procurement and compliance portfolio. Some health systems have existing enterprise agreements with Microsoft or AWS. Using the same provider can simplify procurement, consolidate BAAs, and reduce vendor management overhead.
Cost model. Affordable HIPAA hosting is possible on all three platforms, but the cost depends on your architecture. Reserved instances, spot capacity for non-ePHI batch jobs, and right-sized storage tiers matter more than the provider's list price.
HIPAA Compliant Cloud Storage and Backup Checklist
Cloud storage and cloud backup are where ePHI most commonly lives at rest. Use this checklist when designing or auditing your storage architecture:
- BAA in place that explicitly covers the storage and backup services you use.
- Only eligible services used for ePHI. Each provider publishes a list. S3 is eligible on AWS; Blob Storage is eligible on Azure; Cloud Storage is eligible on GCP. Verify every service against the current list.
- Encryption at rest enabled on every bucket, database, and volume that holds ePHI. Use customer-managed keys where your risk assessment calls for it.
- Encryption in transit enforced. TLS 1.2 or higher for all connections. Reject unencrypted requests at the service level.
- Access controls scoped tightly. No public buckets. No wildcard IAM policies on storage resources. Use resource-based policies and identity-based policies together.
- Versioning enabled on object storage that holds ePHI, so accidental overwrites or deletions are recoverable.
- Backup schedule documented and automated. Daily or more frequent, depending on your recovery point objective.
- Backup encryption and access controls match or exceed production controls. A backup with weaker permissions is a breach vector.
- Cross-region or cross-account backup copies if your disaster recovery plan requires geographic redundancy.
- Retention and deletion policies defined. Know how long you must retain ePHI under applicable state and federal rules, and automate deletion when retention expires.
- Restore testing on a schedule. Backups you have never restored are assumptions, not safeguards. Test quarterly at minimum.
- Access reviews quarterly. Who can read, write, or delete ePHI storage? Review and prune.
This checklist applies whether you are building HIPAA compliant cloud storage for a patient portal, a clinical data warehouse, or a HIPAA compliant cloud backup strategy for disaster recovery.
Migration and Implementation Plan for Healthcare Teams
If you are moving an existing healthcare workload to the cloud or building a new one, a phased approach reduces risk. Teams that handle cloud migration for healthcare workloads typically follow a pattern like this:
Phase 1: Map PHI and vendors. Inventory every system that touches ePHI. Identify every vendor and subprocessor. Confirm BAA status for each. This phase often reveals shadow IT or forgotten integrations.
Phase 2: Design the landing zone. Build your cloud account structure, network topology, IAM baseline, logging pipeline, and encryption configuration before any workload moves. Use infrastructure-as-code so the environment is repeatable and auditable. This is where DevOps and cloud engineering discipline pays off.
Phase 3: Move low-risk workloads first. Start with non-ePHI workloads or internal tools. Validate your deployment pipeline, monitoring, and incident response process on workloads where a mistake does not trigger a breach notification.
Phase 4: Validate controls and logging. Before ePHI enters the environment, run a controls validation. Confirm that encryption is enforced, access is restricted, logs are flowing to immutable storage, and alerting works. Conduct a penetration test or security review.
Phase 5: Migrate production ePHI and monitor. Move ePHI workloads with a rollback plan. Monitor access patterns, error rates, and security alerts closely in the first 30 to 90 days. Adjust controls based on what you observe.
Common Mistakes That Make Cloud Healthcare Projects Risky
These are the patterns we see most often in healthcare cloud projects that run into compliance trouble:
No BAA before testing with real data. Development and staging environments that use real patient data without a BAA in place are violations, even if the data is "only for testing."
Using non-eligible services for ePHI. Not every service on a cloud platform is covered by the BAA. Using a managed service that is not on the eligible list, even briefly, creates exposure.
Public storage buckets or overly broad IAM. Misconfigured S3 buckets and permissive IAM roles are among the most common causes of healthcare data exposure. Automate detection of public access and overly broad permissions.
Logs that accidentally contain PHI. Application logs, error messages, and debugging output can capture patient names, identifiers, or clinical data. If those logs are stored in a service outside your ePHI boundary, you have a problem.
Backups that no one tests. A backup that fails silently or cannot be restored within your recovery time objective is a compliance gap and a business continuity risk.
Treating compliance as a one-time launch task. HIPAA compliance is an ongoing obligation. Configuration drift, new services, staff turnover, and changing threat patterns all require continuous attention. Build compliance checks into your CI/CD pipeline and your operational runbooks.
When Custom Engineering Helps
Managed cloud services cover a lot of ground, but most real healthcare products need custom engineering to tie everything together: identity flows, patient data pipelines, analytics, observability, and security automation.
We saw this pattern in RAE Health, an integration-heavy healthcare platform with mobile apps, a clinician-facing web portal, wearable data ingestion, and analytics. The backend architecture ran on AWS using ECS, RDS, Cognito, and SQS, with Terraform for infrastructure-as-code and a security toolchain that included Semgrep, container scanning with Trivy, and observability through Grafana and InfluxDB. That project ran for over 24 months, not because the cloud services were hard to turn on, but because joining patient data flows, clinician workflows, and operational monitoring into a secure, auditable system required sustained architecture discipline.
If your team has deep cloud and security experience, you can build this in-house. If you need to move faster or fill gaps in healthcare-specific cloud architecture, working with a team experienced in healthcare software development can reduce the time to a compliant, production-ready environment. The goal is not to outsource compliance. It is to get the architecture right from the start so compliance is a property of how the system works, not a checklist bolted on afterward.
For teams building healthcare applications, the cloud hosting layer is the foundation. Get it wrong, and no amount of application-level security fixes the gap. Get it right, and you have a platform that supports growth, new integrations, and evolving regulatory requirements without rearchitecting under pressure.
