AWS Trusted Advisor is a service that helps you understand if you are using your AWS services well. It does this by looking at 72 different best practices across 5 total categories, which include Cost Optimization, Performance, Security, Fault Tolerance, and Service Limits. All AWS users have access to 7 of those best practices, while Business Support and Enterprise Support customers have access to all items in all categories. Let’s dive in to each category to see what is there and what is missing.
A category that is near and dear to our hearts here at ParkMyCloud, the Cost Optimization category includes items related to the following services:
This list includes many of the services that are often the most expensive line items in an AWS account, but doesn’t take into account a large percentage of the AWS services available. Also, these recommendations only provide links to other AWS documentation that might help you solve the problem, as opposed to a service like ParkMyCloud that provides both the recommendations and ability to take the action of shutting down idle instances or resizing those instances for you.
This category caters more towards production instances, as it aims to make sure the performance of your applications is not hindered due to overutilization (as opposed to the Cost Savings category above, which is focused more on underutilization). This includes:
EC2 – highly-utilized VMs, large number of security group rules (per instance or per security group)
EBS – SSD volume configuration, overutilized magnetic volumes, EC2 to EBS throughput
This category is one of the weakest in terms of services supported, so you may want to factor that in if you’re trying to make sure your production applications are performing well on alternative AWS services.
The security checks of AWS Trusted Advisor will look at the following items:
Security Groups – Unrestricted ports, unrestricted access, RDS access risk
IAM – Use of Roles/Users, key rotation, root account MFA, password policy
S3 – Bucket permissions
CloudTrail – logging use
Route 53 – MX and SPF record sets
ELB – Listener security, Security groups
Cloudfront – Custom SSL certificates, certificates on the origin server
Access keys – Exposed keys
Snapshots – EBS public snapshots, RDS public snapshots
Security is a tough category to get right, as almost every one of these needs to be reviewed for your business needs. While this isn’t an exhaustive list of security considerations, it certainly helps your organization cover the basics and prevent some “I can’t believe we did that” moments.
One of the main benefits of the cloud that often gets overlooked is the use of distributed resources to increase fault tolerance for your services. These items in the fault tolerance category are focused on increasing the redundancy and availability of your applications. They include:
EBS – Snapshots
EC2 – Availability Zone balance
Load Balancer – optimization
VPN Tunnel – redundancy
Auto Scaling Groups – general ASG usage, health check
RDS – backups, multi-AZ configuration
S3 – bucket logging, bucket versioning
Route 53 – Name server delegations, record sets with high TTL or failover resources, deleted health checks
Direct Connect – Connection / location / virtual interface redundancy
Aurora DB – instance accessibility
EC2 Windows – EC2Config agent age, PV driver versions, ENA driver versions, NVMe driver versions
Overall, this turns out to be a great list of AWS services that can really make sure your production applications have minimal downtime and minimal latency. Additionally, some services like snapshots and versioning, help with recovering from problems in a timely fashion.
One of the hidden limitations that AWS puts on each account is a limit of how many resources you can spin up at any given time. This makes sense for AWS, so they don’t have new users unintentionally (or intentionally!) perform a DOS for other users. These service limits can be increased if you ask nicely, but this is one of the few places where you can actually see if you’re coming close. The services covered are:
Verdict: Helpful, But Not Game-Changing
While these checks and advice from AWS Trusted Advisor certainly help AWS users see ways to improve their usage of AWS, the lack of one-click-action makes these recommendations just that – recommendations. Someone still has to go verify the recommendations and take the actions, which means that in practice, a lot of this gets left as-is. That said, while I wouldn’t suggest upgrading your support just for Trusted Advisor, it certainly can provide value if you’re already on Business Support or Enterprise Support.
There have been about 1.3 zillion blogs posted this week recapping the announcements from AWS re:invent 2019, and of course we have our own spin on the topic. Looking primarily at cost optimization and cost visibility, there were a few cool new features posted. None of them were quite as awesome as the new Savings Plan announcement last month, but they are still worthy of note.
AWS Compute Optimizer
With AWS jumping feet-first into machine learning, it is no surprise that they turned it loose on instance rightsizing.
The Compute Optimizer is a standalone service in AWS, falling under the Management & Governance heading (yes, it is buried in the gigantic AWS menu). It offers rightsizing for the M, C, R, T, and X instance families and Auto Scaling groups of a fixed size (with the same values for desired/min/max capacity). To use the service you must first “opt-in” in each of your AWS accounts. Navigate to AWS Cost Optimizer and click the “Get Started” button.
Interestingly, they only promise a cost reduction “up to 25%”. This is probably a realistic yet humble claim, given that the savings for a single downsize in the same instance family is typically 50%. That said, the only way to get that 50% cost reduction is to install the AWS CloudWatch Agent on your instances and configure it to send memory metrics to CloudWatch. If you are not running the agent…then no memory metrics. Like ParkMyCloud rightsizing, in the absence of memory metrics, the AWS Compute Optimizer can only make cross-family recommendations that change only the CPU or network configuration, leaving memory constant. Hence – a potential 25% cost reduction.
The best part? It is free! All in all, this feature looks an awful lot like ParkMyCloud rightsizing recommendations, though I believe we add a bit more value by making our recommendations a bit more prominent in our Console – not mixed-in with 100+ other menu items… The jury is still out on the quality of the recommendations; watch for another blog soon with a deeper dive.
Amazon EC2 Inf1 Instance Family
Every time you congratulate yourself on how much you have been able to save on your cloud costs, AWS comes up with a new way to help you spend that money you had “left over.” In this case, AWS has created a custom chip, the “Inferentia”, purposely designed to optimize machine learning inference applications.
Inference applications essentially take a machine learning model that has already been trained via some deep-learning framework like TensorFlow, and uses that model to make predictions based on new data. Examples of such applications include fraud detection and image or speech recognition.
The Inferentia is combined in the new Inf1 family with Intel® Xeon® CPUs to make a blazingly fast machine for this special-purpose processing. This higher processing speed allows you to do more work in less time than you could do with the previous instance type used for inferencing applications, the EC2 G4 family. The G4 is built around Graphics Processing Unit (GPU) chips, so it is pretty easy to see that a purpose-built machine learning chip can be made a lot faster. AWS claims that the Inf1 family will have a “40% lower cost per inference than Amazon EC2 G4 instances.” This is a huge immediate savings, with only the work of having to recompile your trained model using AWS Neuron, which will optimize it for use with the Inferentia chip.
Next Generation Graviton2 Instances
The final cool cost-savings item is another new instance type that fits into the more commonly used M, C, and R instances families. These new instance types are built around another custom AWS chip (watch out Intel and AMD…) the Graviton2. The Graviton chips, in general, are built around the ARM processor design, more commonly found in smartphones and the like. Graviton was first released last year on the A1 instance family and honestly, we have not seen too many of them pass through the ParkMyCloud system. Since the Graviton2 is built to support M, C, and R, I think we are much more likely to see widespread use.
Looking at how they perform relative to the current M5 family, AWS described the following performance improvements:
HTTPS load balancing with Nginx: +24%
Memcached: +43% performance, at lower latency
X.264 video encoding: +26%
EDA simulation with Cadence Xcellium: +54%
Overall, the new instances offer “40% better price performance over comparable current generation instances.”
The new instance types will be the M6g and M6gd (“g”=Graviton, “d”=NVMe local storage), the C6g and C6gd, and the R6g and R6gd. The new family is still in Preview mode, so pricing is not yet posted, but AWS is claiming a net “20% lower cost and up to 40% higher performance over Amazon EC2 M5 instances, based on internal testing of workloads.” We will definitely be trying these new instance types when they release in 2020!
All in all, there were no real HUGE announcements that would impact your costs, but baby steps are OK too!
Google Cloud Platform vs AWS: what’s the deal? A while back, we also asked the same question about Azure vs AWS. After the release of the latest earnings reports a few weeks ago from AWS, Azure, and GCP, it’s clear that Microsoft is continuing to see growth, Amazon is maintaining a steady lead, and Google is stepping in. Now that Google Cloud Platform has solidly secured a spot among the “big three” cloud providers, we think it’s time to take a closer look and see how the underdog matches up to the rest of the competition.
Is Google Cloud catching up to AWS?
As they’ve been known to do, Amazon, Google, and Microsoft all released their recent quarterly earnings around the same time the same day. At first glance, the headlines tell it all:
The obvious conclusion is that AWS continues to dominate in the cloud war. With all major cloud providers reporting earnings around the same time, we have an ideal opportunity to examine the numbers and determine if there’s more to the story. Here’s what the quarterly earning reports tell us:
AWS had the slowest growth they have ever since they began separating their cloud reportings – up just 37% from last year.
Microsoft Azure reported a revenue growth rate of 59%.
Microsoft doesn’t break out specific revenue amounts for Azure, but Microsoft did report that its “Intelligent Cloud” business revenue increased 27% to $10.8 billion, with revenue from server products and cloud services increasing 30%
Google’s revenue has cloud sales lumped together with hardware and revenue from the Google Play app store, summing up to a total of $6.43 billion for the last quarter.
To compare, last year during Q3 their revenue was at $4.64 billion.
During their second-quarter conference call in July, Google said their cloud is on an $8 billion revenue run rate – meaning cloud sales have doubled in less than 18 months.
You can see here that while Google is the smallest out of the “big three” providers, they have shown the most growth – from Q1 2018 to Q1 2019, Google Cloud has seen growth of 83%. While they still have a ways to go before surpassing AWS and Microsoft, they are moving quickly in the right direction as Canalys reported they were the fasted growing cloud-infrastructure vendor in the last year.
It’s also important to note that Google is just getting started. Also making headlines was an increase in new hires, adding 6,450 in the last quarter, and most of them going to positions in their cloud sector. Google’s headcount now stands at over 114,000 employees in total.
The Obvious: Google is not surpassing AWS
When it comes to Google Cloud Platform vs AWS, we have a clear winner. Amazon continues to have the advantage as the biggest and most successful cloud provider in the market. While AWS is growing at a smaller rate now than both Google Cloud and Azure, Amazon still holds the largest market share of all three. AWS is the clear competitor to beatas they are the first and most successful cloud provider to date, with the widest range of services, and a strong familiarity among developers.
The Less Obvious: Google is actually gaining more ground
While it’s easy to write off Google Cloud Platform, AWS is not untouchable. AWS has already solidified itself in the cloud market, but with the new features and partnerships, Google Cloud is proving to be a force to be reckoned with.
Where is Google actually gaining ground?
We know that AWS is at the forefront of cloud providers today, but that doesn’t mean Google Cloud is very far behind. AWS is now just one of the three major cloud providers – with two more (IBM and Alibaba) gaining more popularity as well. Google Cloud Platform has more in store for its cloud business in 2020.
A big step for google was announced earlier this year at Google Cloud’s conference – Google Cloud Next – the CEO of Google Cloud announced that they would be coming out with a retail platform to directly compete with Amazon, called Google Cloud for Retail. What ‘s different about their product? For starters, they are partnering with companies such as Kohl’s, Target, Bed Bath & Beyond, Shopify, etc. – these retailers are known for being direct competition with Amazon. In addition to that, this will be the first time that Google Cloud has had an AI product that is designed to address a business process for a specific vertical. Google doesn’t appear to be stopping at just retail – Thomas Kurian said they are planning to build capabilities to assist companies in specialized industries, ex: healthcare, manufacturing, media, and more.
Google’s stock continues to rise. With nearly 6,450 new hires added to the headcount, a vast majority of them being cloud-related jobs, it’s clear that Google is serious about expanding its role in the cloud market. In April of this year, Google reported that 103,459 now work there. Google CFO Ruth Porat said, “Cloud has continued to be the primary driver of headcount.”
Google Cloud’s new CEO, Thomas Kurian, understands that Google is lagging behind the other two cloud giants, and plans to close that gap in the next two years by growing sales headcount.
Deals have been made with major retailer Kohl’s department store, and payments processor giant, PayPal. Google CEO Sundar Pichai lists the cloud platform as one of the top three priorities for the company, confirming that they will continue expanding their cloud sales headcount.
In the past few months, Pichai added his thoughts on why he believes the Google Cloud Platform is on a set path for strong growth. He credits their success to customer confidence in Google’s impressive technology and a leader in machine learning, naming the company’s open-source software TensorFlow as a prime example. Another key component to growth is strategic partnerships, such as the deal with Cisco that is driving co-innovation in the cloud with both products benefiting from each other’s features, as well as teaming up with VMware and Pivotal.
Driving Google’s growth is also the fact that the cloud market itself is growing so rapidly. The move to the cloud has prompted large enterprises to use multiple cloud providers in building their applications. Companies such as Home Depot Inc. and Target Corp. rely on different cloud vendors to manage their multi-cloud environments.
Home Depot, in particular, uses both Azure and Google Cloud Platform, and a spokesman for the home improvement retailer explains why that was intentional: “Our philosophy here is to be cloud-agnostic, as much as we can.” this philosophy goes to show that as long as there is more than one major cloud provider in the mix, enterprises will continue trying, comparing, and adopting more than one cloud at a time – making way for Google Cloud to gain more ground.
Multi-cloud environments have become increasingly popular because companies enjoy the advantage of the cloud’s global reach, scalability, and flexibility. Google Cloud has been the most avid supporter of multi-cloud out of the three major providers. Earlier this year at Google Cloud Next, they announced the launch ofAnthos, a new managed service offering for hybrid and multi-cloud environments to give enterprises operational consistency. They do this by running quickly on any existing hardware, leverage open APIs and give developers the freedom to modernize. There’s alsoGoogle Cloud Composer, which is a fully managed workflow orchestration service built on Apache Airflow that allows users to monitor, schedule and manage workflows across hybrid and multi-cloud environments.
Google Cloud Platform vs. AWS – Why Does It Matter?
Google Cloud Platform vs AWS is only one of the battles to consider in the ongoing cloud war. The truth is, market performance is only one factor in choosing the best cloud provider. As we always say, the specific needs of your business are what will ultimately drive your decision.
What we do know: the public cloud market is not just growing – it’s booming. Referring back to our Azure vs AWS comparison – the basic questions still remain the same when it comes to choosing the best cloud provider:
Are the public cloud offerings to new customers easily comprehensible?
What is the pricing structure and how much do the products cost?
Are there adequate customer support and growth options?
Will our DevOps processes translate to these offerings?
Can the PaaS offerings speed time-to-value and simplify things sufficiently, to drive stickiness?
Right now AWS is certainly in the lead among major cloud providers, but for how long? We will continue to track and compare cloud providers as earnings are reported, offers are increased, and price options grow and change. To be continued in 2020…
According to most organizations, the biggest drivers to cloud are elasticity and agility. In other words, it allows you to instantly provision and de-provision resources based on the needs of the business. You no longer have to build the church for Sunday. Once in the cloud though, 80% of companies report receiving bills 2-3 times what they expected. The truth is, that while the promise of cloud is that you only pay for what you use, the reality is that you pay for what you allocate. The gap between consumption and allocation is what causes the large and unexpected bills.
Cost isn’t the only challenge. While most organizations report cost being their biggest problem in managing a public cloud environment, you cannot truly separate performance from cost, the two are tightly coupled. If an organization was optimizing for cost alone, moving all applications to the smallest instance type would be the way to go, but no one is willing to take the performance hit. In the cloud, more than ever, cost and performance are tied together.
To guarantee their SLAs, applications require access to all the resources they need. Developers, in an effort to make sure their applications behave as expected, allocate resources based on peak demand to ensure they have access to those resources if they need them. Without constantly monitoring and adjusting the resources allocated to each application, over-allocation is the only way to assure application performance. Overprovisioning of virtualized workloads is so prevalent, that it’sestimated that more than 50% of data centers are over-allocated.
On-premises, over-allocation of resources, while still costly, is significantly less impactful to the bottom line. On-premises the over provisioning is masked by over-allocated hardware and hypervisors that allow for sharing resources. In the cloud, where resources are charged by the second or minute, this over provisioning is extremely costly, resulting in bills much larger than expected.
The only way to solve this problem is to find a way to calibrate the allocation of resources continuously based on demand, or in other words, match supply and demand. This would result in TRULY only paying for the resources you need when you need them, the holy grail of cost efficiency. The ideal state is to have the right amount of resources at the right time, no more, and the only way to achieve that is through automation.
So why doesn’t everyone do that?
This is a complicated problem to solve. To achieve that we must look at all resources required by each application and match them to the best instance type, storage tier and network configuration in real time.
Let’s take a simple application running a front end and a back end on AWS EC2 in the Ohio region using EBS storage. There are over 70 instance types available. Each instance type defines the allocated memory, CPU, the benchmarked performance of the CPU to be expected (not all CPU cores perform equally), the available bandwidth for network and IO, the amount of local disk available and more. On top of that, there are 5 storage tiers on EBS that would further define the IOPS and IO throughput capabilities of the applications. This alone results in over 350 options for each component of the application.
Taking a closer look at network complicates matters even further.
Placing the two components across AZs will result in costly communication costs back and forth between the AZs. In addition, the latency in communication across AZs, even in the same region, is larger than within the same AZ, so depending on the latency sensitivity of the application the decision on which AZ to place the app on impacts the performance of the application, not just the cost. Placing them on the same AZ is not a great option either – it increases the risk to the organization in case of an outage on that zone. Cloud providers would only guarantee five 9s (99.99999%) up time when instances are spread across more than a single zone. In the Ohio region, there are 5 availability zones which brings us up to the need to evaluate 1,750 options for each component of the applications. Each of these options need to be evaluated against the memory, CPU, IO, IOPS, Network throughput and so on.
The problem is just as complicated on Azure, with over X instance types and different levels of premium and standard storage tiers and the recent introduction of availability zones.
Where you get the data to back up your decisions is important as well. When looking at the monitored data at the IaaS layer alone neither performance or efficiency can be guaranteed. Let’s take a simple JVM as an example. When looking at the memory monitored at the IaaS layer it will always report using 100% of the heap, but is it utilizing it? Is the application garbage collecting every minute or once a day? The heap itself should be adjusted based on that to make sure the application gets the resources it needs, when it needs them. CPU isn’t better. If the IaaS layer is reporting an application consuming 95% of a single CPU core, most would argue that it needs to be moved to a 2 core instance type. Looking into the application layer allows you to understand how the application is using that CPU. If a single thread is responsible for the bulk of the resource consumption adding another core wouldn’t help but moving to an instance family with stronger CPU performance would be a better solution.
To sum it up, assuring application performance while maintaining efficiency is more difficult than ever. The only way to truly only pay for what you use you must match supply and demand across multiple resources, from the application layer down to the IaaS layer in real time.
AWS recently announced the release of AWS Savings Plans – a new system for getting a discount on committed usage for EC2 and Fargate. The previous systems of Reserved Instances (RIs) are still around, and in some cases may still be the right way to go. That said, based on our research, if your virtual machines do not need to be running 24/7, they are still not as effective at cost savings as scheduling your systems to be shut down when not in use.
I am not keen on the “Savings Plan” name, as it sounds to me like you are building up money in the bank, but really it is a capacity purchase plan to save you money.
The key feature of the Savings Plans is that you are committing to spend a certain amount of money per hour for EC2 and/or Fargate use. The hourly commitment must be greater than or equal to $0.001. If you make the commitment, AWS will give you a discount on whatever virtual machine to which they apply the expense.
There are two kinds of Savings Plan:
Compute Savings Plan – Apply to EC2 or Fargate usage regardless of instance family, size, AZ, region, OS, or tenancy. For any given instance configuration, pricing is similar (if not identical) to an equivalent Convertible RI, giving up to a 66% discount.
EC2 Instance Savings Plan – Specific to EC2 instances within a family in a specific region, but regardless of size, OS, or tenancy. For any given instance configuration, pricing is similar to an equivalent Standard RI, giving up to a 72% discount in exchange for the reduced flexibility.
Both types require a commitment for either 1 year or 3 years.
They cannot be canceled, refunded, or exchanged
You can buy as many as you like for as much of a commitment as you like. Ten plans at $1/hour each, or one plan at $10/hour, or any other combination for as little or as much as you like.
Savings Plans vs RIs
AWS has a table that compares Savings Plans vs RIs here, but either they were trying to make the Savings Plans look a lot better than RIs, or someone forgot to check a few boxes. (I mean wouldn’t you say that RIs give you a “lower price in exchange for a monetary commitment”? I sure would.) Here is my take on that table:
So obviously there are feature differences. The key thing here is that the Savings Plans give the same amount of savings as a somewhat equivalent RI, but with a LOT more flexibility in terms of what instances can get the discount.
The customers get in, but they can’t get out…
If you change your mind about buying an RI, you can sell it on the AWS RI Marketplace. You will not get back the full value of what you owe, but at least there is an option. With Savings Plans there is (so far) no way to back out. The AWS Service Terms (section 4.5) states “Savings Plans are noncancellable.”
Why might you want to get rid of an RI?
Maybe you bought a non-flexible RI, switched your needed instance size/family, and the RI is no longer useful.
Maybe…you just cannot afford it anymore.
For the first issue, Savings Plans are a lot more flexible, allowing exchanges across sizes, families, and regions, depending on what kind of Savings Plan you buy.
For the second issue…Savings Plans provide no flexibility. Do you have any workloads elsewhere you can bring in to use the commitment – maybe some containers that can be moved to an EC2, or maybe an RDS that you can turn in to a self-managed database? Or maybe you can just use the unused capacity to mine a couple pennies-worth of Bitcoin…
At the end of the day, you need to weigh the discount vs. your confidence in the stability of your workloads and your funding.
(I personally just picked up a $0.001 per hour plan for $8.76 for the year and feel confident that I can meet that obligation.)
Savings Plans vs Scheduling
Just like RIs, savings plans are intended to be applied against resources that are up 7/24/365 (or 7/24/1095 for 3-year purchases). For resources that only need to be when someone is using them, like dev, test, staging, build, and similar system, it is likely better to schedule them.
To demonstrate this, here is a comparison for a t2.medium in us-east-1 running Linux in shared tenancy. The t2.medium, while a small and slightly older instance type, is the most commonly used instance type we see across all of our ParkMyCloud customers, with 3x the number of deployments than the next most common type.
In the graphs below, the slanting green line represents the monthly cost of an instance based on the number of hours it is running per day on weekdays only (so it already accounts for pulling out the cost of weekends). For example, if this virtual machine was running 12 hours per day on weekdays (not a very aggressive schedule) it will cost $144.77 per year. Compared to the baseline pay-as-you-go price of $406.46 per year, this is a savings of 64%.
The following graph shows a comparison of the annual cost of this t2.medium instance when bought with:
Either a Compute Savings Plan or an EC2 Instance Savings plan
For a 1-year vs 3-year term
With no upfront cost (so you are charged monthly)
This graph is telling us that compared to the most aggressive EC2 Instance Savings Plan bought at a 3-year commitment, scheduling is still less expensive. In fact, we need to get up to about 14 hours per weekday before the Savings Plan saves any money.
At the top end, the instance could run all day on weekdays, 5/24, and just match the 1-year Compute Savings Plan savings. (That number matches so closely I truly wonder if this is how they came up with the base savings for the RIs and Savings Plan.)
In this next graph, we change the Savings Plans to be purchased all upfront, which gives a bit more savings but still cannot match the savings of the 5-day/12-hour schedule.
Note that if this WERE a system we want to keep up 7/24, we would have to create a savings plan that covers the hourly cost of the instance. For example, the base price of the t2.medium in our example is $0.0464 per hour. Under the savings plans, we get a discount on this, and if we wanted to be sure at least this instance was covered, we would need to buy a savings plans (with no upfront cost) with one of the following rates
Again note that none of these reach the 64% savings of a basic 5-day/12-hour schedule.
How are Savings Plan Applied to my Bill?
The example above shows what you would pay for that t2.medium if it was the only instance in your account. If you have multiple instances or even multiple accounts within an AWS Organization, the Savings Plan is applied in a prioritized way, trying to “use” up the less flexible savings methods before getting to the most flexible:
First, any RIs are applied to your bill – they are less flexible, so you want them “used up” before Savings Plans are applied
Then, EC2 Instance Savings Plans are applied next
And lastly, Compute Savings Plans are applied
Within either of the Savings Plan types:
The plan is first applied to the AWS Account in which the Plan was purchased
And the plan is applied to the resource type/region/etc with the highest potential discount compared to On-Demand
After that is shared with the rest of the accounts in your AWS Organization
Why did AWS do this?
AWS is philosophically all about the customer…and there is NO question that this new feature is great for the customers. Looking beyond that: anytime a vendor can lock you in to a long-term contract it makes things easier for the vendor in a lot of ways. For AWS, committed use means a more predictable balance sheet and more predictable data center utilization. RIs gave both of these, but they were about as complicated as filling out your taxes, and could be as restrictive as a tight pair of underwear. I am betting AWS is shooting for increased levels of commitment that help the long term bottom-line. The downsides for them are the potentially reduced revenue and the reduced datacenter usage predictability at the region level (since the Compute Savings Plans are cross-region). That said…those long term commitments look really good to the stock market, and a reduction in revenue volatility cannot be bad either.
What do I do now?
At this point you should run (not walk) over to the Savings Plan section of the Billing Dashboard in AWS and see what is recommended in there – it is certainly worth the look. If you were hesitant about buying an RI due to the region or size restrictions, it may be time to reconsider. Note that you do not have to have full coverage of your spend with Savings Plans, but if you have a consistent level of usage 7/24/365, you should cover at least SOME of it with a Compute Savings Plan… And if your usage is not consistent…then consider scheduling your resources with ParkMyCloud…which can also save over 65%.
Longtime readers of the ParkMyCloud blog know about some of the pillars of cost savings – Reserved Instances for production workloads, schedule your non-production servers to turn off on nights and weekends, and resize your VMs to a smaller size if it’s underutilized – our data shows that 95% of instances in the public cloud are operating at less than 50% average CPU – but one of the more underrated methods of saving money on your cloud bill is by making sure your VMs and databases are running on the latest instance family. Let’s take a look at what this means, what your options are, and how much you can expect to save.
Instance Family 101
When you spin up a virtual machine in a public cloud like AWS, Microsoft Azure, or Google Cloud, you get to decide the specifications of the machine. In addition to disk options and network options, you’ll often choose CPU and memory in a “bundle” of pre-built sizes. These sizes have an instance family they are a part of, which usually helps you choose based on whether the application you plan to run is CPU-intensive, memory-intensive, or requires a GPU.
For example, if you are setting up an EC2 virtual machine in AWS, you’ll get to pick from a couple different instance sizes and types as one of the first screens you see in the console. If you pick the instance type of “m5.large”, then “m5” is the instance family and “large” is the size. M5 in AWS is a balanced instance family, while C5 is meant for CPU-intensive applications. Microsoft Azure has a similar idea, with their D-series being a balanced instance and the F-series being optimized for CPU.
Google Cloud does VM sizing a bit differently, but still has the concept of an instance family. A general purpose VM in GCP is often of the type “n2-standard”. Specializing in CPU offers a few different options, where you have the choice between “n2-highcpu” instances for more vCPUs or “c2-standard” for higher performance of those vCPUs. Additionally, GCP offers custom VM sizes, so you can individually pick your vCPU count and the amount of memory you need.
Cloud providers incentivize instance modernization by pricing the newest generations the lowest. Most new instance families come out due to better-performing hardware. This usually comes in the form of newer CPU types, but can also refer to networking or memory improvements as well. This means that not only are you getting a server that performs better (even with the same specs), but it’s also cheaper as well. The same size but in a more modern family gets you 10%-20% discounts in price. This combination of better performance and better price means that unless your application doesn’t interact well with the latest hardware, then it’s a no-brainer to switch.
ParkMyCloud Can Help Modernize
One of the recommendations that ParkMyCloud makes, in addition to schedules for non-production resources and size recommendations based on usage data, is to modernize a VM to a newer instance family so that you can optimize performance with the lowest cost. If you choose to accept this recommendation to move to the latest family, then you can choose to resize right away, or to pick a time in the future (like during a maintenance window) — ParkMyCloud takes the action for you. Note that this involves restarting the machine, so you may want to make sure it’s not in use at the time of resizing.
Remember, VM sizing and type selection has a drastic effect on cost –– one size down within the same VM family can reduce the cost by 50%, and with changes between families or across more than one size, savings can be even greater. ParkMyCloud’s user interface helps you see how much you can save by making this modernization update, so you know that you’re getting the most out of your cloud spend. Try out ParkMyCloud today to get recommendations for parking, rightsizing, and modernizing your instances!