AWS Storage Gateway is one of the first AWS services I ever deployed in the wild. It is one of those services that can be great for specific use cases, but isn’t something that I personally implement very frequently. For those unfamiliar with AWS Storage Gateway, it essentially allows you to abstract underlying AWS S3 or EBS storage for use with on-premises devices. While this typically involves a hybrid cloud use case, it also can be used natively within AWS as needed for certain scenarios. AWS Storage Gateway comes in three flavors:
- File Gateway – present S3 storage as s NFS or SMB file interface
- Tape Gateway – present S3 storage as a Virtual Tape Library (VTL)
- Volume Gateway – presents block storage (EBS) via iSCSI
I recently worked with a customer on an engagement that included a use case for File Gateway. In this particular instance, File Gateway was used to store video/media files for an on-prem security application. This application ran on Windows Servers and used SMB file shares to write data to S3 via the File Gateway. The application left 7 days worth of data on-prem and shipped anything older than 7 days to the SMB share using application native retention policies. Once in S3, a lifecycle policy was created to delete anything in that bucket older than 180 days.
The process of implementing File Gateway is fairly simple, and in this case involved deploying an OVA template into the on-prem VMware environment. Once the virtual appliance is up and running, creating a SMB file share allows for joining the Storage Gateway to the on-prem AD domain. You’d think this part would be simple, but in this case it caused a little bit of aggravation in that the first few attempts at joining the domain failed. After poking around for a little while, we realized that it was a DNS issue, and that the on-prem AD DNS needed an A record mapping the Gateway ID of the appliance to its private IP address. For whatever reason, using the IP address of the appliance didn’t work, and it wasn’t until after the hostname failed that we stumbled upon the Gateway ID value:
Adding this ID as an A record fixed the problem right away, and we were off connecting SMB file shares in no time. I couldn’t find anything in the docs explicitly calling this out, so hopefully this little tidbit may help anyone who runs into this same issue down the road.
