Storage Gateway: File, Volume and Tape

By the end of this lesson you will be able to

• Explain why companies run hybrid storage, place every AWS storage service on the block / file / object map, and say why S3 needs a gateway on premises when EFS does not.
• Describe the Storage Gateway family (S3 File Gateway, FSx File Gateway, Volume Gateway in cached and stored mode, Tape Gateway): the protocol each speaks on premises, where the data lives in AWS, and what AWS can do with it.
• Predict how a gateway’s local cache and upload buffer behave: write-back, cache hits and misses, eviction, a full cache during a link outage, stale listings, and why dirty data matters.
• Follow a virtual tape from creation to Glacier Deep Archive and back, with retrieval times, read-only retrieved tapes, WORM tapes and Tape Retention Lock.
• Deploy and run a gateway: VM or EC2 host (and the end of the hardware appliance), activation, private paths over Direct Connect, bandwidth schedules, monitoring, high availability and pricing.
• Pick the right answer in exam scenarios: S3 File Gateway vs FSx for Windows File Server, cached vs stored volumes, Tape Gateway, DataSync.

#Hybrid cloud for storage

#Why part of the storage stays on premises

AWS pushes hybrid cloud: part of your infrastructure runs in AWS, part stays in your own building. That is not a failure to migrate. It happens for ordinary reasons:

• Long migrations. A bank with 300 applications cannot move them all in one year. For years, some servers stay in the data centre and still need storage.
• Security requirements. Some systems must stay inside the building, for example the core banking servers, while their backups may go to the cloud.
• Compliance requirements. A regulator may require that certain records are kept on premises, or that a copy exists outside the city.
• IT strategy. A company may decide to keep its factories running on local servers, so production never stops when the internet does, but use the cloud for backup, archive and analytics.

Lesson 10.11 (paths to S3: the bulk paths) met S3 File Gateway as “path 6” and saw the rest of the family in one paragraph each. This lesson is the deep dive: how the cache really behaves, the two volume modes, the life of a virtual tape, how a gateway is deployed and what goes wrong.

#The cloud-native storage map: block, file, object

Before choosing a gateway, place every storage service on the map. There are three ways to store data, and each speaks a different language:

Now the problem is easy to see. A Linux server on premises can mount EFS directly over NFS (through Direct Connect or a VPN), because EFS speaks NFS. S3 does not. S3 is a proprietary object API: a file server, a database or backup software built for disks and shares cannot write to it without changes. So how do you expose S3 data on premises, or put on-premises data into S3 without rewriting the applications? AWS Storage Gateway.

#Three words first: NFS, SMB and iSCSI

The owner’s notes explain the first two with office scenes (lesson 10.11 has them in full):

• NFS (Network File System) is the Linux and Unix way of sharing files. Five Linux computers in an office: a folder on computer 1 is used by the other four as if it were on their own disk.
• SMB (Server Message Block) is the Windows way. Right-click a folder, Properties → Sharing → Share: that is SMB. A central Windows server shares folders and printers with every PC.
• Microsoft Active Directory (AD) is the central list of users for a Windows network. In a company of 500 staff, nobody sets a password on each PC. AD keeps all 500 usernames and passwords; when someone logs in at any PC, the PC asks AD “is this person real?”, and AD also decides who may open which folder or use which printer.

The notes never explain the third word, and Volume and Tape Gateway depend on it:

• SCSI is the old, standard language a computer uses with its disks and tape drives: “read blocks 1,000 to 1,007”, “write these blocks”, “load the tape in slot 4”.
• iSCSI sends the same SCSI commands over an IP network. The server runs an initiator; the storage offers a target. Once connected, the server sees a new local disk (or a tape drive) and does not know or care that it is across the network. Optional CHAP authentication makes the initiator prove it knows a shared secret.

#What Storage Gateway is

#A bridge with a local cache

AWS Storage Gateway is a hybrid storage service: a bridge between on-premises data and cloud data. You run a small gateway appliance (a VM) in your building. Your servers talk to it with the protocols they already know (NFS, SMB or iSCSI), and it talks to AWS over HTTPS. The data ends up in AWS storage (S3, S3 Glacier, EBS snapshots), while a local cache on the appliance keeps recently used data close for low latency.

The slides list four use cases, and each gateway type serves some of them:

• Disaster recovery: volume snapshots in AWS can be restored to EC2 if the building is lost.
• Backup and restore: Tape Gateway and volume snapshots replace off-site tapes.
• Tiered storage: hot data in the local cache, everything in S3, cold data moved to Glacier by lifecycle rules.
• On-premises cache and low-latency file access: users open recent files at local speed while the master copy is in AWS.

#The family at a glance

The notes say there are three types. Today there are four, one of them closed to new customers:

Two facts in this table catch people out:

• Only S3 File Gateway writes into your own bucket as normal objects. Volume and tape data is stored in S3 by the service; you cannot open it in the S3 console.
• Volume Gateway backs up as EBS snapshots in both modes, cached and stored. The notes mention snapshots only for stored volumes.

#Amazon S3 File Gateway in depth

#The exam question from the notes

The notes work through a classic question: a company has a large dataset in S3, and on-premises servers must use it with their normal file protocols. The answer is S3 File Gateway, and the reasoning is worth knowing step by step:

1. S3 is object storage that works over HTTP and HTTPS (a REST API). The office servers do not speak that API; they speak local file sharing, NFS or SMB.
2. You install File Gateway (a VM) in the office.
3. It talks NFS or SMB with the local servers.
4. The servers think they are reading and writing a local disk or NAS.
5. Behind the scenes, File Gateway translates each file into an S3 object and stores it in the bucket, or fetches it back, over the internet (or Direct Connect).
6. To control who may see or change the files, it can join the office’s Microsoft AD (for SMB shares).

The notes sum up its biggest advantage: the data really lives in S3 (unlimited and cheap), but the local servers believe it is local.

#The cache: write-back and read-through

The cache is what makes a File Gateway feel local, and most of its problems come from it too. Lesson 10.11 showed a hit and a miss; here is the full behaviour.

• Writes are write-back. A write is stored on the cache disk and acknowledged at once. The data is now dirty: it exists only on premises. The gateway uploads it to S3 asynchronously, and only the changed parts of a file travel when it is edited.
• Reads are read-through. A read is served from the cache if the data is there (a hit). If not (a miss), the gateway fetches only the requested parts from S3, returns them and keeps them in the cache.
• Eviction is least recently used, and clean only. When the cache is full, the gateway removes the least recently used data that is already in S3. It never evicts dirty data, because that would lose it.
• Size it for both. The cache must hold the hot working set (what people read every week) plus all dirty data that can pile up: a busy day on a slow link, or an outage. Cache size per gateway is 150 GiB minimum, 64 TiB maximum; add disks, never resize a disk already in use.
• Watch three CloudWatch metrics. CachePercentDirty (how much is not yet uploaded), CacheHitPercent (how many reads the cache answers) and CachePercentUsed. A dirty share that stays high means the link cannot keep up.

If the cache fills with dirty data, there is nothing left to evict, so the gateway slows down new writes until uploads catch up. Users see saves hang. The office link going down does not stop the share at once; a full cache of unuploaded data does.

#Files, objects and metadata

The mapping from files to objects is simple, and its details matter for cost:

• One file becomes one object. The file’s path becomes the object key (designs/2026/kurta-17.dxf). Folders become folder objects, as in the S3 console.
• File metadata goes into object metadata: owner, group, permissions (POSIX for NFS, Windows ACLs for SMB) and timestamps, so the share looks the same after a cache refresh or on another gateway.
• Partial changes upload efficiently, but a rename or a metadata change rewrites the object: S3 has no rename, so the gateway copies and deletes. Renaming a folder of 100,000 files means 100,000 copies.
• With versioning on the bucket, every save and every metadata change creates a new version. Add a lifecycle rule that expires noncurrent versions, or the bill grows silently.
• Maximum file size is 5 TiB, the largest S3 object.

#Storage classes and Glacier behind a share

A file share writes new objects into S3 Standard (the default), Standard-IA, One Zone-IA or Intelligent-Tiering. It cannot write straight into the Glacier classes, and it does not support Glacier Instant Retrieval at all. Three traps:

• IA classes and edits. Standard-IA and One Zone-IA have a 30-day minimum. Because metadata changes recreate the object, writing directly to IA from a busy share can cause early-deletion charges. AWS recommends writing to Standard and letting a lifecycle rule move objects later.
• Glacier through lifecycle. A lifecycle rule (lesson 10.5) can move objects to Glacier Flexible Retrieval or Deep Archive. Those files still appear in the share, but reading or updating one gives an I/O error until the object is restored in S3. Catch the error with an EventBridge rule and restore automatically if needed.
• Intelligent-Tiering archive tiers. Do not turn on the optional Archive Access or Deep Archive Access tiers for a gateway bucket: files there make the share time out.

#Who may open what: security on a file share

• AWS side. Each file share has an IAM role that lets the gateway read and write its bucket (or a prefix). Data is encrypted in transit with TLS and at rest with SSE-S3 by default, or SSE-KMS with your key (lesson 10.8).
• NFS shares trust client IP ranges: only listed networks may mount, with root squash options as on any NFS server. NFS does not use AD.
• SMB shares can use Active Directory (the gateway joins your domain; users log in with domain accounts and Windows ACLs apply), or guest access with one password for simple cases. SMB v3 can encrypt traffic on the office network too.
• AD is a dependency. If the gateway cannot reach a domain controller, new SMB sessions fail even though the data is fine. Give it at least two domain controllers.
• Audit logs of who opened, changed or deleted which file can go to CloudWatch Logs.

#When something else writes to the bucket

A gateway keeps its own cached view of each folder. If an application writes, changes or deletes objects directly in S3, the share does not show the change until the gateway refreshes its cache:

• call RefreshCache (on demand, or from a schedule), or
• turn on automated cache refresh with a time limit (for example 5 minutes): after that, the gateway re-reads a folder from S3 when it is accessed.

The opposite direction has a feature too: file upload notifications send an EventBridge event when a file written through the share has been fully uploaded to S3, so a cloud workflow (Lambda, Step Functions) can start processing only when the object is complete.

And one hard rule: there is no locking between gateways, or between a gateway and a direct S3 writer. Two offices can read the same bucket through two gateways, but if both edit the same file, the last upload silently wins. Give each office its own prefix for writing.

#S3 File Gateway or FSx for Windows File Server?

The notes give the deciding question:

#FSx File Gateway, briefly

Amazon FSx File Gateway put a local SMB cache in branch offices in front of an FSx for Windows File Server share, so users far from the Region got local speed. AWS stopped offering it to new customers on 28 October 2024; existing customers can keep using it. For new designs, users connect to FSx for Windows directly over Direct Connect or VPN, or use S3 File Gateway when the data belongs in S3. The exam may still list it; recognise the name.

#Volume Gateway

#Block storage over iSCSI

Volume Gateway presents block storage volumes to your servers over iSCSI. A Windows server sees a new disk and formats it with NTFS; a Linux server formats it with ext4. A database can put its data files on it. The gateway stores the volume data in S3 (in storage the service manages, not your bucket) and backs it up as EBS snapshots, which can restore on-premises volumes or create EBS volumes for EC2.

It comes in two modes, and the difference is where the primary copy lives.

#Cached volumes: primary data in AWS

• The full volume lives in S3. The gateway’s local disks hold a cache of recently used blocks and an upload buffer for writes on their way to AWS.
• Writes go to the cache and upload buffer, are acknowledged, then uploaded. Reads of hot blocks are local; reads of cold blocks are fetched from S3 (slower).
• Up to 32 TiB per volume, 32 volumes per gateway, 1,024 TiB in total.
• Why pick it: a site with little local storage needs large volumes, and most of the data is rarely read. You buy disks only for the cache, not for the whole volume.

#Stored volumes: primary data on premises

• The full volume stays on the gateway’s local disks, so every read and write is local: the lowest latency.
• Changed blocks pass through an upload buffer and go to AWS asynchronously, as point-in-time snapshots (EBS snapshots, incremental), on a schedule or on demand.
• Up to 16 TiB per volume, 32 volumes per gateway, 512 TiB in total.
• Why pick it: the application needs local speed for everything and the company wants durable off-site backups. The trade-off: AWS holds only snapshots, so data written since the last snapshot exists only in the building.

#Snapshots and recovery

Both modes create EBS snapshots of a volume, on a schedule (for example every night) or on demand, and AWS Backup can manage them. With a snapshot you can:

• restore an on-premises volume: create a new gateway volume from the snapshot, on the same or a new gateway;
• move to the cloud: create an EBS volume from the snapshot and attach it to an EC2 instance. This is how a Volume Gateway becomes disaster recovery: if the office is lost, the database runs on EC2 from last night’s snapshot. (A snapshot of a cached volume larger than 16 TiB can be restored only to a gateway volume, not to EBS.)
• clone a cached volume from an existing one for testing.

Your recovery point is the snapshot schedule: with nightly snapshots, up to a day of writes can be lost if the building and the gateway are lost together (RPO and RTO are covered in chapter 23).

#When the upload buffer fills

The upload buffer (150 GiB to 2 TiB per gateway) is a staging area for data on its way to AWS. If a stored volume’s buffer fills, because writes are heavy and the link is slow, the volume goes into pass-through: the server keeps working, but the gateway stops tracking what still needs uploading. When space returns, the gateway must bootstrap, reading the whole volume to find the changes, and snapshots are not current until it finishes. Size the buffer for your busiest day and alarm on UploadBufferPercentUsed. On a cached volume, a full buffer slows down writes instead.

#Tape Gateway

#Why companies still use tapes

The notes explain tape from the beginning. Remember audio cassettes and the video cassettes of old, where songs and films were recorded on a magnetic strip? Big companies and banks back up their huge data, such as ten years of transaction records, on very modern and very large versions of the same thing: LTO tape cartridges. Why tapes?

• Very cheap: tape costs far less per terabyte than hard disks or SSDs.
• Long-term: hard disks fail, but data written on a magnetic tape easily lasts 10 to 30 years.
• Security (air-gapped): written tapes are taken offline to a secure vault or another city, for example to a company like Iron Mountain. Hackers and ransomware cannot reach a tape sitting on a shelf.

The problem is handling. When tapes fill up, people must load new ones; trucks carry tapes from place to place; vaults and warehouses cost space and money; and a restore of an old backup takes days.

#What Tape Gateway is

Tape Gateway removes the physical handling and keeps the process. The notes describe it well:

• It is software, a virtual appliance, that you install on your local servers (on VMware, Hyper-V or KVM, or on EC2).
• It is a virtual tape library (VTL): on your network it pretends to be a physical tape drive and a robotic tape library.
• It uses the iSCSI interface. Your company may already own expensive backup software (Veeam, Veritas NetBackup, Commvault and other leading products) that only knows how to work with tape machines over iSCSI. Tape Gateway connects to it the same way.
• Keep the same software. Because the gateway introduces itself as a tape library, the backup software cannot tell whether it is writing to physical tapes or to the cloud. It keeps working as before; nothing new to buy or learn.
• Virtually infinite storage. Instead of tape cartridges, the data goes over the network to AWS. You never run out of tapes.

#How the virtual tape library works

Each Tape Gateway comes with one media changer (the robot) and 10 tape drives, presented as iSCSI devices. You create virtual tapes with barcodes, each from 100 GiB to 15 TiB. One gateway holds up to 1,500 tapes or 1 PiB in its library at a time; the archive behind it has no limit.

Like the other gateways, it has local disks: a cache (150 GiB to 64 TiB) and an upload buffer (150 GiB to 2 TiB). The backup software writes to a virtual tape; the gateway stores the data in both, acknowledges, and uploads it asynchronously to the tape in S3.

#The life of a virtual tape

1. Create a tape (console, API or automatically when the pool runs low). It appears in the library as Available.
2. Write: the backup job loads it into a drive through the media changer and writes. The data is uploaded to S3, where the tapes of the library live.
3. Eject (export) = archive. When the backup software ejects a tape, the gateway moves it to the archive (the virtual tape shelf), backed by S3 Glacier Flexible Retrieval or S3 Glacier Deep Archive, depending on the tape’s pool. The notes say backups go “directly to S3 Glacier”; precisely, they are stored in S3 first and archived on eject.
4. Retrieve. An archived tape cannot be read directly. You retrieve it to a gateway: typically 3 to 5 hours from Glacier Flexible Retrieval, typically within 12 hours from Deep Archive. The retrieved tape is read-only.
5. Delete when the retention period ends. Archived tapes have a minimum charge period (90 days in Glacier Flexible Retrieval, 180 days in Deep Archive), like the storage classes behind them.

#Protecting tapes from deletion

Air-gapped tapes protect against ransomware because nobody can reach them. Virtual tapes get two features for the same goal:

• WORM tapes (write once, read many), set when the tape is created: data on an active tape cannot be overwritten or erased, only appended.
• Tape Retention Lock on a custom tape pool: archived tapes cannot be deleted or moved for a fixed period, up to 100 years, in governance mode (users with special permission can remove the lock) or compliance mode (nobody can, not even the root user).

#Deploying and running a gateway

#Where the gateway runs

A gateway is software. You can run it:

• On premises as a VM on VMware, Microsoft Hyper-V, Linux KVM or Nutanix. The minimum is 4 vCPUs, 16 GiB of RAM and an 80 GiB system disk, plus separate disks for the cache (and the upload buffer for volume and tape gateways). The link to AWS must be at least 100 Mbps to download, activate and update the gateway.
• In AWS as an EC2 instance from the Storage Gateway AMI (an xlarge or larger x86 instance). Useful for disaster recovery (a gateway in the cloud that mounts the same data), for EC2 applications that need NFS or iSCSI over S3, and for testing. Do not put the cache on instance store: if the instance stops before uploads finish, that data is lost.
• As a hardware appliance: a 1U server with the gateway preinstalled, for sites with no virtualisation. It is no longer sold since 12 May 2025; existing appliances are supported until May 2028. Lesson 10.11 and older courses still list it; for new designs use a VM or EC2.

#Activation and the network path

1. Deploy the VM and attach its disks.
2. Activate it: the console reaches the VM once on port 80 to get an activation key, choosing the Region and the endpoint type. Port 80 is needed only during activation.
3. From then on the gateway connects outbound on HTTPS 443 to the Storage Gateway service and to S3. Nothing needs to come in from AWS.

The endpoint type decides the path:

The gateway can also use dual-stack (IPv4 and IPv6) endpoints. On the office side, open only what clients need: NFS 2049 (plus 111 and 20048 for NFS v3), SMB 445, iSCSI 3260, and the AD ports for an SMB share.

#Bandwidth, maintenance and monitoring

• Bandwidth rate limits and schedules: cap uploads (and downloads) at, for example, 50 Mbps from 9 a.m. to 6 p.m. and lift the cap at night. Writes still land in the cache at full speed; only uploads slow down, so the cache must hold a day of dirty data.
• Maintenance window: AWS releases gateway software updates, which install in a weekly window you choose. A gateway restarts briefly during updates, so pick a quiet hour.
• CloudWatch metrics and alarms: CachePercentDirty, CacheHitPercent, CachePercentUsed, UploadBufferPercentUsed, and the health of the gateway itself. Gateway logs and file share audit logs can go to CloudWatch Logs.

#High availability and failure

A gateway is one VM: if its host fails, every share, volume or tape drive on it stops answering. Two defences:

• Run it on a VMware vSphere High Availability cluster with disks on shared storage. Storage Gateway integrates with VMware HA: if the host or the gateway fails, the VM restarts on another host within minutes, and the cache disk with its dirty data survives.
• Protect the cache disk like any production disk. Dirty data exists nowhere else; if the cache disk is lost, the unuploaded data is lost too. For a lost gateway VM, you activate a new gateway and recover the data from AWS (for volumes, from the latest snapshot or recovery point); cloning a gateway VM from a snapshot is not supported.

#How big a cache, and can the link keep up?

The two questions every gateway design must answer. Try your own office’s numbers:

#Pricing

You pay for:

• Data written to AWS by the gateway: about $0.01 per GB, capped at $125 per gateway per month; the first 100 GB per account are free.
• Storage in AWS: S3 objects at normal S3 prices for a File Gateway; volume storage and EBS snapshot storage for a Volume Gateway; virtual tapes in S3, and archived tapes at Glacier Flexible Retrieval or Deep Archive prices (about $1 per TB per month), for a Tape Gateway.
• Requests and retrievals: S3 requests, tape retrievals from the archive, and early deletion for archived tapes.
• Data transfer out of AWS when data is read back to the office, at normal internet or Direct Connect rates; data to a gateway on EC2 in the same Region is free.
• The host: your own hardware for a VM, or the EC2 instance and its EBS volumes.

#Storage Gateway and the alternatives

The notes compare it with DataSync, and the difference is the most useful sentence in this chapter: Storage Gateway is a continuous storage extension (it becomes part of your local storage and stays in the data path), while DataSync is a tool that copies or permanently migrates data from one place to another and then steps away. They are often used together: DataSync for the first bulk copy of years of files, then a File Gateway for the applications that keep writing.

Test yourself on real scenarios:

#What goes wrong

#Storage Gateway in system design

• Cloud-backed file shares for offices and factories: S3 File Gateway in each site, one bucket behind them, each site writing its own prefix, lifecycle rules for archive. The files are available to analytics, ML and other AWS services as soon as they upload (file upload notifications can start a pipeline).
• Tiered storage for a hospital or a newsroom: hot data in the cache, all data in S3, cold data in Glacier, and the application never changes.
• Backup and disaster recovery: stored volumes or Tape Gateway for off-site copies; EBS snapshots restored to EC2 when the site is lost (backup and DR services, chapter 23).
• Retire the tape library: Tape Gateway with Deep Archive pools and Tape Retention Lock for long regulatory retention.
• Migration with a bridge: DataSync or Snowball for the bulk, a gateway while applications are still on premises, then a move to native AWS storage (S3, EFS, FSx) when they migrate.
• Private and controlled: VPC endpoints over Direct Connect when data must not cross the internet; SSE-KMS keys you control; IAM roles per share.

#Try it yourself

These commands use example ARNs and names. Run them against a test gateway (a VM or an EC2 instance from the Storage Gateway AMI) that you have already deployed.

# 1. Activate a gateway as an S3 File Gateway, after getting the key from port 80
aws storagegateway activate-gateway --activation-key ABCD1-EFGH2-IJKL3-MNOP4-QRST5 \
  --gateway-name gazipur-design --gateway-timezone GMT+6:00 \
  --gateway-region ap-southeast-1 --gateway-type FILE_S3
#   "GatewayARN": "arn:aws:storagegateway:ap-southeast-1:111122223333:gateway/sgw-12A3456B"

# 2. Find the local disks and make one of them the cache
aws storagegateway list-local-disks --gateway-arn arn:aws:storagegateway:ap-southeast-1:111122223333:gateway/sgw-12A3456B
#   "Disks": [{ "DiskId": "pci-0000:03:00.0-scsi-0:0:1:0", "DiskSizeInBytes": 2199023255552,
#               "DiskAllocationType": "AVAILABLE" }]
aws storagegateway add-cache --gateway-arn <gateway-arn> \
  --disk-ids pci-0000:03:00.0-scsi-0:0:1:0

# 3. Join Active Directory, then create an SMB share that uses it, with automated cache refresh
#    every 300 seconds and a notification when each file has finished uploading
aws storagegateway join-domain --gateway-arn <gateway-arn> --domain-name corp.example.com \
  --user-name svc-sgw --password '<password>' --domain-controllers 10.20.0.10 10.20.0.11
aws storagegateway create-smb-file-share --client-token design-share-1 \
  --gateway-arn <gateway-arn> \
  --role arn:aws:iam::111122223333:role/FileGatewayS3Access \
  --location-arn arn:aws:s3:::garments-designs-example \
  --authentication ActiveDirectory --valid-user-list @Design \
  --default-storage-class S3_STANDARD \
  --cache-attributes CacheStaleTimeoutInSeconds=300 \
  --notification-policy '{"Upload":{"SettlingTimeInSeconds":60}}'
#   "FileShareARN": "arn:aws:storagegateway:ap-southeast-1:111122223333:share/share-5F7D8E9A"

# 4. After an app writes straight into the bucket, refresh one folder now
aws storagegateway refresh-cache --file-share-arn <share-arn> --folder-list /2026/ --recursive

# 5. Volume Gateway: a 20 TiB cached volume and a nightly snapshot schedule
aws storagegateway create-cached-iscsi-volume --gateway-arn <volume-gateway-arn> \
  --volume-size-in-bytes 21990232555520 --target-name newsroom-archive \
  --network-interface-id 10.30.1.15 --client-token vol-1
#   "TargetARN": "...:gateway/sgw-23B4567C/target/iqn.1997-05.com.amazon:newsroom-archive"
aws storagegateway update-snapshot-schedule --volume-arn <volume-arn> \
  --start-at 1 --recurrence-in-hours 24 --description "nightly"

# 6. Tape Gateway: create ten 2 TiB tapes in a Deep Archive pool, then list the archive
aws storagegateway create-tapes --gateway-arn <tape-gateway-arn> \
  --tape-size-in-bytes 2199023255552 --client-token tapes-1 --num-tapes-to-create 10 \
  --tape-barcode-prefix BNK --pool-id DEEP_ARCHIVE
aws storagegateway describe-tape-archives
#   "TapeArchives": [{ "TapeBarcode": "BNK00042", "TapeStatus": "ARCHIVED",
#                      "PoolId": "DEEP_ARCHIVE", "TapeSizeInBytes": 2199023255552 }]

# 7. Bring an archived tape back to the gateway (read-only), hours not days
aws storagegateway retrieve-tape-archive --tape-arn <tape-arn> --gateway-arn <tape-gateway-arn>

# 8. Limit uploads to 50 Mbps during office hours, Sunday to Thursday
aws storagegateway update-bandwidth-rate-limit-schedule --gateway-arn <gateway-arn> \
  --bandwidth-rate-limit-intervals \
  'StartHourOfDay=9,StartMinuteOfHour=0,EndHourOfDay=17,EndMinuteOfHour=59,DaysOfWeek=[0,1,2,3,4],AverageUploadRateLimitInBitsPerSec=50000000'

# 9. Watch the cache: how much is not uploaded yet?
aws cloudwatch get-metric-statistics --namespace AWS/StorageGateway \
  --metric-name CachePercentDirty --dimensions Name=GatewayId,Value=sgw-12A3456B Name=GatewayName,Value=gazipur-design \
  --start-time 2026-10-26T00:00:00Z --end-time 2026-10-26T12:00:00Z --period 3600 --statistics Maximum

On a Windows PC in the domain, the share is then simply \\10.20.1.15\garments-designs-example. On a Linux server, an iSCSI volume is discovered and mounted with the standard initiator:

sudo iscsiadm --mode discovery --type sendtargets --portal 10.30.1.15:3260
sudo iscsiadm --mode node --targetname iqn.1997-05.com.amazon:newsroom-archive \
  --portal 10.30.1.15:3260,1 --login
lsblk          # a new 20 TiB disk, for example /dev/sdb, ready to format

#Summary

Key takeaways

• Hybrid storage exists because of long migrations, security, compliance and IT strategy. On the storage map, block = EBS, instance store; file = EFS, FSx; object = S3, Glacier. EFS speaks NFS; S3 has its own API, so on-premises servers need Storage Gateway to use it.
• NFS = Linux file sharing, SMB = Windows file sharing, AD = central users and permissions, iSCSI = SCSI disk and tape commands over IP.
• Four gateway types: S3 File Gateway (NFS/SMB → one object per file in your bucket), FSx File Gateway (closed to new customers since October 2024), Volume Gateway (iSCSI, data in S3, EBS snapshots in both modes), Tape Gateway (iSCSI VTL, tapes in S3, archived to Glacier Flexible Retrieval or Deep Archive on eject).
• A File Gateway cache is write-back and read-through; it evicts only clean data, so it must hold the hot set plus all dirty data. Watch CachePercentDirty. Refresh the cache when others write to the bucket; there is no locking between writers.
• File shares write to Standard, IA, One Zone-IA or Intelligent-Tiering, never straight to Glacier; lifecycle moves objects later, and archived files must be restored before reading. Glacier Instant Retrieval is not supported.
• Cached volumes: primary data in S3, hot blocks local, up to 32 TiB. Stored volumes: all data local, asynchronous snapshots, up to 16 TiB. Snapshots restore on premises or become EBS volumes for EC2 (up to 16 TiB).
• Tape Gateway: 10 drives + media changer, tapes 100 GiB–15 TiB, 1,500 tapes / 1 PiB per gateway, unlimited archive. Retrieval 3–5 h (Flexible) or within 12 h (Deep Archive), read-only. WORM tapes and Tape Retention Lock protect them. Keywords: existing backup software, VTL/iSCSI, eliminate physical tapes.
• Deploy as a VM (VMware, Hyper-V, KVM, Nutanix) or EC2; the hardware appliance is no longer sold since May 2025. Activate on port 80, then outbound 443; public, VPC endpoint or FIPS. One gateway is one VM: plan HA and protect the cache disk.
• Price: about $0.01 per GB written, capped at $125 per gateway per month, plus storage. Gateway = continuous extension; DataSync = copy or migrate and step away. Windows + AD with no S3 → FSx for Windows.

Self-check: Storage Gateway31 questions