Trade-offs, TCO & cost

Last reviewed: 2026-06-28 — see the freshness policy.

Learning objectives

After this chapter you will be able to:

• Build a back-of-envelope Total Cost of Ownership (TCO) model for a cloud HLS system.
• Identify the HLS-specific cost drivers that surprise teams most often.
• Apply a trade-off framework to common SA choices (build vs. buy, managed vs. self-hosted, multi-region vs. single).

TCO: the three cost buckets

Total Cost of Ownership is the full cost of a system over its lifetime, not just its build cost. In HLS, teams almost always underestimate run cost — especially for managed clinical data services.

flowchart LR
  Build["Build cost<br/>Engineering, tooling,<br/>cloud (dev/staging)"] --> TCO
  Run["Run cost<br/>Cloud infra, licences,<br/>operations, support"] --> TCO
  Opportunity["Opportunity cost<br/>What you cannot build<br/>while building this"] --> TCO
  TCO["TCO"]

• Build cost is usually one-time or per-sprint: engineering hours, tooling licences, cloud spend during development.
• Run cost recurs monthly or yearly: cloud infrastructure, managed-service fees, operational effort (on-call, patching, capacity management), SaaS licences.
• Opportunity cost is invisible but real: while your team builds a custom HL7v2 integration engine, they are not building features. "Build vs. buy" decisions are always trade-offs between build/run costs and opportunity cost.

HLS rule of thumb: managed services shift cost from build+opportunity to run. Self-hosted shifts cost from run back to build. The right choice depends on team capability, volume, and how long the system lives.

HLS-specific cost drivers (the surprises)

These are the line items that regularly blow cloud budgets in healthcare and life science:

The trade-off axes every SA navigates

Architectural trade-offs are not "good vs. bad" — they are "which cost are you willing to pay?"

Build vs. buy

Managed vs. self-hosted

Self-hosting a HAPI FHIR server on Kubernetes costs ~$2–5 k/month in compute + a full-time engineer to operate it at scale. AWS HealthLake costs ~$0.01/read but requires no operational overhead. The break-even point depends on query volume.

Calculate the break-even: if your team's fully-loaded cost is $150 k/year and managed service run cost is $36 k/year, managed wins unless you have compliance constraints that rule out the vendor.

Multi-region vs. single-region

Multi-region active-active maximises availability but roughly doubles cost, triples operational complexity, and introduces data residency complexity (PHI in multiple jurisdictions). For most provider systems (not nationally-scaled payers), single-region multi-AZ with a tested RTO is the right balance.

Latency vs. cost

Caching FHIR reads reduces managed-service costs but introduces cache invalidation complexity and potential staleness — unacceptable for medication lists that must reflect the latest order. Know which data must be real-time and which can tolerate a cache.

Back-of-envelope TCO: worked example

System: FHIR interoperability platform for a mid-size health system (500-bed hospital), 50 k FHIR reads/day.

At 10× volume (500 k reads/day), run cost reaches ~$800/month — still managed wins. At 10 M reads/day you re-evaluate HAPI FHIR or caching aggressively.

Use cloud pricing calculators for real estimates: AWS Pricing Calculator, GCP Pricing Calculator, Azure Pricing Calculator.

Check yourself

1. A team wants to self-host HAPI FHIR to "avoid vendor lock-in." What is the total cost they need to model, and what question should you ask about volume before advising them?
2. You are designing a DICOM image repository. Which WAF pillar and which cost driver is most relevant?
3. A clinical app requires real-time medication data (updated per-order). Is caching an appropriate cost mitigation here? Why or why not?

Further reading

• AWS TCO Calculator
• FinOps Foundation — cloud cost optimisation practices
• AWS FHIR Works pricing
• Snowflake cost management best practices