Integrating AWS Storage Gateway as an iSCSI target in a VMware ESXi cluster can bridge on-premises infrastructure with virtually unlimited cloud storage. This guide covers the end-to-end process – from setting up your ESXi cluster for iSCSI, deploying and configuring the AWS Storage Gateway VM, to connecting ESXi hosts to the cloud-backed iSCSI volume. We emphasize clarity, 2025 best practices, performance tips, and troubleshooting. Intermediate-level VMware administrators will find actionable steps to successfully add an AWS Storage Gateway iSCSI datastore to their vSphere cluster.
Understanding AWS Storage Gateway and iSCSI Integration
AWS Storage Gateway is a hybrid cloud storage service that presents cloud-backed storage to local environments using standard protocols (NFS, SMB, and in our case iSCSI). In Volume Gateway (cached) mode, it provides iSCSI block storage volumes that cache data locally for low-latency access while asynchronously syncing to AWS. This allows you to use AWS cloud storage for expanding capacity, offsite backups, or disaster recovery, while your VMware servers see the storage as just another iSCSI SAN device on the network.
In our setup, we will use a Volume Gateway in cached mode. The on-premises component is deployed as a VM on ESXi, which will expose an iSCSI target. VMware ESXi hosts (initiators) will connect to this target over the iSCSI network. Once connected, the cloud-backed iSCSI volume can be formatted as a VMware VMFS datastore and used like any other shared storage in the cluster. This hybrid approach gives immediate local storage access with cloud scalability in the background.
Environment Prerequisites
Before diving into the configuration steps, ensure you meet these prerequisites and align with current software versions:
VMware vSphere Environment
A VMware ESXi cluster running a supported version. Using vSphere 8.0 (or later) is recommended for best performance and supportability. All ESXi hosts should be in the same cluster and have network connectivity for iSCSI. Each host needs a VMkernel port configured for iSCSI on the appropriate network (same subnet as the Storage Gateway VM’s IP).
AWS Account
Access to AWS with permissions to use the Storage Gateway service. Make sure you can create Volume Gateways. AWS regularly updates the Storage Gateway appliance software. New Volume Gateway appliances use software version 3.x (based on Amazon Linux 2023) which introduced features like IPv6 support. Always run the latest gateway software for security and fixes.
AWS Storage Gateway Appliance (OVA)
We will deploy the AWS Storage Gateway appliance as a VM on ESXi. Download the latest OVA for Volume Gateway (cached) from AWS. The recommended VM specs are: 4 vCPUs, 16 GB RAM (sufficient for up to ~16 TiB cache), an 80 GB root disk, and at least two additional disks for cache and upload buffer (150 GB each minimum). Use high-performance SSD-backed storage for the cache and buffer disks to improve I/O performance. Thick provisioning is suggested for these disks to avoid latency from dynamic allocation.
Networking
The gateway VM and ESXi hosts must have network connectivity between them on the iSCSI network. Ideally use a high-bandwidth, low-latency network (10 GbE if available) for iSCSI traffic, especially if the datastore will be heavily used. Ensure each ESXi host has a dedicated VMkernel interface with an IP in the same subnet/VLAN as the gateway VM’s IP. ESXi will not route iSCSI traffic across subnets. Also ensure the gateway VM can reach AWS service endpoints either via the internet or via an AWS VPN/Direct Connect. A minimum of 100 Mb/s internet bandwidth is required for initial activation, but a 1 Gb/s or higher link is recommended for ongoing synchronization and throughput.
Time Synchronization
Consistent time is required for the gateway to successfully register with AWS. Synchronize the ESXi host and gateway VM clocks via NTP. AWS advises that the time skew between the gateway VM and actual current time be no more than 60 seconds; otherwise, activation may fail. We will ensure the gateway VM’s time is in sync before attempting activation.
With prerequisites met, let’s move on to the step-by-step process.
Step 1: Prepare the VMware ESXi Cluster for iSCSI
Before adding the AWS Storage Gateway, configure your VMware cluster for iSCSI connectivity:
Network Setup for iSCSI
On each ESXi host, create or identify a network for iSCSI traffic. This typically involves creating a new VMkernel port on a standard vSwitch or distributed vSwitch dedicated to iSCSI. Assign it a static IP address in the same subnet as the planned Storage Gateway VM’s IP. For example, if the gateway VM will use IP 172.16.0.111, ensure each host has an iSCSI VMkernel IP on 172.16.0.x/24 or the corresponding network. Use a high-bandwidth NIC for this VMkernel to match or exceed the gateway’s network capability. It’s good practice to isolate iSCSI traffic on its own VLAN or switch to avoid contention with other traffic. In our example, we use dedicated vSwitches on 10 Gb/s NICs, separate from the 1 Gb/s management network. If no 10 GbE switch is available, hosts can be cross-connected for a high-speed network.
Enable the iSCSI Software Adapter
By default, ESXi may not have the software iSCSI initiator enabled. In the vSphere Client, navigate to Hosts and Clusters > (select a host) > Configure > Storage > Storage Adapters. Click Add Adapter and select Add iSCSI Adapter to create a software iSCSI initiator. A new iSCSI adapter (e.g. vmhba64) will appear. Repeat this on all hosts in the cluster that need to access the Storage Gateway volume.
VMkernel Binding (if needed)
If you have multiple iSCSI VMkernel ports or multiple physical NICs for iSCSI, you may need to bind them to the iSCSI adapter for multipathing. In a simple single-network setup, this usually isn’t necessary beyond the basic network config. Just ensure that each host’s iSCSI VMkernel has network access to the gateway VM. A common mistake is leaving the iSCSI vSwitch with no physical uplink or an isolated network – if the host can’t reach the gateway VM’s IP, it won’t discover the target.
Firewall and Connectivity
ESXi’s firewall allows iSCSI traffic by default, but double-check that the Software iSCSI Client rule is enabled on each host. Also ensure no external firewall is blocking TCP port 3260 between the ESXi hosts and the Storage Gateway VM. At this point, all hosts should be prepared to discover the iSCSI target once it’s available on the network.
Tip: Label your iSCSI network clearly and keep it isolated from management or VM networks to avoid congestion. In our example, we created a dedicated 10 GbE network for storage traffic separate from the general LAN, which is especially important for performance when using a hybrid cloud storage solution.
Step 2: Deploy the AWS Storage Gateway VM on ESXi
Next, deploy the AWS Storage Gateway appliance as a VM on one of the ESXi hosts. It can be any host in the cluster (the gateway will serve storage to all), ideally one with sufficient resources and reliable connectivity.
Download the Storage Gateway OVA
Log in to the AWS Management Console and navigate to Storage Gateway. Begin the process to create a new gateway. Choose the Volume Gateway Cached option when prompted for gateway type. You will then choose VMware ESXi as the host platform, and the console will present a download link for the VM image (OVA). Download the OVA file to your local machine.
Deploy the OVA in vSphere
Open the vSphere Client and deploy the downloaded OVA. Follow the wizard, selecting the desired host/cluster, datastore, and network for the appliance. When prompted for storage, choose Thick Provisioning for the disks. Attach the VM to the network that you intend for iSCSI traffic which should also have internet access or a route to AWS.
Allocate Resources & Add Disks
Ensure the VM is created with the recommended resources. The OVA defaults should be 4 vCPU and 16 GB RAM. Before powering it on, add two additional virtual disks to the VM if the OVA deployment wizard didn’t already prompt for them:
- One disk for the Upload Buffer. Minimum 150 GB; this is a staging area for data to be uploaded to AWS.
- One disk for the Cache. Minimum 150 GB; this will store recently accessed data and pending writes locally.
Use SSD for these disks and mark them Thick Provisioned, Eager Zeroed if possible, to maximize performance. The 80 GB root disk from the OVA is for the gateway’s OS and should remain as thick provisioned as well.
VM Hardware Settings (Networking and SCSI Controller)
After adding disks, adjust the VM’s virtual hardware to meet AWS best practices:
- Network Adapter: The OVA might default to an E1000 or E1000e virtual NIC for broad compatibility. However, E1000-type adapters are limited to 1 Gb/s and have higher CPU overhead. It’s recommended to switch the NIC to VMXNET3, which supports 10 GbE speeds and more efficient operation. If the OVA VM came up with an E1000e, you can edit the VM settings to remove that NIC and add a new adapter of type VMXNET3. Ensure VMware Tools or open-vm-tools is installed in the gateway VM, as VMXNET3 requires it for drivers on some OSes. Attach the NIC to the iSCSI network which also has internet connectivity.
- SCSI Controller: By default the VM may use an LSI Logic SAS controller for its disks. Change this to VMware Paravirtual (PVSCSI) for the data disks. Paravirtual SCSI controllers are high-performance storage controllers that provide greater throughput and lower CPU usage, ideal for this scenario. In vSphere, edit the VM settings, select the SCSI controller, and choose Change Type -> VMware Paravirtual. Using PVSCSI also helps the AWS gateway software correctly identify the cache and buffer disks.
Power On and Initial Console Setup
Now power on the gateway VM. Open its console in vSphere to perform the initial setup. The VM will boot to a text-based setup console. If prompted for login, the default credentials are **sguser / sgpassword as of this writing, though you may not need to log in for the menu. Proceed with the following on the VM’s console menu:
- Networking Configuration: Configure a static IP address for the gateway VM on your iSCSI network. Navigate the console menu to networking and assign an IP with the correct subnet mask and gateway. This IP must be reachable by all ESXi hosts’ iSCSI VMkernel interfaces. If your environment uses DNS, you can also set the DNS servers and hostname as needed, or plan to use the IP directly for iSCSI.
- Time Synchronization: Verify the system time and time zone on the gateway VM. Set the time zone appropriately, and configure NTP servers if possible. Some AWS Storage Gateway VM versions allow setting NTP via the console or you may rely on VMware tools time sync. The goal is to have the gateway’s clock in sync with real time within 60 seconds skew to avoid activation issues. Synchronize time now to be safe.
- Resource Check: The console may offer a system resource check option. Use it to confirm the VM recognizes the disks you added for the upload buffer and cache, and that it has the expected CPU/RAM. This ensures everything is in place before proceeding.
At this stage, the AWS Storage Gateway VM is deployed on ESXi with local network and disks configured. Next, we will activate it in AWS and create the actual cloud volume to present to vSphere.
Step 3: Activate and Configure the Gateway in AWS (Cached Volume Setup)
With the gateway VM running, switch to the AWS Storage Gateway console to complete the gateway activation and volume creation steps:
Activate the Gateway
In the AWS Storage Gateway console, choose Activate Gateway. This typically appears after you select the gateway type and download the OVA, or via the console’s list of gateways if the VM is detected. When prompted, provide the IP address of the gateway VM. The AWS console will connect to the gateway and initiate activation. During activation, assign a Gateway Name and pick the AWS region if not already selected. The gateway will also download any pending software updates from AWS. If activation fails, double-check that the gateway VM has internet connectivity (outbound HTTPS) and that the system time is correct – networking or time sync issues are common culprits for activation problems.
Gateway Type – Cached Volume
Ensure the gateway is operating in Volume Gateway (Cached) mode. If you followed the steps to select Volume Gateway earlier, this will already be set. This mode stores all data in AWS S3 with only recently accessed data and writes cached locally, which minimizes on-prem storage use while still providing low-latency access to active data.
Allocate Local Disks in AWS Console
After activation, the AWS console will show the new gateway’s details. You must now assign the local disks you added to the VM as cache and upload buffer:
- In the gateway’s page, find the section for Local Disk Allocation. You should see the two additional disks as “Available for upload buffer/cache.” Assign one to be the Upload Buffer and the other to be the Cache.
- If the disks do not appear, ensure you added them before activation; otherwise, you may need to rescan or restart the gateway for AWS to detect them.
Create an iSCSI Volume
Now create a storage volume that will be exposed to VMware over iSCSI:
- In the Storage Gateway console, go to the Volumes tab or the gateway’s volumes section and click Create Volume.
- Choose the gateway you just activated as the target gateway.
- Specify a Volume Size. For example, create a 50 GB volume. For testing, size it according to your needs – Volume Gateway cached volumes can be up to 32 TiB each.
- Enter a Volume Name which will be used in the iSCSI target’s IQN. The target name must be unique within your environment. The console will form an IQN like iqn.1997-05.com.amazon:your-volume-name. For uniqueness, consider using a descriptive name with random or unique characters.
- Choose the Network Interface for the volume. If your gateway VM has multiple NICs configured, you will see a dropdown to select which interface’s IP will host the iSCSI target. Select the IP on the iSCSI network. Note: Once you choose the network interface for a volume, you cannot change it later.
- (Optional) Add any tags for the volume if desired, then proceed to create the volume.
After creating the volume, the console will present an option to configure CHAP authentication.
CHAP Authentication (Optional but Recommended)
AWS allows using CHAP for iSCSI targets, but it is not strictly required to use the volume. You can choose to set up CHAP credentials now or skip and configure it later. If you opt to use CHAP:
- Define an Initiator Name. The IQN of the client that will connect, e.g. you could use the ESXi host’s IQN or leave it blank to allow any.
- Set an Initiator Secret. This is the password the initiator will use to authenticate; it must be 12–16 characters.
- Set a Target Secret for mutual authentication. Another 12–16 character secret the gateway will use to authenticate to the initiator, if doing mutual CHAP. The target secret must be different from the initiator secret. For a simple one-way CHAP, you can leave the target secret blank or omit mutual CHAP on the ESXi side.
- Save the CHAP settings. You can edit CHAP settings later per volume if needed.
If you choose No CHAP, the volume will be open to any initiator on that network or restricted only by initiator IQN if you set one without a secret. For security, it’s best to use CHAP unless you are in a fully isolated environment. The AWS console labels CHAP as “optional” but highly recommended.
Note the Target Info
Once the volume is created and CHAP configured or skipped, note down the iSCSI Target IQN and the Gateway’s IP for the volume. The target IQN will look like iqn.1997-05.com.amazon:your-volume-name and the portal IP is the gateway VM’s IP on port 3260. You can find these details in the volume’s details page in AWS. We will need this information to connect from VMware.
Verify Gateway Status
Finally, ensure the gateway in AWS shows as “Running” or “Active” and the volume as available. The gateway VM should now be actively serving the new iSCSI target even though nothing is connected yet. At this point, the AWS side of configuration is done – we have a cloud-backed iSCSI volume ready to be connected to our ESXi hosts.
Step 4: Connect VMware ESXi Hosts to the AWS iSCSI Target
Now we shift back to VMware vSphere to connect the ESXi cluster to the newly created iSCSI target. We will add the iSCSI target to each host and then create a datastore on it.
Add the iSCSI Target Portal on ESXi
On each ESXi host in the cluster, we need to point the iSCSI initiator to the Storage Gateway target. Using the vSphere Client, go to Storage Adapters on the host, select the previously enabled iSCSI Software Adapter (vmhba#). Find the section for Dynamic Discovery. Click Add and enter the Server (Target) details:
- iSCSI Server: Enter the IP address of the Storage Gateway VM.
- Port: 3260.
- Leave CHAP settings empty here for now.
Save the target. Repeat this on all hosts, so each ESXi host knows about the gateway’s portal IP. After adding, the portal will show up in the Static/Dynamic Discovery list for each initiator.
Configure CHAP on ESXi (if used)
If you enabled CHAP on the AWS volume, you must configure the ESXi initiators to use the same CHAP credentials when connecting. On each host’s iSCSI adapter settings, find the Authentication or CHAP configuration. Enable one-way CHAP and enter the name and secret:
- Name: This is the CHAP username. AWS doesn’t actually enforce a specific username for one-way CHAP – it uses the initiator IQN to identify allowed connections. You can typically leave the Name blank on ESXi or use the initiator IQN if AWS expects it. If AWS’s CHAP was set with a specific initiator name, you should use exactly that on ESXi.
- Secret: Enter the same initiator secret that was configured in AWS for this volume. This is the shared secret the ESXi host will use to authenticate to the target.
- Mutual CHAP: If you configured a target secret on AWS (for mutual CHAP), then on ESXi also check the option for mutual CHAP and enter the target secret as the CHAP secret for the target (incoming). ESXi will then authenticate the target as well. Make sure to use the correct secret in the correct field. Don’t mix up which one is initiator vs target secret.
Apply the CHAP settings. Be sure to do this on all hosts so they can all authenticate to the target. All hosts can use the same CHAP secret in this scenario.
Discover and Mount the Volume
After the portal is added and CHAP set, if applicable, perform a Rescan of the iSCSI adapter on each host. The ESXi host should discover the AWS iSCSI target and the new LUN volume. The target IQN will appear under Static Targets and the LUN will show up as an available device. It may take two rescans. One to discover the target, and another to log in and detect the LUN. If any host does not show the new volume after rescanning, troubleshoot by verifying network connectivity, verifying CHAP settings on that host, and ensuring the gateway is running. Each host must individually discover and log into the iSCSI target.
Create a VMFS Datastore on the iSCSI LUN
Once the iSCSI LUN is visible as a device on the ESXi hosts, you can create a VMware datastore on it. In vCenter, go to Storage > Datastores > New Datastore. Choose VMFS datastore, select the new AWS iSCSI disk, and proceed to format it. Give it a name and finish the creation. This will format the volume with VMFS and make it a shared datastore.
Verify Multi-Host Access
After creation, the new datastore should automatically mount on all hosts that have the iSCSI target configured. In vCenter, verify that the datastore is shown as connected on each host in the cluster. If a particular host does not list the datastore, it means that host hasn’t successfully connected to the iSCSI target. In that case, go back to that host’s Storage Adapter, ensure the target is in Static Discovery, and rescan again. All hosts need access to the datastore for full cluster functionality. Remember that each host maintains its own iSCSI session; if you add a new host to the cluster later, you’ll need to repeat the target discovery and CHAP setup on that host as well.
Test the Datastore
At this point, treat the new datastore like any other shared storage. You can try some basic operations to ensure everything is working: for example, create a small test VM on the datastore, or migrate a VM onto it from another datastore. Monitor the vSphere Events and Logs for any iSCSI-related warnings or errors during these operations. If you encounter issues, double-check the network and CHAP configuration. For the initial writes, you might notice latency as data is uploaded to AWS, but subsequent reads of that data should be fast. We’ll discuss performance considerations next.
Step 5: Performance Considerations and Best Practices
Connecting VMware to AWS Storage Gateway introduces new factors for performance and reliability. Keep the following points in mind to ensure a smooth operation in a hybrid cloud storage setup:
Network Throughput and Latency
The performance of the cached volume depends on both the local network and the WAN link to AWS. Locally, using a VMXNET3 adapter and a 10 GbE network ensures the ESXi hosts and gateway VM can exchange data quickly. However, all writes eventually traverse the link to AWS S3 – a slow internet/uplink will bottleneck sustained write throughput once the upload buffer fills. For heavy write workloads, consider using AWS Direct Connect or a high-bandwidth, low-latency internet connection to AWS. Also, segregate iSCSI traffic from general LAN traffic to reduce jitter and contention. Ideally, the iSCSI network should be dedicated and quality-of-service controlled if sharing links.
Cache Sizing
The benefit of the cached volume is that frequently accessed data is kept locally on the gateway’s cache disk. Cache hits will be served at LAN speed from the SSD cache, whereas cache misses require fetching data from AWS S3 which could introduce hundreds of milliseconds of latency. Plan the cache disk size according to your workload’s active data set. AWS allows a cache up to 64 TiB for cached volumes, so allocate as much as is practical for your use case. A larger cache can improve read performance if your working set is large. Also note the upload buffer maximum is 2 TiB – allocating beyond that won’t increase upload throughput, but having sufficient buffer is important for absorbing bursts of writes.
Gateway VM Resources (RAM/CPU)
Ensure the gateway VM has enough memory and CPU for the workload. AWS recommends 16 GB RAM minimum for up to 16 TiB of cache, and potentially more memory if you configure a larger cache or have many concurrent operations. The gateway uses RAM for internal buffering and data transfer tasks. Monitor the gateway VM’s CPU and memory usage in vSphere. If you see it consistently high, consider increasing vCPUs. Similarly, if memory usage is maxed out, consider adding more RAM. The gateway can be scaled up (within supported limits) to improve performance.
ESXi iSCSI Settings (Timeouts & Recovery)
VMware ESXi is typically tuned for storage on a local network with very low latency. When introducing a cloud-backed storage, network latency and occasional interruptions must be tolerated. It is advisable to increase certain iSCSI timeout parameters on ESXi to be more forgiving of delays. For example, you can increase the LoginTimeout, NoopTimeout, or NoopInterval for the iSCSI adapter via ESXCLI or the UI. A common practice is setting timeouts around 60 seconds or more, so that transient network issues or brief AWS connectivity blips don’t immediately drop the iSCSI session. AWS notes that iSCSI clients can typically tolerate up to a 60-second disruption before failing I/O. Also, avoid prematurely disabling “Delayed ACK” on the iSCSI initiator unless you have specific evidence it helps in your environment. Some older best practices suggested turning off Delayed ACK for certain iSCSI arrays, but AWS has not indicated this is necessary for Storage Gateway, and leaving it enabled can aid throughput on higher-latency links.
Gateway Software Updates
AWS Storage Gateway appliances update frequently with bug fixes and improvements. It’s wise to keep the gateway updated to the latest software version, but plan updates during a maintenance window. When the gateway updates or reboots, I/O to the volume will pause. Typically, an update reboot takes around 60 seconds, during which ESXi may time out if not tuned as mentioned above. ESXi will usually retry and continue once the gateway comes back, as long as the downtime is brief. For example, an AWS update in late 2024 addressed an issue where ESXi initiators would not automatically reconnect to volumes after a gateway reboot. Check the AWS Storage Gateway console’s Software Updates section and configure a maintenance window for automatic updates, or apply them manually at convenient times.
Conclusion
By following this guide, you have connected your VMware ESXi cluster to an AWS Storage Gateway cached volume, effectively extending your on-premises storage with scalable cloud-backed capacity. This hybrid cloud storage approach can be powerful: you get the immediate availability of a local iSCSI datastore with the virtually infinite capacity and durability of AWS in the background.
However, always keep in mind the unique aspects of cloud-integrated storage. Monitor your network performance and the gateway’s health regularly. Implement CHAP and other security measures as needed to protect data in transit. Ensure proper network configuration so that all ESXi hosts maintain a solid connection to the gateway. Most issues that arise (as we’ve seen) boil down to network or authentication misconfigurations – once those are resolved, the integration tends to work smoothly.
With a properly configured environment, your VMware hosts will treat the AWS-backed datastore like any other shared storage. If you encounter any problems, revisit the steps and tips above – especially network setup, time sync, and CHAP settings. And consider the limitations for your specific use case: for many scenarios such as backups, archives, or augmenting storage for less critical workloads, AWS Storage Gateway provides a flexible, cost-effective solution. For mission-critical high-I/O workloads, you’ll want to carefully assess performance and possibly use this in tandem with on-prem SAN storage or ensure a robust network link.
Happy virtualizing, and enjoy your new hybrid cloud storage integration!
