At CloudyCon 2019, Keith Jarrett, Global Lead of Cloud Financial Management with AWS, presented the Principles of FinOps. Formulated by the FinOps Foundation and validated by AWS, these six principles are the guiding light behind every FinOps practice. Keep them in mind while you build out FinOps in your organization and you give yourself the best chance of success.
FinOps is a vendor-agnostic operating model, designed to work with all cloud vendors (and multi-cloud infrastructures). That being said, the principles and goals of FinOps mesh perfectly with the AWS Well-Architected Framework. Let’s take a little time to dig into those principles and then see how they work in practical application with AWS.
FinOps is about cultural change and breaking down the silos between teams that, historically, haven’t worked together. In order to effective, your FinOps practice needs to promote collaborative, productive conversations and actions.
FinOps should always consider the business value of the cloud with the goal of making completely informed decisions.
If you’re responsible for cloud usage, then you’re responsible for cloud costs. Accountability should be spread to the edges of your organization, all the way to individual engineers and their teams.
Your teams need to be able to quickly see data as soon as possible so they can make real-time decisions about their cloud usage and spend — instead of waiting until it’s weeks after the fact.
A central FinOps team drives best practices through standardization, education, and cheerleading. That same team can centralize rate optimizations to take full advantage of them, while empowering the rest of the team to maximize usage optimization.
Instead of basing capacity purchases off possible future demand, base your rightsizing, volume discounts, and RI/CUD purchases off your actual usage data. The emphasis becomes making the most out of the services and resources you’re currently using.
The key thing to remember is that FinOps isn’t about saving money — it’s about making money. By incorporating all of these principles into your FinOps practice, you’ll build a culture and scalable systems that make the most out of your AWS investment.
To give you a better idea of how FinOps meshes with AWS, let’s dig into each of the principles in terms of AWS and give you some ideas that will help kickstart your FinOps practice.
FinOps brings together technology, finance, and business leadership teams, so make sure this is reflected in your taxonomies and organizational structure. Involve people from all three teams when you’re figuring out your systems for tagging and account structures. The goal should be to have your linked accounts and tags work together to fit technology’s team splits, finance’s accounting divides, and leadership’s organization charts.
By the end, everything should be tagged and organized so all three teams can easily get the data they need from the AWS CUR file. And once everyone has the right data, you can spend your time working together to reach your goals instead of arguing over metrics, allocation, or structure.
The AWS products are designed to help your organization build a better, faster, stronger infrastructure on the cloud. Embrace that when you make your cloud financial decisions. Everything you do should be done to get as much value as possible from your cloud — and sometimes that will mean increasing spending.
For example, refactoring an application for ECS or Lambda may require a substantial investment of developer time and increase rates over simple EC2 compute. But if doing so increases the speed and stability your applications enough to increase customer use and retention without substantially increasing your per customer charges, then there’s a clear business value to the increased cloud spend.
The key is to make sure that you don’t get so focused on reducing your monthly AWS invoice that you miss out on opportunities provided by the cloud.
AWS makes it easy for developers (and automation) to spin up resources when needed. After all, the flexibility and scalability of cloud is one of its biggest benefits. It also means that procurement is diversified across your organization, a far cry from the centralized procurement of on-prem infrastructure.
To avoid runaway costs and overgrown infrastructure, make sure everyone who uses the cloud fully owns their usage — for good or bad. If a team leaves an error that causes a massive spike in EC2 usage, they need to be responsible for that cost. Likewise, if a team finds a way to lower their spend by 30% with the same performance by switching from m5 to t3 instances, they need to be lauded, even if it’s just by letting them keep that budget for trying something new.
The CUR file is updated with your AWS costs and usage several times a day, which means there’s no excuse for waiting to tell teams their costs and usage until you get your monthly invoice. Your teams should get access to their cost and usage data as soon as possible so they can take any necessary action.
On a cost savings measure, this could be as simple as spending anomaly detection. An update might remove the command to spin down unused EC2 instances, resulting in a massive spike of m5 usage as they’re constantly spun up and never turned off. If you catch this within 24 hours, the spending spike will be minimal, but if more m5s are spun up every day and left on, you’re looking at a spike that will burn through your reservations and cause massive charges at On-Demand rates.
At the same time, those reports are essential for improving efficiency. The sooner they get the data of actual CPU and memory usage, the sooner a team will be able to adjust their resource requests and rightsize their spend. After all, the difference between the On-Demand rate of a t3.large and an m5.large might be only $0.0128, but with 10,000 instances running per day over 4 weeks (28 days), that adds up to $86,016 in charges within a single month that could be avoided and used for other projects. And the only way your team will know whether that’s a viable adjustment is by having timely access to cost and usage data.
AWS is set up to maximize the use of cost optimization tools like Reserved Instances and Savings Plans across an entire consolidated account. Additionally, many organizations with larger usage can work with AWS to develop custom discounts and rates. These kind of cost optimizations are best done on an organization-wide level, and a centralized FinOps team is best equipped to maximize them.
But FinOps goes beyond simple cost optimization. If you want to get the most out of your FinOps practice, then you need to create a company-wide culture of FinOps. A centralized FinOps team then becomes your rallying point, developing best practices and standardization, spearheading education efforts, and cheering on those who excel at FinOps.
The goal should be for that team to become the fulcrum around which all FinOps activities pivot. Tagging strategies should come from them, as well as unified tool or governance decisions. They should act as a bridge between the various teams, enabling them to get the most from their cloud.
There are a lot of different ways a single resource can be billed. Take an m5.large. It could be billed at the rate for On-Demand, Spot, RIs, or Savings Plans. RIs and Saving Plans pricing can be further broken down into whether it’s paid all-upfront, partial-upfront, or no-upfront, then by whether it’s a one-year or three-year commitment. With FinOps, you should always make sure you’re using the best pricing model to fit your usage so you can be as cost efficient as possible.
The key here is to base all of your decisions on actual usage. With on-prem, financial management decisions were based on static predictions and then optimizing consumption with current investments of resources and hardware. AWS and the cloud throw that out the window. Teams are able to constantly vary the size of their infrastructure to fit their needs, fueling innovation and brining releases to market faster.
Your financial management decisions need to operate on the same level as your cloud infrastructure. Use actual, accurate, and current data for your optimization purchases, forecasts, and rightsizing instead of static projections. A lot of this will come down to making sure your team has the right tools. For example, Apptio Cloudability integrates with Amazon Cloudwatch to give you recommendations based on near-real-time cost and usage data — including actual CPU, network, memory, and disk utilization.
Ready to kick off FinOps for AWS in your company? Start by learning what you can of the FinOps cloud operating model:
FinOps is a combination of people, process, and tools. The above resources will help you learn the people and process you need to build out in your organization. When it comes to tools, Apptio Cloudability will help you implement and scale those processes. Developed along the best practices that became FinOps, it’s the ultimate platform for enabling your FinOps practice.
Sign up for a free trial to see for yourself!