Applying the Framework: A Practical Review

In this lesson, we bring together everything you have learned about the AWS Well-Architected Framework by walking through a practical review of a fictional e-commerce application. You will see how to assess each pillar, identify risks, and build an improvement plan.

---

The Scenario

ShopFast is a growing e-commerce company that has migrated its platform to AWS. The architecture currently looks like this:

• Frontend: React application hosted on a single EC2 instance running Nginx
• API: Node.js REST API on two EC2 instances behind an Application Load Balancer
• Database: Single RDS MySQL instance (no Multi-AZ, no read replicas)
• Storage: Product images stored in S3
• Authentication: Custom auth module with passwords stored in the application database
• Deployments: Manual deployments via SSH from a developer's laptop
• Monitoring: Basic CloudWatch CPU alarms on EC2 instances
• Networking: All resources in a single VPC, single Availability Zone
• IAM: One shared IAM user with administrator access used by all developers
• Backups: RDS automated backups enabled with 7-day retention; no tested restore process

Let's review this architecture against each pillar.

---

Pillar 1: Operational Excellence

Current State Assessment

Practice	Status
Infrastructure as code	Not implemented — all resources created manually
CI/CD pipeline	No pipeline — deployments via SSH
Monitoring and alerting	Basic CPU alarms only
Runbooks and playbooks	None documented
Post-mortem process	Ad hoc, not documented

High-Risk Issues

1. No infrastructure as code — environments cannot be reproduced reliably. If a disaster occurs, the team must rebuild manually from memory
2. Manual deployments — high risk of human error, no audit trail, no rollback capability
3. Insufficient monitoring — CPU alarms alone do not capture application health (error rates, latency, business metrics)

Recommendations

• Adopt AWS CDK or CloudFormation to define all infrastructure as code
• Implement a CI/CD pipeline using AWS CodePipeline and CodeDeploy
• Add CloudWatch custom metrics for application error rate, response time, and order throughput
• Create runbooks for common operational tasks (deployments, database failover, incident response)

---

Pillar 2: Security

Current State Assessment

Practice	Status
Least privilege IAM	Not implemented — shared admin user
MFA	Not enabled on root or IAM users
Encryption at rest	RDS encryption enabled; EBS volumes not encrypted
Encryption in transit	HTTPS on ALB; no TLS between internal services
Secrets management	Database password hardcoded in application config
Threat detection	GuardDuty not enabled

High-Risk Issues

1. Shared IAM administrator user — no individual accountability, no audit trail per person, and a single compromised credential exposes the entire account
2. No MFA — root user and IAM users have no multi-factor authentication
3. Hardcoded secrets — database password in application code is a significant security risk

Recommendations

• Create individual IAM users with least-privilege policies. Use IAM roles for applications
• Enable MFA on all users, especially the root user
• Migrate secrets to AWS Secrets Manager
• Enable GuardDuty for threat detection
• Encrypt all EBS volumes and enforce HTTPS everywhere

---

Pillar 3: Reliability

Current State Assessment

Practice	Status
Multi-AZ deployment	Single AZ only
Database high availability	Single RDS instance, no Multi-AZ
Auto Scaling	Not configured
Tested backup restoration	Backups enabled but never tested
Defined RTO/RPO	None defined

High-Risk Issues

1. Single AZ deployment — an AZ outage would take down the entire application
2. Single RDS instance — no automatic failover; database failure means extended downtime
3. Untested backups — backups exist but the team has never verified they can restore from them

Recommendations

• Deploy across at least two Availability Zones
• Enable RDS Multi-AZ for automatic database failover
• Implement EC2 Auto Scaling to handle demand changes and replace failed instances
• Define RTO and RPO targets (e.g., RTO: 1 hour, RPO: 15 minutes)
• Test database restoration quarterly

---

Pillar 4: Performance Efficiency

Current State Assessment