The Science of Choosing EC2 Reserved Instances (ENT221) | AWS re:Invent 2013

1,209 views

Published on

(Presented by Cloudability) Amazon EC2 Reserved Instances (RIs) are a great way for many customers to save money on AWS, particularly because the break-even point is well inside of their term. But for some customers the analysis and selection process is not well understood and can prevent them from making a decision that could save them money.

In this talk, Cloudability VP of Product Development Toban Zolman walks you through the most common scenarios for RIs, shows you how to make the best possible decisions for RI purchases, and how to significantly reduce the time needed to make those decisions.

Published in: Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,209
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
34
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

The Science of Choosing EC2 Reserved Instances (ENT221) | AWS re:Invent 2013

  1. 1. The Science Behind Choosing Reserved Instances Toban Zolman, Cloudability November 13, 2013
  2. 2. Introduction • Understanding reservations • Simplifying Reserved Instance purchases while maximizing ROI • Recommended approach to purchasing reservations
  3. 3. 8000+ Companies • $600M+ managed cloud spending

  4. 4. Our Solution
  5. 5. The Science of Purchasing Reservations
  6. 6. Is your company currently purchasing AWS reservations?
  7. 7. Most people over-simplify reservation purchasing
  8. 8. RESULT: Reserved Instance purchases misalign to your needs reducing ROI
  9. 9. Go all in on 1 or 2 large buys each year
  10. 10. Result: Large cliffs in reservation levels
  11. 11. How frequently are you purchasing reservations?
  12. 12. Reservations 101
  13. 13. What is a reservation? Reservations allow you to reserve resources/capacity for one or three years in a particular region in exchange for a lower overall unit price. Compute Amazon EC2 Database Amazon DynamoDB Amazon RDS Amazon Redshift Amazon ElastiCache CDN Amazon CloudFront
  14. 14. Why make reservations? 1. Lower the cost of resources you are already using Reservations provide substantial cost savings versus “on-demand” pricing.
  15. 15. Cost Savings vs On-Demand Comparison There are 2,000+ different reservation types each with their own breakeven points. LINUX m1.xlarge instance – over 3 years Annual Utilization Rate Light Utilization RI Medium Utilization RI Heavy Utilization RI 20% 25% -7% -77% 40% 40% 33% 11% 60% 45% 46% 41% 80% 48% 52% 56% 100% 49% 59% 65%
  16. 16. Why make reservations? 1. Lower the cost of resources you are already using Reservations provide substantial cost savings versus “on-demand” pricing. 2. Lock-in future capacity in same region/Availability Zone Very useful if you experience bursts/spikes in usage 3. Reserve capacity in another region just in case... Demand can cause a run on capacity. Reservations ensure you get seat at the table.
  17. 17. Why are you currently purchasing Reserved Instances?
  18. 18. Reserved Instance Pricing Components Reservation Type Light Upfront Fee Yes Hourly Usage Fee Yes Minimum Usage Level None If the instance is not used during the hour, there is no charge. Medium Yes Yes None If the instance is not used during the hour, there is no charge. Heavy Yes Yes Yes Billed a full month’s worth of hours at the start of each month.
  19. 19. How are reservations applied • Reserved Instances are purchased for an instance type (m1.xlarge) in a particular Availability Zone (us-east-1a) • Reservations are applied each hour. • If an instance is running in a “linked account”, it can inherit an unused reservation from a different linked account under the consolidated billing payer account • Capacity reservation stays with the linked account.
  20. 20. Modifying Reserved Instances • Amazon allows companies to apply to transfer a reservation from one Availability Zone to another • Trade-in existing Reserved Instances for a different size in the same family • The fine print: Transfers do not happen automatically Transfers are not guaranteed and are based on available capacity
  21. 21. A Simplified Example of Calculating Reservation Needs
  22. 22. Running Instances by Hour of the Month (example assumes 10 hours in month) Hour of month Running Instances 1 4 2 6 3 0 4 5 5 7 6 8 7 5 8 3 9 12 10 3
  23. 23. Hourly Frequency Distribution of Instance Levels Running Instance Count Frequency of Occurrence Freq. % 0 1 10% 1 9 90% 2 9 90% 3 9 90% 4 7 70% 5 6 60% 6 5 50% 7 4 40% Break even point for Medium 8 2 20% Break even point for Light 9 1 10% 10 1 10% 11 1 10% 12 1 10% Break even point for Heavy
  24. 24. It’s not enough to look at utilization rate over a period of time
  25. 25. Recommendation is based on 40 instances running 30.32% of the hours in the report period which is between 1-year break even point of 26.76% and 40.66% for a m1.small LINUX in us-east-1b.
  26. 26. Recommended Approaches to Purchasing Reservations • Base purchase decisions on hourly instance counts of each instance type per AZ 
(not aggregate data). • Frequent reservation purchases help maximize cost efficiency. • Don’t over purchase heavy reservations. Utilize Light and Medium reservations to handle volatility. • If capacity reservations are important, utilize light reservations to hold capacity in specific Availability Zones.
  27. 27. Thank You! continue the conversation: booth 414 web cloudability.com email toban@cloudability.com
  28. 28. We are sincerely eager to hear your feedback on this presentation and on re:Invent. Please fill out an evaluation form when you have a chance.

×