Which solution will meet these requirements?
Create an Amazon Elastic File System (Amazon EFS) file system. Create a new launch template version that includes user data that mounts the EFS file system. Update the Auto Scaling group to use the new launch template version to cycle in newer EC2 instances and to terminate the older EC2 instances.
Enable Multi-Attach on the EBS volumes. Create a new launch template version that includes user data that mounts the EBS volume. Update the Auto Scaling group to use the new template version to cycle in newer EC2 instances and to terminate the older EC2 instances.
Create a cron job that synchronizes the data between the EBS volumes for all the EC2 instances in the Auto Scaling group. Create a lifecycle hook during instance launch to configure the cron job on all the EC2 instances. Rotate out the older EC2 instances.
Create a new launch template version that creates an Amazon Elastic File System (Amazon EFS) file system. Update the Auto Scaling group to use the new template version to cycle in newer EC2 instances and to terminate the older EC2 instances.
Explanations:
Creating an Amazon EFS file system allows all EC2 instances to share the same underlying files. By updating the launch template to include user data that mounts the EFS file system, new instances will automatically mount it on startup. This solution ensures data consistency as EFS provides strong consistency for file operations. Updating the Auto Scaling group to use this new launch template version ensures that older instances can be replaced with the new configuration.
Enabling Multi-Attach on EBS volumes allows multiple EC2 instances to attach to the same EBS volume; however, it does not ensure consistent file access and could lead to data corruption due to the lack of a coordinated file system. EBS is designed for single-instance use and isn’t meant for concurrent access by multiple instances without proper synchronization mechanisms. Therefore, this option does not meet the requirement for data consistency.
While a cron job could synchronize data between EBS volumes, this method does not provide real-time data sharing or consistency across instances. Data synchronization introduces latency and potential inconsistencies, especially if multiple instances are trying to read/write data simultaneously. Additionally, relying on a cron job complicates the architecture and does not provide an optimal solution for sharing files among instances in an Auto Scaling group.
Creating a new launch template version to create an EFS file system is redundant, as EFS is a separate resource and does not need to be created each time an instance launches. Furthermore, simply updating the Auto Scaling group to use this template does not ensure that the existing instances can share files consistently, as it doesn’t address mounting the EFS file system in the instances already running. Thus, this option does not provide a valid solution for the requirement.