AWS Storage Gateway and its architecture
Which type of storage gateway to use for your use case, and
How to create a storage gateway using the EC2 platform
Using AWS Storage Gateway(Hybrid Storage Solution)
AWS Storage Gateway is a powerful service that enables hybrid cloud storage by seamlessly connecting on-premises environments with AWS cloud storage. In this blog, we’ll explore AWS Storage Gateway and its architecture, helping you understand how it works and how it fits into modern cloud and hybrid infrastructures.
We’ll also break down the different types of AWS Storage Gateway—File Gateway, Volume Gateway, and Tape Gateway—and discuss which gateway type to choose based on your specific use case.
To make things practical, the blog will walk you through creating and deploying an AWS Storage Gateway using the Amazon EC2 platform, demonstrating how to set up and configure the gateway step by step.
Prerequisites
To get the most out of this guide, you should have a solid understanding of AWS storage services, including:
Amazon S3
Amazon FSx
Amazon EBS
Amazon Glacier
Basic familiarity with Amazon EC2 is also recommended, as it will help you better understand the deployment and configuration steps covered in the hands-on sections.
The AWS Storage Gateway: The Missing Bridge Between On‑Prem and Cloud Fluency
Every hybrid cloud story begins at the same line: “We still have data on‑prem.”
But the real question AWS architects ask isn’t why — it’s how cleanly can we bridge that world to S3, FSx, or Glacier?
There’s a reason the AWS Well‑Architected Framework flags data movement and hybrid storage patterns in almost every cost and operations review. When on‑prem systems start talking to AWS, you either build a bridge — or a bottleneck.
What the Storage Gateway Really Is
Storage Gateway isn’t just a connector. It’s a translator layer that turns your local protocols — NFS, SMB, iSCSI — into native AWS storage semantics.
At its core, it’s a lightweight virtual machine or a hardware appliance that establishes a secure, encrypted data path to AWS. You can deploy it in three ways:
- As a VM on VMware ESXi, Microsoft Hyper‑V, or Linux KVM — ideal for existing datacenter setups.
- As a hardware appliance, pre‑configured and shipped by AWS for plug‑and‑play deployment.
- As an EC2 instance inside your VPC or within VMware Cloud on AWS — perfect for hybrid use cases with cloud‑resident workloads.
Once deployed, the gateway allocates ~150 MB of local disk space for caching. This cache doesn’t just stage uploads — it works as a low‑latency read buffer, shaving milliseconds off retrieval time for your most frequently accessed objects.
The Four Personalities of Storage Gateway
Each gateway type reflects a different file access pattern, not a marketing SKU.
S3 File Gateway
Talk SMB or NFS. Store natively in S3. Perfect for backup workloads, shared datasets, or applications that don’t speak API‑native S3.FSx File Gateway
Serve SMB workloads that demand Windows‑native semantics — think ACLs, DFS namespaces, and domain integration — backed by FSx for Windows File Server.Tape Gateway
The quiet killer of legacy tape libraries. It abstracts your physical tape system into iSCSI‑based virtual tapes, with automatic tiering into Amazon S3 Glacier Flexible Retrieval or Deep Archive.Volume Gateway
The bridge for block‑based applications. It exports iSCSI block volumes backed by EBS snapshots or S3. Great for backup targets or lift‑and‑shift migrations.
Ask yourself: which protocol do your on‑prem workloads truly speak — files, blocks, or tapes?
That one question reveals your gateway type.
The Economics That Actually Matter
AWS pricing psychology: you’re not paying for the box. You’re paying for where your bits live and how they move.
Three line items drive your AWS Storage Gateway cost model:
- Storage pricing — Mirrors the backing service (S3, FSx, etc.).
- Request pricing — Matches the standard S3 or FSx operation costs.
- Data transfer pricing — Free inbound to AWS, but outbound traffic to on‑prem is billed per terabyte transferred.
Pro tip: moving data out of AWS through the Storage Gateway has the same economics as any AWS data egress — so architect for data gravity, not convenience.
When to Use It — and When to Rethink It
If your workload can’t or won’t move fully to the cloud (yet), the Storage Gateway gives you hybrid leverage without rearchitecting everything overnight.
But if every request ends up bouncing between S3 and on‑prem, you may need to rethink placement, not performance.
The best use cases we see in the wild:
- Archival storage for compliance-heavy workloads.
- Hybrid file shares across geographies.
- Tape backup elimination projects.
- Gradual cloud adoption: data first, compute later.
Thought
Every cloud architect eventually realizes this truth: hybrid isn’t transitional — it’s strategic.
The AWS Storage Gateway exists not to extend your datacenter, but to teach it cloud fluency — one NFS mount, one SMB share, one iSCSI target at a time.
Choosing the Right AWS Storage Gateway — A Principal Engineer’s Take
Most hybrid storage decisions don’t fail in architecture. They fail in clarity.
The AWS console gives you four gateway types — S3 File, FSx File, Tape, and Volume. But behind each type lies a philosophy of data motion: how your workloads talk to AWS, how latency collapses, and how cost behaves over time.
Why Storage Gateway Exists
AWS built Storage Gateway for one quiet but urgent reason: most enterprises aren't cloud‑only — they're latency‑bound.
They need to keep data gravity close to compute without giving up cloud durability or cost efficiency.
Storage Gateway bridges that gap. It speaks on‑premises languages (NFS, SMB, iSCSI) while translating natively to AWS storage APIs (S3, FSx, EBS, Glacier).
Think of it as a bilingual edge device — fluent in both legacy infrastructure and cloud semantics.
Scenario 1: Backups and Archives That Refuse to Die On‑Prem
You’ve got Hadoop clusters and SQL databases sitting in your datacenter.
You want backups in the cloud. You don’t want to rebuild your entire pipeline.
Here’s your moment of clarity:
Use S3 File Gateway when you want object control. Use FSx File Gateway when you want Windows consistency. Use Volume Gateway when you want disaster recovery agility.
The trade‑offs are architectural, not cosmetic.
S3 File Gateway:
Stores data natively in S3, with direct access to S3 Object Lock, versioning, and lifecycle management.
Ideal for large files, logs, and database backups that can benefit from cost tiering into Glacier.
Local cache (up to 64 TB) keeps active data hot — ideal for low‑latency reads in analytics or backup workloads.
FSx File Gateway:
Joins your Microsoft Active Directory and feels like any other SMB file system.
Optimized for multi‑user, mixed file workloads — project shares, home directories, or Exchange backups.
Plays well when your org runs Windows clients or third‑party tools expecting full NTFS parity (shadow copies, permissions, DFS).
Volume Gateway:
Perfect for structured data in block storage form.
Lets you back up volumes as EBS snapshots, which you can later restore to EC2 for cloud migration or disaster recovery.
Comes in two flavors:
Cached volumes: Primary data in AWS, frequent reads cached locally.
Stored volumes: Primary data on‑prem, async backups to AWS. (Think “DR‑first architecture.”)
You can decide which to deploy based on one question:
Do you need object features, file semantics, or block storage integration?
Scenario 2: The Tape Archive Nobody Wants to Touch
Here’s the truth every sysadmin quietly knows: tapes die faster than budgets get renewed.
Tape Gateway solves this elegantly. Not with buzzwords — with compatibility.
It creates a virtual tape library (VTL) that plugs directly into your existing backup software (CommVault, NetBackup, IBM, etc.) over iSCSI. For the backup tool, nothing changes. But instead of shipping tapes to dusty warehouses, you’re sending them to Amazon S3 and auto‑archiving to S3 Glacier.
This is hybrid done right: zero cultural resistance, immediate operational gain.
When to Choose Each
The Hidden “Why Now”
Once your backup data lives in AWS, you’ve quietly unlocked optionality.
Today, it’s backup. Tomorrow, it’s pipeline input for analytics or ML.
That’s the real value — AWS turns what used to be retained data into active data.
If your hybrid architecture still treats storage as passive, you’re leaving compounding value on the table.
Final Thought
Each gateway type reflects a philosophy of transition — from legacy to leverage.
The best AWS builders know that hybrid isn't a stopgap; it’s a design state.
Storage Gateway doesn’t replace your infrastructure. It teaches it to speak cloud fluently.
To Do: Hands-On
Configure an AWS S3 File Storage Gateway to test end to end.
Connect an EC2-based NFS file system to an Amazon S3 bucket and verify that files created on EC2 are automatically stored in S3.
- Storage Gateway Configuration
Opened AWS Storage Gateway from the AWS Console
Created a new gateway named sgw-demo
Selected S3 File Gateway
Chose Amazon EC2 as the hosting platform
Selected the appropriate time zone
- Gateway Deployment on EC2
Launched an EC2 instance for the gateway:
Instance name: sgw-demo-instance
Instance type: m5.xlarge (as recommended)
Public IP enabled
Configured a security group with required ports:
22 (SSH)
80 (Gateway activation)
2049, 111, 20048 (NFS)
Added an extra EBS volume (150 GiB+) for cache storage
- Gateway Activation
Used the public IP address of the EC2 instance to activate the gateway
Selected public internet connectivity
Disabled CloudWatch logs and alarms to reduce cost
Allocated cache storage successfully
- NFS File Share Creation
Created a new NFS file share
Linked it to an existing S3 bucket (sgw-bucket-99)
Selected S3 Standard as the storage class
Left cache and permission settings as default
- Mounting the File Share
Connected to a separate EC2 instance (application server)
Created a mount directory: /web-files
Mounted the NFS file share using the provided Linux mount command
Verified the mount using df -h
- Testing the Setup
Created a file index.html inside /web-files
Added sample content to the file
Checked the S3 bucket and confirmed the file appeared there
Downloaded the file from S3 to verify the content
✅ Final Outcome
The NFS file share and S3 bucket were successfully linked
Any file created on the EC2-mounted file system was automatically stored in Amazon S3
This confirms a 1:1 mapping between the NFS file system and the S3 bucket
In simple terms:
Files written on EC2 using NFS were transparently backed up to Amazon S3 using AWS Storage Gateway.
Flow:
On‑prem data (files, volumes, or backups) flows to the Storage Gateway.
The gateway caches frequently accessed data locally for low‑latency access.
Data is securely transferred to AWS storage services (S3, FSx, Glacier, or EBS).
AWS maintains scalable, durable storage and offers lifecycle management, versioning, or snapshotting depending on gateway type.
Administrators monitor and control the entire setup through the AWS Management Console or APIs.
Image Credits Alana Layton
enable FIPS
connect ssh and copy that example command
Top comments (0)