The current design colocates the web tier, database, and cache on the same EC2 instances. This causes resource contention and makes it difficult to scale each layer independently. The correct solution is to separate these concerns into independently scalable managed services.

Option D uses an Application Load Balancer (ALB) in front of an Auto Scaling group for the web application. ALB is designed for HTTP/HTTPS traffic, supports path-based and host-based routing, and can spread load evenly across multiple instances and Availability Zones, eliminating the issue where one instance is overloaded.

The database is migrated to Amazon Aurora with Multi-AZ, which provides high availability, automated failover, and managed backups. Aurora offloads database management and ensures consistent performance.

For caching, Option D introduces Amazon ElastiCache for Redis, a managed in-memory cache that is purpose-built for low-latency reads, independent scaling, and high availability through replication and clustering.

Option A and C misuse NLB for HTTP traffic or for Redis exposure and introduce unnecessary complexity. Option B keeps Redis on EC2 (via NLB + ASG in a single AZ), which reduces availability and does not leverage managed caching.

Thus, Option D best separates tiers and improves performance and availability.