We have seen tools (Cost Explorer, Budgets, Trusted Advisor) and techniques (rightsizing, Savings Plans) to save money. But managing cloud costs is not just a matter of tools: it is a way of working as a team, a culture. This discipline has its own name: FinOps. We close the chapter on costs by understanding what it is and why it has become so important in companies operating in the cloud.

The problem: in the cloud, anyone can spend

In the traditional model (physical servers), spending money on infrastructure was a slow and centralized process: someone had to approve the purchase of a server, it went through the purchasing department, it took weeks. The spending was controlled by a few people.

In the cloud, this changes radically: any developer can, with a few lines of Terraform or a few clicks, create resources that cost money instantly. This is wonderful for agility (remember the self-service from subchapter 1.2), but it creates a new problem:

Traditional model:  spending = slow, centralized, controlled process
Cloud model:        spending = instantaneous, decentralized, anyone can
   → huge agility, BUT costs can easily get out of control

If no one is responsible for costs, each team creates resources without thinking about spending, and the bill grows uncontrollably. A new way of managing money in the cloud is needed: FinOps.

What is FinOps

FinOps (from Financial Operations) is a discipline and culture for managing cloud costs in a collaborative way, bringing together technical, financial, and business teams so they can make informed and responsible spending decisions. The central idea: cloud cost is everyone's responsibility, not just the finance department's.

   FinOps brings together three worlds that used to be separate:
   
   👩‍💻 Technical teams  ──┐
   💰 Finance           ──┼──►  INFORMED, responsible, and collaborative
   📊 Business          ──┘     spending decisions

Analogy: FinOps is like properly managing a family budget in which everyone collaborates. It's not that only one person controls the money while the others spend without thinking; it's that the whole family understands how much is earned, what it's spent on, and each person is aware and responsible for their expenses. If everyone collaborates and has visibility, the budget is managed healthily. If only one person watches and the others ignore the cost, chaos is guaranteed.

The principles of FinOps

FinOps is based on some key ideas:

  1. Visibility: everyone sees what it costs

For people to be responsible for cost, they first have to see it. FinOps promotes that each team knows how much what they use costs (thanks to tags and Cost Explorer, subchapter 25.1). You can't be responsible for something you can't see.

  1. Responsibility: each team owns its cost

Each team becomes responsible for the spending of its own resources. Cost is no longer "a finance problem" and becomes part of the work of each technical team, which considers cost when designing and operating (just as they consider performance or security).

  1. Continuous optimization: always improving

FinOps is not something you do once, but a continuous process of reviewing and improving: applying rightsizing (25.3), buying Savings Plans when appropriate (25.4), eliminating what is not used, etc., as a habit.

  1. Collaboration: technical, finance, and business together

Spending decisions are made together, with each part contributing its perspective: technical knows what can be optimized, finance understands the budget, and business knows what value each expense brings.

FinOps Principles:
   👁️  Visibility           → everyone sees the costs
   🙋  Responsibility       → each team owns its spending
   🔄  Continuous optimization → always review and improve
   🤝  Collaboration        → technical + finance + business together

The balance: it's not just about spending less

An important nuance: FinOps is not about spending as little as possible at all costs. It's about spending smartly, getting the maximum value for every euro. Sometimes the right thing is to spend more (on a resource that generates a lot of business value), and sometimes it's to cut back. FinOps seeks to ensure that every spending decision is justified by the value it brings.

Cutting costs blindly can be as bad as wasting: if you cut something that supports a revenue-generating service, you lose more than you save. FinOps seeks the balance between cost and value.

Real-world example: a company with a cloud bill growing out of control implements a FinOps culture. They start by tagging all resources by team and giving each team a dashboard with their spending (visibility). Each team assumes responsibility for its bill. Technical, finance, and a business manager meet monthly to review costs (collaboration) and decide on optimizations (rightsizing, Savings Plans). In six months, not only do they reduce the bill by 30%, but they also understand why they spend what they spend and every euro is justified. The most valuable thing is not the one-time savings, but the culture: now cost is considered from the beginning, not as a shock at the end of the month.

How the cost chapter closes

Everything covered in Chapter 25 is part of FinOps:

FinOps (the culture and discipline, this subchapter)
   ├── Visibility and control → Cost Explorer, Budgets (25.1)
   ├── Recommendations       → Trusted Advisor, Compute Optimizer (25.2)
   ├── Rightsizing           → Rightsizing (25.3)
   └── Discounts             → Savings Plans, Reserved Instances (25.4)

The tools and techniques are the "how"; FinOps is the "how we work together" to use them well on an ongoing basis.

What you should remember

  • In the cloud, anyone can spend instantly (great agility, but costs can get out of control). A new way to manage it is needed: FinOps.
  • FinOps is a discipline and culture for managing cloud costs collaboratively, bringing together technical, financial, and business teams to make informed and responsible spending decisions. Like properly managing the family budget together.
  • Principles: visibility (everyone sees the costs), responsibility (each team owns its spending), continuous optimization (always improving), and collaboration (technical + finance + business).
  • It's not about spending the least, but about spending smartly, with the maximum value per euro; sometimes the right thing is to spend more. It's a balance between cost and value.
  • The tools and techniques in the chapter (Cost Explorer, Budgets, rightsizing, Savings Plans) are the "how"; FinOps is "how we work together" to apply them continuously.

You have completed Chapter 25 and mastered cost optimization in the cloud! In Chapter 26, which closes Part VI, we will address how to ensure your systems withstand failures and disasters: high availability and disaster recovery.

Cloud, AWS & Terraform — From Zero to Expert

Chapter 1 · What is cloud computing

Chapter 2 · The cloud market and major providers

Chapter 3 · Regions, availability zones and edge

Chapter 4 · Compute: EC2

Chapter 5 · Storage: S3

Chapter 6 · Networking: VPC

Chapter 7 · Identity and access: IAM

Chapter 8 · Managed databases

Chapter 9 · Why Infrastructure as Code

Chapter 10 · HCL: the Terraform language

Chapter 11 · Providers and state

Chapter 12 · Your first real infrastructure in Terraform

Chapter 13 · Load balancing and auto scaling

Chapter 14 · Serverless with Lambda

Chapter 15 · Messaging and events

Chapter 16 · Content delivery and DNS

Chapter 17 · Containers on AWS

Chapter 18 · Modules: reuse and composition

Chapter 19 · Workspaces and environment management

Chapter 20 · Remote backends and locking

Chapter 21 · Infrastructure testing

Chapter 22 · Terraform in CI/CD

Chapter 23 · Defense in depth

Chapter 24 · Observability: logs, metrics and traces

Chapter 25 · Cost optimization

Chapter 26 · High availability and disaster recovery

Chapter 27 · AWS Well-Architected Framework

Chapter 28 · Serverless architectures at scale

Chapter 29 · Data platforms on AWS

Chapter 30 · Multi-account and landing zones

Chapter 31 · Platform Engineering and Internal Developer Platform

Chapter 32 · Relevant AWS certifications

Chapter 33 · Projects to consolidate what you've learned

Chapter 34 · Resources and community

© Copyright 2024. All rights reserved