Cloud SAN vs. Public Cloud Block Storage: Real Cost Comparison

The real cost of public cloud block storage rarely matches the number on the pricing page. A team budgets for storage at $0.08 per GB per month, runs a production workload for a quarter, and receives an invoice two or three times the estimate — with separate line items for provisioned IOPS, throughput tiers, and data transfer charges that weren’t part of the original calculation. The decision that produces this gap starts at the storage architecture level. The pricing model is a direct consequence of the architecture underneath it.

This post breaks down how AWS EBS, Azure Managed Disks, and Google Cloud Persistent Disk actually bill — then compares that structure to a dedicated Cloud SAN for the same workload profile. The numbers make the decision clearer than any feature comparison chart.

How Public Cloud Block Storage Is Actually Billed

Public cloud block storage charges across multiple dimensions simultaneously. Most teams account for one or two of these when planning. Production invoices reflect all of them.

Capacity (per GB/month). This is the number advertised most prominently. AWS EBS gp3 runs approximately $0.08/GB/month; Azure Premium SSD v2 is in a similar range; Google Cloud Hyperdisk Balanced sits around $0.10/GB/month. For raw capacity alone, these are manageable at moderate scale. Capacity cost becomes a small fraction of the total bill once high-performance volumes and data movement enter the picture.

Provisioned IOPS (per IOPS/month). Performance-tier block volumes separate capacity from IOPS and charge for each independently. AWS EBS io2 charges approximately $0.065 per provisioned IOPS per month. A database requiring 40,000 provisioned IOPS pays around $2,600/month in IOPS charges alone — before any capacity cost is added. Azure and Google follow similar structures on their performance tiers, with per-IOPS fees that accumulate regardless of whether those IOPS are fully consumed in a given month.

Provisioned throughput (per MB/s/month). EBS gp3 includes a 125 MB/s baseline; throughput above that is charged at approximately $0.04 per MB/s per month. For analytics workloads, AI data pipelines, or media processing requiring sustained high-bandwidth storage access, this adds another variable cost layer on top of capacity and IOPS.

Data egress (per GB transferred). This is where costs diverge most sharply from initial estimates. AWS charges approximately $0.09/GB for the first 10TB of outbound data transfer per month, dropping to $0.085/GB for the next 40TB. Azure and Google price similarly. At 50TB of monthly egress, that figure approaches $4,250 in transfer fees alone — every month, in addition to capacity, IOPS, and throughput charges.

These four components bill simultaneously. The total cost for a given workload depends on the specific combination of volume, performance, and data movement — and the gap between estimated and actual spend almost always opens at the IOPS and egress lines.

The Egress Problem at Real Data Volumes

Egress fees are the cost organizations most consistently underestimate before running production workloads in public cloud environments. They look small per gigabyte and become significant at volume.

Egress charges apply when data moves from cloud storage to external systems, crosses between regions, or in some configurations, travels between availability zones. Organizations connecting cloud workloads to on-premises systems through private circuits and peering see these charges on every gigabyte that leaves the provider’s internal fabric.

The scale compounds quickly. An organization moving 200TB outbound per month pays approximately $17,000 in egress fees at standard rates — recurring every month, growing with data volume. For data-intensive verticals like financial services, AI, and media, egress frequently becomes the largest single storage-related cost after the first year of production operation.

A Concrete Cost Scenario

To put specific numbers to the comparison, consider a mid-size enterprise workload: 50TB of block storage, 30,000 provisioned IOPS, 500 MB/s provisioned throughput, and 100TB of monthly data egress. These parameters are representative of a production analytics database or a data pipeline serving a distributed application.

AWS EBS io2 — illustrative monthly estimate:

• Capacity: 50,000 GB × $0.125/GB = $6,250
• Provisioned IOPS: 30,000 × $0.065 = $1,950
• Egress: 100TB × $0.085/GB = $8,704
• Estimated total: ~$16,904/month

These are approximate figures using publicly available 2024–2025 US-East pricing. Actual costs vary by region, commitment tier, and current pricing. The structural point holds regardless of exact figures: for this workload profile, egress alone accounts for more than half the total monthly storage bill.

On a Cloud SAN, the cost structure is different by design. There are no egress charges for data moving between storage and compute on the same private fabric. Capacity and performance are provisioned at a committed rate without per-IOPS or per-throughput metering. For a workload with this access pattern, total cost becomes more predictable and significantly lower at volume — not because Cloud SAN storage is cheaper per gigabyte, but because the per-operation and per-transfer billing components are absent.

What Cloud SAN Pricing Looks Like

A Cloud SAN charges for dedicated infrastructure rather than metered operations. The model is closer to a committed resource contract than a utility bill.

You pay for storage capacity and the network fabric that serves it. You do not pay separately for each IOPS provisioned, each MB/s of throughput consumed, or each gigabyte transferred between storage and compute on the same internal fabric. For workloads that generate consistent, high-volume I/O — exactly the workloads where public cloud per-IOPS and per-throughput charges accumulate fastest — this produces invoices with fewer variables and more predictable totals.

The pricing structure reflects this directly. The right question when comparing isn’t the per-GB rate in isolation — it’s the total cost for the specific combination of capacity, performance, and data movement your workload actually generates.

For teams that want to run their own hardware on dedicated infrastructure rather than leasing capacity, colocation and BYO hardware options allow organizations to bring their own storage into a Cloud SAN environment — combining the economics of owned hardware with the fabric, networking, and operational benefits of a managed cloud environment.

When Public Cloud Block Storage Still Makes Sense

Public cloud block storage is the right tool for workloads with genuinely unpredictable or low I/O. Development environments, short-lived test workloads, and applications that don’t generate consistent high-volume data movement are reasonable fits for on-demand metered pricing. The flexibility and zero upfront commitment have real value when workload size and duration are uncertain.

The economics shift toward Cloud SAN when workloads have consistent, high-volume access patterns; when egress charges accumulate at scale; when predictable monthly costs matter operationally; or when performance requirements exceed what public cloud block volumes reliably deliver under shared-tenancy conditions. The workloads described in the post on block storage for AI and GPU workloads are a clear example — training clusters and inference services combine high throughput, deep IOPS requirements, and significant data movement in exactly the pattern where public cloud billing compounds fastest.

For organizations running hybrid workloads across private and public environments, a hybrid cloud architecture can split workloads by their cost profile — keeping high-volume, consistent I/O workloads on Cloud SAN while retaining public cloud flexibility for variable or development workloads.

Frequently Asked Questions

Is Cloud SAN cheaper than AWS EBS?

For low-I/O or short-term workloads, public cloud block storage’s on-demand pricing is often lower because there’s no committed capacity. For high-IOPS, high-throughput workloads with significant egress — production databases, AI pipelines, analytics platforms — Cloud SAN typically produces lower total cost. The per-IOPS, per-throughput, and egress components of public cloud billing are the lines where Cloud SAN’s committed-resource model pulls ahead at volume.

Why are egress fees so high on public cloud block storage?

Egress fees reflect the cost of moving data out of a provider’s network boundary. They look small per gigabyte because they are — at small volumes. At the data volumes production workloads generate, particularly workloads that move data to external systems, between regions, or across hybrid environments, egress becomes the largest single storage cost. It is also the cost most frequently absent from initial planning estimates.

What is provisioned IOPS, and why does it add cost?

Public cloud performance-tier block volumes separate storage capacity from I/O performance. Provisioned IOPS means paying a monthly fee for a specific IOPS ceiling, whether or not those IOPS are fully consumed. For databases and applications requiring consistent high IOPS, this billing model adds significant cost independent of actual usage patterns. Cloud SAN delivers IOPS as part of the infrastructure allocation rather than as a separately metered variable.

Conclusion

The cost comparison between Cloud SAN and public cloud block storage is not a per-gigabyte comparison — it’s a total cost of ownership analysis that includes IOPS billing, throughput charges, and egress fees. For workloads that generate consistent, high-volume I/O and move data regularly across boundaries, those three components often exceed the raw capacity cost by a significant margin. Cloud SAN’s committed-resource model removes the per-operation and per-transfer billing layers that drive that gap. For enterprise storage buyers running the actual numbers — not just the per-GB rate — MarQi Cloud offers snapshots and backups as part of the infrastructure, so data protection costs don’t add another metered variable to the comparison.