Building blocks
Design goal
Operate containerized application compute without managing EC2 worker nodes, while keeping runtime tasks private, replaceable, and observable.
Success criteria
- Use managed serverless container compute
- Scale tasks horizontally
- Terminate public traffic at a managed load balancer
- Centralize logs and image storage
Architecture
Internet traffic reaches an ALB; private Fargate tasks run across multiple subnets and pull images from ECR, with logs and metrics sent to CloudWatch.
Architecture flow
- Client reaches ALB
- Listener forwards to ECS service target group
- Fargate tasks process requests
- Tasks access required private dependencies
- Logs/metrics flow to CloudWatch
Architecture decisions
Keep tasks private
WhyOnly the load balancer needs to accept public application traffic; task ENIs can remain in private subnets where architecture allows.
Trade-offPrivate tasks reduce exposure but usually require NAT or VPC endpoints for image pulls, telemetry, and external dependencies.
Separate image lifecycle from runtime
WhyECR stores versioned images while ECS services manage deployment and task scaling.
Trade-offSeparating image storage from runtime improves deployment control, but image promotion, scanning, rollback, and retention become explicit release-management responsibilities.
Networking
Make the traffic path explicit. Use multiple subnets across Availability Zones, security-group-to-security-group rules, and VPC endpoints where they materially reduce NAT dependency.
Security
Protect the control and data paths deliberately. Use task roles, secrets management, image scanning controls, WAF where appropriate, and least-privilege security groups.
Availability
Design for the failure domain that must be survived. Run multiple tasks across Availability Zones and configure health checks/autoscaling around observed workload behavior.
Disaster recovery
Treat regional recovery as a separate operating state. For regional DR, replicate or rebuild images/configuration in the recovery region and protect stateful dependencies separately.
Cost drivers
- Fargate vCPU/memory runtime
- ALB usage
- NAT/data transfer
- CloudWatch logs
- WAF requests/rules
Design assumptions
- The application can run in containers
- State is stored in external managed data services or designed explicitly
Implementation plan
- Publish versioned container images to ECR and define the image scanning and promotion process.
- Run Fargate tasks in private subnets with separate task-execution and application IAM roles scoped to the permissions each needs.
- Place an Application Load Balancer in the intended ingress subnets and configure target-group health checks around an application health endpoint.
- Configure service autoscaling from workload signals that reflect real saturation, not only CPU by default.
- Centralize logs, metrics, secrets, and deployment alarms, then test a rolling deployment, task failure, and scale event before production.
Validate the design
- Deploy a new task revision and confirm the service maintains healthy capacity during rollout.
- Stop a running task and verify ECS replaces it without relying on manual intervention.
- Review task-role permissions and confirm the application cannot call APIs outside its required scope.
- Generate load and confirm autoscaling, ALB health checks, and application latency behave within the expected thresholds.