Cloud (AWS · Azure · GCP) for health

In one line

Every major cloud runs health workloads safely. The question that decides your architecture is never which provider — it is where the data physically sits, who is responsible for what, and whether you signed the agreement that makes any of it lawful.

The misunderstanding that causes breaches

Read this sentence carefully, because a great deal of health data has leaked from people getting it wrong:

The cloud provider's compliance is not your compliance.

AWS being HIPAA-eligible does not make your application HIPAA-compliant. Azure holding an ISO 27001 certificate does not certify your system. What the provider certifies is their half — the physical data centre, the hypervisor, the network fabric, the hardware. Your half is everything you build on top: access control, encryption choices, logging, who can query the database at 2am, and whether the S3 bucket is public.

This is the shared responsibility model, and the split is roughly:

Provider secures	You secure
Physical facilities, hardware	Your data and who can reach it
Hypervisor, host OS	Guest OS, patching (on IaaS)
Network infrastructure	Network config, firewall rules
Managed service internals	Identity, keys, application logic

Almost every publicised "cloud breach" in health has been a customer-side misconfiguration — an open storage bucket, an over-broad IAM role, a database with a default password. The provider was never breached. The line was.

The paperwork that is not paperwork

Under HIPAA, a cloud provider handling PHI is a business associate, and you need a Business Associate Agreement (BAA) in place. Two things people get wrong:

• Not every service is covered. Providers publish a list of BAA-eligible services. Use a shiny new service that isn't on the list and you have moved PHI outside your agreement — a compliance failure created by a single terraform apply.
• The BAA is not automatic. It's a thing you sign. Someone must have actually signed it.

Under India's DPDP Act, the equivalent relationship is data fiduciary → data processor, and the obligations flow through contract in a similar shape.

Data residency — the constraint that shapes everything

This is where health diverges hardest from ordinary SaaS.

A generic startup picks a region for latency. A health system picks one because the law, the contract, or the ministry says the data does not leave the country. Once residency is a hard requirement, a series of consequences follow that are easy to miss until they bite:

• Your DR region must also be in-country — which may mean fewer availability zones than the marketing assumed.
• Managed services are not uniformly available in every region. The India regions do not have everything us-east-1 has, and discovering that mid-build is common.
• Backups, logs and telemetry are data too. A perfectly-resident database that ships its logs to a US-hosted observability vendor has exported the data through the back door — and this is the one teams miss most often.
• Support access matters: can the vendor's engineer in another country see the data while debugging?

Latency is a preference. Residency is a boundary. Design for the boundary first.

Choosing, briefly

Honestly: for most health workloads, all three are fine, and the decision is made by things that have nothing to do with health — existing contracts, your team's skills, which regions exist near you, and price. Azure often wins in hospitals already deep in Microsoft licensing. AWS has the broadest service catalogue. GCP is strong on data and ML.

The health-specific offerings (AWS HealthLake, Azure Health Data Services, Google Cloud Healthcare API) are all essentially managed FHIR servers with ingestion pipelines. They're genuinely useful and they are also a lock-in decision worth making with open eyes: your data model becomes portable FHIR, but your operational surface does not.

The unglamorous truth: your risk is far more likely to come from an IAM policy nobody reviewed than from your choice of logo.