2.2 Amazon EC2 Amazon Machine Image(AMI)

Overview

An AMI defines every aspect of the software state at instance launch, including:

• The Operating System (OS) and its configuration
• The initial state of any patches
• Application or system software

An AMI includes the following:

• One or more Amazon Elastic Block Store (Amazon EBS) snapshots, or, for instance-store-backed AMIs, a template for the root volume of the instance (for example, an operating system, an application server, and applications).

• Launch permissions that control which AWS accounts can use the AMI to launch instances.

• A block device mapping that specifies the volumes to attach to the instance when it's launched.

AMI Sources

All AMIs are based on x86 OSs, either Linux or Windows. There are four sources of AMIs:

• Published by AWS
• The AWS Marketplace
• Generated from Existing Instances
• Uploaded Virtual Servers 

AMI Types

You can select an AMI to use based on the following characteristics:

• Region 

• Operating system

• Architecture (32-bit or 64-bit)

• Launch permissions

• Storage for the root device

Region

• AMIs are specific to a region, but can be copied over to other regions

Launch permissions

The owner of an AMI determines its availability(who has access to the AMI) by specifying launch permissions. Launch permissions fall into the following categories.

Launch permission	Description
public	The owner grants launch permissions to all AWS accounts.
explicit	The owner grants launch permissions to specific AWS accounts.
implicit	The owner has implicit launch permissions for an AMI.

Storage for the root device

• All AMIs are categorized as either backed by Amazon EBS or backed by instance store.
• The former means that the root device for an instance launched from the AMI is an Amazon Elastic Block Store (Amazon EBS) volume created from an Amazon EBS snapshot.
• The latter means that the root device for an instance launched from the AMI is an instance store volume created from a template stored in Amazon S3.

The following table summarizes the important differences when using the two types of AMIs.

Characteristic	Amazon EBS-backed AMI	Amazon instance store-backed AMI
Boot time for an instance	Usually less than 1 minute	Usually less than 5 minutes
Size limit for a root device	16 TiB	10 GiB
Root device volume	EBS volume	Instance store volume
Data persistence	By default, the root volume is deleted when the instance terminates(By default, EBS root volumes have the DeleteOnTermination flag set to true). Data on any other EBS volumes persists after instance termination by default.	Data on any instance store volumes persists only during the life of the instance.
Modifications	The instance type, kernel, RAM disk, and user data can be changed while the instance is stopped.	Instance attributes are fixed for the life of an instance.
Charges	You're charged for instance usage, EBS volume usage, and storing your AMI as an EBS snapshot.	You're charged for instance usage and storing your AMI in Amazon S3.
AMI creation/bundling	Uses a single command/call	Requires installation and use of AMI tools
Stopped state	Can be in a stopped state. Even when the instance is stopped and not running, the root volume is persisted in Amazon EBS	Cannot be in stopped state; instances are running or terminated

AWS EBS vs Instance Store: https://jayendrapatil.com/aws-ebs-vs-instance-store/

Linux AMI virtualization types

• Linux Amazon Machine Images use one of two types of virtualization:
  • paravirtual (PV)
  • hardware virtual machine (HVM).
• The main differences between PV and HVM AMIs are the way in which they boot and whether they can take advantage of special hardware extensions (CPU, network, and storage) for better performance.
• For the best performance, we recommend that you use current generation instance types and HVM AMIs when you launch your instances.
• Historically, PV guests had better performance than HVM guests in many cases, but because of enhancements in HVM virtualization and the availability of PV drivers for HVM AMIs, this is no longer true, HVM guests can get the same, or better, performance than paravirtual guests.

HVM

• HVM AMIs are presented with a fully virtualized set of hardware and boot by executing the master boot record of the root block device of your image.
• This virtualization type provides the ability to run an operating system directly on top of a virtual machine without any modification, as if it were run on the bare-metal hardware.
• The Amazon EC2 host system emulates some or all of the underlying hardware that is presented to the guest.
• HVM guests can take advantage of hardware extensions that provide fast access to the underlying hardware on the host system.
• HVM AMIs are required to take advantage of enhanced networking and GPU processing. In order to pass through instructions to specialized network and GPU devices, the OS needs to be able to have access to the native hardware platform; HVM virtualization provides this access.
• All current generation instance types support HVM AMIs.
• All Regions support HVM instances.

PV

• PV AMIs boot with a special boot loader called PV-GRUB, which starts the boot cycle and then chain loads the kernel specified in the menu.lst file on your image.
• Paravirtual guests can run on host hardware that does not have explicit support for virtualization.
• Paravirtual guests cannot take advantage of special hardware extensions such as enhanced networking or GPU processing.
• The following previous generation instance types support PV AMIs: C1, C3, HS1, M1, M3, M2, and T1. Current generation instance types do not support PV AMIs
• Supported region：Asia Pacific (Tokyo), Asia Pacific (Singapore), Asia Pacific (Sydney), Europe (Frankfurt), Europe (Ireland), South America (São Paulo), US East (N. Virginia), US West (N. California), and US West (Oregon)

Shared AMIs

• A shared AMI is an AMI that a developer created and made available for other developers to use. 
• AMIs with encrypted volumes cannot be made public.
• AMIs are a regional resource. Therefore, sharing an AMI makes it available in that Region. To make an AMI available in a different Region, copy the AMI to the Region and then share it.
• If an AMI has a product code, or contains a snapshot of an encrypted volume, you can't make it public; you can share the AMI only with specific AWS accounts.
•  You can only share AMIs that have unencrypted volumes and volumes that are encrypted with a customer managed key. If you share an AMI with encrypted volumes, you must also share any customer managed keys used to encrypt them. 
• There is no limit to the number of AWS accounts with which an AMI can be shared.
• User-defined tags that you attach to a shared AMI are available only to your AWS account and not to the other accounts that the AMI is shared with.
• If you have created a public AMI, or shared an AMI with another AWS user, you can create a bookmark that allows a user to access your AMI and launch an instance in their own account immediately. This is an easy way to share AMI references, so users don't have to spend time finding your AMI in order to use it.

Guidelines for shared Linux AMIs

• Update the AMI tools before using them: for AMIs backed by instance store
• Disable password-based remote logins for root
  • Open the /etc/ssh/sshd_config: PermitRootLogin without-password
• Disable local root access
  • log into your running instance and issue the following command:​​​​​​​ [ec2-user ~]$ sudo passwd -l root
• Remove SSH host key pairs
  • remove the existing SSH host key pairs located in /etc/ssh.
  • This forces SSH to generate new unique SSH key pairs when someone launches an instance using your AMI
• Install public key credentials
  • After configuring the AMI to prevent logging in using a password, you must make sure users can log in using another mechanism.
  • Amazon EC2 allows users to specify a public-private key pair name when launching an instance. 
• Disabling sshd DNS checks (optional)
  • Disabling sshd DNS checks slightly weakens your sshd security.
  • However, if DNS resolution fails, SSH logins still work. If you do not disable sshd checks, DNS resolution failures prevent all logins.
  • Open the /etc/ssh/sshd_config file : UseDNS no​​​​​​​
• Protect yourself
  • We recommend against storing sensitive data or software on any AMI that you share.
  • using the --exclude directory option on ec2-bundle-vol to skip any directories and subdirectories that contain secret information 
  • Always delete the shell history before bundling.
  • Bundling a running instance requires your private key and X.509 certificate. Put these and other credentials in a location that is not bundled  (such as the instance store).

AMI lifecycle

Create an AMI

Create an Amazon EBS-backed Linux AMI

• Create a Linux AMI from an instance:
  • First, launch an instance from an AMI that's similar to the AMI that you'd like to create.
  • You can connect to your instance and customize it.
  • When the instance is configured correctly, ensure data integrity by stopping the instance before you create an AMI
  • Then create the image. When you create an Amazon EBS-backed AMI, we automatically register it for you.

​​​​​​​​​​​​​​

• Create a Linux AMI from a snapshot:If you have a snapshot of the root device volume of an instance, you can create an AMI from this snapshot using the AWS Management Console or the command line.
• During the AMI-creation process, Amazon EC2 creates snapshots of your instance's root volume and any other EBS volumes attached to your instance. You're charged for the snapshots until you deregister the AMI and delete the snapshots.
• After the process completes, you have a new AMI and snapshot created from the root volume of the instance. When you launch an instance using the new AMI, we create a new EBS volume for its root volume using the snapshot.
• If you add instance-store volumes or EBS volumes to your instance in addition to the root device volume, the instance-store volumes specified in the block device mapping for the new instance are new and don't contain any data from the instance store volumes of the instance you used to create the AMI.

Create an instance store-backed Linux AMI

• Only the following instance types support an instance store volume as the root device: C3, D2, G2, I2, M3, and R3.
• Creation process
  • First, launch an instance from an AMI that's similar to the AMI that you'd like to create.
  • You can connect to your instance and customize it.
  • When the instance is set up the way you want it, you can bundle it.
  • Next you upload the bundle to your Amazon S3 bucket and then register your AMI.
• Prerequisites: Before you can create an AMI, you must complete the following tasks:
  • Install the AMI tools. 
  • Install the AWS CLI. 
  • Ensure that you have an Amazon S3 bucket for the bundle. 
  • Ensure that you have your AWS account ID.
  • Ensure that you have your access key ID and secret access key. 
  • Ensure that you have an X.509 certificate and corresponding private key(Used by AMI tools)
  • Connect to your instance and customize it.
• Convert your instance store-backed AMI to an Amazon EBS-backed AMI
  • 1.Launch an Amazon Linux instance from an Amazon EBS-backed AMI
  • 2.Upload the X.509 private key that you used to bundle your instance store-backed AMI to your instance. 
  • 3.Set environment variables for your AWS access key and secret key.
  • 4.Prepare an Amazon Elastic Block Store (Amazon EBS) volume for your new AMI.
  • 5.Create a folder for your bundle.
  • 6.Download the bundle for your instance store-based AMI to /tmp/bundle using the ec2-download-bundle command.
  • 7.Reconstitute the image file from the bundle using the ec2-unbundle command.
  • 8.Copy the files from the unbundled image to the new EBS volume.
  • 9.Probe the volume for any new partitions that were unbundled.
  • 10.List the block devices to find the device name to mount.
  • 11.Create a mount point for the new EBS volume and mount the volume.
  • 12.Open the /etc/fstab file on the EBS volume with your favorite text editor and remove any entries for instance store (ephemeral) volumes. 
  • 13.Unmount the EBS volume and detach it from the instance.
  • 14.Create an AMI from the new EBS volume.
  • 15. After you have tested that you can launch an instance from your new AMI, you can delete the EBS volume that you created for this procedure.

Copy an AMI

• You can copy an Amazon Machine Image (AMI) within or across AWS Regions using the AWS Management Console, the AWS Command Line Interface or SDKs, or the Amazon EC2 API, all of which support the CopyImage action.
• You can copy both Amazon EBS-backed AMIs and instance-store-backed AMIs.
• You can copy AMIs with encrypted snapshots and also change encryption status during the copy process.​​​​​​​

Scenario	Description	Supported
1	Unencrypted-to-unencrypted	Yes
2	Encrypted-to-encrypted	Yes
3	Unencrypted-to-encrypted	Yes
4	Encrypted-to-unencrypted	No

• You can change or deregister the source AMI with no effect on the target AMI
• With an Amazon EBS-backed AMI, each of its backing snapshots is copied to an identical but distinct target snapshot.
  • If you copy an AMI to a new Region, the snapshots are complete (non-incremental) copies.
  • If you encrypt unencrypted backing snapshots or encrypt them to a new KMS key, the snapshots are complete (non-incremental) copies.
  • Subsequent copy operations of an AMI result in incremental copies of the backing snapshots.
• You can use IAM policies to grant or deny users permissions to copy AMIs. Resource-level permissions specified for the CopyImage action apply only to the new AMI. You cannot specify resource-level permissions for the source AMI.
• AWS does not copy launch permissions, user-defined tags, or Amazon S3 bucket permissions from the source AMI to the new AMI.
• If you are using an AWS Marketplace AMI, or an AMI that was directly or indirectly derived from an AWS Marketplace AMI, you cannot copy it across accounts.
• Destination Regions are limited to 100 concurrent AMI copies.
• You cannot copy a paravirtual (PV) AMI to a Region that does not support PV AMIs.

Store and restore an AMI using S3

• You can store an Amazon Machine Image (AMI) in an Amazon S3 bucket, copy the AMI to another S3 bucket, and then restore it from the S3 bucket.
• By storing and restoring an AMI using S3 buckets, you can copy AMIs from one AWS partition to another( A partition is a group of AWS Regions​​​​​​​),or from one AWS Region to another.
• CopyImage is the recommended API to use for copying AMIs within an AWS partition. However, CopyImage can’t copy an AMI to another partition.
• CreateStoreImageTask：The API creates a task that reads all of the data from the AMI and its snapshots, and then uses an S3 multipart upload to store the data in a single S3 object.
• DescribeStoreImageTasks：describes the progress of the AMI store tasks.
• CreateRestoreImageTask: starts a task that restores an AMI from an S3 object that was previously created by using a CreateStoreImageTask request.
  • The restore task can be performed in the same or a different Region in which the store task was performed.
  • The S3 bucket from which the AMI object will be restored must be in the same Region in which the restore task is requested. 
• Only EBS-backed AMIs can be stored using these APIs.
• Paravirtual (PV) AMIs are not supported.
• The size of an AMI (before compression) that can be stored is limited to the size limit of a single S3 object, which is 1 TB.
• Quota on store image requests: 600 GB of storage work (snapshot data) in progress.
• Quota on restore image requests: 300 GB of restore work (snapshot data) in progress.
• For the duration of the store task, the snapshots must not be deleted and the IAM principal doing the store must have access to the snapshots, otherwise the store process will fail.
• You can’t create multiple copies of an AMI in the same S3 bucket.
• An AMI that is stored in an S3 bucket can’t be restored with its original AMI ID. You can mitigate this by using AMI aliasing.
• Currently the store and restore APIs are only supported by using the AWS Command Line Interface, AWS SDKs, and Amazon EC2 API. You can’t store and restore an AMI using the Amazon EC2 console.
• To use the store and restore APIs, the S3 bucket and the AMI must be in the same Region.

Deregister your Linux AMI

• After you deregister an AMI, you can't use it to launch new instances.
• When you deregister an AMI, it doesn't affect any instances that you've already launched from the AMI.
• When you deregister an Amazon EBS-backed AMI, it doesn't affect the snapshot(s) that were created for the volume(s) of the instance during the AMI creation process.
• Cleaning up your Amazon EBS-backed AMI.

• When you deregister an instance store-backed AMI, it doesn't affect the files that you uploaded to Amazon S3 when you created the AMI.

Automate the EBS-backed AMI lifecycle

• You can use Amazon Data Lifecycle Manager to automate the creation, retention, and deletion of Amazon EBS-backed AMIs and their backing snapshots. 

Use encryption with EBS-backed AMIs

Instance-launching scenarios

• Launch with no encryption parameters
  • An unencrypted snapshot is restored to an unencrypted volume, unless encryption by default is enabled, in which case all the newly created volumes will be encrypted.
  • An encrypted snapshot that you own is restored to a volume that is encrypted to the same KMS key.
  • An encrypted snapshot that you do not own (for example, the AMI is shared with you) is restored to a volume that is encrypted by your AWS account's default KMS key.
• Instance launch behaviors with Encrypted set, but no KmsKeyId specified
  • An unencrypted snapshot is restored to an EBS volume that is encrypted by your AWS account's default KMS key.
  • An encrypted snapshot that you own is restored to an EBS volume encrypted by the same KMS key. (In other words, the Encrypted parameter has no effect.)
  • An encrypted snapshot that you do not own (i.e., the AMI is shared with you) is restored to a volume that is encrypted by your AWS account's default KMS key. (In other words, the Encrypted parameter has no effect.)
• Instance with both Encrypted and KmsKeyId set
  • An unencrypted snapshot is restored to an EBS volume encrypted by the specified KMS key.
  • An encrypted snapshot is restored to an EBS volume encrypted not to the original KMS key, but instead to the specified KMS key.
• Encrypt a volume during launch

• Re-encrypt a volume during launch

• Change encryption state of multiple volumes during launch

Image-copying scenarios

• Copy with no encryption parameters
  • An unencrypted snapshot is copied to another unencrypted snapshot, unless encryption by default is enabled, in which case all the newly created snapshots will be encrypted.
  • An encrypted snapshot that you own is copied to a snapshot encrypted with the same KMS key.
  • An encrypted snapshot that you do not own (that is, the AMI is shared with you) is copied to a snapshot that is encrypted by your AWS account's default KMS key.
• Copy-image behaviors with Encrypted set, but no KmsKeyId specified
  • An unencrypted snapshot is copied to a snapshot encrypted by the AWS account's default KMS key.
  • An encrypted snapshot is copied to a snapshot encrypted by the same KMS key. (In other words, the Encrypted parameter has no effect.)
  • An encrypted snapshot that you do not own (i.e., the AMI is shared with you) is copied to a volume that is encrypted by your AWS account's default KMS key. (In other words, the Encrypted parameter has no effect.)
• Copy-image behaviors with both Encrypted and KmsKeyId set
  • An unencrypted snapshot is copied to a snapshot encrypted by the specified KMS key.
  • An encrypted snapshot is copied to a snapshot encrypted not to the original KMS key, but instead to the specified KMS key.
• Encrypt an unencrypted image during copy
  • You can also copy an image with multiple snapshots and configure the encryption state of each individually.

Amazon Linux

Amazon Linux is provided by Amazon Web Services (AWS). It is designed to provide a stable, secure, and high-performance execution environment for applications running on Amazon EC2. 

• AWS provides Amazon Linux 2 and the Amazon Linux AMI. Amazon Linux 2 is recommended.

Connect to an Amazon Linux instance

Amazon Linux does not allow remote root SSH by default. Also, password authentication is disabled to prevent brute-force password attacks. To enable SSH logins to an Amazon Linux instance:

• you must provide your key pair to the instance at launch.
• You must also set the security group used to launch your instance to allow SSH access.
• By default, the only account that can log in remotely using SSH is ec2-user; this account also has sudo privileges.

Run Amazon Linux 2 as a virtual machine on premises

• Use the Amazon Linux 2 virtual machine (VM) images for on-premises development and testing. These images are available for use on the following virtualization platforms:
  • VMWare
  • KVM
  • VirtualBox (Oracle VM)
  • Microsoft Hyper-V
• To use the Amazon Linux 2 virtual machine images with one of the supported virtualization platforms, do the following:
  • Step 1: Prepare the seed.iso boot image which includes the initial configuration information that is needed to boot your new VM, such as the network configuration, host name, and user data.
  • Step 2: Download the Amazon Linux 2 VM image
  • Step 3: Boot and connect to your new VM

Kernel Live Patching

• Kernel Live Patching for Amazon Linux 2 enables you to apply security vulnerability and critical bug patches to a running Linux kernel, without reboots or disruptions to running applications.
• This allows you to benefit from improved service and application availability, while keeping your infrastructure secure and up to date.
• AWS provides kernel live patches for an Amazon Linux 2 kernel version for up to 3 months after its release. 

Supported configurations and prerequisites

• Kernel Live Patching is supported on Amazon EC2 instances and on-premises virtual machines running Amazon Linux 2.
• To use Kernel Live Patching on Amazon Linux 2, you must use:
  • A 64-bit (x86_64) architecture that is supported by Amazon Linux 2
  • Amazon Linux 2 with kernel version 4.14.165-131.185 or later
• You can enable and use Kernel Live Patching on individual instances using the command line on the instance itself, or you can enable and use Kernel Live Patching on a group of managed instances using AWS Systems Manager.

Limitations

• While applying a kernel live patch, you can't perform hibernation, use advanced debugging tools (such as SystemTap, kprobes, and eBPF-based tools), or access ftrace output files used by the Kernel Live Patching infrastructure.
• Amazon Linux 2 instances with 64-bit ARM (arm64) architecture are not supported.

User provided kernels

• If you need a custom kernel on your Amazon EC2 instances, you can
  • start with an AMI that is close to what you want,
  • compile the custom kernel on your instance,
  • and update the bootloader to point to the new kernel.
• Recommend that you have a fallback when you test a new kernel. GRUB can fall back to another kernel in the event that the new kernel fails. 

Reference

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html 

https://aws.amazon.com/ec2/?ec2-whats-new.sort-by=item.additionalFields.postDateTime&ec2-whats-new.sort-order=desc​​​​​​​

AWS Certified Solutions Architect Official Study Guide - Associate

AWS Certified Solutions Architect Study Guide- Associate 2nd Edition