We’ll discuss how you can use a one or three year reserved instance for your FileMaker Cloud instance. This can shave 30% or more off your AWS instance charges.
Determine Usage
When you spin up any new AWS based VM you will by default be using an hourly instance. This can be perfect for short-term usage or where your usage may fluctuate frequently.
Update: September 2017
Two helpful things have happened. You no longer need to add an instance to an autoscale group in order to use your reserved instances. This is a big relief, because creating the autoscale groups has become a bit more difficult, and even before were prone to creating problems if the an instance was stopped, resized, etc.
Secondly, although zone based reserved instances may still have some small benefits, you can now use region based reserved instances. Previously, you had to allocate them to a specific zone in a region to match your instances.
======================
Hourly usage also makes sense if you are actively determining the minimum system size you’ll need, or testing a solution out. Although it’s quite possible to adjust your server’s size even after converting to a reserved instance, its definitely going to be a complication, so best to spend the time getting things settled down first.
Keep in mind that there are two components to your FileMaker Cloud costs: AWS Instance charges, and software licensing charges. If using FileMaker’s hourly licensing (also the default with FileMaker Cloud), there is no mechanism to change FileMaker Cloud’s software licensing from hourly to annual without migrating to a new instance. Somewhat incongrously, this is one advantage of using BYOL (Bring Your Own Licensing) with FileMaker, but you will still need to call FileMaker sales to adjust your license’s user count.
Create the Reserved Instance
Do you now have a good handle on your server’s usage? If so, let’s go ahead and set up our reserved instance.
First, we need to find what reserved instances are currently available. As usual with AWS, there are a lot of choices to consider. What actually shows up will vary as well, possibly even options to buy reservations for periods other than 1 or 3 years. How you pay even has options, but typically you’ll want to pay upfront for the best pricing. However, if there is a chance that you’ll relinquish your reservation before the period is up using one of the pay-as-you-go options may be a better choice. Also, when searching for options, make sure you are searching for the same size instance (e.g., t2.large) as the one you plan to keep.
As an example, I’ve pulled up the currently available t2.large reserved instances.
Allocate Reserved Instance
After you’ve purchased your reservation, we need to do a bit more work before seeing any benefit from it. Besides having the size match, the reservation must also be allocated to the same AZ (Availability Zone) as your FileMaker Cloud instance. We can do this by using the Modify Reserved Instances action to change it from being Region based to instead use the same AZ.
Finally, create an Auto Scaling Group to allow the reserved instance to be allocated to any available EC2 instance matching the AZ and size of the reservation. Your existing instance should now start using the reserved instance’s pricing. How do we determine that? You might be able to discern this on the detail of your bill, but an easier way is to check the detail of your allocation group:
If you have more than one EC2 of the same size and zone you don’t have any control over which one gets the reserved pricing. But luckily, this shouldn’t normally matter.
Problems to Watch For
There are some complications that can come up using reserved instances. For one, if the instance is rebuilt (e.g., for a FM Cloud update), it will result in a new instance being created. This will not be part of the Auto Scaling Group you created. Even worse, the Auto Scaling Group will create a replacement instance for the one terminated for the upgrade. This new instance will only have the OS volume, the backup and data volumes will be missing. If you look at the fmshelper.log you’ll see messages like this:
2017-01-03 17:11:50.107 +0000 Checking /dev/xvda
2017-01-03 17:11:50.108 +0000 /dev/xvda is root disk
2017-01-03 17:11:50.110 +0000 No EBS volume found - unable to separate data/config files
Possibly a scaling policy would help with this, but I haven’t looked into it yet. As a manual solution, you can remove the instance from the scaling group before any bigger updates, and then add back when done.
Simon
References