One of the key drivers to a multi-cloud strategy is the fear of vendor lock-in. “Vendor lock-in” means that a customer is dependent on a particular vendor for products and services, and unable to use another vendor without substantial switching costs or operational impact. The vendor lock-in problem in cloud computing is the situation where customers are dependent (i.e. locked-in) on a single cloud service provider (CSP) technology implementation and cannot easily move to a different vendor without substantial costs or technical incompatibilities.
Vendor Lock-in: Public Cloud vs. Traditional Infrastructure
Before the cloud, IT was running in dedicated on-premises environments, requiring long-term capital investments and an array of software license commitments and never ending hardware refresh contracts. Based on that experience, it is understandable that a customer would be concerned about lock-in. Many large IT vendors like Oracle, IBM, HP, and Cisco would “lock” customers into 3-5-10 year Enterprise License Agreements (ELAs) or All You Can Eat (AYCE) hardware and software license agreements, promising huge discounts and greater buying power – but only for their products, of course. I used to sell these multi-year contracts. There is a common ground for sure, as the customer was locked-in to the vendor for years. But that was then and this is now. Is vendor lock-in really a concern for public cloud users?
Isn’t the point of cloud to provide organizations the agility to speed innovation and save costs by quickly scaling their infrastructure up and down? I mean, we get it – your servers, data, networking, user management, and much more are in the hands of one company, so the dependence on your CSP is huge. And if something goes wrong, it can be very detrimental to your business – your IT is in the cloud, and if you’re like us, your entire business is developed, built and run in the cloud. Most likely, some or all of your organization’s IT infrastructure where you are developing, building and running applications to power your business and generate revenue, is now off-premise, in the cloud. But although “lock-in” sounds scary, you are not stuck in the same way that you were with traditional hardware and software purchases.
Can You Really Get “Locked In” to Public Cloud?
Let’s talk about the realities of today’s public cloud-based world. Here are a couple of reasons why vendor lock-in isn’t as widespread a problem as you might think:
No Long-Term Commitments: Customers can adopt the cloud on their own terms. AWS, Azure, and Google Clouds are designed so customers only use the services when they see value, and they are free to use the technology of their choice. Pay-as-you-go pricing provides customers with the ability to shut down their environment, export their data and virtual machines (VMs), and walk away without ever incurring another expense. Customers are billed monthly without any required long-term commitments or contracts regardless of spend or support tier.
Customer Choice: Today’s cloud customers have alternatives to proprietary tools with advances in open source software technologies, along with a range of ‘as-a-service’ capabilities that can remake traditional IT — IaaS, PaaS, and even SaaS. A wide range of solutions that support industry standards allow customers to choose what they want to invest in and architect for application portability from the beginning, if they so choose.
Moving Into and Out of a CSP: Generally speaking, cloud services are built to support both migration into and out of their platforms, and CSPs and the industry at large provide many tools and documented techniques to make it easy to do both. Many cloud service providers offer tools to help move data between networks and technology partners. Customers can securely move information in and out of the cloud regardless of where that information is going: cloud-to-cloud or cloud-to-data center.
How to Mitigate Risk with a Multi-Cloud Strategy
Now the cloud is not without risk, and when we talk to customers the primary vendor lock-in concerns we hear are related to moving to another cloud service provider IF something goes awry. You hope that this never has to happen, but it’s a possibility. The general risks include:
Data transfer risk – it is not easy to move your data from CSP to another.
Application transfer risk – If you build an application on one CSP that leverages many of its offerings, the reconfiguration of this application to run natively on another provider can be an extremely expensive and difficult process
Infrastructure transfer risk – Every major CSP does things a little bit differently.
Human knowledge risk – simply put, AWS is not the same as Azure which is not the same as GCP, and your IT team has likely gained a lot of institutional knowledge about that provider’s tools and configurations.
To minimize the risk of vendor lock-in, your applications should be built or migrated to be as flexible and loosely coupled as possible. Cloud application components should be loosely linked with the application components that interact with them. And, adopt a multi-cloud strategy.
How Much Should You Worry About Vendor Lock-In?
Many companies are familiar with vendor lock-in from dealing with traditional enterprise companies mentioned above – you begin to use a service only to realize too late what the terms of that relationship brings with it in regards to cost and additional features and services. The same is not entirely true with selecting a cloud service provider like AWS, Azure, or Google Cloud. It’s difficult to avoid some form of dependence as you use the new capabilities and native tools of a given cloud platform. In our own case, we use AWS and we can’t just wake up tomorrow and use Azure or Google Cloud. However, it’s quite possible to set your business up to maintain enough freedom and mitigate risk, so you can feel good about your flexibility.
So how much should enterprises worry about vendor lock-in in public cloud? IMHO: they shouldn’t.
Sean Brundle, DevOps Engineer at website development specialist Brainjocks, told us about how his team uses ParkMyCloud to manage cloud and DevOps costs.
Hi Sean! Tell us about Brainjocks and what you all do.
Sure. Brainjocks is a web design and development company that utilizes Sitecore, Episerver, and WordPress solutions to help companies build and manage websites. The Brainjocks team creates and updates websites that are most frequently hosted on public cloud servers.
We support our customers from end to end. We create and update their websites, and often support them after they go live, also. Sometimes we host their web sites on our cloud servers using Google Cloud, AWS, or Azure cloud solutions.
What’s your role at Brainjocks?
I’m a DevOps engineer, so my role is to set up and support all of the different environments for projects. I also configure automation tools and processes for developers, allowing them to deploy code changes in a seamless and automated process.
That is where ParkMyCloud comes into play for us. I make sure that we aren’t charging our clients too much for their cloud services when those services are not being actively utilized.
We have a DevOps team of five, and we support approximately 90 employees across our company.
How did you all decide to have a multi-cloud environment across all three of the major providers?
When we first started using public cloud, we opted for Google Cloud. At the time, Google Cloud was a more economically affordable option, and it was a great start for internal servers and internal projects. As of today we have 55 Google Cloud servers being managed in ParkMyCloud. These instances consist of internal servers for quality assurance sites, as well as proof of concept servers for the clients who we manage within Google Cloud.
Later we began using AWS for our continuous integration needs. One of the primary tools that we use for continuous integration and continuous deployment is TeamCity, which contains numerous AWS integration points. When Azure became a feature leader in the cloud market we began transitioning many of our clients to the Azure solution, primarily for the reliability of supporting production environments and to take advantage of the integration options for our development tools. Azure bolstered their integration offerings for servers, as well as for the continuous integration Azure Devops tool that we use for most of our projects on the Azure environment. We also use Microsoft products for our development processes. Since we use both SQL Server and Visual Studio, we utilize Azure for production environments.
What led you to search for a solution like ParkMyCloud?
We have a lot of active servers for internal testing, and keeping those online 24/7 is a significant cost when we only need them online when we are actively using them. Initially we would enable and disable the servers manually as needed, but that was a very time-consuming activity for our DevOps team. Cross-department communication became a challenge, also, as the QA team might try to do tests within a certain environment only to discover that the servers they needed were turned off, requiring them to seek out a DevOps resource and request that the server be brought back online.
Azure includes some automated options to schedule server availability, but neither Google Cloud nor AWS offers a good scheduling feature. That’s why I began researching different tools in the market that can automate server schedules. It is ideal to have one to reliably schedule server availability. ParkMyCloud does an amazing job with that.
I also like the option of configuring policies that allow me to schedule specific server availability per project. These scheduling features also greatly facilitate our processes across our US- and European-based offices since they operate in multiple time zones. With ParkMyCloud I have a schedule for each time zone, so when it’s 3:00 in the morning local time in our Atlanta office the European servers will automatically be online. They don’t have to ping us and wake us up early in the morning. So that’s one thing I was definitely looking for in a tool that we never had before.
That sounds like it was a pain to manage.
It sure was. The previous, manual process for enabling and disabling servers was not an efficient process at all, and it was a tedious task to organize all of our servers across all of our time zones.
How did you first hear about ParkMyCloud?
We looked into creating a custom application that would do something similar to ParkMyCloud, but our custom solutions didn’t have a lot of the benefits that we have found in your solution. We wanted a way that the QA team could go in and see if the servers are on or off, request to have the servers turn on, and then I was planning to create an automated process to have these servers on and off on a certain schedule. I was creating automation scripts to turn off the servers, and eventually I just realized that there’s got to be a good tool out there that will automate this process for me. That’s when I started researching, and through my research I found ParkMyCloud. I saw a demo, and determined that ParkMyCloud does everything that I want plus much, much more.
How much have you saved on your cloud bills so far with ParkMyCloud?
We just started using it a few months ago, and we’ve already saved $10,000.
Do you have ParkMyCloud integrated with any other tools you use?
Yes. We use Slack, which is the biggest communication tool that we use throughout our company. I have Slack integrated with ParkMyCloud, so any time a scheduled configuration changes or when certain critical servers are turned on or off, all applicable team members are alerted via the Slack-ParkMyCloud integration before those servers are shut down.
Is green computing something cloud providers like Amazon, Microsoft, and Google care about? And whether they do or not – how much does it matter? As the data center market continues to grow, it’s making an impact not only on the economy but on the environment as well.
Public cloud offers enterprises more scalability and flexibility compared to their on-premise infrastructures. One benefit occasionally touted by the major cloud providers is that organizations will be more socially responsible when moving to the cloud by reducing their carbon footprint. But is this true?
Here is one example: Northern Virginia is the east coast’s capital of data centers, where “Data Center Alley” is located (and, as it happens, the ParkMyCloud offices), home to more than 100 data centers and more than 10 million square feet of data center space. Northern Virginia welcomed the data center market because of its positive economic impact. But as the demand for cloud services continues to grow, the expansion of data centers also increases dramatically. Earlier this year, the cloud boom in Northern Virginia alone was reaching over 4.5 gigawatts in commissioned energy, about the same power output needed from nine large (500-megawatt) coal power plants.
Environmental groups like Greenpeace have accused major cloud providers like Amazon Web Services (AWS) of not doing enough for the environment when operating data centers. According to them, the problem is that cloud providers rely on commissioned energy from energy companies that are only focused on dirty energy (coal and natural gas) and very little from initiatives that include renewable energy. While the claims bring the spotlight on energy companies as well, we wanted to know what (if anything) the major cloud providers are doing to rely less on these types of energy and provide data centers with cleaner energy to make green computing a reality.
Data Center Sustainability Projects from AWS
According to AWS’s sustainability team, they’re investing in green energy initiatives and are striving to commit to an ambitious goal of 100% use of renewable energy by 2040. They are doing this with the proposition and support of smart environmental policies, and leveraging expertise in technology that drives sustainable innovation by working with state and local environmental groups and through power purchase agreements (PPAs) from power companies.
AWS’s Environmental Layer, which is dedicated to site selection, construction, operations and the mitigation of environmental risks for data centers, also includes sustainability considerations when making such decisions. According to them, “When companies move to the AWS Cloud from on-premises infrastructure, they typically reduce carbon emissions by 88%.” This is because their data suggests companies generally use 77% fewer servers, 84% less power, and gain access to a 28% cleaner mix of energy – solar and wind power – compared to using on-premise infrastructure.
So, how much of this commitment has AWS been able to achieve and is it enough? In 2018, AWS said they had made a lot of progress in their sustainability commitment, and exceeded 50% of renewable energy use. Currently, AWS has nine renewable energy farms in the US, including six solar farms located in Virginia and three wind farms in North Carolina. AWS plans to add three more renewable energy projects, one more here in the US, one in Ireland and one in Sweden. Once completed they expect to create approximately 2.7 gigawatts of renewable energy annually.
Microsoft’s Environmental Initiatives for Data Centers
Microsoft has stated that they are committed to change and make a positive impact on the environment, by“leveraging technology to solve some of the world’s most urgent environmental issues.”
In 2016, they announced they would power their data centers with more renewable energy, and set a target goal of 50% renewable energy by the end of 2018. But according to them, they were able to achieve that goal by 2017, earlier than they expected. Looking ahead they plan to surpass their next milestone of 70% and hope to reach 100% of renewable energy by 2023. If they were to meet these targets, they would be far ahead of AWS.
Beyond renewable energy, Microsoft plans to use IoT, AI and blockchain technology to measure, monitor and streamline the reuse, resale, and recycling of data center assets. Additionally, Microsoft will implement new water replenishment initiatives that will utilize rainfall for non-drinking water applications in their facilities.
Google’s Focus for Efficient Data Centers
Google claims that making data centers run as efficiently as possible is a very big deal, and that reducing energy usage has been a major focus to them for over the past 10 years.
Google’s innovation in the data center market came from the process of building facilities from the ground up instead of buying existing infrastructures. According to Google, using machine learning technology to monitor and improve power-usage-effectiveness (PUE) and find new ways to save energy in their data centers gave them the ability to implement new cooling technologies and operational strategies that would reduce energy consumption in their buildings by 30%. Additionally, they deployed custom-designed, high-performance servers that use very little energy as possible by stripping them of unnecessary components, helping them reduce their footprint and add more load capacity.
By 2017, Google announced they were using 100% renewable energy through power purchase agreements (PPAs) from wind and solar farms and then reselling it back to the wholesale markets where data centers are located.
The Environmental Argument
Despite the pledges cloud providers are committing to in renewable energy, cloud services continue to grow beyond those commitments, and how much energy is needed to operate data centers is still very dependant on “dirty energy.”
Breakthroughs for cloud sustainability are taking place, whether big or small, providing the cloud with better infrastructures, high-performance servers, and the reduction of carbon emissions with more access to renewable energy resources like wind and solar power.
However, some may argue the time might be against us, but if cloud providers continue to better improve existing commitments that keep up with growth, then data centers – and ultimately the environment – will benefit from them.
A recent conversation I had with Turbonomic founder and president Shmuel Kliger highlighted the importance of abstraction layers. Shmuel told me, “there’s only one reason why IT exists,” which quickly led to a discussion of cloud and abstraction.
It’s easy enough to get caught up in the whirlwind of ever-evolving technologies that returning to a single, fundamental purpose of IT is actually quite an intriguing idea.
Why Does IT Exist?
So, why does IT exist? As Shmuel put it, the purpose of IT is to get applications the resources they need in order to perform. That’s it!
That key step of “enablement” is where we get to the plethora of technologies – private cloud, public cloud, serverless cloud, containers, managed containers, container orchestration, IoT data, data warehouses, data lakes, the list goes on and on. There’s no lack of solutions to the many productivity and technology-related problems faced in businesses today. Really, the problem is that such a wide and constantly changing array of technologies exist, inadvertently (or perhaps advertently, depending on your view!) creating more complexity in the wake of the problems they solve.
Complexity is no stranger, but it’s no friend, either. Simplification leads to efficiencies across the board, and should be one of the primary goals IT departments seek to achieve.
How Abstraction Provides Simplification
First of all: what do we mean by abstraction? An abstraction layer is something that hides implementation details and replaces it with more easily understandable and usable functions. In other words, it makes complicated things simpler to use. These layers can include hardware, programmable logic, and software.
When you start to think about the layers between hardware and an application end user, you see that the abstraction layers also include on-premises hardware; cloud providers and IaaS; PaaS; FaaS; and containers. These middlemen start to add up, but ultimately, in order for an application to execute its underlying sequence of code, it needs CPU, memory, I/O, network, and storage.
On this point, Shmuel said: “I always say the artifact of demand can change and the artifact of supply can change, but the problem of matching demand to supply doesn’t go away.”
By using layers of abstraction to match this demand to supply, you remove the burden of the vast majority of decisions from the developer and the end user – in other words, simplification. One of the most prominent
The Full Benefits of Operating Through Abstraction Layers
In addition to simplification, other benefits of abstraction include:
Reducing Complexity of Analysis – by bringing data into one place and one format, abstraction makes data analytics simpler and broader reaching.
Reducing Required Expertise – by rolling up multiple hardware and software problems into a single management layer, you eliminate much of the heterogeneity that requires diverse skills in your organization’s workforce and generally reduces the limits imposed by the human end user.
Optimize everything – by eliminating silos and allowing for a single point of analysis, abstraction management opens doors to resource and cost optimization.
IT organizations should attack the problems of complexity in two ways: one, by identifying the most messy and complex areas of your technology stack and creating a plan of attack to simplify their management.
Two, by identifying “quick wins” where you can abstract away the problem with automation, achieving a better environment, automatically. We’ve got one for you: try ParkMyCloud to automatically optimize your cloud costs, saving you time, money, and effort.
AWS Reserved Instances vs. Scheduling On-Demand Instances
We are frequently asked about the impact of instance scheduling on AWS Reserved Instances for EC2 and RDS. Scheduling On Demand instances as well as Reserved Instances (RIs) are both useful techniques for cost optimization, but they are polar opposites in terms of goals. RIs are all about getting a better price for RDS or EC2 instances that are running all the time. Scheduling is all about reducing costs by turning off instances when they are not in use.
How should a customer choose between buying an AWS Reserved Instance and applying scheduling to the instance? This is an important question, as usually the savings from scheduling can exceed the savings available from a Reserved Instance. Before we dive into that though, let’s get familiar with some critical RI nuances that can help you make the decision…and make the most of your RIs.
Note: versions of this article were originally published in 2015 and 2017. It has been completely re-analyzed, rewritten, and updated!
Where are my Reserved Instances?
First of all, it’s worth clarifying that there is no functional difference between Amazon Reserved Instances and On Demand. It’s all in the billing. <rant> I wish I had a dollar for each time someone asked me (while looking at the AWS Console) “Which ones of these are the Reserved Instances?” </rant>. You cannot be sure which instances are using a reservation until you get your bill. You can make a good guess, based on what account you are looking at and what reservations you have purchased, but if you are using instance size flexibility with region-based RIs, it would be a pure guess. An instance reservation is not like a hotel reservation, where you end up with a specific room for the duration of your stay. That would be a Dedicated Host Reservation – a whole other beast with its own set of limitations.
3600 Seconds per Hour
Yep – there are 3600 seconds in an hour. I did the math. You may ask: why does that matter? It matters because of two things: per-second billing for EC2, and the fact that AWS RIs are billed in one hour chunks. More precisely, RIs are billed in one “clock-hour” chunks, where a clock-hour starts on the hour and up to the final second of the hour – like 04:00:00 to 04:59:59.
If you are running a number of instances that use per-second billing, and they go up or down during a (clock) hour, then multiple instances may be able to leverage the Reserved Instance pricing.
As paraphrased shamelessly from here, if you purchase one m5.large Reserved Instance and run four matching m5.large instances for 15 minutes each (900 seconds each) in the same hour, the total running time is one hour, which consumes the entire Reserved Instance allocation. This usage pattern is illustrated below.
That said, if multiple matching instances are running at the same time, the Reserved Instance billing benefit is applied to all of the instances, up to a maximum of 3600 seconds in a clock-hour. On-demand rates are used for any usage after that. This is illustrated below.
By the way, remember that per-second billing only applies to instances running an open-license OS like Amazon Linux or Ubuntu.
If your instance is running any flavor of Windows, Red Hat Linux, or any pay-by-the-hour image from the AWS Marketplace, that instance is billed by the hour, and any matching reservation will be consumed by the hour, even if the instance is not. Any overlapping instances will each need their own RI to get RI pricing.
Elastic Reserved Instances
Wait…what? Isn’t that kind-of an oxymoron? Elastic means it should be able to change with my usage…and aren’t reservations are a commitment to usage? Well, maybe…but some RIs are definitely more elastic (or at least more flexible) than others. Regional Reserved Instances can leverage “instance size flexibility.” This is the ability of a reservation to apply up or down to other instance types in the same family. Regional RIs are applied in priority order from the smallest instance in the region to the largest instance in the region. This makes these AWS reservations somewhat elastic in that if you buy reservations for smaller instance types than you normally use, then those reservations are more likely to be consumed, even if you rightsize an instance or replace one server with another of a different size.
The math of how an RI of one instance type can be applied to another instance type is governed by a “normalization factor”, described here. Putting the table in that link another way:
Some examples of how we can use this table:
To fully cover one t3.medium with RIs, you would buy eight t3.nano RIs. If you stop using the t3.medium instance, the same eight t3.nano RIs could also be used to cover:
Two t3.small instances
One t3.small and two t3.micro
Half of a t3.large
To fully cover an m5.12xlarge would require 24 m5.large RIs. Those 24 m5.large RIs could also be used for:
One m5.8xlarge and one m5.4xlarge
One m5.8xlarge and two m5.2xlarge
One m5.8xlarge, one m5.2xlarge, one m5.xlarge, and two m5.large
Three quarters of an m5.16xlarge
The lesson here is that it is easiest to manage reserved instances if you buy the smallest instance size available within an instance family. In fact, as shown below this is the exact type of recommendation you are likely to receive from the AWS Cost Explorer.
So why do we mention AWS flexible reserved instances with relation to schedules? Recall that the allocation of RIs to instances is done by AWS each second within a clock-hour. Each reservation is consumed by instances in its family until all 3600 seconds have been allocated. You do not necessarily have to keep an instance up for the whole hour to use the reservation. You can still consume the whole RI, even if you are starting and stopping instances by schedule or within an auto-scaling group over the course of an hour.
Something so cool cannot be without limitations and gotchas. Here are a few we’ve noticed:
Instance size flexibility is ONLY available for certain instance platforms.
For AWS EC2 reserved instances, only open-license linux instances support flexible RIs. It is NOT APPLICABLE to any flavor of Windows or other licensed software and OS.
For AWS RDS reserved instances, instance size flexibility is available for MySQL, MariaDB, PostgreSQL, and Amazon Aurora database engines as well as the “Bring your own license” (BYOL) edition of the Oracle. [That said: it is not clear as of this writing if the recent RDS per-second billing change is also applied to RDS instance size flexibility. The billing pages still state that RDS RIs are allocated to instances on a per-hour basis.]
Flexibility is only available within the same instance family
Flexibility is only available for Regional RIs
How does AWS Reserved Instance Pricing Work?
As usual, there are a number of different decisions that need to be made before this question can be answered. AWS RIs are available with two different levels of flexibility and several different terms of purchase.
In terms of flexibility, RIs can either be purchased as “standard” or “convertible.”
AWS Convertible Reserved Instances – allow changing the assigned availability zone, instance size/families, operating system, tenancy, and networking type. There is no fee for changing the reservation attributes, but you can only convert the RI into a new set of attributes with equal or greater cost than the original. If the cost is greater, you will have to pay the difference.
Regional vs. Availability Zone assignment scope. Regional scope offers a lot more flexibility for where your instances can reside while still leveraging RI pricing. Availability Zone scope has the bonus of a guaranteed capacity reservation (though, like RI pricing, capacity reservation cannot be assigned to a specific instance).
For open-license Linux, instance size flexibility, as described earlier.
There are a few options for terms of purchase that affect AWS RI pricing. RIs can be purchased for 1 or 3-year terms, and with no upfront, partial upfront, or all upfront payment available for each.
To get a better idea of the difference in the amount you’ll end up paying with each purchasing option, let’s take a look at some pricing scenarios for the general purpose m5.large instance in us-east-1 (US Virginia). When you look at these on the AWS RI price list, they are usually grouped by year terms and standard vs. convertible. Since you can already see it that way on AWS, and because time is the greatest unknown, I am going to give a bit of a different view, keeping the years together on the same comparison chart.
One-Year Term RIs
To benefit from the discount provided by a reservation while keeping contract terms to a minimum, look at the 1-year RIs:
You can see from this that within the Convertible vs. Standard tiers, there is not a lot of difference between the upfront cost payment options. Your upfront cash decision here can depend on your accounting process, perhaps accounting for the difference between CapEx and OpEx (Capital Expenditures and Operating Expenditures), or based on your current and prospective cash flow. The pricing between the Convertible vs. Standard options are so similar as to make you seriously consider if the benefit of flexibility in the AWS Reserved Instances convertible option outweighs the minor cost savings.
Three-Year Term RIs
If are confident of your three-year usage plans, look at the 3-year RIs, shown here as the cost per year:
There is a bit more visible progression between the options here, and the cost savings difference between the 1-year graph and the 3-year graph are clearly seen. Still, the 1-year vs. 3-year decision may again come down to accounting practices.
Note that these graphs are just for one instance type in one location in about the middle of the overall performance pack. They do not express a true profile of all instance types/families in all locations, and you should do your own comparison before buying any RIs. That said….
AWS Reserved Instances vs. On Demand
FINALLY getting into the core question. Is it better to shut an instance down or buy a reserved instance? Let’s do the math and compare AWS On Demand vs. Reserved, with on/off scheduling applied to the On Demand option. Given all the different pricing options it can be a bit difficult to decide how to compare these. Let’s go with the no-upfront RI options and see where the RIs break even with scheduling.
Since the hours might be judge at this scale, here are the break-even hours in a table (hours rounded-up):
So what do these hours mean?
By way of comparison, here are a few common schedules and their hours in ParkMyCloud (with weeks converted to months on the basis of 52 weeks/12 months = 4.33 weeks/month):
Running 8 AM – 5 PM, Weekdays = 195 hours/month (nominally a 73% savings)
Of the above, 7 AM – 7 PM Weekdays is the second most popular schedule in our entire system, and at 260 hours, easily is more cost-effective than the least expensive RI.
In that final schedule above, you need to run 16 hours per day, Monday-Friday before a 3-year RI starts to look like a better deal. If you have other matching instances on another schedule in that same region/AZ, you could then buy the RI anyway, and save even more money.
Scheduled Reserved Instances
“But wait!” you say… “There are these things called Scheduled Reserved Instances – would they not offer me the best of both worlds?” Maybe, but note that to support Scheduled RIs, AWS has essentially set aside hardware for use as Scheduled RIs – this is a finite set of dedicated resources. On paper, a Scheduled RI can definitely save you a bit more money, but let’s look at the limitations.
Instances intended to consume a Scheduled Reservation must be launched during their scheduled time periods using a launch configuration that matches the reservation. Let’s break that down further:
They are launched with “a launch configuration” and terminated by EC2 three minutes before the end of the schedule window. You cannot stop/start/suspend them, and so they cannot maintain state internally unless you do some EBS volume tweaks after launch.
You cannot launch a scheduled RI outside of its scheduled window. If you try, that instance will not use the Reservation, as you would not expect it to magically jump over onto the dedicated hardware.
Only three regions and only a few older generation instances families are supported.
Limited quantities are available (as of this writing, a search for an m4.large in us-east-1 with a Monday-Friday 7 AM – 7 PM scheduled listed only two reservations being available).
There is a minimum reservation size of 1,200 hours/year, 100 hours/month, 24 hours/week, or 4 hours/day. (So you are not going to be able to use a Scheduled RI to run your database backup server for just a couple hours on Sunday mornings [I just tried…dang it.])
Scheduled RI purchases cannot be cancelled, modified or sold on the RI Marketplace. No buyer’s remorse allowed here…
And finally… AWS describes the cost savings of Scheduled RIs over on-demand as being in the 5-10% range. Again – you have to be really sure this workload is going to be needed on this schedule, and the workload is fully utilized. If you find this server is ever idle or under-utilized, you may have lost an opportunity to save 50% or more by simply scheduling it with ParkMyCloud and then rightsizing it.
When launched in 2016, Scheduled RIs were only available in “US East (N. Virginia), US West (Oregon), and Europe (Ireland) regions, with support for the C3, C4, M4, and R3 instance types.” Given that this has not changed, I am guessing the feature has not taken off as AWS had hoped. That said, if you have something that needs to run for 4 hours per day, daily, and can use an older instance family in a supported region…go for it! This may also be a good place to leverage AWS Spot instance types.
Should You Buy Reserved Instances?
Deciding between different RI options starts with knowledge of how stable your usage is going to be in the coming years. Most organizations have a good understanding of at least a baseline level of usage, and some actually construct portfolios of reserved instance purchases, much like how you might balance a stock portfolio. For example, 3-year Standard Reserved Instances are for those applications that are stable and unlikely to change. Balance those with some 3-year Convertible Reserved Instances to help save money in the longer term but allow for some flexibility in use. Use 1-year RIs to account for shorter-term usage volatility, with again maybe a balance between Standard and Convertible where needed for those loads that might shift over the short term.
Just like with stocks, such portfolios require active management, awareness of what is being used and what is coming in both the short and long term. Companies with these types of RI management typically have dedicated cloud cost management staff, though RI management itself does not need to be a full-time job. One of our larger customers tells us they do a quarterly review of their RI portfolio, starting with using ParkMyCloud to schedule any instances they can, and then rebalancing their RIs and investing in more as needed. This is a best practice for any size company.
For production workloads that run 24×7 long-term, you REALLY should be buying RIs. For production workloads with an unknown future, or for non-production workloads (dev, test, QA, training, etc.), the answer is “probably not”. Be careful though, as often RIs are seen as a quick fix to save 30-50% on the cloud bill, but then other ways are found to save even more, and you end up with underutilized RIs. Before you buy a Standard RI, make sure you have evaluated your resources for underutilization and overprovisioning. Also consider the following cost-saving options:
Choose smaller instance sizes – each size down can save 50%. Use ParkMyCloud Rightsizing to first make sure your resources are appropriately sized for their load before committing to an RI purchase.
For open-license Linux instances, buy RIs for smaller instance types in the same instance family in order to leverage instance size flexibility (allows the RIs to more easily be allocated against other resources, even if they are running for short periods of time)
Use Spot Instances and Autoscaling when appropriate for short-term/volatile workloads.
Schedule on/off times for on-demand instances. Use ParkMyCloud SmartParking to automatically create schedules for when the resources are not being used, while still giving your staff the flexibility to easily restart them if needed outside the normal hours. Even a generous 7 AM – 7 PM workday schedule will immediately save 65%!
The worst thing one can do is…nothing. Set aside some time each quarter to review EC2 and RDS instance utilization. Rightsize and schedule what you can – try a free trial of ParkMyCloud to see how we can help you with that. After that, anything left running 24×7 is a candidate for an RI. If you are risk-averse or time-crunched, stick with 1-year convertible RIs to save at least 36% on at least some of your resources. Then take all that money you saved and put it into other things that will bring greater value to your business.
As an enterprise or organization grows in size, the benefits of SSO grow along with it. Some of these benefits are easy to see, but there are other things that come up as side-effects that might just become your favorite features. If you’re on the fence about going all-in on Single Sign-On, then see if anything here might push you over the edge.
1. Multi-factor Authentication
One of the best ways to secure a user’s account is to make the account not strictly based on a password. Passwords can be hacked, guessed, reused, or written down on a sticky note on the user’s monitor. A huge benefit of SSO is the ease of adding MFA security to the SSO login. By adding a second factor, which is typically a constantly-rotating number or token, you vastly increase the security of the account by eliminating the immediate access of a hacked password. Some organizations even choose to add a third factor, which is typically something you are (like a fingerprint or eye scan) for physical access to a location. Speaking of passwords…
2. Increased Password Complexity
Forcing users to go through an SSO login instead of remembering passwords for each individual application or website means they are much more open to forming complex passwords that rotate frequently. A big complaint about passwords is having to remember a bunch of them without reusing them, so a limitation on the number of passwords means that one password can be much stronger.
3. Easier User Account Deployment
This one might seem obvious to some, but by using an SSO portal for all applications, user provisioning can be greatly accelerated and secured. The IT playbook can be codified within the SSO portal, so a new user in the accounting department can get immediate access to the same applications that the rest of the accounting department has access to. Now, when you get that inevitable surprise hire that no one told you about, you can make it happen and be the hero.
4. Easier User Account Deletion
On the flip side of #3, sometimes the playbook for removing users after they leave the company can be quite convoluted, and there’s always that nagging feeling that you’re forgetting to change a password or remove a login from somewhere. With SSO, you just have one account to disable, which means access is removed quickly and consistently. If your admins were using SSO for administrative access, it also means fewer password changes you have to make on your critical systems.
5. Consistent Audit Logging
Another one of the benefits of SSO is consistent audit logging. Funneling all of a user’s access through the same SSO login means that tracking that user’s activity is easier than ever. In financial and regulated industries, this is a crucial piece of the puzzle, as you can make guarantees about what you are tracking. In the case of a user who is no longer employed by the enterprise, it can make it easier to have your monitoring tools look for such attempts at access (but you know they can’t get in, from point #4!).
6. Quickly Roll Out New Applications
Tell your IT staff that you need to roll out a new application to all users without SSO and you’ll hear groans starting in record time. However, with SSO, rolling out an application is a matter of a few clicks. This means you have plenty of options ranging from a slow rollout to select groups to start all the way to a full deployment within a matter of minutes. This flexibility can really help maximize your user’s productivity, and will make your IT staff happy to put services into play.
7. Simplify the User Experience
If you use a lot of SaaS applications or web apps that require remembering a URL, you’re just asking for your users to need reminders of how to get into them. With an SSO portal, you can make all services and websites show up as clickable items, so users don’t need to remember the quirky spelling of that tool you bought yesterday. Users will love having everything in one place, and you’ll love not having to type anything anymore.
8. Empower Your Users
Speaking of SaaS applications, one of the main blockers for deploying an application to a wider audience is the up-front setup time and effort, which leads to IT and Operations shouldering the load of the work (since they have the access). SSO can accelerate that deployment, which means the users have more power and can directly access the tools they need. Take an example of ParkMyCloud, where instead of users asking IT to turn on their virtual machines and databases, the users can log directly into the ParkMyCloud portal (with limited access) and control the costs of their cloud environments. Users feel empowered, and IT feels relieved.
Don’t Wait To Use SSO
Whether you’ve already got something in place that you’re not fully utilizing, or you’re exploring different providers, the benefits of SSO are numerous. Small companies can quickly make use of single sign-on, while large enterprises might consider it a must-have. Either way, know that your staff and user base will love having it as their main access portal!