Which combination of architecture changes are needed to ensure all tiers of the solution are highly available?

Explanations:

Refactoring the application to store the user’s session in Amazon ElastiCache allows for session persistence across multiple application instances, ensuring that user sessions are not lost when an instance fails or scales. Using Application Load Balancers to distribute traffic among instances improves fault tolerance and availability.

While generating hourly snapshots is a good practice for backups, it does not directly contribute to high availability. Configuring a CloudWatch Events rule to launch a new database instance if the primary fails does not provide immediate failover capabilities, as it involves manual intervention and does not ensure continuous availability.

Migrating the database to Amazon RDS for SQL Server and configuring it for Multi-AZ deployment provides automatic failover capabilities and redundancy, which enhances the database’s high availability. Multi-AZ ensures that a standby instance is ready to take over in case of primary instance failure.

Moving the .NET content to an S3 bucket and configuring it for static website hosting does not contribute to the high availability of the application tier or the database. It is more suited for serving static content rather than improving the availability of dynamic web application components.

Placing application instances in an Auto Scaling group allows the application to automatically scale based on demand and replace unhealthy instances, enhancing overall availability. If an instance fails, Auto Scaling can launch new instances to maintain the desired capacity.

Deploying Amazon CloudFront can improve performance by caching content and reducing latency, but it does not inherently provide high availability for the application tier. CloudFront requires healthy application instances to serve content, but it does not directly manage instance health or failover scenarios.