In short: AWS HealthLake, Google Cloud Healthcare API and Azure Health Data Services are solid managed FHIR stores, built for organisations already on that cloud and handling large volumes. A small team building a patient app often finds two surprises: the bill starts before the first user (AWS lists an always-on data store at about $0.27 an hour, roughly $194 a month), and the parts patients see (accounts, consent, an approval screen, a log of who read their data) are still to build. The alternatives trade some cloud integration for less to build.
At a glance
| Already on AWS, large data | AWS HealthLake: analytics and NLP built in |
|---|---|
| Already on Google Cloud | Google Cloud Healthcare API: FHIR, HL7 v2 and DICOM stores |
| Already on Azure | Azure Health Data Services |
| Full control, no licence | HAPI FHIR or self-hosted Medplum |
| Patient app with consent, no infrastructure | Anpheros Platform: free sandbox, production from €99 a month |
| Moving later | All speak FHIR R4; Bulk Data export moves the data |
The big-cloud FHIR services answer "where do I store FHIR data at scale". A small team usually asks something else: "how do I give patients a record that my app, their clinic and their AI assistant can read, with their permission". This page separates the two and names the alternatives. Anpheros Platform is one of them; we say where the big clouds are the better choice.
What the big-cloud FHIR services include
All three give you a managed FHIR R4 store with search, import and export, inside the cloud's identity, logging and compliance programmes. AWS HealthLake adds medical NLP and analytics exports; Google Cloud Healthcare API has FHIR, HL7 v2 and DICOM stores with de-identification and BigQuery export; Azure Health Data Services adds DICOM and MedTech device ingestion. They suit hospitals, payers and data platforms.
What a small team still builds
A FHIR store is not a patient product. On top of it you build patient sign-up and identity, linking a person to their Patient resource, a consent model (which app sees what, for how long), a screen where the patient approves or revokes, an access log the patient can see, SMART on FHIR app authorisation for third parties, and a way to bring in results from labs and clinics. That is months of work and the part regulators and users look at most closely.
What it costs before the first user
AWS HealthLake bills the data store per hour while it exists: AWS's own example is 720 hours at $0.27, about $194 a month for one store, before storage and queries beyond the included amounts. Google Cloud and Azure bill mainly by storage and requests, with costs that grow with use; add the services around the store (identity, networking, logging). Check each provider's calculator for your volume.
The alternatives
Medplum and Aidbox are FHIR platforms you can run in your own cloud or use hosted, with more application features than a bare store; they fit teams building clinical software (Medplum Alternatives: Managed FHIR Backends Compared). HAPI FHIR is free and open source; you run everything. Anpheros Platform is a managed FHIR R4 API that includes the patient side: consent per app, scope and duration, a patient-visible access log, SMART on FHIR, the International Patient Summary, a FHIR MCP server for AI agents, and EU hosting. It has a free sandbox with 30 synthetic patients, and production starts at €99 a month for 2,500 stored patients with the first month free.
Comparison table
| AWS HealthLake | Google Cloud Healthcare API | Azure Health Data Services | Medplum / Aidbox | HAPI FHIR | Anpheros Platform | |
|---|---|---|---|---|---|---|
| Best for | AWS teams, analytics at scale | Google Cloud teams, FHIR + HL7 v2 + DICOM | Azure teams, devices and imaging | Building clinical software | Full control | Patient and clinic apps, AI products |
| Patient consent and approval screen | Build | Build | Build | Build with access policies | Build | Included |
| Patient-visible access log | Build | Build | Build | Build | Build | Included |
| EU hosting | EU regions | EU regions | EU regions | Your cloud or hosted | Where you run it | By default |
| Cost before first user | Always-on store, about $194 a month | Low; grows with use | Low; grows with use | Licence or hosting | Your servers | Free sandbox |
| AI agents (MCP) | Build | Build | Build | Community / build | Build | Included |
Details for products other than Anpheros are as published by their makers in November 2026; check current pricing before deciding.
How to choose
Stay with your cloud's FHIR service if you are already there, handle large volumes and have the team to build the patient side. Choose Medplum, Aidbox or HAPI FHIR if you want to own the platform. Choose Anpheros Platform if the product is a patient app, a small clinic or an AI tool that needs consented access to a record in the EU and you would rather not build consent and infrastructure first. With FHIR R4 everywhere, moving later is a data export, not a rewrite.
Related pages
- Medplum Alternatives: Managed FHIR Backends Compared: Medplum alternatives compared.
- Free FHIR server for development: a sandbox with 30 synthetic patients and six months of history: free FHIR servers and sandboxes.
- FHIR Bulk Data Export ($export) Explained: moving data with FHIR Bulk Data export.
- FHIR platform as a backend: what a FHIR backend as a service gives you, and what it does not: what a FHIR platform does.
Sources
- AWS HealthLake pricing
- Google Cloud Healthcare API
- Azure Health Data Services
- HAPI FHIR
- Anpheros Platform pricing
Frequently asked questions
How much does AWS HealthLake cost?
AWS lists the data store at about $0.27 per hour while it exists, roughly $194 a month for one always-on store, with import and the first 10 GB of storage included, and extra charges for more storage, queries and export. Use the AWS pricing calculator for your volume.
Is Google Cloud Healthcare API cheaper than AWS HealthLake?
For small volumes usually yes, because Google bills mainly by storage and requests rather than an hourly store. At scale it depends on your query and storage pattern; compare with each provider's calculator.
What do I still need to build on a managed FHIR store?
Patient accounts and identity, linking a person to their record, consent per app and scope, an approval and revocation screen, a patient-visible access log, SMART on FHIR authorisation for third-party apps, and data intake from labs and clinics.
Can I start on one FHIR service and move later?
Yes. All of them support FHIR R4, and the Bulk Data export moves resources between servers; plan for mapping custom extensions and identifiers.
Try it free in the sandbox
Your first FHIR call in 5 minutes. An HL7 FHIR R4 API with the patient's consent built in: try it in the sandbox, then connect your own app or clinic system.
Free · 30 synthetic patients · no card
Anpheros builds a medical record that the patient controls and can share with any clinic, on an HL7 FHIR R4 platform, based in the EU. These guides help you understand and organise your health; they do not replace your doctor.
About Anpheros →
AnpherosThe more you log, the clearer your record
Your health history in one place, under your control.
Free · Works in your browser · No card
