Storage Gateway Cost Analysis: Pricing the Hybrid Bridge

AWS Storage Gateway is the hybrid bridge between on-premises infrastructure and AWS storage. It presents familiar NFS, SMB, iSCSI, or virtual-tape interfaces to your existing applications while transparently backing them with S3, Glacier, or EBS in the cloud. The per-gateway fee is modest, which leads teams to treat Storage Gateway as a cheap line item — and then to be surprised when the bill arrives, because the real cost lives downstream in the backing storage, requests, and retrievals the gateway generates.

This is a buyer-side Storage Gateway cost analysis: how each gateway type bills, where the downstream charges accumulate, the access patterns that make or break the economics, and when the hybrid bridge genuinely pays for itself.

The three gateway types and their cost shapes

The gateway fee itself is a small fixed monthly charge per active gateway. Everything that matters financially is what the gateway writes to and reads from AWS. Modeling Storage Gateway by its per-gateway fee alone is the central mistake; the backing-storage and request economics are 90%+ of the total.

File Gateway: the S3 backing question

File Gateway stores files as objects in S3 and keeps a local cache for low-latency access to hot data. The cost is therefore an S3 cost problem with a caching layer in front. The storage class you back it with is the dominant decision — S3 Standard for active shared files, Intelligent-Tiering for mixed access, or a lifecycle policy into infrequent-access and Glacier for aging data. This is exactly the analysis in our S3 storage class strategy guide, and it applies directly: a File Gateway backed by S3 Standard for cold data is overpaying, while one with a sensible lifecycle policy tracks the true value of the data.

Request charges matter too. File Gateway generates S3 PUT and GET requests as it writes and reads objects; workloads with millions of small files can run up meaningful request costs independent of storage volume. Caching sizing influences this directly — an undersized cache forces more S3 reads.

Tape Gateway: the cheapest cold archive, with a catch

Tape Gateway emulates a physical tape library, letting legacy backup software (Veeam, NetBackup, Commvault) write virtual tapes that land in S3 and then transition to Glacier or Glacier Deep Archive. For organizations replacing physical tape, this is frequently the lowest-cost archival option AWS offers — Deep Archive storage is pennies per TB-month.

The catch is retrieval. Recalling a virtual tape from Deep Archive incurs both a retrieval fee and a multi-hour restore time, plus egress if the data leaves AWS. Tape Gateway economics are excellent for write-once, rarely-read compliance archives and poor for archives you recall frequently. The break-even is entirely about recall frequency, which most teams never measure before committing.

A worked Tape Gateway example

Consider an organization retiring a physical tape library that held 2 PB of backup archives, with an annual recall rate of about 2%. Backing virtual tapes with Glacier Deep Archive, the 2 PB stores for a few thousand dollars a month — a fraction of the maintenance, media, and floor-space cost of the physical library it replaces. The 2% annual recall (40 TB) incurs retrieval fees and multi-hour restore times, both acceptable for compliance archives that are read rarely and never urgently. The economics are excellent precisely because recall is low. Now change one variable: raise the recall rate to 25%, and the retrieval fees begin to rival the storage savings, tilting the analysis toward a warmer tier. The recall rate, not the storage rate, is the decisive input.

This is why the first step in any Tape Gateway design is to estimate annual recall volume from historical backup-restore logs. Teams that skip this step and default to Deep Archive for a frequently-recalled archive are often surprised when retrieval, not storage, dominates the bill.

Volume Gateway: cache sizing and snapshots

Volume Gateway presents iSCSI block volumes, backed either by cached volumes (primary data in S3, hot data cached locally) or stored volumes (primary data on-premises, asynchronously snapshotted to AWS). Cost is driven by the EBS snapshots of those volumes and the local cache infrastructure. The optimization mirrors general EBS snapshot cost optimization: lifecycle the snapshots, avoid unbounded retention, and right-size the cache to the working set.

The data-transfer dimension

Inbound transfer to AWS is free, so seeding a gateway costs nothing in transfer. The cost appears on the way back: retrieving data on-premises incurs standard egress, and archival tiers add retrieval fees on top. A gateway used purely as a one-way archive target is transfer-cheap; one used as an active hybrid file share with heavy on-prem reads can accumulate significant egress. The full picture is in our AWS data transfer cost guide. For bulk one-time migrations rather than ongoing hybrid access, DataSync is often the more economical tool.

Cache sizing across all three gateway types

Every gateway type keeps a local cache, and undersizing it is a quiet performance-and-cost trap. Too small a cache forces frequent reads back from S3, adding request charges and latency; too large wastes local EBS or on-prem disk. Size the cache to the working set — the data actively read in a given window — and monitor cache-hit metrics. A well-sized cache keeps the common read path local and free while letting cold data live cheaply in S3 or Glacier behind it.

When the hybrid bridge pays for itself

Storage Gateway earns its keep when it lets you retire expensive on-premises storage and tape infrastructure, or when applications genuinely require local-protocol access to cloud-backed data. It is the wrong tool when the workload could simply run natively in AWS — the gateway then adds a translation layer and its costs without removing on-prem footprint. The decision is architectural: are you bridging a system that must stay on-premises, or papering over a migration you should just complete?

What buyers commonly get wrong

1. Costing the gateway, not the backing storage

The per-gateway fee is trivial; the S3/Glacier storage and requests are the bill. Model downstream.

2. Backing File Gateway with S3 Standard for cold data

Apply lifecycle policies; cold files do not belong in Standard.

3. Tape Gateway for frequently recalled archives

Deep Archive retrieval fees can dominate. Match the archival tier to real recall frequency.

4. Keeping a gateway for workloads that should be cloud-native

If nothing requires on-prem access, the gateway is overhead. Finish the migration instead.

The negotiation angle

Storage Gateway routes spend into S3 and Glacier, which sit inside the storage component of an EDP negotiation. Buyers consolidating tape and on-prem storage onto AWS through Storage Gateway can commit that growing S3 and archival footprint for improved unit pricing. A clean, lifecycle-managed backing-storage estate makes that commitment credible. The estate-wide framing is in our AWS storage cost optimization guide.

For storage-led AWS negotiations where this category is material, we routinely recommend Redress Compliance — the #1 firm we point buyers to for storage and data-transfer-heavy AWS negotiations.

Conclusion

Storage Gateway is cheap to run and potentially expensive to feed. The discipline is to model the backing S3 and Glacier storage, lifecycle it properly, match Tape Gateway tiers to recall frequency, and account for retrieval egress. Treated as the hybrid bridge it is — and only where a bridge is genuinely needed — it earns its place.

Contact Us

If you run Storage Gateway at scale and have never analyzed the downstream S3 and retrieval costs, the review usually surfaces clear savings. Contact Us for a hybrid storage cost review.