AWS CPU credits are unique to T-series instances – and they can be a bit tricky to figure out. Whether you’re using the AWS free tier or just trying to use the smallest EC2 compute instance you can, you’ll need to keep track of these credits. These credits are both generated and used by the T2 and T3 instance families to decide how much CPU power you can actually use on those EC2 instances. This can be confusing if you aren’t expecting your virtual machine to have it’s CPU power throttled, or are wondering why the cost is much higher than you thought it would be.
AWS first released a “burstable” instance type in the form of the t1.micro instance size in 2010, which was four years after the first EC2 instance size was released (m1.small in 2006, for you historians). Up until 2010, new instance sizes had always been bigger than the m1.small size, but there was demand for a VM size that could accommodate low-throughput or inconsistent workloads.
The t1.micro was the only burstable instance size for another four years, until the t2.medium was released in 2014. Soon, there was a whole range of t2 instances to cover the use case of servers that were low-powered while idle, but could have lots of potential compute resources available for the couple minutes each hour they were needed. In 2018, AWS introduced the t3 family that uses more modern CPUs and the AWS Nitro system for virtualization.
AWS CPU Credits 101
The key reason why T-series instances have a lower list price than corresponding M-series instances (in standard mode, more on that later) is the CPU credits that are tracked and used on each resource. The basic premise is that an idle instance earns credits, while a busy instance spends those credits. A “credit” corresponds to 1 minute’s worth of full 100% CPU usage, but this can be broken down in different ways if the usage is less than 100%. For instance, 10% of CPU usage for 10 minutes also uses 1 credit. Each T-series machine size not only has a number of CPUs available, but also earns credits at different rates.
Here’s where the math starts getting a little tricky. A t2.micro instance earns 6 credits per hour with 1 available CPU. If you run that instance at 10% utilization for a full hour, it’ll spend 6 credits per hour (or 1 credit every 10 minutes). This means that any time spent under 10% utilization is a net increase in CPU credits, while any time spent above 10% utilization is a net decrease in CPU credits. A t3.large instance has 2 CPUs and earns 36 credits per hour, which means the balancing point where the net credit use is zero will be at 30% utilization per CPU.
So what happens when you run out of credits or never use your credits?
Standard Mode vs. Unlimited Mode
One of the differences between the t2 family and the t3 family is the default way each handles running out of credits. The t2 family defaults to Standard Mode, which means that once the instance has run out of credits to use, the CPU is throttled to the baseline value we calculated above (so 10% for t2.micro) and will continue maxing out at that value until credits have built back up. In practice, this means that your process or application that has burst up to use a lot more CPU than normal will soon be slow and unusable if the load remains high.
In 2017, AWS introduced Unlimited Mode as an option for t2 instances – and later, in 2018, as the default for t3 instances when they were introduced. Unlimited mode means that instead of throttling down to the baseline CPU when your instance runs out of credits, you can continue to run at a high CPU load and just pay for the overages. This price is 5¢ per CPU hour for Linux and 9.6¢ per CPU hour for Windows. In practice, this means that a t2.micro that has run out of credits and is running at 35% CPU utilization for a full 24 hours would cost an additional 30¢ that day on top of the normal 27.84¢ for 24hr usage, meaning the price is more than doubled.
Using T-series Instead of M-series
These overage charges for Unlimited Mode of t2 and t3 instances means that while the list price of the instance is much cheaper than corresponding m4 and m5 instances, you need to figure out if the utilization pattern of your workload makes sense for a burstable instance family. For example, an m5.large in us-east-1 costs 9.6¢/hr and a t3.large with similar specs costs 8.32¢/hr with a 30% CPU baseline. If your t3.large server is going to be running higher than 55.6% CPU for the hour on a consistent basis, then the price of the m5.large is actually lower.
When to Stop T-series and When to Let Them Run
One perk of using the t2 instances in Standard mode is that each time you start the server, you receive 30 launch credits that allow a high level of CPU usage when you first start the instance from a stopped state. These launch credits are tracked separately from accrued credits and are used first, so servers that only need to run short-lived processes when first starting can take advantage of this fact. The downside of stopping t2 servers is that accrued credits are lost when you stop the instance.
On the other hand, t3 servers persist earned credits for 7 days after stopping the instance, but don’t earn launch credits when they are first started. This is useful to know for longer-running processes that don’t have huge spikes, as they can build up credits but you don’t need to worry about losing the credits if you stop the server.
At ParkMyCloud, we specialize in scheduling servers and databases to turn off on a schedule, which is perfect for non-production servers. We find that lots of users have t2 and t3 instances for these dev and test workloads, but want to know what happens to credits if you park those servers overnight. As we discussed, AWS CPU credits go away in T2 standard mode (but with additional launch credits) but persist in T3 Unlimited mode. Knowing this, you can pick the right instance size for the workload you’re running and confidently save money using ParkMyCloud.
- Best for non-production instances that have a quick burst of usage when starting = T2 instance with ParkMyCloud parking schedule
- Best for non-production instances with unpredictable, but sporadic spikes = T3 instance with ParkMyCloud parking schedule
Try it for free to see how we can make the cost of your t2 and t3 servers even lower.
Further reading on saving money on AWS:
When it comes to AWS training resources, there’s no shortage of information out there. Considering the wide range of videos, tutorials, blogs, and more, it’s hard knowing where to look or how to begin. Finding the best resource depends on your learning style, your needs for AWS, and getting the most updated information available. Whether you’re just getting started in AWS or consider yourself an expert, there’s an abundance of resources for every learning level. With this in mind, we came up with our 7 favorite AWS training resources, sure to give you the tools you need to learn AWS:
1. AWS Self-Paced Labs
What better way to learn that at your own pace? AWS self-paced labs give you hands-on learning in a live AWS environment, with AWS cloud services, and actual scenarios you would encounter in the cloud. There are two different ways to learn with these labs. You can either take an individual lab or follow a learning quest. Individual labs are intended to help users get familiar with an AWS service as quickly as 15 minutes. Learning quests guide you through a series of labs so you can master any AWS scenario at your own pace. Once completed, you will earn a badge that you can boast on your resume, LinkedIn, website, etc.
Whatever your experience level may be, there are plenty of different options offered. Among the recommended labs you’ll find an Introduction to Amazon Elastic Compute Cloud (EC2), and for more advanced users, a lab on Maintaining High Availability with Auto Scaling (for Linux).
2. AWS Free Tier
Sometimes the best way to learn something is by jumping right in. With the AWS Free Tier, you can try AWS services for free. This is a great way to test out AWS for your business, or for the developers out there, to try services like AWS CodePipeLine, AWS Data Pipeline, and more. While you are still getting a hands-on opportunity to learn a number of AWS services, the only downside is that there are certain usage limits. You can track your usage with a billing alarm to avoid unwanted charges, or you can try ParkMyCloud and park your instances when they’re not in use so you get the most out of your free tier experience. In fact, ParkMyCloud started its journey by using AWS’s free tier!
3. AWS Documentation and Whitepapers
AWS Documentation is like a virtual encyclopedia of tools, terms, training, and everything AWS. You’ll find case studies, tutorials, cloud computing basics, and so much more. This resource is a one-stop-shop for all of your AWS documentation needs, whether you’re a beginner or advanced user. No matter where you are in your AWS training journey, AWS documentation is always a useful reference and certainly deserves a spot in your bookmarks.
Additionally, you’ll find whitepapers that give users access to technical AWS content that is written by AWS and individuals from the AWS community, to help further your knowledge of their cloud. These whitepapers include things from technical guides, reference material, and architecture diagrams.
So far, we’ve gone straight to the source for 3 out of 7 of our favorite AWS training resources. Amazon really does a great job of providing hands-on training, tutorials, and documentation for users with a range of experience. However, YouTube opens up a whole new world of video training that includes contributions from not only Amazon, but other great resources as well. Besides the obvious Amazon Web Services channel, there are also popular and highly rated videos by Edureka, Simplilearn, Eli the Computer Guy, and more.
As cloud technology usage continues to expand and evolve, blogs are a great way to stay up to speed with AWS and the world of cloud computing. Of course, in addition to aws labs, a free-trial, extensive documentation, and their own YouTube channel, AWS also has their own blog. Since AWS actually has a number of blogs that vary by region and technology, we recommend that you start by following Jeff Barr – Chief Evangelist at Amazon Web Services, and primary contributor. Edureka was mentioned in our recommended YouTube channels, they also have a blog that covers plenty of AWS topics. The CloudThat blog is an excellent resource for AWS and all things cloud, and was co-founded by Bhaves Goswami – a former member of the AWS product development team. Additionally, AWS Insider is a great source for all things AWS. Here you’ll find blogs, webcasts, how-to, tips, tricks, news articles and even more hands-on guidance for working with AWS. If you prefer newsletters straight to your inbox, check out Last Week in AWS and Inside Cloud.
6. Online Learning Platforms
As public cloud computing continues to grow – and AWS continues to dominate the market – people have become increasingly interested in this CSP and what it has to offer. In the last 8-10 years, two massive learning platforms were developed, Coursera and Udemy. These platforms offer online AWS courses, specializations, training, and degrees. The abundance of courses that these platforms provide can help you learn all things AWS and give you a wide array of resources to help you train for different AWS certifications and degrees.
GitHub is a developer platform where users work together to review and host code, build software and manage projects. This platform has access to a number of materials that can help further your AWS training. In fact, here’s a great list of AWS training resources that can help you prepare for an Amazon Cloud certification. The great thing about this site is the collaboration among the users. The large number of people in this community brings together people from all different backgrounds so they are able to provide knowledge about their own specialties and experiences. With access to everything from ebooks, video courses, free lectures, and sample tests, posts like these can help you get on the right certification track.
There’s plenty of information out there when it comes to AWS training resources. We picked our 7 favorite resources for their reliability, quality, and range of information. Whether you’re new to AWS or consider yourself an expert, these resources are sure to help you find what you’re looking for.
Q4 2019 earnings are in for the ‘big three’ cloud providers and you know what that means – it’s time for an AWS vs Azure vs Google Cloud market share comparison. Let’s take a look at all three providers side-by-side to see where they stand.
Note: a version of this post was originally published in April 2018 and 2019. It has been updated for 2020.
AWS vs. Azure vs. Google Cloud Earnings
To get a sense of the AWS vs Azure vs Google Cloud market share breakdown, let’s take a look at what each cloud provider’s reports shared.
Amazon reported Amazon Web Services (AWS) revenue of $9.95 billion for Q4 2019, compared to $7.4 billion for Q4 2019. AWS revenue grew 34% in the quarter, compared to a year earlier.
Across the business, Amazon’s quarterly sales increased to $87.4 billion, beating predictions of $86.02 billion.AWS has been a huge contributor to this growth. AWS revenue made up 11% of total Amazon sales for the quarter. AWS only continues to grow, and bolster the retail giant time after time.
One thing to keep in mind: you’ll see a couple of headlines pointing out that revenue growth is down, quoting that 34% number and comparing it to previous quarters’ growth rates, which peaked at 81% in 2015. However, that metric is of questionable value as AWS continues to increase revenue at this enormous scale, dominating the market (as we’ll see below).
In media commentary, AWS’s numbers seem to speak for themselves:
While Amazon specifies AWS revenue, Microsoft only reports on Azure’s growth rate. That number is 62% revenue growth over the previous quarter. This time last year, growth was reported at 76%. As mentioned above, comparing growth rates to growth rates is interesting, but not necessarily as useful a metric as actual revenue numbers – which we don’t have for Azure alone.
Here are the revenue numbers Microsoft does report. Azure is under the “Intelligent Cloud” business, which grew 27% to $11.9 billion. The operating group also includes server products and cloud services (30% growth) and Enterprise Services (6% growth).
The lack of specificity around Azure frustrates many pundits as it simply can’t be compared directly to AWS, and inevitably raises eyebrows about how Azure is really doing. Of course, it also assumes that IaaS is the only piece of “cloud” that’s important, but then, that’s how AWS has grown to dominate the market.
A victory for the cloud provider was the October winner of the $10 billion JEDI cloud computing contract (although AWS is actively protesting the contract with claims of political interference).
Here are a few headlines on Microsoft’s reporting that caught our attention:
This quarter, Google broke out revenue reporting for its cloud business for the first time. For the fourth quarter, Google Cloud generated $2.6 billion in revenue, a growth of 53% from the previous year. For 2019 as a whole, Google Cloud brought in $8.9 billion in revenue, which is less than AWS generated in the fourth quarter alone.
Google CEO Sundar Pichai stated on the earnings report conference call, “The growth rate of GCP was meaningfully higher than that of Cloud overall, and GCP’s growth rate accelerated from 2018 to 2019.”
CFO Ruth Porat also highlighted Google Cloud Anthos, as Google leans into enabling the multi-cloud reality for its customers, something AWS and Azure have avoided.
Further reading on Google’s quarterly reporting:
Cloud Computing Market Share Breakdown – AWS vs. Azure vs. Google Cloud
When we originally published this blog in 2018, we included a market share breakdown from analyst Canalys, which reported AWS in the lead owning about a third of the market, Microsoft in second with about 15 percent, and Google sitting around 5 percent.
In 2019, they reported an overall growth in the cloud infrastructure market of 42%. By provider, AWS had the biggest sales gain with a $2.3 billion YOY increase, but Canalys reported Azure and Google Cloud with bigger percentage increases.
As of February 2020, Canalys reports AWS with 32.4% of the market, Azure at 17.6%, Google Cloud at 6%, Alibaba Cloud close behind at 5.4%, and other clouds with 38.5%.
Ultimately, it seems clear that in the case of AWS vs Azure vs Google Cloud market share – AWS still has the lead.
Bezos has said, “AWS had the unusual advantage of a seven-year head start before facing like-minded competition. As a result, the AWS services are by far the most evolved and most functionality-rich.”
Our anecdotal experience talking to cloud customers often finds that true, and it says something that Microsoft isn’t breaking down their cloud numbers just yet, while Google leans into multi-cloud.
AWS remains far in the lead for now. With that said, it will be interesting to see how the actual numbers play out, especially as Alibaba catches up.
As cloud users continue to use Alibaba Cloud, extending its global presence, we’ll review a comparison of AWS vs Alibaba Cloud pricing. Commonly recognized as the #4 cloud provider (from a revenue perspective anyway), Alibaba is one of the fastest-growing companies in the space today.
Alibaba has been getting a lot of attention lately, given its rapid growth, and making headlines after the release of their latest quarterly revenue and full fiscal year 2019 reports. Alibaba is at the top of the market in Asia, and dominating in China with cloud revenue up 66% year-over-year. While Alibaba is in the top 5 CSPs worldwide, they still have a lot of plans for the future to maintain this growth and continue to move up.
The company said it is focused on high-value security, analytics, and artificial intelligence tools and “rationalizing our offerings of commodity products and services.” With an annual revenue run rate of $4.5 billion, it is clear that Alibaba Cloud intends to compete globally with AWS and other major cloud providers.
However, on a global scale, AWS continues to dominate the market. In the latest quarter, Amazon reported Amazon Web Services (AWS) sales of $7.7 billion, compared to $5.44 billion at this time last year. AWS revenue grew 41% in the first quarter – at this time last year, that number was 49%.
ParkMyCloud supports Alibaba Cloud and AWS, and with that, let us focus on pricing and cost savings – our forte. In this blog, we dive a bit into the pricing of Alibaba Elastic Compute Service (ECS), compare it with that of the AWS EC2 service and whether Alibaba Cloud computing can offer better value than AWS.
Alibaba ECS vs AWS EC2
Elastic Compute Service (ECS) and Elastic Cloud Compute (EC2), respectively, are the standard compute services offered by Alibaba Cloud and AWS.
Both cloud computing services provide the same core features:
- The ability to choose from dozens of instance types.
- Support for virtual as well as bare-metal servers.
- Compatibility with a variety of Windows and Linux-based operating systems.
- The ability to create custom images.
The major differences between Alibaba Cloud ECS and AWS EC2 are that Alibaba Cloud provides a wider range of instance families and that AWS offers more regions globally.
Alibaba vs Aliyun
Finding actual pricing for comparison purposes can be a bit complicated, as the prices are listed in a couple of different places and do not quite exactly match up since pricing varies between different instance types, and no instances from the two companies are identical. If one searches for Alibaba pricing, one ends up here, which I am going to call the “Alibaba Cloud” site. However, when you actually get an account and want to purchase an instance, you can up here or here, both of which I will call the “Aliyun” site. [Note that you may not be able to see the Aliyun sites without signing up for an account and actually logging-in.]
Aliyun (literally translated “Ali Cloud”) was the original name of the company, and the name was changed to Alibaba Cloud in July 2017. Unsurprisingly, the Aliyun name has stuck around on the actual operational guts of the company, reflecting that it is probably hard-coded all over the place, both internally and externally with customers. (Supernor’s 3rd Conjecture: Engineering can never keep up with Marketing.)
Both sites show that like the other major cloud providers, Alibaba’s pricing model includes a Pay-As-You-Go (PAYG) offering, with per-second billing. Note, however, that in order to save money on stopped instances, one must specifically enable a “No fees for stopped instances” feature. Luckily, this is a global one-time setting for instances operating under all Pay-As-You-Go VPC instances, and you can set it and forget it. Unlike AWS, this feature is not available for any instances with local disks (this and other aspects of the description lead me to believe that Alibaba instances tend to be “sticky” to the underlying hardware instance). On AWS, local disks are described as ephemeral and are simply deallocated when they are not in use. Like AWS, Alibaba Cloud system/data disks continue to accrue costs even when an instance is stopped.
Both sites also show that Alibaba also has a one-month prepaid Subscription model. Based on a review of the pricing listed for the us-east-1 region on the Alibaba Cloud site, the monthly subscription discount reflects a substantial 30-60% discount compared to the cost of a PAYG instance that is left up for a full month. For a non-production environment that may only need to be up during normal business hours (say, 9 hours per day, weekdays only), one can easily see that it may be more cost-effective to go with the PAYG pricing, and use the ParkMyCloud service to shut the instances down during off-hours, saving 73%.
But this is where the similarities between the sites end. For actual pricing, instance availability, and even the actual instance types, one really needs to dive into a live Alibaba account. In particular, if PAYG is your preference, note that the Alibaba public site appears to have PAYG pricing listed for all of their available instance types, which is not consistent with what I found in the actual purchasing console.
Low-End Instance Types – “Entry Level” and “Basic”
The Alibaba Cloud site breaks down the instance types into “Entry Level” and “Enterprise”, listing numerous instance types under both categories. All of the Entry Level instance types are described as “Shared Performance”, which appears to mean the underlying hardware resources are shared amongst multiple instances in a potentially unpredictable way, or as described by Alibaba: “Their computing performance may be unstable, but the cost is relatively low” – an entertaining description to say the least. I did find these instance types on the internal purchasing site, but did not delve any further with them, as they do not offer a point of reference for our AWS vs. Alibaba Cloud pricing comparison. They may be an interesting path for additional investigation for non-production instance types where unstable computing performance may be OK in exchange for a lower price.
That said…after logging in to the Alibaba management console, reaching the Aliyun side of the website, there is no mention of Entry Level vs Enterprise. Instead, we see the top-level options of “Basic Purchase” vs “Advanced Purchase”. Under Basic Purchase, there are four “t5” instance types. The t5 types appear to directly correspond to the first four AWS t2 instance types, in terms of building up CPU credits.
These four instance types do not appear to support the PAYG pricing model. Pricing is only offered on a monthly subscription basis. A 1-year purchase plan is also offered, but the math shows this is just the monthly price x12. It is important to note that the Aliyun site itself has issues, as it lists the t5 instance types in all of the Alibaba regions, but I was unable to purchase any of them in the us-east-1 region – “The configuration for the instance you are creating is currently not supported in this zone.” (A purchase in us-west-1, slightly more expensive, was fine).
The following shows a price comparison for Alibaba vs AWS for “t” instance prices in a number of regions. The AWS prices reflect the hourly PAYG pricing, multiplied by an average 730 hour month. I was not able to get pricing for any AWS China region, so the Alibaba pricing is provided for reference.
While the AWS prices are higher, the AWS instances are PAYG, and thus could be stopped when not being used, common for t2 instances used in a dev-test environment, and potentially saving over 73%. One can easily see that this kind of savings is needed to compete with the comparatively low Alibaba prices. I do have to wonder what is up with that Windows pricing in China….does Microsoft know about this??
Aliyun “Advanced Purchase”
Looking at the “Advanced” side of the Aliyun purchasing site, we get a lot more options, including Pay-As-You-Go instances. To keep the comparison simple, I am going to limit the scope here to a couple of instance types, trying to compare a couple m5 and i3 instances with their Alibaba equivalents. I will list PAYG pricing where offered.
In this table, the listed monthly AWS prices reflect the hourly pay-as-you-go price, multiplied by an average 730 hour month.
The italicized/grey numbers under Alibaba indicate PAYG numbers that had to be pulled from the public-facing website, as the instance type was not available for PAYG purchase on the internal site. From a review of the various options on the internal Aliyun site, it appears the PAYG option is not actually offered for very many standalone instance types on Alibaba…
The main reason I pulled in the PAYG prices from the second source was for auto scaling, which is normally charged at PAYG prices. In Alibaba, “all ECS instances that Auto Scaling automatically creates, or manually adds to a scaling group will be charged according to their instance types. Note that you will still be charged for Pay-As-You-Go instances even after you stop them.” It is possible, however, to manually add subscription-based instances to an auto scaling group, and configure them to be not removed when the group scales-down.
In general, the full price of the AWS Linux instances over a month is 22-35% higher than of an Alibaba 1-month subscription. A full price AWS Windows instance over a month is 9-25% higher than that of an Alibaba subscription. (And once again, it appears Windows licensing fees are not a factor in China.)
When it comes to Alibaba Cloud pricing vs AWS, Alibaba Cloud is trying to attract business and expand their global footprint by offering special promotions typically consisting of free trials, specially priced starter packages, and time-limited discounts on premium services. In many cases, taking advantage of these promotions could be useful in order to save money, but so is AWS.
AWS Introduces Savings Plans for EC2
Amazon also has their fair share of money-saving offerings as well. AWS announced the release of AWS Savings Plans – a new system for getting a discount on committed usage for EC2.
There are two kinds of Savings Plan:
- Compute Savings Plan – Apply to EC2 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.
AWS Reserved Instance new queuing option
You can now purchase reserved instances that, rather than going into effect immediately, are scheduled for future purchase.
Now, when planned correctly, you can avoid lapsing on 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.
However, AWS RI purchases have few limitations, they 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.
AWS vs Alibaba Cloud Pricing: Alibaba is cheaper, but…
Alibaba definitely comes out as less expensive in this AWS vs Alibaba cloud pricing comparison – the one-month subscription has a definite impact. However, for longer-lived instances, AWS Reserved Instances will certainly be less expensive, running about 40-75% less expensive than AWS PAYG, and thus less than some if not all of the Alibaba monthly subscriptions. AWS RI’s are also more easily applicable to auto scaling groups than a monthly subscription instance.
For non-production instances that can be shut down when not in use, PAYG is less expensive for both cloud providers, where ParkMyCloud can help you schedule the downtime. The difficulty with Alibaba will actually be finding instances types that can actually be purchased with the PAYG option.
A few years ago, AWS announced the release of their Scheduled Reserved Instances. These reserved instances are designed for workloads that recur on a daily, weekly, or monthly schedule, and are purchased for a one-year term. AWS says that Scheduled Reserved Instances provide a 5-10% savings over On-Demand instances used for this same purpose.
While we always appreciate ways to save on AWS, there are a few reasons that Scheduled Reserved Instances are unlikely to make a useful addition to your toolbox when compared to other cost-savings options available.
First of all, they have a decidedly limited use case, only for predictably scheduled operations that will go on for at least one year. Many companies would need to see a much higher savings rate than 10% with this year-long commitment when looking at AWS on demand vs reserved.
Secondly, they are inflexible. Once you set a schedule, you cannot change or override it, and the options to set schedules are limited to daily, weekly, or monthly recurrence on a set duration. Since one of the main benefits of cloud is the ultra-flexibility you get on short notice, this might be a deal-breaker by itself.
Additionally, as Beth Pariseau pointed in a TechTarget article, additional management overhead is required to manage every additional type of instance that a company leverages.
Note that Scheduled Reserved Instances are also limited by region – only available in US East (Northern Virginia), US West (Oregon), and Europe (Ireland) regions – and by instance type, currently supporting C3, C4, M4, and R3 instance types. This means that modern versions of those EC2 instance families, like M5, M5a, M5n, M6g, C5, or C5n, are not available for scheduling, so you’re using an older version of those EC2 instance types. While this might not matter much now, the list of usable instance types has not been updating along with the on-demand instance types, which means this problem will only get worse with time.
When compared to standard AWS reserved instance pricing, you’re not really getting the savings you’d expect from this kind of commitment. Reserved Instances typically save 30% for a convertible 1-year purchase, and can be about 60% for a standard 3-year purchase. This means that if you have an EC2 instance you need that would match the scheduled reserved instance but are using that same EC2 size for other workloads throughout the month, then the non-scheduled EC2 reserved instance pricing works much better with more savings.
For your recurring workloads, you can run instances only when you need them but maintain flexibility by using ParkMyCloud to schedule on/off times for On-Demand instances. By keeping workloads on just during business hours, you’ll save 65% using ParkMyCloud, with even more savings achievable if you need that instance even less throughout the month (and doesn’t even account for savings achieved through RightSizing). This beats any AWS RI pricing while maintaining flexibility for your organization. Keep this in mind while you are evaluating your reserved instance vs on demand decisions.
See the chart below for a full comparison of using Scheduled Reserved Instances vs. using ParkMyCloud.
This comparison shows that AWS Scheduled Reserved Instances are unlikely to be worth any effort or investigation by your cloud operations team. ParkMyCloud provides more benefits and much higher savings with more flexibility and less commitment. Even standard AWS EC2 Reserved Instance pricing and savings can give you more bang for your buck.
If you’ve got workloads and servers that don’t need to run very frequently throughout the month, but you need to ensure they can be spun up at a moment’s notice, then ParkMyCloud can help you save money and enable your users for maximum cloud efficiency. Give ParkMyCloud a try for yourself – start seeing savings today.
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:
- EC2 – Reserved Instance purchase recommendations, underutilized VMs, Reserved Instance lease expirations
- Load Balancers – idle LBs
- EBS – Underutilized volumes
- Elastic IP – unassociated addresses
- RDS – Idle databases
- Route 53 – Inefficient latency record sets
- Redshift – Underutilized clusters
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
- Route 53 – alias record sets
- Cloudfront – CDN optimization, header forwarding, cache hit ratio, alternate domain names
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
- ELB – connection draining, cross-zone load balancing
- 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:
- Route 53
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.