Deploying Application Code for Scalability

Answer - B.

Since the time required to spin up an instance is required to be fast, it's better to create an AMI rather than use User Data.

When you use User Data, the script will be run during boot up, and hence this will be slower.

An Amazon Machine Image (AMI) provides the information required to launch an instance, which is a virtual server in the cloud.

You specify an AMI when you launch an instance, and you can launch as many instances from the AMI as you need.

You can also launch instances from as many different AMIs as you need.

For more information on the AMI, please refer to the below link:

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html

When building out a layer in a software stack on AWS that needs to be able to scale out to react to increased demand as fast as possible, it is important to choose an application code deployment method that ensures seamless and efficient deployment of new versions of the code.

In this scenario, the application is running on EC2 instances in an Auto Scaling Group behind an ELB, which means that new instances can be launched and terminated automatically in response to changes in demand. To ensure that new instances can be launched quickly and seamlessly with the latest version of the code, it is recommended to use an application deployment method that supports automation and scalability.

Let's evaluate each of the options given:

Option A: SSH into new instances that come online, and deploy new code onto the system by pulling it from an S3 bucket populated by code that you refresh from source control on new pushes.

This option involves manually deploying new code onto new instances by SSHing into the instances and pulling the code from an S3 bucket. This method is not efficient as it involves manual intervention, which can introduce errors and slow down the deployment process. Also, if there are multiple instances that come online at once, this method may not scale well.

Option B: Bake an AMI when deploying new versions of code, and use that AMI for the Auto Scaling Launch Configuration.

This option involves creating a new AMI with the updated code and using that AMI in the Auto Scaling Launch Configuration. This method is more efficient than option A as it eliminates the need for manual intervention. However, it can still introduce some delay in the deployment process as it takes time to create a new AMI.

Option C: Create a Dockerfile when preparing to deploy a new version to production and publish it to S3. Use UserData in the Auto Scaling Launch configuration to pull down the Dockerfile from S3 and run it when new instances launch.

This option involves creating a Dockerfile that specifies the application code and its dependencies, publishing it to S3, and using UserData in the Auto Scaling Launch configuration to pull down the Dockerfile and run it when new instances launch. This method is more efficient than option B as it eliminates the need to create a new AMI every time the code changes. Instead, the Dockerfile can be updated in place, and new instances can be launched quickly with the latest version of the code.

Option D: Create a new Auto Scaling Launch Configuration with UserData scripts configured to pull the latest code at all times.

This option involves creating a new Auto Scaling Launch Configuration with UserData scripts that are configured to pull the latest code at all times. This method is the most efficient as it eliminates the need for any manual intervention or AMI creation. Instead, new instances are launched with the latest version of the code automatically.

Overall, option C or D would be the recommended approach for this scenario as they are the most efficient and scalable options. Option C may be preferred over option D if the application is containerized, and using Docker is preferred.