Part 4 - AWS - Amazon Machine Images

Amazon Machine Images

·        A template for server

o   Amazon provides many AMIs

o   Many others provided by third parties

o   Can also create your own

·        A template to create a running instance

o   Basically a virtual machine snapshot

o   Contains at least a core operating system

o   Some may contain pre-installed tools and software

·        Available for many operating systems

o   Windows

o   Various flavors of Linux

·        Wide range of installed software

o   Database servers

o   Web servers

o   Frameworks

o   Etc.

An Amazon Machine Image (AMI) provides the information required to launch 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.

·        A template for the root volume for 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. 

Selecting an AMI

Selecting an AMI can be often be challenging and confusing

·        Hard to determine exactly what is on the AMI -  can try to Google the AMI ID

·        Some third party provider offer descriptions of images on their websites

o   For example, BitNami, JumpBox.

Best to start from AMIs provided by reliable parties

o   Amazon is usually a safe bet

o   Now always easy to determine who is the owner

§  All images are assigned on owner ID, which is the AWS account number.

§  Can sometimes infer owner from the Source field.

Only one sure way to know what is on an image

o   Start an instance and perform an inventory

Find an image with the core components you need

·        Can customize for specific requirement after launch

·        New AMI can then be created from the instance

Amazon Machine Images - Exam Tip

AMI's are regional. You can only launch an AMI from the region in which it is stored. However you can copy AMI's to other regions using the console, command line or the Amazon EC2 API.

You can select your AMI based on;

·       Region (See Regions and Availability Zones)

·        Operating system

·        Architecture (32-bit or 64-bit)

·        Launch Permissions

·        Storage for the Root Device (Root Device Volume)

o   Instance Store (EPHEMERAL STORAGE) (Less Durability than EBS Backed Volume)

o   EBS Backed Volumes

Instance Store (or S3-backed)(Ephemeral Storage)

·        An Instance store backed instance is an EC2 instance using an Instance store as root device volume created from a template stored in Amazon S3.

a.     I/O Operation to root device are free.

·        Instance store volumes accesses storage from disks that are physically attached to the host computer.

·        When an Instance stored instance is launched, the image that is used to boot the instance is copied to the root volume (typically sda1).

·        Instance store provides temporary block-level storage for instances.

·        Data on an instance store volume persists only during the life of the associated instance; if an instance is stopped or terminated, any data on instance store volumes is lost.

Key points for Instance store backed Instance

1.     Boot time is slower than EBS backed volumes and usually less than 5 min

2.     Can be selected as Root Volume and attached as additional volumes

3.     Instance store backed Instances can be of maximum 10GiB volume size

4.     Instance store volume can be attached as additional volumes only when is the Instance is being launched and cannot be attached once the Instance is up and running

5.     Instance store backed Instances cannot be stopped as one of the main reason being when stopped and started AWS does not guarantee the Instance would be launched in the same host.

6.     Data on Instance store volume is LOST in following scenarios :-

a.     Failure of an underlying drive

b.     Stopping an EBS-backed instance where instance store are additional volumes

c.      Termination of the Instance

7.     Data on Instance store volume is NOT LOST when the instance is rebooted

8.     AMI creation requires usage on AMI tools and needs to be executed from within the server

9.     Instance store backed Instances cannot be upgraded

Amazon Elastic Block Store (EBS)

·        An “EBS-backed” instance means that the root device for an instance launched from the AMI is an Amazon EBS volume created from an Amazon EBS snapshot

o   I/O operation to EBS are not Free.

·        An EBS volume behaves like a raw, unformatted, external block device that you can attach to a single instance and are not physically attached to the Instance host computer (more like a network attached storage).

·        Volume persists independently from the running life of an instance. After an EBS volume is attached to an instance, you can use it like any other physical hard drive.

·        EBS volume can be detached from one instance and attach it to another instance.

·        EBS volumes can be created as encrypted volumes using the Amazon EBS encryption feature.

Key points for EBS backed Instance

1.     Boot time is very fast usually less than a min

2.     Can be selected as Root Volume and attached as additional volumes

3.     EBS backed Instances can be of maximum 16TiB volume size depending upon the OS

4.     EBS volume can be attached as additional volumes when the Instance is launched and even when the Instance is up and running

5.     Data on the EBS volume is LOST only if the Root Volume is EBS backed and the Delete On Termination flag is disabled (enabled by default)

6.     Data on EBS volume is NOT LOST in following scenarios :-

a.     Reboot on the Instance

b.     Stopping an EBS-backed instance

c.      Termination of the Instance for the additional EBS volumes. Additional EBS volumes are detached with their data intact

7.     When EBS-backed instance is in a stopped state, various instance– and volume-related tasks can be done for e.g. you can modify the properties of the instance, you can change the size of your instance or update the kernel it is using, or you can attach your root volume to a different running instance for debugging or any other purpose

8.     EBS volumes are tied to a single AZ  in which they are created

9.     EBS volumes are automatically replicated within that zone to prevent data loss due to failure of any single hardware component

10.  AMI creation is easy using a Single command

11.  EBS backed Instances can be upgraded for instance type, Kernel, RAM disk and user data

EBS vs Instance Store

All AMIs are categorized as either backed by Amazon EBS or backed by instance store.

 For EBS Volumes: The root devices for an instance launched from the AMI is an Amazon EBS Volume created from an Amazon EBS Snapshot.

For Instance Store Volumes: The root device for an instance launched from the AMI is an instance stored volume created from a template stored in Amazon S3.

Note: Your instance will be launched with the following storage device settings. You can attach additional instance store volumes to your instance. You can also attach additional EBS volumes after launching an instance, but not instance store volumes. Learn more about storage options in Amazon EC2

Copying an AMI

You can copy an Amazon Machine Image (AMI) within or across an AWS region using the AWS Management Console, the command line, or the Amazon EC2 API, all of which support the CopyImage action. Both Amazon EBS-backed AMIs and instance store-backed AMIs can be copied.

Copying a source AMI results in an identical but distinct target AMI with its own unique identifier. In the case of an Amazon EBS-backed AMI, each of its backing snapshots is, by default, copied to an identical but distinct target snapshot. (The one exception is when you choose to encrypt the snapshot, as described below.) The source AMI can be changed or deregistered with no effect on the target AMI. The reverse is also true.

There are no charges for copying an AMI. However, standard storage and data transfer rates apply.

AWS does not copy launch permissions, user-defined tags, or Amazon S3 bucket permissions from the source AMI to the new AMI. After the copy operation is complete, you can apply launch permissions, user-defined tags, and Amazon S3 bucket permissions to the new AMI.

EBS vs Instance Store - Exam Tips

·       Instance Store Volumes are sometimes called Ephemeral Storage. (Less Durability, If an host get any issue on Instance store, you lost your EC2 instance)

·        Instance store volumes cannot be stopped. If the underlying host fails, you will lose your data. (Only restart or terminate)

·        EBS backed instances can be stopped. You will not lose the data on this instance if it is stopped. (Example, if you Hypervisor got some issue, then EBS backed volume will get migrated to another Hypervisor, however in case of instance store Volume it will not)

·        You can reboot both, you will not lose your data.

·        By Default, both ROOT volumes will be deleted on termination, however with EBS volumes, you can tell AWS to keep the root device volume.

·        For EBS Backed Volume, the Root disk could be detached and attached to some other EC2 instances, however this is not the case in Instance Store Volumes.

EC2 – EBS Backed vs Instance Store

·        EBS backed volumes are persistent.

·        Instance Store backed volumes are not persistent (ephemeral)

·        EBS Volumes can be detached and reattached to other EC2 instances

·        Instance store volume cannot be detached and reattached to other instances. They exist only for the life of that instance.

·        EBS volumes can be stopped, data will persist.

·        Instance store volumes cannot be stopped. If you do this the data will be wiped.

·        EBS Backed = Stored Data Long Term

·        Instance Store = Shouldn’t be used for long-term data storage.

Which Is Better: Instance Store or EBS AMIs?

·        EBS AMIs are generally easier to use

o   Easier to create new AMIs from instance

o   Easier to back up

o   Can increase the size of the root device

o   Can change the instance type

·        EBS volumes have better latency and throughput than instance stores

·        Instance store AMIs potentially cost less to run

o   Do not pay for EBS storage

o   But you also cannot stop them

·        EBS AMIs are preferred today