AWS Storage Gateway
Key concepts
File Gateway
Volume Gateway (cached/stored)
Tape Gateway
Hybrid cloud storage
Use cases for each type
Overview
AWS Storage Gateway is a hybrid cloud storage service that gives applications running in your on-premises data center seamless access to virtually unlimited cloud storage. Hybrid cloud storage means workloads stay on local hardware while their data is backed by Amazon S3, Amazon S3 Glacier, or Amazon EBS in the AWS cloud. The gateway runs as a virtual machine (on VMware ESXi, Microsoft Hyper-V, or Linux KVM), as a hardware appliance, or as an Amazon EC2 instance, and it exposes familiar storage protocols (NFS, SMB, iSCSI, and iSCSI VTL) so existing applications need no rewrite.
This topic shows up on the SAA-C03 exam through "extend on-premises storage to the cloud" and "replace tape backups" scenarios. You should know the three gateway types (File Gateway, Volume Gateway, and Tape Gateway), the two Volume Gateway modes (cached and stored), the protocol each one speaks, and which cloud service each one writes data into. The exam tests whether you can match a use case (for example, low-latency local access versus full on-premises copies versus virtual tape archiving) to the correct gateway type.
Three Gateway Types, One Hybrid Bridge
File Gateway serves files (NFS/SMB) backed by S3 objects. Volume Gateway serves block volumes (iSCSI) backed by S3 with EBS snapshots, in cached mode (primary data in S3, hot data local) or stored mode (full copy local, async backup to S3). Tape Gateway serves a virtual tape library (iSCSI VTL) backed by S3 and S3 Glacier for backup applications.
Match the protocol to the gateway: NFS/SMB means File Gateway (S3 objects), iSCSI block volumes mean Volume Gateway (cached keeps primary data in S3, stored keeps a full local copy), and iSCSI Virtual Tape Library (VTL) means Tape Gateway (S3 plus S3 Glacier). When a question says replace physical tape backups, the answer is Tape Gateway.
Key Concepts
File Gateway
Files as S3 Objects
File Gateway presents a file interface over NFS (Network File System) or SMB (Server Message Block) and stores each file as a native object in an Amazon S3 bucket. Applications mount the share and read and write files normally, while the gateway keeps a local cache of recently used data for low-latency access. Because files become standard S3 objects, you can apply S3 lifecycle policies, versioning, cross-region replication, and access them directly through the S3 API. File Gateway also integrates with Active Directory for SMB authentication and supports Amazon S3 File Gateway and Amazon FSx File Gateway variants.
Volume Gateway
Block Volumes over iSCSI
Volume Gateway presents cloud-backed block storage volumes as iSCSI (Internet Small Computer Systems Interface) targets that your servers mount like local disks. Data written to a volume is asynchronously backed up to AWS as point-in-time EBS snapshots stored in S3, which you can restore to a new gateway volume or to an Amazon EBS volume. Volume Gateway runs in one of two modes, cached or stored, chosen when you create the volume.
Cached Volumes vs Stored Volumes
With cached volumes, the primary copy of your data lives in S3 and only frequently accessed (hot) data is retained in the local cache. This minimizes on-premises storage and supports up to 32 TB per volume (1,024 TB total across 32 volumes). With stored volumes, the complete dataset is kept on local disk for low-latency access and the gateway asynchronously copies snapshots to S3 for backup and disaster recovery, supporting up to 16 TB per volume (512 TB total across 32 volumes). Choose cached to keep most data in the cloud and stored to keep a full local copy with cloud backups.
Cached vs Stored Volumes
| Dimension | Cached Volumes | Stored Volumes |
|---|---|---|
| Primary data location | Amazon S3 | On-premises disk |
| Local footprint | Hot data cache only | Full dataset |
| Backup to AWS | EBS snapshots in S3 | EBS snapshots in S3 |
| Max size per volume | 32 TB | 16 TB |
| Best for | Minimize local storage, scale to cloud | Lowest-latency local access plus DR copies |
Tape Gateway
Virtual Tape Library for Backups
Tape Gateway presents a Virtual Tape Library (VTL), an iSCSI-based interface that emulates physical tape drives and a media changer, so existing backup software (such as Veeam, Veritas NetBackup, or Commvault) writes to virtual tapes without changes. Active virtual tapes are stored in S3, and when a tape is ejected and archived it moves to the Virtual Tape Shelf (VTS) backed by S3 Glacier Flexible Retrieval or S3 Glacier Deep Archive for long-term, low-cost retention. Tape Gateway is the standard way to replace physical tape infrastructure and offsite tape shipping with cloud-based archiving.
Hybrid Cloud Storage Model
One Appliance, Local Cache, Cloud Backend
All three gateway types share the same hybrid cloud storage model: a gateway appliance deployed near your applications keeps a local cache for low-latency reads and writes, while the durable backend lives in AWS (S3, S3 Glacier, or EBS snapshots in S3). Data is encrypted in transit with TLS and at rest in AWS, transfers are optimized and can be bandwidth-throttled, and you manage everything through the AWS Storage Gateway console or API. This lets you extend a finite on-premises footprint to virtually unlimited cloud capacity without re-architecting applications.
Gateway Types at a Glance
| Gateway Type | Protocol | Cloud Backend | Primary Use Case |
|---|---|---|---|
| File Gateway | NFS and SMB | S3 objects | File shares and content stored as S3 objects |
| Volume Gateway (cached) | iSCSI block | S3 plus EBS snapshots | Cloud-backed volumes with small local cache |
| Volume Gateway (stored) | iSCSI block | S3 plus EBS snapshots | Full local volumes with cloud backup and DR |
| Tape Gateway | iSCSI VTL | S3 plus S3 Glacier | Replace physical tape backups with virtual tape |
Best Practices
1. Match the gateway type to the access pattern
├── File shares as objects: File Gateway (NFS/SMB)
├── Block volumes mounted as disks: Volume Gateway (iSCSI)
└── Backup software writing tapes: Tape Gateway (VTL)
2. Pick the Volume Gateway mode by where primary data must live
├── Cached: keep primary data in S3, small local cache
└── Stored: keep full dataset local, async snapshots to S3
3. Size the local cache and upload buffer correctly
└── Undersized cache causes cache misses and slow reads
4. Use S3 lifecycle policies on File Gateway buckets
└── Transition aging objects to S3 Glacier tiers automatically
5. Archive Tape Gateway tapes to S3 Glacier Deep Archive
└── Lowest-cost retention for long-term compliance copies
6. Protect data with encryption and least-privilege IAM
├── TLS in transit, default encryption at rest in AWS
└── Scope the gateway IAM role to the target bucket onlyCommon Pitfalls
Pitfall 1: Using File Gateway for Block Workloads
Mistake: Choosing File Gateway for a database or application that needs a block device mounted as a local disk.
Why it fails: File Gateway exposes NFS and SMB file shares backed by S3 objects, so it cannot present an iSCSI block volume that block-level workloads require.
Correct Approach: Use Volume Gateway, which serves iSCSI block volumes, and pick cached or stored mode based on where the primary copy must live.
Pitfall 2: Confusing Cached and Stored Volume Modes
Mistake: Assuming stored volumes keep most data in the cloud, or that cached volumes keep a full local copy.
Why it fails: Cached volumes keep primary data in S3 with only hot data local, while stored volumes keep the entire dataset on local disk and send snapshots to S3 for backup. Swapping them leads to wrong capacity and DR planning.
Correct Approach: Choose cached to minimize local storage and scale into S3, and choose stored when low-latency access to the full dataset on-premises is required with cloud backups.
Pitfall 3: Building a Custom Tape Replacement Instead of Tape Gateway
Mistake: Scripting custom S3 uploads to replace physical tape backups instead of using the purpose-built service.
Why it fails: Existing backup applications expect a tape library interface (drives and a media changer), so a custom S3 pipeline forces rework and loses backup-software integration.
Correct Approach: Deploy Tape Gateway, which presents a Virtual Tape Library over iSCSI so backup software writes virtual tapes that land in S3 and archive to S3 Glacier.
Pitfall 4: Undersizing the Local Cache Disk
Mistake: Allocating a small cache disk for a cached Volume Gateway or File Gateway with a large active dataset.
Why it fails: When the working set exceeds the cache, reads miss and must fetch from S3, which increases latency and can stall applications.
Correct Approach: Size the cache to hold the active working set and monitor cache hit metrics in Amazon CloudWatch, expanding the cache disk as the working set grows.
Test Your Knowledge
A media company wants on-premises applications to write files over SMB while storing each file as a durable object in Amazon S3 so it can apply lifecycle policies and access content through the S3 API. Which Storage Gateway type fits best?
A bank keeps its entire transaction dataset on local disk for the lowest read latency but needs asynchronous point-in-time backups copied to AWS for disaster recovery. Which option meets these needs?
An enterprise wants to retire its physical tape library and offsite tape shipping while keeping its existing backup software unchanged and archiving long-term tapes at the lowest cost. Which solution should the architect recommend?
Related Services
Quick Reference
Limits and Capacities
Storage Gateway Quick Facts
| Item | Detail |
|---|---|
| File Gateway protocols | NFS and SMB |
| Volume Gateway protocol | iSCSI block volumes |
| Tape Gateway protocol | iSCSI Virtual Tape Library (VTL) |
| Cached volume max size | 32 TB per volume (1,024 TB total) |
| Stored volume max size | 16 TB per volume (512 TB total) |
| Volume Gateway backups | Point-in-time EBS snapshots stored in S3 |
| Tape archive tiers | S3 Glacier Flexible Retrieval and S3 Glacier Deep Archive |
| Deployment options | VMware ESXi, Hyper-V, Linux KVM, hardware appliance, or EC2 |
Common CLI Commands
# List the gateways in a region
aws storagegateway list-gateways --region us-east-1
# Describe a gateway and its configuration
aws storagegateway describe-gateway-information \
--gateway-arn arn:aws:storagegateway:us-east-1:123456789012:gateway/sgw-12A3456B
# Create an NFS file share backed by an S3 bucket (File Gateway)
aws storagegateway create-nfs-file-share \
--client-token token123 \
--gateway-arn arn:aws:storagegateway:us-east-1:123456789012:gateway/sgw-12A3456B \
--location-arn arn:aws:s3:::my-fileshare-bucket \
--role arn:aws:iam::123456789012:role/StorageGatewayRole
# Create a cached iSCSI volume (Volume Gateway)
aws storagegateway create-cached-iscsi-volume \
--gateway-arn arn:aws:storagegateway:us-east-1:123456789012:gateway/sgw-12A3456B \
--volume-size-in-bytes 107374182400 \
--target-name app-data \
--network-interface-id 10.0.1.50 \
--client-token token456
# Create a virtual tape for archiving (Tape Gateway)
aws storagegateway create-tapes \
--gateway-arn arn:aws:storagegateway:us-east-1:123456789012:gateway/sgw-12A3456B \
--tape-size-in-bytes 107374182400 \
--client-token token789 \
--num-tapes-to-create 1 \
--tape-barcode-prefix TAPE