Three-tier SaaS architecture on AWS
A three-tier AWS architecture: CloudFront edge, ALB to ECS Fargate API, RDS Postgres primary plus read replica, S3 for assets, and SQS for async workers. Reasonable starting point for most B2B SaaS.
Architecture previewThree-tier SaaS architecture on AWS
Recreate this in Raltey
Copy this prompt
Paste this into Raltey's AI agent to generate the same diagram, then tweak it on the canvas.
Prompt
Create an AWS architecture diagram for a three-tier SaaS. Edge: CloudFront fronts both an S3 bucket for static assets and an ALB for the API. App tier: ALB routes to ECS Fargate API tasks; API enqueues async jobs to SQS, consumed by ECS Fargate workers. Data tier: RDS Postgres primary plus a read replica, ElastiCache Redis, and S3 for uploads. External: Stripe.
Context
- - Three tiers: edge, app, data.
- - Stateless app tier on Fargate, scalable horizontally.
- - Async work isolated behind SQS and worker tasks.
Patterns
- - Edge: CloudFront fronts both static assets (S3) and the API (ALB).
- - App tier stays stateless on Fargate to scale horizontally.
- - Read replica absorbs heavy reads (lists, dashboards).
- - Async work goes through SQS, not synchronous calls.
Diagram structure
Nodes and connections
edge
End useractor
CloudFrontcdn
S3 (static assets)storage
app
ALBlb
ECS Fargate (API)service
SQS (jobs)queue
ECS Fargate (worker)service
data
RDS Postgres (primary)db
RDS Postgres (replica)db
ElastiCache Rediscache
S3 (uploads)storage
Nodes
Stripeexternal
Connections
End userCloudFront
CloudFrontS3 (static assets)static
CloudFrontALBapi
ALBECS Fargate (API)
ECS Fargate (API)RDS Postgres (primary)
ECS Fargate (API)RDS Postgres (replica)reads
ECS Fargate (API)ElastiCache Redis
ECS Fargate (API)S3 (uploads)
ECS Fargate (API)SQS (jobs)enqueue
SQS (jobs)ECS Fargate (worker)
ECS Fargate (worker)RDS Postgres (primary)
ECS Fargate (worker)Stripe
Notes from the field
- Use IAM auth for RDS to avoid hardcoded passwords.
- Place ALB in public subnets, Fargate tasks in private subnets.
- Set DLQ on SQS so poison messages are not lost.
Frequently asked
When should I add a Lambda function instead of Fargate?
For bursty, short-lived workloads (image processing, webhooks) Lambda often wins on cost. Stick with Fargate for steady traffic and long-running connections.
Where do background jobs live?
Worker tasks on Fargate consume SQS. This keeps the API tier responsive and isolates retries from user traffic.
More templates
FlowchartSaaS onboarding email flowFlowchartCustomer support runbook flowFlowchartPayment webhook retry and error flowFlowchartGitHub PR review and merge flowFlowchartLogin with magic link flowArchitectureMicroservices architecture on KubernetesArchitectureReal-time data pipeline on GCPArchitectureNext.js + Vercel + Postgres SaaS stack
Open this template in Raltey
Edit it on the canvas, ask the AI agent to extend it, then share or export.
Start for free