Choose your route

Route A: Career changers (software, IT support, networking, data)

You will learn through hands-on measurement & simple models. Your goal is to make reliable estimates, interpret dashboards & explain trade-offs clearly.

Route B: Students & recent graduates (CS, engineering, maths)

You will convert what you already know into cloud-native decision making. Your goal is to reason about systems under real constraints like variable demand, noisy metrics & budgets.

Same topics either way. The difference is whether you start from code & tooling or from theory & tidy examples.

Why this maths matters in cloud roles

Cloud work is about delivering services that are reliable, performant & cost-effective. Major cloud frameworks are built around these pillars. AWS Well-Architected highlights pillars including reliability, performance efficiency & cost optimisation. AWS Documentation Azure’s Well-Architected Framework also emphasises similar pillars. Microsoft Learn

In practice hiring managers look for people who can:

• Estimate load & choose a sensible scaling approach

• Read monitoring data & separate real incidents from normal noise

• Set SLOs that match user expectations then manage error budgets

• Make cost decisions using unit economics rather than guesswork

• Explain trade-offs in plain English to engineers, product & finance

That is applied maths. It is also one of the fastest ways to stand out as a UK job seeker because it shows you can operate in production reality.

The only maths topics you actually need for cloud jobs

1) Units, rates & “cloud arithmetic” (the most underrated skill)

Cloud work is full of rates: requests per second, messages per minute, MB per day, GB per month, CPU seconds, error percentage, p95 latency. If you can translate between units quickly you become the person who can sanity-check designs.

What you actually need

• Bits vs bytes (and the common multiples KB, MB, GB, TB)

• Throughput: MB/s, Gb/s, requests/s

• Latency as time: milliseconds, seconds, timeouts

• Storage growth: GB/day → TB/month

• Percentages & ratios: error rates, cache hit rate, compression ratio

• Simple “per unit” thinking: cost per request, cost per user, cost per GB

Cloud examples that come up in interviews

Example: traffic to capacity

• If you expect 500 requests/s at peak

• Each request uses ~20 ms of CPU time on average

• Total CPU time per second ≈ 500 × 0.02 = 10 CPU-seconds per second
  That implies roughly 10 fully utilised CPU cores at peak before overhead, bursts & safety margin.

You do not need exactness. You need a plausible answer and you need to say what assumptions you made.

Example: log volume

• 2 KB per request

• 500 requests/s peak

• Data per second ≈ 1,000 KB/s ≈ 1 MB/s

• Per day ≈ 86,400 MB ≈ 86.4 GB/day
  That one estimate can prevent an unpleasant billing surprise.

Route A learning method

Pick one service you know (a web API, a queue consumer, a batch job). Practise translating:

• requests/s → CPU → cores

• events/s → storage/day

• latency target → timeout settings

Route B learning method

Practise writing assumptions explicitly:

• peak vs average load

• mean vs p95 latency

• compression ratio

• retention periods

This is exactly how architects write design notes.

2) Statistics for reliability & observability (percentiles, error rates, SLOs)

Cloud systems are noisy. Metrics vary. Averages hide pain. Most real user experience is captured by percentiles and error rates not by mean values.

What you actually need

• Mean vs median vs percentiles (p50, p95, p99)

• Variability & why “spiky” workloads behave differently

• Error rate as a proportion: errors / total requests

• Basic sampling intuition: why small sample sizes mislead

• SLOs & error budgets

Google’s SRE workbook defines an error budget as 1 minus the SLO and gives a concrete example where a 99.9% SLO implies a 0.1% error budget and 1,000 errors allowed per million requests over a period. sre.google This is extremely “cloud interview relevant” because it ties reliability goals to operational decision making.

How this shows up in cloud jobs

• Setting alert thresholds

• Choosing whether a release is safe

• Explaining whether performance improved “enough”

• Writing runbooks that include clear SLO impact

A simple SLO workflow you can use in projects

1. Pick a user journey: “Checkout API returns 2xx”

2. Define an SLI: % of requests under 300 ms and 2xx

3. Set an SLO: 99.9% over 28 days

4. Calculate error budget: 0.1% of requests in that window sre.google

5. Create an error budget policy: what happens when burn rate is high sre.google

Route A learning method

Use a dashboarding mindset:

• practise reading p95 latency charts

• practise computing error rate from logs

• practise explaining what changed after an incident

Route B learning method

Build comfort with “metrics as distributions”:

• write down why p95 matters

• explain why averages hide tail latency

• define an SLO that matches a real user expectation

3) Capacity planning & queueing intuition (Little’s Law & utilisation)

Most scaling problems boil down to one of two things:

• you do not have enough capacity

• you have capacity but it is stuck behind a bottleneck (queue, lock, downstream dependency)

You do not need full queueing theory. You need two reliable intuitions:

• utilisation near 100% creates queues

• queues create latency and timeouts

What you actually need

• Utilisation as a fraction: used / available

• The idea that once utilisation is high, small load increases cause big latency jumps

• Little’s Law: L = λW which relates average number in system (L), arrival rate (λ) and average time in system (W) Wikipedia

• Headroom thinking: plan for burst and failure modes not just average

How it shows up

• Designing autoscaling targets

• Setting queue length alerts

• Estimating how many workers you need to drain a backlog

• Explaining why “CPU is only 60%” can still mean “system is slow” due to I/O or downstream constraints

Example: backlog drain estimate

• You have 1,000,000 messages

• Each worker processes 20 messages/s sustained

• You run 10 workers
  Throughput = 200 messages/s
  Drain time ≈ 1,000,000 / 200 = 5,000 seconds ≈ 1.4 hours

This is the kind of quick maths that makes you look very employable.

Route A learning method

Use a queue + worker demo:

• generate jobs at a rate

• process jobs at a rate

• watch what happens when arrival rate exceeds service rate

Route B learning method

Write a one-page capacity note:

• workload assumptions

• bottleneck analysis

• scaling policy approach

Azure’s Well-Architected guidance explicitly mentions predictive modelling to forecast capacity and avoid shortages or overprovisioning which links performance with cost and reliability. Microsoft Learn

4) Cost modelling & FinOps maths (cost per unit, break-even, right-sizing)

Cloud billing is maths. If you do not model costs you end up discovering your architecture through invoices.

FinOps is widely described as an operational framework and cultural practice to maximise business value from cloud with data-driven decisions and financial accountability through collaboration. FinOps FinOps principles also emphasise cross-team collaboration and taking advantage of the variable cost model. FinOps

What you actually need

• Cost per unit: per request, per user, per GB stored, per GB transferred

• Fixed vs variable costs

• Break-even thinking: commitment discounts vs flexibility

• Forecasting using basic growth models

• Sensitivity analysis: what happens if traffic doubles or retention changes

Practical cloud cost maths that helps in interviews

Cost per 1,000 requests

• compute data egress per request

• compute average CPU time per request

• add storage for logs or traces per request

• create a simple spreadsheet of monthly cost components

Storage retention
Retention is a multiplier. If you keep logs 30 days vs 7 days, your steady-state storage is roughly 4× larger.

Estimating costs with official tools
AWS provides the AWS Pricing Calculator for estimating AWS costs for use cases. calculator.aws Even if you are not an AWS specialist, building the habit of cost estimation is a transferable skill.

Route A learning method

Make cost tangible:

• build a mini “monthly cloud bill” model in a spreadsheet

• vary inputs: traffic, retention, instance size

• explain which variable dominates cost

Route B learning method

Write cost assumptions in a design doc:

• unit of measure for each cost

• expected baseline and expected peak

• safety margin

• risk section: unknown unknowns

5) Trade-off optimisation (performance vs reliability vs cost)

Cloud work is rarely about “maximising” one thing. It is about meeting targets within constraints.

AWS Well-Architected explicitly frames guidance around reliability, performance efficiency and cost optimisation as distinct concerns you must balance. AWS Documentation Azure’s Well-Architected guidance similarly focuses on performance efficiency and scaling strategy choices. Microsoft Learn

What you actually need

• A simple objective: “p95 latency under 300 ms” plus “monthly cost under £X”

• Constraints: “must survive one-zone failure” or “must meet RPO/RTO”

• Iteration: measure, change one thing, measure again

• Avoiding optimisation theatre: do not chase micro wins before fixing big cost drivers

Real trade-offs you can talk about in interviews

• Caching reduces latency and cost but increases complexity and staleness risk

• Overprovisioning reduces incident risk but increases cost

• Tight timeouts reduce resource waste but can increase perceived errors if mis-set

• Higher replication improves availability but increases write cost and operational overhead

If you can talk about these trade-offs with numbers and assumptions you will sound like someone who has actually operated systems.

A 6-week maths plan for cloud jobs

Aim for 4–5 sessions per week of 30–60 minutes. Each week creates one output you can publish.

Week 1: Cloud units & rate maths

Build

• A short notebook that converts between bytes, GB/day and TB/month

• A simple throughput calculator (requests/s to MB/s to storage/day)
  Output

• “Cloud arithmetic cheat sheet” + working examples

Week 2: Percentiles, error rates & basic dashboards

Build

• A small dataset of request times and status codes

• Compute p50, p95, p99 and error rate
  Output

• A dashboard-style notebook that explains what changed when latency shifts

Week 3: SLOs & error budgets

Build

• Choose a service SLI and SLO

• Implement error budget calculation using the SRE definition (1 − SLO) sre.google

• Create a simple error budget policy paragraph sre.google
  Output

• A repo called “SLO starter kit” with clear README

Week 4: Capacity planning & queues

Build

• A queue simulator or a worker backlog drain model

• Demonstrate Little’s Law relationship L = λW with your simulated system Wikipedia
  Output

• A capacity note: assumptions, bottlenecks, scaling approach

Week 5: Cost modelling & FinOps basics

Build

• A spreadsheet that calculates monthly cost from inputs

• Add cost per unit metrics and a sensitivity analysis

• Reference FinOps framing: value, accountability, collaboration FinOps
  Output

• “Cost per request” model plus a one-page explanation

Week 6: Capstone design with measurable targets

Build

• A reference architecture for a simple service

• Define SLO targets, scaling plan and cost target

• Include a small load test plan and reporting format
  Output

• A portfolio-grade README that reads like a real design review

Portfolio projects that prove your maths to employers

Project 1: SLO & error budget calculator

What it shows

• reliability maths that maps directly to SRE style roles
  What to build

• inputs: SLO %, time window, request volume

• outputs: allowed errors, burn rate guidance, simple policy text sre.google

Project 2: Load test + percentile report

What it shows

• you understand percentiles and performance targets not just “it feels fast”
  Tools

• Grafana k6 is a widely used open source load testing tool with clear docs. Grafana Labs
  What to deliver

• test script, results, p95 and p99 interpretation, next optimisation step

Project 3: Queue backlog & autoscaling simulator

What it shows

• capacity planning with numbers not vibes
  What to include

• backlog drain time

• impact of adding workers

• failure scenario: one worker group lost

Project 4: FinOps cost per transaction model

What it shows

• cost awareness and stakeholder communication
  What to include

• cost per 1,000 requests

• top cost drivers

• what you would change first and why
  Helpful tool

• AWS Pricing Calculator for estimates if you choose an AWS example. calculator.aws

How to write this on your CV

Replace “strong analytical skills” with outcomes like:

• Built an SLO and error budget calculator with a documented error budget policy aligned to SRE practice sre.google

• Analysed service latency using p95 and p99 percentiles and produced a performance report with clear recommendations

• Modelled queue backlog drain times and scaling headroom using capacity assumptions and Little’s Law intuition Wikipedia

• Created a cost per request model using FinOps principles to support data-driven cloud spend decisions FinOps

Resources & learning pathways

Cloud architecture frameworks (how cloud teams think)

• AWS Well-Architected Framework pillars including reliability, performance efficiency and cost optimisation. AWS Documentation

• Azure Well-Architected Framework pillars and guidance including performance efficiency principles and scaling strategy recommendations. Microsoft Learn

SLOs, error budgets & reliability practice

• Google SRE workbook on implementing SLOs and creating error budget policies. sre.google

FinOps & cloud cost practice

• FinOps definition and overview plus principles focused on collaboration and value from variable cloud costs. FinOps

• AWS Pricing Calculator for creating cost estimates. calculator.aws

Observability foundations (metrics, logs, traces)

• OpenTelemetry documentation describes telemetry signals including traces, metrics and logs and provides an observability primer. OpenTelemetry

Performance testing for your portfolio

• Grafana k6 documentation for running tests and working with performance testing concepts. Grafana Labs

Next steps

Pick one target role family (Cloud Engineer, DevOps, Platform, SRE or FinOps) then complete the 6-week plan while applying. Publish your outputs with short READMEs that state assumptions, show calculations, include charts and explain decisions.

In cloud hiring, people who can quantify trade-offs and communicate them clearly are often the people trusted with production systems.