Web application using AWS Fargate

I asked Claude (Opus 4.8) and ChatGPT 5.5 about deploying a web application using AWS Fargate. These are the responses I got.

Claude

What’s good

• FastAPI + Docker + Fargate is a well-trodden path. Serverless containers mean no EC2/node patching or capacity management.
• FastAPI is async and performant for I/O-bound APIs.
• Image-based deployment gives you reproducible artifacts and easy rollback (pin task definitions to image digests).

When Fargate is not ideal

• Sustained, predictable high traffic — EC2-backed ECS or EKS can be cheaper at scale.
• Need for GPUs, very large memory, or sub-second cold starts at unpredictable scale (consider Lambda for spiky/low-traffic instead).
• Heavy CPU-bound workloads where you’d want fine-grained instance tuning.

For most internal/customer-facing REST APIs with moderate, variable traffic, it’s a good default.

Fargate runs long-lived containers. Your task starts once and keeps running, serving many requests over its lifetime (hours, days, until you redeploy or scale down). The container does not spin up per request. A single Fargate task handles thousands of concurrent and sequential requests.

So the flow is:

• You launch, say, 2 Fargate tasks (containers).
• Each runs your FastAPI app continuously behind a load balancer.
• Requests get distributed across those running tasks.
• Autoscaling adds/removes tasks based on load — not per request.

That’s exactly why you need FastAPI (and uvicorn/gunicorn): something has to be the long-running process that listens on a port, accepts connections, routes them, and sends responses. Fargate just runs your container; it has no idea what HTTP is.

The per-request-container model you’re describing is AWS Lambda (with API Gateway or a Function URL). There, the platform does spin up an execution environment per invocation (reused when warm), and you don’t run your own web server — you just write a handler function. With Lambda you can still use FastAPI via an adapter like Mangum, but you don’t need a server like uvicorn.

Quick contrast:

	Fargate	Lambda
Lifetime	Long-running container	Per-invocation (reused when warm)
You run	A web server (uvicorn/FastAPI)	A handler function
Scaling unit	Tasks	Concurrent invocations
Cold start	Only when scaling/deploying	Per cold invocation
FastAPI is needed precisely because the container is long-lived and needs an HTTP server inside it.

Here’s the full request lifecycle for your FastAPI-on-Fargate setup, step by step.

The steps

Deployment (happens once, ahead of time)

1. You build a Docker image with your FastAPI app + uvicorn/gunicorn inside it.
2. You push the image to ECR (Elastic Container Registry).
3. You define an ECS Task Definition (image, CPU/memory, port, env, secrets).
4. You create an ECS Service that says “keep N tasks of this task definition running.”
5. ECS/Fargate pulls the image and launches N long-lived containers. Each starts uvicorn, which binds to a port and waits.
6. As each task becomes healthy, it registers with the ALB’s target group.

Request handling (happens for every request, against already-running containers)

1. Client sends an HTTPS request to your domain.
2. Route 53 resolves the domain to the ALB.
3. The ALB terminates TLS and picks a healthy target (one of your running tasks).
4. The request is forwarded to that task’s uvicorn process.
5. Uvicorn hands the request to FastAPI, which routes it to the matching path operation.
6. Your handler runs (DB calls, business logic, etc.) and returns a response.
7. Response travels back: FastAPI → uvicorn → ALB → client. The container stays alive for the next request.

Scaling (continuous, in the background)

• Service Auto Scaling watches CPU / memory / request-count metrics and adds or removes tasks — never per request. New tasks repeat deploy-steps 5–6; removed tasks drain in-flight requests (SIGTERM) then stop.

---

ChatGPT

I liked the way ChatGPT drew the pictures.