No cloud provider can sell you a HIPAA certificate, because the US Department of Health and Human Services doesn't run a certification program for one. What you can buy is HIPAA compliant cloud hosting in a narrower sense: a provider that signs a business associate agreement and runs a defined list of services under it.
That distinction decides which hosting you pick and what you still owe after you've picked it.
What HIPAA compliant cloud hosting actually means
It means two things at once: a signed contract with the host, and a deployment you've configured correctly. The contract is the part a provider can give you. The configuration is yours.
Microsoft states the first half plainly. Its Azure compliance documentation says no certification program approved by HHS exists through which a cloud provider acting as a business associate could demonstrate HIPAA compliance. Google Cloud says the same of its own products.
So when a hosting page calls itself "HIPAA certified", read it as marketing. The useful questions are whether the provider will sign a BAA, which services that BAA covers, and what the provider expects you to handle.
Why the business associate agreement comes first
Once a cloud provider stores electronic patient data for you, it becomes a business associate under HIPAA, and the two of you need a BAA before any real data goes in. The same applies when you're a vendor and subcontract your hosting to a cloud provider.
Law firm Hunton Andrews Kurth, summarizing HHS's October 2016 cloud guidance, notes that the BAA must cover permitted uses and disclosures, Security Rule safeguards and the reporting of security incidents. It also reports that cloud providers can't claim the conduit exception, since they store data and have more persistent access to it than a pipe that merely passes it along.
The practical upshot is that "we never look at your data" doesn't excuse a host from the contract.
Providers also carry their own exposure. According to the same summary, they're directly liable under the Security Rule for failing to safeguard patient data. HIPAA doesn't force a provider to hand over security documentation or allow audits, but your BAA can require it, which is worth asking for before you sign anything.
Comparing the big three: AWS, Azure and Google Cloud
All three major platforms will sign a BAA, so choosing HIPAA compliant cloud hosting rarely turns on whether they're allowed to host health data. It turns on how the agreement is accepted, how the covered-service list works, and which stack your team already knows.
| Provider | How you get the BAA | What it covers |
|---|---|---|
| AWS | Review and accept a standard addendum in the AWS Artifact console | HIPAA-eligible services only, per AWS's maintained reference list |
| Microsoft Azure | Included by default through Product Terms and the Data Protection Addendum | In-scope Azure services listed in Microsoft's audit-scope page |
| Google Cloud | Review and accept through Google's compliance records process | A long named list including Compute Engine, BigQuery, Cloud Storage, GKE and Cloud SQL |
AWS
AWS asks you to accept its standard addendum yourself. Its HIPAA compliance page explains that you can use any AWS service in a HIPAA account, but you should process, store and transmit patient data only in the services the BAA defines as HIPAA eligible.
You accept it from AWS Artifact in the management console. If your login can't see Artifact, an administrator has to grant the permissions first.
Microsoft Azure
Azure has the lowest-friction contract. Microsoft says there's no separate document to sign, because the BAA comes with the Product Terms and the Data Protection Addendum, and signing a volume licensing agreement includes it.
One detail matters if you sell software. According to Microsoft, a healthcare SaaS vendor running on Azure signs BAAs with its own customers, and those customers don't need a separate BAA with Microsoft. Microsoft also can't use a customer's own BAA template, since it runs standardized multi-tenant services.
Google Cloud
Google's HIPAA documentation says its BAA covers Google Cloud's infrastructure and a long list of named products, and that you aren't restricted to particular regions. Google Workspace tools such as Gmail and Drive fall under a separate list.
Two rules there are easy to miss. If a service isn't supported and you can't switch it off, you mustn't use it with patient data, and pre-GA offerings are off limits unless a notice says otherwise.
Where your responsibility starts
A BAA doesn't make your application compliant. Microsoft answers the question outright in its FAQ: using Azure doesn't automatically make your cloud solution compliant, and you're responsible for your own compliance program and for how you use the service.
Google puts it the same way. Compliance is shared, and you decide whether you're a covered entity or a business associate and whether your environment and applications are configured to meet HIPAA's requirements.
In practice, HIPAA compliant cloud hosting begins with the host's contract and ends with your configuration. Access control, how data is encrypted in your own application, logging and who can reach the database are your decisions, and a misconfigured storage bucket on a fully eligible service is still your problem.
Teams building products on top of a host usually find this out during application design rather than during procurement, which is why we cover the build side separately in our guide to what HIPAA compliant app development takes.
Services outside the BAA
The covered-service list is the most overlooked part of any HIPAA compliant cloud hosting contract. A provider can sign a BAA and still run products it doesn't cover, and sending patient data through one of them is a violation even though you hold a BAA.
Before you design an architecture, write down every service that will touch patient data, including logging, analytics, backups and messaging, and check each against the provider's current list. Lists change, so treat the provider's own page as the source rather than a blog post, ours included.
The same applies to anything experimental. Google's rule on pre-GA offerings is a good habit for every provider: if a service is in preview, keep patient data out of it.
Hosting location and offshore storage
HIPAA compliant cloud hosting doesn't have to mean US-only servers, since HIPAA doesn't ban storing patient data abroad. The Hunton summary of the HHS guidance says it's permitted, though covered entities should weigh the risks tied to the country where the servers sit.
Choose a US region by default unless a contract or a patient-population reason pushes you elsewhere, because that removes one risk assessment from your list. It's a judgment call, not a legal requirement.
Which provider should you choose?
Go with the platform your engineers already run well. Since all three sign a BAA, familiarity with the tooling, and therefore fewer misconfigurations, is worth more than any difference in contract wording.
If you have no existing stack, Azure's default BAA removes a step, while AWS and Google Cloud ask you to accept the agreement yourself. Where you're still choosing an architecture, scalable web architecture for healthcare teams shows how the hosting layer fits with the rest of the system.
Hosting is only one layer of a health product. When we designed and built OptimalMD's website, members portal and mobile app end to end, the hosting decision sat beneath all three. You can read how that project came together in our OptimalMD case study.
If you're planning something larger, our healthcare software development guide covers the wider decisions, and our apps and SaaS team builds the product that goes on top of the host.
Before you commit to HIPAA compliant cloud hosting from any provider, get its eligible-service list and BAA in front of whoever handles your compliance, and check your planned architecture against that list line by line.
Frequently asked questions
Is HIPAA compliant cloud hosting the same as a HIPAA certified provider?
No. HHS doesn't offer a certification program, and both Microsoft and Google say so in their documentation. A provider can sign a BAA and attest to related security frameworks, but that isn't a HIPAA certificate.
Do I need a BAA if my cloud provider can't read my encrypted data?
Yes. Providers that store patient data are business associates, and the conduit exception doesn't apply to them because they maintain the data rather than merely transmit it.
Does my SaaS customer need its own BAA with Microsoft if I host on Azure?
No. Microsoft says healthcare providers can sign a BAA directly with you as the SaaS vendor and don't need one with Microsoft to use your product.
Can I store patient data on servers outside the US?
HIPAA permits it, according to the Hunton summary of HHS's guidance. You should weigh the risks of the server's country before choosing it.
Can I use any service on AWS once I've accepted the BAA?
You can use any service in the account, but AWS says patient data should only be processed, stored and transmitted in the HIPAA-eligible services its BAA defines.
Cover photo by Christina Morillo on Pexels
Sources
- HIPAA Compliance - AWS — Amazon Web Services
- HIPAA - Azure Compliance — Microsoft Learn
