Cloud Storage Pricing Comparison 2026: Object, Block, File, and Archive Costs by Provider

Overview

If you are trying to run a website, protect backups, or support application data, a simple “price per GB” comparison is not enough. Cloud storage pricing depends on three things: what kind of storage you are buying, how often you access it, and which secondary fees apply.

The four storage models covered here solve different problems:

• Object storage is usually the default choice for backups, media assets, logs, static site files, and large unstructured datasets. It often looks inexpensive at first glance, but request charges, egress fees, and lifecycle rules can materially affect total cost.
• Block storage is attached to virtual machines and is usually priced more like persistent disks. It is often the right fit for databases, boot volumes, and applications that need low-latency reads and writes.
• File storage exposes shared filesystems over standard protocols and is useful for shared application data, content teams, and workloads that need many systems to mount the same storage.
• Archive storage is built for low-cost long-term retention, but the low monthly rate usually comes with tradeoffs around retrieval time, access patterns, and restore fees.

For buyers doing a cloud storage pricing comparison, the goal is not just to find the cheapest provider. The goal is to find the lowest effective cost for your access pattern and recovery needs.

An evergreen way to think about this is:

1. Choose the storage model that matches the workload.
2. Estimate monthly stored capacity.
3. Estimate data written, read, and transferred out.
4. Add operational extras like snapshots, replication, minimum retention, and API activity.
5. Compare providers on total monthly cost, not headline storage price.

This is also why public comparison resources remain useful over time. The source material behind this article points to a large community-maintained comparison table covering dozens of cloud storage services and feature differences. That kind of broad survey is helpful for shortlisting options, but buyers still need a workload-specific calculator mindset before they commit.

For hosting teams, this matters beyond backup budgets. Storage choices affect website recovery time, asset delivery architecture, and the economics of cloud hosting itself. If your broader platform decisions are tied to performance and capacity planning, our guide to web performance benchmarks for hosting engineers is a useful companion read.

How to estimate

The most reliable way to estimate cloud storage pricing is to model your workload in layers. Start with storage consumed, then add access, resilience, and recovery behavior.

1. Identify the primary storage type

Do not compare object storage pricing directly to block storage cost or file storage pricing as if they are interchangeable. They are not. A few examples:

• A WordPress media library backup target usually belongs on object or archive storage, not block storage.
• A database disk for a VPS hosting deployment belongs on block storage, not archive.
• A shared creative asset repository for multiple servers may justify managed file storage.
• Compliance copies that are rarely touched may be cheaper in archive tiers if restore delay is acceptable.

2. Estimate your average stored data

Use average monthly stored capacity, not just the starting amount. If your backups grow every week, or if lifecycle rules shift data between hot and cold tiers, calculate the average footprint across the month.

A simple formula:

Monthly storage charge = average GB or TB stored × published rate for that class

If the provider uses multiple classes, split your estimate by class, such as standard object, infrequent access, and archive.

3. Estimate data movement

Storage bills often rise because of traffic rather than capacity. Track:

• Ingress: data uploaded into the platform
• Egress: data transferred out to users, applications, or other regions
• Inter-region replication: copies written to another location
• Restore traffic: data retrieved from backups or archives

For backup-heavy environments, egress may stay low most months and spike during incidents. That makes it useful to model both a normal month and a recovery month.

4. Add operation-based fees

This is where object storage pricing becomes less intuitive. Some providers charge for API operations such as PUT, GET, LIST, lifecycle transitions, or retrieval requests. Small websites may barely notice this. High-churn workloads, image-heavy applications, and logging pipelines often do.

Questions to ask:

• How many files are created per day?
• How many retrievals happen per month?
• Are backups full or incremental?
• Does the application generate many small objects?
• Will lifecycle policies move data between tiers often?

5. Include durability and availability choices

Redundancy affects price. A single-zone storage option can cost less than multi-zone or geo-redundant storage, but recovery objectives change. If the data supports a production website, backups alone may not be enough; you may need replicated storage plus offsite website backup.

A practical estimate should separately list:

• Base storage
• Redundancy or replication premium
• Snapshot or versioning costs
• Transfer and request fees
• Archive retrieval or early deletion penalties if relevant

6. Compare monthly and yearly scenarios

Some providers and independent comparison resources show monthly, yearly, or even lifetime plan structures for cloud storage services. For business infrastructure, the most useful comparison is still the one based on operational behavior over time. Promotional discounts, prepaid commitments, and reserved capacity can lower cost, but they should be layered onto a realistic baseline rather than used to create one.

If you want a fast sanity check, compare three totals for each provider:

1. Quiet month cost: routine storage and normal access
2. Busy month cost: increased reads, writes, or media delivery
3. Recovery month cost: large restore, high egress, or archive retrieval

This three-scenario view is usually more useful than a single average.

Inputs and assumptions

Good estimates depend on clear assumptions. The best cloud storage pricing comparison is one you can update in five minutes when a rate card changes.

Core inputs to capture

• Total data stored: in GB or TB
• Monthly growth rate: how much data is added
• Read frequency: rare, moderate, or high
• Write frequency: one-time backup, daily sync, continuous ingest
• Average object or file size: many small items can increase request costs
• Retention period: especially important for archive tiers
• Restore requirements: how quickly data must be available
• Redundancy level: local, multi-zone, cross-region
• Snapshots or versioning: how many copies are retained
• Expected outbound transfer: to users, apps, or disaster recovery processes

Assumptions that often distort cost comparisons

Assumption 1: archive is always cheapest.
Archive storage cost is usually low for retained data, but a single urgent restore can erase much of the monthly savings. It is best for data that is truly cold, not merely infrequently used.

Assumption 2: object storage fits every backup workload.
Object storage is versatile, but backup software behavior matters. Some tools generate a very high number of small object operations. Others are more efficient. The storage class may be correct while the implementation still creates avoidable cost.

Assumption 3: block storage is too expensive for backups.
Usually it is not the first choice for backup retention, but block storage can still be economical for short-lived snapshots, rapid rollback points, or attached application volumes where performance matters more than raw capacity cost.

Assumption 4: file storage is just object storage with folders.
It is not. Managed file platforms often charge for throughput, provisioned capacity, metadata performance, or minimum allocations. File storage pricing should be treated as its own category.

Assumption 5: published rates are comparable across providers.
They are only comparable if scope is the same: same region, same redundancy level, same access tier, same billing unit, same support expectations, and similar retrieval behavior.

A simple estimation worksheet

Use a spreadsheet with the following columns:

• Provider
• Storage type
• Region
• Base storage rate
• Stored TB
• Monthly base charge
• Request estimate
• Transfer-out estimate
• Replication or snapshot estimate
• Retrieval estimate
• Total quiet month
• Total recovery month
• Notes on limits or caveats

That format keeps the comparison grounded in outcomes, not marketing language.

For cloud storage used in broader infrastructure stacks, connect storage decisions to application behavior. Teams running AI or analytics workloads, for example, often underestimate how training data movement changes storage economics. If that is relevant, see our guide to storage profiles for cloud-based AI development.

Worked examples

The examples below avoid named prices because provider rates change and vary by region. Instead, they show how to reason about object storage pricing, block storage cost, file storage pricing, and archive storage cost in realistic scenarios.

Example 1: Offsite website backup for a small business

Workload: A business website and database generate nightly backups. Total retained data is modest but growing. Restores are rare, and the main goal is offsite protection.

Best-fit models: Object storage first, archive for older recovery points.

Estimate approach:

• Store recent backups in standard object storage for fast restores.
• Move backup sets older than a defined threshold into colder storage using lifecycle rules.
• Estimate low monthly egress during normal operation.
• Model one recovery month with a full-site restore.

What usually matters most: retention policy, lifecycle transitions, and the restore path. The cheapest headline rate may lose if retrieval from cold tiers is slow or expensive during an incident.

This is a common case where archive storage can help, but only after you define recovery time objectives clearly.

Example 2: Media-heavy application serving user uploads

Workload: An application stores images, videos, and generated assets. Files are uploaded constantly and read frequently by end users.

Best-fit models: Object storage, potentially paired with CDN delivery.

Estimate approach:

• Calculate the average stored asset footprint.
• Estimate monthly uploads and total downloads.
• Add request-heavy behavior if the app handles many small files.
• Include CDN offload if applicable, since direct storage egress may otherwise dominate cost.

What usually matters most: egress and request patterns, not just stored capacity. A provider that appears cheap on base storage can become expensive if outbound transfer is high.

For website hosting teams, this is one reason storage architecture and front-end performance should be considered together rather than separately.

Example 3: Persistent disks for VPS or cloud hosting

Workload: A production application runs on VMs and needs attached disks for operating system, database, and application state.

Best-fit models: Block storage.

Estimate approach:

• Separate boot volume from data volume.
• Estimate provisioned capacity and any performance tier requirements.
• Add snapshot retention and backup exports.
• If the database is replicated, include duplicate volume cost.

What usually matters most: IOPS or throughput class, snapshot policy, and redundancy. Block storage cost can rise quickly when teams provision for peak performance rather than average need.

If your environment spans development, staging, and production, clone and snapshot practices deserve special attention. They often become a hidden multiplier.

Example 4: Shared content repository for a distributed team

Workload: Multiple systems and users need simultaneous access to a common filesystem for assets, builds, or content workflows.

Best-fit models: File storage.

Estimate approach:

• Estimate provisioned or active shared capacity.
• Check whether the provider bills separately for throughput or performance modes.
• Include backup copies and snapshots.
• Review minimum size commitments.

What usually matters most: the gap between provisioned and actually used capacity. File storage pricing may be less forgiving if you need a small active footprint with high throughput.

Example 5: Long-term compliance retention

Workload: Data must be retained for long periods and is rarely accessed except for audits, investigations, or legal requests.

Best-fit models: Archive storage.

Estimate approach:

• Estimate retained data over the full policy period.
• Account for minimum retention rules.
• Model occasional retrieval events separately.
• Check whether expedited restore options exist and what they cost.

What usually matters most: retrieval timing, compliance controls, and deletion rules. Archive is excellent when the access pattern is truly cold. It is a poor fit for data that users expect to open on demand.

When to recalculate

Cloud storage estimates should be revisited whenever the underlying inputs change. This is the practical habit that turns a one-time comparison into a durable decision tool.

Recalculate your storage model when:

• Provider pricing changes for storage classes, transfer, or API operations
• Your data growth rate changes materially after a new product launch, media expansion, or backup policy shift
• Access patterns change, such as more frequent restores, analytics jobs, or public downloads
• You move regions or add geographic redundancy
• Your backup software changes behavior in deduplication, object counts, or retention handling
• Compliance rules change and require longer retention or different recovery targets
• You adopt new workloads such as AI pipelines, log retention, or larger asset libraries

A practical operating rhythm is:

1. Review current bills quarterly.
2. Compare actual usage against the assumptions in your worksheet.
3. Flag the top two cost drivers: storage growth, requests, egress, snapshots, or retrieval.
4. Test whether another tier or storage model would lower total cost without weakening recovery.
5. Document the trigger that would justify migration.

If you manage infrastructure for multiple teams, it also helps to define a threshold for re-evaluation, such as a percentage increase in stored data or a repeated spike in transfer charges. That keeps storage review disciplined rather than reactive.

Finally, treat cloud storage pricing as part of operational resilience, not just cost control. If your architecture depends on a single geography or vendor behavior that may change, storage strategy should be reviewed alongside supplier and location risk. For that broader lens, see our playbook on geopolitical risk and cloud provider supply chains.

Action checklist:

• Map each workload to object, block, file, or archive storage before comparing rates.
• Build a simple worksheet with quiet month and recovery month scenarios.
• Include transfer, request, snapshot, and retrieval assumptions explicitly.
• Check lifecycle rules and retention minimums before using cold tiers.
• Revisit the model whenever provider pricing or workload behavior changes.

That approach will give you a better answer than any single “cheapest cloud storage” list, and it will remain useful as providers update plans, features, and fee structures over time.