Auto Scaling for EC2 Instances: Configuration and OS Patching

Auto Scaling for EC2 Instances with OS Patching

Prev Question Next Question

Question

Your organization had set up Auto Scaling for an EC2 instance.

They intend to launch one additional new instance with same configuration automatically when the workload increases and shut it down automatically when the workload is back to normal.

However, they have applied operating system patches to the main instance for security reasons and would like this to be reflected when the Auto Scaling group launches a new EC2 instance.

What actions would you take in this scenario?

Answers

Explanations

Click on the arrows to vote for the correct answer

A. B. C. D.

Answer: D.

Option A is not correct.

Auto Scaling group launches new instances based on the configuration defined in Launch Configuration.

AMI ID is one of the configuration parameter which defines the type of instance to be launched when auto-scaling logic is executed.

AMI ID is set during the creation of the launch configuration and cannot be modified.

So, the auto-scaling group will not launch a new instance based on the latest image of the main instance.

Option B is not correct.

AMI ID is a configuration on Launch Configuration, not Auto Scaling Group.

Option C is not correct and Option D is correct.

https://docs.aws.amazon.com/autoscaling/ec2/userguide/change-launch-config.html
Launch Configuration:

Details

Al
IAM Instance Profile

ID ami-8b240711

Key Name
EBS Optimized
Spot Price
RAM Disk ID
User data -

Instance Type
Kernel ID
Monit

Security Groups
Creation Time
Block Devices

IP Address Type

‘2.micro

false

Do not assign a public IP address to any instances.

In this scenario, the organization wants to ensure that any new instance launched by the Auto Scaling group has the latest security patches that were applied to the main EC2 instance.

Option A, which suggests that the Auto Scaling group will launch a new instance from the main instance's latest snapshot, is not a suitable solution in this scenario because snapshots capture only the disk contents of the instance, not the state of the instance, including the installed patches.

Option B suggests creating an image (AMI) out of the main EC2 instance and updating the Auto Scaling group configuration with the new image AMI. This option is partially correct, but it doesn't provide a clear way to update the patches on the new instances. Creating a new image AMI I based on the main EC2 instance will capture its state, including the installed patches, but the AMI needs to be regularly updated with the latest security patches.

Option C is more appropriate. It suggests creating an image out of the main EC2 instance and updating the Launch Configuration with the new image AMI I. This way, any new instances launched by the Auto Scaling group will have the latest patches applied to the main EC2 instance.

Option D is the best solution in this scenario. It suggests creating an image out of the main EC2 instance, creating a new Launch Configuration with the new image AMI ID, and updating the Auto Scaling group with the new Launch Configuration ID. This option allows you to keep the existing Launch Configuration and update it with the new image AMI ID, which helps avoid any configuration errors that may arise from creating a new Launch Configuration from scratch.

In summary, the correct option in this scenario is option D. You should create a new image AMI based on the main EC2 instance, create a new Launch Configuration with the new image AMI ID, and update the Auto Scaling group with the new Launch Configuration ID. This approach ensures that any new instances launched by the Auto Scaling group have the latest security patches applied to the main EC2 instance.