Is data redundant without replication?

Yes. 40 of 120 shards are parity headroom and any 80 of 120 reconstruct the object, with no separate replication step to lag or fail.

Is data geographically distributed?

Yes, inherently — shards are placed across independent hosts by the network's distribution engine as part of the write path.

← S3 compatibility matrix S3 resource guide · Replication & geo-distribution

No S3 CRR/SRR — geo-distribution is architectural, not configured

Q: Does XNS support S3 cross-region replication?

No. GetBucketReplication/PutBucketReplication/DeleteBucketReplication return 501 NotImplemented. Every object is erasure-coded 80 data + 40 parity across up to 120 independent hosts at write time instead.

XNS does not implement S3 bucket replication: GetBucketReplication / PutBucketReplication / DeleteBucketReplication are registered routes that return 501 NotImplemented. There is nothing to configure because every object is already erasure-coded 80 data + 40 parity across up to 120 independent hosts at write time — redundancy and geo-distribution are inherent to the write path, not a policy layered on top of it.

S3 CRR/SRR — 501 stub, not implemented 80+40 erasure coding — every object, every write Up to 120 independent hosts

What this area is

S3 replication copies objects between buckets or regions after the fact.

Amazon S3 stores an object once, on one bucket, in one primary location. Cross-Region Replication (CRR) and Same-Region Replication (SRR) are policies you configure via PutBucketReplication that asynchronously copy new (and optionally existing) objects to a second bucket, for disaster recovery, latency, or compliance reasons. It’s an explicit, configured, after-the-write mechanism — replication lag is real, and a misconfigured or paused rule silently stops copying.

CRR (Cross-Region Replication): Async copy to a second bucket in another region.
SRR (Same-Region Replication): Async copy to a second bucket, same region.
Replication lag: Real; a paused or misconfigured rule silently stops copying.

How XNS implements it

Redundancy and geo-distribution happen at write time, not as a follow-up copy.

Every PutObject is split into 80 data shards + 40 parity shards and distributed across up to 120 independent hosts in the network in the same write operation — there is no single primary copy to replicate from, and no second async step that can lag or fail silently. Any 80 of the 120 shards reconstruct the object; the other 40 are pure redundancy headroom. Because the hosts are independent and geographically distributed by the placement engine, geo-distribution is a property of where the shards already landed, not a region you pick in a replication rule.

The boundary, stated plainly

S3 bucket replication is not implemented. GetBucketReplication, PutBucketReplication, and DeleteBucketReplication are registered routes that return 501 NotImplemented — one of exactly 6 routes on the gateway's 73-route table with no real handler (the other 5 are the BucketWebsite trio and two more). This is a documented architectural substitution, not a gap awaiting a fix: adding CRR/SRR on top of an already-erasure-coded, already-distributed write path would duplicate a property the write path already has.

GetBucketReplication / PutBucketReplication / DeleteBucketReplication: 501 NotImplemented. No route handler; architectural substitution, not roadmap.
Erasure coding (80 data + 40 parity, up to 120 hosts): Runs on every PutObject/CompleteMultipartUpload, unconditionally. Not an S3-visible configuration — no bucket setting controls it or turns it off.
Geo-distribution: Inherent consequence of shard placement across independent hosts on the same write path — not a second copy operation.

How we conform to the S3 protocol

Three 501s, by design, plus a passing test suite for the mechanism that replaces them.

Replication routes are measured against the gateway’s own route-table test suite, and object durability against the object-durability tier of the standard ceph/s3-tests data-plane suite. Full per-test results for both are published on the compatibility matrix.

Source: the gateway’s route-table test suite (73-route table, 6-stub set, code-verified) and our internal S3 capability test suite. Object-level durability is exercised as part of the standard data-plane suite, run fullsuite-53dedd8d, 2026-08-11.

Where we deliberately differ. GetBucketReplication, PutBucketReplication, and DeleteBucketReplication return 501 NotImplemented — one of exactly 6 routes on the gateway's 73-route table with no real handler. That's a documented architectural substitution, not a gap: every object is already erasure-coded 80 data + 40 parity across up to 120 independent hosts at write time, so a second async replication step would duplicate a property the write path already provides.

The full route-table breakdown and the data-plane durability figure both live on the S3 compatibility matrix, alongside every measured figure and its provenance.

How we compare

Same rows as the matrix — AWS S3, Ceph, MinIO, Wasabi, B2, Storj.

Source: the same competitor cells published on the S3 compatibility matrix — “Replication & geo-distribution” section — researched from each vendor’s own documentation, 2026-06-14.

Competitor figures from each vendor’s official documentation, researched 2026-06-14. Reused verbatim from the S3 compatibility matrix.
Feature	XNS	AWS S3	Ceph RadosGW	MinIO	Wasabi	B2	Storj DCS
Bucket replication (S3 CRR / SRR)	✗ redundancy via 80+40 erasure coding, not S3 CRR	✓	◐ multisite cross-zone only	✓	✓	◐ native Cloud Replication, not S3 API	✗
Geo-distributed data	✓ inherent: shards across distributed host network	✓	✓	✓	◐	◐	– global by erasure coding

How applications use it

There is no replication call to make — a plain PutObject already gets the redundancy.

boto3

import boto3
s3 = boto3.client("s3", endpoint_url="https://your-gateway:9000",
                   aws_access_key_id="AKIA...", aws_secret_access_key="...")
# A single PutObject already lands as 80 data + 40 parity shards
# across up to 120 independent hosts — no replication rule to attach.
s3.put_object(Bucket="dr-archive", Key="backup-2026-08-12.tar.zst",
              Body=open("backup.tar.zst", "rb"))
# Calling replication config returns NotImplemented — expected, not a bug:
try:
    s3.get_bucket_replication(Bucket="dr-archive")
except s3.exceptions.ClientError as e:
    print(e.response["Error"]["Code"])  # -> "NotImplemented"

AWS CLI

aws s3 cp ./backup.tar.zst s3://dr-archive/backup-2026-08-12.tar.zst \
  --endpoint-url https://your-gateway:9000
# Replication config is not applicable — returns NotImplemented
aws s3api get-bucket-replication --endpoint-url https://your-gateway:9000 \
  --bucket dr-archive

Use cases

Where this matters in practice.

Disaster-recovery targets

Backup destinations that need durability without configuring or monitoring a separate replication rule — the write itself is already redundant.

Geo-distributed retrieval

Applications that read from wherever they are, without a multi-region replication topology to design and pay for twice.

Compliance workloads wanting no single point of failure

No single host holding a full copy of any object simplifies a “where does my data live” conversation compared to a two-bucket replication pair.

Applications that lean on it heavily

Real software, named.

restic / kopia / rclone

Backup tools that write to a single S3 target and rely on the target's own durability guarantee rather than configuring app-level replication.

Veeam (S3-compatible repository target)

Treats XNS as one repository target; the redundancy story is XNS's write path, not a Veeam-side replication policy to a second bucket.

FAQ

Replication questions, answered directly.

Does XNS support S3 cross-region replication (CRR)?

No. GetBucketReplication, PutBucketReplication, and DeleteBucketReplication return 501 NotImplemented. This is a deliberate architectural substitution: every object is already erasure-coded 80 data + 40 parity across up to 120 independent hosts at write time, which delivers the redundancy and geo-distribution CRR is used for on AWS.

Is my data actually redundant without replication?

Yes. Redundancy is built into every write — 40 of the 120 shards are pure parity headroom, and any 80 of the 120 reconstruct the object. There is no separate replication step that can lag, pause, or misconfigure.

Is my data geographically distributed?

Yes, inherently — shards land across independent hosts placed by the network’s distribution engine, so geo-distribution is a property of the write path rather than a region pair you configure.

Will XNS ever add S3 bucket replication?

It is documented as an architectural non-goal today — adding a CRR-style copy mechanism on top of an already-distributed, already-redundant write path would duplicate a property the write path already provides, rather than filling a gap.

See the full conformance picture.

The replication rows above are one section of the full S3 compatibility matrix — object operations, versioning, lifecycle, encryption, access control, and integration all get the same treatment.

Back to the compatibility matrix

Get started

Explore the platform

The full platform

Everything you need to go from evaluation to production.

How it works →The Relayer, erasure coding, and your Virtual Private Datacenter.S3 compatibility →Head-to-head S3 feature matrix vs the field.Eleven nines →Durability, computed — not rounded up.What's new →Everything built since you last looked.Releases →Every build, newest first — what changed and when.

Claims on this page last verified September 4, 2026