An online retail app currently runs on two on-prem servers: a web server that renders pages and stores session state in memory, and a MySQL database server that stores orders. Under heavy load, the web server's memory usage nears 100% due to session management. When migrating the web tier to EC2 instances in an Auto Scaling group behind an ALB, what additional changes should be made to improve performance?

The correct approach is to use Amazon ElastiCache for Memcached for session data and Amazon RDS for MySQL for application data. The original web server stores session state in memory, which becomes a bottleneck under heavy load. Migrating to EC2 instances in an Auto Scaling group behind an ALB means multiple web servers will handle requests. To maintain session state across these instances and allow for horizontal scaling, a shared, external session store is necessary. ElastiCache for Memcached is an excellent choice for this, providing a high-performance, in-memory key-value store. Amazon RDS for MySQL is the appropriate managed service for the relational application database, offloading database administration. Hosting MySQL on an EC2 instance and storing both session and application data there would still centralize session state, but it adds operational overhead compared to RDS and Memcached, and MySQL is not optimized for high-speed session storage. Using ElastiCache for Memcached for both session and application data is incorrect because Memcached is not a persistent database and is unsuitable for critical application data. Using EC2 instance store for session data is problematic as instance store is ephemeral; data is lost if the instance stops or terminates, making it unsuitable for session management in a dynamic Auto Scaling environment.