A tale of two products (don’t expect Dickens)

At Re:Invent and just after, AWS released several new products. Included in those were AWS FSx Windows and AWS Backup. Both of these products had a lot of interest for me, for various reasons, so I thought I’d give them a try. None of my experience was under work conditions, but the following are my experiences. Note: Both are only in a small number of regions, currently.

AWS FSx Windows


  • Easy setup (by itself)
  • Fully compatible Windows file server
  • DFS support
  • Has backups
  • Works as expected


  • Requires AWS Microsoft AD in each VPC
  • Can’t change file share size
  • Some features can only be changed from CLI
  • Throughput can only be changed through restore
  • Minimum share size is 300GB

First out of the box, and released at Re:Invent is AWS FSx Windows. AWS Elastic File System has been around for a while now and works nicely for providing a managed NFS share. Great for Linux, not so good for Windows. Your Windows sharing options are now enhanced with AWS FSx Windows. This is an AWS managed Windows File Server, running on Windows Data Centre. When you go to do the setup, there are only a few options, so it should be pretty easy, right? Well, yes and no. 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. 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. 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. That’s it. You now have a Windows file share you can use for all your Windows file sharing goodness.

FSx Windows FS Creation

But, what’s the catch? It can’t be that easy? Well, mostly it is, but there are some gotchas. With EFS, you don’t specify a size. You just use space and Amazon bill you for what you use. If you throw a ton of data on the share, all good. It just grows. With FSx Windows, you have to specify a size, min 300GB, at creation. Right now, there is no option to grow the share. If you run out of space, you’ll need to look at DFS (fully supported). Create a new FSx Windows share and use your own DFS server to manage merging the two shares into a single namespace. While on the topic of DFS, FSx Windows is just single AZ. If you want redundancy, you’ll need to create a second share and keep the data in sync. AWS has a document on using DFS for a multi-AZ scenario: https://docs.aws.amazon.com/fsx/latest/WindowsGuide/multi-az-deployments.html

What other issues are there? Well, a semi-major one and a minor one. The major one is there is currently no way to easily change the throughput, or at least not that I’ve found. 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. Not terrible, but a bit painful. For backup changes, time and retention, or scheduled maintenance window changes, those can only be done via CLI. It would be nice to have that option in the console, but not really a huge deal.

And there you have it. An AWS managed Windows File Server. Having to rely on an AWS Microsoft AD in each VPC is a bit of pain, but not terrible. Overall, I think this is a great option. Once it rolls out to GA it’s definitely worth investigating if you currently have EC2 instances running as Windows File Servers.

AWS Backup


  • Easy EFS backup
  • RDS & Dynamo DB backup


  • No EC2 backup (EBS isn’t the same)
  • Dashboard is fairly basic

Last year AWS launched their first foray into managed backups with Data Lifecycle Manager (DLM). This was very basic and helped with the scheduling and life cycle management of EBS snapshots. The recent announcement of AWS Backup sounded like this would be a big step forward in AWS’s backup offering. In some ways it is, but in others it is still very lacking. I’ll start with the good, because while these are great, they are relatively quick to cover. RDS and DynamoDB expands on what is already offered past the traditional 35-day mark. The big surprise, and much needed feature, was support for EFS backups. Previously, you had to roll your own, or use an AWS Answer provided by AWS to do an EFS to EFS backup. It worked, but was messy. This option makes it really easy to backup an EFS volume. Just configure it into a Backup Plan and let AWS do the work! There’s not a lot to say about this, but it’s big, and may be the main reason people include AWS Backup in their Data Protection strategy.

AWS Backup - Dashboard01

Now for the bad; there is no EC2 backup or restore. But wait! What about the EBS backup & restore option? That’s OK, but really, how many people spin up EBS volumes and only want to protect the volume? You don’t. You spin up an EC2 instance (with attached volumes) and want to protect the instance. Sadly, this is where AWS Backup falls down and products like Cloud Protection Manager from N2W Software shine. When you have an issue that requires restoring an EC2 instance from backup, it’s generally not in a calm situation with plenty of time to stop and think. There’s a disaster of some form and you need that server back now! You don’t want to have to restore each EBS volume, launch an instance from the root volume, make sure you know what volumes were attached in what order and with what device name and have all the details of security groups, IPs, etc. You just want to hit that one button that says “restore my instance” and be done. That’s what tools like CPM give you and what is sorely lacking in this offering from AWS Backup.


What’s my wrap up from my “Tale of two products”? For FSx Windows, if you have a need for a Windows File Server, wait until it comes to your region and go for it. With AWS Backup, it has a place, especially if you have important data in EFS, but it’s no replacement for a proper backup solution. Most likely this will be implemented in a hybrid arrangement with another backup product.

Note: AWS Backup also manages backups of AWS Storage Gateway. I didn’t have one to test, so I won’t comment.

Backups? Doesn’t Amazon handle that?

For many, the cloud is a magical place where servers just appear and your cloud provider looks after everything, or, if they at least have a concept of the servers, they just assume that the provider will also back them up. Lots of people never bothered to think about protection in a VMware environment, so why start now?

Unfortunately, while your cloud provider probably supplies the tools, you still need to do the configuration and management. In this blog, I won’t talk in specifics about tools, but I’ll start with discussing the concepts around backups. I’ll be discussing these concepts in relation to AWS, but the IaaS elements are roughly the same in Azure too.

Oh crap! I didn’t mean to blow away that server!
This is the time when you really need to find out if your backups are configured correctly, and by that, I don’t mean “are they working”, but are they backing up the right servers, at the right times, with the right frequency. There are two big buzz terms when designing backup policies: Recover Time Objective (RTO) and Recover Point Objective (RPO).

RTO is the “how quick can I get my data back” question. This is the question that governs how you back up your data. AWS natively has snapshots for volumes, plus backup options for RDS, DynamoDB, Aurora, and Redshift. They also have Lifecycle Management (DLM) for volume snapshots. There are all sorts of options in this space, from using the native tools; roll your own using Lambda, Step Functions, SSM, etc.; or backup products from vendors using their own methods or better frontends around AWS APIs. While tools like DLM & lambda functions are cheap and may backup well, the ease, and hence speed, with which restores are done may not be the fastest.

RPO is the “how much data can I afford to lose” question. For things like app servers, or even file servers, your standard nightly backup is often sufficient. For infrastructure like database servers, some logging servers, time sensitive data, then more frequent backups are often required. Often times, it’s a mix of the two, e.g. full nightly backup of the database and hourly archive log backups, or even writing the archive logs to a secondary location, S3, upon completion.

RTO & RPO are vital to your DR, or operational recovery. They answer the questions of how fast will you get your infrastructure back and at what point your data will be. The next set of questions are for historical data recovery. This is a mixture of questions around regulations, business processes, and cost. If your industry has certain legal requirements, those need to be allowed for. The longer you keep data, the more it’s going to cost. Also, how you keep your data will have an impact on cost. Is it snapshots, is it EBS, is in in some virtualised dedupe device, or S3/Glacier?

In summary, backups of data is still the customer’s responsibility, even S3. If you are going to backup your data, it is worth taking the time to plan it properly and regularly review that plan. Think of it as business insurance, along the lines of, if I lost this data, can the business survive?

Follow Us!

Kloud Solutions Blog - Follow Us!