Be Wise Apps
Leer en español · Lire en français · Auf Deutsch lesen
Section 10.8 of 10.8 · Intermediate · 22 min read
FinOps, cost architecture and vendor lock-in
Video lesson
5 min · narrated, with captionsListen only (audio)
Read the transcript
In the cloud, every architectural decision is also a purchasing decision. In this last lesson of the chapter, you'll learn to treat cost as a quality, and to price lock-in rather than fear it.
Renting a car for a day is cheap. Renting one every day for three years is far dearer than buying. Leaving the engine running in the car park costs fuel for nothing. And if you lease one with a special charging plug, switching brands means new chargers. FinOps is the household budget habit for the cloud. Lock-in is the special plug: some dependence is worth it, if you chose it on purpose and know how you'd leave.
FinOps, defined by the FinOps Foundation, shares financial accountability between engineering, finance and the business. At its centre is shared ownership, not a central team policing spend. Inform makes costs visible: allocate them to the teams that cause them, show them to their owners, and forecast. Optimise reduces waste and improves rates, by rightsizing, scheduling, commitments and redesigning costly paths. Operate builds the habits that keep costs under control: policies, budgets, ownership, and cost in every design decision. Then the cycle repeats, maturing from crawl, to walk, to run.
A cloud bill that rises from eighty thousand to a hundred thousand a month might be a disaster or a triumph, depending on whether the business grew by five per cent or by fifty. Unit economics expresses cost per unit of business value: for the food delivery platform, cost per order. It separates efficiency from growth, and gives teams a target they can influence. Most surprising bills come from a few drivers: data transfer, idle and oversized resources, logging volume, managed service premiums and storage that's never deleted. Nearly all are shaped by architecture.
Here's a day of compute. The always-on floor is covered by a one or three year commitment discount. Commit only to the baseline you're certain to need; committing to peak converts a discount into waste. Spot capacity is spare capacity at large discounts, often sixty to ninety per cent, but the provider can reclaim it at short notice. It suits interruptible, retriable work, such as night-time batch jobs, never databases. The lunch and dinner peaks are covered by on-demand capacity that autoscales. And rightsize before you commit.
Let's apply it. The platform handles one point two million orders a month, on a bill of ninety six thousand pounds. That's eight pence per order. First, compute requests were about twice measured usage. Setting them from measurements cut the nodes by a quarter, and only then was the steady part committed for a year. Compute fell from forty two thousand pounds to twenty five thousand eight hundred and thirty. Second, half the log volume was debug output. Turning it off, sampling successful requests, and keeping hot logs for fourteen days instead of ninety cut observability from fourteen thousand pounds to six thousand five hundred. Third, the order and pricing services exchanged about forty calls per order across zones. Moving the hot path's pricing into the order service, and serving restaurant images from a CDN, saved a net five thousand pounds. The bill fell to sixty seven thousand three hundred and thirty pounds, about five point six pence per order: thirty per cent lower, with the same features and reliability targets.
Now lock-in: the cost of leaving something once you depend on it. Gregor Hohpe argues that avoiding lock-in at all costs is itself a trap. Price it: switching cost times the likelihood of switching. A switch that would cost fifty thousand, with a five per cent chance of happening, has an expected cost of two thousand five hundred. Spending far more than that to avoid it is a poor bargain. His matrix sets unique utility against switching cost. Commodity services that are cheap to replace are disposable: use them freely. Where a service gives unique value worth its switching cost, accept the lock-in, deliberately. Be cautious where leaving is costly but the unique benefit is small. And the ideal, unique and easy to leave, is rare.
Portability isn't free: it means using only the features every cloud shares, and building abstraction layers that leak. Many multi-cloud strategies end up with the costs of all their providers and the advantages of none. A sound middle position: accept lock-in where it buys clear value, keep business logic behind ports and adapters at the few seams most likely to change, and keep data in formats you can export. And write down an exit strategy, and rehearse it at least partly. In the EU, the Digital Operational Resilience Act now requires financial firms to have one for critical services.
That completes Chapter 10. When you're ready, take the optional chapter test: twenty multiple choice questions and two written answers, with a pass mark of eighty per cent. Then continue to Chapter 11, on evaluation, decision making and governance. See you there.
What you need to know
- In the cloud every architectural decision is also a purchasing decision, so cost is a quality attribute that changes with each deployment and is best expressed per unit of business value, such as cost per order.
- FinOps, defined by the FinOps Foundation (a Linux Foundation project), shares financial accountability between engineering, finance and the business through three iterative phases: inform, optimise and operate.
- Common cost drivers are data egress and cross-zone transfer, idle and over-provisioned resources, logging volume, managed-service premiums and unmanaged storage growth; most are shaped by architecture.
- Commitment discounts suit only the certain baseline, spot capacity suits interruptible and retriable work, and on-demand autoscaling covers peaks; rightsize before committing.
- Tagging enables allocation; showback reports costs to teams, chargeback charges their budgets and needs accurate allocation and agreed rules for shared costs.
- Lock-in is a trade-off: Hohpe (2019) distinguishes many kinds and weighs switching cost times likelihood against the cost of avoiding it; accept it where it buys unique value.
- Portability has real costs; keep business logic behind ports at likely seams, keep data exportable and maintain a tested exit strategy, which EU financial regulation now requires for critical services.
Cost is an architectural quality
Section 2.7 (security, usability and more) listed cost among the quality attributes and recommended expressing it per unit of work. In a data centre, cost was mostly fixed: hardware was bought every few years and an architect's choices barely moved the monthly bill. In the cloud, every architectural decision is also a purchasing decision, made continuously by engineers rather than once a year by procurement. A chatty service boundary, a debug log level, a forgotten test environment or a synchronous cross-region call each shows up on next month's invoice. Cost has become a quality attribute that changes with every deployment.
Two disciplines help. FinOps is the operating practice that makes cloud spending visible, owned and managed. Cost-aware architecture is the design practice that makes systems cheap to run per unit of value in the first place. This section covers both, and then turns to their awkward neighbour: lock-in, the cost of leaving.
FinOps: phases, principles and who does what
FinOps is defined by the FinOps Foundation, a Linux Foundation project, as an operational framework and cultural practice that maximises the business value of technology through timely, data-driven decisions and financial accountability shared between engineering, finance and the business. The name deliberately echoes DevOps: just as DevOps broke down the wall between building and running software, FinOps breaks down the wall between spending money and deciding how software is built.
The FinOps Framework organises the work into three iterative phases. Inform: make costs visible, allocate them to the teams and products that cause them, forecast and benchmark. Optimise: reduce waste and improve rates, by rightsizing, scheduling, commitments and design changes. Operate: build the habits that keep costs under control, such as budgets, policies, ownership and cost considered in every design decision. Organisations move through the cycle repeatedly, maturing from crawl to walk to run in each capability. The framework's principles include that teams collaborate, that business value drives technology decisions, that everyone takes ownership of their technology use, that cost data is accessible, timely and accurate, that FinOps is enabled centrally, and that the variable cost model of the cloud should be used to advantage. Recent versions extend the framework beyond public cloud to other technology spending, such as SaaS licences, data centres and AI services.
The FinOps cycle
Unit economics: cost per order
A cloud bill that rises from 80,000 to 100,000 a month might be a disaster or a triumph, depending on whether the business grew by 5% or by 50%. Unit economics expresses cost per unit of business value: cost per order for the food-delivery platform, per active customer for a streaming service, per thousand API calls for a developer platform. It separates efficiency from growth, connects engineering decisions to business outcomes and gives teams a target they can influence.
Computing it well needs three things. First, a unit that matters to the business, chosen with finance and product, not invented by engineers. Second, cost allocation: direct costs (the order service's compute and database) assigned through tags or namespaces, and shared costs (the Kubernetes control plane, the observability stack, the platform team's tools) split by an agreed rule such as proportional usage. Third, a distinction between average and marginal cost: the average cost per order includes fixed costs that do not grow with orders, so the cost of the next thousand orders is usually lower than the average suggests, which matters when pricing a promotion or forecasting growth.
Where the money goes: common cost drivers
Most surprising cloud bills come from a handful of drivers, and nearly all of them are shaped by architecture rather than by negotiating better prices.
Common cost drivers and architectural responses
| Driver | Why it grows | Architectural responses |
|---|---|---|
| Data egress and transfer | Providers charge per gigabyte for data leaving to the internet, and often for traffic between zones and regions and through managed NAT gateways. Chatty services spread across zones pay on every call. | Serve public content through a CDN; keep chatty services zone-local (topology-aware routing); use private endpoints to provider services; compress; avoid synchronous cross-region traffic. |
| Idle and over-provisioned resources | Test environments running 168 hours a week for 50 hours of use; container resource requests set far above real usage; orphaned volumes, snapshots and load balancers. | Rightsizing from measured usage; schedules and autoscaling to zero for non-production; time-limited preview environments; automated clean-up of unattached resources. |
| Logging and observability volume | Ingestion and retention are priced per gigabyte; debug logs in production, verbose request logging and high-cardinality metric labels grow with traffic. | Log levels and sampling for successful requests; tiered retention (hot for days, archive for months); metrics instead of logs for counts; trace sampling. |
| Managed-service premiums | A managed service costs more per unit of capacity than running the software yourself; per-request pricing grows linearly with volume. | Compare total cost of ownership including people and risk; review per-request services at high steady volume (see serverless); use them where the premium buys real reliability or speed. |
| Storage growth | Data that is never deleted, object versions, duplicated copies and old backups accumulate quietly. | Lifecycle policies to cheaper tiers and deletion; retention rules agreed with the business and the law; deduplicated, incremental backups. |
Paying less for the same capacity
Once waste is removed, the rate paid for the remaining capacity can be lowered. On-demand capacity is the most flexible and most expensive. A commitment discount exchanges flexibility for price: AWS Reserved Instances and Savings Plans, Azure reservations and savings plans, and Google Cloud committed use discounts offer substantial reductions (AWS quotes up to 72% for some commitments) in return for committing to a level of usage or spend for one or three years. Commitments should cover only the baseline that will certainly be needed for the term; committing to peak capacity converts a discount into waste.
Spot capacity (AWS Spot Instances, Azure Spot Virtual Machines, Google Cloud Spot VMs) sells spare capacity at large discounts, often 60% to 90%, but the provider can reclaim it at short notice: two minutes on AWS, about 30 seconds on Azure and Google Cloud. It suits work that is stateless, interruptible and retriable, such as batch processing, CI runners, rendering and some stateless web tiers spread across many instance types. It does not suit databases or anything that cannot be stopped mid-task. Architecture decides how much of a workload can use spot: idempotent, checkpointed jobs can; long, stateful ones cannot.
Matching pricing models to the shape of demand
Tagging, showback and chargeback
Nobody optimises a cost they cannot see. Allocation starts with a tagging (or labelling) policy: every resource carries a small set of mandatory tags, such as owner team, service, environment and cost centre, enforced by guardrails in infrastructure code and cloud organisation policies, because tags added by hand are soon missing. For Kubernetes, costs are allocated by namespace and label with tools such as the open-source OpenCost project or the providers' own cost allocation features. The FinOps Foundation's FOCUS specification defines a common format for billing data so that costs from several providers can be combined.
With costs allocated, an organisation chooses how to use them. Showback reports each team's costs to it without touching its budget; it builds awareness and is the usual starting point. Chargeback charges the costs to each team's budget, which creates stronger incentives but needs accurate allocation, agreed rules for shared costs and a way to handle disputes. Either way, publish the share of spend that cannot be allocated: an untagged share above a few per cent means the numbers are not yet trustworthy enough to act on.
Architectural decisions that drive cost
The largest savings come from design, not discounts, and they are cheapest to obtain before a system is built. Each of the following decisions has a predictable cost profile. Service granularity: every network hop costs compute, serialisation and possibly data transfer, so fine-grained services in many zones cost more per request than a modular monolith. Synchronous fan-out: a request that calls ten services keeps eleven sets of resources busy for its duration. Environment count: full copies of production for every team and branch multiply the bill; shared environments with isolation or short-lived previews cost far less. Data retention and replication: every extra copy and every extra region multiplies storage and transfer. Caching and CDNs: a cache hit is usually far cheaper than recomputing, and a CDN hit avoids egress from the origin. Compute model: per-request serverless pricing is cheaper than always-on capacity below a crossover volume and dearer above it.
Record significant cost consequences in decision records alongside the other quality trade-offs, and consider adding cost to the fitness functions that guard the architecture: for example, a monthly check that cost per order has not risen by more than 10% without an explanation.
Lock-in is a trade-off, not a sin
Lock-in is the cost and difficulty of leaving something once you depend on it. It is usually discussed as something to avoid at all costs; Gregor Hohpe's 2019 article on martinfowler.com, Don't get locked up into avoiding lock-in, argues that this is itself a trap. He distinguishes several kinds of lock-in: vendor (contracts and commercial terms), product (a particular product's APIs and features, even if open source), version, architecture (a style such as serverless), platform (accounts, identity and security models), skills (what your people know), legal (compliance and licensing) and mental (assumptions that stop you considering alternatives). Using open-source software reduces vendor lock-in but leaves most of the others.
The key move is to treat lock-in as an option-pricing problem. The switching cost is what it would cost to move; multiplied by the likelihood of ever moving, it gives the expected cost of being locked in. Reducing the switching cost has a price of its own: extra abstraction, lowest-common-denominator designs and forgone features. A switch that would cost 50,000 and has a 5% chance of happening carries an expected cost of 2,500, so spending far more than that to avoid it is a poor bargain. Hohpe's matrix of unique utility against switching cost turns this into a quick classification.
Unique utility against switching cost
The cost of portability and the exit strategy
Portability is not free. Designing every component to run on several clouds means using only features they all share, building and testing abstraction layers that leak (see information hiding and leaky abstractions), keeping skills in several platforms and giving up managed services that would have saved effort. Many multi-cloud strategies end up with the costs of all their providers and the advantages of none. Portability is cheapest where open standards already exist: OCI container images, Kubernetes manifests, PostgreSQL-compatible databases, S3-compatible object storage APIs, standard protocols such as HTTP, AMQP and the Kafka protocol, and OpenTelemetry for observability. Even the tools used to stay portable, such as Terraform or OpenTofu, are dependencies in their own right.
Practitioners disagree on how far to go. Advocates of portability point to price rises, outages, sanctions, regulation and the cases where moving out of the cloud paid off (see cloud repatriation in section 10.1). Advocates of committing to one provider point to the speed and reliability gained from using managed services fully. A sound middle position is to accept lock-in deliberately where it buys clear value, keep business logic independent of provider APIs behind ports and adapters at the few seams most likely to change, keep data in formats you can export, and write down an exit strategy.
Regulation increasingly requires that last step. The EU's Digital Operational Resilience Act (Regulation (EU) 2022/2554, applying from 17 January 2025; not to be confused with the DORA delivery metrics) requires financial entities to have exit strategies for ICT services that support critical or important functions. The EU Data Act's cloud-switching rules have applied since 12 September 2025: customers may switch provider with at most two months' notice, providers may charge only their direct costs for switching, including data egress, until 12 January 2027, and nothing after that. In 2024 the largest providers also announced free data transfer for customers leaving them, subject to conditions. An exit strategy should name the replacement for each critical service, estimate the time and cost to move, show that data can be exported in a usable format, and be rehearsed at least partly, for example by restoring a backup into another environment.
Worked example
Worked example: cost per order and three architectural changes
The food-delivery platform handles 1.2 million orders a month. Its monthly cloud bill is 96,000: compute 42,000, managed databases 18,000, observability 14,000, data transfer 12,000, other managed services 6,000 and storage 4,000. All figures are illustrative, in pounds.
| Baseline | 96,000 / 1,200,000 orders = 0.080 per order. Showback reveals that compute requests are about twice measured usage, half the log volume is debug output, and the order and pricing services exchange about 40 calls per order across availability zones. |
|---|---|
| Change 1: rightsize, then commit | Requests set from measured p95 usage cut node count by 25%: compute 42,000 to 31,500. The steady 60% of that (18,900) is covered by a one-year commitment at about 30% off, saving 5,670. Compute becomes 25,830, a saving of 16,170. |
| Change 2: log less, keep it shorter | Debug logging off in production, successful requests sampled at 10%, hot retention cut from 90 to 14 days with an archive tier. Ingestion falls by about 60%: observability 14,000 to 6,500, a saving of 7,500. |
| Change 3: stop paying for distance | Pricing logic moved into the order service's process for the hot path (removing most of the 40 calls), zone-aware routing for the remaining calls, and restaurant images served from a CDN instead of the origin. Data transfer 12,000 to 6,000; CDN adds 1,000. Net saving 5,000. |
| Result | 96,000 minus 28,670 = 67,330 a month, or 0.056 per order: 30% lower per order, with no change in features or reliability targets. |
| What did not change | Database and storage costs were left alone this quarter because the savings available there were small relative to the risk; they remain in the backlog. |
The largest structural change was architectural (removing a chatty boundary and introducing a CDN), the logging change was a design decision about observability, and the rate discount was applied only after rightsizing, so the company did not commit to waste.
Tracking cost per order rather than the total bill shows whether future growth keeps the improvement: if orders double and cost per order stays near 0.056, efficiency has held.
Questions people ask
Should every team be charged for its cloud costs?
Start with showback, so that teams see their costs and can act, and move to chargeback only when allocation is accurate and shared costs are split by rules everyone accepts; charging inaccurate numbers creates arguments, not savings.
Is multi-cloud the best protection against lock-in?
Rarely on its own. Running the same system on several clouds is expensive and limits you to common features. Using different providers for different, independent workloads, plus a tested exit strategy for critical ones, usually gives most of the protection at a fraction of the cost.
When is cost optimisation premature?
When the product has not found its market and engineering time is the scarcest resource. Even then, tagging from day one and a rough cost per unit are cheap and make later optimisation far easier.
Check your understanding
Why is cost per order more useful than the total monthly bill?
It separates efficiency from growth: a rising bill with a falling cost per order is healthy, while a flat bill with falling orders is not.
Why should rightsizing come before buying commitment discounts?
A commitment locks in a level of spend for one or three years; committing before removing over-provisioning turns waste into a long-term obligation.
What kind of workload suits spot capacity, and why?
Stateless, interruptible and retriable work such as batch jobs and CI runners, because the provider can reclaim spot capacity with seconds or minutes of notice.
According to Hohpe, when is lock-in acceptable?
When it buys unique utility worth the switching cost, or when switching is so unlikely that the expected cost is lower than the cost of avoiding the lock-in.
Sources and further reading
Have a question about this section? ArchitectBot, the course’s AI study assistant, answers from the course first.
Ask: “Our cloud bill grew 40% this year while orders grew 15%. How do I find out which architectural decisions are driving the cost, and which fixes to try first?”