Skip to content

AWS 2026-09-17

Read original ↗

AWS — Building cloud-native PACS on AWS

Summary

An AWS Architecture Blog reference-architecture post for modernizing hospital-chain medical imaging infrastructure by re-hosting a PACS (Picture Archiving and Communication System) as a cloud-native, hub-and-spoke hybrid architecture on AWS. Local PACS instances at each hospital (spokes) keep serving daily reads at LAN speed while asynchronously replicating imaging studies to a centralized cloud archive (hub) over Direct Connect or Site-to-Site VPN. The centralized deployment spans two Availability Zones (EC2 web/VNA/app tiers behind NLBs, Aurora PostgreSQL metadata store), with all DICOM pixel data on Amazon S3 under lifecycle policies that tier by access age, and a teleradiology viewer delivered through CloudFront + WAF. The post's central design lever is mapping medical imaging's predictable decline in access frequency onto S3 storage classes to break the on-prem SAN/NAS cost model.

Key takeaways

  1. Medical imaging is an ideal tiered-storage workload because access frequency decays predictably. Studies are hot in the first 6–12 months (reporting, follow-ups), drop sharply after 6–12 months, and are rarely accessed after 2–3 years — so mapping age to S3 storage classes is "a high-impact cost optimization decision". (Source: article, "Storage tier planning")
  2. Hub-and-spoke, single-vendor-everywhere is what enables cross-facility interoperability. Because every site AND the cloud archive run the same PACS sharing a common metadata database, a radiologist at one hospital can query and open a study acquired at any other — a unified enterprise patient imaging record. This requires vendor consistency across all sites. (Source: article, "Architecture flow")
  3. Replication is asynchronous so clinical workflow is never blocked. New studies land on the local VNA at LAN speed and are replicated to S3 in the background over Direct Connect / Site-to-Site VPN. (concepts/asynchronous-replication) (Source: article, "In the background... replicated to Amazon S3")
  4. Transparent dual viewer routes by image location. The PACS viewer checks the metadata DB for image location; locally cached studies (the majority of daily requests) serve at LAN speed, expired ones stream from S3 via CloudFront with progressive loading — the clinician "remains unaware of the backend source". (concepts/cache-hit-rate) (Source: article, "Transparent viewer experience")
  5. The six PACS components are re-hosted, not replaced. Web Server, VNA Server, Application server, Database, Object Storage, and PACS Viewer persist across any deployment model; cloud migration re-hosts and enhances them (S3 replaces SAN/NAS; Aurora holds metadata; CloudFront delivers the viewer). (Source: article, "Key components")
  6. S3 storage-class ladder mapped to imaging age: S3 Standard for active studies (<6–12 mo, millisecond access ≈ local SAN); S3 Glacier Instant Retrieval for occasional comparative reads of 6–12+ mo studies (millisecond retrieval at archive pricing, nominal retrieval fee); S3 Intelligent-Tiering for unpredictable access (research/teaching hospitals — auto-tiers, no retrieval fee); S3 Glacier Deep Archive for >5 yr retention (12–48 h retrieval, minimal cost). (Source: article, "Storage tier planning")
  7. Built-in durability + DR from S3 semantics. S3 replicates every object across multiple AZs within a Region; Cross-Region Replication (CRR) gives a full DR copy in a second Region with no extra infra. Most modern PACS natively support S3-compatible APIs, so "no custom middleware" is needed. (Source: article, "Why this matters for PACS")
  8. HA failure spectrum: local server fails → requests route to the cloud (recent data already synced); cloud connectivity drops → local cache keeps serving recent studies; single AZ fails → automatic NLB failover to the surviving AZ within seconds. (concepts/regional-failover) (Source: article, "High availability and disaster recovery")
  9. Security under the shared responsibility model: encryption at rest + in transit at every layer, KMS key management with rotation, CloudTrail + S3 access-log audit, least-privilege IAM RBAC, continuous AWS Config monitoring. Regional deployment + S3 bucket policies enforce data residency for sovereignty requirements. (concepts/data-residency) (Source: article, "Data protection and security controls")
  10. Cloud-only vs hybrid is decided by connectivity + vendor, NOT volume. Cloud-only fits when there is redundant multi-carrier high-bandwidth connectivity AND the vendor offers a cloud-optimized solution (some vendors publicly demonstrate faster-than-on-prem retrieval). Hybrid fits when connectivity is limited/single-carrier OR the vendor is local-cache-optimized. Both use AWS as the durable long-term archive — the difference is where the active working set lives. (Source: article, "Cloud-only vs. hybrid")

Operational numbers

  • Per-study image counts: CT 300–2,000 DICOM images; MRI 500–3,000 slices; digital mammography 8–12 high-res images.
  • A multi-hospital chain accumulates 50–200 TB of new imaging data yearly, with 7–10 year retention mandated.
  • On-prem SAN/NAS refresh cycle 3–5 years; annual maintenance contracts consume 15–20% of hardware cost.
  • Access-frequency decay: frequent first 6–12 mo → sharp drop after 6–12 mo → rarely accessed after 2–3 years.
  • S3 Glacier Deep Archive retrieval latency 12–48 hours.
  • Cloud deployment spans 2 Availability Zones with automatic NLB failover "within seconds".

Systems / concepts / patterns extracted

Caveats

  • This is a reference-architecture / guidance post, not a production retrospective — no throughput, latency, or dollar cost figures for a real deployment; per-study and per-chain numbers are illustrative planning ranges.
  • The single-vendor-everywhere requirement is a hard constraint of the centralized model: heterogeneous-vendor estates do not get the unified cross-facility record from this pattern.
  • Security section is explicitly "controls healthcare organizations can use as part of their security programs" — not a compliance attestation; HIPAA/GDPR posture is the customer's responsibility under the shared responsibility model.

Source

Last updated · 766 distilled / 2,225 read