Among the many announcements made at Google Cloud Next last week was a new option for Google Cloud discounts: resource-based pricing.
This new option, which Google will roll out in the fall, expands their idea of “pay per use pricing”. For resource types n1-standard, n1-highmem, and n1-highcpu, Google will no longer charge based on machine types. Instead, they will now aggregate across resources and charge based on the quantity of vCPU and GB of memory you use.
This new addition to the family of Google Cloud discounts will have its biggest effect on Sustained Use discounts.
Sustained Use Discounts are Even Better
We recently asked the question, do sustained use discounts really save you money? The answer was yes, although depending on the situation, perhaps not the maximum amount of money possible.
With the resource-based pricing change, Sustained Use Discounts will be based in regions instead of just zones, so you can rack up “percentage of the month” usage and therefore discounts faster and easier. For example, if you have a single busy week in the month, during which you run several VMs with varying amounts of vCPU, the vCPU will all be counted together before the sustained use amount is calculated, giving you potential for a better-optimized discount.
For some customers, the biggest impact of this change will be in Autoscaling Managed Instance Groups. In the old system, if a group of instances scaled up and down over time (especially daily), the new instances that were created and then shut down a short time later never had an opportunity to accumulate enough hours to reach a sustained use discount tier. In the new system, the aggregated use of these systems counts toward the sustained use, giving a much higher likelihood of getting the Sustained Use Discount.
Billing Simplicity (…Hopefully)
While this should make your bill lower, it may not make your bill “easier to understand” as Google claims. Since discounts will apply at a regional level, and there’s now yet another step going on behind the scenes to calculate your bill, some users may find it harder to predict their monthly bills. You will no longer be able to see the machine types that you are using in your invoice, although you can obtain them via Billing BigQuery. Keep this in mind, and be sure to dig into your first few invoices after the change is made to see how it’s affecting your particular environment.
It’s All About Automation
One thing we appreciate about the change is that Google Cloud customers do not need to take any action to receive these discounts – it’s all done automatically. The same has always been true for Sustained Use Discounts, something that makes Google Cloud stand out from its immediate competition – neither AWS nor Azure offers something directly equivalent.
Google Cloud Discounts are Good for the Customer
Here’s what people are saying about the update.
It shows flexibility as a priority:
And AWS would be wise to do the same:
We’re glad to see another addition to the Google Cloud discounts that go directly toward improving the customer experience. It’s clear to see that GCP is focusing on a customer-first experience – which is good news for all of us.
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.
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. To optimize your existing RIs, be sure to check out our Reserved Instance management solution.
Did we miss any of your questions in this AWS Reserved Instances Marketplace FAQ? Let us know!
In this blog we will look at the Google Cloud Committed Use discount program for customers that are willing to “commit” to a certain level of usage of the GCP Compute Engine.
The Committed Use purchasing option is particularly useful if you are certain that you will be continually operating instances in a region and project over the course of a year or more. If your instance usage does not add up to a full month, you may instead want to look at the Google Cloud Sustained Use discounts, which we discussed in a previous blog.
The Google Cloud Committed Use discount program has many similarities to the AWS and Azure Reserved Instances (RI) programs, and a couple unique aspects as well. A comparison of the various cloud providers’ reservation programs is probably worth a blog in itself, so for now, let’s focus on the Google Cloud Committed Use discounts, and the best times and places to use them.
Critical Facts about Google Cloud Committed Use
- The Committed Use discount is best for a stable and predictable workload (you are committed to pay – regardless of whether you use the resources or not!)
- Commitment periods are for either 1 or 3 years.
- Commitments are for a specific region and a specific project. Zone assignment within a region is not a factor.
- Discounts apply to the total number of vCPUs and amount of memory– not to a specific machine or machine type.
- No pre-payment – the commitment cost is billed monthly.
- GCP Committed Use discounts are available for all of the GCP instance families except the shared-core machine types, such as f1-micro and g1-small.
- Committed Use discounts do not apply to the premium charges for sole-tenants, nor can they be used for Preemptible instances.
- The commitments for General Purpose instances are distinct from those for Memory Optimized instances. If you have some of both types, you must buy two different types of Commitment. These types are:
- Standard – n1-standard
- High Memory – n1-highmem
- High CPU – n1-highcpu
- General purpose sole-tenant
How much does it cost?
Each Committed Use purchase must include a specific number of vCPUs and the amount of memory per vCPU. This combination of needing to commit to both a number of vCPUs and amount of Memory can make the purchase of a commitment a bit more complicated if you use a variety of machine types in your environment. The following table illustrates some GCP machine types and the amount of memory automatically provided per vCPU:
||Memory per vCPU
||0.9 – 6.5 GB
While the vCPU aspect is fairly straightforward, the memory commitment to purchase requires a bit of thought. Since it is not based on a specific machine type (like AWS and Azure), you must decide just how much memory to sign-up for. If your set of machine types is homogeneous, this is easy – just match the vCPU/memory ratio to what you run. The good news here is that you are just buying a big blob of memory – you are not restricted to rigidly holding to some vCPU/memory ratio. The billing system will “use up” a chunk of memory for one instance and then move on to the next.
Looking at a specific example, the n1-standard-8 in the Oregon region that we discussed in the Sustained Usage Blog, we can see that the Committed Use discount does amount to some savings, but one must maintain a usage level throughout the month to fully consume the commitment.
Recall from the earlier blog that the base price of this instance type in the GCP Price list already assumes a Sustained Usage discount over a full month, and that the actual “list price” of the instance type is $277.40, and Sustained Usage provides up to a maximum of a 30% discount. With that as a basis, we can see that the net savings for the Committed Use discount over 1 year is 37%, and over 3 years, rises to 55%. This is close to the advertised discount of 57% in the GCP pricing information, which varies by region.
The break-even points in this graph are about 365 hours/month for a 3 year commitment, and 603 hours/month for a 1 year commitment. In other words, if you are sure you will be using a resource less than 365 hours/month over the course of a year, then you probably want to avoid purchasing a 3 year Commitment.
Allocation of Commitments
Because Commitments are assigned on a vCPU/RAM basis, you cannot simply point at a specific instance, and say THAT instance is assigned to my Committed Use discount. Allocation of commitments is handled when your bill is generated, and your discount is applied in a very specific order:
- To custom machine types
- Sole-tenant node groups
- Predefined machine types
This sequence is generally good for the customer, in that it applies the Commitment to the more expensive instances first. For example, an n1-standard-4 instance in Northern Virginia normally costs $109.35. If an equivalent server was constructed as a Custom instance, it would cost $114.76.
For sole-tenant node groups, you are typically paying for an entire physical machine, and the Committed Use discount serves to offset the normal cost for that node. For a sole-tenant node group that is expected to be operating 7x24x365, it makes the most sense to buy Committed Use for the entire system, as you will be paying for the entire machine, regardless of how many instances are running on it.
Commitments are allocated over the course of each hour in a month, distributing the vCPUs and RAM to all of the instances that are operating in that hour. This means you cannot buy a Commitment for 1 vCPU and 3.75 GB of RAM, and run two n1-standard-1 instances for the first half of the month, and then nothing for the second half of the month, expecting it all to be covered by the Commitment. In this scenario, you would be charged for one month at the committed rate, and two weeks at the regular rate (subject to whatever Sustained Usage discount you might accumulate for the second instance).
Thank you for….not…sharing?
Unlike AWS, where Reserved Instances are automatically shared across multiple linked accounts within an organization, GCP Commitments cannot be shared across projects within a billing account. For some companies, this can be a major decision point as to whether or not they commit to Commitments. Within the ParkMyCloud platform, we see customers with as many as 60 linked AWS accounts, all of which share in a pool of Reserved Instances. GCP customers do not have this flexibility with Commitments, being locked-in to the Project in which they were purchased. A number of our customers use AWS Accounts as a mechanism to track resources for teams and projects; GCP has Projects and Quotas for this purpose, and they are not quite as flexible for committed resource sharing. For a larger organization, this lack of sharing means each project needs to be much more careful about how they purchase Commitments.
Google Cloud Committed Use discounts definitely offer great savings for organizations that expect to maintain a certain level of usage of GCP and that expect to keep those resources within a stable set of regions and projects. Since GCP Commitments are assigned at the vCPU/Memory level, they provide excellent flexibility over machine-type-based assignments. With the right GCP usage profile over a year or more, purchase of Google Cloud Committed Use discounts is a no-brainer, especially since there are no up-front costs!
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. Does all this sound complex to manage? That’s because it is. Take the DIY route by keeping an eye on your infrastructure, or put our automated solution to work and check out our Reserved Instance manager.
Sometimes we ask potential customers what their top ParkMyCloud alternative is. Usually, they don’t have one, but sometimes, they’re considering scripting their own on/off solution instead.
It makes sense: at a glance at the problem of scheduling cloud resources, it’s easy to say, “my team can write a scheduler.” However, there are more factors than you may have considered – including cost optimization over a variety of resources, maintenance time, visibility and reporting, opportunity cost, and more.
11 Things to Include in Your Scripts – Besides Scheduling
While you may be able to write scripts to turn resources on and off on a schedule, there are a number of associated functionalities that would be more difficult and time consuming:
- Multi-account/user – scripting typically doesn’t support multi-cloud/multi-user/multi-account access, and it is difficult to support existing team structures and ensure appropriate controls
- Schedule override – difficult to let users override schedules when they need to access them while scheduled
- Custom usage-based schedules – must determine a way to create custom schedules per resource based on usage analytics
- Logical Groups – hard to find a way to let users group resources and start/stop sequentially
- Scale group parking – must develop means to create a single view and the ability to manage and start/stop scale groups
- On-demand access – must develop a process to enable on-demand access to stopped instances in off hours
- Visibility – need to develop custom application to determine cost savings based upon application of automation or removal of schedules (to date we have not encountered anyone who has developed such an application)
- Reporting – not only do cost savings need to be tracked, they need to be reportable via ad hoc utilization, savings, and scheduling reports over arbitrary date ranges
- Policies – difficult to build custom policies regarding the scheduling of instances like “Never Park” or “Snooze Only”
- Standardization – difficult to ensure consistency and standardization of automation approach across entire organization unless highly centralized
- Easy-to-use UI for non-developers – no easy way to create a UI that allows you to devolve management of cloud resources to non-technical teams who may not be familiar with the cloud provider console
ParkMyCloud provides you the ability to do all of the above – with no scripting necessary. See a full comparison here.
The Cost of Scripting
If you’re interested in automating on/off times for your cloud resources, then you’re probably interested in optimizing costs. So don’t lose sight of the cost behind “building” – the man-hours and opportunity cost. After all, every time you have your team working on creating solutions for side projects, you distract them from your core business activities.
And it will take more time than you think. In addition to the functionality listed above, consider the following maintenance tasks:
- Must keep up-to-date on changes to public cloud APIs
- Must keep up-to-date on change/updates to public cloud services
- When your business’s desired policies, schedules, or behavior change, must update and test
Is Scripting a Viable ParkMyCloud Alternative?
Of course, it’s up to you to determine whether scripting is a worthwhile ParkMyCloud alternative for your business. We’d say, it’s not worth the cost and sacrifice of value. Besides, ParkMyCloud users save an average of $12 on their cloud bills per dollar spent on the product – that’s an ROI that will keep your finance team happy. And that’s just the paid versions. If it’s still hard for you to justify, then use ParkMyCloud’s free tier – with no cost, there’s no reason to waste your time scripting.
Ready to try the easy way? Get started.
ParkMyCloud just turned 3 years old, and from here, the future looks great. The market is growing, cloud is the norm, and cost control is always top of mind for companies big and small. In fact, over 600 enterprises in 25+ countries now use our platform to “park idle cloud resources (including instances, databases and scale groups) in AWS, Azure, GCP and now Alibaba.
As we look to the future, we’re taking a moment to consider current cloud trends and how cost control needs are changing. To provide context, let’s take a quick look at where the market was three years ago.
The Problem that Got Us Started
When we founded the company three years ago, we set out to build a self-service, SaaS platform which would allow DevOps users to automate cloud cost control and integrate it into their cloud operations. We saw a need for this platform as we were talking to enterprises using AWS about broader cloud management needs as a service play. They wanted a self-service, purpose-built easy button for instance scheduling that could be centrally managed and governed but left up to the end user to control – enter ParkMyCloud.
Our value proposition started simply and has stayed relatively constant: save 20% on your cloud bill in 15 minutes or less (it’s 65% per parked resource). The ease of use, verifiable ROI, and richness of our platform capabilities allow global companies like McDonald’s, Unilever, Sysco, Sage and many others to adopt ParkMyCloud on their own, with no services, and begin to automate their cloud cost control in minutes – not days or weeks.
I went back and looked at our pre-launch pitch decks. At that time, the cloud Infrastructure-as-a-Service (IaaS) market was $10B or so, and dominated by AWS, and others like Rackspace and HP were in the game with the other usual suspects. Today, Gartner estimates enterprises will spend $41B on IaaS in 2018, and it’s still dominated by AWS, but the number of players is really down to 4 or 6 depending on where you want to put IBM and Oracle.
But the cloud waste problem is still prominent and growing, most analysts and industry pundits estimate that 25% or more of your bill is wasted on unused, idle or over provisioned resources – that equates to $10B+ based on 2018 IaaS predictions being wasted – that’s a BIG nut. In fact, if you break that down that’s $1MM in wasted cloud spend every hour. And it’s important. Most enterprises rank cloud security/governance and cost management as their primary concerns with cloud adoption.
Cloud Trends Driving the Market
So how are things changing? We see three key trends that will drive our company and platform vision over the next 3 years:
- Multi-cloud – it’s been long discussed, but it’s now a reality: 20% of the enterprises using PMC manage 2 or more CSPs in the platform, and that number is growing. As always, cost control is an important factor in a multi-cloud strategy.
- PaaS – Platform as a Service (PaaS) use is growing, so users are looking to optimize these resources. ParkMyCloud offers optimization for databases, scale groups, and logical groups. We plan to expand into containers and stacks to meet this need.
- Data-driven automation (AIOps) – our customers, large and small, are pushing us to expand our data-driven policies and automation – everyone is becoming more comfortable with the idea of automation. Our first priority on this front is to optimize overprovisioned resources – often referred to as RightSizing … RightSizeMyCloud!
Cloud trends are not always easy to predict, but one thing is for certain: costs will need to be controlled. Good fun ahead.