1 Yes, in many cases a PACS or VNA archive can run on S3 object storage, and a growing number of hospitals already do it. Many modern PACS, VNA and enterprise imaging platforms can write their long-term archive to S3-compatible storage, either natively or through an intermediate layer. The real questions are how the integration works for your specific products, whether retrieval performance meets clinical expectations, and how to handle the details that make imaging different from other workloads: very large numbers of small DICOM files, long retention, strict integrity requirements and ransomware risk. This article explains how PACS on S3 object storage typically works, what to evaluate and how to test before committing. For the broader imaging storage picture, see our hub on PACS and VNA storage. Why hospitals look at object storage for imaging Imaging archives share the characteristics that object storage was designed for: Massive scale, often hundreds of terabytes to petabytes, growing every year. Write once, read occasionally: images are never modified after acquisition, and most older studies are rarely read. Long retention, so the archive outlives several hardware generations. High durability requirements, since a lost or corrupted image is a clinical and legal problem. Object storage scales out by adding nodes, protects data with erasure coding across nodes and sites, supports immutability through object lock and allows hardware to be refreshed without migrating the archive. Traditional NAS and SAN archives tend to hit scale limits and require disruptive migrations at refresh. See object storage vs traditional storage. How PACS and VNA integrate with S3 Native S3 support Many current VNA and enterprise imaging products, and some PACS, can use an S3 bucket as an archive tier directly. The application writes studies or instances as objects and keeps its own database of what is stored where. This is the simplest and most scalable model when supported. Tiering from file to S3 Some products keep recent studies on file storage and move older studies to S3 based on age or access. The application manages the tiering and recalls studies when needed. This combines fast local access for current work with scalable long-term capacity. File gateway Where an application only supports file protocols, a gateway can present S3 storage as an NFS or SMB share. This can work for archive tiers but adds a component to size, manage and protect, and performance depends on the gateway’s caching. Through a VNA In many hospitals, departmental PACS keep only short-term storage and send everything long-term to a VNA, which in turn uses S3. The PACS never talks to object storage directly. See PACS vs VNA: what changes for the storage team. Always confirm the supported model and versions with each vendor. S3 support can differ between product versions and editions. Performance: will radiologists notice? Reading performance depends mainly on the PACS short-term cache, which usually remains on fast storage. Object storage matters for: Prior retrieval when older studies are needed for comparison. Prefetching, when the system pulls priors in advance of scheduled exams. Ad hoc retrieval of older studies by clinicians or for second opinions. Bulk access for migrations, research or AI model validation. On-premises object storage on a hospital network can deliver retrieval in seconds for typical studies, provided the platform and network are sized correctly. Prefetching hides most latency for scheduled work. Public cloud archives can add network latency and retrieval or egress charges, so test real retrieval times and costs. Small files and object counts A single CT or MR study may contain hundreds or thousands of individual DICOM instances. Stored one object per instance, a large archive can hold billions of objects, many of them small. Some applications bundle instances into larger study-level objects to reduce counts and improve efficiency. When evaluating storage, check: How the application maps DICOM instances or studies to objects. The object storage platform’s ability to handle billions of objects with consistent performance. Small-object write and read rates during peak acquisition and prefetch. Delete performance, for when retention-based deletion begins. The scality.com blog covers S3 request performance factors that apply here. Integrity and durability Images must remain exactly as acquired for their entire retention period. Object storage platforms typically store checksums for every object and verify them in the background, repairing silent corruption from other copies or erasure-coded fragments. Combined with application-level checks, this provides strong integrity assurance over decades. See data durability in high-density storage systems and the scality.com post on object storage integrity verification. Immutability and ransomware protection Healthcare is heavily targeted by ransomware, and image archives are an attractive target. Object lock can make archived studies immutable for a defined period, preventing deletion or encryption even by someone with administrative credentials. Points to check: Whether the PACS or VNA supports writing with object lock, or whether immutability is applied at the bucket level. How retention periods align with clinical retention policy. How legal holds and eventual deletion are handled. Whether at least one copy is isolated from general IT credentials. See S3 object lock: immutability and WORM and ransomware-proof backup. Disaster recovery Object storage makes DR for imaging simpler. Common designs replicate buckets to a second site, use a platform that spans sites, or keep an immutable copy in a separate environment. The PACS or VNA database must also be protected and recoverable, since the archive is only useful if the application knows where each study is. Test recovery of both together. Security and compliance Imaging archives hold protected health information. Requirements include encryption at rest and in transit, role-based access, audit logging and, for public cloud, a business associate agreement and clarity on data location. On-premises object storage keeps images within the hospital’s own facilities, which simplifies residency questions. See HIPAA compliant storage. Cost considerations Object storage on standard servers usually lowers the cost per terabyte of long-term archives compared with traditional arrays, especially at scale, and avoids migration projects at hardware refresh. In public cloud, include retrieval and egress costs for priors and migrations, request charges and the long-term cost of a growing archive. Model costs over at least ten years. See the cost of health data retention. How to test before committing A pilot should prove that the integration works in your environment: Confirm the exact PACS, VNA and version combination is supported for S3. Archive a representative set of studies across modalities. Measure retrieval times for priors, including large CT, MR and tomosynthesis studies. Test prefetch behavior during a normal clinical day. Simulate a storage node failure and confirm retrieval continues. Test object lock behavior and deletion at end of retention. Recover the archive and application database at a DR site. Verify integrity of retrieved studies against originals. Migrating an existing archive to S3 Moving historical images from NAS or a vendor archive to S3 usually happens through the PACS or VNA, which reads studies from the old storage and writes them to the new tier. Plan for temporary double capacity, sustained read load on old storage, network bandwidth and verification of every study. Starting with new studies going straight to S3 and migrating older data in the background reduces risk. See cold data migration strategy. Checklist: PACS on S3 object storage Confirm S3 support model and versions with each imaging vendor. Keep fast short-term storage for current reading. Size object storage for capacity, object count and small-object performance. Measure prior retrieval and prefetch performance in a pilot. Use object lock and isolated copies for ransomware resilience. Replicate to a second site and protect the application database. Ensure encryption, access control and audit logging. Model ten-year cost, including refresh and any cloud fees. Plan migration with verification of every study. Putting it together PACS on S3 object storage is a proven pattern when the imaging application supports it and the storage platform is sized for imaging’s scale, object counts and retrieval needs. Keep fast storage for current reading, place the long-term archive on scalable, immutable object storage and test retrieval, failure and recovery before committing. The payoff is an archive that grows without forklift upgrades, survives ransomware and outlasts the next PACS replacement. Frequently asked questions Can PACS store images on S3? Many modern PACS, VNA and enterprise imaging products support S3-compatible storage for long-term archives, natively or through tiering or gateways. Confirm with your vendor. Is S3 storage fast enough for radiology? Reading typically uses the PACS short-term cache. For priors from the S3 archive, properly sized on-premises object storage can retrieve typical studies in seconds, and prefetching hides most latency. How are DICOM files stored in object storage? Either as one object per DICOM instance or bundled into larger study-level objects, depending on the application. Can object storage make medical images immutable? Yes. Object lock can prevent deletion or modification for a defined retention period, protecting against ransomware and mistakes. Is cloud or on-premises S3 better for imaging? Both can work. On-premises avoids retrieval and egress fees and keeps data local; public cloud avoids running infrastructure. Many hospitals keep the primary archive on premises and use cloud or a second site for DR. Further reading See PACS and VNA storage, PACS vs VNA storage, medical imaging storage growth, medical image retention and HIPAA compliant storage.
