Cloud Storage Gateway (CSG) connects your on-premises or cloud applications to Object Storage Service (OSS) buckets using standard file and block storage protocols—Network File System (NFS), Server Message Block (SMB), and Internet Small Computer Systems Interface (iSCSI)—so you can read and write object storage without rewriting your applications.
CSG supports two gateway types. Choose based on your application's storage access pattern:
File gateway — exposes an OSS bucket as an NFS or SMB file share. Use this to replace on-premises file servers, back up or share small files, or distribute files across branches.
Block gateway — exposes an OSS bucket as an iSCSI block device. Use this when your application requires raw block storage access.
Key benefits
No application changes required. Applications communicate over NFS, SMB, or iSCSI—the same protocols they already use.
Hot data stays local, cold data moves to the cloud. An intelligent caching layer keeps frequently accessed data on local disks for low-latency access while offloading cold data to OSS.
Unlimited backend storage. CSG inherits OSS's scalability: bucket capacity and object count are not limited.
99.9999999999% designed data reliability. Data flushed from CSG is stored in OSS, which maintains twelve-nines durability across multiple servers within a region.
Built-in encryption. CSG encrypts data in transit from gateways to OSS. Enable server-side encryption with a customer master key (CMK) to encrypt data at rest on OSS as well.
Flexible deployment. Run CSG on an Elastic Compute Service (ECS) instance in the cloud, or deploy it as a virtual machine in your on-premises data center.
Gateway types
File gateways
A file gateway maps objects and folders in an OSS bucket to files and directories, making the bucket accessible over NFS and SMB. Local storage serves as a cache for hot data, providing low-latency access while OSS holds the full dataset.
File gateways are compatible with Portable Operating System Interface (POSIX) and work with most third-party backup software. Four subtypes are available:
| Subtype | Best for |
|---|---|
| Standard | Small file backup and sharing |
| Basic | Small file backup and sharing |
| Enhanced | High performance or multi-client concurrent access |
| Advanced | High performance or multi-client concurrent access |
On Linux, mount the NFS share to a local directory. On Windows, map the SMB share to a network drive. Either way, your application interacts with the OSS bucket as if it were a local file system.
Block gateways
A block gateway creates storage volumes in OSS and presents them as iSCSI targets. Local applications connect through an iSCSI initiator, exactly as they would with a local block device.
Two operating modes are available:
| Mode | How it works | Use when |
|---|---|---|
| Write-through | Data is sliced and written to OSS synchronously | High-speed links (e.g., leased lines) where latency is low |
| Cache | Data is written to local cache disks first, then uploaded to OSS asynchronously | Fast local access is needed at normal upload speeds |
Use cases
Scale out storage without changing applications
CSG's intelligent caching layer automatically identifies hot and cold data. Hot data is retained in the local cache; cold data is moved to OSS. Users and applications access data normally—the cloud connection is transparent. A full copy of all data is maintained in OSS to guarantee data integrity.
Extend storage protocols to the cloud
Legacy applications that rely on NFS, SMB, or iSCSI cannot communicate with object storage APIs directly. CSG acts as a protocol bridge, letting modern and legacy applications in the same environment exchange data without protocol conversion work on either side.
Share files across branches
Deploy CSG instances in multiple regions and associate them with the same OSS bucket. Data written in one region is immediately visible in others, making CSG well-suited for branch offices that need synchronized file access.
Cloud disaster recovery
CSG supports virtualization environments, making it straightforward to extend on-premises workloads into Alibaba Cloud for disaster recovery without replacing existing infrastructure.
Replace ossfs and ossftp
ossfs and ossftp are open-source tools for mounting OSS buckets as file systems, but their POSIX compatibility is limited and they are not supported in production environments. Mounting to multiple clients requires extensive configuration. CSG is a production-ready alternative: create a CSG instance, mount an NFS share (Linux) or map an SMB share (Windows), and manage the OSS bucket like a local file system.
Performance
CSG sits between your applications and OSS, so overall performance depends on:
Local disk speed and configuration
Bandwidth between the iSCSI initiator and the gateway
Storage capacity allocated to the gateway virtual machine
Bandwidth between the gateway virtual machine and OSS
Sizing the local cache. Provision enough local cache to absorb writes during temporary bandwidth gaps:
Recommended local cache capacity =
[Application bandwidth (Mbit/s) - Gateway backend bandwidth (Mbit/s)]
x Write duration (seconds)
x 1.2Also estimate your total hot data footprint. Set the local cache disk to whichever is larger: the formula result or the estimated hot data size.
Transfer acceleration. Enable transfer acceleration on a share to increase cross-region transfer rates using the gateway's public bandwidth. This can be enabled when creating a share or afterward.
OSS bandwidth. OSS provides up to 10 Gbit/s of bandwidth for each user. Exact limits vary by region—contact OSS support for region-specific figures.
Data durability and availability
In cache mode, CSG uses synchronous I/O to write data to local disks, preventing data loss from unexpected power failures. For cloud-deployed gateways, local cache disks are backed by Alibaba Cloud disks.
For on-premises gateways, durability depends on your virtual environment's backend storage. Use Redundant Array of Independent Disks (RAID) or a distributed storage system as the local cache disk to improve resilience.
Data that CSG flushes to OSS benefits from OSS's 99.9999999999% (twelve 9's) designed data reliability, stored across multiple servers within the same region.
Scalability and elasticity
CSG inherits OSS's scalability and elasticity: the total storage capacity of OSS and the capacity of a single bucket are not limited, and you can store an unlimited number of objects in a bucket. Note that storing a large number of files in the same directory in a common file system can cause problems; OSS-backed storage through CSG does not have this constraint.
Security
Identity and access control. CSG integrates with Resource Access Management (RAM). Create and manage RAM users under a single Alibaba Cloud account, grant each user only the permissions they need, and avoid sharing AccessKey credentials across users.
Encryption. CSG encrypts data transferred from gateways to OSS buckets. To also encrypt data at rest, enable server-side encryption on OSS and configure a CMK. Files uploaded from a share are then automatically encrypted on the OSS side using the specified CMK.
For detailed setup, see Use RAM to implement account-based access control.
Management and operations
Manage CSG through the CSG console or via API:
Console: Deploy a gateway virtual machine to an ECS instance or on-premises data center, configure file or block gateways, and create cache disks and shares.
API: Send GET requests over HTTP or HTTPS to manage CSG programmatically.
Billing
CSG is billed based on the resources you use. Billing varies by deployment type:
| Deployment | Billed items | Billing methods |
|---|---|---|
| Cloud (ECS-hosted) | Gateway specifications, cache type, public bandwidth | Pay-as-you-go, subscription |
| On-premises | Gateway software license only (you supply the VM and cache hardware) | License fee |
For a complete pricing breakdown, see Billable items and billing methods.