An internal city-hall form API is invoked only a few dozen times per day and has no need for a persistent server. Which design most reduces idle compute cost?
Select an answer to reveal the explanation.
Short Explanation
A sleepy internal form doesn't need a server humming all night like a vacant lobby with the lights on. Lambda bills when someone actually hits the form—perfect for rare city-hall traffic.
Full Explanation
Implementing the internal city-hall form API with AWS Lambda is the correct design to reduce idle compute cost when the API is invoked only a few dozen times per day and needs no persistent server, because Lambda bills primarily for invocations and duration rather than for hours of idle EC2. Sparse municipal forms—vacation requests, simple intake—fit that duty cycle and avoid paying for a lobby left lit all night. Keeping a large always-on EC2 instance in a public subnet fails because idle hours still bill and a public subnet placement adds unnecessary exposure for an internal form. Running the API on a Dedicated Host sized for peak parade season fails by locking in expensive tenancy and peak capacity for a low-duty internal workload. Placing the form behind Global Accelerator to eliminate backend compute fails conceptually: Global Accelerator improves traffic entry and performance/availability paths; it does not execute application logic or remove the need for a compute backend. Exam caveat: choose Lambda (or equivalent serverless) for sparse internal APIs; Global Accelerator and always-on/Dedicated Hosts do not solve idle compute. Operational check: move the form API to Lambda behind an appropriate private or authenticated entry (API Gateway/ALB); confirm cold-start and auth meet city-hall UX; compare monthly cost to the former always-on host; and set budgets/alarms so rare spikes remain visible without returning to 24/7 EC2.