Cost and security fundamentals

⏱ 30 min

Hook

Two Monday-morning emails end careers-in-miniature. The first is a billing alert: a test cluster someone spun up "just for an hour" ran all weekend and burned $2,400. The second is worse — a security researcher reports that a storage bucket holding customer records was readable by anyone on the internet, because a single access setting was left wide open. Neither took a sophisticated attacker or an exotic bug. Both came from not asking two ordinary questions: what does this cost, and who can reach it. This lesson makes both questions routine.

Concept

Cloud billing is pay-per-use: you are charged for what you consume, metered finely, with no upfront purchase. That is the appeal and the trap. There is no gate that stops a forgotten resource from accruing charges, so cost becomes an engineering property you design for, not a bill you react to. The discipline the whole school insists on is one sentence you attach to every design: what does this cost per month?

Answering it means knowing the cost drivers — the handful of things a data workload is actually billed on. For nearly every data service, the bill reduces to three:

Cost driver	Metered as	Typical example rate	What moves it
Storage	GB stored per month	$0.023 per GB-month	Data volume and retention
Egress	GB leaving a boundary	$0.09 per GB	Cross-region / internet
Compute	Hours (or bytes work)	$0.0116 per hour	Run time and machine size

Those rates are illustrative and vary by provider and region, but the shape is universal, and two properties of it trip people up. First, egress is asymmetric: putting data into the cloud is usually free, but pulling it out — across regions or to the internet — is not. This is exactly the boundary-crossing from Lesson 1, now with a price on it. Second, compute bills for wall-clock time it is on, not for useful work done: an idle cluster costs the same as a busy one. The forgotten weekend cluster was 60-plus hours of compute nobody used.

Cost has a security twin, and it is least privilege: every identity should have the minimum access it needs to do its job, and nothing more. An identity is a principal that can act — a user, or a role a service assumes. A policy is the rule set attached to it saying which actions on which resources are allowed. The habit is to start from deny everything and grant narrowly: a reporting job that reads one prefix of one bucket gets exactly that, not read-write on the whole account. The open-bucket disaster is the opposite habit — access granted broadly "to make it work," never narrowed. Least privilege limits the blast radius when credentials leak or code misbehaves, and like cost, it is cheapest to build in from the first day rather than retrofit after an incident.

🧠 Knowledge check

1. What makes pay-per-use billing a trap for the careless?

a) It charges a large fixed fee upfrontb) Nothing automatically stops a forgotten resource from accruing chargesc) It only bills once per year, so mistakes compoundd) It refuses to run compute unless a budget is set

2. Which best states the least-privilege habit?

a) Grant broad access first, then remove what causes problemsb) Give every identity full account access to avoid blockersc) Start from deny-everything and grant only the minimum access neededd) Share one admin credential so access is easy to manage

Worked example

Let me estimate a small pipeline's monthly bill by hand, because the arithmetic is the whole skill. Scenario: a curated dataset holds 200 GB in object storage, a daily job runs 2 hours a day (about 60 hours a month), and a dashboard pulls 30 GB out to users across a region boundary each month.

I compute each driver separately, then sum — and I write it as code so the estimate is reproducible rather than a mental guess:

STORAGE_RATE = 0.023   # dollars per GB-month
EGRESS_RATE = 0.09     # dollars per GB
COMPUTE_RATE = 0.0116  # dollars per compute-hour

storage_gb = 200
egress_gb = 30
compute_hours = 60

storage_cost = storage_gb * STORAGE_RATE
egress_cost = egress_gb * EGRESS_RATE
compute_cost = compute_hours * COMPUTE_RATE
monthly = storage_cost + egress_cost + compute_cost

print(f"storage: ${storage_cost:.2f}")
print(f"egress:  ${egress_cost:.2f}")
print(f"compute: ${compute_cost:.2f}")
print(f"monthly total: ${monthly:.2f}")

storage: $4.60
egress:  $2.70
compute: $0.70
monthly total: $8.00

Eight dollars a month, and — just as usefully — I can now see where it would grow. Storage dominates, so a careless retention policy that hoards old data is the biggest risk; egress is the next lever, which is why keeping the dashboard in the same region matters. The security estimate runs in parallel: this pipeline's job needs read on one prefix and write on one output location, so its role gets precisely those two grants — not the account-wide access that would let a bug or a leaked key touch everything. Cost and access, answered together, before a single resource is created.

Hands-on

Your turn, with different numbers. The exercise below gives you a workload's storage, egress, and compute-hours plus the per-unit rates and asks you to return its monthly bill, then flag the single driver that contributes the most. It runs in Python Arena, so there is nothing to install.

▶ Python Arenacd101-estimate-the-bill

Open in Python Arena ↗

Success criteria: your monthly total matches the expected figure to the cent, and your "biggest driver" is the dimension with the highest individual cost. The Arena validates your output against a hidden set of workloads automatically.

Recap

• You can explain pay-per-use billing and why cost is an engineering property you design for rather than a bill you react to.
• You can name the three cost drivers of a data workload — storage, egress, and compute — and estimate a monthly bill from them, accounting for egress being asymmetric and compute billing for wall-clock time.
• You can state the least-privilege habit and grant an identity only the minimum access its job needs, from a deny-everything default.

Next up: the lab, where you turn this estimation into a reusable cloud cost-calculator that computes a monthly bill and flags any configuration that would spill out of the free tier.

🧠 Knowledge check

1. In the worked example, storage was the largest cost. What does that most directly suggest watching?

a) The number of users on the dashboardb) Data volume and retention policy, since stored GB drive the biggest chargec) The programming language of the daily jobd) The color of the dashboard theme

2. Why is egress called asymmetric, and why does it matter for a dashboard?

a) Uploading data costs more than downloading it, so avoid uploadsb) Data going into the cloud is usually free, but pulling it out across a boundary is billedc) Egress is free in every region, so it never mattersd) Egress only applies to compute, not to data movement

📌 Key takeaways

• Pay-per-use has no safety gate, so cost is designed for up front with the question "what does this cost per month?" - A data bill reduces to three drivers — storage, egress, and compute — and egress is asymmetric while compute bills for wall-clock time. - Least privilege grants each identity only the minimum access its job needs, from a deny-everything default, limiting the blast radius of any leak.