How to Build a Highly-Available EMR on AWS/Azure (Architecture + Cost Breakdown)

Modern Electronic Medical Records (EMR) systems need to function around the clock with almost no downtime, quick performance, and safe access to patient data. Healthcare IT teams may implement EMRs with redundant infrastructure and elastic scaling thanks to cloud platforms like AWS and Azure. For fault tolerance, a typical cloud EMR has a multi-tier architecture spread over several Availability Zones (AZs).

For instance, deploying web/application servers in two or more AZs behind load balancers with the database replicated across AZs is supported by both AWS and Azure. Every cloud provider offers managed services (storage, networking, databases, and computing) that automatically fail over during outages and mirror data.

As AWS notes in its Healthcare Lens, “medical imaging or EHR systems may require more consistent latency and connectivity compared to other systems”, so redundant network paths and low-latency links (e.g. AWS Direct Connect or Azure ExpressRoute) are used. In actuality, this entails building EMR components (web UI, API, database, storage) to operate actively across AZs so that servers in the other AZs can manage traffic if one datacenter goes offline.

Multi-AZ Architecture Comparison Between AWS and Azure for EMRs

From an architectural standpoint, the two clouds offer very similar building blocks for EMRs:

Compute/Web Tier

• Install several application servers across AZs (Virtual Machines or App Service/AKS on Azure; EC2 or ECS/EKS on AWS).
• An Application Load Balancer (ALB) may be used in conjunction with an Auto Scaling Group of EC2 instances (or Fargate/EKS containers) in AWS.
• Behind an Azure Load Balancer or Application Gateway, two or more virtual machines (VMs) (or a VM Scale Set or Azure Kubernetes Service cluster) are positioned in different zones.
• As one industry analysis notes, both are “excellent hosts for major EHRs” – AWS using EC2 + RDS, and Azure using VMs + Azure SQL.

Database Tier

• Use a high-availability relational database. 
• AWS offers RDS Multi-AZ or Amazon Aurora (Multi-AZ Aurora clusters). 
• Azure offers Azure SQL Database with a zone-redundant “High Availability” configuration or a Managed Instance in an availability group. 
• The primary database replicates synchronously to a standby in a different Arizona in both scenarios.
• (AWS Multi-AZ RDS, for instance, maintains a hot standby in a second AZ.) The standby is automatically promoted in the event that one AZ fails, keeping the EMR accessible.

Storage & Backup

• EMRs generate large volumes of data (patient documents, images, logs). 
• In AWS, this is stored on Amazon S3 (with cross-AZ durability) or EFS/NAS for files, while Azure uses Blob Storage or Azure Files. 
• These durable object storage holds backups and snapshots of the servers and database.
• Since every service is multi-AZ by nature (S3, for example, automatically replicates across AZs), data is secure even in the event that an entire AZ fails.

Networking

• Both clouds use Virtual Networks spanning AZs. 
• Typical patterns include private subnets for app servers and databases, public subnets with NAT gateways to control outbound traffic, and managed firewalls/WAFs at the perimeter. 
• Each AZ has its own NAT gateway (or Azure NAT) so that outbound connectivity remains if one AZ’s NAT fails. 
• Load balancers distribute incoming traffic across instances in all AZs, and DNS can be updated to shift users to a healthy region if needed. 
• (AWS defines an AZ as a “discrete data centre with separate and redundant power, networking and connectivity”, and Azure similarly provides multiple independent zones in each region.)

Monitoring & Logging

• A highly available EMR needs constant health checks. 
• AWS CloudWatch and Azure Monitor can be used to watch server health, latency, and errors. Alarms can trigger scaling or failover. 
• Logging services (CloudWatch Logs, Azure Log Analytics) store audit trails and application logs with geo-redundancy.

AWS’s OpenMRS blog walkthrough underscores this approach: it first shows a simple one-EC2-node deployment, then promises a reference “scalable, resilient, and secure” architecture for production deployments. In practice, that means at least two AZs, load balancers, and Multi-AZ databases. 

Likewise, Azure solution guidance (e.g. for OpenEMR) emphasizes that “Azure provides high availability for OpenEMR hosting, with multiple data centres and redundancy built-in to ensure that data and applications are always available”.

Related: AWS vs Azure for Medical Clinics – Full Comparison

Core AWS vs. Azure EMR Architecture

To put this into concrete terms, consider an example custom EMR deployment on each cloud. The architecture diagrams (textually described here) are largely analogous on AWS and Azure:

Web/Application Servers

• AWS: Launch at least 2 EC2 instances (e.g. t3.large or m5.large for moderate traffic) in separate subnets/AZs. Place them in an Auto Scaling group behind an Application Load Balancer (ALB). The ALB has target groups in each AZ, so traffic is evenly distributed. Alternatively, use AWS Fargate/EKS with a Kubernetes Service of type LoadBalancer.
• Azure: Run 2 VMs (e.g. D2_v3 or D4_v3 sizes) in different availability zones. Put them in a Virtual Machine Scale Set or separate scale sets for horizontal scaling. Front them with an Azure Load Balancer or Application Gateway with a zone-redundant frontend IP. Azure App Service (if used) inherently provides multi-AZ deployment across nodes.

Relational Database

• AWS: For MySQL, PostgreSQL, and SQL Server with Multi-AZ enabled, use Amazon RDS. For instance, in MySQL mode, a db.r5.large instance (2 vCPU, 16GB RAM) costs roughly $0.20/hr (2 vCPU × $0.10/vCPU). AWS keeps a standby instance in a different AZ with Multi-AZ; write I/O is synchronously replicated for quick failover. GP3 volumes ($0.08/GB-month) are used for storage (100–1000GB). As an alternative, you can use Amazon Aurora, which is compatible with both MySQL and PostgreSQL. It offers reader endpoints for scaling and automatically replicates between AZs.
• Azure: Use Azure SQL Database (PaaS). A General Purpose, 2 vCore database with ~20–50GB might cost on the order of $0.30–0.50/hr (roughly $220–$360/month) plus storage fees. Azure SQL offers built-in “zone-redundant” HA, or you can place an Azure SQL Managed Instance in multiple zones with Auto-Failover Groups. Alternatively, you could run SQL Server or MySQL on Azure VMs: for example, a 2‑vCore SQL Server on a D2_v3 VM (which itself is ~$0.096/hr) plus SQL licensing. Both approaches give a multi-AZ/zone redundant database.

Storage & Backups

• AWS: Place bulk data (imaging, PDFs, backups) in S3 buckets. S3 provides 99.999999999% durability with multi-AZ replication, at about $0.023/GB-month for standard storage. Logs and nightly DB snapshots also go to S3. If you need a file share (e.g. for reports), use Amazon EFS (multi-AZ NFS) or FSx for Lustre/ONR. Each EC2 still has local EBS volumes (root disk, temp space, maybe small data volumes) — by default, these are provisioned to survive instance failures but not AZ failures (so they’re usually kept minimal, with persistent data on RDS/S3).
• Azure: Use Azure Blob Storage for bulk data (similar durability, ~$0.018–$0.020/GB-month for hot tier). Cloud backups and snapshots (from SQL or VMs) can target Azure Backup vaults. For shared files, use Azure Files (an SMB/NFS share) with zone redundancy. OS disks of VMs are on Azure Managed Disks (standard SSD or premium SSD) – these persist if the VM stops but are tied to an AZ; critical data should be in higher-level services like SQL DB anyway.

Networking & Redundancy

• AWS: Create a VPC with subnets spread across at least two AZs. The load balancer is located in public-facing subnets, whereas app servers and RDS are located in private subnets. For HTTP traffic, use Elastic Load Balancer (ALB), which is regional and spans AZs; if an AZ’s instances fail, the ALB automatically reroutes to healthy ones. For outgoing traffic, offer a NAT gateway or NAT instance per AZ; for hybrid connections, utilize an AWS Transit Gateway/VPN. Due to their complete isolation (separate power/seed network) and high-bandwidth connections, AWS AZs provide minimal latency and synchronous replication. Route53 (DNS) can do weighted or failover routing to switch between regions if doing active-active multi-region.
• Azure: Use a Virtual Network (VNet) peering across zones or a single VNet that stretches across AZs. Deploy an Azure Load Balancer (or Application Gateway) with a frontend IP that is zone redundant. Each VM subnet exists in each zone, and you put one NAT Gateway (zone redundant) or one per subnet for internet egress. Azure’s Availability Zones are similarly independent datacenters with isolated infrastructure. Azure also supports geo-redundancy via paired regions. As on AWS, you can use ExpressRoute/VPN for on-prem connectivity.

High Availability Features

• Run all components in at least 2 AZs. Use Autoscaling (with health checks) so that if a server fails, a new one is launched in that AZ or another. Enable Multi-AZ for RDS/Azure SQL. For compute clusters (EKS/AKS), ensure multiple nodes in each zone. Use health probes on load balancers (ALB or Azure LB) to remove unhealthy instances immediately.
• Optionally, set up an Active-Active multi-region DR plan: replicate your database across regions (Aurora global DB or Azure SQL Geo-Replicas) and duplicate front-end stacks in a secondary region. This is beyond “high availability” and falls under disaster recovery, but the cloud makes it straightforward (e.g. cross-region S3 replication, or Azure Geo-Zone-Redundant Storage).
  

Both clouds provide managed services for scaling and resilience. For example, Azure offers Scale Sets that can automatically expand virtual machines (VMs) across zones, and AWS offers Auto Scaling Groups (no additional cost, just pay for EC2). Logging and monitoring are completely integrated: track latency, failures, CPU/memory, etc., and initiate auto-healing activities using AWS CloudWatch and Azure Monitor/Application Insights.

Crucially, because the platform manages node replacement and data failover, you rarely need to create complicated failover logic yourself, thanks to these cloud-native patterns.

Comparing Architectures: AWS vs Azure

Although AWS and Azure use different names, the architecture patterns for an HA EMR are parallel. In summary:

• Compute: EC2 (AWS) vs Virtual Machines or PaaS (Azure). Both support container orchestration (EKS/Fargate vs AKS) and serverless (Lambda vs Functions) if you want to go cloud-native.
• Database: RDS/Aurora (AWS) vs Azure SQL/Managed Instances. Each can be set to synchronous multi-AZ mode. AWS also has DocumentDB (Mongo-compatible) or DynamoDB if a NoSQL EMR is acceptable; Azure has CosmosDB.
• Load Balancing: AWS Application Load Balancer (or Gateway Load Balancer) spans AZs; Azure Load Balancer or Application Gateway does the same. Both charge per hour plus a small data-processing fee.
• Storage: S3/Glacier (AWS) vs Blob Storage/Archive Tier (Azure). S3 standard is about $0.023/GB-month; Azure Blob Hot is about $0.018–0.020/GB-month. For long-term archiving, AWS S3 Glacier Deep Archive is ~$0.00099/GB (night-to-week retrieval) and Azure Archive is ~$0.00099–$0.002/GB. Both platforms lock data in for 180+ days at this tier.
• Networking Charges: Both have data transfer and NAT charges. AWS NAT Gateway is $0.045 per hour per NAT plus $0.045/GB for traffic. Azure NAT Gateway is similar ($0.045/hr). Data egress (to the internet or between regions) is billable on both sides, though intra-zone traffic is free.
  

A major difference is licensing: if your EMR is Microsoft-based (e.g. SQL Server back-end, or Windows app), Azure’s pricing model (e.g. Azure Hybrid Benefit) can yield discounts. The CapMinds clinic comparison points out that for a typical clinic scenario (SQL-based EHR + 5 TB imaging), AWS might cost $1,200–$1,800 per month, while Azure is $1,100–$1,700 per month. 

In that analysis, AWS pricing used EC2 and S3, whereas Azure used VMs plus Blob storage. The takeaway is that costs are often comparable if architectures are similar. (Azure can be cheaper if you already own Windows/SQL licenses, due to hybrid use benefits; AWS can win on deep-archive storage costs.)

Example Cost Breakdown (Rough Monthly)

Here’s a notional monthly cost example for a mid-size EMR deployment in a single region. Actual costs will vary by region, instance sizes, and usage patterns, but this illustrates the breakdown:

AWS (US-East-1, On-Demand)

• 2 × t3.large EC2 Linux (2 vCPU, 8 GB) for web/API servers: ~$61 × 2 = $122/month.
• 1 × db.r5.large Multi-AZ RDS for MySQL (2 vCPU, 16 GB): ~$0.20/hr × 720 = $144/month (single-AZ). Multi-AZ effectively doubles this (adds standby).
• 100 GB gp3 EBS for DB ($0.08/GB-month): $8/month.
• ALB (application load balancer): $18–$20/month (base hourly fee plus a bit for traffic).
• 2 × NAT Gateways (one per AZ) @$0.045/hr: $65 × 2 = $130/month.
• Elastic IPs (for NATs): $3.60/month each → $7.20.
• S3 Storage for backups & images (5 TB @ $0.023/GB): $115/month. (Use Glacier for older data to save.)
• CloudWatch & data transfer: $20–$50/month (rough estimate for logs/metrics and moderate outbound).

Total AWS (approx): $550–$700 per month (assuming minimal I/O and moderate traffic). (Note: RDS Multi-AZ with standby roughly doubles the instance cost to ~$288/mo.)

Azure (East US, Pay-As-You-Go)

• 2 × D2_v3 VMs (2 vCPU, 8 GB) Linux: $0.096/hr × 730 × 2 = $140/month.
• Azure Load Balancer (Standard LB): $18/month (plus small outbound data fees).
• Azure Database for MySQL/PostgreSQL, General Purpose 2 vCore: approx $200–$300/month (includes storage). Or Azure SQL DB (2 vCore GP) ~$360/month.
• 100 GB Premium SSD (Managed Disk) for any VM data: $12/month.
• NAT Gateway: $64/month (at $0.045/hr).
• Blob Storage (Hot) for 5 TB: $0.018/GB × 5120 = $92/month. (Cool/Archive tiers could cut costs in half if cold data.)
• Monitoring & Backup (Azure Monitor + Vault): $20–$40/month.

Total Azure (approx): $600–$800 per month.

These figures line up with the CapMinds estimates: AWS $1.2–1.8K vs Azure $1.1–1.7K for a similar EHR setup. Of course, a larger EMR with more users, compute-heavy analytics, or multi-region DR would be higher. But the structure of the bill—web servers, DB service, storage, network—mirrors between AWS and Azure, so architects can do a side-by-side comparison once the architecture is set. Both clouds also offer pricing calculators to refine estimates (AWS Pricing Calculator, Azure Pricing Calculator).

For commercial EMR products (e.g. Epic, Cerner) or open-source EMRs (like OpenEMR/OpenMRS), the cloud architecture is similar. Instead of custom code, you deploy the vendor’s application image or container, but still use ELB/ALB, multiple servers, and a resilient database. For example, AWS and Epic have co-authored a blueprint for “Epic on AWS” following this model. 

The difference lies in licensing and support: vendor software may have its own licensing costs and may recommend certain instance sizes. But technically, a vendor EMR stack is just another 3-tier application as far as AWS/Azure are concerned. In both scenarios (custom or packaged EMR), multi-AZ deployment and managed backups are best practices. Indeed, AWS highlights that “the longest track record of uptime” and the “unmatched variety of services” make it a reliable choice, while Azure offers “seamless integration” with existing Microsoft tools and hybrid cloud.

CapMinds Cloud Deployment & EMR Modernization Services

Building a highly available EMR on AWS or Azure is only the first step—achieving long-term reliability, scalability, and cost efficiency requires the right healthcare technology partner. CapMinds delivers end-to-end Digital Health Tech Services designed to help healthcare organizations deploy, optimize, and manage cloud-based EMR systems with confidence.

With deep expertise in EMR cloud architecture, multi-AZ deployments, and secure healthcare data management, we help you move from complex infrastructure to seamless clinical operations. Our team ensures every layer—compute, database, networking, storage, monitoring, and backups—is fully optimized for HIPAA-compliant, 24/7 performance.

At CapMinds, our services include:

• Cloud EMR Deployment & Migration (AWS/Azure)
• Compute & Kubernetes (EC2, EKS, AKS, App Service)
• Database Management (RDS, Aurora, Azure SQL)
• S3/Blob Storage Architecture & Backup Automation
• Network, Load Balancer & Security Hardening
• Monitoring, Logging & Cost Optimization Services
• Custom EMR/EHR Development, Integration & Support…and more
  

Partner with CapMinds to build a future-ready, highly available EMR ecosystem that empowers providers, protects patient data, and scales as your practice grows. 

Let’s modernize your healthcare technology—together.

Contact Us