Containerized Web Service with Amazon ECS and Fargate
This architecture runs a production container service without managing an EC2 host fleet. A protected global edge forwards to a Multi-AZ ALB, Fargate tasks stay private, and managed data, image, secret, and observability services support the runtime.
Published August 18, 2026
Reference architecture
Architecture diagram
Open on the canvasAmazon ECS Fargate web architecture diagram with CloudFront, WAF, ALB, private Fargate tasks, RDS, ElastiCache, ECR, and Secrets Manager. The image links to a fully editable BuildPlane starter.
Overview
A containerized web service on ECS Fargate. Traffic enters through a global edge (Route 53, CloudFront, WAF), hits a cross-AZ ALB, and reaches a private Fargate service. RDS and ElastiCache provide state and caching, ECR supplies scanned images, and Secrets Manager injects credentials.
Components
- Global Edge: Route 53, CloudFront, and WAF handle DNS, caching, and protection.
- VPC Networking: Public subnets host the ALB; private subnets isolate the tasks and data.
- Containers: A Fargate service scales by target tracking across Availability Zones with no host fleet to manage.
- Data Layer: A Multi-AZ RDS instance and ElastiCache separate durable writes from hot reads.
- Images + Config: ECR supplies scanned images and Secrets Manager injects credentials over the private subnets.
Traffic Flow
- Users resolve the domain via Route 53 and reach CloudFront, which forwards dynamic traffic after WAF.
- CloudFront routes to the ALB, which balances requests across the Fargate service.
- The service reads from ElastiCache and writes to the Multi-AZ RDS instance.
- Tasks pull images from ECR and read secrets from Secrets Manager over the private subnets.
- Auto scaling adjusts task count as load changes.
Customize First
- Set task sizes, service auto-scaling targets, and desired counts for your traffic profile.
- Split into web and worker services, or add service discovery / App Mesh, as your app grows.
- Introduce blue/green deployments and image-scan gates in your delivery pipeline.
Design rationale
Decisions that shape this architecture
Keep tasks in private subnets
The ALB is the public regional entry point. Tasks accept application traffic from the load balancer and do not require public IP addresses.
Treat the image and secret paths as runtime dependencies
Tasks need reliable private access to ECR, logs, and Secrets Manager. VPC endpoints can reduce NAT dependency and keep AWS service traffic private.
Scale on the service bottleneck
Target tracking can use CPU, memory, request count, or a custom metric. The chosen signal should represent user impact and downstream capacity.
Before production
Operational checks
Use deployment health checks that distinguish container startup from application readiness.
Set task CPU and memory from load tests, then define safe scaling limits.
Scan images and deploy immutable tags or digests from ECR.
Test connection pressure on RDS and cache behavior during task scaling.
Scope and tradeoffs
What this diagram does not solve
Fargate removes host management, not service operations
Teams still own container health, deployments, task sizing, logs, scaling, dependency timeouts, and application security.
A single service may not fit every workload
Split web, API, and worker responsibilities when they need different images, scaling signals, release cadence, or network permissions.
Common questions
Frequently asked questions
Why use Fargate instead of ECS on EC2?
Fargate removes the need to provision and manage the container host fleet. ECS on EC2 can offer more host control and different economics at sustained scale.
Should Fargate tasks have public IP addresses?
Public web-service tasks normally stay private behind an ALB. They can reach required services through NAT or VPC endpoints.
How should containers receive database credentials?
Store credentials in Secrets Manager, grant the task role narrow access, and rotate secrets according to the database and application connection strategy.
Keep exploring
Related AWS architectures
CI/CD Pipeline to Amazon ECS Fargate
This delivery architecture turns a source change into a tested, scanned, approved, and deployed Fargate release. It keeps build artifacts and container images distinct, makes the production approval visible, and delegates infrastructure updates to CloudFormation.
Explore the architecture
Production-Grade Highly Available Web Platform on AWS
This reference expands the three-tier baseline with a global edge, separate scaling domains, caching, read scaling, private egress, secrets, backups, and operations. It is intended for teams evaluating a conventional production web platform rather than a minimal learning diagram.
Explore the architecture
Public and Private Subnets in an AWS VPC
This VPC pattern makes exposure decisions explicit. The load balancer and NAT gateway live in the public path, application compute accepts traffic only from the load balancer, and the database has no direct route from the internet.
Explore the architectureFrom reference to working draft
Adapt this architecture with your AWS AI Agent
Start from the exact diagram in this guide. Change requirements, challenge a decision, or ask what fails first, while keeping the architecture editable.