Amazon Web Services (AWS) monthly bills start arriving in inboxes the world round about this time every month. When they do, there are two questions we like to ask AWS users.
One, did you look at your AWS bill?
For some readers, the idea that you might not is ridiculous. You may be surprised how many companies we’ve talked to where even key decision makers are unsure how much they are spending on cloud services. (Mature cloud users are more likely to worry about spend, as found by RightScale’s 2017 State of the Cloud Report, but that doesn’t mean that even those users have their eye on the bill each month.)
Okay, so let’s assume that you have looked at your AWS bill. Time for the second question. Was your AWS bill more than you expected this month?
For more and more cloud users, the answer is yes. Only 46% of enterprises monitor and rightsize cloud resources – which means 54% do nothing. Between resources left running when they’re not needed, incorrectly sized resources, and orphaned volumes, it’s easy for bills to climb out of control.
I’m a fan of automation – as a CEO, I think you should do everything possible to simplify your day-to-day, whether that means you overhaul your calendar system or automate tasks in AWS.
Amazon themselves is great at this. I’m sure you are well aware of Amazon’s quest for automation in their warehouses (robots) and distribution (drones) to reduce costs and deliver packages faster. (That’s a great goal, by the way – I am an Amazon Prime customer – love it.) If you’re interested in Amazon’s robots, check out this article from Business Insider. And as the use of drones to deliver product becomes reality, Amazon has created a service – check out Amazon Prime Air if you haven’t already.
So let’s look at another branch of Amazon – Amazon Web Services (AWS). AWS is a large distributor of cloud, which in and of itself is actually a utility that can be used on demand to provide compute, database, and storage services to small and large companies alike. It’s just like the way utility companies provide electricity, water and heat to homes and business. Over time, features and services have been built and sold to optimize these traditional utilities in order to simplify mundane tasks via automation and achieve ROI by saving more money than cost. Here are a few examples:
Nest to detect, learn, and automate programmable thermostats to save on heating and cooling
In-office motion sensors to detect movement to turn lights off/on
Motion sensors on faucets and hand dryers to eliminate water and electric waste
Gadgets on showers, toilets, etc. to reduce water consumption and waste
The point is, all of these utilities need to be optimized with 3rd party technologies to automate and reduce waste, and to optimize spend. At home, you’re the CFO (or maybe your spouse is 🙂) but you don’t want to spend more than you need to, and you will buy technology to automate mundane tasks and save yourself money if there is a tangible ROI.
Amazon is doing this with robots and drones – neither of which they built. So why not use 3rd party technology to automate for AWS, Azure, and Google Compute. Remember that the public cloud is a utility, and utilities have waste. In public cloud, what can we look at that’s mundane, that can be automated and where you can save dollars on cloud waste?
I have a simple one – automate tasks in AWS by turning servers off and on. Did you know that on average, 66% of what you spend on the public cloud is on compute (servers), and 45% of that is on non-production systems like development, test, and QA – servers that’s don’t need to run 7×24. That’s $6B in waste per year.
Even better than Nest, which you can install and set up in 30 minutes, ParkMyCloud can be setup and configured in 15 minutes or less. The next day, we will tell you how much you saved in the previous 24 hours by simply automating the mundane task of turning idles servers on/off with schedules.
There’s a reason Amazon is so successful – they automate mundane tasks in a simple, efficient way, follow their lead – automate today!
>_ 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. Updated November 2018: we now offer a Reserved Instance management solution to save you time and help you get the most out of your reservations – learn more here.
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 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!
We spoke to Bobby Chan, System Engineer and Melanie Metcalfe, Project Support Manager, at software development company Foster Moore about their AWS use and how they’re managing costs and cloud users with ParkMyCloud.
Can you describe what Foster Moore does? What does your team do within the company?
Foster Moore is an international software development company based in New Zealand which specializes in online registries using our product called “Catalyst”. We have clients all around the world which requires us to be agile to cater to the different time zones.
Bobby Chan (BC): I am part of the Operational Services Group (OSG). We look after the day-to-day running of production systems as well as our internal infrastructure. My role is a System Engineer, primarily dealing with Release Management.
Melanie Metcalfe (MM): I run our Project Support Office. We sit within the Finance Division, providing administration and support for all three Foster Moore offices.
Can you describe how you are using the cloud?
BC: We are currently using AWS for most of our Catalyst product implementations. This is for all environments, from development up to production using a lot of the core functions like EC2, RDS and Route53.
What challenges did you experience in using AWS prior to using ParkMyCloud?
BC: As the business was rapidly growing, we started to struggle with the escalating costs of the cloud. On one hand, we were trying to restrict people’s use of AWS for security reasons, but on the other hand we wanted to provide them the freedom of the cloud.
We attempted to have manual on/off schedules for instances, but this proved troublesome with the dispersed team and the human ability to forget. This also put a lot of pressure on the OSG team, who would be solely responsible for this management.
MM: From both a Project and Finance perspective, AWS invoices have limited usability of supporting data provided. We needed to be able to attach costs to certain projects and control the associated responsibility for those costs by team or by project.
What drove you to search for a solution?
BC: Ultimately costs and the ability to manage and control them. Additionally, we wanted to pass the responsibility of management to the dev/test teams.
How did you hear about ParkMyCloud?
BC: A colleague of ours was tasked with finding a solution to the escalating cost of AWS by the Director of Operational Services. When ParkMyCloud was initially described to our director, who previously worked for utility companies, the analogy of a light switch that the “consumer” could switch on and off was a revelation. The technological simplicity enabled an easy transition of ownership to Mel’s “cost control police”. Mel took it from there and made it her own. It’s now a business controlled process rather than an IT one, which is as it should be.
MM: I was introduced to ParkMyCloud through a colleague in the OSG. I could immediately see the benefits is controlling costs and potential for forecasted savings.
Can you describe your experience so far using ParkMyCloud?
BC: It has been very good. The tool itself has been simple to use and most of our team here have been able to use it with minimal guidance. The PMC team have also been very receptive to our requests and comments.
MM: The first thing we did was establish Teams and set up a process for access to all environments that sit within each Team. The Team Lead is ultimately responsible for who has access. As above we endeavor to have all possible instances on a 24/7 down schedule with team members given full access to override for as long as needed.
What servers are you putting schedules on?
BC: We have schedules on everything but production. The idea of that is that since production is never “meant to be down”, we have left them without a schedule.
What benefits has your company realized with ParkMyCloud?
BC: First, as this was a cost exercise, it was cost savings. We then had the benefits of incorporating all other teams like development and test teams in the responsibility of looking after their own instances.
MM: The savings have been hugely beneficial. The forecasted savings from scheduling feature is excellent. The access via teams also provides a better level of ownership and accountability.
What percent are you saving using ParkMyCloud?
MM: Anywhere from 30-40%, depending on how much time we spend chasing unscheduled instances.
What other cloud cost-savings measures do you have in place?
BC: While we don’t have any other tools used primarily for cost savings (other than the native AWS tools i.e. Trusted Advisor), we have been going through the exercise of trying to actively reduce the RDS costs for our environments as this is one of our largest costs other than EC2 instances.
Do you use ParkMyCloud for user governance? What other cloud governance measures do you have in place?
BC: We use the teams function from ParkMyCloud to control access to instances in AWS. We divvy up the instances based on the clients they service and then assign users accordingly. We use ParkMyCloud as the primary access point for AWS instances, so we don’t need other measures to lock down the users.