Glossary

Cloud storage gateway

A cloud storage gateway is a hardware or virtual appliance, installed near the applications it serves, that presents cloud object storage through a local file, block or tape interface. It translates between the protocols those applications already use and the HTTP APIs of object storage, and keeps a local cache to hide the distance.

Why cloud storage gateways exist

Much of the enterprise application estate was written for NFS and SMB shares, iSCSI volumes or tape libraries, and cannot be rewritten to speak an object API. Gateways let that software keep its interface while the capacity behind it moves to object storage in a public cloud or on premises. For infrastructure teams, the attraction is a way to retire file servers, tape libraries or ageing arrays without touching the applications that use them. The cost is a translation layer that sits in the data path and shapes performance, resilience and how easily the data can be used later.

How protocol translation works

• File to object. The gateway exports a share. Each file becomes an object, and the file path becomes the object key, so /projects/2026/report.pdf is stored as projects/2026/report.pdf. Other applications can read these objects directly.
• Block to object. The gateway exports a virtual disk, splits its address space into fixed-size chunks and stores each written chunk as an object. The objects mean nothing individually and can only be read back through the gateway.
• Tape to object. The gateway emulates a tape library, with virtual drives and cartridges, for backup software that writes to tape. Each virtual cartridge is stored as data in the bucket.

Some block gateways run in a cached mode, where the primary copy lives in the cloud and hot data is cached locally, and others in a stored mode, where the full dataset stays local and snapshots go to the cloud for recovery.

The cache and the write path

A round trip to a cloud region typically takes tens of milliseconds, against about a millisecond to local disk. The cache closes most of that gap for data in the working set. Average read latency follows the hit ratio h: h × local latency + (1 − h) × remote latency. At a 90% hit ratio, 1 ms locally and 40 ms remotely, the average is 0.9 × 1 + 0.1 × 40 = 4.9 ms. Every miss still pays the full remote round trip, so tail storage latency is set by the network.

Writes are usually acknowledged once they reach the cache and uploaded afterwards. Until upload finishes, the gateway holds the only copy of new data.

Gateways ship as virtual machines on an existing hypervisor, as hardware appliances with their own cache disks, or as instances inside the cloud provider for recovery and testing. The cache is sized to the active working set. An undersized cache turns a share into a remote file system in which most reads cross the wide-area link.

What a cloud storage gateway means for enterprise file and backup estates

The link sets the ceiling. A 1 Gb/s connection carries at most 125 MB/s, so 2 TB of daily change takes at least 2,000,000 ÷ 125 = 16,000 seconds, about 4.4 hours, to upload before protocol overhead or competing traffic. When daily change outgrows what the link can carry, the cache fills with unsent data, write performance falls to the speed of upload, and the volume of data that exists only on the gateway keeps rising.

The gateway becomes a single point of access. Losing a gateway with unsent writes loses those writes, and rebuilding one means a cold cache, with every early read going to the cloud. For a site that depends on the share for daily work, the gateway is as critical as the file server it replaced.

Multi-site collaboration needs extra machinery. Two gateways in different offices writing to the same bucket do not coordinate file locks unless the product adds a distributed locking layer, so simultaneous edits of one file from two sites can overwrite each other.

Format decides future use. File gateways that map one file to one object leave data that analytics, AI pipelines and other cloud services can read in place. Block and tape gateways leave data that only the gateway can interpret, which ties the dataset to that product and turns any later migration into a full read-back through it.

Applications that already speak S3 skip the gateway entirely and write to cloud or S3-compatible storage directly, which removes the cache, the upload queue and the translation step from the data path. Gateways therefore tend to appear in cloud migration projects as a bridge for legacy NAS and tape workloads, alongside native S3 access for newer ones.

Gateway functions and Scality

Scality RING is software-defined object and file storage on standard x86 servers, so S3 applications and file-based applications can both store data on premises without a separate translation appliance. For the reverse direction, Scality's Azure partner page describes an S3-to-Blob translation through which "Amazon S3 applications consume Azure Blob without code changes".