HIPAA Cloud Hosting Compared: What’s Not in the Sales Page

Another “HIPAA-ready” platform list. What broke last time, and what will your auditor ask for this time?

I’ve watched teams pick a provider because it had a BAA link and a shiny compliance badge, then spend the next 90 days chasing missing logs, unclear service scope, and “oh, that product is not covered.” They claim it’s simple, but HIPAA work usually fails in the gaps between defaults, contracts, and day-two operations.

Concerns first: where “HIPAA-compliant hosting” usually goes sideways

Start here. Always.

The thing nobody mentions is that “HIPAA-compliant” often means “we will sign a BAA for some services, if you configure them correctly, and if your lawyers like the terms.” That is not the same as “safe to store ePHI on Tuesday night after a rushed patch.”

• BAA scope holes: Ask, “Which exact services are covered for ePHI?” If the vendor answers with a blog post instead of a list in the contract, assume you will find out the hard way.
• Shared responsibility surprises: Cloud providers secure the metal and some managed control planes. You still own IAM, network rules, app auth, data access patterns, and usually the mistakes that leak patient data.
• Audit evidence friction: Auditors do not accept “the platform is certified.” They ask for artifacts. Who can export raw access logs, prove retention, and show change history without a week of ticket ping-pong?
• Defaults that drift: A “minor” change can flip a default, expand a service’s access, or add a new integration path. Why did they rush this? What did they not put in the changelog?

Before you compare platforms, pin down what you must prove

Evidence beats vibes.

HIPAA compliance lives in what you can demonstrate, not what a landing page promises. So I treat every vendor claim as “maybe” until I can collect proof and store it somewhere the vendor cannot quietly rotate away.

• Signed BAA (and the boring attachments): Get the BAA, any amendments, and the subprocessor list. Save PDFs in immutable storage, not someone’s inbox.
• Access control proof: Enforce MFA and least privilege, then export evidence. “We require MFA” is not evidence. Show policy settings and access review records.
• Encryption proof: Encrypt at rest and in transit, yes. Also prove key control and key use. If you cannot answer “who used the key last week,” you do not have control, you have hope.
• Audit logging proof: Turn on the logs that show data access, not just management events. Export them off-platform on a schedule. Test a restore of those logs, too.

Some teams skip evidence automation early because “we’re just an MVP.” That works until a hospital asks for a security packet on a Friday afternoon.

Platform types, viewed through a suspicious engineer’s lens

Pick your pain.

You can buy convenience, or you can buy control. You cannot buy “no work.” The only real question is where you want the work to live and how likely it will wake you up at 2 a.m.

1) Specialized healthcare hosting (turnkey, but read the fine print)

I like these when the team has one part-time ops person and a deadline that does not care about your Terraform backlog.

• Atlantic.Net: Positions itself as regulated-industry hosting with an included BAA on HIPAA plans. Verify what “one-click” actually configures. Does it set log export destinations, retention policies, and least-privilege defaults, or just spin up a VM with encryption checked?
• HIPAA Vault: Fully managed can reduce operational risk, but it also adds a dependency. Ask how they prove patching happened, how they handle incident response evidence, and what you get during a breach review. They claim strong support KPIs. Ask for a dated, written source.
• Render HIPAA workspaces: Developer experience looks good, and the HIPAA add-on pricing feels predictable. I’d still ask: what does “dedicated, access-restricted infrastructure” mean in contract language, and which managed data services are in scope for ePHI under the BAA?

2) Big cloud (AWS, Azure, GCP): powerful, easy to misconfigure

This is where I’ve seen the most “we’re compliant” confidence evaporate. Fast.

AWS, Azure, and GCP can support HIPAA programs, but you will build a lot of your own guardrails. Unless you already run tight infrastructure code reviews and policy enforcement, you will probably ship a permissive role or a public bucket once. Then you will spend a week proving what happened.

• AWS: Huge service catalog and a published HIPAA-eligible service list. That list matters. If a service is not eligible, do not route ePHI through it and hope nobody notices. Also, budget time for CloudTrail and data event logging decisions because costs and noise climb quickly.
• Azure: Microsoft ties HIPAA/BAA terms into its standard contract structure for in-scope services. Procurement tends to move faster. Engineering still needs to lock down identity, networking, and logging, because “integrated” does not mean “safe by default.”
• GCP: Strong data tooling and a Healthcare API story that healthcare teams like. That does not remove your obligations around access, audit logs, and segmentation. If you plan to do analytics on ePHI, decide early who controls keys and who can query datasets.

3) Self-managed containers (Kubernetes): maximum control, maximum ways to mess it up

Kubernetes will not save you.

I’ve seen teams run “secure clusters” that still allowed broad namespace access, weak network policy, and sloppy secret handling. Kubernetes can support HIPAA controls, but you must wire them in and keep them wired in after every cluster upgrade and add-on update.

• Policy enforcement: Enforce restricted pod security settings and reject risky manifests. Do not rely on “we tell developers not to do that.”
• Network isolation: Default-deny policies beat diagrams. If you cannot say “this pod cannot talk to that pod,” you do not have segmentation.
• Secrets and keys: Keep secrets out of YAML. Use a real secrets system and audit access to it.
• Runtime detection: Add runtime monitoring if you store ePHI in the cluster. You will want the story when something weird happens.

4) Heroku Shield and DigitalOcean: niche fits, but verify scope

These can work. Sometimes.

Heroku Shield can make sense if you already live in the Salesforce world and you can afford the enterprise overhead. DigitalOcean can make sense for small workloads, but only if the specific products you use fall under its HIPAA program and you sign the right paperwork. They claim support. Make them show you the covered product list and the BAA requirements in writing.

Questions I send vendors because the docs won’t answer them

This saves weeks.

• “List the exact services covered for ePHI under the BAA.” Not “most services.” Not “our platform.” The list.
• “Show how to export raw access logs off-platform.” Include format, latency, and retention controls. If export needs an add-on or enterprise tier, I want to know now.
• “What’s the breach notification timeline in the contract?” And what evidence will they provide. Logs, forensics help, access history, all of it.
• “Who can access my data on your side, and how is that access logged?” If the answer is hand-wavy, I assume the worst.
• “What changed in the last 30 days that affects isolation, IAM defaults, or logging?” Watch how they react. The reaction tells you more than the answer.

Grudging recommendations (and why I’d wait a week)

My default stance: wait.

If you are not actively blocked, I’d give any new “HIPAA feature” release a week in the wild. Let other people find the foot-guns. Then test in staging with real log export, real access reviews, and a fake incident drill. Yes, even for a patch release.

• If you have limited DevOps capacity: Start with a managed, healthcare-focused platform that will sign a BAA and can hand you compliance artifacts quickly. But still verify scope and log export before you store a single patient record.
• If you already run a mature cloud security program: Use AWS, Azure, or GCP, pick only HIPAA-eligible services, and enforce policies in code. Do not let engineers click around consoles for production changes.
• If you need portability or on-prem constraints: Kubernetes can fit, but only if you treat it as a product with owners, budgets, and on-call. Otherwise you will build a compliance science project.

HIPAA compliance is not a configuration state. It’s a habit you can defend with logs, contracts, and test results.

Implementation checklist (the stuff you actually get audited on)

Do the boring things.

• Sign the BAA: No BAA, no ePHI. Full stop.
• Encrypt data: At rest, in transit, and in backups. Then document how you manage keys and who can use them.
• Require MFA: For every human and every admin path. Kill shared accounts.
• Log access to ePHI: Turn on the right logs, export them, and prove retention with a written policy.
• Test restores: Run restore tests on a schedule. Record results. Keep them.
• Run a risk analysis: Do it at least annually and after major architecture changes.
• Train staff: People cause most incidents. Tools just record them.
• Practice incident response: Tabletop exercises force you to find missing contacts and missing evidence paths before you need them.

There’s probably a cleaner way to score these platforms, but I keep coming back to the same rule. If a vendor cannot help you produce audit evidence quickly, they are not reducing your risk, they are moving it around.