Payload CMS 3.x on AWS ECS Fargate

Before you touch the AWS console, you need a complete mental model of what you are building. Most deployment failures happen because people start provisioning resources before they understand how those resources talk to each other.

This post maps the full architecture for a production Payload CMS 3.x deployment on AWS. No console steps yet. Just the map.

Why ECS Fargate?

Payload CMS 3.x embeds Next.js 15, which means it is a long-running Node.js server process. You cannot deploy it to Lambda or S3. You need a container orchestration platform that runs persistent processes, scales horizontally, and integrates cleanly with the rest of AWS.

ECS Fargate gives you all of that without managing EC2 instances. You define the task, specify CPU and memory, and Fargate handles the underlying infrastructure. You pay only for what runs.

The Astro SSR frontend runs the same way — a separate Fargate service, separate task definition, separate scaling configuration.

The Full Architecture

Here is every AWS service in this stack and why it exists:

VPC with public and private subnets across two availability zones
Everything sensitive runs in private subnets. The database never has a public IP. The Fargate tasks run in private subnets and reach the internet through a NAT Gateway. The ALB sits in the public subnets. Two AZs gives you high availability without active-active complexity.

Application Load Balancer (ALB)
A single ALB handles all inbound traffic. Path-based routing rules send /admin* and /api* to the Payload CMS target group, and everything else to the Astro frontend target group. One certificate, one DNS record, two backends. This is covered in detail in Part 4.

ECS Cluster with two Fargate services
One service runs the Payload CMS container. One service runs the Astro SSR frontend container. Each has its own task definition, CPU/memory allocation, and auto-scaling policy. The services do not share a container — they communicate through the internal ALB routing or directly via the Payload REST API.

Amazon ECR (Elastic Container Registry)
Your Docker images live here. One repository for Payload CMS, one for the Astro frontend. ECS pulls from ECR at deploy time. Your CI/CD pipeline pushes to ECR on every merge to main.

RDS Aurora PostgreSQL
Payload CMS requires PostgreSQL. Aurora PostgreSQL gives you a writer endpoint, reader endpoints, automatic failover, and storage that scales without intervention. It runs in a private subnet with no public access. The Payload CMS Fargate task connects via the Aurora writer endpoint using credentials stored in Secrets Manager. This is covered in Part 2.

AWS Secrets Manager
Database credentials, the Payload secret key, and any API keys live in Secrets Manager — not in environment variables baked into the container image. The ECS task role has permission to read specific secrets at runtime. This is the right pattern for anything you would not want visible in a Dockerfile or a GitHub repo.

CloudFront
CloudFront sits in front of the ALB. Static assets are cached at the edge. The admin UI is served through CloudFront with a separate cache behavior that passes through to the ALB without caching. This gives you DDoS protection via AWS Shield Standard and a single CDN endpoint for your entire application.

AWS WAF
Attached to CloudFront. Rate limiting, IP-based rules, and managed rule groups for common web exploits. For government deployments, WAF is not optional.

S3 for media uploads
Payload CMS handles file uploads. In production, those files go to S3, not to the container filesystem. Containers are ephemeral — anything written to the local filesystem disappears when the task restarts. S3 gives you durable, scalable media storage with direct CloudFront delivery.

IAM roles and policies
Three roles: an ECS task execution role (allows ECS to pull images from ECR and push logs to CloudWatch), a Payload CMS task role (allows the running task to read secrets and write to S3), and a frontend task role (read-only access to what it needs). Least privilege throughout.

Data Flow

A request from a public visitor follows this path:

1. DNS resolves to CloudFront
2. CloudFront checks cache. Cache hit returns immediately. Cache miss continues.
3. CloudFront forwards to the ALB
4. ALB evaluates path-based routing rules
5. Request routes to the Astro frontend Fargate task (or to Payload CMS if the path matches /admin* or /api*)
6. The Astro frontend fetches content from Payload CMS via the internal REST API
7. Payload CMS queries Aurora PostgreSQL via the writer or reader endpoint
8. Response travels back up the chain

A content editor accessing the admin UI follows steps 1 through 4, then routes directly to the Payload CMS Fargate task. The Astro frontend is never involved in admin traffic.

What This Architecture Costs

The main cost drivers are Aurora PostgreSQL (the smallest Aurora Serverless v2 configuration starts around $50 to $80 per month at low traffic), Fargate compute (two services at 0.25 vCPU and 512MB each runs under $30 per month at low traffic), and the NAT Gateway (roughly $35 per month baseline plus data transfer). CloudFront and WAF add $5 to $20 per month depending on traffic.

For a typical government website with moderate traffic, expect $150 to $250 per month in AWS costs. This is significantly lower than managed CMS platform fees for equivalent capability.

What Comes Next

Part 2 covers RDS Aurora PostgreSQL setup — subnet groups, security groups, the Secrets Manager integration, and the connection string pattern that Payload CMS expects. That is where most database-related deployment failures originate.

This is the architecture we used to build the Chippewa County municipal CMS — deployed from an RFP document alone in 5 days. Read the case study.