Meter
Write once, read many, and what it still costs to restore
A source-dated definition of write once, read many storage, its main enforcement patterns, and the restore meters that remain after data is locked.
Put your own numbers through the calculator to see what this meter does to a normal month and to the day you restore.
WORM storage keeps a retained object readable but not mutable
WORM means write once, read many. During the applicable retention period or legal hold, the protected object or object version remains readable but cannot be overwritten or deleted through the protected path. Amazon S3 describes Object Lock as a WORM model, while Azure describes immutable Blob Storage as data held in a WORM state. [1] [2]
WORM is the behavior, Object Lock is one implementation family, and immutable backup is a use case that applies a retention control to backup data. Those terms overlap, but they do not prove the same thing: a service can publish a native retention system without implementing the S3 Object Lock API, and a storage feature can exist without being supported by a specific backup tool. [1] [2] [4] [5]
| Term | What it establishes | What it does not establish | Source ref |
|---|---|---|---|
| WORM storage | The protected data can be read but cannot be overwritten or deleted while the applicable retention control remains in force [1] [2] | It does not by itself identify the API, retention scope, bypass rules, or backup-tool compatibility | [1] [2] |
| Immutable backup | A backup copy is placed under a documented control that blocks unwanted modification or deletion for the required period [1] [3] | It does not prove that every object, version, region, class, or repository path is protected | [1] [3] |
| Object Lock | A provider feature applies retention periods, legal holds, or both to protected objects or versions [1] [3] | The name alone does not prove identical governance, compliance, versioning, or enablement behavior across providers | [1] [3] [6] |
| Legal hold | Protection remains until an authorized action removes the hold, rather than expiring on a predetermined date [1] [3] | It does not replace a separate time-based retention period when both controls are required | [1] [3] |
Retention mode and API compatibility decide whether two WORM controls are comparable
S3 Object Lock separates governance mode, which a specially authorized identity can bypass, from compliance mode, which cannot be shortened or bypassed during retention. Legal hold is a separate control with no predetermined expiration. Backblaze B2 and Wasabi publish the same broad mode names, but their enablement and retention details still have to be checked independently. [1] [3] [6]
Native retention systems should keep their own vocabulary. Azure uses unlocked and locked WORM policies, and Cloudflare R2 uses removable bucket-lock rules while its S3 compatibility matrix marks Object Lock configuration and object-level Object Lock headers as unsupported. R2 bucket locks are therefore not comparable to a full S3 governance and compliance implementation. [2] [4] [5]
| Control archetype | Protection and scope | Bypass or change rule | Eligibility state | Source ref |
|---|---|---|---|---|
| Amazon S3 Object Lock | Retention periods and legal holds protect specified object versions in versioned general-purpose buckets [1] | Governance can be bypassed only with the required permission and explicit header; compliance cannot be shortened or bypassed during retention [1] | conditional on bucket type, versioning, object version, mode, and retention configuration | [1] |
| Azure immutable Blob Storage | Container-level or version-level WORM policies use time-based retention, legal holds, or both [2] | An unlocked time policy can be changed or deleted; a locked time policy cannot be deleted or shortened [2] | not comparable to S3 governance and compliance labels | [2] |
| Backblaze B2 Object Lock | Governance or compliance retention and legal hold protect B2 files from deletion [3] | Governance can be changed by a client with the required capabilities; compliance cannot be removed and can only be extended [3] | conditional on eligible bucket and file retention configuration | [3] |
| Wasabi Object Lock | Bucket-level defaults or object-level retention can use governance, compliance, and legal hold after Object Lock and versioning are enabled [6] | Governance permits authorized bypass; compliance cannot be reversed during retention; legal hold remains until removed [6] | conditional on bucket creation, versioning, and applied retention | [6] |
| Cloudflare R2 bucket locks | Rules can protect matching objects from deletion or overwrite for a duration, until a date, or indefinitely [4] | Bucket-lock rules can be removed, and R2 does not implement the S3 Object Lock configuration or object-level retention API [4] [5] | not comparable to S3 Object Lock governance or compliance | [4] [5] |
WORM blocks protected mutations, not a read-only restore
A read-only restore retrieves or reads the retained source. Depending on provider and class, it can add retrieval, request, temporary-copy storage, and egress charges, but it does not delete, overwrite, move, or transition the retained object. Early deletion is therefore does not apply to the restore itself. [7] [8]
Retention can still change storage and request costs around the restore. Versioning can retain additional object versions, policy changes can create transaction charges, and a lifecycle deletion can be deferred while a lock rule remains stricter than the lifecycle rule. Those are retention or maintenance effects, not early-deletion charges caused by reading data. [2] [9] [4]
| Action | WORM result | Billing classification | Source ref |
|---|---|---|---|
| Read or restore a protected object | Allowed through the provider's documented read or restore path [1] [7] | Retrieval, requests, temporary-copy storage, and egress can apply; early deletion does not apply | [1] [7] [8] |
| Overwrite a protected version | Blocked during effective retention in the documented WORM modes [1] [2] | Not a restore; a new version or failed request can have separate storage or request consequences | [1] [2] |
| Permanently delete a protected version | Blocked unless the active control permits an authorized bypass or the protection has ended [1] [3] | Early deletion is conditional only if a permitted destructive action removes data before a separate minimum storage duration | [1] [3] [8] |
| Run a lifecycle deletion before lock expiry | The stricter R2 bucket-lock rule keeps the object until its retention requirement is met [4] | The object continues to occupy storage; this is not a read-only restore charge | [4] |
| Create another object version | The previously protected version remains retained under version-scoped controls [1] | Additional version storage and write requests can apply | [1] [2] [9] |
Egress still decides the restore bill after data is locked
WORM status does not replace the provider's transfer, retrieval, and request meters. The provider dataset records three different restore archetypes: Backblaze B2 has a proportional free-egress allowance with a published overage rate, Cloudflare R2 has no egress charge but keeps request and class-specific retrieval meters, and Wasabi has a proportional fair-use boundary with no published monetary overage rate. [10] [12] [9]
A WORM comparison that reduces all three to free egress would be wrong. B2 converts cleanly to a dollar result beyond its allowance, R2 can still bill Class A and Class B operations and Infrequent Access retrieval, and Wasabi must stop at not published beyond its policy boundary because the published remedy is limitation or suspension rather than a per-GB price. [10] [12] [9]
| Provider | Retention control | Read-only restore rule from providers.json | Receipt state | Source ref |
|---|---|---|---|---|
| Backblaze B2 | S3-compatible Object Lock with governance, compliance, and legal hold is documented [3] | Free egress up to 3 times monthly average storage, then $0.01 per GB; retrieval and captured Class A and Class B operations are not charged [10] [11] | conditional on monthly average storage and restore volume | [3] [10] [11] |
| Cloudflare R2 | Native bucket locks are documented, but S3 Object Lock operations are not implemented [4] [5] | Internet egress is not charged; Class A and Class B operations remain billable after applicable allowances, and Infrequent Access retrieval is $0.01 per GB [12] | not comparable retention API; conditional request and retrieval cost | [4] [5] [12] |
| Wasabi | S3 Object Lock with governance, compliance, and legal hold is documented [6] | Egress is inside the fair-use policy when monthly egress does not exceed active storage; the provider publishes no per-GB overage rate beyond that boundary [9] | not published beyond the policy boundary, never $0 by assumption | [6] [9] |
The pricing dataset is incomplete for two retention-capability fields
The 2026-07-25 provider dataset marks Wasabi Object Lock as not published because that capture checked pricing documents rather than the dedicated Object Lock guide. The current official guide verifies Object Lock, versioning requirements, governance, compliance, and legal hold. This page uses the official guide for retention capability while keeping all Wasabi rates and policy states from providers.json. [13] [6]
The same dataset marks Cloudflare R2 Object Lock as not published from the pricing page. Current R2 documentation verifies native bucket locks, while the S3 compatibility matrix still marks S3 Object Lock configuration, retention, legal-hold, and bypass operations as unsupported. The honest state is not comparable for the retention API, not true and not zero. [12] [4] [5]
| Provider | Dataset field | Dedicated documentation | Resolution | Source ref |
|---|---|---|---|---|
| Wasabi | object_lock_immutability: not published because the checked pricing documents did not source the feature [13] | Official Object Lock documentation verifies the feature and its retention modes [6] | stale capability evidence in providers.json; pricing and egress policy remain dataset-sourced | [13] [6] |
| Cloudflare R2 | object_lock_immutability: not published because the checked pricing page did not state the feature [12] | Native bucket locks are documented, but S3 Object Lock operations remain unsupported [4] [5] | not comparable to S3 Object Lock rather than a boolean capability claim | [12] [4] [5] |
Sources
Every figure above comes from one of these pages, on the date shown. Each numbered reference in the text links to its entry here. Vendors change prices; if a date looks old, check the source. Three vendors publish a machine-readable feed and the rest are re-checked by hand, which is why the dates are not uniform.
The source ledger13 sources
- 1AWS documentation: Object lockdocs.aws.amazon.com · checked 2026-07-27
- 2Microsoft Learn: Immutable storage overviewlearn.microsoft.com · checked 2026-07-27
- 3Backblaze: Cloud storage object lockwww.backblaze.com · checked 2026-07-27
- 4Cloudflare developer docs: Bucket locksdevelopers.cloudflare.com · checked 2026-07-27
- 5Cloudflare developer docs: Apidevelopers.cloudflare.com · checked 2026-07-27
- 6Wasabi documentation: Object lockingdocs.wasabi.com · checked 2026-07-27
- 7AWS documentation: Restoring objectsdocs.aws.amazon.com · checked 2026-07-27
- 8Amazon Web Services: S3 pricingaws.amazon.com · checked 2026-07-27
- 9Wasabi: Faqwasabi.com · checked 2026-07-27
- 10Backblaze: Transaction pricingwww.backblaze.com · checked 2026-07-25T15:34:44Z
- 11Backblaze: Cloud storage pricingwww.backblaze.com · checked 2026-07-25T15:34:44Z
- 12Cloudflare developer docs: R2 pricingdevelopers.cloudflare.com · checked 2026-07-25T15:34:44Z
- 13Wasabi: Faqwasabi.com · checked 2026-07-25T15:34:44Z