A production-ready WordPress deployment on AWS ECS (Elastic Container Service) using Docker containers, showcasing modern cloud infrastructure and containerization best practices.
This project demonstrates a scalable, highly available WordPress application deployed on AWS ECS Fargate. It leverages Docker containers for consistent deployment across environments, with a focus on security, performance, and automation.
The deployment architecture includes:
- Container Platform: AWS ECS Fargate (serverless containers)
- Application: WordPress 6.5.5 with PHP 8.1 & Apache
- Database: Amazon RDS with RDS Proxy for connection pooling
- Storage: Amazon EFS (Elastic File System) for persistent WordPress data
- Secrets Management: AWS Secrets Manager for secure credential storage
- Logging: CloudWatch Logs for centralized log management
- Networking: VPC with proper security groups and private/public subnets
The application uses the official WordPress Docker image with specific optimizations:
- Base Image:
wordpress:6.5.5-php8.1-apache - CPU: 1024 units (1 vCPU)
- Memory: 2048 MB (2 GB)
- PHP Memory Limit: 512M for optimal performance
- Port Mapping: Container port 80 β Host port 80
- β Rootless capable with configurable user permissions
- β EFS integration for persistent WordPress files and media
- β CloudWatch logging with automatic log group creation
- β Secrets injection from AWS Secrets Manager
- β Health monitoring and auto-restart capabilities
- AWS Account with appropriate permissions
- AWS CLI configured
- Docker installed (for local testing)
- ECS CLI (optional, for easier deployment)
The project includes a production-ready ECS task definition (tasks-definition/wordpress-front.json) that defines:
{
"family": "wordpress-front-new",
"requiresCompatibilities": ["FARGATE"],
"networkMode": "awsvpc",
"cpu": "1024",
"memory": "2048"
}-
Register the Task Definition:
aws ecs register-task-definition \ --cli-input-json file://tasks-definition/wordpress-front.json
-
Create or Update ECS Service:
aws ecs create-service \ --cluster your-cluster-name \ --service-name wordpress-front-service \ --task-definition wordpress-front-new \ --desired-count 2 \ --launch-type FARGATE \ --network-configuration "awsvpcConfiguration={subnets=[subnet-xxx],securityGroups=[sg-xxx],assignPublicIp=ENABLED}" -
Deploy with Load Balancer (recommended):
aws ecs create-service \ --cluster your-cluster-name \ --service-name wordpress-front-service \ --task-definition wordpress-front-new \ --desired-count 2 \ --launch-type FARGATE \ --network-configuration "awsvpcConfiguration={subnets=[subnet-xxx],securityGroups=[sg-xxx]}" \ --load-balancers "targetGroupArn=arn:aws:elasticloadbalancing:.. .,containerName=wordpress-front,containerPort=80"
Database credentials are securely stored in AWS Secrets Manager and injected at runtime:
- WORDPRESS_DB_USER: Retrieved from Secrets Manager
- WORDPRESS_DB_PASSWORD: Retrieved from Secrets Manager
- No hardcoded credentials in the codebase
- VPC isolation with private subnets for database
- RDS Proxy for secure database connections
- Security groups restricting traffic flow
- EFS encryption in transit enabled
- Execution Role:
wordpress-prod-rolewith minimal required permissions - Follows AWS principle of least privilege
| Component | Service | Purpose |
|---|---|---|
| Compute | ECS Fargate | Serverless container orchestration |
| Database | RDS (via Proxy) | Managed MySQL/MariaDB |
| Storage | EFS | Persistent file storage |
| Secrets | Secrets Manager | Credential management |
| Logging | CloudWatch Logs | Centralized logging |
| Networking | VPC + Subnets | Network isolation |
WORDPRESS_DB_HOST: RDS Proxy endpointWORDPRESS_DB_NAME: Database name (wordpressdatabase)PHP_MEMORY_LIMIT: Set to 512MECS_RESERVED_MEMORY: 100MB reserved for system
{
"sourceVolume": "efs-wordpress-volume",
"containerPath": "/bitnami/wordpress"
}The Fargate deployment supports:
- Horizontal Scaling: Increase task count for more capacity
- Auto Scaling: Configure based on CPU/Memory metrics
- Load Balancing: Distribute traffic across multiple tasks
Example auto-scaling configuration:
aws application-autoscaling register-scalable-target \
--service-namespace ecs \
--resource-id service/your-cluster/wordpress-front-service \
--scalable-dimension ecs:service:DesiredCount \
--min-capacity 2 \
--max-capacity 10All container logs are automatically sent to CloudWatch:
- Log Group:
wordpress-front-container - Region:
eu-west-1 - Stream Prefix:
wordpress-front
aws logs tail wordpress-front-container --followThis setup is ready for CI/CD integration with:
- GitHub Actions
- AWS CodePipeline
- Jenkins
- GitLab CI
Example GitHub Actions workflow snippet:
- name: Deploy to ECS
run: |
aws ecs update-service \
--cluster your-cluster \
--service wordpress-front-service \
--force-new-deploymentTest the Docker container locally:
docker run -d \
-p 8080:80 \
-e WORDPRESS_DB_HOST=localhost \
-e WORDPRESS_DB_NAME=wordpress \
-e WORDPRESS_DB_USER=root \
-e WORDPRESS_DB_PASSWORD=password \
wordpress:6.5.5-php8.1-apache- Name:
wordpress-prod-task-front - Easy identification in AWS Console
- Cost allocation tracking
- Fork the repository
- Create a feature branch
- Commit your changes
- Push to the branch
- Create a Pull Request
This project is licensed under the MIT License.
For issues and questions:
- Open an issue in this repository
- Check AWS ECS documentation
- Review CloudWatch logs for troubleshooting
Built with β€οΈ using Docker and AWS ECS
