One of the most important mechanisms for saving money with AWS is the reserved instance. There are reserved EC2 and RDS instances, and in spite of the name, they are not really instances at all. They are like coupons that can be purchased to obtain discounts on the instances that you use. While the concept is simple, optimal reserved instance planning is a little bit more complicated than you might expect.
First, reserved instances are used for more than just obtaining discounts. They also improve your chances of getting the instances that you need in the region and availability zone where you need them. There have been temporary capacity shortages of specific instance families in specific availability zones in the past. When these shortages occur, AWS gives preference to the accounts with reservations for those instance types. Keep that in mind if instance type and location is important to you, especially with an autoscale group that may need to scale up to meet increased demand or you otherwise need additional capacity on short notice.
Next, AWS uses the reserved instance model to help predict where demand will be. They offer the discounts in return for reservations that notify them what instance types will be needed where. Reservations are made for specific instance types in specific availability zones and are for a period of one or three years. Thankfully, there is some flexibility and some adjustments are allowed during the reservation period. EC2 Linux instances, for example, can be moved between availability zones within a region, and they can be traded proportionally within an instance family. For instance, two m4.small instances can be traded for one m4.medium instance, or a m4.xlarge instance can be traded for two m4.large instances, etc. If your environment is very large, it can be very helpful to use a tool such as CloudHealth, Cloudability, CloudCheckr, or others to get recommendations on this sort of reservation rebalancing as well as additional reservation purchases based on historical usage patterns.
Another characteristic of instance reservations that can be both helpful and complicating is that they can be applied across accounts if you have multiple AWS accounts linked to a consolidated billing account. At the end of the billing month, if you purchased reservations in one account that did not end up being used, AWS will apply the reservation discounts to applicable on-demand usage in another account. (Note that the discounting benefits apply across accounts; the previously mentioned capacity reservation benefits do not cross accounts.) The reason that this can create complications is that you have no control over which instance a reservation applies to. If you have more instances running than you have applicable reservations, AWS applies the reservations somewhat randomly from hour to hour. If you have multiple accounts for the purpose of associating expenses with individual cost centers, the reservations will not be consistently applied to the accounts or instances you intended.
AWS currently offers reserved instances in three different payment models, each with a different discount level. The no up-front reservation offers the lowest discount, but as the name implies, it requires no initial payment and is paid monthly, just like an on-demand instance. Note that you do pay monthly for the instance regardless of whether you actually use an instance of that type or not. The next style is the partial up-front reservation, which often has a substantially larger discount where there is both an initial payment and a smaller monthly fee regardless of actual usage. The last style is the full up-front reservation. This style often has only a nominally larger discount than the partial up-front style, and interestingly, the actual usage for instances of this type are not reported in the AWS usage reports. Because of the small incremental discount, the larger initial cash outlay, and the lack of reported usage data, many AWS customers prefer to stick to no up-front and partial up-front reservations.
The discounts associated with reserved instances are such that it may be beneficial to purchase a reserved instance even if you do not intend to use all of it. For instance, if the one-year, no up-front reservation savings associated with an i2.2xlarge instance is 50%, it is still cost advantageous to purchase a reservation even if you know that you will only use it for 9 months. Furthermore, three year reservations are usually not a lot more expensive than one year reservations, so even if your future plans are unclear, it could still make sense to purchase a three year reservation. (Note that AWS introduces new instance families periodically, so you should be prepared to continue running on an instance family that is deprecated by the time the reservation expires. There generally isn’t a problem with running on deprecated instance types. As long as the instance is current generation when a three-year reservation is purchased, you should be fine.)
And if that isn’t enough to think about, there are a couple of additional things to consider. AWS now offers scheduled reserved instances. The reservations only apply in the time periods you specify. This is a good option for dev/test instances that don’t need to be running 24 hours a day. Also, AWS has a Marketplace where unused reservations that were purchased can be bought and sold. You may be able to find reservations that you would benefit from with a reduced reservation period or at an additional discount on the Marketplace. You can also sell reservations there, for a fee, if you find that you no longer need a reservation that you purchased.
For more information on reserved instances, see https://aws.amazon.com/ec2/purchasing-options/reserved-instances/.
March 11th, 2016
Reserved Instances on AWS
By Gregg Gibson
One of the most important mechanisms for saving money with AWS is the reserved instance. There are reserved EC2 and RDS instances, and in spite of the name, they are not really instances at all. They are like coupons that can be purchased to obtain discounts on the instances that you use. While the concept is simple, optimal reserved instance planning is a little bit more complicated than you might expect.
First, reserved instances are used for more than just obtaining discounts. They also improve your chances of getting the instances that you need in the region and availability zone where you need them. There have been temporary capacity shortages of specific instance families in specific availability zones in the past. When these shortages occur, AWS gives preference to the accounts with reservations for those instance types. Keep that in mind if instance type and location is important to you, especially with an autoscale group that may need to scale up to meet increased demand or you otherwise need additional capacity on short notice.
Next, AWS uses the reserved instance model to help predict where demand will be. They offer the discounts in return for reservations that notify them what instance types will be needed where. Reservations are made for specific instance types in specific availability zones and are for a period of one or three years. Thankfully, there is some flexibility and some adjustments are allowed during the reservation period. EC2 Linux instances, for example, can be moved between availability zones within a region, and they can be traded proportionally within an instance family. For instance, two m4.small instances can be traded for one m4.medium instance, or a m4.xlarge instance can be traded for two m4.large instances, etc. If your environment is very large, it can be very helpful to use a tool such as CloudHealth, Cloudability, CloudCheckr, or others to get recommendations on this sort of reservation rebalancing as well as additional reservation purchases based on historical usage patterns.
Another characteristic of instance reservations that can be both helpful and complicating is that they can be applied across accounts if you have multiple AWS accounts linked to a consolidated billing account. At the end of the billing month, if you purchased reservations in one account that did not end up being used, AWS will apply the reservation discounts to applicable on-demand usage in another account. (Note that the discounting benefits apply across accounts; the previously mentioned capacity reservation benefits do not cross accounts.) The reason that this can create complications is that you have no control over which instance a reservation applies to. If you have more instances running than you have applicable reservations, AWS applies the reservations somewhat randomly from hour to hour. If you have multiple accounts for the purpose of associating expenses with individual cost centers, the reservations will not be consistently applied to the accounts or instances you intended.
AWS currently offers reserved instances in three different payment models, each with a different discount level. The no up-front reservation offers the lowest discount, but as the name implies, it requires no initial payment and is paid monthly, just like an on-demand instance. Note that you do pay monthly for the instance regardless of whether you actually use an instance of that type or not. The next style is the partial up-front reservation, which often has a substantially larger discount where there is both an initial payment and a smaller monthly fee regardless of actual usage. The last style is the full up-front reservation. This style often has only a nominally larger discount than the partial up-front style, and interestingly, the actual usage for instances of this type are not reported in the AWS usage reports. Because of the small incremental discount, the larger initial cash outlay, and the lack of reported usage data, many AWS customers prefer to stick to no up-front and partial up-front reservations.
The discounts associated with reserved instances are such that it may be beneficial to purchase a reserved instance even if you do not intend to use all of it. For instance, if the one-year, no up-front reservation savings associated with an i2.2xlarge instance is 50%, it is still cost advantageous to purchase a reservation even if you know that you will only use it for 9 months. Furthermore, three year reservations are usually not a lot more expensive than one year reservations, so even if your future plans are unclear, it could still make sense to purchase a three year reservation. (Note that AWS introduces new instance families periodically, so you should be prepared to continue running on an instance family that is deprecated by the time the reservation expires. There generally isn’t a problem with running on deprecated instance types. As long as the instance is current generation when a three-year reservation is purchased, you should be fine.)
And if that isn’t enough to think about, there are a couple of additional things to consider. AWS now offers scheduled reserved instances. The reservations only apply in the time periods you specify. This is a good option for dev/test instances that don’t need to be running 24 hours a day. Also, AWS has a Marketplace where unused reservations that were purchased can be bought and sold. You may be able to find reservations that you would benefit from with a reduced reservation period or at an additional discount on the Marketplace. You can also sell reservations there, for a fee, if you find that you no longer need a reservation that you purchased.
For more information on reserved instances, see https://aws.amazon.com/ec2/purchasing-options/reserved-instances/.