All courses / Architecture as Code / Module 4 / Chapter 15B
Learning objectives
After the lesson the participant can:
- Explain how FinOps practices are integrated into Architecture as Code workflows.
- Design cost allocation tags and budget alerts for a workload.
- Describe the Kubernetes components that govern resource consumption and their cost effect.
- Evaluate a proposed commitment against the chapter's five considerations.
Key concepts
- FinOps in Architecture as Code
- A discipline that combines financial management with cloud operations to maximise business value from cloud investments. In this context it means automated policies for resource configuration, budget alerts and regular cost analysis built into the workflow.
- Cost allocation tags and chargeback
- Metadata on all resources, such as cost centre, project, environment and owner, with chargeback models that distribute costs transparently between teams, projects and business units and give developers an incentive to make cost-optimal design decisions.
- Rightsizing
- Adjusting resource allocation to actual usage. Provider recommendations based on historical usage become actionable only when turned into reviewed code changes within Architecture as Code workflows.
- Kubernetes resource governance
- ResourceQuotas set hard limits per namespace, LimitRanges define default and maximum container resources, the Vertical Pod Autoscaler adjusts resource requests to actual usage, and the Horizontal Pod Autoscaler scales the number of replicas with demand.
- Commitment-based pricing
- Discounts received for committing to a defined usage level over a one-year or three-year term. The chapter advises a baseline of at least 30 to 90 days of usage data, flexible instruments, governance, rightsizing first and periodic review.
Interactive exercises
Do them here and get feedback at once. Choose a card and then where it belongs, or drag it.
Interactive exercise 1 · Match
Cost controls and what they do
Match each cost control to its purpose in the chapter's tables.
Interactive exercise 2 · Scenario
A cheaper region outside the EU
Read the situation and choose what the chapter's reasoning leads to. Each choice gives feedback.
Teaching plan
| 15 min | Teacher presents the cost optimisation workflow, the FinOps cycle and why cost estimation belongs between plan and apply. |
| 15 min | Walk through the cost-aware configuration table and the Kubernetes table. Participants identify which mechanisms their organisation already uses. |
| 10 min | Teacher explains commitment-based pricing and the five considerations, stressing that the published maximum discounts are provider figures and realised savings vary. |
| 25 min | Exercise: design cost governance for one workload. |
| 10 min | Close on the chapter's summary sentence about cost being declared, estimated and reviewed with the change that causes it, and on data residency as a cost constraint. |
Discussion
- The chapter says transparent cost distribution creates incentives for developers. What could go wrong with chargeback, and how would you design against it?
- How do data residency requirements under GDPR change what cost optimisation can mean for a European organisation?
- Why should reservation purchases pass through the same approval workflows as infrastructure changes?
Written exercise
Exercise · 25 minutes
Cost governance for one workload
Choose one cloud workload in your own organisation. Define its cost allocation tags using the four the chapter lists: cost centre, project, environment and owner, and say which pipeline check rejects a resource without them. Set a budget and two alert thresholds, following the pattern of notifications at 80 and 100 per cent, and name who is notified and what they are expected to do. State where in the pipeline a cost estimate appears and which threshold triggers an approval gate. List three kinds of unused resource to detect. Finally assess whether the workload is a candidate for a commitment by answering the five considerations from the chapter.
Deliverable: A one-page cost governance design with tag policy, budget and alert thresholds, pipeline cost gate, unused resource checks and a reasoned commitment assessment.
Self-test
Choose an answer to see whether it is right, or open the answer below each question.
How much usage data does the chapter say should be analysed before committing to reserved capacity?
Show the answer
B. At least 30 to 90 days
Baseline before committing: the chapter advises analysing at least 30 to 90 days of usage data to identify stable, predictable workloads suitable for reservation.Why does the chapter say rightsizing should be acted upon before making multi-year commitments?
Show the answer
C. Because committing to the wrong instance size locks in waste
Combine with rightsizing: committing to the wrong instance size locks in waste, so recommendations should be acted on before a multi-year commitment is made.Which Kubernetes component sets hard limits on CPU, memory and pod count per namespace?
Show the answer
A. ResourceQuotas
ResourceQuotas set hard limits per namespace, preventing over-allocation and enforcing budget constraints. LimitRanges define defaults and maxima for individual containers.