AWS Beanstalk uses AMI as the basis for the EC2 instances it launches to run our apps. Bobcares, as a part of our AWS Support Services offers solutions to every query that comes our way.

Overview

1. More About AWS AMIs (Amazon Machine Image)
2. Standard AMI
   • What is a Standard AMI?
   • Advantages of Standard AMI
   • Disadvantages of Standard AMI
3. Custom AMI
   • What is a Custom AMI?
   • Advantages of Custom AMI
   • Disadvantages of Custom AMI
   • Creating a Custom AMI
   • Cleaning a Custom AMI
4. Conclusion

More About AWS AMIs (Amazon Machine Image)

In the context of Amazon Web Services (AWS), an Amazon Machine Image (AMI) is simply a template for building virtual servers. Consider it as a pre-assembled package that includes the operating system, apps, libraries, and configurations needed to start a cloud instance, or virtual server. The basis for EC2 (Elastic Compute Cloud) instances is provided by AMIs.

There are two primary types of AMIs available:

1. Standard AMIs:

These are supplied and managed by third-party companies or AWS. They are pre-configured with popular operating systems (like Windows Server, Ubuntu, and Amazon Linux) and frequently come with well-known software stacks (such web servers and databases) to accommodate a range of use cases.

2. Custom AMIs:

Users are able to design custom AMIs that meet their own needs. This include installing needed software, tweaking settings, storing the modified image, and customizing an existing AMI or beginning from scratch. Custom AMIs are appropriate for specific applications or unusual configurations since they provide flexibility and control over the environment’s setup.

When we create an Elastic Beanstalk environment, we have the option to specify either a standard AMI provided by AWS or a custom AMI that we’ve created and configured. Let’s look into the details of each category.

Standard AMI

What is a Standard AMI?

The vendor (Amazon for Amazon Linux, Canonical for Ubuntu, CentOS for CentOS, Microsoft for Windows, and so on) provides us with a standard AMI.

If we don’t care too much about patch levels and have a tiny codebase, standard AMIs can be helpful. With standard AMIs, we can stop worrying about keeping own AMI up to date with the newest updates. With the most recent security updates in the new AMI, we can rebuild the environment and get started right away. We just need to rebuild the environment using the most recent AMIs.

To prevent taking the application offline, it is best to start rebuilding the environment with a small portion of it or build a new cluster and point the DNS to the load balancer.

Advantages of Standard AMI

1. Patching Convenience: Standard AMIs come pre-patched with the latest updates, saving us the hassle of applying patches manually.

2. Code Updates Simplified: We don’t need to update AMIs with the application code changes. Instead, the deployment process should involve fetching the latest code from the repository.

3. Faster Automation: Automating processes with standard AMIs is quicker than with custom ones, reducing setup time and effort.

4. Easy Instance Updates: We can update new instances effortlessly using user data for bootstrapping, streamlining the update process.

Disadvantages of Standard AMI

1. Longer to boot up to application readiness. Before the instance can be used to deliver content, it must retrieve all of its third-party tools, the application, deploy it, and configure it.

2. It’s unlikely that the team have reviewed patches. As such, we are unable to correctly prevent compliance issues or mark such boxes.

Since Standard AMIs are maintained by AWS and come pre-configured with the necessary software stack for the supported platforms, we are not discussing it’s configuration details here.

Custom AMI

What is a Custom AMI?

On the other side, custom AMIs are AMIs that we design and alter to meet our unique needs. If we need to incorporate extra tools or configurations, have specific software requirements, or want more control over the environment’s setup, we may need to construct a bespoke AMI. We can carefully customize the environment to meet the requirements of the application with custom AMIs.

If we have a large codebase and are concerned about the changes that are applied for code compliance or reliability, custom AMIs can be helpful. Although custom AMIs need more work, we have complete control over the AMI’s state and the fixes that are applied.

Advantages of Custom AMI

1. We are aware of the patch levels being used, which can improve code dependability and assist with compliance issues. If there aren’t many changes to the code, we can pre-stage the codebase on the servers.

2. On the systems, we can pre-stage other apps like Splunk, NewRelic, or other client monitoring agents so we won’t have to worry about configuration afterwards.

3. Reduced startup to application readiness time. When the new instance boots up, it should be prepared to handle application requests as the code is already on the instance and doesn’t need to be fetched.

4. Transferring the AMI with ease between regions can be used for backups.

Disadvantages of Custom AMI

1. Setting up and handling a personal AMI deployment process.

2. If the AMI generation process isn’t automated, updating the AMI for each application requires a specific amount of human labor.

3. The AMI has to be updated to reflect new code whenever it is released.

4. Starting and continuing process development can be expensive and time-consuming.

Creating a Custom AMI

1. Initially, run a command in the command window specifying the AWS Region and platform ARN.

2. Replace the platform ARN and version number with the Elastic Beanstalk platform details.

3. Take note of the ImageId value returned, which is the stock Elastic Beanstalk AMI for the platform.

Don’t create an AMI from an instance launched in an Elastic Beanstalk environment as it can cause issues. Also, it’s best to use the latest platform version for compatibility and updates.

Now to create Custom AMI, follow the below steps:

4. Open the Amazon EC2 console and choose Launch Instance.

5. Choose Community AMIs and enter the base Elastic Beanstalk AMI ID.

6. Select the desired instance type and proceed to configure instance details.

7. For Linux platforms, add specific text in the User Data field to configure repository settings.

8. Connect to the instance and perform any customizations needed.

9. For Windows platforms, run the EC2Config service Sysprep and stop the EC2 instance.

10. Choose Create Image (EBS AMI) from the Instance Actions menu to create the custom AMI.

11. Stop the EC2 instance to avoid additional charges.

Using Custom AMI in Elastic Beanstalk:

12. Open the Elastic Beanstalk console and select the AWS Region.

13. Go to Environments and choose the desired environment.

14. In Configuration, edit the Capacity configuration.

15. Enter the custom AMI ID in the AMI ID field and apply the changes.

16. When creating a new environment with the custom AMI, use the same platform version as the base.

17. Elastic Beanstalk will attempt to apply updates during the bootstrapping process if we later apply a platform update to an environment using a custom AMI.

Cleaning a Custom AMI

In order to reduce storage costs, think about cleaning up a custom AMI after we finish with it and are no longer able to use it to launch Elastic Beanstalk environments. Deregistering a custom AMI from Amazon EC2 and removing any related resources are the first steps in cleaning it up.

[Looking for a solution to another query? We are just a click away.]

Conclusion

In conclusion, Amazon Elastic Beanstalk simplifies the deployment and management of apps by providing the option to use either standard or custom Amazon Machine Images (AMIs).