Hello, welcome to another episode of 'Back to Basics'.
I'm Hareesh Singireddy, a solutions architect at AWS.
Today, we are going to talk about building and maintaining
Amazon Machine Images or AMIs.
AMIs are templates that contain a software configuration.
For example, an operating system,
an application server and applications.
From an AMI, you launch an instance,
which is a copy of the AMI, running as
a virtual server in the cloud.
A common pattern is to set up a process to create
golden AMIs through standardized configurations.
Like adding your own monitoring agents,
consistent security patching and hardening.
But often times, setting up the process
is time-consuming, resource-intensive,
and error-prone.
EC2 Image Builder lets you simplify that
using a one-stop shop to create
an image management pipeline.
Let's say you'd like to build a baseline
AMI with some custom configuration
and security tools installed.
And once the image is built, you'd like to share it
with other regions within the account,
or with other AWS accounts within your organization.
Let's see how EC2 Image Builder can help you
simplify and automate this process.
The first step is to create an image recipe.
Yes, as the name suggests, it's a document that defines
the components to be applied to the source image
to produce the AMI you wanted.
Think of the components as the building blocks
for that image.
Image Builder, out of the box, also comes
with a set of Amazon-managed components
for common packages and security standards,
such as STIG.
It also comes with AWS-provided test components,
that can be, for example, verify if images booth properly,
requires drivers are installed, and if images are hardened
to CIS standards.
You can also create your custom components
to install your packages, apply configurations
and run tests.
Now that you have your recipe ready,
let's take a look at the infrastructure configuration
that is used to build the AMIs.
Image Builder launches EC2 instances
in your AWS account to customize images
and run validation tests.
You might need to customize this configuration
to suit your needs.
Maybe a bigger instance, so that you can build
components faster, or one of your components needs to
download a package from S3, and you need
an IAM role attached to the build instance.
You can optionally create this infrastructure configuration
within Image Builder.
As part of the configuration, you can also define
what should happen if the build fails
and configure logs to be routed to an S3 bucket.
Now, you have enough details to build an image.
Let's see how you can share it with your application teams.
Multi-account and multi-region setups are a very common pattern.
You might be running applications in a region
that's closer to your customers, and using
multiple different AWS accounts
for production and non-production workloads.
You can use Image Builder distribution configuration
to define additional regions to copy the image to
and with each region you can also define other
AWS accounts that can have launch permissions.
And the final step would be to create an image pipeline
that automates the build process.
Image Pipeline is the automation configuration
that ties all of these pieces together.
As part of the Image Pipeline, you first create a
Build Schedule.
Build Schedule lets you define a job schedule
to run the pipeline automatically.
A powerful feature of it is to run it only
if there are dependency updates.
For example, if there is a new version of the parent image,
or one of the components has an update.
You can also choose to run the pipeline manually
if you need to.
And after the Build Schedule, you add the image recipe,
the infrastructure configuration and the distribution configuration
that you've just created, to the pipeline.
That's it, you now have an image pipeline
that runs at a schedule and builds your images
to your specifications and shares it automatically.
Check out the resources in the description below
to learn more about EC2 Image Builder.
And thanks for tuning in.