Air-Gapped Storage Architecture with S3-Compatible Backends

Air-gapped storage used to be the thing a handful of defense contractors and banks worried about. It has since become a mainstream design question for anyone running serious infrastructure, because two separate problems hit at the same time and turned out to need the same fix.

The first is ransomware, and the numbers are blunt. Veeam found that 89% of ransomware victims in 2025 had their backup repositories specifically targeted, and a large share of those backups ended up modified or deleted by the time anyone noticed. A backup that an attacker can reach is a backup in name only. If the repository sits on the same network as everything else, it's a second target with a bigger blast radius, not a recovery plan. The second pressure is regulatory: the EU AI Act took effect in 2024, stacking a new layer of compliance on top of data-residency rules that already existed in plenty of jurisdictions. Together, these two pressures turn air-gapped storage from a checkbox for auditors into the thing standing between a company and a very bad week.

There's a concrete version of this already running in production. In a regulated manufacturing environment, models train and fine-tune on proprietary process data, batch records, and equipment history entirely inside an air gap. No training data ever leaves the premises. It's a working deployment, and it's a useful preview of the stakes: the data in question took years to accumulate, and losing it isn't a footnote in an incident report.

What an Air Gap Means

People use "air-gapped," "isolated," and "immutable" like they're interchangeable. They're not, and mixing them up is how organizations end up building something weaker than they think they built.

For a physical air gap, a backup gets written to tape or removable media, and then it is physically disconnected. Ransomware can't reach what isn't plugged in, though recovery is slow and someone has to manage the media by hand. A logical air gap is different: it's a copy kept in a separate account, subscription, or isolated storage namespace, where the credentials and systems used for daily operations simply can't reach it. The isolation here comes from access control rather than pulling a cable. N2WS's 2026 analysis draws a clean line between the two: AWS Backup's logically air-gapped vault is a genuinely useful managed feature, but practitioners classify it as a strong logical gap rather than a true air gap. For a true gap, the copy has to physically leave the cloud environment it's protecting.

Immutability gets folded into this conversation too, and it shouldn't be treated as the same thing. S3 Object Lock running in WORM mode stops data from being deleted or altered for a set retention period. It does nothing to stop an attacker from reading or exfiltrating that data, and it creates no network separation at all. Immutability locks the door from the inside. An air gap means the building isn't on the same street.

Air-gapped storage still has to connect to a network during backup windows, and during that window it's briefly exposed. Isolation alone leaves a gap (pun very much intended) that only immutability closes. Neither one is optional, and neither substitutes for the other. A well-designed architecture needs the separation and the WORM lock, stacked, because each one shuts down an attack path the other leaves open.

The S3 API as Connective Tissue

Air-gapped storage needed a common language, and it got one almost by accident: the S3 API, originally built for Amazon's public cloud, turned out to be exactly what offline, disconnected infrastructure needed too.

S3 decouples the logic of a pipeline from the physical location of the endpoint. Backup software, SDKs, and training pipelines built against S3 don't care where the bucket lives. They can be pointed at a new endpoint with swapped credentials and keep working, whether the storage sits in a public cloud region or inside a locked server room with no internet connection at all.

For AI training specifically, this isn't a minor convenience. The entire data path in a typical pipeline, data landing in object storage, getting staged into a working set, checkpoints flowing back out, is already shaped around S3 semantics. If an air-gapped backend speaks the same API, that whole pipeline keeps running inside the perimeter without a rewrite. Teams don't have to retrain their tooling just because the storage moved behind a locked door.

The same property also solves a harder problem: cross-cloud replication for a true air gap. For a real air gap, you copy data into storage the organization controls somewhere else entirely, a different cloud, or on-premises hardware. S3 compatibility is what makes that copy actually usable once it lands there, readable by standard recovery tools without someone writing a custom adapter for every vendor's quirks. Without a shared API, every air-gapped copy would need its own bespoke recovery tooling. With it, the copy just works like any other S3 bucket, because, mechanically, it is one.

The performance problem air-gapped S3 backends must solve for AI workloads

Isolating the data is only half the job. The other half is making sure GPUs don't sit there twiddling their thumbs waiting for it, and air-gapped setups have to solve that problem without any of the elastic scaling tricks hyperscale clouds use to paper over it. There's no "just spin up more bandwidth" button when the whole point is that nothing reaches outside the perimeter.

Meta's engineering teams reported that storage bottlenecks are a primary cause of GPU stalls, and they said researchers lose real time just moving datasets around as training sets grow and GPU clusters spread across regions. The gap between doing this well and doing it badly is not subtle. If I/O is poorly configured, GPUs average well under half utilization, but an optimized setup keeps them running close to full tilt. A poorly configured cluster leaves an expensive space heater instead of a working GPU cluster.

The fix taking shape across on-premises, air-gapped deployments as of April 2026 is a layered storage stack: an NVMe hot tier for active data, an S3-compatible warm tier underneath it, and archival cold storage further down. NVIDIA is also attacking this at the protocol level rather than just throwing faster disks at it. Its RDMA client and server libraries speed up object storage transfer directly, and they've already been integrated by Cloudian HyperStore, Dell ObjectScale, and HPE Alletra Storage MP X10000 for S3-API-based object storage. That's the protocol doing the heavy lifting instead of brute-force hardware.

For anyone sizing one of these systems, the 2026 planning heuristic is about 4 GB/s of read bandwidth per GPU for high-resolution or data-heavy training workloads. That's the number architects are actually designing against, not a rule of thumb pulled from a textbook.

The components of a working air-gapped S3 architecture

A working air-gapped S3 setup isn't one appliance someone bought and plugged in.

Network segmentation is the isolation layer, and it's what actually enforces the air gap. The storage endpoint stays unreachable from the production network except during controlled backup windows. This is a question of network architecture rather than a product someone can buy off a shelf.

S3 Object Lock in WORM mode is the immutability layer, sitting on top of that isolation. It closes the exact gap isolation leaves open: the brief window, during a backup run, when the system is connected and theoretically reachable. Separate from both of those is the durability layer: erasure coding and replication inside the air-gapped environment, protecting against a drive failing or a node going down, a concern that has nothing to do with network isolation and needs solving on its own terms.

Then there's tiering, which is about matching storage type to how data actually gets used. NVMe handles active training data and checkpoints that need speed. S3-compatible object storage handles the warm working set. If data needs to sit around for years, tape or archival storage handles it. This three-tier pattern is already standard in production: data lands in object storage because it's cheap, gets staged onto NAS for the training-time working set, and touches block storage briefly for checkpoint writes. Collapsing all three into one undifferentiated pool under a single operating system sounds efficient on a slide deck, but it erases the protocol boundaries that keep each tier doing its actual job, and it tends to multiply management overhead rather than cut it.

Named on-premises and air-gapped S3-compatible backends

The backend you pick for the S3-compatible warm tier isn't a cosmetic choice. It shapes durability, how far the system scales, and whether it satisfies the compliance rules driving the whole project in the first place. The right pick depends on how long data needs to be retained, how big the deployment needs to get, and whether the workload needs tape integration, a simple backup appliance, or a distributed software layer doing the heavy lifting.

Spectra Logic's BlackPearl is an S3-compatible object gateway built for petabyte-to-exabyte scale, pairing native object storage with integrated tape and cloud tiers. It supports immutable copies and air-gapped archival strategies, using tape-based preservation to guard against ransomware, accidental deletion, and long-term data loss. It's compatible with Amazon's S3-compatible APIs and the Amazon S3 Glacier API.

Object First's Ootbi is a different animal entirely: an S3-ready, Veeam-optimized on-premises backup appliance, available in 64, 128, or 192 TB configurations, with clusters scaling up to 4 nodes and 768 TB total. It's built specifically for backup duty, and that narrow scope for AI training is a feature. It's a toaster, not a kitchen.

Cloudian HyperStore is software-defined, S3-compatible object storage built for enterprise-scale distributed deployments, and it has full API compatibility with Amazon S3 and support for hybrid cloud setups. It also carries the RDMA integration mentioned earlier, so it has a direct performance edge for AI workloads specifically.

The open-source side of this map has shifted recently, and it's worth tracking. The previously dominant free self-hosted option had its community edition stripped down, and its open-source repository was archived and made read-only by April 2026, so teams that built on it now have to look elsewhere. RustFS, Ceph RGW, and SeaweedFS are the names filling that gap now. RustFS stands out for metadata-heavy workloads, things like reading Iceberg manifests or listing partitions, because Rust's zero-cost abstractions sidestep the garbage-collection pauses of Go or Java-based systems.

Red Hat OpenShift AI rounds this out at the platform level. It supports on-premises, hybrid cloud, and fully disconnected, air-gapped deployments, covering model serving, training, and GPU-as-a-service. It's not plug-and-play, though. Air-gapped dependency management means mirroring the operator and model catalogs carefully ahead of time, and that upfront investment is the price of entry.

Where S3 API compatibility breaks down for air-gapped pipelines

"S3 compatible" sounds like a yes-or-no label. It behaves more like a dial, and the distance between a basic SDK connection and a fully functioning production workflow is exactly where air-gapped migrations quietly rack up cost and downtime.

Every vendor on the list above handles the basic verbs: PutObject, GetObject, DeleteObject. That part works everywhere, so it tells you almost nothing about whether a migration will go smoothly. The real breakage occurs one layer deeper, in lifecycle rules, Object Lock modes, S3 Select, and bucket logging, where syntax varies from vendor to vendor and code written against AWS doesn't just drop into an alternative without rework. Roughly a third of the full S3 API surface is made up of vendor-specific extensions, things like event notifications, specialized encryption schemes, IAM policies, and request-payer configuration, none of which carry over cleanly between implementations.

Mixpeek's evaluation in July 2026 put this to the test against real workloads: multipart uploads, presigned URLs, lifecycle policies, event notifications, Object Lock, versioning, and batch operations. Mixpeek found that "S3 compatible" covers a wide spread of actual behavior under load, and different providers land in very different places on that spectrum.

For a cloud deployment, a missing feature is an annoyance. There's usually a managed service nearby that can route around it. An air-gapped deployment doesn't get that option. Whatever gap shows up has to get solved inside the perimeter, with the tools already on hand, or the pipeline has to be redesigned around the limitation, and that's the detail worth checking before committing to a backend, not after the migration is already underway.