HIPAA-Compliant Hosting: AWS vs Azure vs Google Cloud (and What a BAA Actually Covers).

Quick Answer: No cloud, host or server is "HIPAA certified," because HHS does not certify any. What you can do is host protected health information (PHI) on a provider that signs a business associate agreement (BAA), use only the services that BAA covers, and configure them correctly. AWS, Microsoft Azure and Google Cloud all do this, and all three say the customer stays responsible for compliance. The BAA is the starting line, not the finish line.

If you are building or buying a healthcare application, "where does this run?" is one of the first questions a hospital, clinic or insurer will ask you. The honest answer has three parts: the contract (the BAA), the services (the ones that contract covers), and your configuration (the part nobody else can do for you).

We are a Houston software company that builds healthcare software, including the infrastructure it runs on. This guide covers what the three big clouds actually say about HIPAA, a configuration checklist, and how to decide between managed "HIPAA hosting" and doing it yourself. It is the hosting companion to our healthcare software development work. Provider statements below were read on their official pages on November 1, 2026.

First: there is no such thing as "HIPAA certified"

Vendors love the phrase "HIPAA certified hosting." It is marketing. Microsoft says it plainly in its Azure documentation: "There is currently no certification program approved by the US Department of Health and Human Services (HHS) through which a CSP acting as a business associate could demonstrate compliance with HIPAA and the HITECH Act". Providers instead map HIPAA requirements to frameworks they can be audited against, such as NIST, ISO 27001 and the Cloud Security Alliance's controls.

What a provider can honestly say is one of these:

• "We will sign a BAA."
• "These services are covered by our BAA."
• "We are audited against SOC 2 / ISO 27001 / HITRUST," with a report you can request.

If a hosting company says it is "HIPAA certified," ask who certified it. There is no government body that does.

What a BAA actually covers

HIPAA requires a written contract with any vendor that handles PHI for you. HHS's cloud guidance, as summarized by Hunton Andrews Kurth, says covered entities and business associates may use a cloud service to store or process electronic PHI, provided they have a HIPAA-compliant BAA with the cloud provider. Read HHS's original Guidance on HIPAA and Cloud Computing as well.

Points from that guidance worth knowing:

• The cloud provider is a business associate, even when it only stores your data. The guidance states that CSPs are directly liable for failing to safeguard ePHI as well as for impermissible use or disclosure.
• "We can't see your data" is not a loophole. HHS's cloud guidance treats a provider that stores only encrypted data and does not hold the key as still a business associate. You still need the BAA.
• The BAA also covers incident reporting. The cloud provider must report security incidents it becomes aware of.
• The HIPAA Rules do not require a CSP to hand over documentation or allow audits of its security practices, though your contract can. Read what you are getting.

What a BAA does not do:

• It does not make your application compliant. Microsoft's FAQ is blunt: a BAA helps support compliance, but using Azure "doesn't automatically impart compliance onto your cloud solutions."
• It does not cover every product the provider sells. Each provider limits the BAA to listed services.
• It does not cover the software you or your vendors build on top. If you are a SaaS company, your customers sign a BAA with you; Microsoft notes that customers of a healthcare SaaS on Azure do not need their own BAA with Microsoft.

The shared responsibility model

All three providers use the same idea: they secure the cloud, you secure what you put in it. Google puts it this way: "Complying with HIPAA is a shared responsibility between you and Google". AWS says its services are HIPAA eligible "subject to the shared responsibility model. Customers still must configure these services consistent with HIPAA requirements".

In plain terms:

AWS vs Azure vs Google Cloud on HIPAA

All three will sign a BAA. The differences are in how, and in the details you must follow.

Is AWS HIPAA compliant?

AWS is a BAA-signing provider with a list of services it calls HIPAA eligible, which it describes as eligible to create, receive, process, maintain or transmit ePHI. Examples on that list include Amazon S3, Amazon RDS, AWS Lambda, Amazon DynamoDB, AWS KMS and Amazon EC2. AWS also states you agree not to use these services for PHI without first entering into a BAA, and that customers are responsible for their own HIPAA compliance. So the accurate answer to "is AWS HIPAA compliant?" is: AWS can be used in a HIPAA-compliant way, if you sign the BAA, use eligible services and configure them properly. The account does not become compliant by itself.

Azure

Microsoft's approach is the simplest contractually: its BAA is part of the Product Terms and Data Protection Addendum, available to customers who are covered entities or business associates, with no separate paper to sign. In exchange, Microsoft says it doesn't inspect, approve or monitor your applications, and that you are wholly responsible for your own compliance.

Google Cloud

Google's page is the most operational. Beyond the shared-responsibility statement, it tells customers not to include PHI in resource metadata, logs, monitoring labels or configuration files, to use Cloud KMS and strict IAM controls, and to export audit logs to secure long-term storage and review them.

Which should you pick?

Honestly, for most healthcare apps the three are close enough that the deciding factors are non-HIPAA ones:

• Where your team already has skill. A misconfigured cloud you know is worse than a well-configured one you know less about, but the real risk is the unknown, so favor familiarity.
• What your customers require. Some hospitals standardize on one cloud, and an EHR you integrate with may sit near one. Our FHIR and EHR integration guide covers that side.
• Whether the specific services you need are on the BAA list. Check the services, not the brand. A managed AI or analytics feature might be outside the BAA even when the database is inside it.

HIPAA hosting configuration checklist

Use this as a review list for any environment holding PHI. These are engineering practices aligned with the HIPAA Security Rule's safeguards, not a legal opinion. Your risk analysis decides what is required for your situation.

1. Sign the BAA first, before any PHI enters the account. Record where it lives and who owns renewal.
2. Use only covered services for PHI. List every service your app touches and check it against the provider's list. Turn off or isolate the rest.
3. Encrypt at rest. Databases, object storage, disks and backups, with keys in the provider's key management service and rotation defined.
4. Encrypt in transit. TLS on every connection, including internal service-to-service traffic and database connections.
5. Require MFA for every human with console or admin access. Prefer short-lived, role-based access over shared long-lived keys.
6. Apply least privilege. Each person and service gets only the permissions needed. Review access on a schedule and when people change roles.
7. Turn on audit logging for account activity and for access to PHI, send logs to storage nobody can casually edit, and set a review routine and retention period.
8. Keep PHI out of logs, error messages and metadata. Google specifically warns against PHI in logs, labels and config. Scrub application logs and error reports.
9. Back up and test restores. A backup you have never restored is a guess. Define recovery goals and test them.
10. Segment the network. Databases are not reachable from the open internet. Separate production from development, and never use real PHI in dev or test.
11. Manage vendors. Every vendor that touches PHI (email, SMS, support desks, error tracking, AI services) needs a BAA or must not receive PHI.
12. Write the incident plan and rehearse it. Know who decides a breach is reportable and how fast.
13. Document your risk analysis and update it when the system changes.

Don't leak PHI through analytics and ad tags

This one catches healthcare websites constantly. HHS's Office for Civil Rights published a bulletin on online tracking technologies used by covered entities. In June 2024 a federal court in Texas (American Hospital Association v. Becerra) vacated part of it: the portion that treated an IP address plus a visit to an unauthenticated public page about a health condition as PHI by itself. Per Holland & Knight's summary, the rest of the revised bulletin was not vacated, and OCR continues to watch tracking on pages that require authentication, such as patient portals. Read the bulletin itself and get your lawyer's view.

The practical rule is simple and does not depend on the ruling: no analytics pixel, session-replay tool or ad tag inside a login, patient portal or app screen, unless the vendor has signed a BAA and your counsel has approved it. Audit your tags the way you audit your servers.

Managed "HIPAA hosting" vs running it yourself

Many companies sell "HIPAA-compliant hosting": a managed environment, often on top of AWS, Azure or Google Cloud, where they handle configuration, patching and monitoring. Neither option is better in general. Here is how to decide.

Questions to ask a managed host before signing:

• Will you sign a BAA, and can I read it first?
• Which services and which underlying cloud do you use, and are they on that provider's covered list?
• Who owns encryption keys and backups, and how do I get my data out if I leave?
• What logging and monitoring do I get access to?
• What exactly is my responsibility, in writing?

Either way, you remain responsible for the application: what it stores, what it logs and who can see it. That is true on every provider above.

Where we fit

We build healthcare applications and the infrastructure behind them, including clinical documentation software for home-health agencies, where visit documentation and EHR integration run on infrastructure designed around these same rules. If you are planning a healthcare product and want the hosting, security controls and application designed together, start with our healthcare software development team. If the product includes video visits, see telemedicine app development, and for budgeting, read what drives healthcare app development cost.

FAQ

Is AWS HIPAA compliant? AWS lists services that are HIPAA eligible and signs a business associate agreement, but AWS itself says customers must configure those services consistent with HIPAA and are responsible for their own compliance. Using AWS does not make an application compliant.

Is there an official HIPAA certification for cloud hosting? No. Microsoft's Azure documentation states there is no certification program approved by HHS through which a cloud provider can demonstrate HIPAA compliance. Providers instead point to a BAA and to audits such as SOC 2 or ISO 27001.

Do I need a BAA with my cloud provider? Yes, if the provider creates, receives, maintains or transmits electronic protected health information for you. HHS guidance says the cloud provider is a business associate, even if it only stores encrypted data and does not hold the key.

Can I use any AWS, Azure or Google Cloud service with PHI once I have a BAA? No. Each provider's BAA covers a defined list of services. AWS says you must not use its services for PHI without a BAA, and Google tells customers to disable unsupported services and not to use pre-GA offerings with PHI unless expressly noted.

Is managed HIPAA hosting better than running it myself? It depends on your team. A managed provider can take on configuration and monitoring, but you still have to sign a BAA with them and remain responsible for how your application handles data. Running it yourself on a hyperscaler gives more control and needs security expertise.

Planning a healthcare product?

Tell us what you are building and where PHI will live, and we will help you design the hosting and controls around it. Start with healthcare software development or contact us.

Sources read November 1, 2026: AWS HIPAA eligible services, Microsoft Azure HIPAA/HITECH offering, Google Cloud HIPAA compliance, Hunton summary of HHS cloud guidance, Holland & Knight on the OCR tracking bulletin ruling. This article is general information, not legal advice.