In the last few chapters, we have focused on creating and managing instances. This chapter is about the templates we use to create those instances. Amazon refers to these templates as Amazon Machine Images (AMIs). In this chapter we will explore the AMIs that already exist, and we will discuss how to create your own AMI and share it with others. Finally, we learn how to import a VM from VMware or Hyper-V into AWS.
Many users will never have occasion to create a custom AMI. Most users will be happy with the countless images that Amazon and its partners make available. But some users will want to have complete control over their environment. For example, you may have a corporate server image that you want to make available to your companies’ employees that are using AWS.
As your experience progresses, you will likely find that you want to automate instance builds. Configuration management tools are all about scripting server builds to minimize build time and ensure consistency between builds. Assuming you want to automate the build, there are many options. Most fall on a spectrum somewhere between scripted builds and prepared images.
Working with Scripted Builds and Prepared Images
At one end of the spectrum is the scripted build. With a scripted build, you start with a generic image and use a series of scripts to configure the server as needed. For example, to create a Web Server, you might start with the Amazon Windows Server 2019 Base image. Then you could use the user data to include a custom PowerShell script that enables the Web Server role and downloads the application from source control.
At the other end of the spectrum is the prepared image. With a prepared image, you configure the server, usually manually, and then create an image. When a user needs a new server, he or she selects your server image and creates a new instance. If you choose a prepared image, be sure to update the image periodically with the latest security patches and virus definitions.
Both options have benefits and drawbacks. The scripted build is best when the application is changing often. You always get the latest code and can change the script as requirements change. The prepared image, on the other hand, is best when the application is stable. There are fewer external dependencies that can cause errors and the build is usually faster.
Of course, there are many options on the spectrum between scripted build and prepared image. The Amazon Windows AMIs provide a good example. Amazon offers a base image as well as SQL Server images. By using the SQL Server image, you do not have to script the configuration of SQL Server. You simply focus on scripting the deployment of your application.
Most of this chapter is focused on preparing images, but don’t overlook scripting as an option. There are many AWS Services that will help you script instance configuration such as CloudFormation and OpsWorks. Chapters 15–17 will cover Systems Manager which can be used to script instance configuration with Ansible, Salt, or PowerShell Desired State Configuration (DSC) .
Listing AMIs
Before we create our own AMI, or simply an image, let’s take a deeper look at the images that are already available. We don’t want to spend time creating and maintaining an image if an identical image already exists.
Caution
There are over 100,000 images available giving you a ton of options to choose from, but be careful! You should only launch images from publishers you trust. As you will see later in this chapter, anyone can publish an image.
You can find images using the Get-EC2Image command, but this command will return the complete list of over 100,000 images. Obviously, this is far too many to look through one at a time.
Limiting the Number of Instance Results
Finding an Instance by Name
So, let’s review. We can use a combination of the platform and owner-alias filters to discover new images from a trusted source. Then, once we know the name, we can search by name. If all of this seems cumbersome to you, I agree. Wouldn’t it be great if we had a short list of the most common images?
Locating the Most Common Images
You can run Get-EC2ImageByName without any parameters to get a list of available names.
Now that we know how to find images, we can decide whether we need to create our own. Let’s assume that none of the existing images meet our needs and we have decided to create our own image. Images are created using SysPrep and the EC2Config Service. Before we get started creating an image, let’s look at EC2Launch.
Introducing EC2Launch
Before we move on to creating an image, I want to introduce EC2Launch. Note that EC2Launch runs on Windows 2016 or newer images. It replaces the EC2Config Service that was installed on Windows images through 2012 R2. We have mentioned these tools a few times in prior chapters, but now is a good time to look at it in detail.
EC2Launch is used to configure Windows instances. It plays a critical role in configuring an instance when it boots for the first time. For example, the EC2Launch is responsible for encrypting the administrator password and executing scripts in the user data.
- 1.
Renames the computer. This is disabled by default.
- 2.
Sets the administrator password. By default, a new, random password will be generated and encrypted with the specified key pair.
- 3.
Creates RDP certificate. A new self-signed host certificate is created for Remote Desktop connection. You cannot use RDP without a certificate.
- 4.
Extends the OS partition. Remember that you can change the size of the OS volume at launch. Therefore, the service extends the partition to fill the volume.
- 5.
Activates Windows if necessary.
- 6.
Writes event log entries to the AWS System Log. This can help debug errors that occur before RDP is available in the boot sequence.
- 7.
Creates a new wallpaper image. This includes useful information (name, type, memory, etc.) about the image.
- 8.
Configures a few custom routes. For example, 169.254.169.250 and 169.254.169.251 are the default KMS servers and 169.254.169.254 is the metadata URL we used in Chapter 3.
Now that we understand EC2Launch, let’s look at the EC2LaunchSettings tool.
Preparing an AMI Using EC2LaunchSettings
In the prior section, we learned about EC2Launch. In this section we will prepare an image of our own. To start, launch a new Windows Server 2019 Base instance that will serve as our template. You remember how to do that right?
Once the instance boots, you can log in and make whatever changes you want. Let’s assume we are developing a web application and we want to create a server to test it on. Our application requires that we enable a few unique features of IIS.
Once you have configured your server and installed any software you want in the template, it is time to prepare the image. As I mentioned in the prior section, you use EC2LaunchSettings to create an image. Behind the scenes, EC2LaunchSettings uses SysPrep to do the heavy lifting.
Caution
Before continuing, you should take a snapshot of the instance. Once we SysPrep the image, there is no going back. If the instance fails to boot, you will have to start over from scratch.
Open the Ec2LaunchSettings application (see Figure 7-1 for reference). Leave the defaults and simply click the Shutdown with SysPrep button. This will take a few minutes. Once it’s done, we can finally create the AMI.
Creating an AMI
The instance is now configured and waiting to run setup. We want to clone the instance in this state, so that each copy runs setup when it first boots. It’s finally time to create an image. Let’s look at the AWS Administration Console first and then discuss the PowerShell commands.
At this point you have your own custom AMI and you can create instances. This same process can be used to make as many variations as you need. If you find that an image is particularly useful, you may want to share it with others. In the next section, I will show you how to share your image.
Sharing an AMI
You may find that you want to share an image with other accounts. Maybe your company has multiple accounts and you want to use a single corporate image across all accounts. Or maybe you have an image that includes a trial version of your company’s software and you want to share it with the world.
As you can see, AMIs are a powerful tool. You can leverage the tens of thousands of existing images, create your own images, and even share your images with others.
Although it is easy to customize an Amazon AMI, it would be great if we could leverage the library of images we already have onsite. In Exercise 7.1, I will show you how to import an existing VM image from an onsite hypervisor like VMware or Hyper-V.
Exercise 7.1: Uploading a VM
Many of us already have a library of images that we have built for our VMware or Hyper-V environments. Luckily Amazon allows you to upload an existing image into EC2.
There are a few ways to do this. If you have a lot of instances to import, you should look at the Server Migration Service (SMS). SMS is easiest way to import VMs into AWS. However, this is a book on PowerShell, so let's import an image using PowerShell.
- 1.
Check that remote desktop is enabled.
- 2.
Check that Windows Firewall allows public RDP traffic.
- 3.
Ensure that DHCP is enabled.
- 4.
Disable antivirus and intrusion detection systems.
- 5.
Remove any virtualization tools such as the VMware Tools.
- 6.
Disconnect any DVD (or other removable media) devices.
- 7.
Stop the VM before importing it.
Now, it is time to export the image from your hypervisor. The import process supports VMDK, VHD, and OVF file formats. Let’s assume that our file is called GoldenImage.vmdk.
Next we upload the file to an S3 bucket. We are going to do this in two parts: first, upload the file to S3 and, second, import the image. Splitting it into two parts is really ingenious. It means that we could bulk import a bunch on VMs using an AWS Snowball. Snowball is a hardware appliance for importing (or exporting) large volumes of data through the mail.
We will cover S3 in detail in Chapter 11. For now, I will assume you have an S3 bucket called mybucket. You can upload the file like this:
Write-S3Object -File GoldenImage.vmdk -BucketName mybucket
Once the conversion completes, you will have an instance running in EC2 Classic. The import command does not clean up the temporary data stored in S3. You can delete it manually or use the ec2-delete-disk-image command .
Once your instance is imported, you can either use it as is or follow the instructions in this chapter to create derivative images. As you can see, the Import-EC2Image command will allow you to leverage your existing image library in the cloud and ensure that you have the same bits running on site and in the cloud.
Summary
In this chapter, we learned about Amazon Machine Images. We saw how to find and leverage the over 100,000 images already available. Then we discussed how to create our own custom images. We discussed how to prepare a Windows instance using SysPrep. Finally, we learned how to share our images with others and import images from our on-prem infrastructure.
Then, in the first exercise, we saw an alternative to rolling a custom image: scripted builds. In the second exercise, we saw how to import an existing image from VMware or Hyper-V. In the next chapter, we will talk about scalability and high availability.