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!
Every week, we find ourselves having a conversation about cost optimization with a wide variety of enterprises. In larger companies, we often talk to folks in the business unit that most people traditionally refer to as Information Technology (IT). These meetings usually include discussions about the centralization vs decentralization of IT and oftentimes they don’t realize it, as we are discussing cloud and how it’s built, run and managed in the organization.
Enterprises traditionally organized their IT team as a single department under the leadership of the CIO. The IT team works across organizational departments and supports the enterprise to meet various tooling and project needs requested by other business units or the executive team. Although there are significant efficiencies from this type of approach, there are some risks that can affect the entire organization, in particular, one that seems to stem from the ‘need for speed’ (agility). The LOB depends on IT to deliver services, hardware, software, and other ‘tools’, but this is not always done quickly and efficiently, mostly due to internal processes.
Benefits of Centralized IT Structures
The benefits of this type of organizational structure were often associated with increased purchasing power, improved information flow between IT team members, skilled hiring efficiencies, and a watchful view of the enterprise’s technical infrastructure from both an operational network and security perspective. Let’s dig into these in a bit more detail.
Lowered expenses and increased purchasing power – the centralized environment will always provide a business with more buying power at a lower cost by combining all of the needs of the business into a centralized buying pool.
Improved productivity for IT staff – IT teams are like any other team, they thrive with collaboration and mutual understanding and respect for each other’s skillsets. It also makes installations and technical resolution(s) easier as you’re addressing a centralized resource.
Enterprise-wide information dissemination – the centralized organization will build its network from the center out – LOBs will typically share the same networked resources – such as an ERP or CRM. This avoids the dangers of siloed information that could be critical to another LOB, but without access, there’s no visibility into the information that is available.
Despite the benefits stated above, a centralized team has several limitations and challenges – one of those challenges with the greatest enterprise-wide exposure is how best to prioritize project requests from each of the LOBs – enter decentralization and cloud — IaaS, PaaS and SaaS.
Decentralization is a type of organizational structure in which daily operations and decision-making responsibilities are delegated by top management to middle and lower-level managers and their respective business units. This frees up top management to focus more on major decisions. For a small business, growth may create the need to decentralize to continue efficient operations. Decentralization offers several advantages and is a practical approach when different departments or business units in a company have different IT needs and strategies.
Benefits of Decentralized IT Structures
The ability to tailor IT selection and configuration. When individual departments have IT decision-making power, they can choose and configure IT resources based on their own specific needs. For example, each department has its own servers optimized to run its required applications.
More fail-safes and organizational redundancy. Decentralizing makes servers and applications more resilient—and it can do the same for IT networks, too. If each department maintains its own server, one can function as a backup server in case another server fails. (Of course, this type of redundancy would need to be properly configured in advance.)
Respond faster to new IT trends. Since departments in decentralized organizations can make independent decisions, it’s easier for them to take advantage of new technology in the cloud.
One drawback of decentralized IT structures is that this model often leads to information silos – collections of data and information that cannot be easily shared across departments. Centralized IT structures help prevent these silos, leading to better knowledge-sharing and cooperation between departments. For example, using one centrally managed CRM system makes it possible for any employee in a company to access customer information from anywhere — think SalesForce.
The Reality is Hybrid IT
As we see above and in real life, there are many reasons an organization might be tempted to move toward or away from a centralized IT organizational structure but in practice many companies practice a hybrid model – some IT systems like your CRM and ChatOps are centralized, while others like your Cloud Provider and Orchestration tool may be decentralized (buy business unit). The top reasons for this hybrid model that come to mind are technical agility and the availability of tools through SaaS, IaaS and PaaS providers – IT no longer needs to build every solution and tool for you. And decentralized IT organizational structures are typically best for companies that rely on technical agility to remain competitive. These include newer, smaller companies (e.g., startups), and organizations that need to respond quickly to new IT developments (e.g., software and hardware companies or app developers). And, for larger companies that want to bring that mentality and model to their business, here is a great example, Capital One, a bank wanting to be a technology company.
What are your thoughts on the centralization vs decentralization of IT?
In the search to accelerate and simplify the DevOps process, we take a look at Microsoft’s Azure DevOps, a hosted service providing development and collaboration tool that was formerly known as Visual Studio Team Services (VSTS). Last year, Microsoft split VSTS into five separateAzure-branded services, under the banner Azure DevOps for a complete offering in public cloud that makes it easier for developers to adopt portions of the Azure DevOps platform, without requiring them to go “all in” like the former VSTS.
Azure DevOps supports both public and private cloud configurations – the services include:
Azure Boards – A work tracking system with Kanban boards, dashboards, and reporting
Azure Pipelines – A CI/CD, testing, and deployment system that can connect to any Git repository
Azure Repos – A cloud-hosted private Git repository service
Each of these Azure DevOps services is open and extensible and can be used with all varieties of applications, regardless of the framework, platform or cloud. Built-in cloud-hosted agents are provided for Windows, Mac OS and Linux and workflows are enabled for native container support and Kubernetes deployment options, virtual machines, and serverless environments.
With all five services together users can take advantage of an integrated suite that provides end to end DevOps functionalities. But, since they are broken up into separate components, Azure DevOps gives users the flexibility to just pick which services to employ without the need to use the full suite. For example, with Kubernetes having a standard interface and running the same way on all cloud providers, Azure Pipelines can be used for deploying toAzure Kubernetes Service (AKS),Google Kubernetes Engine (GKE),Amazon Elastic Kubernetes Service (EKS), or clusters from any other cloud provider without requiring the use of any of the other Azure DevOps components.
Embracing Azure DevOps
One of the main benefits for teams using Azure DevOps is developers will be able to work securely from anywhere and in any format and embrace open-source technology. Azure DevOps addresses thevendor lock-in problem from its early version by providing extensive integration with industry and community tools.
With the many integrations available, users can log in using SSO tools like Azure AD or communicate with their team via Slack integration while accessing both cloud and on-premises resources.
Azure Pipelines offers free CI/CD with unlimited minutes and 10 parallel jobs for every open source project and many of the top open-source projects already use Azure Pipelines for CI/CD, such as Atom, CPython, Pipenv, Tox, Visual Studio Code, and TypeScript.
Benefits of Azure DevOps
Azure DevOps use cases include:
Planning – Azure DevOps makes it easy for DevOps teams to manage their work with full visibility across products and projects, helping them keep development efforts transparent and on schedule. Teams can define, track, and layout work with Kanban boards, backlogs, custom dashboards and reporting capabilities using Azure Boards.
Developing – Allows teams to share code and collaborate together with Visual Studio and Visual Studio Code. Users can create automatic workflows for automated testing and continuous integration in the cloud with Azure Pipelines.
Delivery – Helps teams deploy applications to any Azure service automatically and with full control. Users can define and spin up multiple cloud environments with Azure Resource Manager or HashiCorp Terraform, and then create continuous delivery pipelines into these environments using Azure Pipelines or tools such as Jenkins and Spinnaker.
Operations – With Azure Monitor, users can implement full stack monitoring, get actionable alerts, and gain insights from logs and telemetry.
As for Azure DevOps pricing, there are a lot of open-source tools that can be combined to deliver the functionality that Azure DevOps promises to provide, but the basic plan for open source projects and small projects is free up to five users. For larger teams, the cost can range from $30 per month for 10 users to $90 per month for 20 users and so forth.
In summary, Azure DevOps is an all in one focussed project tracking and planning tool mixed with Developer and DevOps tools for writing, building and deploying code that’s relatively quick and easy to use. But, while maintenance cost is decreased, developers only need an active subscription to have constant access to the latest version. Azure DevOps will indirectly utilize Azure Storage and compute services that will increase usage and impact costs.
With another recent round of earnings reports from Amazon, Microsoft and Google out of the way it’s always enjoyable to stand back and see what we can discern about the public cloud market share.
According to Synergy Research Group who closely monitor such trends, they saw 37% overall growth year-over-year in public cloud. They reported that it has taken just two years for the public IaaS and PaaS markets to double in size and their forecast shows them doubling within the next three years. Within the overall market it is possible to discern some interesting trends amongst the top three providers, which we discuss below.
Amazon Web Services (AWS)
Last Thursday, Amazon reported that its cloud division revenue increased 35% in the third quarter, which was down from 37% in the previous quarter, and its slowest growth rate in five years. AWS finished its third-quarter with $9 billion in revenue. Each of the three previous quarters also showed a decline in growth which can be seen below.
Microsoft followed AWS’s report with Azure reporting a revenue growth rate of 59%. In a similar vein to AWS, growth was reported as slowing and was down on the previous quarter which was 64% and down from 76% from a year ago. While Microsoft doesn’t break out specific revenue amounts for Azure (unlike AWS) 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%
Azure also hit the headlines around the same time as their earnings report with the announcement of their securing the lucrative, high profile and highly contested $10B Pentagon’s JEDI Cloud contract. This was viewed as a key strategic win for the company and a game changer in the face-off with AWS.
Google Cloud Platform (GCP)
Last to report were Google’s parent company Alphabet. During their analysts call a few references were made to overall performance which included the Alphabet CEO calling out Thomas Kurian, who leads the GCP business, in saying “Obviously, ever since Thomas has come in, he has continued to invest across the board. He’s definitely focused a lot on scaling up our sales, partner and operational teams, and it’s playing out well”. Furthermore, it was reported that GCP had hired more sales, engineering and product managers, and that GCP, analytics and compute would continue to be a focus of the company’s investments going forward.
GCP falls into Alphabets “other” revenue bucket, which includes Google Play and hardware. Of businesses, GCP had the highest revenue. Other revenue was $6.43 billion in Q3, which was a 39% increase over $4.64 billion a year ago. There is no doubt that the cloud business is the largest of the three but Alphabet didn’t break out more specific numbers for cloud.
Some of the companies outside The Big Three, including Alicloud, IBM, Oracle, etc. are all growing, but they continue to lose ground to these three dominant market leaders. To compete, hyper-scale really matters, and these three bring that in spades.
Cloud in 2020 and beyond
As we enter the next decade a number of market watchers are speculating about what the reported slow down in growth means for the public cloud market share. As has been widely observed in other markets it’s a truism that as hyper-scale is achieved growth rates will decline. However, even with the overall reduction in growth they still exceed almost every other area within the broader technology market. As of Q3 2019, the overall quarterly run rate size was $25 billion, implying the annual run rate is now over $100 billion and still growing fast. It’s unlikely that there are too many other markets with better prospects going into next year.