ParkMyCloud’s Top 5 Blog Posts of 2017

ParkMyCloud’s Top 5 Blog Posts of 2017

Before we ring in the new year, ParkMyCloud is taking a look back at 2017. We get a lot of great feedback on our blogs so we decided to summarize our top 5 blog posts, as indicated by our readers (views and shares). In case you missed them, please take a moment and enjoy our most popular posts of 2017!  

Azure vs AWS 2017: Is Azure really surpassing AWS?

Azure vs AWS – what’s the deal? After both cloud providers reported their quarterly earnings at the same time, speculation grew as to whether Azure might have a shot at outpacing Amazon. Provocative headlines teased the idea that Azure is catching up with AWS, making it a great opportunity to compare two out of the ‘big three’ providers. While it may seem like AWS is the one to beat, this blog examines whether Azure is catching up, where they are gaining ground, and why the debate even matters.

AWS vs Google Cloud Pricing – A Comprehensive Look

When it comes to comparing cloud providers, a look at pricing is not only helpful, it’s imperative. AWS and Google Cloud Platform (GCP) use different terminology for their instances, different categories of compute sizing, and take marketing liberties in describing their offerings. To make matters even more confusing, each provider takes a different approach to pricing, charging you by the hour in some cases or by the minute in others, and both having minimums. This blog breaks down all of the jargon and gives you valuable insight into how AWS and GCP are charging you on their monthly cloud bill.

The Cloud Waste Problem That’s Killing Your Business (And What To Do About It)

As enterprises continue shifting to the cloud, service providers like AWS, GCP, Azure, and more offer cloud services as a valuable utility for cost savings. However, as a utility, the cloud has serious potential for waste if not used optimally. What is “cloud waste” and where does it come from? What are the consequences? What can you do to reduce it? This blog answers those burning questions and tells you how to prevent waste and optimize your cloud spend.

Start and Stop RDS Instances – and Schedule with ParkMyCloud

When Amazon announced the release of start and stop RDS instances, AWS users finally had the ability to ‘turn off’ their RDS instances and save money on their cloud bill – nice! However, they would still be charged for provisioned storage, manual snapshots, and automated backup storage. What if there was a solution to starting and stopping RDS instances on an automated schedule, ensuring that they’re not left running when not needed? This blog explains how ParkMyCloud offers automated cost control on a schedule, saving you even more on your monthly cloud bill.

Why We Love the AWS IoT Button

We talk a lot about how ParkMyCloud can save you money on your cloud bill, because we can, but we also love to share the exciting, fun, and innovative offerings that the could brings. The AWS IoT button is a device like no other. You can program it to integrate with any internet-connected device, opening up a whole world of possibilities for what you can do with it. Make a remote control for Netflix, brew coffee in the morning without getting out of bed, or place a takeout order for lunch, all with the push of a button. This blog tells you about how the button was created, how to use it, and some ways that creative developers are using the AWS IoT button.

To another great year…

As we wrap up 2017, the ParkMyCloud team is especially thankful to those of you who have made our blog and our Cloud Cost Control platform successful. We look forward to another great year of keeping up with the cloud, sharing our posts, and of course, saving you money on your cloud bill.

Cheers to 2018! Happy New Year from the ParkMyCloud team and keep an eye open for SmartParking and several great announcements in early January.    

Spot Instance Hibernation – What It Means For You

Spot Instance Hibernation – What It Means For You

At AWS re:Invent 2017, one of the announcements that was made is that spot instance hibernation is now available. This change to how AWS spot instances works can mean some tweaks to how you approach this instance type. Let’s explore the ramifications of this and see what it means for you and your infrastructure.

What are Spot Instances?

When you use a cloud provider like AWS, they run data centers so you don’t have to. In doing so, those data centers have similar side effects as traditional on-prem deployments, including spare compute power when utilization is low. AWS decided to let free market forces work to their advantage by offering these spare resources at auction-style prices.

How this worked in practice (prior to this recent hibernation announcement) involved naming your bid price for how much you were willing to pay for an EC2 instance. Once the price of a spot instance went below your bid price, your instance started up and began doing work. Later, when the cost was above your bid price, your instance would be terminated.

Typical Spot Instance Use Cases

As you can tell, spot instances introduce a different way of thinking about your resources.  There are some use cases that don’t make any sense for spot instances, but others that can work well. For instance, high-performance computing scenarios that need a lot of machines for a short period of time can work well with spot instances, as long as the result isn’t extremely urgent. Another possibility is batch processing, like video conversions or scientific analysis, which can typically be done in off-hours without a human present to manually tweak things.

Hibernation vs. Termination

As mentioned above, the loss of a spot instance used to result in termination of the instance, regardless of the data or state of the machine. With Amazon’s recent announcement, you can now have spot instances hibernate instead. This means the system’s memory will be saved to the root EBS volume, then reloaded when the machine is resumed. It’s like time travel, but for your cloud infrastructure!

From a practical perspective, this can change how you approach spot instances. The main benefit is that you don’t have to prepare for sudden termination of your virtual machine, so more workloads could use spot instances with less preparation. The downside to this is that while your workload will eventually finish, you can’t quite be sure of when.

Spot Instances vs. Parking Schedules

The “not being sure when” part is the big differentiator between spot instance hibernation versus on-demand EC2 instances with parking schedules applied via ParkMyCloud. This new hibernation features means lots of benefits and cost savings, but introduces a nebulous time frame that tends to make developers (and executives) nervous. By utilizing known parking schedules that are automatically applied to instances, the cost savings can be quite comparable while maintaining business-hour uptime. The additional flexibility of manual or automated overrides via ParkMyCloud’s UI or API can mean all the difference to your cloud infrastructure team and the application owners who are running these workloads.

AWS claims that you can save up to 90% on your instance costs with spot instances. In the real world, various reports seem to be in the 50%-70% range, based on some stats from large companies like Pinterest and Vimeo. With parking schedules, most development teams turn off systems on nights and weekends, which is around 65% of the time. This means you can get similar savings, but with different timing structures for your use. The best way to save the most is to use a combination, so check out Amazon’s spot instances and try out ParkMyCloud for cost optimization for all workload types!

Amazon’s EC2 Scheduler – How Does it Compare with ParkMyCloud?

Amazon’s EC2 Scheduler – How Does it Compare with ParkMyCloud?

Amazon recently announced updates to their EC2 scheduler, responding to the already-answered question: “How do I automatically start and stop my Amazon EC2 instances?”

Been there, done that. ParkMyCloud has been scheduling instances and saving our customers 65% or more on their monthly cloud bills from Amazon, Azure, and Google since 2015. It looks like Amazon is stepping up to the plate with their EC2 scheduler, but are they?

The premise is simple: pay for what you use. It’s what we’ve been saying all along – cloud services are like any other utility (electricity, water, gas) – you should use them only when needed to avoid paying more than necessary. You wouldn’t leave your lights on all night, so why leave your instances running when you’re not using them?

Until now, Amazon had basic scripting suggestions for starting and stopping your instances. With the EC2 scheduler, you’re getting instructions for how to configure a custom start and stop scheduler for your EC2 instances. Implementing the solution will require some work on your part, but will inevitably reduce costs. Welcome to the club, Amazon? Sort of, not really.

EC2 Scheduler vs ParkMyCloud

While the EC2 scheduler sounds good, we think ParkMyCloud is better, and not just because we’re biased. We took a look at the deployment guide for the EC2 scheduler and noticed a few things we offer that Amazon still doesn’t

  • This solution requires knowledge and operation of DynamoDB, Lambda, CloudWatch custom metrics, and Cloudformation templates, including Python scripting and Cloudformation coding.
    • None of that is required with our simple, easy-to-use platform. You don’t need a developer background to use ParkMyCloud, in fact you can use your mobile phone (insert link) or tablet.
  • There’s no UI, so it’s not obvious which instances are on what schedules.
    • ParkMyCloud has a simple UI with an icon driven operational dashboard and reporting so you can easily see and manage not only your AWS resources in a single-pane but your Azure and Google resources as well.
  • Modifications require code changes and CloudFormation deployments, including simple overrides of schedules.
    • Again, ParkMyCloud is easy to use, no coding or custom scripting required. Users can also temporarily override schedules if they need to use an instance on short notice, but will only have access to the resources you grant. And you can use our API and Policy Engine to automate scheduling as part of your DevOps process.
  • No SSO, reporting, notifications
    • Check, check, check. Did we mention that ParkMyCloud added some new features recently? You can now see resource utilization data for EC2 instances, viewable through animated heatmaps.
  • Doesn’t have SmartParking – automated parking recommendations based on usage data.
    • We do.
  • You cannot “snooze” (temporarily override) schedules on parked instances. You would have to do that manually through the AWS interface.
    • You can snooze schedules in ParkMyCloud with a button click.
  • Doesn’t work with Azure or Google.
    • We do.
  • Doesn’t park ASG
    • We do.
  • No Slack integration.
    • We do.

Conclusion

Amazon – nice try.

If you’re looking for an alternative to writing your own scripts (which we’ve known for a long time is not the best answer), you’re purely using AWS and EC2 instances, and are comfortable with all the PaaS offerings mentioned, then you might be okay with the EC2 scheduler. The solution works, although it comes with a lot of the same drawbacks that custom scripting has when compared to ParkMyCloud.

If you’re using more than just EC2 instances or even working with multiple providers, if you’re looking for a solution where you don’t need to be scripting, and if you’d prefer an automated tool that will cut your cloud costs with ease of use, reporting, and parking recommendations, then it’s a no-brainer. Give ParkMyCloud a try.

New in ParkMyCloud: Visualize AWS Usage Data Trends

We are excited to share the latest release in ParkMyCloud: animated heat map displays. This builds on our previous release of static heat maps displaying AWS EC2 instance utilization metrics from CloudWatch. Now, this utilization data is animated to help you better identify usage patterns over time and create automated parking schedules.

The heatmaps will display data from a sequence of weeks, in the form of an animated “video”, letting you see patterns of usage over a period of time. You can take advantage of this feature to better plan ParkMyCloud parking schedules based on your actual instance utilization.

Here is an example of an animated heatmap, which allows you to visualize when instances are used over a period of eight weeks:

The latest ParkMyCloud update also includes:

  • CloudWatch data collection improvements to reduce the number of API calls required to pull instance utilization metrics data
  • Various user interface improvements to a number of screens in the ParkMyCloud console.

As noted in our last release, utilization data also provides the necessary information that will allow ParkMyCloud to make optimal parking and rightsizing recommendations (SmartParking) when this feature is released next month, part of our ongoing efforts to do what we do best – save you money, automatically.

AWS users who sign up now can take advantage of the latest release as we ramp up for automated SmartParking. In order to give you the most optimal cost control over your cloud bill, start your ParkMyCloud trial today to collect several weeks’ worth of CloudWatch data, track your usage patterns, and get recommendations as soon as the SmartParking feature becomes available in a few weeks.

If you are an existing customer, be sure to update your AWS policies to enable ParkMyCloud to access your AWS CloudWatch data. Detailed instructions can be found in our support portal.

Feedback? Anything else you’d like to see ParkMyCloud do? Let us know

New in ParkMyCloud: AWS Utilization Metric Tracking

New in ParkMyCloud: AWS Utilization Metric Tracking

We are happy to share the latest release in ParkMyCloud: you can now see resource utilization data for your AWS EC2 instances! This data is viewable through customizable heatmaps.

This update gives you information about how your resources are being used – and it also provides the necessary information that will allow ParkMyCloud to make optimal parking and rightsizing recommendations when this feature is released next month. This is part of our ongoing efforts to do what we do best – save you money, automatically.

Utilization metrics that ParkMyCloud will now report on include:

  • Average CPU utilization
  • Peak CPU utilization
  • Total instance store read operations
  • Total instance store write operations
  • Average network data in
  • Average network data out
  • Average network packets in
  • Average network packets out

Here is an example of an instance utilization heatmap, which allows you to see when your instances are used most often:

In a few weeks, we will release the ability for ParkMyCloud to recommend parking schedules for your instances based on these metrics. In order to take advantage of this, you will need to have several weeks’ worth of CloudWatch data already logged, so that we can recommend based on your typical usage. Start your ParkMyCloud trial today to start tracking your usage patterns so you can get usage-based parking recommendations.

If you are an existing customer, you will need to update your AWS policies to enable ParkMyCloud to access your AWS CloudWatch data. Detailed instructions can be found in our support portal.

Feedback? Anything else you’d like to see ParkMyCloud do? Let us know!

Cloud Per-Second Billing – How Much Does It Really Save?

Cloud Per-Second Billing – How Much Does It Really Save?

It has been a little over a month since Amazon and Google switched some of their cloud services to per-second billing and so the first invoices with the revised billing are hitting your inboxes right about now. If you are not seeing the cost savings you hoped for, it may be a good time to look again at what services were slated for the pricing change, and how you are using them.

Google Cloud Platform

Starting with the easiest one, Google Cloud Platform (GCP), you may not be seeing a significant change, as most of their services were already billing at the per-minute level, and some were already at the per-second level. The services moved to per-second billing (with a one-minute minimum) included Compute Engine, Container Engine, Cloud Dataproc, and App Engine VMs.  Moving from per-minute billing to per-second billing is not likely to change a GCP service bill by more than a fraction of a percent.

Let’s consider the example of an organization that has ten GCP n1-standard-8 Compute Engine machines in Oregon at a base cost of $0.3800 per hour as of the date of this blog. Under per-minute billing, the worst-case scenario would be to shut a system down one second into the next minute, for a cost difference of about $0.0063. Even if each of the ten systems were assigned to the QA or development organization, and they were shut down at the end of every work day, say 22 days out of the month, your worst-case scenario would be an extra charge of 22 days x 10 systems x $0.0063 = $1.3860. Under per-second billing, the worst case is to shut down at the beginning of a second, with a highest possible cost for these same machines (sparing you the math) being about $0.02. So, the best this example organization can hope to save over a month with these machine with per-second billing is $1.39.

Amazon Web Services

On the Amazon Web Services (AWS) side of the fence, the change is both bigger and smaller.  It is bigger in that they took the leap from per-hour to per-second billing for On-Demand, Reserved, and Spot EC2 instances and provisioned EBS, but smaller in that it is only for Linux-based instances; Windows instances are still at per-hour.

Still, if you are running a lot of Linux instances, this change can be significant enough to notice.  Looking at the same example as before, let’s run the same calculation with the roughly equivalent t2.2xlarge instance type, charged at $0.3712 per hour. Under per-hour billing, the worst-case scenario is to shut a system down even a second into the next higher hour. In this example, the cost would be an extra charge of 22 days x 10 systems x $0.3712 = $81.664. Under per-second billing, the worst case is the same $0.02 as with GCP (with fractions of cents difference lost in the noise). So, under AWS, one can hope to see significantly different numbers in the bill.

The scenario above is equally relevant to other situations where instances get turned on and off on a frequent basis, driving those fractions of an hour or a minute of “lost” time. Another common example would be auto-scaling groups that dynamically resize based on load, and see enough change over time to bring instances in and out of the group. (Auto-scale groups are frequently used as a high-availability mechanism, so their elastic growth capabilities are not always used, and so savings will not always be seen.) Finally, Spot instances are built on the premise of bringing them up and down frequently, and they will also enjoy the shift to per-second billing.

However, as you look at your cloud service bill, do keep in mind some of the nuances that still apply:

  • Windows: GCP applies per-second billing to Windows; AWS is still on one-hour billing for Windows.
  • Marketplace Linux: Some Linux instances in the AWS Marketplace that have a separate hourly charge are also still on hourly billing (perhaps due to contracts or licensing arrangements with the vendors?), so you may want to reconsider which flavor of Linux you want to use.
  • Reserved instances: AWS does strive to “use up” all of the pre-purchased time for reserved instances, spreading it across multiple machines with fractions of usage time, and per-second billing can really stretch the value of these instances.
  • Minimum of one-minute charge: Both GCP and AWS will charge for at least a minute from instance start before per-second billing comes into play.

Overall, per-second billing is a great improvement for consumers of cloud resources…and will probably drive us all more than ever to make each second count.