🛠️ Lab 15 — Spot vs. On-Demand vs. Owned: A Build-vs-Buy Cost Model (50 pts)

Goal: Build a spreadsheet-based cost model comparing Spot GPUs, on-demand GPUs, and amortized owned hardware for a target inference workload, and pair it with a hands-on Kubernetes autoscaling demo that shows how autoscaling turns idle capacity into savings. All tools used are free. Steps:

1. Gather public pricing. Open the AWS EC2 Spot Instances page and note the advertised savings (up to \~90% off on-demand), the published historical interruption rate (under 5% for many instance types/regions), and the \~2-minute Spot termination notice. Then open the AWS Pricing Calculator and look up on-demand and Spot pricing for a GPU instance type (e.g., a g5 or p4 family instance) in a region of your choice.
2. Build a spreadsheet (Google Sheets, Excel, or LibreOffice Calc — all free) with a tab called "Spot Break-Even" that computes:
• The expected cost of running a GPU batch job on Spot, including an assumed checkpoint/restart overhead (e.g., "5 minutes of lost work per interruption") added back in as wasted GPU time.
• The same job's cost on pure on-demand pricing (no interruptions).
• A formula that solves for the break-even interruption rate — the interruption frequency at which Spot's savings are fully eaten up by checkpoint/restart overhead, making on-demand cheaper.
3. Add a second tab, "Build vs. Buy," where you pick a target monthly inference volume (e.g., 300M tokens/month) and compute three cost columns side by side:
• Renting on-demand GPUs sized to that volume.
• Renting Spot GPUs sized to that volume (assuming it's a batchable workload).
• An amortized owned-hardware estimate (purchase price / expected useful life in months, plus a DevOps maintenance line — use the \~\$145K/year figure from lecture as your DevOps cost assumption, and add a one-time engineering build cost if relevant).
• Plot or clearly label the crossover point: the utilization or volume level at which owned hardware becomes cheaper than renting.
4. Write a one-paragraph build-vs-buy recommendation underneath your tables, explicitly citing your crossover point and which row of the Week 15 decision framework table (bursty/API, batchable/spot, or steady/self-host) your target workload falls into and why.
5. Local Kubernetes autoscaling demo. Install minikube or kind (both free/local). Deploy a mock inference service (any simple HTTP server that sleeps briefly to simulate GPU inference latency works fine — e.g., a small Python Flask or Node.js app in a container that sleeps 200ms per request). Configure a Kubernetes Horizontal Pod Autoscaler targeting CPU or a custom metric.
6. Drive synthetic load against the mock service (a simple shell loop with curl, or a tool like hey or k6, all free) and observe the HPA scaling replicas up as load increases, then back down as load stops. Capture terminal output or a screenshot showing at least one scale-up and one scale-down event (kubectl get hpa -w and kubectl get pods -w are useful here).
7. Translate replica-minutes into cost. Using the public GPU on-demand rate you looked up in Step 1, estimate what your observed scale-up/scale-down pattern would have cost if each replica were a GPU pod, versus what it would have cost to run the maximum replica count constantly (i.e., no autoscaling). Write 2–3 sentences quantifying the savings.

Deliverables: Submit your spreadsheet (Google Sheets link or exported .xlsx/.csv) with both tabs completed, your build-vs-buy recommendation paragraph, a screenshot or terminal log showing the HPA scale-up/scale-down event, and your 2–3 sentence cost-savings estimate — combined into a single document or zip file uploaded to Canvas.