Thuta Learning
BasicDevOps & Toolsintermediate

Cloud Cost Basics

What you'll walk away with

  • Explain the core ideas behind Cloud Cost Basics
  • Read the diagram/table and identify how these platform categories differ
  • Explain how you would choose the right platform category for a real project

Build the mental model

A cloud bill can look intimidating at first glance, but the categories that typically get charged form a fairly small, consistent set.

  • Compute — time a server runs
  • Storage — volume of data kept
  • Database — a managed database instance
  • Bandwidth/Egress — data leaving to the outside world
  • Requests — number of API calls
  • Build minutes — time spent compiling and deploying
  • Logs — log storage volume

The single most important distinction is fixed cost versus usage-based cost. A fixed cost charges roughly the same amount regardless of traffic. A usage-based cost scales with actual consumption.

Free tier does not mean free forever

Free tier means usage is free only up to a defined limit — cross it and charges begin. Real production traffic can exceed that limit without warning, and free tier does not mean free forever in production.

text
COST BREAKDOWN MAP
------------------
COST BREAKDOWN MAP
---------------------

  Compute   ---\
  Storage   ----\
  Database  -----\
  Bandwidth ------>---[ TOTAL CLOUD BILL ]
  Requests  -----/
  Build     ----/
  Logs      ---/

  Each category can be FIXED (same cost every period)
  or USAGE-BASED (scales with consumption). Most bills
  mix both types across different categories.

Connect it to a real scenario

This example never touches a real pricing number — it's here purely to show the STRUCTURE of a cost bill.

It sets an illustrative placeholder unit cost for four categories — compute, storage, bandwidth, and requests — and computes a rough relative percentage breakdown.

Learn the structure, not the numbers

The value here is not the dollar figure — it's seeing which category is driving the total.

Free tier is not 'free forever'

As production traffic grows, it's easy to exceed free tier limits and get an unexpectedly large bill. Before launch, compare your expected usage against the free tier's actual limits.

Try the working example

javascript
function estimateCostBreakdown(usage) {
  // ILLUSTRATIVE placeholder unit costs only - NOT real provider pricing
  const illustrativeUnitCost = {
    computeHours: 0.05,
    storageGB: 0.02,
    bandwidthGB: 0.09,
    requestCount: 0.0000004
  };

  const rawCost = {
    compute: usage.computeHours * illustrativeUnitCost.computeHours,
    storage: usage.storageGB * illustrativeUnitCost.storageGB,
    bandwidth: usage.bandwidthGB * illustrativeUnitCost.bandwidthGB,
    requests: usage.requestCount * illustrativeUnitCost.requestCount
  };

  const total = Object.values(rawCost).reduce((sum, n) => sum + n, 0);
  const breakdownPercent = {};
  for (const category in rawCost) {
    breakdownPercent[category] = Math.round((rawCost[category] / total) * 1000) / 10;
  }

  return {
    estimatedTotalUnits: Math.round(total * 100) / 100,
    breakdownPercent
  };
}

const smallApiWorkload = {
  computeHours: 720,
  storageGB: 50,
  bandwidthGB: 200,
  requestCount: 2000000
};

console.log(JSON.stringify(estimateCostBreakdown(smallApiWorkload), null, 2));
You should see
{
  "estimatedTotalUnits": 55.8,
  "breakdownPercent": {
    "compute": 64.5,
    "storage": 1.8,
    "bandwidth": 32.3,
    "requests": 1.4
  }
}

(units are placeholders, not real pricing — this shows that compute and bandwidth drive most of the bill in this scenario)

5-minute try-it

Increase `bandwidthGB` to 2000 and re-run it. Watch how the breakdown percentages shift, and think about what that implies for a real app whose egress traffic grows a lot.

One important caution

Assuming free tier means 'never charged,' rather than 'free up to a limit'

Ignoring bandwidth/egress cost while focusing only on compute cost

Wikipedia: Cloud computing (pricing models section)Cloud Providers & Platforms

Easy traps

  • Assuming free tier means 'never charged,' rather than 'free up to a limit'
  • Ignoring bandwidth/egress cost while focusing only on compute cost
  • This course teaches the provider/platform landscape at comparison level only -- for hands-on depth on AWS, Docker, CI/CD, Firebase, or deployment fundamentals, continue to the AWS Fundamentals, Docker, CI/CD, Firebase, or Cloud & Deployment tutorials.

Exercise

Increase `bandwidthGB` to 2000 and re-run it. Watch how the breakdown percentages shift, and think about what that implies for a real app whose egress traffic grows a lot.

You'll know it worked when: { "estimatedTotalUnits": 55.8, "breakdownPercent": { "compute": 64.5, "storage": 1.8, "bandwidth": 32.3, "requests": 1.4 } } (units are placeholders, not real pricing — this shows that compute and bandwidth drive most of the bill in this scenario)