Container service
Stable capacity and different operational controls, billed while idle.
The clinician dashboard worked locally, but pilot traffic did not yet exist. I chose request-driven compute, corrected the cold-start cost story, and wrote down the evidence that would justify containers later.
An always-running container can be the right production answer. At pilot stage, request-driven Lambda matched the traffic CareFlow actually had.
Stable capacity and different operational controls, billed while idle.
Requests and execution drive compute cost; no separate function-URL endpoint charge.
Concurrency, latency, limits, and cost can reverse the choice.
AWS currently supports SnapStart for Python 3.12 and later, on published versions, with compatibility constraints. Non-Java runtimes incur snapshot caching and restoration charges.
CloudFront can route the static application to S3 and the API path to a Lambda function URL. OAC can restrict the Lambda origin when IAM authorization and documented signing requirements are configured.
One public CareFlow domain.
Default static behavior and an API path behavior.
S3 with OAC; Lambda URL with its own OAC and request policy.
The FastAPI core remains independent of the transport adapter. The decision ledger names what would earn a move rather than calling Lambda permanent.
Observed load benefits from always-on capacity.
Measured user experience remains unacceptable.
Current regional estimates favor containers.
The source’s zero-to-two-dollar estimate is not repeated as a current quote. Every deployment needs current pricing, traffic assumptions, and alarms.
A narrated comparison of idle economics, SnapStart caveats, the CloudFront request path, and the signals that would reverse the pilot architecture.