Cost, Capacity, Performance and Sustainability

Introduction and Context

Cloud deployment changes the economics of computing. Instead of purchasing servers in advance, an organisation can obtain infrastructure as a service and pay according to consumption, commitment, or a combination of both. This flexibility is strategically valuable, but it also creates operational risk: an application may be technically successful while its cost is uncontrolled, capacity is poorly matched to demand, performance is inadequate, or its environmental impact is unnecessarily high.

Cloud cost management is therefore not merely an accounting activity. It is a socio-technical discipline involving architecture, engineering, finance, procurement, security, and management. AWS and Google Cloud provide detailed billing records, budgets, usage reports, pricing calculators, monitoring systems, and commitment products. These tools become useful only when an organisation establishes clear ownership, reliable measurements, and disciplined decision-making.

This chapter explains how to analyse cloud expenditure, estimate total cost of ownership, right-size resources, select pricing models, apply FinOps practices, and connect performance and capacity decisions with sustainability.

Learning Objectives

By the end of this chapter, a learner should be able to:

1. Interpret cloud billing, usage, and cost-allocation data.
2. Distinguish direct cloud cost from total cost of ownership.
3. Estimate consumption and compare pricing models.
4. Apply capacity-planning and right-sizing techniques.
5. Relate performance metrics to cost and user experience.
6. Use budgets, forecasts, tags, labels, and unit economics for managerial decisions.
7. Evaluate sustainability practices in AWS, Google Cloud, and hybrid environments.
8. Recognise the governance, ethical, and practical limitations of cloud cost estimates.

1. The Economics of Cloud Computing

Traditional infrastructure commonly involves capital expenditure, or CapEx: servers, storage systems, network equipment, facilities, and licences are purchased before their full utilisation is known. Cloud services generally emphasise operating expenditure, or OpEx: consumption is charged periodically, although reserved or committed capacity can introduce a contractual commitment resembling CapEx.

Cloud economics is not automatically cheaper than a data centre. It is advantageous when elasticity, speed, resilience, global reach, or reduced operational responsibility creates value. A continuously running, predictable workload may be cheaper on owned infrastructure or a long-term cloud commitment. An intermittent workload may benefit from pay-as-you-go pricing because unused capacity is not purchased.

A useful management distinction is between:

• Cost visibility: knowing what was spent and by which service, team, product, or environment.
• Cost control: preventing unauthorised or wasteful consumption.
• Cost optimisation: obtaining a required level of capability at the lowest sustainable cost.
• Cost avoidance: preventing future expenditure through architectural or operational choices.
• Business value: relating expenditure to revenue, users, transactions, availability, or mission outcomes.

The correct question is rarely “What is the cheapest resource?” It is “What combination of cost, capacity, performance, reliability, security, and sustainability best satisfies the service requirement?”

2. Cloud Cost Components

A cloud invoice may contain several classes of charge. The exact names and prices change by provider, region, service, and date, so production estimates should use current provider documentation or pricing tools.

A bill should be analysed at several levels: account or billing profile, service, region, environment, application, team, and business unit. Tags in AWS and labels in Google Cloud can support allocation, but only if they are consistently applied and monitored. Untagged resources create a governance problem because their technical owner and business purpose are unclear.

Direct, shared, and indirect costs

Direct costs can be attributed to one workload, such as the compute cost of a production API. Shared costs support multiple workloads, such as a central Kubernetes cluster, security platform, identity service, or network hub. Indirect costs include engineering labour, incident response, governance, migration, training, and the cost of management attention.

A fair allocation method should be documented. For example, a shared observability platform might be allocated according to log volume, while a shared cluster might be allocated according to requested CPU and memory or measured usage. Allocation is an approximation; it should improve decision-making rather than create false precision.

3. Billing Analysis and Unit Economics

Billing analysis begins with reliable evidence. Useful data sources include provider invoices, detailed billing exports, cost-and-usage reports, resource inventories, monitoring data, deployment records, and service-level objectives. A cost report without usage context can be misleading. A rise in compute expenditure may represent waste, or it may reflect a successful increase in customers.

Important dimensions include:

• Spend: monetary expenditure during a period.
• Usage: measured consumption, such as instance-hours, GB-months, requests, or GB transferred.
• Rate: cost per unit of usage.
• Utilisation: the proportion of provisioned capacity actually used.
• Efficiency: the amount of useful output produced per unit of cost or resource.
• Variance: the difference between actual and planned or forecast values.

A basic cost identity is:

Here, quantity_i is the usage quantity for item i, unit price_i is its price in the applicable currency per unit, fixed charges are costs not proportional to usage, discounts reduce eligible charges, and taxes may be applied according to jurisdiction. The equation assumes that all relevant billing components are included and that quantities and prices use compatible units.

For unit economics, an organisation may calculate:

A business unit might be a transaction, active customer, video minute, build, or order. The denominator must be clearly defined. If a platform costs £12,000 per month and processes 3,000,000 orders, its infrastructure cost per order is £0.004, or 0.4 pence, before other business costs. This metric is meaningful only if the cost boundary and order count are stable and comparable.

4. Forecasting, Budgets, and Variance

A budget is an approved spending plan; a forecast is an evolving estimate of expected spending. A budget should not be treated as a target to exhaust. A forecast should be updated when demand, architecture, price, or commitment assumptions change.

For a simple linear forecast:

This is appropriate only when the remaining-cost estimate reflects seasonality, planned deployments, and known changes. A run-rate estimate may be calculated as:

The standard month length must be stated. Using 30 days is a management approximation; calendar-based forecasting should use actual dates. Run rate is unreliable after a one-off migration, outage, marketing event, or temporary test.

Variance can be represented as:

and percentage variance, when the budget is non-zero, as:

A positive value may indicate overspending, but interpretation depends on the sign convention and whether increased usage produced additional revenue or service value.

Budgets and alerts should be layered. A warning may be sent to a team when projected spending exceeds a threshold; a stronger control may require approval for new resources; an emergency control may stop non-production workloads. Automatic shutdown is dangerous for production systems unless dependencies, recovery, and customer impact have been assessed.

5. Capacity Planning and Right-Sizing

Capacity planning matches resources to demand while preserving required performance and resilience. The key terms are:

• Demand: work requested by users or systems.
• Capacity: maximum sustainable work under stated conditions.
• Utilisation: used capacity divided by provisioned capacity.
• Headroom: capacity reserved for bursts, failures, and uncertainty.
• Scaling: changing capacity vertically or horizontally.
• Elasticity: the ability to adjust capacity in response to changing demand.

A simple utilisation relationship is:

The numerator and denominator must refer to the same resource, period, and unit. CPU utilisation alone is insufficient: an application may be limited by memory, disk latency, database connections, network throughput, locks, or external dependencies.

Right-sizing is an evidence-based process:

1. Inventory resources and identify owners.
2. Observe representative peak and off-peak periods.
3. Measure CPU, memory, storage, network, latency, errors, and queue depth.
4. Compare measurements with service objectives and workload forecasts.
5. Test a smaller or differently shaped resource.
6. Deploy gradually and verify performance, reliability, and cost.
7. Repeat periodically because workloads evolve.

A common error is reducing capacity solely because average utilisation is low. Average values conceal peaks and tail latency. A resource with 15% average CPU may still need its current size if a short daily peak causes timeouts. Conversely, a constantly oversized resource may be a strong candidate for scaling or for an alternative architecture.

Scaling patterns

Vertical scaling changes the size of a resource. It is simple but has upper limits and may require interruption. Horizontal scaling adds or removes instances. It supports elasticity but requires stateless design, load balancing, health checks, shared state management, and appropriate database capacity. Scheduled scaling suits predictable patterns; reactive autoscaling suits measurable demand but requires suitable signals and response time.

Capacity planning should include failure scenarios. A service with two instances may have acceptable normal capacity but insufficient capacity when one instance fails. High availability therefore changes the cost baseline. Resilience is not waste; it is a deliberate service property whose value should be compared with business impact.

6. Pricing Models and Total Cost of Ownership

Common cloud pricing choices include:

A commitment should be evaluated against a baseline, not optimistic growth. Analyse minimum expected demand, contract term, cancellation or modification rules, regional constraints, and the cost of under-utilisation. Spot or preemptible resources should not host work that cannot checkpoint, retry, or tolerate interruption.

Total cost of ownership compares alternatives across their full economic boundary. A simplified model is:

For a defined analysis period, such as three years, each term must be estimated over the same period and discounted only if the organisation’s financial method requires it. Cloud charges should include compute, storage, network, observability, support, and relevant taxes. Labour should include design, operations, security, patching, incident response, and training. TCO is not the same as invoice total.

7. FinOps as an Operating Model

FinOps is a collaborative operating model that connects engineering, finance, procurement, and business teams. Its central principles are shared accountability, timely visibility, informed decision-making, and continuous optimisation. It is not simply a finance department reviewing invoices after the fact.

A practical FinOps cycle is:

1. Inform: publish reliable cost, usage, ownership, and unit metrics.
2. Optimise: remove waste, right-size, improve architecture, and select suitable commitments.
3. Operate: embed budgets, policies, forecasting, accountability, and continuous review.

A mature operating model includes a cloud centre of excellence or equivalent community, named service owners, tagging or labelling standards, budget owners, cost anomaly detection, and regular review forums. Governance should be proportional: a small development environment does not need the same approval process as a regulated production platform.

Useful metrics include commitment coverage, commitment utilisation, idle resource value, tag or label completeness, forecast accuracy, cost per transaction, and percentage of spend associated with an accountable owner. Metrics should not encourage harmful behaviour. For example, a team rewarded only for reducing spend may disable monitoring or reduce redundancy. Balanced scorecards should include reliability, security, delivery speed, and customer outcomes.

8. Performance, Cost, and Sustainable Computing

Performance and cost are coupled. More replicas may reduce latency but increase compute cost. Aggressive compression may reduce network cost but increase CPU use. A premium database may reduce operational work but increase direct expenditure. Decisions must therefore consider the relevant service-level objective and business value.

Important performance measures include response-time percentiles, throughput, error rate, availability, queue depth, saturation, and resource utilisation. Percentiles are often more informative than averages. The 95th-percentile latency is the value below which 95% of observations fall; it reveals tail behaviour that an average can hide.

Sustainable computing seeks to reduce environmental impact while maintaining required service outcomes. Relevant practices include:

• selecting efficient instance types and managed services;
• scaling down non-production environments outside working hours;
• deleting unused disks, snapshots, images, and addresses;
• using lifecycle policies for storage;
• reducing unnecessary data transfer and duplicate data;
• choosing lower-carbon regions where legal, latency, resilience, and data-residency requirements permit;
• improving software efficiency and workload scheduling;
• measuring emissions using provider tools while stating their boundaries and assumptions.

Cost and carbon are related but not identical. A cheaper resource is not necessarily lower carbon, and a highly utilised resource may still use carbon-intensive electricity. Sustainability claims should distinguish operational emissions, embodied emissions in hardware, and the boundaries of the measurement method. Avoid presenting provider estimates as precise physical measurements when the methodology is approximate.

9. Applied Case: Illustrative Online Retail Platform

Background

An illustrative retailer operates an online platform on a public cloud. Its monthly bill is £18,000. The platform uses virtual machines, a managed relational database, object storage, log analytics, and inter-region data transfer. Sales grow rapidly during seasonal campaigns.

Problem

The finance team observes a 35% increase in expenditure over three months, while revenue has increased by only 12%. Engineers report acceptable average latency but occasional checkout failures during peaks. Resource ownership is incomplete, and development databases run continuously.

Analysis

The FinOps team exports billing data and joins it with resource labels, monitoring data, and order counts. It finds that:

• 22% of virtual-machine capacity has low utilisation throughout working hours;
• development environments account for 18% of non-production compute;
• log retention is longer than the compliance requirement;
• inter-region transfer is caused by an avoidable application-data access pattern;
• the database is provisioned for the seasonal peak throughout the year;
• cost per order has risen from £0.006 to £0.0075.

The cost-per-order calculation uses attributable monthly platform cost divided by completed orders. It is a managerial indicator, not a complete profitability measure.

Approach and solution

The retailer introduces mandatory ownership labels, a budget for each environment, and anomaly alerts. Development resources are scheduled off outside agreed periods. Compute instances are right-sized after load testing, while high-availability capacity is preserved for production. Database capacity is adjusted using scheduled scaling and a tested peak plan. Log retention is reduced only after security and regulatory review. The application is redesigned to reduce unnecessary cross-region reads. A commitment is purchased only for the measured baseline; seasonal capacity remains pay-as-you-go.

Outcome

After two billing cycles, the platform bill falls to £15,200 during normal demand, while the production service maintains its availability and latency objectives. The seasonal test demonstrates that the platform can scale to peak demand. Cost per order falls to £0.0058. The result is not attributed to one change: it comes from ownership, measurement, architecture, scheduling, and pricing decisions.

Learning points

The case demonstrates that cost optimisation must not be separated from performance and resilience. It also shows why averages and invoices alone are insufficient. A reduction in spending is valuable only when the service continues to meet its agreed requirements.

10. Governance, Ethics, and Limitations

Cloud financial governance must protect confidential billing, customer, and usage data. Access to detailed cost reports should follow least privilege. Allocation data can expose business performance, so reports require appropriate controls.

Ethically, cost reduction must not produce unsafe staffing levels, insecure configurations, discriminatory service degradation, or hidden transfer of costs to customers and communities. Sustainability reporting should be transparent about uncertainty and should not use selective metrics to create misleading environmental claims.

Technical limitations also matter. Provider pricing changes, currency fluctuations, taxes, tier thresholds, minimum charges, regional differences, and data-transfer rules can invalidate an old estimate. Forecasts are models, not guarantees. Load tests may fail to represent real user behaviour. Utilisation metrics can be distorted by sampling intervals or missing telemetry. Every significant business case should state assumptions, time horizon, confidence, and excluded costs.

11. Contemporary Practice and Best Practices

Current cloud operations increasingly combine policy-as-code, infrastructure-as-code, anomaly detection, automated rightsizing recommendations, and machine-learning-assisted forecasting. AI can identify unusual spending or suggest resources for review, but recommendations require human validation. Automated deletion or resizing should have safeguards, maintenance windows, rollback procedures, and exception handling.

Best practices include:

1. Establish ownership before optimisation.
2. Use current provider prices and document assumptions.
3. Separate baseline, variable, and one-time costs.
4. Analyse cost together with usage, performance, reliability, and security.
5. Use budgets and forecasts as management controls, not punishment mechanisms.
6. Right-size from representative measurements, including peaks and failure cases.
7. Commit only to predictable baseline demand.
8. Treat tags and labels as governed data.
9. Review shared-service allocation methods periodically.
10. Include sustainability and exit costs in architecture decisions.
11. Test automated controls before applying them to production.
12. Express optimisation in business units such as cost per transaction, not only total spend.

Chapter Summary

Cloud cost management is a strategic discipline linking billing data, engineering choices, financial planning, service performance, resilience, and sustainability. Billing analysis requires reliable usage data, ownership metadata, and a clear distinction between direct, shared, and indirect costs. Budgets, forecasts, variance analysis, and unit economics help managers interpret expenditure in context.

Capacity planning and right-sizing require measurement of demand, utilisation, latency, saturation, and failure conditions. Pricing models should be selected according to workload predictability and interruption tolerance. Total cost of ownership includes cloud charges as well as migration, labour, licences, connectivity, and transition costs. FinOps establishes an inform–optimise–operate cycle with shared accountability. Sustainable computing reduces waste and environmental impact while respecting performance, security, legal, and resilience requirements. The most defensible decisions are evidence-based, transparent about assumptions, and evaluated against business outcomes.

Key Terms

FinOps: A collaborative operating model for managing cloud economics.

Total cost of ownership: The complete cost of acquiring, operating, and transitioning a technology solution.

Right-sizing: Matching resource capacity to measured workload requirements.

Utilisation: Observed resource use divided by provisioned capacity.

Elasticity: The ability to adjust capacity as demand changes.

Capacity planning: Estimating resources required to meet present and future demand.

Headroom: Capacity reserved for bursts, uncertainty, or failures.

On-demand pricing: Payment for consumption without a long-term commitment.

Committed use: A pricing arrangement based on a commitment to a level or term of consumption.

Spot or preemptible capacity: Discounted capacity that may be interrupted by the provider.

Unit economics: Analysis of cost or value per business unit.

Run rate: An estimate of future spending based on observed spending over a stated period.

Variance: The difference between actual and planned values.

Budget: An approved spending plan.

Forecast: An evolving estimate of expected future spending.

Tag or label: Metadata used to identify ownership, purpose, or allocation.

Service-level objective: A target for reliability or performance.

Sustainable computing: Computing practices that reduce environmental impact while meeting required outcomes.

Shared cost: Expenditure supporting multiple workloads or teams.

Cost anomaly: Unexpected or abnormal spending behaviour.

Review Questions

Short Answer Questions

1. Distinguish cost visibility, cost control, and cost optimisation.
2. Why can average CPU utilisation be insufficient for right-sizing decisions?
3. State two differences between a budget and a forecast.
4. What is the purpose of tags or labels in cloud billing analysis?
5. Name three factors that should be included in total cost of ownership.

Long Answer Questions

1. Explain the FinOps inform–optimise–operate cycle and describe the responsibilities of engineering, finance, and management within it.
2. Compare on-demand, committed-use, and spot or preemptible pricing for different workload patterns.
3. Explain how performance, reliability, cost, and sustainability can conflict in an architecture decision.
4. Describe a disciplined right-sizing process, including measurement, testing, deployment, and review.
5. Discuss the limitations and governance risks of cloud cost forecasts and automated optimisation tools.

Analytical / Application Questions

1. A team spends £9,600 per month to process 1,600,000 transactions. After an architectural change, spending becomes £8,400 and transactions become 1,500,000. Calculate cost per transaction before and after the change, and determine whether unit cost improved.
2. A production service requires two instances to remain available during a single-instance failure. Explain why reducing the service to one instance because average utilisation is low may be inappropriate, and identify measurements needed before a change.
3. Design a FinOps and sustainability plan for a development environment used by three teams. Specify ownership data, budget controls, scheduling, storage lifecycle actions, reporting metrics, and safeguards against disrupting legitimate work.

Multiple Choice Questions with Answers

Question 1

Which practice best supports reliable cloud cost allocation?

A. Using mandatory ownership tags or labels

B. Relying only on the monthly invoice total

C. Assigning all shared costs to the largest team

D. Deleting resource metadata after deployment

Correct Answer: A. Using mandatory ownership tags or labels

Question 2

What is the primary risk of purchasing a commitment based on optimistic growth?

A. The provider will always increase the unit price

B. The committed capacity may be underused

C. The workload will become automatically more secure

D. Network latency will necessarily increase

Correct Answer: B. The committed capacity may be underused

Question 3

A service costs £12,000 and processes 3,000,000 orders in a month. What is its infrastructure cost per order?

A. £0.0004

B. £0.004

C. £0.04

D. £0.40

Correct Answer: B. £0.004

Question 4

Which metric is especially useful for identifying tail-latency problems?

A. Average invoice value

B. 95th-percentile response time

C. Monthly tax rate

D. Number of resource tags

Correct Answer: B. 95th-percentile response time

Question 5

Which workload is most suitable for spot or preemptible capacity?

A. An interruptible, checkpointed batch job

B. A single-instance payment database

C. A service with no retry mechanism

D. A workload requiring guaranteed uninterrupted execution

Correct Answer: A. An interruptible, checkpointed batch job

Question 6

In the FinOps cycle, the inform phase primarily involves:

A. Publishing reliable cost, usage, and ownership data

B. Deleting every low-utilisation resource immediately

C. Replacing all on-demand resources with commitments

D. Disabling monitoring to reduce expenditure

Correct Answer: A. Publishing reliable cost, usage, and ownership data

Question 7

Which statement about utilisation is correct?

A. It is always equal to CPU percentage

B. It compares observed use with provisioned capacity

C. It measures only the monetary price of a resource

D. It proves that a resource can be safely removed

Correct Answer: B. It compares observed use with provisioned capacity

Question 8

Which item is commonly included in a broader TCO analysis but not necessarily in the cloud invoice?

A. Migration labour

B. Compute usage

C. Object storage

D. Data transfer

Correct Answer: A. Migration labour

Question 9

Why should sustainability estimates state their measurement boundaries?

A. Carbon estimates may use different scopes and methodologies

B. Cloud regions never use electricity

C. Cost and carbon are always identical

D. Provider tools cannot measure any operational data

Correct Answer: A. Carbon estimates may use different scopes and methodologies

Question 10

A budget is £10,000 and actual spending is £11,500. What is the percentage variance using (Actual − Budget) ÷ Budget × 100%?

A. 1.5%

B. 10%

C. 15%

D. 115%

Correct Answer: C. 15%