AWS Amplify + ECS – Scalable & Secure Decoupled Application Architecture

The frontend repository is connected to Amplify Hosting. Every push to a branch triggers an automatic build and deployment, and each branch (for example, development, staging, and production) gets its own environment. Pull request previews let reviewers test changes on a live URL before merging, and failed builds never replace the live site.

Amplify serves the frontend through its built-in Amazon CloudFront-based content delivery network, caching static assets close to users and invalidating the cache automatically on each deployment. Server-side rendered pages for frameworks such as Next.js are handled by Amplify without separate infrastructure.

Amazon Route 53 hosts the domain. The frontend is served at the main domain (for example, app.example.com) through Amplify, and the API at a subdomain (for example, api.example.com) through the Application Load Balancer. AWS Certificate Manager (ACM) provides and automatically renews the SSL/TLS certificates for both.

The backend is packaged as a Docker image, stored in Amazon Elastic Container Registry (Amazon ECR) with scan-on-push enabled, and deployed as an ECS service on AWS Fargate. Tasks are spread across at least two Availability Zones, and unhealthy tasks are replaced automatically.

An internet-facing Application Load Balancer in public subnets terminates HTTPS using the ACM certificate, redirects HTTP to HTTPS, and routes requests to healthy ECS tasks in private subnets. Health checks remove failing tasks from rotation before users are affected, and path-based routing can direct requests to separate microservices.

AWS WAF web ACLs are attached to the Amplify app and to the Application Load Balancer. AWS Managed Rules block common exploits such as SQL injection and cross-site scripting, the Known Bad Inputs and IP reputation rule groups filter malicious sources, rate-based rules limit abusive clients, and Bot Control can be added to manage automated traffic.

Database credentials, third-party API keys, and other sensitive values are stored in AWS Secrets Manager, encrypted with AWS Key Management Service (AWS KMS), and injected into ECS tasks at startup through the task definition, so they never appear in source code, images, or logs. Database credentials are rotated automatically. Non-sensitive configuration is kept in AWS Systems Manager Parameter Store.

The backend runs inside an Amazon VPC with public subnets for the load balancer and NAT gateways, and private subnets for ECS tasks and the database. Security groups allow the ECS tasks to accept traffic only from the load balancer, and the database to accept traffic only from the ECS tasks. VPC endpoints keep traffic to Amazon ECR, Secrets Manager, Amazon S3, and CloudWatch on the AWS network.

The API stores data in Amazon RDS (or Amazon Aurora) in a Multi-AZ configuration with automatic failover, encrypted at rest with AWS KMS and backed up automatically. Amazon ElastiCache can be added to cache frequent queries and session data, reducing database load and response times.

ECS service auto-scaling adds and removes backend tasks based on CPU, memory, or request count per target, while Amplify scales the frontend automatically with no configuration. Both layers handle traffic spikes without manual intervention and scale back down when demand falls.

AWS CodePipeline and AWS CodeBuild build, test, and scan the backend image on every commit and deploy it to ECS using rolling updates with the deployment circuit breaker, so API releases happen without downtime and roll back automatically on failure.

Amazon CloudWatch collects ECS Container Insights metrics, application logs, load balancer metrics, and Amplify hosting metrics, with dashboards and alarms for error rates, latency, and task health. AWS WAF logs record blocked requests, Amazon GuardDuty provides continuous threat detection including ECS runtime monitoring, and AWS CloudTrail records all account activity.