100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace
AWS

AWS Storage Gateway Overview

See how AWS Storage Gateway bridges on-premises applications to S3, EBS snapshots, and Glacier using File, Volume, and Tape gateway modes.

StorageIntermediate8 min readJul 10, 2026
Analogies

Bridging On-Premises Storage and AWS

AWS Storage Gateway is a hybrid-cloud service: it deploys as a virtual machine (or a physical hardware appliance) inside your on-premises data center, or as an EC2 instance, and presents standard storage protocols — NFS/SMB file shares, iSCSI block volumes, or a virtual tape library (VTL) interface — to your existing applications, while transparently storing the actual data in AWS behind the scenes. This lets legacy applications that were never written with cloud APIs in mind gain the durability and elasticity of S3, EBS snapshots, or Glacier without any application code changes, because from the application's point of view it's just talking to a familiar local file share or block device.

🏏

Cricket analogy: It's like a translator standing pitch-side who lets an English-only commentator (the legacy app) call a match in Hindi for the local broadcast (AWS) without the commentator changing a single word of how they work — Storage Gateway does the protocol translation invisibly.

The Three Gateway Types

S3 File Gateway presents an NFS or SMB file share backed directly by an S3 bucket, so files written locally appear as native S3 objects (accessible by other AWS services immediately), with a local cache keeping recently used data fast to access. Volume Gateway presents iSCSI block volumes and comes in two flavors: Cached mode keeps only frequently accessed data locally while the full volume lives in S3-backed storage in AWS (good for large volumes where local disk is limited), while Stored mode keeps the entire volume on-premises for low-latency local access and asynchronously backs it up as EBS snapshots to AWS (good for disaster recovery of a fully local dataset). Tape Gateway presents a virtual tape library (VTL) that integrates with existing backup software (NetBackup, Veeam, and similar) using the iSCSI-VTL interface, replacing physical tape drives while archiving virtual tapes to S3 and Glacier.

🏏

Cricket analogy: It's like a team keeping only star players' recent form stats on hand at the ground (Cached Volume Gateway) versus keeping the entire squad's full historical data pitch-side while still mirroring it to head office (Stored Volume Gateway), and separately keeping old season archives on physical tape shipped off to storage (Tape Gateway).

bash
# Activate a deployed Storage Gateway VM and configure it as an S3 File Gateway
aws storagegateway activate-gateway \
  --activation-key ABCD1-EFGH2-IJKL3-MNOP4-QRST5 \
  --gateway-name onprem-file-gw-01 \
  --gateway-timezone GMT-5:00 \
  --gateway-region us-east-1 \
  --gateway-type FILE_S3

# Create an NFS file share backed by an S3 bucket
aws storagegateway create-nfs-file-share \
  --client-token nfs-share-token-01 \
  --gateway-arn arn:aws:storagegateway:us-east-1:123456789012:gateway/sgw-1234ABCD \
  --location-arn arn:aws:s3:::onprem-backup-bucket \
  --role arn:aws:iam::123456789012:role/StorageGatewayRole

Choosing a Gateway Type and Common Pitfalls

Choose S3 File Gateway when you want on-premises applications to write files that other AWS services (analytics, machine learning pipelines, S3 lifecycle policies) can consume as first-class S3 objects. Choose Volume Gateway (Cached or Stored) when an application needs a block device via iSCSI rather than a file share, such as a legacy database expecting a local disk. Choose Tape Gateway specifically to retire physical tape infrastructure while keeping existing backup software workflows unchanged. In every mode, the local gateway appliance's cache size and your site's upload bandwidth are the real throughput bottleneck, not AWS itself, so undersized cache disks or a slow WAN link are the most common cause of poor performance and should be sized against your actual working-set and change-rate before going live.

🏏

Cricket analogy: It's like a stadium choosing floodlights (File Gateway, general-purpose lighting for everyone) versus a dedicated spotlight rig for the pitch report camera (Volume Gateway, purpose-built for one specific need) versus archiving old broadcast tapes to a storage facility (Tape Gateway) — the wrong choice, or too small a generator (bandwidth/cache), ruins the whole setup.

All Storage Gateway data is encrypted in transit (TLS) and at rest in AWS (SSE-S3 or SSE-KMS depending on configuration). CloudWatch metrics like CacheHitPercent and CachePercentDirty are the key signals for diagnosing whether your local cache is undersized for the working set.

Stored Volume Gateway keeps the primary copy of data on-premises with only asynchronous EBS-snapshot backups going to AWS — if you need AWS to be the durable primary copy (e.g., to shrink your on-prem footprint), choose Cached Volume Gateway or S3 File Gateway instead, not Stored mode.

  • Storage Gateway is a hybrid appliance (VM, hardware, or EC2) that lets on-prem apps use AWS storage via familiar protocols.
  • S3 File Gateway exposes NFS/SMB shares backed directly by S3 objects.
  • Volume Gateway exposes iSCSI block volumes in Cached mode (AWS is primary, local is cache) or Stored mode (on-prem is primary, AWS holds snapshots).
  • Tape Gateway exposes a virtual tape library (VTL) for existing backup software, archiving virtual tapes to S3/Glacier.
  • The local cache size and WAN bandwidth, not AWS, are typically the real performance bottleneck.
  • All modes encrypt data in transit (TLS) and at rest in AWS.
  • Choose gateway type based on whether the app needs files, block volumes, or a tape-backup interface, and whether AWS or on-prem should hold the primary copy.

Practice what you learned

Was this page helpful?

Topics covered

#AWS#AWSFundamentalsStudyNotes#CloudComputing#AWSStorageGatewayOverview#Storage#Gateway#Bridging#Premises#StudyNotes#SkillVeris