Architecture as Code · Module 4 · Delivery & Operations

Cost Optimisation and Resource Management

The lesson treats cost as a property of the architecture. It covers FinOps and cost governance, allocation tags and chargeback, cost estimation in the pipeline, automatic scaling and rightsizing, cost monitoring with budget alerts and anomaly detection, multi-cloud cost considerations including data transfer and residency, Kubernetes resource governance, and commitment-based pricing with the considerations that should precede a commitment.

Lesson 19 of 31Chapter 15B75 minutes

Read the chapterThe whitepaperThe slides

All courses / Architecture as Code / Module 4 / Chapter 15B

Learning objectives

After the lesson the participant can:

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 minTeacher presents the cost optimisation workflow, the FinOps cycle and why cost estimation belongs between plan and apply.
15 minWalk through the cost-aware configuration table and the Kubernetes table. Participants identify which mechanisms their organisation already uses.
10 minTeacher explains commitment-based pricing and the five considerations, stressing that the published maximum discounts are provider figures and realised savings vary.
25 minExercise: design cost governance for one workload.
10 minClose 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

  1. The chapter says transparent cost distribution creates incentives for developers. What could go wrong with chargeback, and how would you design against it?
  2. How do data residency requirements under GDPR change what cost optimisation can mean for a European organisation?
  3. 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.

  1. 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.

  2. 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.

  3. 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.