About This Architecture

Autocash production architecture on AWS spans three tiers: a public tier with App Runner services (FastAPI, Hasura GraphQL, Windmill), an app tier with ECS Fargate workers across multiple AZs, and a data tier with RDS PostgreSQL 17.4 in Multi-AZ configuration. Internet traffic routes through an Internet Gateway to App Runner managed services, while private app subnets in us-east-1a, us-east-1b, us-east-1d, and us-east-1f host Windmill and Celery workers with dual-AZ redundancy. The RDS primary database (db.r8g.large, 200GB gp3) resides in us-east-1f with standby replicas across four private subnets, backed by Amazon SQS, S3, Lambda, Secrets Manager, KMS, ECR, and CloudWatch for async jobs, artifact storage, embeddings, secrets, encryption, container registry, and observability. This architecture demonstrates high-availability SaaS design with managed services, multi-AZ failover, and secure network isolation. Fork and customize this diagram on Diagrams.so to adapt the topology, instance types, or regional configuration for your production workload.

People also ask

How do you design a production SaaS application on AWS with high availability, multi-AZ failover, and managed services?

Autocash production architecture uses AWS App Runner for managed FastAPI and Hasura GraphQL services, ECS Fargate for Windmill and Celery workers distributed across us-east-1a, us-east-1b, us-east-1d, and us-east-1f, and RDS PostgreSQL 17.4 in Multi-AZ configuration with primary in us-east-1f and standby replicas. Amazon SQS handles async job queuing, S3 stores vectors and artifacts, Lambda powers