How to save on AWS costs is a question that many project managers will have likely asked themselves since Amazon launched its Elastic Compute Cloud (EC2) in 2006. Indeed, as the number of organizations using the EC2 platform has grown – and the amount each organization spends on EC2 balloons – the question has probably been asked more frequently than you might imagine.

There are a number of answers to this question. Organizations can take advantage of Amazon´s flexible pricing plans to assign instances to the most cost-effective option or, if they have the organizational foresight to plan three years ahead, use Amazon´s Reserved Instances pricing model to save on AWS costs.

Where organizations use a high proportion of non-production instances, one way how to save on AWS costs is to reassign resources in order to develop scheduling scripts. Although this solution may be counter-productive in terms of reducing costs, it is a lot more reliable than asking teams to switch off their non-production instances before they go home at night.

Another way how to save on AWS costs is to implement an AWS management solution from ParkMyCloud. ParkMyCloud is a lightweight Software-as-a-Service app that automates the scheduling process in a simple user-friendly process called “parking”. The app even suggests which non-production instances are most suitable for parking – saving internal resources as well as AWS costs.

ParkMyCloud is also an exceptionally versatile cloud management solution. It enables administrators to set permission levels for development teams, provides a single-view dashboard across all accounts for easy governance, and allows for the schedule to be snoozed when developers want to access their development, testing and staging instances while they are parked.

To find out more about how to save on AWS costs with ParkMyCloud, contact us today.

How to Create Your 2018 AWS re:Invent Schedule

It’s time to plan your 2018 AWS re:Invent schedule! This will be our team’s fourth re:Invent, so we’ve put together some tips for planning out your conference experience.

First up, if you have not yet registered for re:Invent, do that now! Tickets sold out last year, so don’t wait.

Choose Your Sessions in Advance

The key to a great AWS re:Invent schedule is to plan in advance. The essential part of this planning is to register for sessions in advance. There will be a session registration open date, which has not yet been announced for 2018. When that date is released, though, put it on your calendar and reserve some time for registration – it can be competitive and sessions fill up quickly. Last year, session registration opened on October 19, so expect a similar date this year.

What you can get started with today is reading through the re:Invent agenda and, especially, the immense event catalog. Note the sessions you’re interested in. Here are some tips to keep in mind:

  • Focus – what do you most hope to gain at re:Invent? You can sort sessions based on subject areas and industries – would a “focus path” help you gain more out of your experience?
  • Value of In-Person vs. Session Videos – Many sessions will be online afterward, so prioritize sessions with an element that is more valuable in person – that may be chalk talks, workshops, and others with interactive elements. You’ll be able to watch any sessions you missed and catch up on the information on others with videos. This can put you more at ease and let you have some fun while in Vegas.
  • Travel time – This won’t be the first or the last time you hear this, but it’s worth saying again: the re:Invent campus is big. HUGE. Plan your schedule accordingly, with as few travel periods up and down The Strip as possible. If there are multiple sessions you’re interested in at the same time, prioritize ones with the least travel time. You should also plan to arrive to sessions early.

Once dates, times, and locations have been announced for sessions, we recommend putting them into your calendar for a clean visual of your day, and reminders. Once it’s available, you’ll be able to view your AWS re:Invent schedule in the mobile app, along with maps and more.

Set Aside Time for the Expo Hall

Make sure you plan on time to visit the expo hall! Actually, there are now two expos – the main one at The Venetian and another at the Aria.

The Welcome Reception from 4-7 PM on Monday is a great time to visit the expo and kick off your re:Invent experience with food, drinks, and giveaways. However, it will be crowded. You’ll want to come back again later in the week to check out vendor products and services, chat with vendors whose products you already use, get swag, and enter drawings. The expo is open from 8 AM – 6 PM Tuesday, 10 AM – 6 PM Wednesday, and 10 AM – 4 PM Thursday.

You won’t be disappointed by the swag. Just search #reinventswag for examples — sponsors go all out. By the way, if you’re aiming to maximize swag, definitely stop by after lunch on Thursday. Sponsors will practically beg you to take stuff off their hands so they don’t have to ship it home. You can grab toys, stickers, and keychains for your kids, or build an entire wardrobe of t-shirts and socks for yourself.

And of course, stop by and visit ParkMyCloud at the Venetian expo, booth #1709! Mention this post and we’ll hook you up with some secret bonus swag.

(Also, what secret bonus swag would you want? Asking for a friend…)

Activities and Parties

Round out your Vegas experience with some partying! The great thing about a conference like this is that you can often drink your way through for free, courtesy of vendors with bigger marketing budgets than mine. Outside of Tuesday’s pub crawl, many parties require you to register ahead of time, so keep an eye on your email for invitations. You’ll want to bookmark this list of 2018 re:Invent parties. As of this writing, it’s a bit sparse, but check out last year’s party list for an idea of the multitude of options to come.

Obviously, you don’t want to miss re:Play, the centerpiece of the conference (you know, besides the keynotes.) More free food, drink, an EDM concert, retro arcade, laser escape room, drone obstacle course, climbing wall, dodgeball, bounce castle, archery tag, and/or whatever else they come up with for this year.

Or venture out beyond the conference hall walls and try your luck or catch a show – it’s hard to be bored in Vegas.

 

Do you have any other tips for planning the perfect AWS re:Invent schedule? Let us know in the comments. Cheers, and see you there!

 

More on re:Invent: 2017 recap.

Read more ›

5 Things to Do When You Outgrow the AWS Free Tier

The AWS free tier is a great way to get started using Amazon Web Services — it can be a great boost to individuals, startups, and small businesses. In fact, the AWS free tier was essential to getting ParkMyCloud off the ground when we launched. But of course, this program has limits on what you can use without being charged.

The AWS free tier is designed to give you the AWS experience without the cost, but that also comes with limitations on instance types, storage, hours, and how often you can call operations each month. Of course, all good things must come to an end. If you’ve outgrown the free tier option and are ready to experience the full benefits of AWS, there are a few things you can do to make sure you’re getting the most out of being a paying AWS customer.

#1 Set spending limits

The first thing to consider when your 12 months on forgoing the AWS free tier expire option is the most obvious difference – cost versus no cost. You’re paying for cloud services now, so ensure that you don’t pay more than you intend to.

Use AWS Budgets to create custom cost and usage budgets that notify you when you exceed (or are about to exceed) your budgeted amount. Track budgets by the month, quarter, or year, with custom start and end dates. You can also track costs by services, account, tags, and more, receiving alerts directly to your email or through the Simple Notification Service.

With AWS Budgets, you can also set custom utilization targets for reserved instances including Amazon EC2 instances, Amazon RDS, Amazon Redshift, and Amazon ElastiCache, receiving alerts whenever your usage drops below your set utilization target. To get started with creating and tracking budgets, start from the AWS Budgets dashboard or the Budgets API.

#2 Optimize resource usage

Next, you need to ensure that that budget is only going toward resources you actually need – so cost optimization should be a top priority. You might be overpaying by leaving instances running during non-production times, when you don’t need them. Scheduling stop/start times with automation is an easy way to integrate cost control outside of the AWS free tier.

#3 Set sizing limits

Yet another caveat of cost optimization is right sizing. Besides making sure your instances are turned off when not in use, you should also make a practice of only using as much as you need at a given time, and that’s where right sizing comes into play. Size your workloads according to performance and capacity requirements, both initially and on an ongoing basis to ensure that resources do not end up underused or idle. AWS suggests that you use CloudWatch metrics to get a full view of your environment, and make a habit of right sizing once per month to keep the process smooth, ensure that you’re monitoring costs and keeping track of your billing and usage over time.

See a full list of cost traps to avoid in The Cloud Waste Checklist.  

#4 Plan your tagging structure

As your infrastructure grows, it’s important to manage your AWS resources with an effective tagging strategy. Tagging gives you the ability to attach custom metadata to instances, images, and more. Resources can be categorized by owner, purpose, or environment, helping you stay organized, improve visibility, and keep costs in check.

A good tagging strategy gives you a more accurate model for chargeback and showback and better insight in your usage and spend, but it’s up to you to enforce quality of tagging. Soft enforcement gives users notifications when policies are not followed, and hard enforcement automatically removes resources that are not tagged to align with company standard. According to AWS, organizations that use hard enforcement have a better time ensuring that quality of tagging is enforced.

Learn more about tagging best practices.

#5 Establish governance

Scheduling, right sizing, budget limits, and tagging are all methods of keeping costs optimized after you switch from the AWS free tier to a paid, full-service option. But what do all of these practices have in common? Governance. Clear policies and processes to keep usage, capacity requirements, and billing in check are all part of cloud and cost management, and should remain an ongoing priority as you continue using AWS or any cloud service provider.

For more information and how to plan governance after outgrowing the AWS free tier option, learn about how one software company automates governance.

Read more ›

AWS Reserved Instance Marketplace – Seller’s FAQ

As we continue to dive into AWS Reserved Instances, today we want to take a look at the AWS Reserved Instance Marketplace.

Reserved Instances are a great way to save money – unless they don’t get used, and you won’t really know until you get the bill. But just because you’re locked into that contract doesn’t mean that your unused RIs have to be a total waste of money. AWS has given users a place to sell them –  the Reserved Instance Marketplace.

Using the Reserved Instance Marketplace, you can list your reservation for other users to purchase.  Of course, like any online marketplace, there’s no guarantee that you’ll actually sell them, but at least you have a shot at getting some of your money back.

AWS has some solid documentation for all the ins and outs of buying and selling in the Reserved Instance Marketplace, but we decided to highlight answers to some of the questions we most commonly see about  how to get started with selling unused RIs. Read our FAQ below.

Selling on the Reserved Instance Marketplace

AWS customers and third-parties are free to use the marketplace to sell unused Standard RIs regardless of length terms or original pricing options.

When is it a good idea to sell unused RIs?

If you’re changing instance types (perhaps for rightsizing or better optimizing the instance type for its load or application), moving regions, your  business needs have changed, your capacity needs have changed, or you just don’t need that instance type anymore – use the marketplace.  

How do I become a seller?

To register as a seller, you’ll need to provide bank account and tax information. Once you’ve completed registration, you’ll receive a confirmation email.

Are there any restrictions or limitations to what I can sell?

  • Once you’ve registered as a seller, you’re free to sell any EC2 Standard Reserved Instances as long as your term length has at least one month remaining.
  • Convertible instances cannot be sold in the marketplace.
  • You can sell Standard RIs regardless of the purchasing plan (No Upfront, Partial Upfront, or All Upfront), but in the case of All Upfront – you must have made the full payment before you can sell, and the reservation must be active for at least 30 days before listing. AWS also charges a 12% service fee for upfront pricing.
  • Pricing is flexible – the minimum sale price is $0.00
  • You can’t modify or change a listing once it’s been made, but you can cancel it and create a new one.

What information does AWS share with buyers?

According to US regulations, buyers will be able to see your legal name on the buyer’s statement. In the event that AWS Support is contacted regarding invoices or tax purposes, the buyer may receive your email address to be able to communicate with you directly, along with your ZIP code and country.   

How does selling work?

Once you list the RIs you want to sell in the marketplace, buyers will be able to see them. Instances are grouped by remainder of term length and hourly rate. The cheapest reservations are sold first, followed by the next cheapest, and so on until the buyer’s order is fulfilled. AWS handles the transaction and transfer of ownership. The instances are yours until they’re sold, and once you make a sale, you’ll go back to paying the on-demand rate whenever you use that instance type moving forward.

How do I list my RIs in the marketplace?

There’s a few ways you can list your unused RIs in the AWS Reserved Instances Marketplace. You can sell them all at once, in parts, or by instance type, platform, and scope. You can also cancel your listing, but you won’t get anything back on any portions that have already been sold. There are also several routes you can take for where and how to list your RIs: using the AWS Management Console, using the AWS CLI or Amazon EC2 API, and from the Listing State of the My Listings tab of the Reserved Instances page.

How do I price my RIs in the marketplace?

When selling an RI, the only fee that you can decide on is the upfront fee – the one-time fee that the buyer is charged for purchasing your instance. Usage and recurring fees cannot be specified – the buyer will pay what was charged for the original purchase. The minimum sales price allowed is $0.00 and the maximum you can sell per year is $50,000 (although AWS can grant you permission to sell more on a case-by-case basis).

AWS also sets a default pricing schedule for your listed RIs. Pricing decreases incrementally over a month-to-month period to account for the value of the RI decreasing over time. What you can do, however, is set upfront prices based on the point of sale for your RI (a set price if its sold with 5 months remaining in the term, 3 months remaining, etc).

What happens after I make a sale?

You’ll get an email notification anytime an RI has sold, and each day there is any activity on your account, such as creating or selling a listing. Once the buyer pays AWS for your RIs, you’ll get a message to your email account about the sold reservation. AWS sends a wire transfer to the bank account provided, typically 1-3 days from the date of sale, but you won’t be able to receive funds until after AWS has verified the account with your bank, which can take up to 2 weeks. You can also see your sales in the Reserved Instance disbursement report, where you can check the status of everything you’ve listed. Or you can track the status of your RI listings in the console (Reserved Instance > My Listings > Listing State) for a full breakdown of available listings, pending, sold, and canceled.

Conclusion

Reserved Instances can save money on your AWS bill, but can just as easily waste money by going unused. Luckily, the AWS Reserved Instances Marketplace can help by giving you a place to sell your unused RIs. Did we miss any of your questions in this AWS Reserved Instances Marketplace FAQ? Let us know!

Read more ›

EC2 Instance Types Comparison (and how to remember them)

aws ec2 instance types comparison

AWS offers a range of EC2 instance types optimized for various purposes. It’s great that they provide so much variety, but of course, it means one more thing that you have to learn.

We broke this down in a new video, which also compares EC2 purchasing options. Check it out here:

Or, read on for a look into each instance type. Remember that within each type, you’ll still need to choose instance sizes for your specific needs. Additionally, older generations within each instance types are available for purchase – for example, c5 is the latest “c” instance, but c4 and c3 are still available – but as the newer types tend to perform better at a cheaper price, you’ll only want to use the older types if you have an AMI or other dependency.

This image shows a quick summary of what we’ll cover:

ec2 instance types comparison chart with mnemonics

General Purpose

These general purpose EC2 instance types are a good place to start, particularly if you’re not sure what type to use. There are two general purpose types.

t2 instance type

The t2 family is a burstable instance type. If you have an application that needs to run with some basic CPU and memory usage, you can choose t2. It also works well if you have an application that gets used sometimes but not others. When the resource is idle, you’ll generate CPU credit, which you’ll utilize when the resource is used. It’s a cheaper option that’s useful for things that come and go a lot, such as websites or development environments.

We’ll also add a mnemonic to help you remember the purpose of each instance type.

Mnemonic: t is for tiny or turbo.

m5 instance type

The m5 instance type is similar, but for more consistent workloads. It has a nice balance of CPU, memory, and disk. It’s not hard to see why almost half of EC2 workloads are on “m” instances.

There’s also an m5d option, which uses solid state drives (SSD) for the instance storage.

Mnemonic: m is for main choice or happy medium.

Compute Optimized

c5 instance type

The c5 instance type has a high ratio of compute/CPU versus memory. If you have a compute-intensive application – maybe scientific modelling, intensive machine learning, or multiplayer gaming – these instances are a good choice. There is also the c5d option, which is SSD-backed.

Mnemonic: c is for compute (at least that one’s easy!)

Memory Optimized

r4 instance family

The r4 instance family is memory-optimized, which you might use for in-memory databases, real-time processing of unstructured big data, or Hadoop/Spark clusters. You can think of it as a kind of midpoint between the m5 and the x1e.

Mnemonic: r is for RAM.

x1e instance family

The x1e family has a much higher ratio of memory, so this is a good choice if you have a full in-memory application or a big data processing engine like Apache Spark or Presto.

Mnemonic: x is for xtreme, as in “xtreme RAM” seems to be generally accepted, but we think this is a bit weak. If you have any suggestions, comment below.

Accelerated Computing

p3 instance type

If you need GPUs on your instances, p3 instances are a good choice. They are useful for video editing, and AWS also lists use cases of “computational fluid dynamics, computational finance, seismic analysis, speech recognition, autonomous vehicles” – so it’s fairly specialized.

Mnemonic: p is for pictures (graphics).

Storage Optimized

h1 instance type

The h1 type is HDD backed, with a balance of compute and memory. You might use it for distributed file systems, network file systems, or data processing applications.

Mnemonic: h is for HDD.

i3 instance type

The i3 instance type is similar to h1, but it is SSD backed, so if you need an NVMe drive, choose this type. Use it for NoSQL databases, in-memory databases, Elasticsearch, and more.

Mnemonic: i is for IOPS.

d2 instance type

d2 instances have an even higher ratio of disk to CPU and memory, which makes them a good fit for Massively Parallel Processing (MPP), MapReduce and Hadoop distributed computing, and similar applications.

Mnemonic: d is for dense.

What EC2 instance types should you use?

As AWS has continued to add options to EC2, there are now EC2 instance types for almost any application. If you have comparison questions around pricing, run them through the AWS monthly calculator. And if you don’t know, then generally starting with t2 or m5 is the way to go.

Read more ›

Don’t Waste Money on Unused Reserved Instances

Among the various ways to lose money on idle or orphaned resources in the cloud, here’s another for AWS users to add to the list: unused reserved Instances. At first, the idea of wasting money on AWS Reserved Instances seems counterintuitive. After all, aren’t RIs meant to save money? The short answer is yes – but only if you use them efficiently.

How Unused Reserved Instances Occur

To understand how unused Reserved Instances contribute to cloud waste, consider how they work. With AWS Reserved Instances, you’re making a commitment of usage by renting instances for a fixed amount of time in exchange for a lower rate (per-hour or per-second) than on-demand. You’re still free to use all the same families, OS types, and instance sizes with either one, except with RIs your ability to use certain instance types is limited to the purchasing plan you choose.

The only real difference between an AWS On-Demand instance and an AWS Reserved Instance is how you get billed for them on the backend – and this is where it gets tricky. You don’t know if your Reserved Instances have been used until you get the bill. Instead, you run your instances as you always would, with no insight into what will get billed as reserved instances. It’s only when your bill is created the following month that AWS reviews your reservations alongside your usage to apply the Reserved Instances that match up with your workload. This leaves you with little visibility into what your costs will be, forcing you to track usage on your own, and running the risk of unused reservations that result in, you guessed it – wasted money.

Ways to Avoid Losing Money Unused Reserved Instances

Reserved Instances require commitment of usage, ongoing awareness and insight into your future costs, and the possibility of going unused if AWS can’t apply them sufficiently. But that doesn’t mean you should shy away from using them. Reserved Instances can be cost-effective if used with a few things in mind:

Pick the RI type that suits your usage and workload. The best plan is one of prevention. Before you get started with purchasing reservations, get a detailed look at your usage and the most optimal instance types for your workload (something you should already be doing as part of your cost control measures). By design, Reserved Instances work best with steady state workloads and consistent usage. Once you confirm that your usage makes you a good candidate, you’ll want to choose the RI instance type that will benefit your needs most:

  • Standard RIs – Recommended for steady-state usage, and provide the most savings.
  • Convertible RIs – a smaller discount from On-Demand instances, but in return provide flexibility to change families, OS types, and tenancies.
  • Scheduled RIs – similar to Standard RIs, but only apply to instances launched within the time windows you select, which can recur on a daily, weekly, or monthly schedule.

Sell unused reserved instances on the Reserved Instance Marketplace. Using the marketplace allows you to list your reservation for purchase by other users. The cheapest reservations are sold first, and once someone purchases yours, you’ll be the charged the on-demand rate whenever you use that instance type moving forward.  

Purchase convertible reservations. With convertible reservations, you have the option to convert your reserved instances to other types, so long as the new type is more expensive. You won’t get as much of a discount, but flexibility and more options for use make up for the smaller savings.

The Lesson to be Learned

Just like any other idle or unused cloud resource, unused reserved instances can only do one thing – waste your money. Cloud services were meant to help you keep infrastructure costs in check, but only if you use them smartly. Optimize your cloud spend with awareness of your usage, ongoing insight into your infrastructure needs, and running instances only when you need them.

More questions answered in our recent blog, AWS Reserved Instance FAQs.

Read more ›

6 Types of Overprovisioned Resources Wasting Money on Your Cloud Bill

In our ongoing discussion on cloud waste, we recently talked about orphaned resources eating away at your cloud budget, but there’s another type of resource that’s costing you money needlessly and this one is hidden in plain sight – overprovisioned resources. When you looked at your initial budget and made your selection of cloud services, you probably had some idea of what resources you needed and in what sizes. Now that you’re well into your usage, have you taken the time to look at those metrics and analyze whether or not you’ve overprovisioned?

One of the easiest ways to waste money is by paying for more than you need and not realizing it. Here are 6 types of overprovisioned resources that contribute to cloud waste.  

Unattached/Underutilized Volumes

As a rule of thumb, it’s a good idea to delete volumes that are not attached to instances or VMs. Take the example of AWS EBS volumes unattached to EC2 instances – if you’re not using them, then all they’re doing is needlessly accruing charges on your monthly bill. And even if your volume is attached to an instance, it’s billed separately, so you should also make a practice of deleting volumes you no longer need (after you backup the data, of course).

Underutilized database warehouses

Data warehouses like Amazon Redshift, Google Cloud Datastore, and Microsoft Azure SQL Data Warehouse  were designed as a simple and cost-effective way to analyze data using standard SQL and your existing Business Intelligence (BI) tools. But to get the most cost savings benefits, you’ll want to identify any clusters that appear to be underutilized and rightsize them to lower costs on your monthly bill.

Underutilized relational databases

Relational databases such as Amazon RDS, Azure SQL, and Google Cloud SQL offer the ability to directly run and manage a relational database without managing the infrastructure that the database is running on or having to worry about patching of the database software itself.

As a best practice, Amazon recommends that you check the configuration of your RDS for any idle DB instances. You should consider a DB instance idle if it has not had a connection for a prolonged period of time, and proceed by deleting the instance to avoid unnecessary charges. If you need to keep storage for data on the instance, there are other cost-effective alternatives to deleting altogether, like taking snapshots. But remember – manual snapshots are retained, taking up storage and costing you money until you delete them.

Underutilized Instances/VMs

We often preach about idle instances and how they waste money, but sizing your instances incorrectly is just as detrimental to your monthly bill. It’s easy to overspend on large instances or VMs that are you don’t need. With any cloud service, whether it’s AWS, Azure, or GCP, you should always “rightsize” your instances and VMs by picking the instance size that is optimized for the size of your workload – be it compute optimized, memory optimized, GPU optimized, or storage optimized.

Once your instance has been running for some time, you’ll have a better idea of whether not the chosen size is optimal. Review your usage and make cost estimates with AWS Management Console, Amazon CloudWatch, and AWS Trusted Advisor if you’re using AWS. Azure users can review their metrics from Azure Monitor data, and Google users can import GCP metrics data for GCP virtual machines. Use this information to find under-utilized resources that can be resized to better optimize costs

Inefficient Containerization

Application containerization allows multiple applications to be distributed across a single host operating system without requiring their own VM, which can lead to significant cost savings. It’s possible that developers will launch multiple containers and fail to terminate them when they are no longer required, wasting money. Due to the number of containers being launched compared to VMs, it will not take long for container-related cloud waste to match that of VM-related cloud waste.

The problem with controlling cloud spend using cloud management software is that many solutions fail to identify unused containers because the solutions are host-centric rather than role-centric.  

Idle hosted caching tools (Redis)

Hosted caching tools like Amazon ElastiCache offer high performance, scalable, and cost-effective caching. ElastiCache also supports Redis, an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker. While caching tools are highly useful and can save money, it’s important to identify idle cluster nodes and delete them from your account to avoid accruing charges on your monthly bill. Be cognizant of average CPU utilization and get into the practice of deleting the node if your average utilization is under designated minimum criteria that you set.

How to Combat Overprovisioned Resources (and lower your cloud costs)

Now that you have a good idea of ways you could be overprovisioning your cloud resources and needlessly running up your cloud bill – what can you do about it? The end-all-be-all answer is “be vigilant.” The only way to be sure that your resources are cost-optimal is with constant monitoring of your resources and usage metrics. Luckily, optimization tools can help you identify and automate some of these best practices and do a lot of the work for you, saving time and money.

Read more ›

AWS Reserved Instances FAQ

This AWS Reserved Instances FAQ is a culmination of questions we are often asked about using Reserved Instances to save on your Amazon Web Services (AWS) costs.

First, let’s make sure you’re all on the same page. AWS Reserved Instances are a way to save money on your cloud bill by reserving capacity in advance, which you can choose to pay for all, some, or no upfront. Due to the different billing model and variety of options, these often raise questions.  Let’s explore a few:

Q1: How do I know which instances are reserved?

Because of how AWS billing works, Reserved Instances aren’t applied until you’re actually being charged for the instances. Think of it more like a “voucher” than a specific virtual machine.

This means that you run your instances as you normally would throughout the month, without seeing which will be billed as reserved vs. on-demand. When your bill comes on the 5th of the next month, AWS will look at your reservations and your usage and automatically apply the reservations that match the instances.

This means that you don’t have to decide which instances are reserved, but it also means you don’t have the visibility into what your true costs are going to be. You’ll have to track this on your own, or use some tools to help you manage your Reserved Instances. AWS has included some reports in the Cost Explorer that can help you visualize your month-to-date usage of your reservations.

Q2: What if I don’t need that instance type anymore?

There’s a couple of options for unused reservations, depending on the reason you aren’t using them anymore. The first option is to sell the reservation on the Reserved Instance Marketplace. This marketplace lets you list your reservation and allows others to purchase it from you. The reservations are grouped together, with the cheapest being sold first in that group. Once someone purchases your reservation, you start getting charged at the on-demand rate (if you still use that type).

The other option is to purchase convertible reservations, which allow you to change the attributes of the reservation (as long as it’s to a more expensive instance type). These convertible types give you much more flexibility, especially as your company or application are growing in use, but they do come with a smaller savings rate over standard Reserved Instances.

Q3: How do Reserved Instances work if I have multiple AWS accounts?

Many users of AWS in large organizations have started using a multi-account strategy, either for security reasons or billing reasons. When managing multiple AWS accounts, billing and reservations can get confusing. The good news is that reservations can “float” across multiple linked accounts, even if they weren’t purchased in the master account. Amazon is smart enough to attempt to apply the reservation to the account it was purchased in, but if a suitable instance is not found, it can apply it to an instance in a different account that matches. You can also choose to exclude linked accounts from receiving these floating reservations if you’d like.

Q4: Are AWS Reserved Instances better than On Demand?

Great question. This is actually the subject of the most popular post on the ParkMyCloud blog. In short: usually yes, but only for production environments. Otherwise, On Demand instances with on/off schedules are typically better value.

Conclusion

Reserved Instances can help save a lot of money on your AWS bill, but require a different way of thinking about your instances than the normal pay-as-you-go that you may be used to with cloud computing. These reservations are typically used for steady-state workloads with consistent usage. Did we miss any of your questions in this AWS Reserved Instances FAQ? Let us know!

Read more ›

Interview: Hitachi ID Systems Optimizes Training Infrastructure with ParkMyCloud

Hitachi ID Systems recently reached their first ParkMyCloud birthday – to celebrate, we chatted with Patrick McMaster about how they optimize training infrastructure and why he and his team said “We honestly couldn’t be happier with ParkMyCloud.”

Can you start by telling me about Hitachi ID Systems and what you and your team do within the company?

Hitachi ID Systems makes identity and access management (IAM) software. I am the training coordinator, so I handle getting clients and potential partners up to speed with how our software works, how to install it, how to administrate it, etc. For those who are more interested in learning about software, we set them up with a virtual environment and course materials or an instructor to get them up to speed with how the software works.

Can you describe how you’re using public cloud?

We use AWS exclusively. When we advertise that we’re running a course a few months ahead of time, our infrastructure starts seeing the registrations and will start creating VMs, applying patches, getting the latest version of the appropriate software installers on the desktop and getting everything ready for the students, who will be accessing geographically-local AWS infrastructure.

In the past, everything for this online training was very manual. We on the training team  would spin up the VMs manually, do the updates manually, and send the information to the potential students., Then when the course was over we would go through and do the reverse – shutting the elements down and turning off the virtual machine on AWS.

What does the supporting training infrastructure in AWS look like?

We have a number of VMs running per student or team that only need to be active during the team’s local business hours, plus some additional supporting infrastructure which is required 24/7. We started to realize as we got more students and began offering self-paced training that our AWS fees were increasing from the 24/7 access we were providing, but also just the management of keeping track of which students are where, when they should be brought into the system, when they should be shut down, etc. We needed to find a solution pretty quickly as we experienced that period of rapid growth.

How did that lead you to finding ParkMyCloud?

We knew we needed to automate the manual processes for this. Of course, lots of organizations tend to come up with solutions internally first. We’re a software company, so we had the talent for that, but we never have enough time. I’ve come to terms more and more every year with the benefits of delegating to the other sources. I realized that we are probably not the first organization to have this problem, so I Googled and found ParkMyCloud.

It became quickly evident that the features that you offered were exactly what we were looking for.

Can you describe your experience as a ParkMyCloud user so far?

Sure! So just before our demo of ParkMyCloud, we were fighting with this issue of trying to figure out how we can manage multiple time zones and multiple geographic locations, and not pay for that time that VMs are just spun up.

Then we went through the ParkMyCloud demo process and started our trial. We connected to our system and looked at ways to set up different schedules and pull information from AWS. There was definitely a moment where everyone in the room looked each other and said, “we must be missing something” – there had to be some additional steps we hadn’t thought out because it seemed too easy to work. But it really was that easy.

It just took a week of monitoring to make sure everything was turning off when it was supposed to – the bulk of our effort was really in that first week, and the time we need to spend in the interface is so small. We can go into ParkMyCloud’s dashboard and make exceptions to the schedule when needed, but the time that we actually spend thinking about these things is now about 2 hours a week, whereas before it was something that members of our staff might struggle with for 1-2 days. It’s been a huge improvement.

We did some calculations just in terms of uptime versus what we were doing before, and having the different schedules at our disposal and being able to spend that one week coming up with every scenario we could come up with was time well-spent. Now there are very few exceptions. I don’t think we’ve had to create a new schedule in a long time. Everything is organized logically, it’s very easy for us to find everything we need.

Who is responsible for tracking your AWS spending in the organization? Have they had any feedback?

Our finance department. Since we started using ParkMyCloud, it’s been very very quiet. No news is good news from finance. We are saving about 40% of our bill.

Do you have any other cloud cost savings measures in place?

Not for this training infrastructure. We have a pretty unique use case here. Our next steps are going to be more towards automatic termination, automatic spinning things up, more time-saving measures rather than cost.

This summer ParkMyCloud is working on instance rightsizing, if that’s something that would be helpful for you.

 That’s definitely something that we could use. We are always trying to find better ways of doing things.

OK, great, thanks Patrick! Appreciate your time.

 Thank you, have a good one!

 

Read more ›

4 Orphaned Cloud Resources Eating Away at Your AWS Budget – and How to Avoid Them

We recently discussed how orphaned volumes and snapshots contribute to cloud waste and what you can do about it, but those are just two examples of orphaned cloud resources that result in unnecessary charges. The public cloud is a pay-as-you-go utility, requiring full visibility of specific infrastructure – you don’t want to be charged for resources you aren’t using. Here are other types of orphaned cloud resources that contribute to cloud waste (and cost you money):

Unassociated Elastic IPs  

Elastic IPs are reserved public IP addresses designed for dynamic cloud computing in AWS. As a static IPv4 address associated with your AWS account, Elastic IPs can continue running an EC2 instance, even if it is stopped and restarted, by quickly remapping the address to another one of your instances. You can allocate an Elastic IP address to any EC2 instance in a given region, until you decide to release it.  

The advantage of having an Elastic IP (EIP) is the ability to mask the failure of an EC2 instance, but if you do not associate the address to your account – you’re still getting charged. To avoid incurring a needless hourly charge from AWS, remember to release any unassociated IPs you no longer need.

Elastic Load Balancers (with no instances)

Cloud load balancing allows users to distribute workloads and traffic with the benefit of the cloud’s scalability. All major cloud providers offer some type of load balancing – AWS users can balance workloads and distribute traffic among EC2 instances with its Elastic Load Balancer, Google Cloud can distribute traffic between VM instances with Google Cloud Load Balancing, and Azure’s Load Balancer distributes traffic across multiple data centers.   

An AWS Elastic Load Balancer (ELB) will incur charges to your bill as long as it’s configured with your account. Like with Elastic IPs, whether you’re using it or not – you’re paying. If you have no instances associated with your ELB, delete to avoid paying needless charges on your monthly bill.   

Unused Machine Images (AMIs)

A Machine Image provides the information required to launch an instance, which is a virtual server in the cloud. In AWS they’re called AMIs, in Azure they’re Managed Images, and in Google Cloud Platform they’re Custom Images.

As part of your measures to reduce unnecessary costs from orphaned volumes, delete unused machine images when you no longer need them. Unless deleted, the snapshot that was created when the image was first created will continue to incur storage costs.

Object Storage

One of the growing pains that organizations face is the management of isolated pools of data in their cloud environment. Fragmented storage can result from data coming from a number of sources used by applications and business processes. Object Storage was designed to break down silos into scalable, cost-effective storage to store data in its native format. AWS offers object storage solutions like Amazon S3 and Amazon Glacier, Google has Google Cloud Storage, and Azure calls its solution Azure Blob Storage. All options help you manage your storage in one place, keeping your data organized and your business more cost effective.  

Although object storage in and of itself is a cost effective solution, there are still ways to optimize and reduce costs within this solution. Delete files you no longer need so that you’re not paying for them. Delete unused files which can be recreated. In S3, use the “lifecycle” feature to delete or overwrite older versions of data. Clean up incomplete uploads that were interrupted, resulting in partial objects that are taking up needless space. And compress your data before storing to give you better performance and reduce your storage requirements.

How to Avoid Wasted Spend on Orphaned Cloud Resources

Don’t let forgotten resources waste money on your cloud bill. Put a stop to cloud waste by eliminating orphaned cloud resources and inactive storage, saving space, time, and money in the process. Remember to:

  • Release unassociated IPs you no longer need.
  • Remove Elastic Load Balancers with no instances attached.
  • Delete unused machine images when you no longer need them.
  • Keep object storage minimal – optimize by “cleaning up” regularly, removing files you don’t need.

The premise of the cloud and the resources available to you were meant to be cost effective, but it’s up to you keep costs in check. Optimize your cloud spend with visibility, management, and cost automation tools like ParkMyCloud to get the most out of your cloud environment.  

Read more ›

Why Your Spring Cleaning Should Include Unused Cloud Resources

Given that spring is very much in the air – at least it is here in Northern Virginia – our attention has turned to tidying up the yard and getting things in good shape for summer. While things are not so seasonally-focused in the world of cloud, the metaphor of taking time out to clean things up applies to unused cloud resources as well. We have even seen some call this ‘cloud pruning’ (not to be confused with the Japanese gardening method).

Cloud pruning is important for improving both cost and performance of your infrastructure. So what are some of the ways you can go about cleaning up, optimizing, and ensuring that our cloud environments are in great shape?

Delete Old Snapshots

Let’s start with focusing on items that we no longer need. One of the most common types of unused cloud resources is old Snapshots. These are your old EBS volumes on AWS, your storage disks (blobs) on Azure, and persistent disks on GCP. If you have had some form of backup strategy then it’s likely that you will understand the need to manage the number of snapshots you keep for a particular volume, and the need to delete older, unneeded snapshots. Cleaning these up immediately helps save on your storage costs and there are a number of best practices documenting how to streamline this process as well as a number of free and paid-for tools to help support this process.

Delete Old Machine Images

A Machine Image provides the information required to launch an instance, which is a virtual server in the cloud. In AWS these are called AMIs, in Azure they’re called Managed Images, and in GCP Custom Images. When these images are no longer needed, it is possible to deregister them. However, depending on your configuration you are likely to continue to incur costs, as typically the snapshot that was created when the image was first created will continue to incur storage costs. Therefore, if you are finished with an AMI, be sure to ensure that you also delete its accompanying snapshot. Managing your old AMIs does require work, but there are a number of methods to streamline these processes made available both by the cloud providers as well as third-party vendors to manage this type of unused cloud resources.

Optimize Containers

With the widespread adoption of containers in the last few years and much of the focus on their specific benefits, few have paid attention to ensuring these containers are optimized for performance and cost. One of the most effective ways to maximize the benefits of containers is to host multiple containerized application workloads within a single larger instance (typically large or x-large VM) rather than on a number of smaller, separate VMs. In particular, this is something you would could utilize in your dev and test environments rather than in production, where you may just have one machine available to deploy to. As containerization continues to evolve, services such as AWS’s Fargate are enabling much more control of the resources required to run your containers beyond what is available today using traditional VMs. In particular, the ability to specify the exact CPU and memory your code requires (and thus the amount you pay) scales exactly with how many containers you are running.

So alongside pruning your trees or sweeping your deck and taking care of your outside spaces this spring, remember to take a look around your cloud environment and look for opportunities to remove unused cloud resources to optimize not only for cost, but also performance.

Read more ›

5 Ways to Get Discounts on Cloud Resources

Whether you’re just getting started on public cloud, or you’ve gotten a bill that blew your budget out of the water, it’s a good idea to research ways to get discounts on cloud resources. There’s no reason to pay list price when so many cost-savings measures are available (and your peers are probably taking advantage of them!) Here are our top five ways to get discounts on cloud.

1. Buy in Advance

By purchasing your compute power in advance, you can get a discounted rate — the notable examples being AWS Reserved Instances, Azure Reserved Instances, and Google Committed Use Discounts.

So will these save you money? Actually, that’s a great question. There are several factors that weigh into the answer:

  • How much you pay upfront (for example AWS offers all-upfront, partial-upfront, or no-upfront)
  • Contract term: 1-year or 3-year term – the longer term will save more, but there’s risk involved in committing for that long
  • If the cloud provider cuts their prices during your contract term (and they probably will), you’ll save less

This blog post about AWS Reserved Instances digs into these issues further. Bottom line: paying in advance can save you money, but proceed with caution.

2. Use Your Resources More

The primary example of “spending more to save more” in the cloud computing world is Google Sustained Use Discounts. This is a cool option for automatic savings – as long as you use an instance for at least 25% of the month, GCP will charge you less than list price.

But just like the advanced purchasing options above, there are several factors to account for before assuming this will really save you “up to 60%” of the cost. It may actually be better to just turn off your resources when you’re not using them – more in this post about Google Sustained Use Discounts.

3. If You’re Big: Enterprise Agreements and Volume Discounts

Anyone who’s shopped at Costco isn’t surprised that buying in bulk can get you a discount. Last week, Twitter announced that it will be using Google Cloud Platform for cold data storage and flexible compute Hadoop clusters — at an estimated list price of $10,000,000/month. Of course, it’s unthinkable that they would actually pay that much – as such a high-profile customer, Twitter is likely to have massive discounts on GCP’s list prices. We often hear from our Azure customers that they chose Azure due to pre-existing Microsoft Enterprise Agreements that give them substantial discounts.

If you have or foresee a large volume of infrastructure costs, make sure to look into:

4. If You’re Small: Startup Credits

Each of the major cloud providers offers free credit programs to startups to lure them and get locked in on their services – but that’s not a bad thing. We’ve talked to startups focused on anything from education to location services who have gotten their money’s worth out of these credits while they focus on growth.

If you work for a startup, check out:

5. Wait

So far, history tells us that if you wait a few months, your public cloud provider will drop their prices, giving you a built-in discount.

If you stick with the existing resource types, rather than flocking to the newer, shinier models, you should be all set. The same AWS m1.large instance that cost $0.40/hour in 2008 now goes for $0.175. We’ll just say that’s not exactly on pace with inflation.

It’s Okay if You Don’t Get Discounts on Cloud

What if you’re not a startup, you’re not an enterprise, and you just need some regular compute and database infrastructure now? Should you worry if you don’t get discounts on cloud list prices? No sweat. Even by paying list price, it’s still possible to optimize your spend. Make sure you’re combing through your bill every so often to find orphaned or unused resources that need to be deleted.

Additionally, right-size your resources and turn them off when you’re not using them to pay only for what you actually need – you’ll save money, even without a discount.

Read more ›

Interview: ParkMyCloud Empowers Sysco Foods’ Cloud-Only Strategy

We talked with Kurt Brochu, Senior Manager of the Cloud Enablement Team at Sysco Foods, about how his company has been using ParkMyCloud to empower end users to keep costs in check with the implementation of their cloud-only strategy.

Thanks for taking the time to speak with us today. I know we chatted before at re:Invent, where you gave us some great feedback, and we’re excited to hear more about your use of ParkMyCloud since it rolled out to your other teams.

To get started, can your describe your role at Sysco and what you do?

I’m senior manager here in charge of the cloud enablement team. The focus is on public cloud offerings, where we function as the support tier for the teams that consume those services. I also have ownership of ensuring that cost containment and appropriateness of use is being performed, as well as security and connectivity, network services, authentication, and DNS.

We don’t consider ourselves IT, our department is referred to as Business Technology. Our CTO brought us on 3 or 4 years ago with the expectation that we understand the business needs, wants, and desires, to actually service them as they would need versus passively telling them that their server is up or down.

As well as security and the dev team, teams using cloud also include areas that are customer facing, like sales, or internal, like finance, business reporting, asset management, and the list goes on.

Tell us about your company’s cloud usage.

We’ve had our own private cloud since 2003, offered on-prem. We’ve been in public cloud since 2013. Now, our position has gone from a “cloud-first” to a “cloud-only” strategy in the sense that any new workload that comes along is primarily put in public cloud. We primarily use AWS and are adding workloads to Azure as well.

Talk to me about how cost control fits into your cloud-only strategy. How did you realize there was a problem?

We were seeing around 20% month over month growth in expenditure between our two public clouds. Our budget wasn’t prepared for that type of growth.

We realized that some of the teams that had ability to auto-generate workloads weren’t best managing their resources. There wasn’t an easy way to show the expenses in a visual manner to present them to Sysco, or to give them some means to manage the state of their workloads.

The teams were good at building other pipelines for bringing workloads online but they didn’t have day-to-day capabilities.

How did you discover ParkMyCloud as a solution to your cost control problem?

We first stumbled upon ParkMyCloud at the 2016 AWS re:Invent conference and were immediately intrigued but didn’t have the cycles to look into it until this past summer, when when we made the switch from cloud-first to a cloud-only strategy.

We’ve been running ParkMyCloud since the week before re:Invent in 2017. From there, we had our first presentation to our leadership team in December 2017, where we showed that the uptick in savings was dramatic. It’s leveled off right now because we have a lot of new workloads coming in, but the savings are still noticeable. We still have developers who think that their dev system has to be always be on and at will, but they don’t understand that now that we have ParkMyCloud, making it “at will” is as simple as an API call or the click of a button. I expect to see our savings to grow over the rest of the calendar year.

We have 50+ teams and over 500 users on ParkMyCloud now.

That’s great to hear! So how much are you saving on your cloud costs with ParkMyCloud?

Our lifetime savings thus far is $28,000, and the tool has paid for itself pretty quickly.

We have one team who has over 40% savings on their workloads. They were spending on average about $10,000 a month, and now it’s at $5,800 because they leverage ParkMyCloud’s simplified scheduling start/stop capabilities.

What other benefits are you getting from your use of the platform?

What I really like is that we have given most of our senior directors, who actually own the budgets, access to the tool as well. It lets the senior directors, as well as the executives when I present to them, see the actual cost savings. It gives you the ability to shine light in places that people don’t like to have the light shine.

The development team at ParkMyCloud has also been very open to receiving suggestions and capabilities that will help us improve savings and increase user adoption.

That’s great, and please continue to submit your feedback and requests to us! And in that regard, have you tried our SmartParking feature to get recommended schedules based on your usage?

Yes, we have started to. When I’m asked by a team to show them how we suggest they use the tool, they get to decide whether or not to enforce it. I’ll say that they are exceedingly happy by the fact that they can go and see their usage. One developer is telling their team that the feature has to be on at all times.

Are there any other cost savings measures that you use in conjunction with ParkMyCloud or in addition?

We pull numbers and look at Amazon’s best prices guide for sizing. We also take the recommendations from ParkMyCloud and we cross compare those.

Do you have any other feedback for us?

The magic of ParkMyCloud is that it empowers the end user to make decisions for the betterment of business, and gives us the needed visibility to do our jobs effectively. That’s the bottom line. Each user has a decision: I can spend money on wasted resources or I can save it where I can and apply the savings to other projects. Once you start to understand that, then you have that “AHA” moment.

Before using ParkMyCloud, most developers have no awareness of the expense of their workloads. This tool allows me to unfilter that data so they can see, for example: this workload is $293 a month, every month. If you look at your entire environment, you’re spending $17,000 a month, but if you take it down just for the weekend, you could be saving $2-3,000 a month or more depending on how aggressive you want to be, without hurting your ability to support the business. It’s that “AHA” moment that is satisfying to watch.

That’s what we noticed immediately when we looked at the summary reports  – the uptick that appears right after you have these presentations with the team makes your heart feel good.

Well thank you Kurt, again we really appreciate you taking the time to speak with us.

Thank you.

Read more ›

Interview: Qcentive Saves Significant Amounts on AWS while Enabling Cloud Computing in Healthcare

We talked with Bill Gullicksen, Director of IT at Qcentive, about how the company is using ParkMyCloud to save money on their AWS costs while enabling cloud computing in healthcare.

Thanks for taking the time to speak with us today. Can you start by telling me about Qcentive and how you are using the cloud?

We are a 2-year-old healthcare startup founded through the venture capital arm of Blue Cross Blue Shield of Massachusetts (BCBSMA). We build systems for the healthcare industry to help reduce costs in healthcare and provide efficiencies. Our cloud-based payment platform will facilitate the development and management of value-based contracts between healthcare companies. We are excited to be one of the earliest vendors authorized to take healthcare information and move it securely to the cloud.

What do you think made Qcentive stand apart as the best option for moving data to the cloud?

Healthcare has historically been cloud-averse due to issues like privacy and security concerns. In order to prove the use case for cloud computing in healthcare, we needed to build out a prototype and go through many months of meetings–producing artifacts to prove that we could move data to the cloud in a HIPAA/HITECH-compliant and secure manner.

We’ve recently released our first prototype module of the application by taking years of patient and healthcare contract information, loading it all into AWS, and then putting our application on top of it. Our application allows our health plan customers and their value-based contracting provider partners to analyze healthcare claim records, emergency room visits, etc. and to quickly calculate how to potentially realize savings in those areas.

So as you’re helping healthcare companies transition to the cloud, how did you come to find ParkMyCloud as a useful tool for your mission?

We had a few architects just going to town on AWS during the first year we were in business. They were building away, and all of a sudden our monthly AWS costs began to ramp up. We were spending a lot of money on Amazon and we didn’t even have a working application yet!

Last summer I was put in charge of our AWS operations and was asked to address our AWS costs. I asked, “what can we do to get some of these costs under control?” We started out with some rightsizing exercises and scaled some stuff back and that got us some savings. We found areas where we have had some stability and used Reserved Instances there, allowing us to get a 30-40% discount, but we didn’t want to do long-term commitments so we only did those for a year.

For the remaining instances, I realized we pay by the minute and we really don’t need to be running instances 24/7. That’s that’s when we started thinking about how to schedule instances to shut down. I could do that and turn them off with AWS tools, but then telling an instance to turn itself back on at 6 in the morning–I didn’t have a way to do that. And that’s when I found out about ParkMyCloud and said this looks perfect – we can schedule instances to get them running 12 hours a day, 5 days a week instead of 24/7 and we’ll probably cut our costs in half.

Have you discovered any other benefits while using ParkMyCloud?

ParkMyCloud was the perfect tool for what we needed at the time and it also gave us a side benefit where we could give developers, QA people, and even data analysts and business folks the ability to turn an instance off when they’re done, or turn it on without having to write a bunch of complex policies within AWS.

Before, if we only wanted certain people to be able to manipulate a handful of instances, I had to put those instance IDs in the policies. Instance IDs frequently change, so running custom policies was taking a lot of overhead and we got the benefit from ParkMyCloud of just assigning them teams. Now, whether the instance IDs change or not, there’s no extra work for our IT team.

That’s why we chose ParkMyCloud and why we’ve been using it for 6-7 months now. For me it was great, very simple to set up, simple to use, easy for non-technical users and with very little effort from me and my technical staff, so it’s been perfect.

Great. So it seems like you were using a good mix of different cost savings efforts between the reserved instances, the rightsizing, and ParkMyCloud. Is there anything else you’re doing to manage cloud re-infrastructure costs?

Those are the bulk of it. We have other cloud-tracking subscriptions that we use sometimes. They are very simple but I just use it for looking at the daily spend, seeing if there’s any unexpected spikes, things like that. I can use it for finding resources that are no longer being used. It’s nice to have for identifying orphaned volumes and gives me a simple, easy way to clean some of that up, but we get our biggest use out of ParkMyCloud.

What percent of your resources are currently on ParkMyCloud schedules?

We’ve taken some schedules off just to keep some systems up for a while, but our rule of thumb has been to put a schedule and a team on everything. Even if a schedule is running 24/7/365, we want to at least have a schedule on it and know that it’s a conscious business decision we made to keep that up versus “it just slipped through the cracks and we never looked at it.”

About how many people in your team or organization are using ParkMyCloud?

Somewhere around 15 or so users.

Where do those users sit within your organization?

I’m Director of IT and we’ve got a Director of DevOps and a DevOps engineer–we are the three technical resources around infrastructure. Then we’ve got around 10 or so software developers that all have access so they can spin up their dev environments and spin them down when they’re not working.

We have a flexible schedule. Some of our software developers do their best coding at 3 in the morning. If they get up with an idea and they want to code, they need the ability to start up instances, do what they need to do, and then turn them off when they’re done. So they’re all in there, our QA department and some business analysts that do a lot of data analysis and database querying are also using ParkMyCloud.

That makes sense. So, how much are you saving on your AWS bills using ParkMyCloud?

Our initial savings with ParkMyCloud were significant and the product paid for itself quickly. Based on business needs, our costs can escalate rapidly so we estimate we’re saving up to 20% on our costs on a monthly basis.

We’ve got a lot of instances that we keep normally parked now and we only turn them on when there’s a workload to run. And then we’ve got probably another 40 or 50% of our instances that only run Monday through Friday, from 7:00 AM to 7:00 PM, so we’re getting that savings there which to me is bigger savings than dealing with Reserved Instances.

Things like Reserved Instances look great the day you buy them, but then the first time you have to change the size on something, all of the sudden you’ve got Reserved Instances that you’re not using anymore. With ParkMyCloud that never happens, it’s all savings.

How did you first hear about ParkMyCloud?

We were interviewing an external technology company, G2 Technologies in Boston last summer that was being brought in to augment our CI/CD process. While they were in we asked, “hey, do you know any good methods for doing scheduling?” – and they said take a look at ParkMyCloud.

Any other feedback for us?

I was surprised how simple ParkMyCloud was to get up and running. It was a couple of hours from signing up for the trial to having most of the work done and realizing savings, which was great. The release of your mobile app has been fantastic because it’s nice if we need to turn something on for somebody that doesn’t have access on a Saturday when I’m 30 miles away from my computer. I can do it anywhere with the mobile app.

Glad to hear it! I think that wraps things up for now. Thank you Bill, I appreciate your time.

You’re welcome!

Read more ›

Don’t Let Your Server Patching Schedule Get in the Way of Cost Control

Don’t let your server patching schedule get in the way of saving money. The idea of minimizing cloud waste was a very new concept two years ago, but as cloud use has grown, so has the need for minimizing wasted spend. CFOs now demand that the cloud operations teams turn off idle systems in the face of rising cloud bills, but the users of these systems are the ones that have to deal with servers being off when they need them.

Users of ParkMyCloud are able to overcome some of the common objections to scheduling non-production resources. The most common objection is, “What if I need the server or database when it’s scheduled to be off?” That’s why ParkMyCloud offers the ability to “snooze” the schedule, which is a temporary override that lets you choose how long you need the system for. This snooze can be done easily from our UI, or through alternative methods like our API, mobile app, or Slackbot.

A related objection is related to how your parking schedule can work with your server patching schedule. The most common way of dealing with patching in ParkMyCloud is to use our API. The workflow would be to log in through the API, get a list of the resources, then choose which resources you want and choose to “snooze” the schedule for a couple of hours, or however long the patching takes. Once the schedule is snoozed, you can toggle the instance on, then do the patching. After the patching is complete, you can either cancel the snooze to go back to the original schedule or wait for the snooze to finish and timeout. If you have an automated patching tool that can make REST calls, this can be an easy way to patch on demand with minimal work.

If you’re on a weekly server patching schedule, you could also just implement the patch times into your pre-set schedules so that the instances turn on, say, at 2:00 a.m. on Wednesdays. By plugging this into your normal schedules, you can still save money during most off-hours, but have the instances on when the patch window is open. This can be a great way to do weekly backups as well, with minimal disruption.

This use of ParkMyCloud while plugging in to external tools and processes is the best way to get every developer and CloudOps engineer on board with continuous cost control. By reducing these objections, you can reduce your cloud costs and be the hero of your organization. Start up a free trial today to see these plug-ins in action!

Read more ›

AWS Neptune Preview – Amazon’s Graph Database Service

At the AWS DC Meetup we organized last week, we got a preview of AWS Neptune, Amazon’s new managed graph database service. It was announced at AWS re:Invent 2017, is currently in preview and will launch for general availability this summer.

What is a graph database?

A graph database is a database optimized to store and process highly connected data – in short, it’s about relationships. The data structure for these databases consists of vertices and direct links called edges.

Use cases for such highly-connected data include social networking, restaurant recommendations, retail fraud detection, knowledge graphs, life sciences, and network & IT ops. For a restaurant recommendations use case, for example, you may be interested in the relationships between various users, where those users live, what types of restaurants those users like, where the restaurants are located, what sort of cuisine they serve, and more. With a graph database, you can use the relationships between these data points to provide contextual restaurant recommendations to users.

Tired of SQL?

If you’re tired of SQL, AWS Neptune may be for you. A graph database is fundamentally different from SQL. There are no tables, columns, or rows – it feels like a NoSQL database. There are only two data types: vertices and edges, both of which have properties stored as key-value pairs.

AWS Neptune is fully managed, which means that database management tasks like hardware provisioning, software patching, setup, configuration, and backups are taken care of for you.

It’s also highly available and shows up in multiple availability zones. This is very similar to Aurora, the relational database from Amazon, in its architecture and availability.

Neptune supports Property Graph and W3C’s RDF. You can use these to build your own web of data sets that you care about, and build networks across the data sets in the way that makes sense for your data, not with arbitrary presets. You can do this using the graph models’ query languages: Apache TinkerPop Gremlin and SPARQL.

There is no cost to use Neptune during the preview period. Once it’s generally available, pricing will rely on On Demand EC2 instances – which means ParkMyCloud will be looking into ways to assist Neptune users with cost control.

If you’re interested in the new service, you can check out more about AWS Neptune and sign up for the preview.

Read more ›

7 Ways Cloud Services Pricing is Confusing

Beware the sticker shock – cloud services pricing is nothing close to simple, especially as you come to terms with the dollar amount on your monthly cloud bill. While cloud service providers like AWS, Azure, and Google were meant to provide compute resources to save enterprises money on their infrastructure, cloud services pricing is complicated, messy, and difficult to understand. Here are 7 ways that cloud providers obscure pricing on your monthly bill:  

1 – They use varying terminology

For the purpose of this post, we’ll focus on the three biggest cloud service providers: AWS, Azure, and Google. Between these three cloud providers alone, different analogies are used for just about every component of services offered.

For example, when you think of a virtual machine (VM), that’s what AWS calls an “instance,” Azure calls a “virtual machine,” and Google calls a “virtual machine instance.” If you have a group of these different machines, or instances, in Amazon and Google they’re called “auto-scaling” groups, whereas in Azure they’re called “scale sets.” There’s also different terminology for their pricing models. AWS offers on-demand instances, Azure calls it “pay as you go,” and Google refers to it as “sustained use.” You’ve also got “reserved instances” in AWS, “reserved VM instances” in Azure, and “committed use” in Google. And you have spot instances in AWS, which are the same as low-priority VMs in Azure, and preemptible instances in Google.

2 – There’s a multitude of variables

Operating systems, compute, network, memory, and disk space are all different factors that go into the pricing and sizing of these instances. Each of these virtual machine instances also have different categories: general purpose, compute optimized, memory optimized, disk optimized and other various types. Then, within each of these different instance types, there are different families. In AWS, the cheapest and smallest instances are in the “t2” family, in Azure they’re called the “A” family. On top of that, there are different generations within each of those families, so in AWS there’s t2, t3, m2, m3, m4, and within each of those processor families, different sizes (small, medium, large, and extra large). So there’s lots of different options available. Oh, and lots confusion, too.  

3 – It’s hard to see what you’re spending

If you aren’t familiar with AWS, Azure, or Google Cloud’s consoles or dashboards, it can be hard to find what you’re looking for. To find specific features, you really need to dig in, but event just trying to figure out the basics of how much you’re currently spending, and predicting how much you will be spending – all can be very hard to understand. You can go with the option of building your own dashboard by pulling in from their APIs, but that takes a lot of upfront effort, or you can purchase an external tool to manage overall cost and spending.

4 – It’s based on what you provision…not what you use

Cloud services pricing can charge on a per-hour, per-minute, or per-second basis. If you’re used to the on-prem model where you just deploy things and leave them running 24/7, then you may not be used to this kind of pricing model. But when you move to the cloud’s on-demand pricing models, everything is based on the amount of time you use it.

When you’re charged per hour, it might seem like 6 cents per hour is not that much, but after running instances for 730 hours in a month, it turns out to be a lot of money. This leads to another sub-point: the bill you get at the end of the month doesn’t come until 5 days after the month ends, and it’s not until that point that you get to see what you’ve used. As you’re using instances (or VMs) during the time you need them, you don’t really think about turning them off or even losing servers. We’ve had customers who have servers in different regions, or on different accounts that don’t get checked regularly, and they didn’t even realize they’ve been running all this time, charging up bill after bill.

You might also be overprovisioning or oversizing resources — for example, provisioning multiple extra large instances thinking you might need them someday or use them down the line. If you’re used to that, and overprovisioning everything by twice as much as you need, it can really come back to bite you when you go look at the bill and you’ve been running resources without utilizing them, but are still getting charged for them – constantly.

5 – They change the pricing frequently

Cloud services pricing has changed quite often. So far, they have been trending downward, so things have been getting cheaper over time due to factors like competition and increased utilization of data centers in their space. However, don’t jump to conclude that price changes will never go up.

Frequent price changes make it hard to map out usage and costs over time. Amazon has already made changes to their price more than 60 times since they’ve been around, making it hard for users to plan a long-term approach. Also for some of these instances, if you have them deployed for a long time, the prices of instances don’t display in a way that is easy to track, so you may not even realize that there’s been a price change if you’ve been running the same instances on a consistent basis.

6 – They offer cost savings options… but they’re difficult to understand (or implement)

In AWS, there are some cost savings measures available for shutting things down on a schedule, but in order to run them you need to be familiar with Amazon’s internal tools like Lambda and RDS. If you’re not already familiar, it may be difficult to actually implement this just for the sake of getting things to turn off on a schedule.  

One of the other things you can use in AWS is Reserved Instances, or with Azure you can pay upfront for a full year or two years. The problem: you need to plan ahead for the next 12 to 24 months and know exactly what you’re going to use over that time, which sort of goes against the nature of cloud as a dynamic environment where you can just use what you need. Not to mention, going back to point #2, the obscure terminology for spot instances, reserved instances, and what the different sizes are.

7 – Each service is billed in a different way

Cloud services pricing shifts between IaaS (infrastructure as a service), which uses VMs that are billed one way, and PaaS (platform as a service) gets billed another way. Different mechanisms for billing can be very confusing as you start expanding into different services that cloud providers offer.

As an example, the Lambda functions in AWS are charged based on the number of requests for your functions, the duration, and the time it takes for your code to execute. The Lambda free tier includes 1M free requests per month and 400,000 GB-seconds of compute time per month, or you can get 1M request free and $0.20 per 1M requests thereafter, OR use “duration” tier and get 400,000 GB-seconds per month free, $0.00001667 for every GB-second used thereafter – simple, right? Not so much.

Another example comes from the databases you can run in Azure. Databases can run as a single server or can be priced by elastic pools, each with different tables based on the type of database, then priced by storage, number of databases, etc.

With Google Kubernetes clusters, you’re getting charged per node in the cluster, and each node is charged based on size. Nodes are auto-scaled, so price will go up and down based on the amount that you need. Once again, there’s no easy way of knowing how much you use or how much you need, making it hard to plan ahead.

What can you do about it?

Ultimately, cloud service offerings are there to help enterprises save money on their infrastructures, and they’re great options IF you know how to use them. To optimize your cloud environment and save money on costs, we have a few suggestions:

    • Get a single view of your billing. You can write your own scripts (but that’s not the best answer) or use an external tool.  
    • Understand how each of the services you use is billed. Download the bill, look through it, and work with your team to understand how you’re being billed.
    • Make sure you’re not running anything you shouldn’t be. Shut things down when you don’t need them, like dev and test instance on nights and weekends.Try to plan out as much as you can in advance.
    • Review regularly to plan out usage and schedules as much as you can in advance
    • Put governance measures in place so that users can only access certain features, regions, and limits within the environment. 

Cloud services pricing is tricky, complicated, and hard to understand. Don’t let this confusion affect your monthly cloud bill. Try ParkMyCloud for an automated solution to cost control.

Read more ›

How to Use Terraform Provisioning and ParkMyCloud to Manage AWS

Recently, I’ve been on a few phone calls where I get asked about cost management of resources built in AWS using Terraform provisioning. One of the great things about working with ParkMyCloud customers is that I get a chance to talk to a lot of different technical teams from various types of businesses. I get a feel for how the modern IT landscape is shifting and trending, plus I get exposed to the variety of tools that are used in real-world use cases, like Atlassian Bamboo, Jenkins, Slack, Okta, and Hashicorp’s Terraform.

Terraform seems to be the biggest player in the “infrastructure as code” arena. If you’re not already familiar with it, the utilization is fairly straightforward and the benefits quickly become apparent. You take a text file, use it to describe your infrastructure down to the finest detail, then run “terraform apply” and it just happens. Then, if you need to change your infrastructure, or revoke any unwanted changes, Terraform can be updated or roll back to a known state. By working together with AWS, Azure, VMware, Oracle, and much more, Terraform can be your one place for infrastructure deployment and provisioning.

How to Use Terraform Provisioning and ParkMyCloud with AWS Autoscaling Groups

I’ve talked to a few customers recently, and they utilize Terraform as their main provisioning tool, while ParkMyCloud is their ongoing cloud governance and cost control tool. Using these two systems together is great, but one main confusion comes in with AWS’s AutoScaling Groups. The question I usually get asked is around how Terraform handles the changes that ParkMyCloud makes when scheduling ASGs, so let’s take a look at the interaction.

When ParkMyCloud “parks” an ASG, it sets the Min/Max/Desired to 0/0/0 by default, then sets the values for “started” to the values you had originally entered for that ASG. If you run “terraform apply” while the ASG is parked, then terraform will complain that the Min/Max/Desired values are 0 and will change them to the values you state. Then, when ParkMyCloud notices this during the next time it pulls from AWS (which is every 10 minutes), it will see that it is started and stop the ASG as normal.

If you change the value of the Min/Max/Desired in Terraform, this will get picked up by ParkMyCloud as the new “on” values, even if the ASG was parked when you updated it. This means you can keep using Terraform to deploy and update the ASG, while still using ParkMyCloud to park the instances when they’re idle.

How to Use Terraform to Set Up ParkMyCloud

If you currently leverage Terraform provisioning for AWS resources but don’t have ParkMyCloud connected yet, you can also utilize Terraform to do the initial setup of ParkMyCloud. Use this handy Terraform script to create the necessary IAM Role and Policy in your AWS account, then paste the ARN output into your ParkMyCloud account for easy setup. Now you’ll be deploying your instances as usual using Terraform provisioning while parking them easily to save money!

Read more ›

$12.9 Billion in wasted cloud spend this year.

Wake up and smell the wasted cloud spend. The cloud shift is not exactly a shift anymore, it’s an evident transition. It’s less of a “disruption” to the IT market and more of an expectation. And with enterprises following a visible path headed towards the cloud, it’s clear that their IT spend is going in the same direction: up.

Enterprises have a unique advantage as their cloud usage continues to grow and evolve. The ability to see where IT spend is going is a great opportunity to optimize resources and minimize wasted cloud spend, and one of the best ways to do that is by identifying and preventing cloud waste.

So, how much cloud waste is out there and how big is the problem? What difference does this make to the enterprises adopting cloud services at an ever-growing rate? Let’s take a look.

The State of the Cloud Market in 2018

The numbers don’t lie. For a real sense of how much wasted cloud spend there is, the first step is to look at how much money enterprises are spending in this space at an aggregate level.

Gartner’s latest IT spending forecast predicts that worldwide IT spending will reach $3.7 trillion in 2018, up 4.5 percent from 2017. Of that number, the portion spent in the public cloud market is expected to reach $305.8 billion in 2018, up $45.6 billion from 2017.

The last time we examined the numbers back in 2016, the global public cloud market was sitting at around $200 billion and Gartner had predicted that the cloud shift would affect $1 trillion in IT spending by 2020. Well, with an updated forecast and over $100 billion dollars later, growth could very well exceed predictions.

The global cloud market and the portion attributed to public cloud spend are what give us the ‘big picture’ of the cloud shift, and it just keeps growing, and growing, and growing. You get the idea. To start understanding wasted cloud spend at an organizational level, let’s break this down further by looking at an area that Gartner says is driving a lot of this growth: infrastructure as a service (IaaS).

Wasted Cloud Spend in IaaS

As enterprises increasingly turn to cloud service providers like Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) to provide compute resources for hosting components of their infrastructures, IaaS plays a significant role in both cloud spend and cloud waste.

Of the forecasted $305.8 billion dollar public cloud market  for 2018, $45.8 billion of that will be spent on IaaS, ⅔ of which goes directly to compute resources. This is where we get into the waste part:

  • 44% of compute resources are used for non-production purposes (i.e. development, staging, testing, QA)
  • The majority of servers used for these functions only need to run during the typical 40-hour work week (Monday through Friday, 9 to 5) and do not need to run 24/7
  • Cloud service providers are still charging you by the hour (or minute, or even by the second) for providing compute resources

The bottom line: for the other 128 hours of the week (or 7,680 minutes, or 460,800 seconds) – you’re getting charged for resources you’re not even using. And there’s a large percent of your waste!

What You Can Do to Prevent Wasted Cloud Spend

Turn off your cloud resources.

The easiest and fastest way to save money on your idle cloud resources when  is by simply by not using them. In other words, turn them off. When you think of the cloud as a utility like electricity, it’s as simple as turning off the lights every night and when you’re not at home. With ParkMyCloud you can automatically schedule your cloud resources to turn off when you don’t need them, like nights and weekends, and eliminate 65% or more on your monthly bill with AWS, Azure, and Google. Wham. bam.

Turn on your SmartParking.

You already know that you don’t need your servers to be on during nights and weekends, so you shut them off. That’s great, but what if you could save even more with valuable insight and information about your exact usage over time?

With ParkMyCloud’s new SmartParking feature, the platform will track your utilization data, look for patterns and create recommended schedules for each instance, allowing you to turn them off when they’re typically idle.

There’s a lot of cloud waste out there, but there’s also something you can do about it: try ParkMyCloud today.

Read more ›

The Cost of Cloud Computing Is, in Fact, Dropping Dramatically

You might read the headline statement that the cost of cloud computing is dropping  and say “Well, duh!”. Or maybe you’re on the other side of the fence. A coworker recently referred me to a very interesting blog on the Kapwing site that states Cloud costs aren’t actually dropping dramatically. The author defines“dramatically” based on the targets set by Moore’s Law or the more recently proposed Bezos’ Law, which states that “a unit of [cloud] computing power price is reduced by 50 percent approximately every three years.” The blog focused on the cost of the Google Cloud Platform (GCP) n1-standard-8 machine type, and illustrated historical data for the Iowa region:

Date N1-standard-8 Cost per Hour
January 2016 $0.40
January 2017 $0.40
January 2018 $0.38

The Kapwing blog also illustrates that the GCP storage and network egress costs have not changed at all in three years. These figures certainly add up to a conclusion that Bezos’ Law is not working…at least not for GCP.

Whose law is it anyway?

If we turn this around and try to apply Bezos’ Law to, well, Bezos’ Cloud we see a somewhat different story.

The approach to measuring AWS pricing changes needs to be a bit more systematic than for GCP, as the AWS instance types have been evolving quite a bit over their history. This evolution is shown by the digit that follows the first character in the instance type, indicating the version or generation number of the given instance type . For example, m1.large vs. m5.large. These are similar virtual machines in terms of specifications, with 2 vCPUs and about 8GB RAM, but the m1.large was released in October 2007, and the m5.large in November 2017. While  the “1” in the GCP n1-standard-8 could also be a version number,  it is still the only version I can see back to at least 2013. For AWS, changes in these generation numbers happen more frequently and likely reflect the new generations of underlying hardware on which the instance can be run.

Show me the data!

In any event, when we make use of the Internet Archive to look at  pricing changes of the specific instance type as well as the instance type “family” as it evolves, we see the following (all prices are USD cost per hour for Linux on-demand from the us-east-1 region in the earliest available archived month of data for the quoted year):

m1.large m3.large m4.large m5.large Reduction from previous year/generation 3-year reduction
2008 $0.40
2009 $0.40 0%
2010 $0.34  -18%
2011 $0.34 0% -18%
2012 $0.32 -6% -25%
2013 $0.26 -23% -31%
2014 $0.24 $0.23 -13% -46%
2015 $0.175 $0.14 -64% -103%
2016 $0.175 $0.133 $0.120 -17% -80%
2017 $0.175 $0.133 $0.108 -11% -113%
2018* $0.175 $0.133 $0.100 $0.096 -13% -46%

*Latest Internet Archive data from Dec 2017 but confirmed to match current Jan 2018 AWS pricing.

FWIW: The second generation m2.large instance type was skipped, though in October 2012 AWS released the “Second Generation Standard” instances for Extra Large and Double Extra Large – along with about an 18% price reduction for the first generation.

To confirm that we can safely compare these prices, we need to look at how the mX.large family has evolved over the years:

Instance type Specifications
m1.large (originally defined as the “Standard Large” type) 2vCPU w/ECU of 4, 7.5GB RAM
m3.large 2vCPU w/ECU of 6.5, 7.5GB RAM
m4.large 2vCPU w/ECU of 6.5, 8GB RAM
m5.large 2vCPU w/ECU of 10, 8GB RAM

A couple of notes on this:

  • ECU is “Elastic Compute Unit” –  a standardized measure AWS uses to support comparison between CPUs on different instance types. At one point, 1 ECU was defined as the compute-power of a 1GHz CPU circa 2007.
  • I realize that the AWS mX.large family is not equivalent to the GCP n1-standard-8 machine type mentioned earlier, but I was looking for an AWS machine type family with a long history and fairly consistent configuration(and this is not intended to be a GCP vs AWS cost comparison).

The drop in the cost of cloud computing looks kinda dramatic to me…

The net average of the 3-year reduction figures is -58% per year, so Bezos’ Law is looking pretty good. (And there is probably an interesting grad-student dissertation somewhere about  how serverless technologies fit into Bezos’ Law…)  When you factor the m1.large ECU of 4 versus the m5.large ECU of 10 into the picture, more than doubling the net computing power, one could easily argue that Bezos’ Law significantly understates the situation. Overall, there is a trend here of not just a significantly declining prices, but also greatly increased capability (higher ECU and more RAM), and certainly reflecting an increased value to the customer.

So, why has the pricing of the older m1 and m3 generations gone flat but is still so much more expensive? On the one hand, one could imagine that the older generations of underlying hardware consume more rack space and power, and thus cost Amazon more to operate. On the other hand, they have LONG since amortized this hardware cost, so maybe they could drop the prices. The reality is probably somewhere in between, where they are trying to motivate customers to migrate to newer hardware, allowing them to eventually retire the old hardware and reuse the rack space.

Intergenerational Rightsizing

There is definite motivation here to do a lateral inter-generation “rightsizing” move. We most commonly think of rightsizing as moving an over-powered/under-utilized virtual machine from one instance size to another, like m5.large to m5.medium, but intergenerational rightsizing can add up to some serious savings very quickly. For example, an older m3.large instance could be moved to an m5.large instance in about 1 minute or less (I just did it in 55 seconds: Stop instance, Change Instance Type, Start Instance), immediately saving 39%. This can frequently be done without any impact to the underlying OS. I essentially just pulled out my old CPU and RAM chips and dropped in new ones. Note that it is not necessarily this easy for all instance types – some older AMI’s can break the transition to a newer instance type because of network or other drivers, but it is worth a shot, and the AWS Console should let you know if the transition is not supported (of course: as always make a snapshot first!)

Conclusion

For the full view of cloud compute cost trends, we need to look at both the cost of specific instance types, and the continually evolving generations of that instance type. When we do this, we can see that the cost of cloud computing is, in fact, dropping dramatically…at least on AWS.

Read more ›

ParkMyCloud Reviews – Customer Video Testimonials

A few weeks ago at the 2017 AWS re:Invent conference in Las Vegas, we had the opportunity to meet some of our customers at the booth, get their product feedback, and a few shared their ParkMyCloud reviews as video testimonials. As part of our ongoing efforts to save money on cloud costs with a fully automated, simple-to-use SaaS platform, we rely on our customers to give us insight into how ParkMyCloud has helped them. Here’s what they had to say:

TJ McAteer, Prosight Specialty Insurance

“It’s all very well documented. We got it set up within an afternoon with our trial, and then it was very easy to differentiate and show that value – and that’s really the most attractive piece of it.”

As the person responsible for running the cloud engineering infrastructure at ProSight Specialty Insurance, ParkMyCloud had everything TJ was looking for. Not only that, but it was easy to use, well managed, and demonstrated its value right away.

James LaRocque, Decision Resources Group

“What’s nice about it is the ability to track financials of what you’re actually saving, and open it up to different team members to be able to suspend it from the parked schedules and turn it back on when needed.”

As a Senior DevOps engineer at Decision Resources Group, James LaRocque discovered ParkMyCloud at the 2016 AWS re:Invent and has been a customer ever since. He noted that while he could have gone with scripting, ParkMyCloud offered the increased benefits of financial tracking and user capabilities.

“The return on investment is huge.”

Kurt Brochu, Sysco Foods

“We had instant gratification as soon as we enabled it.”

Kurt Brochu, Senior Manager of the Cloud Enablement Team at Sysco Foods, was immediately pleased to see ParkMyCloud saving money on cloud costs as soon as they put it into action. Once he was able to see how much they could save on their monthly cloud bill, the next step was simple.   

“We were able to save over $500 in monthly spend by just using it against one team. We are rolling out to 14 other teams over the course of the next 2 weeks.”

Mark Graff, Dolby Labs

“The main reason why we went for it was that it was easy to give our users the ability to start and stop instances without having to give them access to the console.”

Mike Graff, the Senior Infrastructure Manager at Dolby Labs, became a ParkMyCloud customer thanks to one of his engineers in Europe.

“We just give them credentials, they can hop into ParkMyCloud and go to start and stop instances. You don’t have to have any user permissions in AWS – that was a big win for us.”


We continue to innovate and improve our platform’s cloud cost management capabilities with the addition of SmartParking recommendations, SmartSizing, Alicloud and more. Customer feedback is essential to making sure that not only are we saving our customers time and money, but also gaining valuable insight into what makes ParkMyCloud a great tool.

If you use our platform, we’d love to get a ParkMyCloud review from you and hear about how ParkMyCloud has helped your business – there’s a hoodie in it for you! Please feel free to participate in the comments below or with a direct email to info@parkmycloud.com

 

Read more ›
Page 1 of 3123
Copyright © ParkMyCloud 2016-2018. All rights reserved|Privacy Policy