Applying the AWS Well-Architected Framework to Modernize a Legacy CRM & Employee Portal Platform
Modernizing enterprise applications is not only about containerization and CI/CD automation — it’s about aligning architecture decisions with the AWS Well-Architected Framework’s six pillars:
- Operational Excellence
- Security
- Reliability
- Performance Efficiency
- Cost Optimization
- Sustainability
This post analyzes a cloud-native CRM & Employee Portal modernization through the lens of Well-Architected best practices.
1. Operational Excellence
Goal: Run and monitor systems to deliver business value and continuously improve processes.
Challenges in Legacy Environment
- Manual 2–3 hour deployments
- No centralized logging
- No automated rollback
- High dependency on human intervention
Architectural Decisions
CI/CD Automation
- GitHub → CodePipeline → CodeBuild → ECR → CodeDeploy → ECS Fargate
- Blue/green deployments with automated rollback
- Infrastructure defined as code
Observability
- CloudWatch metrics and logs for ECS, ALB, RDS
- Custom CloudWatch alarms
- SNS-based alerting
- CloudTrail API activity logging
- External synthetic monitoring
{
"AlarmName": "crm-platform-composite-health",
"AlarmDescription": "Composite alarm — triggers only when both ECS task failures AND high ALB error rate occur simultaneously, reducing alert noise",
"AlarmRule": "ALARM(crm-ecs-task-failure-alarm) AND ALARM(crm-alb-5xx-rate-alarm)",
"ActionsEnabled": true,
"AlarmActions": [
"arn:aws:sns:ap-south-1:<account-id>:crm-oncall-alerts"
]
}
# Create the two child alarms first
# 1 — ECS task failure alarm
aws cloudwatch put-metric-alarm \
--alarm-name crm-ecs-task-failure-alarm \
--namespace AWS/ECS \
--metric-name TaskCount \
--dimensions Name=ClusterName,Value=crm-cluster \
--statistic Minimum \
--period 60 \
--threshold 1 \
--comparison-operator LessThanThreshold \
--evaluation-periods 2 \
--alarm-actions arn:aws:sns:ap-south-1:<account-id>:crm-oncall-alerts
# 2 — ALB 5xx error rate alarm
aws cloudwatch put-metric-alarm \
--alarm-name crm-alb-5xx-rate-alarm \
--namespace AWS/ApplicationELB \
--metric-name HTTPCode_Target_5XX_Count \
--dimensions Name=LoadBalancer,Value=<alb-arn-suffix> \
--statistic Sum \
--period 60 \
--threshold 10 \
--comparison-operator GreaterThanThreshold \
--evaluation-periods 2 \
--alarm-actions arn:aws:sns:ap-south-1:<account-id>:crm-oncall-alerts
# 3 — Composite alarm combining both
aws cloudwatch put-composite-alarm \
--alarm-name crm-platform-composite-health \
--alarm-rule "ALARM(crm-ecs-task-failure-alarm) AND ALARM(crm-alb-5xx-rate-alarm)" \
--alarm-actions arn:aws:sns:ap-south-1:<account-id>:crm-oncall-alerts
The composite alarm is the key operational excellence pattern here. Individual alarms on ECS task count or ALB 5xx errors fire frequently on transient blips — a single noisy alert trains teams to ignore alerts. The composite alarm fires only when both conditions are true simultaneously, which is a genuine platform health event requiring human action. This reduced alert fatigue by ~70% on the CRM platform and improved on-call response quality.
Outcomes
- 98% reduction in deployment time
- Zero-downtime releases
- 80% reduction in manual operations
- Faster incident response
Well-Architected Alignment:
- Perform operations as code
- Make small, reversible changes
- Refine operations procedures frequently
- Anticipate failure
2. Security
Goal: Protect information, systems, and assets while delivering business value.
Legacy Gaps
- Hardcoded credentials
- No encryption enforcement
- No layered network segmentation
- Limited audit trails
Security Controls Implemented
Identity & Access
- IAM task roles (least privilege)
- Role-based CI/CD permissions
- Resource-level IAM policies
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowSecretsManagerAccess",
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue"
],
"Resource": "arn:aws:secretsmanager:ap-south-1:<account-id>:secret:crm-db-*"
},
{
"Sid": "AllowECRImagePull",
"Effect": "Allow",
"Action": [
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage",
"ecr:BatchCheckLayerAvailability"
],
"Resource": "arn:aws:ecr:ap-south-1:<account-id>:repository/crm-app"
},
{
"Sid": "AllowCloudWatchLogs",
"Effect": "Allow",
"Action": [
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "arn:aws:logs:ap-south-1:<account-id>:log-group:/ecs/crm-app:*"
},
{
"Sid": "DenyEverythingElse",
"Effect": "Deny",
"NotAction": [
"secretsmanager:GetSecretValue",
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage",
"ecr:BatchCheckLayerAvailability",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "*"
}
]
}
Secrets Management
- AWS Secrets Manager
- Runtime injection of credentials
- Automatic secret rotation
Why Secrets Manager over Parameter Store? Both AWS Secrets Manager and Systems Manager Parameter Store can store credentials securely, and Parameter Store is free for standard parameters. We chose Secrets Manager for this CRM platform for three specific reasons: automatic secret rotation on a defined schedule without any application code change, native integration with RDS to rotate database passwords automatically, and a dedicated audit trail in CloudTrail that logs every secret access event. For a CRM handling customer PII, the rotation capability alone justified the cost — a credential that auto-rotates every 30 days has a fundamentally smaller blast radius than one that relies on manual rotation discipline.
Network Segmentation
- Public subnets (ALB only)
- Private subnets (ECS + RDS)
- Security Groups for micro-segmentation
- Network ACLs as secondary boundary
Encryption
- KMS encryption for RDS
- Encrypted S3 storage
- TLS via CloudFront + ALB
Threat Detection & Audit
- CloudTrail for API logging
- GuardDuty for threat monitoring
- VPC Flow Logs for network visibility
Outcomes
- Elimination of hardcoded secrets
- Full encryption at rest and in transit
- Audit-ready logging for compliance
Well-Architected Alignment:
- Implement strong identity foundation
- Enable traceability
- Protect data in transit and at rest
- Apply security at all layers
3. Reliability
Goal: Ensure workload performs correctly and consistently when expected.
Legacy Risks
- Single-point-of-failure servers
- No fault tolerance
- Long downtime during deployment
Reliability Enhancements
Compute Layer
- ECS tasks across multiple Availability Zones
- Fargate-managed infrastructure
- ALB health checks
Database Layer
- Amazon RDS Multi-AZ deployment
- Automated backups
- Point-in-time recovery
Deployment Resilience
- Blue/green releases
- Automatic rollback
Why Blue/Green over Rolling deployments? Rolling deployments gradually replace instances and are simpler to set up — but they create a window where two versions of the application run simultaneously. For a CRM with active user sessions and database schema dependencies, mixed-version traffic is a real risk. Blue/Green eliminates this entirely: the new version is fully deployed and validated in the green environment before a single byte of live traffic touches it. The ALB listener rule switches traffic in one atomic operation, and rollback is equally instant — flip the listener back. The ~5-minute additional deployment time is a worthwhile trade for zero mixed-version exposure and sub-second rollback capability.
Edge Resilience
- CloudFront CDN reduces regional latency impact
Outcomes
- Zero downtime deployments
- Multi-AZ resilience
- Automated failover for database
- Consistent availability during peak usage
Well-Architected Alignment:
- Automatically recover from failure
- Test recovery procedures
- Scale horizontally
- Manage change through automation
4. Performance Efficiency
Goal: Use IT and computing resources efficiently.
Legacy Constraints
- Fixed hardware capacity
- No auto-scaling
- Global latency issues
Optimization Strategies
Serverless Containers
- ECS with Fargate eliminates overprovisioning
- Scale tasks dynamically
CDN Acceleration
- CloudFront reduces global latency
- Edge caching for static assets
Auto Scaling
- ECS task auto-scaling policies
- ALB request-based scaling
Managed Services
- RDS managed scaling and performance tuning
Outcomes
- Improved global performance
- Elastic scalability during CRM peak loads
- Reduced resource waste
Well-Architected Alignment:
- Democratize advanced technologies
- Go global in minutes
- Use serverless architectures
5. Cost Optimization
Goal: Avoid unnecessary costs.
Legacy Cost Drivers
- Overprovisioned on-prem hardware
- Idle compute during lean periods
- Manual operations overhead
Cost Improvements
Pay-As-You-Go Model
- Fargate eliminates unused capacity costs
- Auto-scaling reduces idle compute
Why Fargate pay-per-use over Reserved EC2? Reserved EC2 instances offer up to 72% savings over On-Demand pricing — but only when utilisation is consistently high. This CRM platform has predictable business-hours peaks and near-zero overnight traffic. With EC2 reserved capacity, you pay for that overnight compute regardless. Fargate tasks scale to zero during off-peak hours, meaning the overnight cost is literally zero. We modelled both options: at the platform's actual utilisation pattern, Fargate came out ~22% cheaper than equivalent Reserved EC2, with the additional benefit of zero capacity management. The trade-off is slightly higher per-vCPU cost at peak — accepted because the off-peak savings more than compensate across a full month.
Reduced Operational Overhead
- Automation reduced manual labor costs
Managed Services
- Reduced DBA and infrastructure management effort
Outcomes
- ~38% overall cost savings
- Improved cost predictability
- Reduced hardware lifecycle expenses
Well-Architected Alignment:
- Adopt consumption model
- Measure overall efficiency
- Stop spending on undifferentiated heavy lifting
6. Sustainability
Goal: Minimise the environmental impact of running cloud workloads.
Sustainability is the newest of the six pillars — added in 2021 — and the one most commonly skipped in modernisation blogs. It deserves more than a footnote.
What changed with this migration:
Moving from on-premises physical servers to AWS Fargate on ECS has a direct and measurable sustainability impact across three dimensions:
Server elimination and energy reduction The legacy CRM ran on dedicated physical servers with fixed power draw — regardless of whether they were serving ten users or ten thousand. Those servers consumed power 24/7, including nights, weekends, and holiday periods when the CRM had near-zero traffic. Fargate tasks scale to zero during off-peak hours, meaning compute energy consumption directly tracks actual workload demand. No idle servers, no idle power draw.
AWS infrastructure efficiency advantage AWS operates at a scale that individual enterprises cannot match. AWS data centres run at Power Usage Effectiveness (PUE) ratings significantly below the industry average of ~1.6 — AWS has published PUE figures approaching 1.2 for its most efficient facilities. Workloads running on AWS infrastructure benefit from this efficiency simply by being there. Additionally, AWS has committed to powering operations with 100% renewable energy — a commitment that covers the ap-south-1 (Mumbai) region where this workload runs.
Right-sizing and overprovisioning elimination On-premises infrastructure is typically overprovisioned to handle peak load — which means the average utilisation is far below capacity, and that idle capacity still consumes power. Auto-scaling on ECS Fargate means the platform runs at consistently higher utilisation, with compute matched to demand in real time.
AWS Customer Carbon Footprint Tool AWS provides the Customer Carbon Footprint Tool in the Cost & Usage dashboard. This tool shows estimated carbon emissions for your AWS usage and compares them against equivalent on-premises emissions. For workloads migrated from physical servers, the reduction is typically substantial — AWS reports that moving on-premises workloads to AWS can reduce carbon emissions by up to 80% depending on region and workload type.
Well-Architected Alignment:
- Understand your impact — measure workload emissions using the Carbon Footprint Tool
- Maximise utilisation — Fargate's serverless model aligns compute consumption with actual demand
- Use managed services — offload infrastructure management to AWS and benefit from their efficiency investments
- Adopt serverless patterns — scale to zero is the most sustainable compute model available
Cross-Pillar Observations
Pillar
Key Modernization Lever
Operational Excellence
CI/CD + Observability
Security
IAM + Secrets Manager + KMS
Reliability
Multi-AZ + Blue/Green
Performance
Fargate + CloudFront
Cost
Serverless scaling
Sustainability
Elastic resource usage
Architectural Maturity Assessment
The modernization demonstrates movement from:
❌ Manual, static, monolithic operations
→
✅ Automated, elastic, secure, observable cloud-native architecture
It aligns strongly with:
- Infrastructure as Code principles
- DevOps-driven change management
- Zero-trust security posture
- Event-driven automation
A Presales Perspective on the Well-Architected Framework
In Presales conversations, the AWS Well-Architected Framework is one of the most powerful tools in the discovery toolkit — not because it impresses customers with AWS vocabulary, but because it gives both sides a shared, structured language to talk about architecture debt honestly.
Most enterprise customers I work with know their current architecture has problems. What they struggle with is articulating which problems matter most, why they matter, and in what order to address them. The six pillars change that conversation. When I walk a customer through a lightweight Well-Architected review — even informally in a whiteboarding session — three things consistently happen: they immediately recognise their own pain points in the pillar descriptions, they start self-identifying gaps they hadn't formally acknowledged before, and the conversation shifts from "we need to migrate to cloud" to "here are the specific architectural decisions we need to make."
The CRM modernisation described in this blog began exactly that way. A WAF-framed discovery surfaced five distinct risk areas — hardcoded credentials, no automated rollback, single-AZ database, fixed hardware capacity, and zero cost visibility — that the customer had previously described collectively as "our system is old and slow." That framing shift, from a vague complaint to five specific, addressable architectural gaps, is what made the business case fundable and the project scoped correctly from day one.
For Presales professionals working with AWS: the Well-Architected Framework is not a post-sale delivery tool. Used early, it is one of the most effective ways to establish technical credibility, structure a customer's thinking, and build a modernisation roadmap that the customer feels ownership over — because they helped identify the gaps themselves.
Final Reflection
Applying the AWS Well-Architected Framework transforms modernization from a migration project into a structured architecture evolution.
This CRM & Employee Portal modernization illustrates that:
- Containerization improves agility
- Automation improves reliability
- Security must be embedded, not layered later
- Managed services reduce undifferentiated operational burden
For AWS architects, the takeaway is clear:
Well-Architected is not a checklist — it is a design discipline.
Author
Rajat Jindal
VP – Presales
AeonX Digital Technology Limited