>_ Today we have a piece of advice: don’t write a script to save money on AWS. Here at ParkMyCloud, we spend a lot of time chatting with DevOps and infrastructure teams, listening to how they manage their cloud operations.
You can Take the DIY Approach (scripting)
Although there is a lot of ‘tooling’ out there to make their lives easier, many infrastructure guys still choose to drop to the command line to take control of their environments. They might do this by using automation tools like Chef or Puppet, continuous delivery tools like Jenkins or simply revert to Bash or PowerShell. They are using these tools because of the granular control they provide and because they can seemingly quickly ‘knock out a script’ to either solve a problem or provide a quick automation of a common task.
We’ve talked with a number of larger AWS customers who are optimizing thousands or even tens of thousands of instances using scripting technologies. Given the needs of their businesses, their internal customers are typically geographically distributed with hundreds of teams and team members utilizing their cloud infrastructure.
But do you really want to?
Although we love scripts as much as the next guy, when it comes to cloud we see a few problems with this approach. Firstly, cloud is the great democratizer of infrastructure. No longer do the business folk in finance, marketing, sales etc. need to call IT to bring on new resources. They know they can spin it up themselves – even if they don’t know they can turn it off just as easily. But if you want cloud users to take on responsibility and ensure governance, they need tools, not scripts. Secondly, supporting hundreds of teams and user-managed infrastructures without embedding DevOps resources in every team quickly becomes burdensome and inefficient. The way we see it, just because you can do it, doesn’t mean you should do it.
There is a reason that simple, single-purpose web apps are sweeping across the enterprise. Users like simple UI’s with little to no learning curve. Companies realized that if you want to empower internal stakeholders by providing tools that allow them to optimize their workflow and resource use, it’s much easier to sustain if the end users can ‘do it themselves’. Be it the crack dev team who begins to self-manage their non-production environment or the team of data-scientists who make the CFO wince when they run their clusters.
Leave it to the folks down under to turn things on their heads
As we listen and learn how our customers optimize their cloud environments, we are always excited when we see an entirely new way of doing something. Recently, we were chatting with Foster Moore, one of our Antipodean customers in New Zealand. They too were active users of automation scripts for cloud optimization.
Once they found ParkMyCloud, however, they realized that they could free up their DevOps team to work on higher value activities. With their new tool in hand they decided to turn upside down the way their teams thought about cloud computing. They created a simple ‘always-off’ schedule, which takes newly launched instances and turns them off by default unless a user needs them turned on. By having them held in a stopped-state until exactly when they need them they avoid all unnecessary running costs.
The lesson is, you don’t need to write a script to save money on AWS. While our customer’s overall approach would have been technically possible using scripts, the ability to enable all their teams to have a simple way to remove this ‘always-off schedule’ would have required custom application development. Instead they were able to use ParkMyCloud’s ‘snooze’ functionality which allows its parking schedules to be temporarily removed for user defined periods of time, which could be an 8-hour workday or any other compute resources needed to be available. By reversing the ‘always-on’ nature of cloud compute to ‘always-off’, they were able to empower their teams to cut costs by 40% – without a single script in sight.
One cool feature on the ParkMyCloud website is the little chat window we’ve added, which allows you talk directly to our team – usually Katy. Well, Katy gets a lot of random questions for sure, things like:
Are you a car park in London? No, but mind the gap!
Are you a cloud provider? No, but we love public cloud providers like AWS, Azure, Google, and the like, and look forward to helping you manage your resources from all of these providers.
Do you support Azure? We will soon. In fact, we just started the dev work – expect Azure out after the New Year.
Do you support AWS Reserved Instances?
We get that last question quite a lot, so we thought we would expand our answer here.
If you don’t know what an AWS Reserved Instance (RI) is, your best bet is to learn about this Amazon Web Services offering is directly on their site.
Let’s break it down a little more.
Can I see my AWS Reserved Instances in ParkMyCloud?
Short answer: yes.
When ParkMyCloud discovers and manages your environment, we don’t know if an instance is treated as an RI, as the RI magic happens on the backend with Amazon. When you reserve an instance, you’re not actually designating a specific instance or server. What you’re reserving is a billing structure and capacity, which is then automatically applied to running instances that match your specified parameters.
So, from third-party apps like PMC, these instances look just like any On-Demand EC2 instance. So, when PMC ingests and displays your instances, your RIs will show among your other instances.
Can I use both ParkMyCloud and AWS Reserved Instances to get savings at the same time?
Definitely. You can actually get maximum cost savings if you use RI for production instances, and PMC to manage your non-production instances.
How can I save on my non-production servers?
For non-production environments (think test, dev, staging and QA), you can schedule servers off during nights and weekends using ParkMyCloud. Doing this typically saves PMC customers 65% or so off their monthly instance cost. The 65% range is based on a 50-hour workweek – meaning your instances run just 50 of the 168 hours in a given week – so they are parked a majority of the time to maximize savings.
How is that better than AWS Reserved Instances?
While AWS advertises RI savings as high as 75%, in reality for production RI savings typically run in the 30-40% range for the most commonly used instances (e.g., m3.medium, m4.large, m4.xlarge). Additionally, Reserved Instances require a 1-3 year upfront commitment, while PMC does not – leaving you more flexible.
If you have an AWS account which has both production and non-production in it and you have already purchased RI contracts, then using ParkMyCloud for non-production will, over time, shift the RI benefit to the production side (since those instances run 24×7) as your environment grows, the RI shift is factored in on the bill. Of course, if your environment is static then the shift does not occur – but whose AWS environment is not growing, right?
What else should I keep in mind?
Please also remember that unlike ParkMyCloud scheduling, Reserved Instances require you to specify the type, platform, payment option, instance type, offering class, and term length. You can optionally select an Availability Zone if you want to reserve capacity. Convertible RIs allow you to change some of these attributes, but at a reduced savings of around 45%.
We hope this is helpful – let us know of course and remember to use RI for Production and PMC for Non-Production to optimize savings. You can even sprinkle Spot in there but that’s another blog. Stay tuned…
Savings of spot instances, reserved instances, and ParkMyCloud vs. on demand.
We recently held a web session “5 reasons to turn off your cloud servers when they’re not in use.” Even if you weren’t able to join us, you can check out the recording below – or use the annotations below to skip ahead to the section you’re interested in.
00:51 Overview of presentation
01:18 Reason #1 – Save Money
Compute makes up the largest share of spend for most enterprise cloud users
$10 billion/year in revenue
70% is EC2 ($7 billion)
52% is non-production which could be turned off at night ($3.5 billion)
A simple 12-hour on/off schedule saves $1.75 billion in instance costs
03:00 Comparison of the major ways to save money in AWS
03:07 Reserved instances – pay upfront for a contract for 30-40% savings. Best for production environments.
04:06 Spot instances – open market on spare capacity. Savings are compelling (70-90%) but risk that your instance could go away if the price goes above your bid price.
04:37 Autoscaling groups – scale up and down groups of all types of instances according to your environment needs.
05:00 Turn instances off to save money when you’re not using them.
05:29 Reason #2 – Improve Security
There is nothing more secure than a server that is OFF (This is what security people actually dream about)
There is nothing easier to monitor than servers that are OFF (so long as your NOC folks are NOT surprised)
06:20 Reason #3 – Reduce Environmental Impact
Data centers consume ~2% of all electricity globally (3% of U.S.), growing at 12% YoY.1
80% of power is provided by fossil fuels
Avoiding the need for new data centers reduces carbon emissions
It also makes good business sense:
Cloud providers like AWS improve profitability and increase carbon credits when they can oversubscribe their infrastructure.
They can’t oversubscribe if they are over-provisioned
Therefore, turning servers off when not in use is one sure fire way help oversubscribe
08:31 Reason #4 – Because Werner Says So
AWS CTO Werner Vogels recently addressed an audience of AWS users, saying, “You can turn off your resources when you go home. Typical cost savings are 75%.”
08:51 Reason #5 – Peace of Mind
Knowing you’re saving money, improving security, helping the environment and obeying Werner will help you sleep better at night … who wouldn’t?
The question is how?
You manually turn things off when you leave. In Offices there are automated light switches. There’s a reason, right?
You could create scripts to do this automatically – that is not a cost-effective
09:29 ParkMyCloud – built specifically to turn off your servers when you don’t need them
WHAT: Simple, single- purpose SaaS tool.
HOW: Automatically schedule on/off times for idle servers.
WHY: Optimize cloud services spending.
ROI: Save 60% or more; 6 week payback.
10:17 ParkMyCloud product demo
10:28 Dashboard overview – see all your instances in one place
11:19 Parking recommendations
12:15 Parking schedule interface – create your own schedules
13:51 Snooze parking schedules
15:24 Automated policy engine – create policies to automatically handle scheduling, team assignments
18:16 How did you connect to AWS and find your instances?
19:18 How do you figure that you can save 65% on instances that you turn off nights and weekends?
19:52 Can you compare turning instances off to Reserved Instances?
22:12 Do the energy savings you described for Amazon apply to other cloud providers?
24:05 Why Dale doesn’t like scripting on/off times
We welcome additional questions in the comments below, and hope to see you at our next web session!