Project 12 — Deploy in the Cloud, Read the Bill

“For where your treasure is, there your heart will be also.” — Matthew 6:21 (ESV)

Chapter: 12 — Cloud Systems Administration and Counting the Cost Due: End of Week 12 Submit: A link to a public GitHub repository containing your deployment artifacts (IaC/config or deploy scripts), your FinOps configuration, a COST_REPORT.docx, your agent-log.txt, and a one-page DECISION_MEMO.docx. See Appendix A and Appendix B. Allowed tools: Any one AI platform — see Pick your platform first, below. The OpenAI-compatible SDK; your provider’s billing/cost-export console; Python/bash. This project can be completed for $0. If you do choose to spend, spend a few dollars, not a few hundred. AI policy: Phase 2. AI is part of the work and may be agentic. You must keep an agent-log.txt (what you delegated, what it did, where it was confidently wrong — especially about prices and units — and where you intervened). The project is shaped so an agent cannot finish it for you: the judgment in the Hard tier memo is yours. See Appendix C.

Pick Your Platform First (read this before you create any account)

The graded skill in this project is forecasting a cost and then reconciling it against what actually got metered. That skill is identical on every platform. The vendor is not the lesson — so pick the path with the least friction and spend your hours on COST_REPORT.docx, not on a signup form.

Work down this list and stop at the first one you can get into:

Do not deploy this project on Amazon Bedrock. Bedrock is worth reading about — §12.2 covers it as one of the big four, and its “model unit” is one of the lock-in units you will analyse in the Medium and Hard tiers — but it is the worst possible place to start. It authenticates with full AWS IAM rather than a simple key, the account needs a verified payment method before it activates, and then you must separately request access to each model before a single call works. Students lose days to this. Analyse Bedrock from published pricing; deploy somewhere else.

You never need an account with more than one provider. The Medium tier’s provider comparison is done from published per-token prices, not from live accounts.

The no-cost path (Path 4) — full credit, zero dollars

If you run a local model, there is no invoice to pull. Do this instead, and you can still earn every point:

• Predict exactly as written below, using token_cost.py with the published prices of a named commercial model. You are forecasting what this workload would cost on that platform.
• Run your fixed volume against your local endpoint and capture the real measured token counts from the usage field.
• Reconcile your prediction against those measured tokens priced at the published rate, and against code/sample-bill.csv — the billing export shipped with this chapter for exactly this purpose. Explain the same gap: where did your token estimate miss, and why?
• In COST_REPORT.docx, state plainly that you used the no-cost path and report $0.00 actual spend. There is no grade penalty for this. A careful $0 reconciliation beats a sloppy $4 one.

The Setup

Grace & Mercy Relief is a mid-sized Christian relief organization. Donations spiked after a disaster, and the small IT team is drowning in donor correspondence and field-report triage. The board has approved a modest budget for an AI assistant — and, having been burned once by a “quick experiment” that left a GPU running over a holiday weekend and cost four figures, the board has attached one non-negotiable condition: whoever builds it must be able to read the bill and defend every dollar.

You are that administrator. Your job is not merely to make the assistant work. Anyone can make it work. Your job is to deploy it, instrument it so the cost is visible, drive real traffic through it, and then read the bill and write the analysis a steward could defend to a board. The treasure here is donor data and the org’s limited money; you will count the cost of keeping it in the cloud — in dollars and in dependence.

Setup (the starter)

This chapter’s code/ holds your starting instruments:

• code/token_cost.py — a per-token / per-volume cost calculator. Use it for predictions and to cross-check your actual bill.
• code/finops_alerts.sh — a reference FinOps daily-spend / per-tag / threshold-alert script to adapt to your provider’s billing export.
• code/deploy-notes.txt — a short, provider-agnostic checklist for standing up a serverless model endpoint or a self-hosted GPU instance, and where to find each provider’s cost export.
• code/sample-bill.csv — a synthetic billing export to practice reconciliation against before your real bill lands.

Learning Targets

You will demonstrate that you can:

• Deploy a real AI workload to a cloud platform and drive a measured, repeatable volume of traffic through it.
• Predict a workload’s cost before running it, then reconcile prediction against the actual bill and explain the gap.
• Wire FinOps controls — cost-allocation tags, a budget, an alert, and (where supported) a hard cap — before launch.
• Compare the same workload’s cost across providers and across billing models (serverless vs. reserved), and locate the crossover.
• Make and defend a build-vs-buy / self-host-vs-API architecture decision that weighs dollars against data residency, lock-in, and operability — a call an agent cannot make for you.

Normal Tier

Goal: Deploy a serverless AI workload, instrument its cost, run a fixed volume, and reconcile predicted cost against the actual bill.

Required features

1. Deploy. Stand up a working AI workload on the platform you picked above: a serverless model-API endpoint (call a hosted model), a self-hosted open-weight model on a cloud GPU instance, or a local model endpoint (Path 4). The app must do something concrete (e.g., draft donor thank-you letters from a small synthetic record set — use only synthetic PII, never real personal data).
2. Tag. Apply cost-allocation tags (project, env, team) to every billable resource/key the platform allows. (Path 4: name the tags you would apply and where they would go — the design is the point.)
3. Budget + alert. Configure a monthly budget and at least one alert threshold (e.g., 80%) before you generate traffic. (Path 4: state the budget and threshold you would set, and show where in the console it lives.)
4. Predict. Using code/token_cost.py, write down the cost you expect for a fixed run (e.g., 500 requests at a stated token shape) before running it. Record it in COST_REPORT.docx.
5. Run. Drive the fixed request volume through the workload. Capture the request/token counts from the usage field on every call.
6. Reconcile. Put predicted vs. actual side by side in COST_REPORT.docx and explain the gap (cached input? a tier you forgot? overhead?). Pull “actual” from your provider’s billing/cost export if you used Paths 1–3, or — on Path 4 — from your measured token counts priced at the published rate, cross-checked against code/sample-bill.csv.

Normal-tier rubric (out of 100)

No path earns fewer points than another. A $0 submission on Path 4 and a $4 submission on Path 1 are graded identically. What is being graded is whether you predicted before you ran, and whether you can explain the difference afterward.

Medium Tier (+up to 25% extra credit)

Goal: Make it a comparison, not a single data point.

• Provider comparison. Price the same workload (same token shape and volume) across at least two of the big-four catalogs, using published per-token snapshots, and present a table. Show that the model can be the same while the bill differs — the model is the same, the bill is the vendor. This is desk research from published price pages — you do not need an account with either provider, which is exactly how you can analyse Bedrock without ever signing up for AWS.
• Reserved-vs-serverless crossover. For your workload’s projected monthly volume, compute (and chart, even roughly) where reserved capacity would overtake serverless per-token. State the volume at which you’d switch, using the ~150–200M-token third-party rule of thumb (flag it as third-party, not vendor-official), and adjust it for your workload’s duty cycle.
• Tier sweep. Run the workload on at least two model tiers (a flagship and a cheaper tier), report the cost difference and a quick quality judgment, and recommend a tier with evidence.

Document each in COST_REPORT.docx with tables and your reasoning.

Hard Tier (+up to 25% additional extra credit)

Goal: Make the call only a human can make, and defend it.

Write DECISION_MEMO.docx (~1 page) for a sensitive-data version of the scenario: the assistant must touch donor PII (names, gift amounts, contact info). Make a defensible build-vs-buy / self-host-vs-API recommendation that weighs:

• Dollars — your measured/projected cost across the options, with the crossover.
• Data residency — what it means to send donor PII to a third-party model API vs. keep it in your boundary (and the “rent the GPU, self-host the model” middle path from §12.5).
• Lock-in — the abstract-unit dependence (PTU/model-unit/GSU), egress cost, and whether you wrote against a portable /v1 endpoint.
• Operability — whether this specific team can actually run the option you recommend at 2 a.m.

End the memo with a single, signed recommendation and the one column that decided it. Then add the theological paragraph (see the footnote below): where is this org’s treasure, and what does it cost — in dollars and in dependence — to keep it elsewhere? This is the deliverable an agent cannot produce: it requires a judgment, an accountable owner, and a value the spreadsheet does not contain.

Submission

Push a public GitHub repo containing:

• Deployment artifacts (deploy scripts / IaC / config — reproducible, no secrets, placeholder keys only).
• Your adapted FinOps script and a note on the budget/alert/cap you configured.
• COST_REPORT.docx (Normal + any Medium work).
• DECISION_MEMO.docx (Hard tier).
• agent-log.txt (required — Phase 2).
• A README.txt with run instructions, which path (1–4) you took, and your total real spend (be honest; $0.00 is a valid and expected answer).

Hints (Read Before You Begin)

• Don’t let a signup form eat your week. If you cannot get into a platform within about thirty minutes, stop and drop to the next path in the table above. Nobody has ever learned FinOps from an account-verification screen. If you are already stuck, take Path 4 and finish the project today.
• Predict first, every time. The graded skill is forecasting, not reading a number after the fact. Write the prediction down where you can’t fudge it.
• Free/low tiers are your friend. You do not need a big spend to learn this — a few hundred real requests is plenty, and $0 is a perfectly good number. The lesson is in the reconciliation, not the size of the bill.
• Tag before you run, budget before you run, cap before you run. A control you wire after the scary bill is a lesson learned the expensive way.
• Re-verify every price. The chapter’s prices are mid-2026 snapshots and will have drifted. Pull live numbers from the console; note the date you pulled them.
• Use synthetic PII only. Never put real personal data into a homework deployment, especially one calling a third-party API. That is itself the lesson of the Hard tier.
• Watch idle resources. If you self-host on a GPU instance, schedule it to stop. An H100 left running over the weekend is the classic cost incident.

What Mastery Looks Like (Beyond the Rubric)

A passing submission deploys, tags, budgets, and reconciles. A masterful one reads like something a board would trust: the predicted-vs-actual gap is explained with a real cause, the provider comparison makes the lock-in visible, and the Decision Memo names a number and a non-dollar reason and stands behind it. Mastery is when a reader finishes your DECISION_MEMO.docx and thinks, this person counted both ledgers and I would let them sign the invoice.

Coach’s Note — The temptation on this project is to make the deployment fancy and the cost analysis thin. Resist it. Nobody on the board cares how clever the deployment is; they care whether you can tell them what it costs and why, and whether you’d have caught the runaway before it bit. Spend your last hour on COST_REPORT.docx and DECISION_MEMO.docx, not on the demo.

When You’re Done

• Workload deploys and runs from a clean clone of your repo.
• Every billable resource is tagged; a budget and alert were set before the run.
• COST_REPORT.docx shows predicted vs. actual with the gap explained.
• (Medium) Provider comparison + reserved-vs-serverless crossover + tier sweep documented.
• (Hard) DECISION_MEMO.docx makes one signed, defensible build-vs-buy call with the deciding column named.
• agent-log.txt is honest about where AI helped and where it was wrong.
• No real secrets; no real PII; total real spend reported.

A theological footnote. “For where your treasure is, there your heart will be also” (Matthew 6:21, ESV). This project is, on its face, about a bill. But the bill is a confession. What Grace & Mercy Relief chooses to keep on someone else’s computer — its donors’ data, its dependence, its money — reveals what it has decided to treasure and to entrust, and the heart follows the treasure there. A faithful steward counts both ledgers: the dollars the console shows, and the dependence it doesn’t — the lock-in unit, the deprecation schedule, the data that left the boundary. The cloud is often exactly right, and refusing a good tool out of false piety is no virtue; “it is required of stewards that they be found faithful” (1 Corinthians 4:2, ESV), and faithfulness is honest accounting, not asceticism. Your Decision Memo is where you give that account. Write it like someone will have to answer for it — because someone will.

See you next week.