Did you miss a session from the Future of Work Summit? Head over to our Future of Work Summit on-demand library to stream.
This article was contributed by Aran Khanna, CEO of Archera
Anyone managing their team’s cloud services faces the gargantuan task of parsing through all hosting and purchasing options to find the right ones for their projects, products, and services. Purchasing one, three, or five-year commitments for your applications, such as AWS Savings Plans and Reserved Instances (RI), offers teams significant cost reductions with the tradeoff of getting locked-in with the services covered for the term length. The cost-saving benefits of these commitments are incredibly appealing, with discounts of up to 72% off on-demand pricing, but managing cloud service savings can be challenging. You can also risk wasting money if you don’t end up using or needing as much of the resource through your term length, which means commitment selection also requires balancing a need for flexibility with savings.
To illustrate the complexity and scope of this task, just look at AWS EC2 instances. There are close to 100,000 EC2 instance types that can be used to host your application, and for each of those there are over 36 different commitment types that can be applied to them. That’s just in EC2 alone (not to mention other hosting options like serverless). Now imagine adding other managed services from AWS, and from other cloud providers such as GCP and Azure, with their own unique options and commitment structures.
Selecting the right infrastructure and subsequent commitments can be incredibly beneficial to the bottom line. It can take a company’s unit economics from good to great or increase margins for low margin businesses, while still leaving engineering teams the flexibility to access the best resources to innovate their product. Many teams, however, miss out on opportunities for savings or generate waste because they did not consider certain elements of cloud service usage scenarios, contracts, or data when planning.
1. Your AWS bill will not give insights into the cost of goods sold
Making future commitments to cloud services requires thoroughly understanding how services are affecting profit and loss calculations for a business. Oftentimes, people rely on their AWS bill to find this information, but there are key pieces of information that are missing. The bill is a roll-up of costs and not highly granular, and does not enable you to allocate costs (and specifically the savings from centralized commitments) to teams and projects. Furthermore, there are many miscellaneous costs associated with AWS, such as Premium Support, that are unrelated to your cost of goods sold.
You can get a higher level of granularity in your data through properly tagging resources. Tag management is key to proper cost attribution but does require enforcing tag hygiene practices across teams and it still leaves you parsing costs apart in spreadsheets at the end of the month. Finding tools with auto-tagging as well as specific financial reporting will enable true visibility without burdening your team with additional work.
2. Historical data alone will not accurately forecast future utilization and costs or potential cloud service savings
Data on the historical usage of resources for a product or project is key to getting an understanding of the basic needs for your engineering and developer teams to plan and select commitments. However, it is often overlooked that past resource utilization will not always reflect future usage. Changes in business strategy, right-sizing or migration plans, and other external factors can lead to a drastic deviation from historical usage patterns. The net result is either over committing to resources and wasting money, or under-committing and missing savings opportunities.
To anticipate potential deviations from historical usage, consider modeling the impact of different scenarios on usage and costs. Scenario planning is a nuanced activity that takes place between engineering, finance, and operations teams. Inputs such as right-sizing, migration, re-architecting, new projects, business growth, and financial best practices need to supplement historical data in estimating future costs and cloud service savings and usage to avoid over or under-commitment to services. For instances that could have variable future usage, you can choose more flexible commitments with shorter term lengths that can be exchanged or resold on the AWS Marketplace.
3. High coverage does not mean quality coverage
Teams often strive for a high level of commitment coverage across their infrastructure but do not think about the percentage savings from that coverage. Frameworks, such as the FinOps Maturity Model, include commitment coverage as a metric to measure the maturity of an organization’s cloud financial operations. A higher percent coverage indicates higher maturity.
The issue with prioritizing coverage is that not all commitments provide the same level of discount. Many of the “safest” commitments with the highest flexibility actually provide less than one third the savings rate of a less flexible commitment. This can lead to situations where you have high coverage, but a low savings rate. You may actually be saving less than if you had lower coverage with a high savings rate. Companies that are not in a state of growth can actually become stuck in a position where they have very little flexibility to increase their savings rate and must simply wait for the contract terms to expire. Commitment coverage is a metric that delivers more value when considered with percentage savings to get an understanding of the net cost reduction your commitment strategy is driving. This is particularly important when you model different purchasing strategies to see whether higher coverage does provide the most savings.
4. Savings plans alone are not enough to maximize cloud service savings
Many companies achieve a high level of coverage using AWS Savings Plans because of their ease of use relative to RIs. Savings Plans allow a higher degree of flexibility than RIs because you can switch regions and coverage is immediately applied to any changes in instances. The flexibility provided by RIs still requires manual labor to exchange CRIs or resell Standard RIs.
While it’s undeniable, they are easier to use for some organizations, the issue lies in the fact that their high flexibility comes with a very low savings rate relative to RIs. When Savings Plans are used for workloads that will not leave the region they are hosted in (which is often the majority of workloads in a customer’s account), there is a lot of money that can be left on the table that other strategies such as RIs could have saved. Because the Savings Plan purchase is a one-way door, it becomes very hard to update the strategy to increase savings rates.
If you are trying to maximize your savings, you should consider a blend of different commitment types that also include Standard RIs in addition to Savings Plans. Furthermore, you should vary the term lengths of your contracts. Blend low-savings-rate one-year contracts with high-savings-rate three-year contracts to balance flexibility and savings against your planned resource usage.
5. Vary upfront spend amounts across commitments
Commitments can be purchased with all, partial, or no upfront payment, each with a varying discount rate depending on the resource being covered. Typically, all upfront payment provides the highest discount and no upfront payment provides the lowest. Using only one level of upfront payment across various commitments is often the approach taken and recommended by vendors like AWS. There are limitations to this approach. An all upfront approach for all of your resources can lead to upfront money being spent on commitments with very little incremental savings lift when compared to the no upfront and partial upfront version of those commitments. On the other hand, no upfront spending significantly reduces savings and can leave a lot of potentially great deals on the table, depending on the expected return an organization has for the upfront money it spends.
In addition to blending different commitment types and contract term lengths, using a combination of all, no and partial upfront spending for your commitments can also help with increasing cloud services savings while retaining flexibility (in this case financial flexibility). The combination of different upfront spends should yield incremental savings that match or exceed your organization’s cost of capital. This acts as a good check to make sure budgets are not entirely used inefficiently.
Aran Khanna is the CEO of Archera
DataDecisionMakers
Welcome to the VentureBeat community!
DataDecisionMakers is where experts, including the technical people doing data work, can share data-related insights and innovation.
If you want to read about cutting-edge ideas and up-to-date information, best practices, and the future of data and data tech, join us at DataDecisionMakers.
You might even consider contributing an article of your own!
Read More From DataDecisionMakers
Source: Read Full Article