I’ll start with the good, because while these are great, they are relatively quick to cover. In some ways it is, but in others it is still very lacking. The recent announcement of AWS Backup sounded like this would be a big step forward in AWS’s backup offering. This was very basic and helped with the scheduling and life cycle management of EBS snapshots. Last year AWS launched their first foray into managed backups with Data Lifecycle Manager (DLM).
Once it rolls out to GA it’s definitely worth investigating if you currently have EC2 instances running as Windows File Servers. Having to rely on an AWS Microsoft AD in each VPC is a bit of pain, but not terrible. It would be nice to have that option in the console, but not really a huge deal.Īnd there you have it. For backup changes, time and retention, or scheduled maintenance window changes, those can only be done via CLI. When doing a restore, you can choose the throughput, so you can restore with a new throughput, blow away the old share and then map to the new one. The major one is there is currently no way to easily change the throughput, or at least not that I’ve found. What other issues are there? Well, a semi-major one and a minor one. AWS has a document on using DFS for a multi-AZ scenario: If you want redundancy, you’ll need to create a second share and keep the data in sync.
While on the topic of DFS, FSx Windows is just single AZ. Create a new FSx Windows share and use your own DFS server to manage merging the two shares into a single namespace. If you run out of space, you’ll need to look at DFS (fully supported). Right now, there is no option to grow the share. With FSx Windows, you have to specify a size, min 300GB, at creation.
If you throw a ton of data on the share, all good. You just use space and Amazon bill you for what you use. You now have a Windows file share you can use for all your Windows file sharing goodness.īut, what’s the catch? It can’t be that easy? Well, mostly it is, but there are some gotchas. OK, so, I’ve got my AWS Window AD, what’s next? Well, jump into the FSx Windows console, enter the size, throughput (default 8MB/s), backup retention and window, and maintenance window. If you’re running Windows based workloads, you’ll likely have a Windows admin, so this shouldn’t be too hard to configure and tie into your regular AD. Actually configuring FSx Windows is easy, but before you do that, you need to have an AWS Microsoft AD directory service (not just an EC2 running AD) in the VPC that you are launching FSx Windows. When you go to do the setup, there are only a few options, so it should be pretty easy, right? Well, yes and no. This is an AWS managed Windows File Server, running on Windows Data Centre. Your Windows sharing options are now enhanced with AWS FSx Windows. Great for Linux, not so good for Windows.
AWS Elastic File System has been around for a while now and works nicely for providing a managed NFS share. Throughput can only be changed through restoreįirst out of the box, and released at Re:Invent is AWS FSx Windows.Some features can only be changed from CLI.Note: Both are only in a small number of regions, currently. None of my experience was under work conditions, but the following are my experiences. Both of these products had a lot of interest for me, for various reasons, so I thought I’d give them a try. Included in those were AWS FSx Windows and AWS Backup. At Re:Invent and just after, AWS released several new products.