HIPAA compliant cloud hosting
Hosting for applications that handle health data. Coverage is granted per service, from a published eligibility list that moves.
Accepting the addendum on a major cloud platform is the easy part, often a few clicks in a console at no extra cost. What follows is harder. Coverage comes from a published list of eligible services, and that list is long, revised often, and full of exclusions buried inside services that are themselves eligible: a particular studio or labs edition, a specific messaging channel, certain database engines, certain models. A team can be well inside the list at service level and outside it two menus down.
The platform also does very little for you. These vendors are explicit that using an eligible service does not by itself protect anything, and that encryption, key management, network isolation, access control, logging and backup are yours to design. Organizations that handle this well treat the eligibility list as a procurement gate every new service must pass before an engineer switches it on.
3 cloud platforms compared
3 of 3 can be used with patient information under a signed agreement.
| Vendor | Verdict | Agreement and plan | How to get it | Not covered | Reviewed |
|---|---|---|---|---|---|
| AWSAWS | Conditional | No special plan or support tier. Self-service for any AWS account, or organization-wide via AWS Organizations. | AWS Artifact console → Agreements → Account agreements → Business Associate Addendum → Download → accept the Artifact NDA → review → Accept agreement. | Any service not on the HIPAA Eligible Services Reference. | |
| Google CloudGoogle Cloud Platform | Conditional | No special plan or support tier. Google notes it offers regulated customers the same products at the same pricing as everyone else, including sustained-use discounts. | Review and accept the agreement by following Google's privacy compliance and records instructions for Google Cloud. | Any Google Cloud product not explicitly named on the covered-products list. | |
| AzureMicrosoft Azure and Azure Government | Conditional | No particular tier. Included by default for covered entities and business associates purchasing under a licensing agreement that incorporates the Product Terms and Data Protection Addendum. | Nothing to request. Microsoft states there is no separate contract to sign; the agreement rides on the Product Terms, and the Data Protection Addendum provides that executing your volume licensing agreement executes it. | Azure services outside Microsoft's published audit scope. |
What to check before you adopt one
- Read the eligibility entry for each service you plan to use, footnotes included, since exclusions often sit inside a service that does appear on the list.
- Establish who is permitted to accept the addendum and whether it can be applied once across every account in your organization.
- Decide in advance which accounts or projects may hold patient data, and keep experimentation on separate accounts that never receive any.
- Write down the encryption, logging and access-control configuration the platform expects of you, because none of it is applied automatically when the addendum is accepted.
- Add a step to your change process requiring the eligibility list to be re-checked before any new service is adopted.
The expensive mistake
Treating the signed addendum as though it covered the whole platform. An engineer picks a convenient managed service to solve a problem, and nobody checks whether that service, or the specific feature within it, appears on the eligibility list. The list is the boundary, not the account. Anything outside it holding patient data is outside the agreement regardless of what you signed.