AWS for Django / Python Backends cheat sheet · AWS

1.Mapping a Django or FastAPI Backend to AWS

A Django or FastAPI project already names every piece it needs: a WSGI or ASGI server, a database, a cache, a place for uploads, a task queue, somewhere for settings and secrets. Deploying to AWS is mapping each of those to a managed service and deciding what the process boundaries are. Nothing about the application changes shape — what changes is who runs each piece.

Key features

The application container is identical for web and worker processes; only the command and the scaling policy differ
The task role gives the container its AWS permissions — no access keys are ever put in the image or the environment
RDS Proxy pools and reuses database connections, which avoids the memory and CPU overhead of opening a new connection per request, and keeps application connections during a failover
Secrets are read at startup from Secrets Manager or Parameter Store by ARN, so rotating one is a restart rather than a rebuild
ALB fits a long-running Django or FastAPI service; API Gateway fits per-request Lambda handlers, and mixing the two front doors for one service rarely pays off
stdout and stderr from the container go to CloudWatch Logs by the log driver, so the application writes JSON to stdout and configures no log files

The mapping, line by line

The mapping, line by line
In the project	On AWS	What changes in the code
`gunicorn` / `uvicorn` process	ECS task on Fargate (or EC2, or Lambda)	Nothing — it still listens on a port
`DATABASES`	RDS or Aurora PostgreSQL, Multi-AZ	Host becomes an endpoint name; never an IP
`CACHES`	ElastiCache for Redis or Valkey	Host becomes the primary endpoint
`MEDIA_ROOT` uploads	S3 bucket, private, served via presigned URLs	Storage backend swapped; view code unchanged
`STATIC_ROOT` assets	S3 bucket behind CloudFront	Collected at build time, not at runtime
`CELERY_BROKER_URL`	SQS queue (or ElastiCache Redis)	Broker URL only
`SECRET_KEY`, DB password, API keys	Secrets Manager or Parameter Store	Read once at startup by ARN
`logging` handlers	CloudWatch Logs via the container log driver	Log JSON to stdout; delete file handlers
`ALLOWED_HOSTS`, health endpoint	ALB target group health check	Add a cheap `/healthz` that touches nothing

ALB or API Gateway in front of the same application

ALB or API Gateway in front of the same application
Aspect	ALB → ECS/EC2	API Gateway → Lambda
Process model	Long-running server, many requests per process	One execution environment per concurrent request
Request duration	Bounded by your own timeout settings	Hard ceiling of 900 seconds (15 minutes)
Payload	Large uploads pass through, or bypass via presigned URLs	6 MB request and response, synchronous
Database connections	A pool per process, reused across requests	One per execution environment — reach for RDS Proxy
Idle cost	You pay for running tasks	You pay per request
Reach for it when	Steady traffic, WebSockets, long requests, existing WSGI/ASGI app	Spiky or low traffic, short handlers, no idle spend

Every line in settings.py, and the service that answers it

Front door and edge

Route 53

api.example.com → ALB alias

CloudFront

static assets and cached GETs

ALB

TLS, health checks, path rules

Your code — one image, two commands

ECS web service

gunicorn / uvicorn, behind the ALB

ECS worker service

celery worker, no load balancer

Scheduled task

celery beat, or an EventBridge schedule

State — none of it in your container

RDS / Aurora PostgreSQL

DATABASES, Multi-AZ

ElastiCache Redis

CACHES, sessions, locks

S3

media uploads and static files

SQS

CELERY_BROKER_URL

Cross-cutting

Secrets Manager

DB password, API keys, SECRET_KEY

IAM task role

the container's only credentials

CloudWatch

logs from stdout, metrics, alarms

Signature

DATABASES→RDS · CACHES→ElastiCache · media→S3 · broker→SQS · secrets→Secrets Manager · logs→CloudWatch

Read the settings file as a list of services to rent: RDS for DATABASES, ElastiCache for CACHES, S3 for uploads and static, SQS for the Celery broker, Secrets Manager for anything sensitive, CloudWatch for stdout. One image runs both web and worker; the task role, not an access key, is the container's identity.

2.Static Files, Media, Jobs, Migrations, and Health Checks

Once the services are chosen, a handful of details decide whether the deployment is stable. Static files and media files look alike and behave completely differently. Uploads should never travel through your application. Migrations are a deployment step with its own failure mode. Connections to the database are a limited resource. And the health check the load balancer calls decides when your service is considered alive.

Key features

Static files are collected at build time into the image or an S3 prefix, versioned per release, and served through CloudFront with a long cache lifetime
Media is user-created, lives in a private S3 bucket, and is served by presigned URL or through CloudFront with a signed URL — never by making the bucket public
A presigned upload URL lets the browser PUT straight to S3; the URL carries the credentials of whoever signed it and expires with them
Migrations run as a one-off task before the new version starts serving, not in the container entrypoint — otherwise every task races every other task
Only expand-then-contract migrations are safe during a rolling deployment, because old and new code run at the same time
The health check must be cheap and must not touch the database, or one slow query takes every task out of service at once

The operational details, and the failure each one prevents

The operational details, and the failure each one prevents
Concern	The choice that works	What it prevents
Static files	Collected at build, uploaded to S3, served via CloudFront	A deploy that serves half-old, half-new assets
Media files	Private S3 bucket, presigned URLs, Block Public Access on	An indexed bucket full of customer documents
Uploads	Presigned PUT direct from the browser	Request timeouts and memory tied to file size
Background jobs	Separate worker service on SQS, own scaling policy	Slow jobs consuming the request-serving capacity
Migrations	One-off task before the new version starts serving	Every task in the deployment running the same migration
Connection pooling	A bounded pool per process; RDS Proxy when processes are many and short-lived	Exhausting `max_connections` during a scale-out
Logging	JSON to stdout, collected by the log driver	Logs living on a filesystem that is deleted with the task
Tracing	Trace ID propagated from the ALB through to the database call	Knowing a request was slow but not which hop was slow
Health checks	A cheap `/healthz` that touches no dependency	A slow database marking every task unhealthy at once

Static files and media files are not the same thing

Static — built with the release

Produced by `collectstatic` or a frontend build, at build time
Identical for every user; safe to cache at the edge for a year
Versioned by content hash, so a deploy never invalidates anything
Public by design — that is what a CSS file is for
Lost on rebuild? Rebuild it. Nothing is lost.

Media — created by users at runtime

Arrives after deploy, from an upload, forever
Different per user; usually not cacheable and often not shareable
Keyed by tenant and object id, not by release
Private by default; access granted per request via a presigned URL
Lost on rebuild? It is gone. Versioning and backups apply here.

Signature

static → build-time, public, immutable · media → runtime, private, presigned · migrate → one-off task, expand then contract

Static is built and cacheable, media is user-created and private — never the same bucket or the same rules. Uploads go direct to S3 by presigned URL. Migrations are a gated one-off task, expand before contract. Health checks stay cheap and dependency-free, and logs go to stdout.

3.Web and Workers Scale on Different Signals

The web tier is busy when requests arrive; the worker tier is busy when the queue is deep. Those two things move at different times and for different reasons, so they need two services with two scaling policies. Scaling both on CPU, or running workers inside the web containers, ties them together and makes both worse.

Key features

The number of messages in a queue does not change proportionally to the number of workers, which is why queue depth alone is a poor target-tracking metric
Backlog per instance is the queue length divided by the number of instances in service; that is the metric to target
Acceptable backlog per instance is acceptable latency divided by average processing time per message — AWS's worked example is 10 s ÷ 0.1 s = 100 messages
Web traffic and job volume peak at different times: a nightly report run creates worker load with no request load at all
Workers handling long tasks can use scale-in protection so a scale-in event does not kill a job halfway through
A message not finished when a worker is terminated returns to the queue and is picked up by another worker

What each tier scales on, and why the other signal fails

What each tier scales on, and why the other signal fails
Tier	Scale on	Why not the obvious alternative
Web	Requests per target, or p95 latency	CPU lags: a request tier can be saturated on I/O wait at 30% CPU
Worker	Backlog per worker (queue length ÷ workers in service)	Queue depth alone does not scale with worker count, so the target has no stable meaning
Worker, long jobs	Backlog per worker, plus scale-in protection	Plain scale-in can terminate a worker mid-job; the message returns to the queue and the work restarts
Scheduled batch	Scheduled scaling ahead of the known peak	Reactive scaling starts after the backlog exists, so the first minutes are always behind
Both	Separate minimum capacities	A shared minimum sizes one tier for the other tier's idle period

Two services, two signals, one image

The web service reacts to request latency and count; the worker service reacts to how far behind its queue is. Neither signal tells you anything about the other tier.

Signature

web → requests per target / p95 latency · worker → backlog per worker (queue length ÷ workers in service)

Two services, two policies, one image. Scale the web tier on requests per target or latency, and the worker tier on backlog per worker — queue length divided by workers in service — with a target of acceptable latency divided by processing time per message. Protect long-running workers from scale-in.