Overview
Standard is the recommended starting point for production applications. It runs on-demand Fargate tasks across 3 availability zones, backed by an RDS Instance and an Application Load Balancer, with CPU-based auto-scaling and CloudWatch monitoring.What’s Included
- ECS Fargate containers (Multi-AZ)
- RDS Instance database (Multi-AZ capable)
- Application Load Balancer
- Auto-scaling configuration
- CloudWatch monitoring
Architecture
Generated Infrastructure
Specifications
Compute (ECS Fargate)
- CPU: 512 units (0.5 vCPU)
- Memory: 1024 MiB
- Tasks: 2 (scales up to 5)
- Auto-scaling: CPU-based (70% target)
- Health checks: Automatic with ALB
Database (RDS Instance)
- Engine: PostgreSQL 17.5
- Instance: t4g.large
- Storage: 20 GB gp3
- Backup: 14-day retention
- Multi-AZ: Available (not default)
Networking
- VPC: 3 AZ with public/private subnets
- Load Balancer: Application Load Balancer
- NAT: 1 NAT gateway
- Security: Automatic security groups
- SSL: ACM certificate support
Customisation
Scaling Configuration
Database Upgrades
Enable Multi-AZ Database
After deployment, enable Multi-AZ in AWS Console or via AWS CLI:Cost Estimation
| Resource | Specification | Monthly Cost |
|---|---|---|
| ECS Fargate | 0.5 vCPU, 1 GB x 2 tasks | ~$36 |
| RDS Instance | t4g.large | ~$25 |
| Load Balancer | 1 ALB | ~$16 |
| Data Transfer | 100 GB | ~$9 |
| Total | ~$86/month |
When to Use
Perfect for:- Production web applications
- APIs with moderate traffic
- Business applications
- SaaS products
- Mobile app backends
- Need high availability and encryption (use Resilient)
- Cost-sensitive with low traffic (use Lightweight)
- Experimenting or learning (use Tinkerer)
- Custom requirements (use Custom)
Production Checklist
Before going live:- Enable Multi-AZ for database
- Verify desired count is 2+ for HA
- Configure custom domain
- Set up monitoring alerts
- Enable deletion protection
- Configure backup retention
- Review security groups
- Set up CI/CD pipeline
Monitoring
Standard pattern includes:CloudWatch Metrics
- ECS service metrics
- RDS performance metrics
- ALB request metrics
- Custom application metrics
Alarms (Configure Separately)
Security Features
- Encryption: At-rest and in-transit
- Private subnets: Database isolated
- Security groups: Least privilege
- Secrets Manager: Database passwords
- IAM roles: Service permissions
Upgrade Paths
To Resilient Pattern
- Switch database to Aurora
- Increase minimum task count to 4
- Add KMS encryption
- Add enhanced monitoring
Add Background Workers
Troubleshooting
Container Failing to Start
- Check CloudWatch logs
- Verify environment variables
- Confirm the Dockerfile is correct
- Check memory limits
Database Connection Issues
- Verify security groups
- Check credentials in Secrets Manager
- Confirm the database is running
- Test from bastion host
High Costs
- Review auto-scaling settings
- Check data transfer
- Optimise container size
- Consider reserved instances
Breaking Out the Pattern
As your application grows, you may want to customise the infrastructure generated by the Standard pattern. You can decompose it into individual factory calls for full control. See the individual factory documentation for details:- Compute Factory - Customise ECS, Lambda, or EC2 settings
- Database Factory - Configure RDS or Aurora parameters
- Storage Factory - Manage S3 buckets
- Network Factory - Custom VPC and networking
- CDN Factory - CloudFront distribution settings
Next Steps
Deploy Application
Deploy your Standard app to AWS
Add Resources
Extend with storage, messaging, or CDN
Compute Factory
Customise ECS, Lambda, or EC2 settings
Configure CI/CD
Set up an automated deployment pipeline