Exercise 1: Why Thumbnail Generation Belongs on Lambda, Not the Web Servers — Possible Solution
====================================================================

Thumbnail generation is a short, event-driven, bursty task -- it only
needs to run for a few seconds, only when a new photo is actually
uploaded, and the number of uploads at any given moment is genuinely
unpredictable. Chapter 7 established that Lambda's own real pricing
model charges only for actual requests and execution duration, with
nothing at all charged while no function is running.

Running this same job continuously on the Step 4 EC2 web servers
instead would mean paying for that capacity around the clock,
regardless of whether anyone is actually uploading a photo at any
given moment -- exactly the always-on billing model Chapter 7
contrasted directly against Lambda's own pay-only-when-running
approach. It would also unnecessarily couple image-processing load to
the same servers handling real user-facing web traffic, meaning a
burst of uploads could compete for the same CPU capacity the web tier
needs for ordinary requests.

ANSWER: Lambda is the better fit because the workload is short,
bursty, and event-driven -- exactly the shape Chapter 7 identified as
where serverless is often dramatically cheaper than an always-on EC2
instance, since there's no idle-time cost between invocations, and no
competition with the web tier's own separate, steady traffic load.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly applies Chapter 7's own specific cost/execution-model
reasoning (idle-time cost, event-driven fit) to this capstone's real
scenario, rather than just asserting "Lambda is for small tasks" in
the abstract, and adds the real, additional resource-contention
argument for keeping this workload off the web tier entirely.