S3 Express One Zone durability tradeoff: 99.9% vs single-AZ risk

This guide explains why the 99.9% S3 Express One Zone durability SLA does not satisfy a zero-loss recovery objective. It defines the copy rule for workloads that cannot tolerate the single-AZ data-loss window.

How S3 Express One Zone actually works

S3 Express One Zone uses a different storage model from standard S3 buckets. Its directory buckets are purpose-built for workloads that need very low latency and are placed in a single Availability Zone. AWS describes this as a 99.9% availability SLA: the commitment concerns the availability of the designated zone, not the multi-zone durability associated with S3 Standard’s 11 nines, or 99.999999999%. The practical check is simple: if the bucket is the only copy of an object, that object has no independent copy in another Availability Zone.

The speed comes partly from a request path that differs from standard S3. Directory buckets are documented by AWS as offering a low-latency path and a session-based authentication model (via CreateSession) rather than the standard request-signing flow for every operation. Verify the current latency figures and session mechanics in the AWS S3 documentation before relying on them in a design, because published numbers can change. Neither the session mechanism nor the directory structure makes the bucket multi-AZ replicated by default: authentication and replication are separate properties, and a fast authenticated request can still be writing to only one AZ.

This design makes the bucket suitable for temporary data, caches, and other latency-sensitive artifacts, but neither the session mechanism nor the directory structure makes the bucket multi-AZ replicated by default. Authentication and replication are separate properties: a fast authenticated request can still be writing to only one AZ.

That placement creates the relevant loss boundary. A zone-level disruption—such as a power failure or loss of the underlying zone—can make the stored objects unavailable, and a workload with no other copy can face actual data loss. The 99.9% availability figure does not eliminate that risk, nor can it be read as a durability percentage comparable to S3 Standard. For a regenerable cache, checkpoint, or intermediate artifact, verify that the source or upstream process can recreate the object after this event; for a non-regenerable business record, the single-bucket arrangement fails the zero-loss test.

The actionable rule follows directly. If the object is the only copy and the business cannot tolerate any loss, do not store it exclusively in S3 Express One Zone. Maintain a second copy in a standard S3 class, or explicitly accept that the workload has a measurable, non-zero data-loss window. A useful architecture review records the object’s recovery point objective, the source of every durable copy, and the procedure for restoring from the independent copy. If no such copy or reconstruction path exists, the object is protected by availability machinery, not by a multi-AZ durability guarantee.

The evidence: what the numbers actually say

Check AWS’s current documentation for the metric distinction: the S3 Express One Zone service commitment is an availability SLA for a service whose data is placed in one Availability Zone, while S3 Standard advertises a durability objective designed around redundant storage across multiple Availability Zones. Those percentages are not competing versions of the same scorecard. Availability describes whether the service is expected to be reachable during a given period; durability describes the likelihood that an acknowledged object remains intact. Treating the availability commitment as though it were a durability guarantee turns a service-level metric into a stronger data-protection claim than AWS documents.

Those percentages are not competing versions of the same scorecard. Availability describes whether the service is expected to be reachable during a given period; durability describes the likelihood that an acknowledged object remains intact. Treating the availability commitment as though it were a durability guarantee turns a service-level metric into a stronger data-protection claim than AWS documents.

The practical check is the recovery point objective. Ask whether the system can tolerate acknowledged data disappearing after a successful write because an Availability Zone event affected the only stored copy. If the business requirement is an RPO of zero, a single-copy S3 Express One Zone object fails that requirement. The relevant question is not whether its availability SLA is attractive, but whether the object still exists somewhere else after the local failure domain is impaired.

The Postgres durability literature from xzilla.net illustrates the same separation. In that discussion, disabling synchronous_commit creates a window in which Postgres can acknowledge a commit before the corresponding data is fully synchronized to persistent storage. The resulting risk is potential loss of recently acknowledged transactions, while the database’s ordering and crash-recovery mechanisms are designed to prevent corruption. That is a useful analogy for storage design: lower-latency or faster write acknowledgment is not equivalent to an atomic guarantee that the sole copy is durable everywhere.

Both examples converge on the copy rule already stated above: an only-copy object with a zero-loss requirement needs a second copy in a standard S3 class, while a regenerable cache, checkpoint, or intermediate artifact may accept a measurable recovery window if the reconstruction path is explicit and testable.

The decision therefore comes down to one verifiable test: after a zone-level disruption, can the workload recover the acknowledged object from another copy, or does its existence depend on the impaired zone?

Options compared: single-AZ vs replicated

Option A—S3 Express One Zone only—is the performance-first choice. AWS describes its directory buckets as purpose-built for low-latency workloads, with storage placed in one Availability Zone and a 99.9% availability SLA. That SLA promises service availability, not the multi-AZ durability associated with standard S3 buckets. If the Availability Zone becomes unavailable, the design creates a non-zero recovery point objective: recently written objects may be unavailable or lost. The practical rule is straightforward: if the object exists nowhere else and losing even the latest state is unacceptable, an Express One Zone-only design does not meet the requirement.

Option B is the explicit winner for the default case in which the business requires an RPO of zero. Keep the Express One Zone copy for the fast path, but also write the object to a standard S3 class so the second copy is not tied to the same Availability Zone. The trade is added time and expense. Inngest reports that persisting workflow state to a durable store can add roughly 5–50 milliseconds because the workflow waits for the write acknowledgment. Your check is to measure that synchronous replication path in the actual workload rather than treating the Express One Zone write as the only completed write.

Option C—standard S3 only—removes the single-AZ placement risk and avoids Express One Zone charges, but it gives up the lowest-latency storage path. It is appropriate when multi-copy durability matters more than response time and the application can tolerate standard S3 latency. It also does not require maintaining a second destination.

Use one final classification check before choosing: mark each object as either non-regenerable state or a regenerable cache, checkpoint, or intermediate artifact. Non-regenerable state with a zero-loss requirement should use Option B. A regenerable artifact can use Option A if the application can recreate it from authoritative source data. If recreation is impossible and no second copy is retained, do not use Express One Zone exclusively.

Costs and numbers that matter

The first number to put into the design is the cost of a second durable write. Inngest’s “Eliminating latency in AI workflows: How to avoid the durability tradeoff” reports a synchronous persistence round-trip of approximately 5–50 milliseconds. For a workflow that must keep a second copy in a standard S3 class, treat that as the latency added to the operation: the workflow waits for the durable write to be acknowledged before proceeding. This is a workload-level decision, not merely a storage-class comparison, because the additional write can affect step time, throughput, and orchestration costs. Measure it in the application path that actually performs the replication rather than relying on a synthetic request.

The second number is not a fixed storage multiplier. S3 Express One Zone and S3 Standard prices vary by AWS Region, storage class, request type, and usage volume. Check the current AWS S3 pricing page for per-GB storage rates, PUT, COPY, GET, and LIST request rates, and any applicable data-transfer charges. Build the comparison from the actual object sizes and request mix: storage cost, duplicate object footprint, and request volume should be calculated separately. A small-object workload may be dominated by request charges, while a large-object workload may make replicated capacity and data transfer more important. Record the region and pricing-page date in the decision so the estimate remains auditable.

Then price the failure decision. The cost of choosing a single-AZ-only design includes two components that are easy to omit: reconstructing objects that cannot be recovered, and the business impact of the recovery point objective window. A useful worksheet has separate lines for engineering time, compute or third-party retrieval costs, customer support, contractual remedies, and lost revenue or lost work. If the object can be regenerated from another authoritative source, those regeneration costs may be modest; if it is an only copy, the calculation can become open-ended. The worksheet should also identify who makes the call during an incident and how quickly the business can tolerate unresolved data loss.

Apply the copy rule from the earlier sections to the cost worksheet: an only-copy object with a zero-loss RPO takes the standard-S3 second copy and its measured synchronous-write latency; a regenerable cache, checkpoint, or intermediate artifact needs its rebuild time and data-loss exposure quantified before the lower-latency single-copy path is accepted. The key check is whether the measured cost of replication is less than the quantified cost of being wrong.

The key check is whether the measured cost of replication is less than the quantified cost of being wrong.

Finally, validate both sides with a controlled test. Write representative objects to each path, measure the complete durable-write round trip, and repeat enough to capture the range your application experiences. Then calculate the monthly bill using current regional rates and the expected request mix. This produces a decision based on actual latency and cost rather than on an assumed price multiplier or an assumption that low-latency storage is inexpensive to protect.

What the evidence does NOT establish

First, the evidence does not establish how quickly an application can recover after the loss of the Availability Zone hosting an S3 Express One Zone directory bucket. There is no measured AZ-loss recovery time in the cited material, so assigning one would turn an assumption into a fact. The practical check is to review the current AWS service documentation and service-status processes, then run a game-day exercise that simulates the relevant failure and measures the actual interval between the disruption and the point at which reads and writes are usable again. Include application retries, queue backlogs, and any restore or reindexing steps, because service recovery alone does not establish workload recovery.

Second, the 99.9% figure is an availability commitment, not a durability commitment. The available sources does not establish a durability percentage for S3 Express One Zone. Therefore, any article, diagram, or design review that converts “99.9% availability” into “99.9% durability,” or presents it as proof that a single stored object cannot be lost, has crossed a boundary that the evidence does not support. Treat a proposed durability percentage as unverified until AWS documentation or a test program explicitly defines it and its measurement method.

The Postgres and Inngest sources are useful analogies, not measurements of S3 Express One Zone. Zilla’s Postgres durability discussion shows the general shape of the tradeoff: relaxing synchronous persistence can improve performance while creating a window in which acknowledged work may be lost after a crash. Inngest likewise describes durable state persistence as a workflow-latency cost in the range of 5–50 milliseconds. Those examples establish that reducing a persistence safeguard can shift latency against loss exposure; they do not quantify S3 Express One Zone durability, AZ recovery, or the duration of any customer-visible data-loss window.

The resulting rule follows the decision framework set out above: an only-copy object with a zero-loss RPO requires a verified second copy in a standard S3 class, and any workload that keeps a single copy must be described as having a non-zero RPO and tested for its actual recovery behavior, not labeled zero-loss.

The rule relaxes for a regenerable cache, checkpoint, or intermediate artifact: if the system can recreate the object without relying on the missing copy, its business RPO may be greater than zero. The edge case is not the storage class itself but the artifact’s recoverability and the business consequence of losing it.

A 1TB checkpoint workload

A concrete example is a training pipeline that writes a 1 TB checkpoint every 15 minutes. The job is latency-sensitive, but the business can tolerate losing the most recent checkpoint and resume from the preceding one. That requirement makes an asynchronous second copy reasonable: preserving the job’s progress matters, but losing one interval of training state does not end the entire run.

For the first copy, write the checkpoint to S3 Express One Zone. AWS markets this storage option for low-latency writes, which suits a workload trying to minimize the pause between computation and checkpoint creation; confirm the current published latency figures in the AWS documentation before sizing the checkpoint pause.

The training job can begin the write and continue toward its next step while the checkpoint is persisted. Because losing one checkpoint is acceptable, this copy can serve as the fast operational copy from which a restarted job attempts to resume.

For the second copy, asynchronously replicate the checkpoint to a standard S3 class. Inngest reports that a durable-store write adds approximately 5–50 milliseconds, illustrating the cost of waiting for durability acknowledgment. That round trip does not belong on the training job’s critical path here. The checkpoint process can initiate the copy independently, allowing the job to continue while the durable version is written in the background.

The copy-usable checklist should confirm that the source checkpoint was accepted successfully, the standard-S3 destination contains the complete 1 TB object, and the replication has completed before that destination is designated as the recovery checkpoint. A copy merely started is not a usable checkpoint. The system should also expose the source and destination states and their completion times, so operators can distinguish “write in progress,” “copy in progress,” and “ready for recovery.” The amount of training progress represented by the latest verified copy is the relevant recovery point.

This design fits the stated requirement because the business can lose one checkpoint, but it does not make an unverified checkpoint equivalent to a durable one. If the run must survive with no checkpoint loss at all, the job should wait for confirmation that the standard-S3 copy is usable before treating the checkpoint as complete—or avoid keeping the only copy in S3 Express One Zone. The practical rule is to validate the backup state, not merely the speed of the first write.

Decision rules

Use the object’s recoverability and documented recovery point objective (RPO) as the decision gate. If the object is the only copy and the business cannot tolerate any loss, do not store it exclusively in S3 Express One Zone. Treat that condition as a stop condition for a single-copy design: the storage choice must preserve the ability to recover the object without depending on the availability or continued operation of the original copy. Document the owner, the source of truth, and the recovery procedure before deploying the workload.

If the object can be regenerated and the RPO is explicitly documented, then S3 Express One Zone alone is acceptable. The documentation should identify how the object is regenerated, which component performs the regeneration, and the point from which recovery begins. A cache, checkpoint, or intermediate artifact can qualify only when the business has accepted the consequences of losing that particular copy and has a repeatable way to recreate it. “It is probably reproducible” is not a sufficient test; the procedure should be testable by the team responsible for recovery.

If the workload needs Express One Zone latency and cannot tolerate loss, write a second copy to a standard S3 class and verify it before overwrite. Apply the rule at the write boundary: the primary write may proceed in Express One Zone, but an overwrite of the protected version should not be treated as complete until the corresponding copy in the standard S3 class has been confirmed. Make the verification result part of the application’s success criteria or logging so that an operator can distinguish a completed write from a write that still needs repair.

The operational check is therefore straightforward. Classify the object, record the RPO, and identify whether the primary storage is the only copy. For a regenerable object with an accepted and documented RPO, use the lower-latency option by itself. For an irreplaceable or single-copy object, add the standard S3 copy and require verification before overwrite. If neither condition is satisfied, resolve the data-loss requirement before moving the workload into an exclusively single-zone design.

What to do next

Frequently Asked Questions

Does the 99.9% SLA for S3 Express One Zone provide multi-AZ durability?

No; the 99.9% guarantee applies to a single-AZ storage class and is not a multi-AZ durability guarantee.

What copy is required to achieve an RPO of zero with S3 Express One Zone?

An RPO of zero requires a second copy outside S3 Express One Zone.

Where should the second copy of an irreplaceable object be stored when any data loss is unacceptable?

Keep the second copy in a standard S3 storage class.

Can an object that is the only copy remain in S3 Express One Zone if the business cannot tolerate loss?

No; the business must retain another copy in a standard S3 class.

Which types of artifacts may be stored exclusively in S3 Express One Zone?

Regenerable artifacts may be stored exclusively in S3 Express One Zone.

Can caches, checkpoints, and intermediate artifacts tolerate the single-AZ data-loss window?

Yes; caches, checkpoints, and intermediate artifacts can accept the measurable, non-zero data-loss window.

Quick answers

Also worth reading: Cloud storage speed test: 50TB Simple Storage Service (S3) Express One Zone vs Standard: Cloud storage speed test: 50TB · Cloud storage cost 2026: 10M Simple Storage Service (S3) Express One Zone split: Cloud storage cost 2026: 10M · Erasure coding vs 3x replication for petabyte durability tradeoffs: Erasure coding vs 3x replication