AWS Storage Gateway: File, Volume, and Tape Gateway for Hybrid Storage

2 min readCloud Infrastructure

Storage Gateway bridges on-premises environments and AWS storage. File Gateway exposes S3 as NFS/SMB shares. Volume Gateway provides iSCSI block storage backed by S3 snapshots. Tape Gateway replaces physical tape libraries with VTL. Each type has different caching behavior and failure modes when the WAN link degrades.

awsstorage gateways3hybrid cloud

Three gateway types for three use cases

| Type | Protocol | Backed by | Primary use case | |---|---|---|---| | File Gateway | NFS, SMB | Amazon S3 | On-premises apps reading/writing files to S3 | | Volume Gateway (Stored) | iSCSI | S3 snapshots | Block storage with local primary + cloud backup | | Volume Gateway (Cached) | iSCSI | S3 (primary) | Block storage with low-latency local cache | | Tape Gateway | iSCSI VTL | S3 + Glacier | Replace physical tape backup infrastructure |

Storage Gateway runs as a VM (VMware, Hyper-V, KVM) or hardware appliance on-premises, or as an AMI on EC2.

File Gateway caches frequently accessed files locally — bandwidth and cache size determine latency

ConceptAWS Storage Gateway

File Gateway maintains a local cache of recently accessed and recently written files. Read operations hit the local cache if the file is present; cache misses fetch from S3 over the WAN. Write operations are written to the local cache and asynchronously uploaded to S3. The cache size (configurable on the VM) determines how much data avoids WAN round-trips.

Prerequisites

  • Amazon S3
  • NFS/SMB file protocols
  • WAN connectivity basics

Key Points

  • Local cache must be at least 20% of the S3 storage used for optimal performance.
  • Write-back caching: writes are acknowledged locally before S3 upload completes — fast locally, but data is at risk if the gateway fails before upload.
  • RefreshCache API or console action forces the gateway to scan S3 for changes made outside the gateway (e.g., by other services or direct S3 uploads).
  • Multiple File Gateways can share the same S3 bucket, but simultaneous writes from multiple gateways to the same file cause conflicts.

File Gateway: on-premises access to S3

File Gateway presents an S3 bucket as a network file share. Applications write files using NFS or SMB; the gateway translates these into S3 PutObject calls.

# Terraform: create the gateway (requires an activated gateway appliance ARN)
resource "aws_storagegateway_gateway" "file" {
  gateway_name     = "file-gateway-prod"
  gateway_timezone = "GMT"
  gateway_type     = "FILE_S3"

  smb_active_directory_settings {
    domain_name = "corp.example.com"
    username    = "svc-gateway"
    password    = var.ad_password
  }
}

# Create an S3 file share on the gateway
resource "aws_storagegateway_nfs_file_share" "main" {
  gateway_arn  = aws_storagegateway_gateway.file.arn
  location_arn = aws_s3_bucket.data.arn
  role_arn     = aws_iam_role.storage_gateway.arn

  nfs_file_share_defaults {
    directory_mode = "0770"
    file_mode      = "0660"
    group_id       = 65534
    owner_id       = 65534
  }

  cache_stale_timeout_in_seconds = 300   # how long until cached data expires

  # Restrict access to specific on-prem IP ranges
  client_list = ["10.0.0.0/8"]
}

Mount the share on Linux:

mount -t nfs -o nolock,hard,intr \
  gateway-ip:/my-s3-bucket \
  /mnt/s3-share

The RefreshCache problem: if files are written directly to S3 (via Lambda, another service, or the console), the File Gateway doesn't know about them until you trigger a cache refresh. Applications reading from the mount see stale data until the refresh completes.

# Force cache refresh via CLI
aws storagegateway refresh-cache \
  --file-share-arn arn:aws:storagegateway:us-east-1:123456789:share/share-abc123 \
  --folder-list "/" \
  --recursive true

Volume Gateway: iSCSI block storage

Volume Gateway presents iSCSI block devices. On-premises servers attach these volumes like local disks.

Stored mode: primary data lives on-premises. The gateway continuously snapshots to S3 (EBS snapshots). Recovery creates EBS volumes from snapshots.

Cached mode: primary data lives in S3. The gateway caches frequently accessed blocks locally. The local cache only needs to hold hot data, not the full dataset.

resource "aws_storagegateway_gateway" "volume" {
  gateway_name     = "volume-gateway-prod"
  gateway_timezone = "GMT"
  gateway_type     = "STORED"   # or "CACHED"
}

resource "aws_storagegateway_stored_iscsi_volume" "main" {
  gateway_arn            = aws_storagegateway_gateway.volume.arn
  network_interface_id   = "10.0.1.10"   # gateway NIC IP
  target_name            = "prod-volume"
  disk_id                = "disk-abc123"   # local disk on gateway VM
  preserve_existing_data = false
  snapshot_id            = ""   # or start from an existing snapshot
}
📝Tape Gateway: replacing physical tape with VTL

Tape Gateway emulates a physical Virtual Tape Library (VTL) — a tape changer and tape drives accessible via iSCSI. Existing backup software (Veeam, Backup Exec, NetBackup) connects to the VTL without modification.

Virtual tapes:

  • Active tapes: stored in S3 — fast access (~milliseconds)
  • Archived tapes: stored in S3 Glacier or S3 Glacier Deep Archive — lower cost, retrieval takes hours
resource "aws_storagegateway_gateway" "tape" {
  gateway_name     = "tape-gateway-prod"
  gateway_timezone = "GMT"
  gateway_type     = "VTL"

  tape_drive_type   = "IBM-ULT3580-TD5"   # emulated tape drive model
  medium_changer_type = "AWS-Gateway-VTL"
}

resource "aws_storagegateway_tape_pool" "archive" {
  pool_name     = "glacier-pool"
  storage_class = "GLACIER"   # or "DEEP_ARCHIVE"
  retention_lock_type = "GOVERNANCE"
  retention_lock_time_in_days = 90
}

Tape retrieval from Glacier takes 3-5 hours. Plan backup windows and recovery objectives around this — Tape Gateway is appropriate for compliance archiving and cold backup, not for rapid recovery scenarios.

A team uses File Gateway to give on-premises applications NFS access to an S3 bucket. A Lambda function also writes files directly to the same S3 bucket. On-premises applications sometimes see stale file listings that don't include the Lambda-written files. What causes this?

medium

File Gateway caches directory listings and file content locally. The Lambda function bypasses the gateway and writes directly to S3.

  • AFile Gateway doesn't support buckets that are also written to by other AWS services
    Incorrect.File Gateway supports shared S3 buckets. The issue is cache staleness, not a functional limitation.
  • BFile Gateway's local cache doesn't know about S3 changes made outside the gateway — it caches directory listings and file metadata until cache_stale_timeout expires or RefreshCache is called
    Correct!File Gateway maintains a local cache of directory structure and file metadata. When Lambda writes directly to S3, the gateway cache has no knowledge of the new files — the NFS mount shows the old cached listing. The cache expires based on cache_stale_timeout_in_seconds (default varies by gateway version), or you can force a refresh via the RefreshCache API. For use cases where multiple writers share an S3 bucket, set a short stale timeout or trigger RefreshCache after Lambda writes complete.
  • CLambda must use the gateway's NFS endpoint to write files — direct S3 writes are not supported
    Incorrect.Lambda can write directly to S3. The gateway doesn't enforce exclusive access to the bucket. The staleness is a caching behavior, not an access restriction.
  • DThe NFS cache is invalidated automatically whenever S3 receives a new PutObject event
    Incorrect.File Gateway does not subscribe to S3 event notifications to auto-invalidate its cache. RefreshCache must be triggered explicitly.

Hint:File Gateway's local cache only learns about S3 changes through what mechanism?