This content originally appeared on DEV Community and was authored by Dickson Victor
I recently lead a project where I migrated a customer’s application backend to AWS. Its an e-commerce/marketplace platform with its core backend built with a microservices architecture.
Here are key notes to consider when migrating a similar workload.
1. Infrastructure as Code is Essential
- Use Terraform with modular architecture for consistent deployments
- Separate modules for ECS services, task definitions, and target groups
- Environment-specific configurations (e.g prod.tfvars) for scalability
2. Service Discovery & Communication
- Implemented AWS Service Connect for inter-service communication
- Both HTTP and gRPC endpoints configured for each service
- Service mesh approach eliminates hardcoded service endpoints
3. Load Balancing Strategy
- Single ALB with path-based routing e.g (/admin/* , /order/* , etc.)
- Priority-based listener rules for 7 services
- Cost-effective compared to individual load balancers per service
4. Security & Configuration Management
- AWS Systems Manager Parameter Store for environment variables
- IAM roles with least-privilege access per service
- Secrets management separated from application code
5. Observability & Monitoring
- Centralized logging with CloudWatch Log Groups
- Service-specific log streams for easier debugging
- Health check endpoints for each service
6. Deployment & Scaling Considerations
- Fargate for serverless container management
- Circuit breaker pattern for deployment safety
- Auto-scaling capabilities
7. Network Architecture
- Multi-AZ deployment across 3 availability zones
- Public subnets for ALB, private subnets for services
- Security groups for network-level isolation
8. Service Organization
- Clear service boundaries: admin, notification, order, ship, store, user, wallet
- Consistent naming conventions and tagging strategy
- Modular Terraform structure for maintainability
9. Container Strategy
- ECR for private container registry
- Standardized port configurations (HTTP + gRPC)
- Resource allocation (CPU/memory) per service requirements
10. Operational Excellence
- GitHub Actions for CI/CD automation
- Terraform state management for team collaboration
- Parameter scripts for environment setup automation
These lessons demonstrate a well-architected microservices migration focusing on scalability, security, and operational efficiency.
Fargate vs EC2-Based ECS: Key Migration Lessons
Why Fargate Was Chosen
1. Operational Simplicity
- No EC2 instance management (patching, scaling, monitoring)
- AWS handles underlying infrastructure completely
- Eliminated capacity provider complexity
2. Cost Optimization for Microservices
- Pay-per-task model better for 7 small services
- No idle EC2 capacity costs
- Right-sizing at container level (256 CPU, 512 MB per service)
3. Security Benefits
- No SSH access or EC2 security hardening needed
- Automatic security patches by AWS
- Network isolation at task level with awsvpc mode
4. Simplified Networking
- Each task gets its own ENI
- Direct security group assignment to tasks
- No port mapping conflicts between services
5. Auto-scaling Efficiency
- Task-level scaling vs instance-level
- Faster cold starts for microservices
- No pre-provisioned capacity waste
Trade-offs Accepted
1. Higher Per-vCPU Cost
- Fargate costs ~40% more than EC2 equivalent
- Justified by reduced operational overhead
2. Limited Customization
- No access to underlying OS
- Can’t install custom agents or tools
- Fixed networking and storage options
3. Cold Start Considerations
- Slightly longer task startup times
- Mitigated with health check grace periods ( in my case 120s)
Fargate Sweet Spot
For 7 lightweight microservices with variable traffic, Fargate eliminated infrastructure management complexity while providing better resource utilization than maintaining EC2 instances that would often run underutilized.
This content originally appeared on DEV Community and was authored by Dickson Victor