AWS FinOps Simplified E-Book

Peter Chung

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 414

Veröffentlichungsjahr: 2022

Beschreibung

Much like how DevOps is a combination of cultural philosophies, practices, and tools that advocate a collaborative working relationship between development and IT operations, FinOps encourages the same collaboration between technology and finance team, making it key relationship to establish and maintain for any thriving business.
This book will help you understand how organizations with a mature FinOps practice can decentralize cost ownership to developer teams and encourage cross-functional collaboration between business, finance, and technology, enabling speed, innovation, and business growth. You’ll focus on structuring your organization to form the right FinOps team, including a Cloud Center of Excellence, and learn how to implement practical cost savings measures with AWS tools to optimize costs in both the short as well as long term.
By the end of this cloud FinOps book, you’ll be ready to implement a successful Cloud FinOps practice for your organization to get the best value from the AWS cloud for your workloads.

Leseprobe

AWS FinOps Simplified

Eliminate cloud waste through practical FinOps

Peter Chung

BIRMINGHAM—MUMBAI

AWS FinOps Simplified

Copyright © 2022 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Rahul Nair

Publishing Product Manager: Yashashree Hardikar

Senior Editor: Tanya D’cruz

Technical Editor: Arjun Varma

Copy Editor: Safis Editing

Project Coordinator: Shagun Saini and Ashwin Kharwa

Proofreader: Safis Editing

Indexer: Hemangini Bari

Production Designer: Shankar Kalbhor

Marketing Coordinator: Nimisha Dua

First published: October 2022

Production reference: 1220922

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80324-723-6

www.packt.com

To my mother and father, for their sacrifices and for exemplifying the value of diligence. To Jennifer for being my loving partner and encouragement, and to Jeremy and Ezra our stars.

– Peter Chung

Contributors

About the author

Peter Chung enjoys seeing companies leverage new technologies such as the cloud to experience digital transformation. Before his current role as a Senior Solutions Architect at Amazon Web Services, Inc. (AWS), Peter helped customers save on their AWS bill as a Customer Optimization Specialist. Prior to AWS, Peter worked in numerous New York City agencies to help the city tackle complex challenges such as hurricane recovery efforts, responding to street homeless populations, and improving shelter conditions. He holds all AWS certifications, two Google Cloud certifications, and is, of course, FinOps certified.

About the reviewer

With more than 20 years of working in technology, Felipe Campos, also known as KiKo, started his career as a developer and then migrated into the cloud infrastructure area. When he began working in the FinOps area, he finally managed to bring together all of his passions, such as development, cloud architecture, and evangelization in tech. Always very curious, Felipe participates in several communities, contributing his knowledge in articles, lectures, events, and even long chats with friends!

Surely my journey alone would have ended at the first steps, had it not been for the support I’ve received from the people I’ve known in the tech community, and of course, my beautiful family and friends who have been extremely important in defining who I am.

Table of Contents

Preface

1

FinOps Foundation

Changing with the cloud

Rethinking procurement

Defining FinOps

FinOps principles

What FinOps is…

A FinOps approach

Summary

Further readings

Part 1: Managing Your AWS Inventory

2

Establishing the Right Account Structure

Technical requirements

Establishing an operating model

Fully siloed models

Separated application development with centralized FinOps

Decentralized FinOps with autonomous teams

The optimal model

Creating a multi-account environment

Structuring your AWS accounts

Managing accounts with AWS Organizations

Managing your AWS accounts with AWS Control Tower

Understanding billing with AWS Organizations

Summary

Further reading

3

Managing Inventory

Technical requirements

Tracking your AWS resources

A brief primer on tags

Tracking inventory with AWS Cost Explorer

Tracking inventory with AWS CUR

Tracking Amazon EC2 inventory with EC2 Global View

Tracking tagged resources with AWS Resource Groups

Tracking inventory with AWS Config

Establishing a tagging strategy

Grouping tags with AWS Cost Categories

Summary

Further reading

4

Planning and Metrics Tracking

Technical requirements

Cost monitoring on AWS

Cost monitoring with Cost Explorer

Cost monitoring with AWS analytics services

Cost reporting with QuickSight

Cost monitoring with Amazon CloudWatch

Budgeting on AWS

AWS budgeting methods

Setting up AWS Cost Anomaly Detection

Anomaly detection with CloudWatch

Summary

Further reading

5

Governing Cost and Usage

Technical requirements

A quick primer on IAM

Access to member accounts in Cost Explorer

Governance with SCP

Implementing tagging policies

Tag governance with AWS Config

Governance with Service Catalog

Auditing with CloudTrail

Summary

Further reading

Part 2: Optimizing Your AWS Resources

6

Optimizing Compute

Technical requirements

Leveraging steady state discounts

How RIs work

Understanding RI performance

Modifying RIs

Exchanging reserved instances

Improving utilization with SPs

Knowing when to buy more SPs

Maximizing savings for flexible workloads

Right sizing compute

Optimizing AWS Lambda

Summary

Further reading

7

Optimizing Storage

Technical requirements

Optimizing object storage

Establishing clean S3 hygiene

Optimizing with S3 storage classes

Managing S3 at scale

Optimizing databases

RDS-reserved instances

Optimizing OpenSearch clusters

Optimizing DynamoDB

Optimizing block and file storage

Optimizing EBS

Optimizing EBS snapshots

Optimizing EFS

Summary

Further reading

8

Optimizing Networking

Technical requirements

Understanding data transfer scenarios

Data transfer inside an AWS AZ

Data transfer inside an AWS Region

Data transfer across AWS Regions

Data transfer from AWS to on-premises environments

Managing data transfer costs

Optimizing with Amazon CloudFront

Tips for minimizing data transfer costs

Summary

Further reading

9

Optimizing Cloud-Native Environments

Technical requirements

Maximizing efficiency with AWS Auto Scaling

What is auto scaling?

AWS Auto Scaling versus Amazon EC2 Auto Scaling

When to use AWS Auto Scaling

Optimizing analytics

Optimizing data ingestion and preparation

Optimizing ML

Understanding an ML workflow

Optimizing model training and tuning

Optimizing model deployment

Summary

Further reading

Part 3: Operationalizing FinOps

10

Data-Driven FinOps

Establishing a centralized function

Reasons for a centralized FinOps function

Personas for a centralized FinOps function

Creating an effective metrics strategy

What is metrics strategy governance?

Applying a metric governance framework

Metrics strategy persona responsibilities

Defining the right metrics

Five considerations for metrics development

Cloud metric examples

Leveraging the CUR

Accessing the CUR in Amazon S3

Integrating AWS Glue with the CUR

Querying CUR with Amazon Athena

Visualizing CUR data with Amazon QuickSight

Creating metrics with QuickSight

Summary

Further reading

11

Driving FinOps Autonomously

Creating a self-service FinOps portal

Understanding AWS CloudFormation

Getting to know AWS’ Enterprise Dashboards

Setting up the dashboards

Using the Cloud Intelligence Dashboard

Forecasting spending using ML-driven insights

Forecasting cost and usage with Amazon Forecast

Automating cost optimization within operations

Integrating Trusted Advisor with other AWS services

Summary

Further reading

12

Management Functions

Leveraging AWS Solutions

Instance Scheduler in AWS Solutions

Cost Optimizer for WorkSpaces in AWS Solutions

Conducting billing and administrative tasks

Simplifying billing with AWS Billing Conductor

Managing your AWS Free Tier usage

Creating purchase orders with AWS Billing

Engaging with enterprise discount programs

Scaling FinOps for your organization

EventStorming, FinOps style

Training for FinOps

Summary

Further reading

Index

Other Books You May Enjoy

1

FinOps Foundation

Before we embark on a FinOps journey, we must level-set expectations and definitions for us to stay on the right path. We’ll begin by justifying the need for FinOps. Operating in the cloud warrants a mind shift from traditional IT procurement practices. For organizations to truly benefit from what the cloud offers, they must align their line of thinking with the variable nature of paying for cloud resources.

We will define what FinOps is and its principles. We’ll use these definitions as set boundaries as we dive deeper into the execution and implications of FinOps on AWS.

In this chapter, we’re going to cover the following main topics:

Changing with the cloudRethinking procurementDefining FinOps

Changing with the cloud

Cloud cost management is hard. A dynamic cloud environment, autonomous teams provisioning IT resources at will, and even changing prices of the resources themselves all complicate cloud cost management. Layer a multi-cloud strategy on top of that and the complexity increases even more. But how come we see companies such as Lyft cutting costs by 40% in 6 months, Etsy achieving a 42% reduction in computing costs, and MicroStrategy optimizing by 30%? Surely cost management appears to be possible.

Cloud cost management is indeed hard but, even more fundamentally, change management is hard. We get so used to the way of doing things. We set up processes, reports, approval mechanisms, and training sessions, then something changes that forces us to re-evaluate and redeploy all our efforts. We not only have to help people understand why things are changing, but we must help people change their behavior to adapt to what’s new.

Cloud cost management is a major change to how organizations think about IT resource procurement. It is a change in the operational processes involving software development, and it is a change in how teams gauge metrics and democratize resource ownership. Successful cloud cost management depends on successful organizational and cultural changes. It requires a mind shift that aligns IT procurement thinking to the variable nature of the cloud.

Cloud cost management calls for increased awareness of how efficiently you use your cloud resources. The on-demand nature of the cloud is convenient in the sense that you can obtain resources at will, but it also requires discipline in choosing the right amount of resources to get the job done.

The business value of cloud cost management is no different from the business value of optimizing any other domain of your business. We can take operation optimization as an example. When you optimize your operations, you find ways to minimize your operational costs while maximizing your operational outputs. With process optimization, you identify areas of improvement in a defined process, implement those changes, then measure the impact of those changes on some business-centric performance indicators. All these efforts are meant to help your business lower costs and increase profitability. Moreover, to ensure that your efforts are having an impact on your business, you define Key Performance Indicators (KPIs) to validate the outcomes.

The practice of cloud cost management is the application of these optimization efforts in different areas of the business and the use of cloud IT resources. You apply the same discipline of minimizing cloud costs while maximizing the value of cloud resources. Equally important is the measuring of KPIs for intended business outcomes; having data to validate your cloud cost optimization efforts proves your efforts have business value.

Let’s unpack a bit more of how we must change the way we think about our use of cloud IT resources to move toward these efficiency gains.

Rethinking procurement

Imagine you grab lunch at a local eatery that provides several culinary options. You can either purchase option A, a sandwich/soup combo at a fixed price, or you can choose option B, the buffet, in a sense, but where you pay based on weight. Given that the buffet has a myriad of food items that you enjoy, you choose to go with the latter. When you select your options, you are sensitive to what and how much you put in the to-go box. On the other hand, if you went with the sandwich/soup combo, there’s less mindful calculation required because you know exactly how much you’re paying. This juvenile example illustrates the mind shift required to go from option A to B where cloud spending is more like the latter.

Those with cloud cost management success stories have already adopted this new way of thinking and dismissed traditional IT procurement processes. In the past (and even in some cases today), the relationship between technology and finance teams was largely transactional. When developers needed resources, a centralized finance procurement team found the appropriate vendor and approved the request. Oftentimes these approvals took weeks, hampering technology teams’ efficiency. Moreover, developers had to wait for the hardware to arrive even after approvals, further extending this waiting game.

With the cloud, things are different. Engineering teams can now procure the necessary IT resources at the click of a button, or even an entire data center through code. The on-demand nature of the cloud enables teams to innovate quickly because not only are they able to obtain resources within minutes, but they can also test and experiment freely without the financial burden of keeping those resources long-term. Teams can easily spin up resources and just as easily remove them when they are done, and not pay for them. Organizations avoid the disadvantages of lengthy procurement cycles and wasted IT resources, especially when they sit idle for a long period of the year.

These all sound like good things to have. But they also sound like they can lead organizations on the wrong path. In fact, it’s quite easy to indulge in cloud resources at any moment given the on-demand nature of the cloud, while ignoring the financial consequences, much like piling food on your lunch platter at the local eatery. We will dive into the various strategies around cost control, cost management, and value-driven optimization strategies on AWS throughout this book. But let’s first level-set a few things.

Important note

Cost throughout this book refers specifically to financial costs. There are other costs to consider such as labor costs, operational costs, and the cost of technical debt. I will explicitly indicate the type of cost when appropriate when I’m not referring to financial costs.

We’ve established that change is hard but inevitable in today’s technological landscape. Modern computer system architectures make teams rethink how they design network communications, databases, and data processing within a cloud computing framework. This also requires teams to rethink how they procure these resources to support their business domains. Although not entirely obsolete, traditional means of procuring computer hardware and software debilitate an organization’s need to move quickly. This requires a shift in how teams think and operate financial practices to be more in line with the methods adopted by agile software delivery teams. This is where FinOps comes into the picture.

Defining FinOps

To put FinOps into context, let’s look at its derivation, DevOps. The industry often describes DevOps as a set of practices that combines software development (Dev) and IT operations (Ops). It involves people, processes, and tools that work together in a collaborative culture to accelerate an organization’s ability to deliver services to customers. DevOps isn’t just one tool, nor is it a one-time event. It’s a repeated and ever-evolving practice that serves to ultimately bring value to an organization. Indeed, if it doesn’t bring value to an organization, it is not something worth pursuing. At the same time, if it’s not bringing value, there might be a chance it’s being implemented incorrectly.

Similarly, FinOps is the merging of financial accountability and management of cloud resources with cloud operations. Much like how DevOps is a combination of cultural philosophies, practices, and tools that advocate a collaborative working relationship between development and IT operations, FinOps encourages the same collaboration between technology and finance teams as well as across lines of business. While DevOps increases an organization’s ability to deliver applications and services at high velocity, FinOps increases an organization’s visibility, cost efficiency, and profitability of cloud resources. Storment and Fuller succinctly define FinOps as the practice of bringing financial accountability to the variable spend model of cloud, enabling distributed teams to make business trade-offs between speed, cost, and quality. They aptly proceed to say that FinOps is not about saving money. FinOps is about making money and using your money in a more effective way.

The ultimate purpose of FinOps is to bring business value to your organization by reducing cloud waste. Simply decreasing cloud costs by purchasing AWS Reserved Instances (RIs) or using optimal Amazon S3 storage classes is narrow in scope (we will discuss these practices in later chapters). These practices may bring immediate benefits but may fail to bring lasting value if they aren’t implemented strategically without measurable metrics and meaningful KPIs.

For the remainder of this book, I’ll refer to the term FinOps to encompass the people, processes, and tools you use toward your path of eliminating waste in using AWS cloud resources.

Important note

Cloud providers use their own terms when referring to cloud cost management. For example, AWS uses Cloud Financial Management, Azure uses Cloud Cost Management, while Oracle uses Cost Management Cloud. In this book, FinOps refers to all these and more as they all mean to achieve the same goal.

FinOps is the framework within which teams can operate to ensure they are optimizing their use of cloud resources. Conversely, FinOps cannot apply to traditional IT procurement processes – you cannot operate and scale with agility if you are waiting for financial approval for hardware that will be arriving in 3 months. For FinOps to be successful, teams must accept cloud operating principles and expect to dynamically provision IT resources. Let’s take a closer look at these principles in the next section.

FinOps principles

An organization with a successful FinOps cadence involves personas from business, finance, and technology actively working as a cohesive team to embed cost management discipline within business domains. And (hopefully!) within your business domains, there exist domain experts. Domain experts are the folks who know the line of business they are working in very well. Whether they are product managers, developers, financial analysts, or architects, they have deep knowledge of the business domain in which they operate.

If you’re already familiar with Domain-Driven Design (DDD), you know how important it is in developing software. DDD is a software design approach that exists to not only help teams build high-quality software but software that meets core business objectives. Without DDD, you may have a scenario such as a developer engaging with a domain expert, but the collaboration is largely transactional. The developer builds software that’s based on a list of business requirements that is loosely interpreted rather than truly reflecting what the business needs. The result is a poor representation of the domain experts’ mental model and over time, this disconnect between software and the business domain increases.

DDD addresses this disconnect by aligning software to business value. Developers can easily get distracted by technology and technical solutions to business problems. By investing in developers’ knowledge of the business domain and creating a common language between domain experts and developers, software becomes more about the business rather than technology.

Within DDD, the domain is the problem space that a business occupies. The business operates within a particular domain. However, regardless of the existence of the business, the domain always exists. Then, a subdomain is a component of the main domain, but it focuses on a specific subset of the business. This usually manifests itself in the form of business departments such as sales, engineering, or finance.

A domain model is an abstraction of the domain in which a business operates. The properties of the domain that are most important to the business constitute the business’ domain model. Models oftentimes need to be changed as the domain changes and the business priorities change.

Finally, bounded contexts are the logical boundaries that include the inputs, outputs, events, requirements, data models, and processes. These bounded contexts are a property of the solution space and are, ideally, aligned to the subdomain.

I broach the topic of DDD because DDD’s good intentions apply to FinOps’ good intentions. FinOps requires a common language among all teams. One of DDD’s primary pillars is Ubiquitous Language. This is a shared team language among domain experts and developers. This Ubiquitous Language is not meant to be organization-wide and only applies within a bounded context of a business domain. To illustrate, a tomato in the bounded context of nutrition is considered a vegetable, whereas in the bounded context of botany, it is considered a fruit due to the presence of seeds (but let’s face it, it’s really a vegetable).

Different terms mean different things in different contexts so it’s important to have the right language within a FinOps context. It’s also nearly impossible to have an established global language within a larger enterprise. So, the best approach is to accept that differences will exist but when speaking within a FinOps context, the language is well-defined and clearly understood.

A common language is a property of a business’ communication structure. DDD aims to improve the efficiencies that come with organizing teams by function, which was traditionally how teams were organized when deploying software:

Sales teams would request engineering teams build something.Engineering teams would respond with an estimated deployment date of 8 weeks.Sales teams would outsource troubleshooting to support teams.Support teams would request the engineering teams fix a bug.

This transactional type of communication would not facilitate domain knowledge to be shared across the organization. It would, at times, prevent businesses from iterating and innovating quickly since teams and data were siloed with teams having to depend on other teams to make changes and meet customer demand.

Rather, DDD organizes teams into their respective bounded contexts. Teams operate within their own subdomains and make their data and interfaces to other teams through well-defined protocols and processes. Teams better understand how to communicate with each other since this is implied within the software architecture. I’m not saying FinOps is a bounded context in and of itself. What I am saying is that the discipline that comes with maintaining consistent, reliable, and defined communication channels for an organization practicing DDD is a helpful frame of reference when thinking about the communication channels necessary between a FinOps team and the various other teams within a business.

This common language is critical when deciding on going with application design A over B, even when A costs much more. Optimizing application A solely for the purpose of saving money but sacrificing its performance or availability, which leads to system downtime, which can crush revenue, hardly seems like a worthy trade-off. Even language around AWS-specific cost terms such as RI unblended cost, and Intelligent-Tiering can lead to confusion if teams don’t have a shared understanding of what they mean, and specifically how they impact the business.

Centralization of knowledge and oversight is key to ensuring that business domain knowledge doesn’t sit lazily within the minds of a select few. In FinOps, having a central team driving cost management policies and documenting knowledge helps with this knowledge transfer. In the cloud, this central team is often called a Cloud Center of Excellence (CCoE), composed of individuals from various lines of business. A CCoE drives cloud adoption for the business, instilling cloud best practices in the various teams. A FinOps team derived from, or as part of, this CCoE can drive the adoption of FinOps best practices across the organization, embed them as part of the software development cycle, and report on performance to continually find areas to reduce waste.

What FinOps is…

FinOps is using tools to eliminate waste, whether those are AWS-native tools, third-party solutions, or your own homegrown applications. These tools help you take inventory, track cost performance over time, identify outliers, and assist in automation to remove unexpected waste and maximize the efficiency of cloud resources. However, tools themselves are a means to an end. FinOps also involves education and enablement in using these tools and interpreting the results appropriately so that the tools themselves bring value to the business. We will see how to apply various AWS-native tools to reduce cloud waste.

FinOps is establishing and executing practices that encourage automation to optimize as quickly and as efficiently as possible. Rather than manually pulling RI recommendation reports every few months and determining which instances are worth purchasing upfront, FinOps, at its best, automates the process of gathering RI recommendations, interpreting the results, and communicating to the ones responsible, ranking the RIs by maximum value for the business. FinOps also re-evaluates its practices and iterates on them depending on the use case.

FinOps creates meaningful metrics that you can track to see how well you are achieving your goals. You may have business leaders that worry that “our cloud costs are increasing.” However, are increasing cloud costs necessarily a bad thing? What if for every dollar you spend on a cloud application, that application is bringing in 5 dollars? In that case, although your cloud costs are indeed increasing, the costs are nominal compared to the revenue generated. Although AWS itself is ultimately a technology, the cost of building on AWS becomes a justifiable business investment, not just a cost center. But you need to have metrics to prove this. FinOps not only involves these metrics but budgeting and planning so that you can track your cloud cost efficiency over time. The better you get at tracking metrics, the better you can prove your efficiency in reducing cloud waste.

A FinOps approach

You can define a successful FinOps approach broken up into four major practices: identify what you own, optimize resources that you need, plan and track spending, and execute policies that align with your financial goals. The diagram in Figure 1.1 presents these ideas but in no particular order.

Figure 1.1 – A FinOps approach to waste elimination

Everyone will have a different starting point because everyone’s cloud journey is unique. Some may be just starting out and won’t have any resources provisioned. Others may have already been using the cloud for years and thus have a huge inventory of cloud resources to manage. Moreover, some organizations may prefer methodological approaches and set budgets before approving any projects, whereas others may prefer to be iterative and adjust budgets as needed. Regardless of your preference, these are important practices that you can incorporate into your FinOps strategy. We’ll see how you can apply these practices on AWS.

Identifying what you own is knowing what resources are provisioned and will be provisioned. Imagine you are a company that sells toys online and in-store. You have warehouses storing your assets to ship to customers and deliver to physical stores. It’s likely you have an inventory of your assets so you know when to replenish when stock is low. It would be rather difficult to run your business if you didn’t know what you own! The same can be said of your cloud resources. It’s unlikely that you’ll have a successful FinOps strategy if you don’t know what you have.

Optimizing the resources that you need means maximizing the efficiency of what you elect to use. Naively, the best way to reduce costs in the cloud is to not use anything – if you pay for what you use, just use as little as possible. Although facetious, it holds some truth. Turning off resources when you don’t need them is a great way to eliminate waste (to know what you can turn off, you need to take inventory). Rightsizing resources, choosing the right pricing model, and leveraging the cloud’s elasticity are practical ways to optimize the resources that you do need.

Planning and tracking help you see whether you are actually moving toward the ultimate goal of eliminating waste. By setting budgets, you can anticipate what your costs will be on a daily, monthly, and yearly basis. Budgets and reports can help you establish a baseline for your cloud spending. Then you can use features such as anomaly detection to identify events that deviate from expectations. Metrics also inform leadership on how cloud spending is contributing to the business. From that point of view, cloud spending becomes more of an investment.

Executing involves scaling your FinOps practices, incorporating automation, and iterating on your practices as business needs change. It’s also important to standardize and communicate these practices to stakeholders, showing how these practices support business goals. Ideally, you want to automate as much as possible to ensure FinOps isn’t a blocker to agility and innovation.

The following chapters focus on each practice so you can apply them within your AWS accounts.

Important note

You can apply these practices to any public cloud platform, but this book’s focus is on AWS. The tools we use will be dependent on AWS-provided services. You can stay up to date with AWS tools on their Cloud Financial Management website.

We use a fictitious example throughout this book to demonstrate how an organization might apply FinOps to reduce cloud waste. We’ll follow VidyaGames in their journey to transform from an organization with little to no FinOps practices to an organization with a mature FinOps practice. Each chapter focuses on a particular FinOps practice and as we expound on each practice, we’ll see how VidyaGames applies the practice to its specific business domain.

VidyaGames’ cloud cost journey

VidyaGames is an online video game review website with a growing user base. The company’s core domain is a social media platform where registered users can share video game reviews, experiences, and photos. The company expects to build a live-streaming application and a vibrant online advertising space as two strategic business initiatives. Originally running on-premises in a data center, the company has migrated most of its applications to the cloud.

The business has been growing but so have its cloud costs. Initially, leadership wasn’t concerned with cloud costs. The agility, scalability, and availability of the cloud were reasons enough to justify the move to AWS. Fortunately, the business experienced these benefits immediately, which contributed to its growth. However, as the business adjusts its goals to better manage its assets, cloud cost control has become a priority.

The company recently hired Jeremy as the head of engineering practices for the organization. His immediate directive is to get the organization’s AWS costs under control. Leadership expects AWS costs to decrease by 30% within the next 3 months.

Jeremy asks Ezra, from the finance department, for a copy of last month’s AWS bill. Ezra sends Jeremy multiple bills, each reflecting cost for a distinct AWS account. Jeremy asks Ezra who are the respective owners of the AWS accounts but Ezra does not know.

Jeremy cannot recognize any spending patterns based on the bills. He doesn’t have any visibility into resource use to help him make any optimization decisions. He understands that he won’t be able to do this alone.

A successful FinOps practice depends on a decentralized approach where all teams are engaged in practicing resource hygiene, cost awareness, and optimization techniques where possible. Although individual teams drive FinOps practices, a centralized team will evangelize best practices and apply the appropriate governance to ensure teams are operating within bounds that help the business achieve their cost goals.

Summary

In this chapter, you learned about the importance of having to change your mindset when running financial operations in the cloud. You cannot use a traditional, centralized IT procurement approach since cloud operations aren’t owned by a single team. Rather, it is much more important to provide autonomy to your business teams to enable them to maximize cloud benefits. We will discuss how to enable your teams to be agile, autonomous, and to bring business value while controlling and managing their cloud spending throughout the remainder of this book.

You also learned that FinOps is a framework and discipline that crosses many teams within an organization. It is a combination of people, processes, tools, and metrics that empowers an organization using the cloud to manage its cloud resources as true assets that bring measurable value to the business. FinOps is not a one-person job, nor should it be owned and managed entirely by scattered teams. Rather, a centralized body such as a CCoE should own FinOps and share best practices with teams, enabling them to embed clean cloud cost hygiene within their operations.

You were also introduced to a few characters from a fictitious company struggling with implementing FinOps. You will encounter these characters and their stories throughout this book. The intent is for you to learn from their experiences and be able to apply their stories to yours. Let’s continue on our journey.

Further readings

Lyft Uses AWS Cost Management to Cut Costs by 40% in 6 Months: https://aws.amazon.com/solutions/case-studies/lyft-cost-management/#:~:text=As%20part%20of%20its%20cloud,engineers%20to%20build%20new%20tools.Doing More with Less: How MicroStrategy Cut Cloud Costs by 30%: https://aws.amazon.com/solutions/case-studies/microstrategy-cost-management/Etsy: Doing more with less cost and infrastructure: https://cloud.google.com/customers/etsyWhat is FinOps?: https://www.finops.org/introduction/what-is-finops/

Part 1: Managing Your AWS Inventory

The objective of Part 1 is to help you understand and track your inventory. This is the first step toward eliminating waste. This part will help you know what you own and what your baseline spending is. If you do not have this information, you won’t know what to optimize! This is like knowing your inventory in a warehouse: if you don’t know what you have, you are poorly established to grow your business.

This part of the book comprises the following chapters:

Chapter 2, Establishing the Right Account StructureChapter 3, Managing InventoryChapter 4, Planning and Metrics TrackingChapter 5, Governing Cost and Usage

2

Establishing the Right Account Structure

A successful financial operations (FinOps) practice begins with the right foundation. With Amazon Web Services (AWS), the organization of your AWS accounts constitutes that foundation. In this chapter, we’ll explore ways to establish your account structure. In subsequent chapters, we’ll see how an account structure directly impacts your ability to implement successful FinOps practices such as inventory management, governance and control, auditability, and reporting.

But first, we’ll learn about the various AWS tools that can help structure your AWS accounts, including AWS Organizations. This is the foundation that will direct how successful your FinOps efforts will be over time. We’ll then conclude with a brief look at how billing works for a multi-account AWS Organization.

In this chapter, we’re going to cover the following main topics:

Establishing an operating modelCreating a multi-account environmentUnderstanding billing with AWS Organizations

Technical requirements

To complete the exercises in this chapter, you will need:

A personal computing device (PC, Mac, or Linux) with a web browser installed that has access to the internetAWS credentials such as your AWS account name and passwordIf you’ve enabled AWS multi-factor authentication, you will also need your device’s authentication code.

Establishing an operating model

We’ve already established that a successful FinOps practice depends on the foundation of how you structure your AWS accounts. But how you structure your AWS accounts will likely depend on how you organize your business teams. Organizational structure is important because if the way you operate FinOps does not align with how your teams operate, you’ll create a chasm that disrupts any well-intended cost-saving initiatives. Conway’s law particularly holds true within FinOps:

Any organization that designs a system…will inevitably produce a design whose structure is a copy of the organization’s communication structure.

(Melvin Conway, How Do Committees Invent?)

Teams must know which role they play when contributing to projects that yield business value. They also need to know how their team synergizes with others when they collectively work toward set goals. The same ideas apply when implementing FinOps. Rather than having a centralized FinOps entity telling teams what to do and how to optimize, it’s much more effective if teams take ownership of cost savings and federate FinOps among teams. By doing so, teams are empowered with information; this data gives teams the information they need to see the kind of impact they have on costs as they gauge how their work impacts the broader business.

Operating models will vastly differ depending on a company’s industry, size, team size, and maturity, but we can at least categorize three generalized operating models that apply to FinOps on AWS.

Fully siloed models

When teams expect to operate with their specific function, a company can create silos that make it difficult for cross-team engagements. In the following diagram, we have four teams operating within their functional domains:

Figure 2.1 – A fully siloed operating model

Business informsEngineering of the application’s requirements. Engineering then passes the day-to-day operations of the application’s deployment to Operations. Meanwhile, Finance works with Engineering to find cost optimization opportunities that impact all teams within the organization. These practices can include tagging policies to ensure all cloud resources are tagged with an owner, purchasing reserved instances, executing automation scripts to clean up unused resources, or rightsizing instances.

As described, this model represents a functional separation between teams. Although a very common organizational practice, there is one major disadvantage: the lack of agility. By separating an application into functional teams, we expose operations similar to what we outlined previously: the user interface (UI) team builds and passes code to the business logic team to ensure functional requirements, then the code passes to the database team to work on storage components.

Each functional team is dependent on the others. This dependency hinders agility since each team cannot build, test, and deploy independently. In order to make a change, all teams must be involved; the change requires the entire application to change as a single unit.

It’s common for today’s enterprise products to change frequently during a lifetime. Given changing business requirements, changing customer preferences, market dynamism, and changing technologies, it is fitting for companies to move away from this model. Architecturally, this model generally implies a monolithic architecture because monoliths also commonly separate teams by function.

Separated application development with centralized FinOps

This model follows the you built it, you run it mantra. Engineering and operations work together as a unit—they perform both development and operations of the software they build to support a business function. Now that teams are working together and don’t have to pass off and potentially wait for dependencies from other teams, this enables teams to move faster and meet the demands of both external and internal stakeholders.

A development-operations (DevOps) approach has application and operations teams working together to deploy software quickly and iteratively. This removes the need for application developers to ship code to the operations or infrastructure team and wait for deployment. The following diagram shows this silo between engineering and operations removed. Now, the team acts as one enabling quick and agile deployment:

Figure 2.2 – A separated application model with a centralized FinOps function

FinOps, however, is management separated and centralized by finance. FinOps determines policies and governance controls and distributes them to the application teams. This centralized team can be a cloud center of excellence (CCoE) itself or a sub-team within the CCoE, focused mainly on cost-saving initiatives for the organization.

This model enables more agility than the siloed model in the previous section. Now that teams own the application as a unit, they can operate independently without dependencies on other teams. The trade-off for this is the requirement for organizations to create teams that have full-stack expertise, which can be challenging to say the least. Organizations can operationalize the most common requirements such that some teams can support themselves, while more specialized individuals serve on a cross-team. These best practices are covered in greater detail in Part 3, Operationalizing FinOps, of this book.

Decentralized FinOps with autonomous teams

The last model provides the most autonomy to teams. In this model, teams adopt and embed FinOps practices into their day-to-day workings. Although it doesn’t preclude the existence of a centralized FinOps team (such as a CCoE), it expects teams to embed FinOps within their operations. This is more easily achieved if there exists a strong culture of autonomy and teams adopting best practices.

In application development, you might see a shared services team that handles networking, security, monitoring, and other cross-domain practices, while the application components are owned by autonomous teams.