As your company becomes more enmeshed in the AWS ecosystem, it’s easy to find costs spiraling out of control. If it’s gotten bad enough, you may already have a direct mandate from your executives to reduce costs.
This webinar will show you 5 strategies for controlling AWS costs, including the benefits and best use cases of Reserved Instances, Spot Instances, Autoscaling groups, and on/off schedules...
… all of which serve to put a smile on the face of your CFO!
2. AWS Elastic Compute Cloud (EC2)
• AWS has a $10B run
rate, growing 70% Y-o-Y
• EC2 makes up almost
70% of that revenue,
growing at 88% Y-o-Y
(~$7 B)
• Approximately 51% are
non-production (~$3.5B)
2
How can we unlock
savings from here?
3. AWS Has Reduced Prices To Drive Demand
• In 2006 On-Demand (Pay as you go) introduced as
1st Purchasing Option
• AWS now has 40 Instance Types and 13 regions
• As adoption increased, so did “sticker shock”
• AWS introduced other ways to help customers
save money and accelerate adoption:
o Reserved Instances
o Spot Instances
o Auto Scaling Groups using all options above
3*AWS claims up to 75% with 3 year commitment
4. 1. How Reserved Instances Work
• Contract – Pay upfront to reserve capacity for 1 or 3 year
commitment*
• Pay upfront, partial upfront + monthly or monthly
• Use it or lose it:
o Managing and tracking RI usage can be very complex
o Specific to a Region, Availability Zone, Instance Type, Platform
Type and Tenancy
o AWS applies the benefit for instances that match (at random)
o AWS decrements contract amount every hour when not used
o If users don’t launch matching types, companies pay twice – for
unused RI’s and for the new instances
4*There is a market place for unused RI’s where you can get shorter contract periods.
5. Reserved Instance Savings
5
31%
41% 43%
60% 63%
• If AWS drops their pricing, then the promised savings evaporate!
• Therefore, the Best Use for Reserved Instances: Production.
• We can do better than that for non-production!
6. 2. How Spot Instances Work
• You bid on AWS spare capacity within Spot Pools, based on Instance
Type, Platform, Availability Zone
• The instance keeps running, if:
o There is spare capacity
o Your bid price > the actual price
• Risks:
o Your app might not run immediately
o Your app might terminate abruptly (after 2 minute warning)
• Mitigations:
o Build apps that can withstand interruption and/or run in parallel
o Use a mixture of on-demand and spot, with persistent requests
o Be flexible in Instance Type (broader choice, lower cost)
o Less demand on older Instance Types
o Leverage Spot Fleets (specify a mix of types with a single request)
6
7. Spot Instance Savings
7
m4.large example:
On-Demand Price: $0.126
Bid Price: $0.030
Spot Price: $0.0139
Savings: 89%
Savings in the 70% to 90% range are not uncommon for Spot
8. Where Are Spot Instances Being Used?
Best Uses:
Batch Production Workloads
• Scientific research (HPC jobs)
• Analytics batch jobs (e.g., Hadoop)
• Batch video processing
Non-production Workloads:
• Performance and Scalability Testing
8
9. 3. How Auto Scaling Groups Work
Auto Scaling Groups:
• Leverage any or all of the
Purchasing Options discussed
• Quickly scale up to meet
demand
• Scale down to save money
• Improve fault tolerance
• Best Uses:
o Production: Auto Scaling
Groups + Reserved Instances
o Non-Production: Auto Scaling
Groups + Spot Instances
9
10. 4. Scheduling "On/Off” Times with Scripting
• The simplest way to save money in these non-production
environments: Turn off stuff when not in use*
• AWS does not offer a “parked” state has no plans to do so
• Recommended by most cloud analytics platforms, but
many don’t help users actually do it
• Some cloud management platforms can do this, but they
are expensive and complicated
Lack of viable options has driven customers to fallback to
their comfort zone: Scripting
10
– How??
*The 10 Biggest Mistakes Made With Amazon Web Services
11. The Problem with Scripting
• Scripting is not cost-effective
• You have to maintain these scripts as the environment changes ($$)
• If you don’t maintain them, you miss stuff that could have turned
off ($$$)
• How do you quantify the savings to your leadership to justify the
effort, without some type of cost tracking or reporting? ($$$)
• How will you add new features? For example, support for other
cloud providers: Azure or Google Compute ($$$)
• Maintaining these scripts robs you of time that could be better
spent on your company’s main mission ($$$$)
11
12. 5. ParkMyCloud: Purpose-Built to Save Money
• ParkMyCloud schedules on/off times for EC2
instances (i.e., “Instance Parking”) without
scripting
• Think of “Parked” as a new instance “state”
between Running and Stopped
• Achieves EC2 Savings of 50 – 73%, without an
annual commitment, upfront payment or risk of
instance termination
12
On DemandReservedSpot
Free
Full
Price
13. Reserved Instance Savings
13
31%
41% 43%
64%
60% 63%
64%
ParkMyCloud Advantages in Non-Production
• Better Savings
• No Commitment or Upfront Payment
• Price Cut Protection
19. Summary – Unlocking EC2 Non-Production Savings
19
RISK
SAVINGS
High Low
High
Low
On Demand
Spot
Savings: 70-90%
Downside:
• Delay in Fulfillment
• Termination on Short Notice
• Complex Mitigation
Reserved
Savings: 31-43%
Downside:
• Locked in for 1 or 3 years
• No Price Cut Protection
• Use it or Lose it
Savings: 50-73%
Downside:
• Non-Production Only
20. Signup for a 30-day Free Trial
20
www.parkmycloud.com
Hello. My name is Dale Wickizer and I’m the CTO and Co-Founder of ParkMyCloud. Prior to ParkMyCloud, I was the CTO for NetApp’s $1B US Public Sector business. After many many years of being a data center infrastructure technologist, I have spent the past year and a half becoming immersed in cloud computing and data analytics. I manage the development effort here at ParkMyCloud.
As Katy mentioned, we are going to be discussing 5 Ways to Reduce Your AWS Spending, or How to Make Your CFO Happy.
Let’s begin to dig a little deeper into what spending we are talking about …
AWS has cracked a $10 B run rate is growing at 70% year over year. That’s staggering!
They also announced that they have more than doubled their lead in compute power: They now boast 10X more compute power than their nearest 14 competitors COMBINED!
In fact, the Elastic Compute Cloud (or EC2), makes up almost 70% of that revenue, or about $7 B, and it is growing at a 88% year over year growth rate. How does one explain that type of growth rate? !
The interesting thing is that a little over half of that compute power supports non-production workloads, such as dev, test, QA, staging, training and sandbox environments and comprises about $3.5 B, or almost 1/3 of AWS’ revenue.
Many of these environments run 24 x 7, even though they are not being used. It would be like you leaving your car running all the time, even when it’s at home in your garage, which is insane. Are there services which AWS provides to help you reduce your spend? Are there other ways outside of AWS?
THAT’S THE FOCUS OF THIS WEBINAR: HOW CAN WE UNLOCK SAVINGS FROM THESE NON-PRODUCTION ENVIRONMENTS.
EC2 has come a long way, since it was first introduced in 2006. There was one Purchasing Option (Pay as you go, or On-Demand), there were only a couple of Instance Types and 1 Region. Interestingly, most of AWS’ customers were developers and most of the workloads were non-production.
Today, looking at the current generation of EC2 instances, AWS has 40 Instance Types running in 13 Regions. And, as you saw, about half of their workloads are production environments.
AWS has done a great job of making their services, especially EC2, easy to adopt. Perhaps a little too good! As customer adoption increased, so did their “monthly sticker shock”.
AWS realized early on that it’s important to keep their customers happy and their services “sticky”. So, besides a number of price cuts on their On-Demand instances, AWS introduced Reserved Instances, Spot Instances and Auto Scaling Groups to help their customers save money. These moves, along with the wealth of new services every year, has rocketed EC2 to its current levels.
AWS also has a vested interest in having their customers save money. How? By reducing waste they avoid building new data centers, allowing them to oversubscribe the infrastructure they currently have in place, making them more profitable.
Reserved Instances, Spot Instances and Auto Scaling Groups will definitely save money in both production and non-production environments, but like many things there are tradeoffs to consider.
Each of these Instance Purchasing Options and Auto Scaling Groups could easily fill their own series of seminars. Time will only permit me to focus in on these options at a high level, as they relate to non-production cost savings.
So, with that backdrop, let’s look at our first way to save money: EC2 Reserved Instances.
A Reserved Instance is a contract or a commitment – you pay now to reserve capacity for a set period of time: 1 year or 3 years. [CLICK]
With that commitment, and your agreement to pay that contract upfront, partially upfront or monthly, AWS agrees to give you a discount. In general, that discount, as you will see on the next slide, increases the more you pay upfront and the longer the commitment time period.
There are also some caveats you must be aware of, if you are not already:
It is very much a use it or lose it proposition. It’s like those annoying gift cards that have a hidden monthly fee and have a zero balance by the time you get around to using them.
Managing these contracts can be very complex. In fact, a whole industry of analytics applications has grown up around helping you track Reserved Instances.
These contracts are specific to a Region, Availability Zone, Instance Type (e.g., m4.large), Platform Type (e.g., Linux or Windows) and Tenancy. As you launch instances,
AWS automatically (and randomly) attempts to match what is launched to the contracts you have in place. [CLICK]
If there is a match, they apply the benefit. If there is no match, AWS decrements the contract amount and your ROI decreases. [CLICK]
The nightmare scenario is when your users are launching the types of instances for which DON’T you have contracts. You end up essentially paying twice: once for the RI’s you paid for and then for the new instances.
That said, How much can you save with Reserved Instances?
I have two graphs here. These are for an m4.large Instance Type, running Linux, in the US-East-1 Region. The graph on the left is for a 1-year commitment; the graph on the right is for a 3-year commitment. NOTE: There is no green bar for the 3 year term, because AWS only allows the No Upfront option for the 1-year term..
The purple bar shows the On-Demand pricing in both.
Notice that for the 1-year commitment, you’ll save between 31% and 43%, and that the savings improves as you pay more upfront.
For the longer 3-year commitment, the savings improves to between 60% and 64%, not bad.
However, what happens if AWS cuts their On-Demand price as they have done in the past?
In 2014, AWS dropped their price by 30%.
If that happens, then the savings you hoped to achieve, evaporates. The longer the commitment, the greater the chance that this will happen, which is why more companies make the shorter 1 year commitment and settle for the lower savings
That said, as long as you are aware fo these caveats, the best use for Reserved Instances is in Production.
However, we can do better than that for non-production!
Let’s switch gears and look at the second way to save money in AWS non-production: Spot Instances.
Here’s how they work:
AWS runs a “spot market” on spare EC2 capacity. (Anyone familiar with derivatives markets or energy trading, should be familiar with the concept.)
This spare capacity is bundled in Spot Pools, based on Instance Type, Platform and Availability Zone.
You place a bid. If there is spare capacity and your bid price is above the current spot price, your request is fulfilled and your instances start. They will keep running as long as there is capacity and your bid price stays above the market price.
As we will see on the next slide, you can reap some great savings. However, there are risks involved.
If there is no spare capacity for the instance type you want, you may have to way a very long time before your request is filled.
As soon as the market price rises above your bid price, or if they run out of capacity, then your instances terminate abruptly (after a 2 minute warning)
Of course building applications that can withstand instance termination is the best strategy,
However, the spot market has led to all sorts of creative mitigation strategies, including:
Using a mixture of on-demand and spot instances with persistent requests
Avoiding the shiny, new EC2 types and settling for older types, with more stable pricing
Being flexible in the Instances Types you use. In fact, AWS has come out with Spot Fleets: the ability launch a mix of different Spot Instances in one request
What are the potential savings with Spot?
Here is an example of an m4.large Instance Type running in northern Virginia, running Linux.
You are looking at a 3 month price history, where the price has been quite low (about $0.014 per hour) for months.
If you had been willing to pay $0.03 per hour, your instance would have run for over 3 months.
You are billed on the Spot Price, not the Bid Price, so, mitigation strategies aside, you would have saved about 89%.
In fact, savings in the 70% to 90% range are not uncommon for Spot Instances.
So, even with the risks mentioned, Spot instances are used in both production and non-production.
They are NOT generally used in interactive production workloads, such as web applications, nor are they used in real-time production workloads.
They are used a lot in scientific research (e.g., HPC), analytics batch jobs and in batch video processing.
In non-production, Spot Instances are used for performance and scalability testing.
The third way you can save money in AWS is by leveraging Auto Scaling Groups.
An auto scaling group allows you to scale the number of instances up or down automatically:
Here is a simple web application, leveraging several web servers, sitting behind an elastic load balancer
You provide a launch configuration (one or more AMIs)
You set the minimum, desired and maximum number of instances. In my example, I set the minimum to 2 nodes, the desired to 4 and the max to 10.
You provide the CloudWatch metrics to use (e.g., CPU utilization, disk I/O, etc.) and thresholds
The system scales up and down automatically, by either the number of nodes or the %capacity you specified
Auto Scaling Groups leverage any or all of the Purchasing Options discussed, making them quite flexible
They can quickly scale-up to meet demand, like when the Christmas ecommerce rush hits,
then quickly scale down when the rush is over to save money.
They can be used to Improve fault tolerance for applications.
While they can help save money in both production and non-production, the amount of savings is rather hard to pin down, as it depends heavily on Instances Types used, whether they are On-Demand, Reserved Instances or Spot, and what the scaling policies/rules are.
That said, for Production, Auto Scaling Groups + On-Demand (backed by Reserved Instances) is probably the best bet.
For non-production: Auto-Scaling Groups and spot instances.
We talked about the fact that people often leave non-production environments running, even when they are not being used.
The best way to save money is to simply turn this stuff off when not in use. Well, easier said than done!
AWS does not offer a “parked” state and has no plans to do so
Despite the variety of Cloud Analytics platforms out there telling people to stop to doing that, those platforms don’t actually do anything to act on those recommendations
There are cloud management platforms out there, but unless you already own one, they can be expensive and complicated to use and the ROI might not be that great.
So, what do people do when there is a lack of viable options?
WHEN THE GOING GETS TOUGH, THE TOUGH START SCRIPTING!
As a recovering command line interface guy, who has done his fare share of scripting. I get the appeal:
You’re in control of your own destiny
It’s an opportunity to get your hands dirty
At the end of the process you have the satisfaction of actually building something from start to finish.
However, scripting is just NOT cost-effective. Why?
Building it is only half the battle. You now have to maintain those scripts as the environment changes, even with the help of Chef, Puppet or Saltstack, there’s added cost
If you don’t keep up with your environment, then you miss stuff you could have turned off. You then miss out on a lot of savings that could have helped justifying doing all of this.
Then, your boss taps you on the shoulder and wants to know why you are wasting your time on scripting up this stuff, when you are supposed to be working on more mission critical work? So, you have to come up with a way to quantify the savings, which takes time.
Heaven forbid that he likes your report, because now he is going to want to see a report every week. Who knows how long that will take?
Are you really going to have time to keep up with the changes in AWS, or add other service providers, such as Azure or Google?
And, what is the opportunity cost of not having you work on the company’s main mission? That probably makes these other costs pale in comparison!
So, let’s talk about the fifth and better way to save money in non-production environments: ParkMyCloud!
ParkMyCloud is purpose-built to do one thing really well: Schedule on/off times for EC2 instances WITHOUT SCRIPTING and without being a DevOps expert. We call that “Instance Parking”. It’s like NEST for the Cloud.
Think of “Parked” as a new instance “state” between Running and Stopped
Depending on the schedule used, ParkMyCloud can achieve savings of between 50% and 73%, making it better than Reserved Instances for non-production, without an annual commitment or an upfront payment
It provides almost the savings of Spot instances without the risk of abrupt instance termination
Let’s look at this comparison with Reserved Instances a little more closely, to show you why I think ParkMyCloud is better for non-production environments.
Here is that graph I showed you before, except now we have added the ParkMyCloud savings.
Here we used a Parking Schedule where instances were ON 12 hours & OFF 12 hours on weekdays and OFF on weekends. That results in a savings of 64%
To achieve that level of savings with Reserved Instances, you would have had to commit to a 3-year contract and pay the whole thing upfront … Yikes!
Also, remember what happens when AWS cuts their On-Demand prices? Your Reserved Instance savings is decimated.
Not so with ParkMyCloud: Since there is no annual commitment nor upfront payment, you would just ride the new price curve, which would be 64% below the new On-Demand price.
And unlike Reserve Instant management, ParkMyCloud is simple-to-use:
You create a parking schedule of on/off times
Set the proper timezone
Save it …
Then attach it to one or more of your non-production instances.
In fact, we even recommend instances to park, based on criteria you provide.
Once the parking schedules are applied, we predict you savings for the next 30 days.
Leave the schedules in place and we’ll also show you your actual savings month-to-day.
We do this for about $3 per instance per month!
For the folks who script, do you think you can maintain your scripts that inexpensively?
So, to show you how simple this, let’s look at a short demo of the product.
In summary, we have talked about 5 ways to reduce costs in AWS, focusing on non-production environments:
Reserved Instances, can save about 31-43%, but the downside is that you are locked in for 1 or 3 years, there is no protection against AWS price cuts and it is definitely a “use it or lose it” situation. While these can be used in production and non-production, production is probably the best place for them.
Spot Instances can save a lot, routinely 70-90%. However, because of potentially long delays in request fulfillment, termination of instances on short notice and the need for complex mitigation strategies, these are much higher risk, but there are definite use cases in both production and non-production.
Auto-Scaling takes advantage of all of the other instance options, allowing you to drive up availability and scalability in both production and non-production. However, the cost savings are difficult to pin down, as they are very configuration specific.
We talked about scheduling on/off times with scripting, but suggested that approach is not cost-effective, so it is not shown here.
We talked about ParkMyCloud, which provides better savings than Reserved Instances in non-production environments, without the need for annual commitments or upfront payments, like Reserved Instances; and without risks of Spot. The downside is that it is limited to non-production, on-demand instances. It cannot park auto scaling groups (yet).
I hope you found the information presented here to be of use.
If you haven’t tried ParkMyCloud, we offer a no-strings-attached, 30-day free trial.
We also offer Parking Savings Calculator, which you can use to estimate the savings for your environment.