How Do I Stop Wasting Money on Reserved Instances?

How Do I Stop Wasting Money on Reserved Instances?

“How do I stop wasting money on Reserved Instances?” 

It’s a question we’ve heard before from despairing AWS users. They were told Reserved Instances (RIs) would save them money, so they purchased them. Now, halfway into a three-year contract, they realize they’re not utilizing the RIs they’re paying for. Or worse… they may not even know what RIs they have. 

Amazon offers Reserved Instances to ostensibly help get your cloud costs in control. The message is that RIs help you save money on your EC2 instances by offering discounted hourly rates in exchange for a 1- or 3-year commitment. Before we get into how you can cut your cloud spending with an AWS RI, here’s a bit of background and what you need to know about AWS EC2 Reserved Instance pricing. 

How do EC2 Reserved Instance Purchasing Options Work?

When it comes to Reserved Instances purchasing options, you can either choose a 1- or 3-year contract. The longer the commitment, the greater the cost savings compared to On-Demand. By choosing one of these contracts, customers are promised savings of up to 75%.

There are a few risks that come with the longer commitment times. For starters, if AWS drops pricing, then the promised savings are reduced or may disappear. And when AWS introduces a new generation of an instance type family it may attract your users away from your contracts – these are based on the older generation. If you don’t know your future needs, it may be appealing to use the 1-year instead of a 3-year contract, which has savings vs. On Demand at about 31-40%.

There are three different types of EC2 Reserved Instances that customers can purchase – Standard Reserved Instances, Convertible Reserved Instances, or Scheduled Reserved Instances. With Standard Reserved Instances, customers would see the most significant savings. However, Convertible Reserved Instances are attractive to customers because it gives them added flexibility like the ability to use different instance families, operating systems, or tenancies over the term. Scheduled RIs allow you buy an RI that is only used at certain times each day in a recurring schedule.

When an RI expires, you are charged again at the normal rate.  See the recently released option to queue RI purchases in advance. This may help provide the greatest savings by eliminating gaps in your coverage from reservations.

Additional Ways To Save

AWS also offers additional discounts if you have more than $500,000 worth of Reserved Instances in a region – the more Reserved Instances you have, the larger your discount. 

You may also buy RIs on the Reserved Instance Marketplace from third-party sellers. The great thing about this is that these third parties tend to list their RIs at lower prices for a shorter period of time. And if you find you have too many RIs, you can sell them on the Marketplace as well.

Payment plans

There are three different payment plans offered with Reserved Instances. Payments can be made either All Upfront, Partial Upfront, or No Upfront. It is important to note that if you pay all up front, you will have greater savings because there are no other costs or additional charges during the term regardless of the usage hours. 

Some may think that the need to pay upfront and be locked in undermines both “pay as you go” and the notion of being “elastic”- almost like a step backward to the old economic model. 

An example of the savings offered by each EC2 RI option, along with the percent of savings each has over the On-Demand price is shown below. From these graphs, you can see that with a 3-year contract, your savings would be much greater. Other things to note is that you will have greater savings with Standard Instances, as well as if you choose the “All Upfront” payment plan. While you would receive discounted hourly rates for choosing Partial Upfront or No Upfront as a payment plan, if you can, All Upfront would be your best option with the most savings.

How should I use my Reserved Instances?

In non-production environments such as dev, test, QA, and training, Reserved Instances are not your best bet. Why is this the case? These environments are less predictable; you may not know how many instances you need and when you will need them, so it’s better to not waste spend on these usage charges. Instead, schedule such instances (preferably using ParkMyCloud). Scheduling instances to be only up 12 hours per day on weekdays will save you 65% – better than all but the most restrictive 3-year RIs!

Reserved Instances are very much a “use it or lose it” proposition. In other words, there are no rollover minutes – if you don’t use your reserved instances one month you don’t get extra time the next month. Here’s why they are like this:

  • The EC2 options available are specific to Region, Availability Zone, Instance Type (e.g. m5.large) with some exceptions, Platform Type (e.g. Linux or Windows), and Tenancy. AWS, behind the scenes, attempts to randomly match instances you launch to the Reserved Instance contracts you have in place, based on the specific criteria. When there is a match, the cost benefit is applied. It is not uncommon for people to believe they are launching instances that match all the criteria, when in fact they are not, so the contracts are under-utilized. And you won’t know what matches were made until you get your bill at the end of the month.
  • AWS decrements the contract amount for every hour when not used, meaning your return on investment diminishes. 
  • For every hour in your RI term, you pay the fee for hourly usage regardless of whether there has been any usage during that hour. 

Given all of the tradeoffs mentioned above, Reserved Instances make the most sense in a production environment, where instances need to always be “on.” 

How ParkMyCloud Can Help Manage Your Reserved Instances

ParkMyCloud is an easy to use platform that allows users to automatically identify and eliminate wasted cloud spend. You can use the ParkMyCloud platform to fully optimize your non-production instances without committing to an AWS EC2 RI term that will go underutilized. The platform does this by scheduling, rightsizing, and identifying idle instances. Recently, we added the ability to view all your existing Reserved Instances in the platform so you can better track what commitments you have already made, with more optimization functionality coming soon.

With ParkMyCloud, you can create parking schedules that automatically turn EC2 instances on and off according to your specifications. ParkMyCloud provides customized parking recommendations based on criteria provided by the user, which makes identifying “parkable” instances easier – and you can automatically accept these recommendations if you like. Turning this into an automated process cuts down on time and costs, thus further optimizing your cloud environments. Another perk of ParkMyCloud is that the platform tracks costs, projected 30-day savings, and actual savings for the current month – giving you better visibility. 

ParkMyCloud easily achieves EC2 savings of 50-73% with no annual commitment, upfront payment, or risk of instance termination or price cuts. In fact, we had a customer cancel a $10,000 order for AWS Reserved Instances in favor of EC2 instances that they could turn on and off after they found out just how easy and powerful this cost savings tool can be. Here are some of the advantages that come with using ParkMyCloud:

  • Better savings
  • No commitment or upfront payment
  • Price cut protection

Try out ParkMyCloud for yourself and get started parking your non-production systems and RightSizing your resources to ensure that your environments are running in the most efficient way possible.

If you use AWS RIs, you need to use the new queuing option

If you use AWS RIs, you need to use the new queuing option

The AWS reserved instance (AWS RI) offerings got a recent upgrade with the release of a “queue” function. This means that you can now purchase reserved instances that, rather than going into effect immediately, are scheduled for future purchase. (Yes – despite the fact that RI’s have been available for a decade, this is a new feature!)

Back up – what was released? 

If you haven’t used AWS RIs before, it’s worth a brief primer. When you purchase a reservation, you’re not buying a specific instance or even capacity: it’s a billing function. In exchange for a commitment over 1 or 3 years, you get an attractive discount. These discounts are applied on the back end of the billing process, and are allocated against specific instances on an hour-by-hour basis over the course of the month. 

There are a few variations within the AWS RI purchasing options, such as the term; how much you pay upfront vs. monthly; the option for them to be scheduled; whether the scope of the discount covers instances in a single region or in a particular availability zone; etc.

More on those options and whether you should actually be using Reserved Instances, in this post. (TL;DR: RIs are the right choice when you have 24×7 long-term production workloads; otherwise they’re usually not.) 

So, the new feature is the option to purchase these reservation discounts to begin on a future date rather than immediately. This is designed to make it easier for users to have uninterrupted reserved instance coverage. Previously, at the end of a 1- or 3-year term, many users would be unaware that their reservation expired and would have a spike in cost…which they may or may not notice. 

How does queuing work?

Now, when planned correctly, you can avoid the lapse of Reserved Instance coverage for your workloads by scheduling a new reservation purchase to go into effect as soon as the previous one expires. The furthest in advance you can schedule a purchase is three years, which is also the longest RI term available. 

Before queueing was available, customers had the option to either just go ahead and purchase a new reservation a few days/hours/weeks before the previous RI was due to expire, or set a reminder to go in and buy a new reservation after the previous one had lapsed. Either way, there was an extra cost – either a time window with too many RIs, or one with too few. So it is easy to see that RI queueing can save you money. Queueing can also save you some hassle, as you no longer have to set reminders and build your daily/weekly schedule around going in to buy a new RI. (Reminiscent of some late-night eBay sessions, waiting for the end of an auction to roll around.)

There are a few limitations. AWS RI purchases can be queued for regional Reserved Instances, but not zonal Reserved Instances. Regional RIs are the broader option as they cover any availability zone in a region, while zonal RIs are for a specific availability zone and actually reserve capacity as well. 

Cancellation is an option: since payment is processed only at the scheduled purchase time in the queue, you can cancel a purchase at any time before it is processed. 

We find it interesting that these are designed as new purchases rather than a “renewable” RIs – likely due to an idea that users may queue an evolving RI type or purchase profile, instead of the same instance type/duration/payment terms over time.

Beware the AWS RI Black Hole

Of course, the downside to queuing a purchase in advance is that you now have a new commitment to track – and one that may not meet your needs by the time the purchase goes into effect. 

It’s already difficult to shine light on your existing reservations, especially with options in place such as instance size flexibility and the broad applicability of regional RIs.

That’s why ParkMyCloud has released our first support for Reserved Instances this week. You told us that RIs are the next biggest thing that need optimization help on your cloud bills, and we listened. Now, you can see all your AWS RIs – past, present, and queued future purchases – in one place in ParkMyCloud. Next, we’ll be working on more recommendations and optimization – stay tuned!

How to Get the Cheapest Cloud Computing

How to Get the Cheapest Cloud Computing

Are you looking for the cheapest cloud computing available? Depending on your current situation, there are a few ways you might find the least expensive cloud offering that fits your needs.

If you don’t currently use the public cloud, or if you’re willing to have infrastructure in multiple clouds, you’re probably looking for the cheapest cloud provider. If you have existing infrastructure, there are a few approaches you can take to minimize costs and ensure they don’t spiral out of control.

Find the Cloud Provider that Offers the Cheapest Cloud Computing for Your Needs

There are a variety of small cloud providers that attempt to compete by dropping their prices. If you work for a small business and prefer a no-frills experience, perhaps one of these is right for you.

However, there’s a reason that the “big three” cloud providers – Amazon Web Services (AWS), Microsoft Azure, and Google Cloud dominate the market. They offer a wide range of product lines, and are continually innovating. They have a low frequency of outages, and their scale requires a straightforward onboarding process and plenty of documentation. 

Whatever provider you decide on, ensure that you’ll have access to all the services you need – is there a computing product, storage, databases? If you want to use containers or have the option for serverless, how do those products fit in? How good is the customer support? Does your company directly compete with the provider – for example, with Amazon’s retail arm? (You may not care, but some companies definitely do.) 

While there is no one “cheapest” cloud provider among the major options, you should still compare to ensure you’re getting the best cloud prices for the services you’ll use most. For more information about the three major providers’ pricing, please see the following cloud computing cost comparisons:

A note on the idea of vendor lock-in: if you are already purchasing cloud services from a cloud service provider, you may be worried that you’re “locked in” to that provider. What we see in practice is a little different: with on-demand flexibility and more opportunity than ever to practice multi-cloud, companies shouldn’t really worry about vendor lock-in when it comes to public cloud.

How to Get the Cheapest Cloud Computing from Your Current Provider

Of course, whether or not you’re concerned about vendor lock-in, you should ensure that you’re getting the most efficient cloud computing cost available to you. That means optimizing your options for the products you use most. 

Here’s a brief rundown of things you should do to ensure you’re getting the cheapest cloud computing possible from your current provider.

Use Reserved Instances for Production Environments

All of the major cloud providers offer a pricing option for Reserved Instances – that is, if you commit to use capacity over time, you can pay a discounted price.  Reserved instances can save money – as long as you use them the right way. It’s important to focus on workloads with 24×7 demand – i.e., production workloads – for Reserved Instances. You will get the best price for the longest commitment. Of course, each cloud provider structures this option differently. Here are our guides to each:

Only Pay for What You Actually Need

There are a few common ways that users inadvertently waste money and throw away the option for the cheapest public cloud bill, such as using larger instances than they need, and running development/testing instances 24/7 rather than only when they’re needed. To pay for what you need, ensure that all of your instances are “rightsized” to the size that best matches the workload. You should also use on/off schedules so your non-production resources used for development, testing, and staging are turned off nights and weekends. 

ParkMyCloud makes it easy to automated both of those things and reduce wasted cloud spend – try it out.

Take Advantage of Other Discounted Pricing Options

There are a number of other discounted pricing and purchasing options offered by the major cloud providers to help you get the cheapest cloud services. 

  • AWS Spot Instances – the best way to get the cheapest EC2 instance. This option offers heavy discounts for excess infrastructure, which can be reclaimed for other workloads at any time.
  • Azure Low Priority VMs – similar to AWS’s spot instances, although there is a fixed discount for Azure’s offering, and a few other operational differences.
  • Google Cloud Preemptible VMs – Google Cloud’s preemptible VMs are another similar option.
  • Google Cloud Sustained Use Discounts – this is a built-in pricing mechanism for Google users that discounts pricing the more you run each server.
  • Azure Dev/Test Pricing – a discounting option specifically for workloads used for development and testing. 

Ask

It never hurts to contact your provider and ask if there’s anything you could be doing to get a cheaper price. If you use Microsoft Azure, you may want to sign up for an Enterprise License Agreement, or if you’re on AWS, ask your rep about the Enterprise Discount Program. Or maybe you qualify for AWS startup credits

Get Credit for Your Efforts

While finding the cheapest cloud computing is, of course, beneficial to your organization’s common good, there’s no need to let your work in spending reduction go unnoticed. Make sure that you track your organization’s spending and show your team where you are reducing spend.

ParkMyCloud users have a straightforward way to do this. You can not only create and customize reports of your cloud spending and savings, but you can also schedule these reports to be emailed out. Users are already putting this to work by having savings reports automatically emailed to their bosses and department heads, to ensure that leadership is aware of the cost savings gained… and so users can get credit for their efforts.

AWS vs Google Cloud Pricing – A Comprehensive Look

AWS vs Google Cloud Pricing – A Comprehensive Look

Since ParkMyCloud provides cost control for Amazon Web Services (AWS) along with Google Cloud Platform (GCP) resources, we thought it might be useful to compare AWS vs Google Cloud pricing. Additionally, we will take a look at the terminology and billing differences. There are other “services” involved, such as networking, storage and load balancing, when looking at your overall bill. I am going to be focused mainly on compute charges in this article.  

Note: a version of this post was originally published in 2017. It has been completely rewritten and updated to include the latest AWS pricing and GCP pricing as of October 2019.

AWS and GCP Terminology Differences

As mentioned before, in AWS, the compute service is called “Elastic Compute Cloud” (EC2). The virtual servers are called “Instances”.

In GCP, the service is referred to as “Google Compute Engine” (GCE). The servers are called also called “instances”. 

A notable difference in terminology are GCP’s there are “preemptible” and non-preemptible instances.  Non-preemptible instances are the same as AWS “on demand” instances.  

Preemptible instances are similar to AWS “spot” instances, in that they are a lot less expensive, but can be preempted with little or no notice. GCP preemptible instances can be stopped without being terminated. In November 2017, AWS introduced a similar feature with spot instance hibernation. Flocks of these instances spun up from a snapshot according scaling rules are called “auto scaling groups” in AWS.

The similar concept can be created within GCP using “instance groups”. However, instance groups are really more of a “stack”, which are created using an “instance group template”. As such, they are more closely related to AWS CloudFormation stacks.

AWS vs. GCP Compute Sizing

Both AWS and GCP have a dizzying array of instance sizes to choose from, and doing an apples-to-apples comparison between them can be quite challenging. These predefined instance sizes are based upon number of virtual cores, amount of virtual memory and amount of virtual disk.

They have different categories.

AWS offers:

  • Free tier – inexpensive, burst performance (t3 family)
  • General purpose (m4/m5 family)
  • Compute optimized (c5 family)
  • GPU instances (p3 family)
  • FPGA instances (f1 family)
  • Memory optimized (x1, r5 family)
  • Storage optimized (i3, d2, h1 family)

GCP offers the following predefined types:

  • Free tier – inexpensive, burst performance (f1/g1 family)
  • Standard, shared core (n1-standard family)
  • High memory (n1-highmem family)
  • High CPU (n1-highCPU family)

However, GCP also allows you to make your own custom machine types, if none of the predefined ones fit your workload. You pay for uplifts in CPU/Hr and memory GiB/Hr. You can also add GPUs and premium processors as uplifts.

With respect to pricing, this is how the two seem to compare, by looking at some of the most common “work horses” and focusing on CPU, memory and cost.  

The bottom line:

In general, for most workloads AWS is less expensive on a CPU/Hr basis. For compute intensive workloads, GCP instances are generally less expensive

Also, as you can see from the table, both providers charge uplifts for different operating systems, and those uplifts can be substantial. You really need to pay attention to the fine print. For example, GCP charges a 4 core minimum for all their SQL uplifts (yikes!). And, in the case of Red Hat Enterprise Licensing (RHEL) in GCP, they charge you a 1 hour minimum for the uplifts and in 1 hour increments after that. (We’ll talk more about how the providers charge you in the next section.)

AWS vs. Google Cloud Platform Pricing – Examining the Differences

Cost per hour is only one aspect of the cloud pricing equation, though. To better understand your monthly bill, you must also understand how the cloud providers actually charge you. AWS prices their compute time by the hour, but charges by the second, with a 1 minute minimum.

Google Compute Engine pricing is also listed by the hour for each instance, but they charge you by the minute, rounded up to the nearest minute, with a 10 minute minimum charge. So, if you run for 1 minute, you get charged for 10 minutes. However, if you run for 61 minutes, you get charged for 61 minutes. 

AWS Reserved Instances vs GCP Committed Use

Both providers offer deeper discounts off their normal pricing, for “predictable” workloads that need to run for sustained periods of time, if you are willing to commit to capacity consumption upfront. AWS offers Reserved Instances. Google offers Committed Use Discounts.  Both involve agreeing to pay for the life of the reservation or commitment, though some have you pay up-front versus paying per month. This model of payment can get you some significant discounts over on-demand workloads, but can limit your flexibility as a trade-off. Check out our other posts on AWS Reserved Instances and Google Committed Use Discounts.

GCP Sustained Use Discounts

In addition to the Committed Use Discounts, GCP also has a unique offering with no direct parallel in AWS: Sustained Use Discounts. These provide you with an automatic discount if you run a workload for more that 25% of the month, with bigger discounts for more usage. These discounts can save up to 30% based on your use and instance size. The Google Cloud Pricing Calculator can help figure out how much this will affect your GCP costs.

Conclusion

If you are new to public cloud, once you get past all the confusing jargon, the creative approaches to pricing and the different ways providers charge for usage, the actual cloud services themselves are much easier to use than legacy on-premise services.

The public cloud services do provide much better flexibility and faster time-to-value. 

When comparing AWS vs. Google Cloud pricing, AWS EC2 on-demand pricing may on the surface appear to be more competitive than GCP pricing for comparable compute engines. However, when you examine specific workloads and factor in Google’s approach to charging for CPU/Hr time and their use of Sustained Use Discounts, GCP may actually be less expensive. 

In the meantime, ParkMyCloud will continue to help you turn off non-production cloud resources, when you don’t need them and help save you a lot of money on your monthly cloud bills, regardless of which public cloud provider you use.

Like this post? See also: How much do the differences between cloud providers actually matter? 

How to Create Your 2019 AWS re:Invent Schedule

How to Create Your 2019 AWS re:Invent Schedule

It’s time to plan your 2019 AWS re:Invent schedule! This will be our team’s fifth trek to the AWS conference in Las Vegas, 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 have sold out in the past, 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. Reserved seating goes live on October 15 at 10:00 AM PST. Mark your calendar and plan to select a few key sessions immediately – seating can be competitive and fill up quickly!

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. You may want to use one of these schedule planning tools to show in a calendar view, have better filters, and get email notifications of new sessions.

When planning, 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.
  • Sessions will be repeated at the 2019 event – no doubt in response to complaints about full sessions and long wait times in 2018, for this year, AWS will be repeating their most popular sessions several times over across venues. There will also be overflow rooms for popular sessions and more late-night session options than have been available in previous years. 
  • 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 schedule in the AWS re:Invent app, along with maps and more.

Scroll down to the bottom of this post for a list of sessions that looked particularly interesting to our team. 

Set Aside Time for the Expo Hall

Make sure you plan on time to visit the expo hall! Actually, there are 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 10:30 AM – 6 PM Tuesday, 8 AM – 6 PM Wednesday, and 10:30 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 and Turbonomic at the Venetian expo! We’ll be at booth #1029.

We’d love to see you there!  Sign up for a meeting with us now.

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. Outside of the 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 2019 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 AWS re:Invent party and 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. And new for 2019 is the Intersect Music Festival put on by AWS on Friday and Saturday, although note that tickets are separate from re:Invent. 

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

Frequently Asked Questions, Answered

Here are some answers to the most common questions about AWS re:Invent 2019:

How much does AWS re:Invent 2019 cost? 

A full pass to the conference costs $1799. There are a handful of discounts available (for example, if your company is also sponsoring the event), but if you don’t already have access to one of those, we’d recommend going ahead and buying a full pass. 

What are the AWS re:Invent 2019 dates? 

This year’s AWS Las Vegas extravaganza will run December 2-6. If you fly in on Sunday December 1, you can participate in Midnight Madness. And don’t forget that AWS’s new Intersect Music Festival is then 6th and 7th.

Will there be AWS re:Invent video recordings? 

Yes – AWS records many of the sessions and posts to their YouTube channel.

How does AWS re:Invent registration work when I arrive?

There will be registration areas available in multiple venues throughout the conference. There may also be one in the arrival terminal at the airport, but if the line is long, skip it – you’ll wait less at the Venetian or other venues to check-in.

AWS re:Invent Sessions That Caught Our Eyes

See more details and (once open) register through the official AWS re:Invent agenda

  • AIM302-R – Create a Q&A bot with Amazon Lex and Amazon Alexa – A recent poll showed that 44 percent of customers would rather talk to a chatbot than to a human for customer support. In this workshop, we show you how to deploy a question-and-answer bot using two open-source projects: QnABot and Lex-Web-UI. You get started quickly using Amazon Lex, Amazon Alexa, and Amazon Elasticsearch Service (Amazon ES) to provide a conversational chatbot interface. You enhance this solution using AWS Lambda and integrate it with Amazon Connect.
  • AIM303-R –  Stop guessing: Use AI to understand customer conversations – You don’t need to be a data scientist to build an AI application. In this workshop, we show you how to use AWS AI services to build a serverless application that can help you understand your customers. Analyze call-center recordings with the help of automatic speech recognition (ASR), translation, and natural language processing (NLP). Get hands-on by producing your own call recordings using Amazon Connect. In the last step, you set up a processing pipeline to automate transcription and NLP analysis, and run analytics and visualizations on the results.
  • ARC201 – Comparing serverless and containers – Microservices are a great way to segment your application into well-defined, self-contained units of functionality. Come join us in this chalk talk as we discuss two common architectures for deploying microservices: containers and serverless.
  • ARC204-R – Cost optimizing a workload – In this hands-on session, we guide you through the AWS tools, services, and design decisions for architecting cost-optimized applications. Whether you run cloud-native applications or legacy monolithic applications, we show you tricks and techniques to run your workload at the lowest cost possible. Once the workload is optimized, we set up an enterprise cost-optimization dashboard to measure and report on workload efficiency utilizing Amazon Athena and Amazon QuickSight.
  • ARC303-R – Failing successfully: The AWS approach to resilient design – AWS global infrastructure provides the tools customers need to design resilient and reliable services. In this session, we explore how to get the most out of these tools. We discuss achieving continued stability and availability in the face of impaired dependencies. We also cover AWS tools and best practices you can use to design applications and services that avoid overload.
  • ARC406-R1 – Building multi-region microservices – In this session, participate in a hands-on exercise where you create, verify, and test a serverless solution across multiple regions using AWS Lambda and Amazon DynamoDB global tables.
  • CON210-S – How to run like a startup with enterprise Kubernetes on AWS – Scholastic Corporation reinvented itself with the adoption of a startup mindset and a move to microservices on AWS running in Red Hat OpenShift Container Platform, an enterprise Kubernetes distribution. In this session, you hear about the journey that this large publishing enterprise went on during its transformation. From our discussion of breaking up monolithic applications into microservices, you learn about some of the pitfalls along the road to Kubernetes, containers, and microservices adoption. You also hear about the resulting demonstrable benefits—faster time to market, lower infrastructure costs, happier developers, and improved business performance.
  • DOP204-S – Transforming IT pros to DevOps gurus: How to secure your new tech stacks – Large enterprises are limited by legacy systems. With existing tools, traditional platforms, outdated requirements, and more, IT and engineering teams have difficulty building in a modern way. Hear how Pivvot, a US enterprise, used tools in the AWS Cloud to escape this traditional trap. The Pivvot team learned to scale by adopting a DevOps philosophy to support hundreds of organizations and thousands of customers inside a commercial software company. Learn how building a pipeline-driven cloud-native process with built-in security helps modernize an organization. Culture change is challenging, but with the right approach and a strong tech stack, you can build securely and ship quickly in the AWS Cloud. 
  • DOP206-S – Breaking the monolith with style and speed – Microservices are here to stay, but nearly all of the most successful architectures originate from the classic monolith. The promised land of microservices is filled with treasures like decoupled deploys, scalability, resilience, development velocity, and more. However, the journey there can involve prolonged seasons of pain, suffering, and even regret. This talk is the story of how Stitch Fix used all three pillars of observability to build confidence, accelerate its migration, and collaborate with other teams. Learn about the strategies that Stitch Fix used and how it incorporated logs, metrics, and traces into these strategies. 
  • IOT301-R – Race to generate IoT connected wind energy – In this workshop, learn how to connect a simple wind turbine to AWS IoT Core and work in teams to see which one can generate the most aggregate power in a five-minute race at the end of the workshop. A large fan will be the single source of wind, and energy levels from each turbine will be aggregated between the two teams with a continuously updating dashboard. Participants will learn how to set up an IoT device connection with their own account, enrich the data with a pipeline, and store the data for a dashboard.
  • MGT304 – Automate everything: Options and best practices – You can use an expanding set of services to automate many common management tasks in your AWS environment, including patching, configuration updates, software stack deployments, and more. In this session, we explore how you can use AWS management tools for automation, including the use of self-service runbooks. We discuss the many options available, including AWS CloudFormation, AWS Service Catalog, and AWS Systems Manager.
  • MGT310-R – High-velocity service delivery: Infrastructure as code – Customers today are looking to the cloud to help them evolve, adapt, and innovate faster than ever. In this chalk talk, learn how to use AWS native services to increase your organization’s ability to deliver at high velocity using services like AWS CloudFormation, AWS OpsWorks, and AWS Systems Manager. We talk about best practices to help you provision and manage infrastructure, deploy code, and automate your software-release processes.
  • SVS203-R1 – Build a serverless ride-sharing web application – In this workshop, you deploy a simple web application that lets users request unicorn rides from the Wild Rydes fleet. The application presents users with an HTML-based user interface for indicating the location where they would like to be picked up and interfaces on the backend with a RESTful web service to submit the request and dispatch a nearby unicorn. The application also provides facilities for users to register with the service and log in before requesting rides.
  • SVS309 – Development life cycle for serverless backends – With serverless applications, you can easily get started, experiment, and build prototypes. However, as serverless usage grows and more developers adopt serverless, it can be hard to maintain a good workflow from ideas to production. In this talk, we share inspirations for how to build a good development workflow for serverless applications that allow for fast experimentation while sharing common standards across teams and organizations.

See You There!

Do you have any other tips for planning the perfect AWS re:Invent schedule? Sessions you’re looking forward to? Any other questions, tips, swag suggestions  Let us know in the comments. Cheers, and see you there!

More on re:Invent: 2018 recap.

Are AWS Reserved Instances Better Than On-Demand?

Are AWS Reserved Instances Better Than On-Demand?

AWS Reserved Instances vs. Scheduling On-Demand Instances

We are frequently asked about the impact of instance scheduling on AWS Reserved Instances for EC2 and RDS.  Scheduling On Demand instances as well as Reserved Instances (RIs) are both useful techniques for cost optimization, but they are polar opposites in terms of goals.  RIs are all about getting a better price for RDS or EC2 instances that are running all the time. Scheduling is all about reducing costs by turning off instances when they are not in use.  

How should a customer choose between buying an AWS Reserved Instance and applying scheduling to the instance?  This is an important question, as usually the savings from scheduling can exceed the savings available from a Reserved Instance.  Before we dive into that though, let’s get familiar with some critical RI nuances that can help you make the decision…and make the most of your RIs.

Note: versions of this article were originally published in 2015 and 2017. It has been completely re-analyzed, rewritten, and updated! 

Where are my Reserved Instances?

First of all, it’s worth clarifying that there is no functional difference between Amazon Reserved Instances and On Demand. It’s all in the billing. <rant> I wish I had a dollar for each time someone asked me (while looking at the AWS Console) “Which ones of these are the Reserved Instances?” </rant>. You cannot be sure which instances are using a reservation until you get your bill.  You can make a good guess, based on what account you are looking at and what reservations you have purchased, but if you are using instance size flexibility with region-based RIs, it would be a pure guess.  An instance reservation is not like a hotel reservation, where you end up with a specific room for the duration of your stay. That would be a Dedicated Host Reservation – a whole other beast with its own set of limitations.

3600 Seconds per Hour

Yep – there are 3600 seconds in an hour.  I did the math. You may ask: why does that matter?  It matters because of two things: per-second billing for EC2, and the fact that AWS RIs are billed in one hour chunks.  More precisely, RIs are billed in one “clock-hour” chunks, where a clock-hour starts on the hour and up to the final second of the hour – like 04:00:00 to 04:59:59.

If you are running a number of instances that use per-second billing, and they go up or down during a (clock) hour, then multiple instances may be able to leverage the Reserved Instance pricing.

As paraphrased shamelessly from here, if you purchase one m5.large Reserved Instance and run four matching m5.large instances for 15 minutes each (900 seconds each) in the same hour, the total running time is one hour, which consumes the entire Reserved Instance allocation.  This usage pattern is illustrated below.

That said, if multiple matching instances are running at the same time, the Reserved Instance billing benefit is applied to all of the instances, up to a maximum of 3600 seconds in a clock-hour.  On-demand rates are used for any usage after that. This is illustrated below.

By the way, remember that per-second billing only applies to instances running an open-license OS like Amazon Linux or Ubuntu.  

If your instance is running any flavor of Windows, Red Hat Linux, or any pay-by-the-hour image from the AWS Marketplace, that instance is billed by the hour, and any matching reservation will be consumed by the hour, even if the instance is not.  Any overlapping instances will each need their own RI to get RI pricing.

Elastic Reserved Instances

Wait…what?  Isn’t that kind-of an oxymoron?  Elastic means it should be able to change with my usage…and aren’t reservations are a commitment to usage?  Well, maybe…but some RIs are definitely more elastic (or at least more flexible) than others.  Regional Reserved Instances can leverage “instance size flexibility.”  This is the ability of a reservation to apply up or down to other instance types in the same family.  Regional RIs are applied in priority order from the smallest instance in the region to the largest instance in the region.  This makes these AWS reservations somewhat elastic in that if you buy reservations for smaller instance types than you normally use, then those reservations are more likely to be consumed, even if you rightsize an instance or replace one server with another of a different size.

The math of how an RI of one instance type can be applied to another instance type is governed by a “normalization factor”, described here.  Putting the table in that link another way:

Some examples of how we can use this table:

  • To fully cover one t3.medium with RIs, you would buy eight t3.nano RIs.  If you stop using the t3.medium instance, the same eight t3.nano RIs could also be used to cover:
      • Two t3.small instances
      • One t3.small and two t3.micro
      • Half of a t3.large
  • To fully cover an m5.12xlarge would require 24 m5.large RIs.  Those 24 m5.large RIs could also be used for:
      • One m5.8xlarge and one m5.4xlarge
      • One m5.8xlarge and two m5.2xlarge
      • One m5.8xlarge, one m5.2xlarge, one m5.xlarge, and two m5.large
      • Three quarters of an m5.16xlarge
      • Etc.

The lesson here is that it is easiest to manage reserved instances if you buy the smallest instance size available within an instance family.  In fact, as shown below this is the exact type of recommendation you are likely to receive from the AWS Cost Explorer.

So why do we mention AWS flexible reserved instances with relation to schedules?  Recall that the allocation of RIs to instances is done by AWS each second within a clock-hour.  Each reservation is consumed by instances in its family until all 3600 seconds have been allocated.  You do not necessarily have to keep an instance up for the whole hour to use the reservation. You can still consume the whole RI, even if you are starting and stopping instances by schedule or within an auto-scaling group over the course of an hour.

Something so cool cannot be without limitations and gotchas. Here are a few we’ve noticed:

  • Instance size flexibility is ONLY available for certain instance platforms.
    • For AWS EC2 reserved instances, only open-license linux instances support flexible RIs.  It is NOT APPLICABLE to any flavor of Windows or other licensed software and OS.
    • For AWS RDS reserved instances, instance size flexibility is available for MySQL, MariaDB, PostgreSQL, and Amazon Aurora database engines as well as the “Bring your own license” (BYOL) edition of the Oracle. [That said: it is not clear as of this writing if the recent RDS per-second billing change is also applied to RDS instance size flexibility. The billing pages still state that RDS RIs are allocated to instances on a per-hour basis.]
  • Flexibility is only available within the same instance family
  • Flexibility is only available for Regional RIs 

How does AWS Reserved Instance Pricing Work?

As usual, there are a number of different decisions that need to be made before this question can be answered.  AWS RIs are available with two different levels of flexibility and several different terms of purchase. 

In terms of flexibility, RIs can either be purchased as “standard” or “convertible.” 

  • AWS Convertible Reserved Instances – allow changing the assigned availability zone, instance size/families, operating system, tenancy, and networking type. There is no fee for changing the reservation attributes, but you can only convert the RI into a new set of attributes with equal or greater cost than the original.  If the cost is greater, you will have to pay the difference.
  • Standard Reserved Instances – once purchased, cannot be changed. They can be sold on the AWS Reserved Instance Marketplace.

Both AWS Convertible RIs and Standard RIs offer:

  • Regional vs. Availability Zone assignment scope.  Regional scope offers a lot more flexibility for where your instances can reside while still leveraging RI pricing. Availability Zone scope has the bonus of a guaranteed capacity reservation (though, like RI pricing,  capacity reservation cannot be assigned to a specific instance).
  • For open-license Linux, instance size flexibility, as described earlier.

There are a few options for terms of purchase that affect AWS RI pricing. RIs can be purchased for 1 or 3-year terms, and with no upfront, partial upfront, or all upfront payment available for each. 

To get a better idea of the difference in the amount you’ll end up paying with each purchasing option, let’s take a look at some pricing scenarios for the general purpose m5.large instance in us-east-1 (US Virginia).  When you look at these on the AWS RI price list, they are usually grouped by year terms and standard vs. convertible.  Since you can already see it that way on AWS, and because time is the greatest unknown, I am going to give a bit of a different view, keeping the years together on the same comparison chart.

One-Year Term RIs

To  benefit from the discount provided by a  reservation while keeping contract terms to a minimum, look at the 1-year RIs:

You can see from this that within the Convertible vs. Standard tiers, there is not a lot of difference between the upfront cost payment options.  Your upfront cash decision here can depend on your accounting process, perhaps accounting for the difference between CapEx and OpEx (Capital Expenditures and Operating Expenditures), or based on your current and prospective cash flow.  The pricing between the Convertible vs. Standard options are so similar as to make you seriously consider if the benefit of flexibility in the AWS Reserved Instances convertible option outweighs the minor cost savings.

Three-Year Term RIs

If you are confident of your three-year usage plans, look at the 3-year RIs, shown here as the cost per year:

There is a bit more visible progression between the options here, and the cost savings difference between the 1-year graph and the 3-year graph are clearly seen.  Still, the 1-year vs. 3-year decision may again come down to accounting practices.

Note that these graphs are just for one instance type in one location in about the middle of the overall performance pack.  They do not express a true profile of all instance types/families in all locations, and you should do your own comparison before buying any RIs.  That said….

AWS Reserved Instances vs. On Demand

Scheduling Break-even

FINALLY getting into the core question.  Is it better to shut an instance down or buy a reserved instance?  Let’s do the math and compare AWS On Demand vs. Reserved, with on/off scheduling applied to the On Demand option.  Given all the different pricing options it can be a bit difficult to decide how to compare these. Let’s go with the no-upfront RI options and see where the RIs break even with scheduling.

AWS On Demand vs. Reserved Instance Purchase Option Comparison

Since the hours might be judge at this scale, here are the break-even hours in a table (hours rounded-up):

So what do these hours mean?  

By way of comparison, here are a few common schedules and their hours in ParkMyCloud (with weeks converted to months on the basis of 52 weeks/12 months = 4.33 weeks/month):

  • Running 8 AM – 5 PM, Weekdays = 195 hours/month (nominally a 73% savings)
  • Running 7 AM – 7 PM, Weekdays = 260 hours/month (64% savings)
  • Running 5 AM – 9 PM, Weekdays = 347 hours/month (53% savings)

Of the above, 7 AM – 7 PM Weekdays is the second most popular schedule in our entire system, and at 260 hours, easily is more cost-effective than the least expensive RI.  

In that final schedule above, you need to run 16 hours per day, Monday-Friday before a 3-year RI starts to look like a better deal.  If you have other matching instances on another schedule in that same region/AZ, you could then buy the RI anyway, and save even more money.

Scheduled Reserved Instances

“But wait!” you say…  “There are these things called Scheduled Reserved Instances – would they not offer me the best of both worlds?”  Maybe, but note that to support Scheduled RIs, AWS has essentially set aside hardware for use as Scheduled RIs – this is a finite set of dedicated resources.  On paper, a Scheduled RI can definitely save you a bit more money, but let’s look at the limitations.  

  • Instances intended to consume a Scheduled Reservation must be launched during their scheduled time periods using a launch configuration that matches the reservation. Let’s break that down further:
      • They are launched with “a launch configuration” and terminated by EC2 three minutes before the end of the schedule window.  You cannot stop/start/suspend them, and so they cannot maintain state internally unless you do some EBS volume tweaks after launch.
      • You cannot launch a scheduled RI outside of its scheduled window.  If you try, that instance will not use the Reservation, as you would not expect it to magically jump over onto the dedicated hardware.
  • Only three regions and only a few older generation instances families are supported.
  • Limited quantities are available (as of this writing, a search for an m4.large in us-east-1 with a Monday-Friday 7 AM – 7 PM scheduled listed only two reservations being available).
  • There is a minimum reservation size of 1,200 hours/year, 100 hours/month, 24 hours/week, or 4 hours/day.  (So you are not going to be able to use a Scheduled RI to run your database backup server for just a couple hours on Sunday mornings [I just tried…dang it.])
  • Scheduled RI purchases cannot be cancelled, modified or sold on the RI Marketplace. No buyer’s remorse allowed here…
  • And finally…  AWS describes the cost savings of Scheduled RIs over on-demand as being in the 5-10% range.  Again – you have to be really sure this workload is going to be needed on this schedule, and the workload is fully utilized.  If you find this server is ever idle or under-utilized, you may have lost an opportunity to save 50% or more by simply scheduling it with ParkMyCloud and then rightsizing it.

When launched in 2016, Scheduled RIs were only available in “US East (N. Virginia), US West (Oregon), and Europe (Ireland) regions, with support for the C3, C4, M4, and R3 instance types.”  Given that this has not changed, I am guessing the feature has not taken off as AWS had hoped.  That said, if you have something that needs to run for 4 hours per day, daily, and can use an older instance family in a supported region…go for it!  This may also be a good place to leverage AWS Spot instance types.

Should You Buy Reserved Instances?

Deciding between different RI options starts with knowledge of how stable your usage is going to be in the coming years.  Most organizations have a good understanding of at least a baseline level of usage, and some actually construct portfolios of reserved instance purchases, much like how you might balance a stock portfolio.  For example, 3-year Standard Reserved Instances are for those applications that are stable and unlikely to change. Balance those with some 3-year Convertible Reserved Instances to help save money in the longer term but allow for some flexibility in use.  Use 1-year RIs to account for shorter-term usage volatility, with again maybe a balance between Standard and Convertible where needed for those loads that might shift over the short term.  

Just like with stocks, such portfolios require active management, awareness of what is being used and what is coming in both the short and long term.  Companies with these types of RI management typically have dedicated cloud cost management staff, though RI management itself does not need to be a full-time job.  One of our larger customers tells us they do a quarterly review of their RI portfolio, starting with using ParkMyCloud to schedule any instances they can, and then rebalancing their RIs and investing in more as needed.  This is a best practice for any size company.

For production workloads that run 24×7 long-term, you REALLY should be buying RIs. For production workloads with an unknown future, or for non-production workloads (dev, test, QA, training, etc.), the answer is “probably not”.  Be careful though, as often RIs are seen as a quick fix to save 30-50% on the cloud bill, but then other ways are found to save even more, and you end up with underutilized RIs. Before you buy a Standard RI, make sure you have evaluated your resources for underutilization and overprovisioning.  Also consider the following cost-saving options:

  • Choose smaller instance sizes – each size down can save 50%. Use ParkMyCloud Rightsizing to first make sure your resources are appropriately sized for their load before committing to an RI purchase. 
  • For open-license Linux instances, buy RIs for smaller instance types in the same instance family in order to leverage instance size flexibility (allows the RIs to more easily be allocated against other resources, even if they are running for short periods of time)
  • Use Spot Instances and Autoscaling when appropriate for short-term/volatile workloads.
  • Schedule on/off times for on-demand instances.  Use ParkMyCloud SmartParking to automatically create schedules for when the resources are not being used, while still giving your staff the flexibility to easily restart them if needed outside the normal hours. Even a generous 7 AM – 7 PM workday schedule will immediately save 65%!

The worst thing one can do is…nothing.  Set aside some time each quarter to review EC2 and RDS instance utilization.  Rightsize and schedule what you can – try a free trial of ParkMyCloud to see how we can help you with that.  After that, anything left running 24×7 is a candidate for an RI.  If you are risk-averse or time-crunched, stick with 1-year convertible RIs to save at least 36% on at least some of your resources.  Then take all that money you saved and put it into other things that will bring greater value to your business.