AWS EC2 Guide

1. What is Amazon EC2?

Amazon Elastic Compute Cloud (Amazon EC2) provides on-demand, scalable computing capacity in the Amazon Web Services (AWS) Cloud. Using Amazon EC2 reduces hardware costs so you can develop and deploy applications faster. You can use Amazon EC2 to launch as many or as few virtual servers as you need, configure security and networking, and manage storage. You can add capacity (scale up) to handle compute-heavy tasks, such as monthly or yearly processes, or spikes in website traffic. When usage decreases, you can reduce capacity (scale down) again.

Amazon EC2 was launched on August 25, 2006, which was the third service on AWS.

2. Instances families

Amazon EC2 offers over 500 instance types. You can choose the latest processor, storage, networking, and operating system to help you match the needs of your workload.

An EC2 instance is a virtual machine (VM) that runs in the AWS Cloud. When you launch an instance, you decide the virtual hardware configuration by choosing an instance type. The instance type that you choose determines the hardware of the host computer used for your instance. Each instance type offers different compute, memory, and storage capabilities, and is grouped into an instance family based on these capabilities.

• An instance is a VM.
• An instance type is the combination of virtual hardware components, such as CPU and memory, that make up the instance.
• Instance types are grouped together into instance families. Each instance family is optimized for specific types of use cases.
• Instance families have sub-families, which are grouped according to the combination of processer and storage used.
• A virtual central processing unit (vCPU) is a measure of processing ability. For most instance types, a vCPU represents one thread of the underling physical CPU core. For example, if an instance type has two CPU cores and two threads per core, it will have four vCPUs.

The AWS instances are currently categorized into five distinct families.

1. General purpose instances provide a balance of compute, memory, and networking resources and can be used for a wide range of workloads. These instances are ideal for applications that use these resources in equal proportions, such as web servers and code repositories.

2. Compute optimized instances are ideal for compute-bound applications that benefit from high-performance processors. Instances belonging to this family are well suited for compute-intensive operations, such as the following:

• Batch processing workloads
• Media transcoding
• High performance web servers
• High performance computing (HPC)
• Scientific modeling
• Dedicated gaming servers and ad server engines
• Machine learning (ML) inference

1. Memory optimized instances are designed to deliver fast performance for workloads that process large data sets in memory.

2. Storage optimized instances are designed for workloads that require high, sequential read and write access to very large data sets on local storage. They are optimized to deliver tens of thousands of low-latency, random input/output (I/O) operations per second (IOPS) to applications.

3. Accelerated computing instances use hardware accelerators, or co-processors, to perform some functions more efficiently than is possible in software running on CPUs. Examples of such functions include floating point number calculations, graphics processing, and data pattern matching. Accelerated computing instances facilitate more parallelism for higher throughput on compute-intensive workloads.

Instance names are a combination of the instance family, generation, and size. They can also indicate additional capabilities, such as specific processor type or optimized networking performance.

1. The letter in the first position represents the instance family. In many cases you can remember this by what the letter represents. M is a general purpose instance sub-family. M can be remembered as the instance to use for Main, Many, Most, and so on, purposes. There are a variety of mnemonics used to remember the instance families, and any browser search will give you a variety to choose from.
2. This number represents the generation of the processor, with higher numbers being the newest generation. Older generations are supported for applications that have been optimized on one particular generation. However, it is a best practice to update your instances as new ones are released. The newest generation often provides a performance improvement, a cost saving, or both. Higher numbers in this field represent newer generations.
3. Not all instances have an attribute option. This attribute provides additional information about the instance capabilities. In the case of the m5z instance, the z indicates high frequency and tells us that this instance is ideal for high single-thread performance.
4. Not all instance have an additional attribute that details what the instance is optimized to do. In the case of the m5zn, we've learned that m is the instance family, 5 is the generation of the processor, z means it's optimized for high performance, and now the n stands for network and indicates that this instance is optimized for high throughput and low network latency. Combined with the z attribute for high compute, this instance is a high performance instance for workloads such as gaming, modeling, and HPC.
5. This represents the size of the instance. The larger the size, the more resources, such as CPU and memory. Sizes are based on the combination of hardware resources used for this instance.

Check these out AWS Instance types and Vantage's instance tool.

3. Amazon Machine Image (AMI)

An Amazon Machine Image (AMI) is a template that contains the software configuration—for example, an operating system (OS), applications, or tools. You use the AMI and the information contained within it to launch an instance. You must specify an AMI when you launch an instance because it contains all the necessary information and files required to build and launch the instance. If you don't specify an AMI, you cannot launch an instance.

Because the AMI is a configuration template, you can use a single AMI to launch multiple instances. Or you can choose to launch a variety of different instances using different AMIs that contain unique configuration options.

• For storage, when you use an Amazon EBS–backed volume, the AMI contains one or more Amazon EBS snapshots. When you use an instance store-backed AMI, the AMI contains a template for the root volume of the instance (for example, an operating system, an application server, and applications).
• The AMI contains the launch permissions that control which AWS accounts can use the AMI to launch instances.
• The AMI contains the block device mapping that specifies any additional EBS volumes to attach to the instance when it's launched.

An EC2 instance is made up of the host's physical hardware components (storage, networking, compute), a hypervisor (software that hides hardware resources from the application OS), and the configuration information from the AMI.

A hypervisor is a piece of virtualization software that allocates resources and manages physical hardware in a virtualized environment. The hypervisor allows multiple operating systems to run on a single physical server.

AWS has two types of hypervisors: the original hypervisor and the newer Nitro Hypervisor that was launched as part of the AWS Nitro System.

The AWS Nitro System is a combination of dedicated hardware and a lightweight hypervisor, for faster innovation and enhanced security. This course doesn't cover the AWS Nitro System hardware in depth. But if you want to learn more, you can read all about it on the AWS Nitro System documentation page.

When Amazon EC2 originally launched, up to 30% of the host's compute resources were allocated to the hypervisor for managing the hardware. This left only 70% of the resources for the remaining hypervisor functions and the customer instances.

Traditionally, a hypervisor's job is to protect the physical hardware and BIOS; virtualize the CPU, storage, and networking; and provide a rich set of management capabilities. With the Nitro System, these functions are separated and offloaded to dedicated hardware and software. Doing this reduces costs and increases performance by delivering practically all of the server resources to your instances.

The following image illustrates how the AWS Nitro System splits the management resources from the hardware resources.

By offloading all hardware, management, and security operations to a dedicated card, the hypervisor no longer has to carve out a portion of compute resources to handle this I/O.

4. Tenancy

A tenant is the most fundamental concept in the cloud. A tenant is an entity that occupies space, whether that space is a rented apartment in a building you own, or if that rented space is an instance occupying resources on AWS infrastructure. With Amazon EC2, tenancy defines how the EC2 instances are distributed across the physical hardware. Tenancy choices also have an effect on pricing.

These are the three available tenancy options:

• Shared (default) – Multiple AWS accounts can share the same physical hardware. Shared tenancy means that when you launch your instance, the instance is created on an AWS server that you share with many other different AWS customer accounts. Your instance is isolated and secured from the other user's instances but you are all sharing the same underlying hardware.

The image shows one single physical host with several allocated instance slots. Each unique color represents a single AWS customer. Shared tenancy allows multiple customer's instances to run on shared physical hardware. The gray instances are unused capacity.

Shared tenancy is the most economical choice and can support Spot Instances and burstable instance types. Shared tenancy doesn’t support instances that use the Bring Your Own License (BYOL) model.

• Dedicated Instance (dedicated) – Your instance runs on single-tenant hardware. Dedicated Instances are Amazon EC2 instances that run on hardware that's dedicated to a single customer. Dedicated Instances can share hardware with other instances from the same AWS account that are not Dedicated Instances, as illustrated in the following image. For example, you have two Dedicated instances that need to run on hardware allocated to your account. You then launch two additional regular instances that could be run on any hardware. But because you have hardware dedicated to your account, you can place these two additional regular instances on that dedicated instance hardware.

Dedicated Instances and Dedicated Hosts can both be used to launch EC2 instances onto physical servers that are dedicated for your use. An important difference between a Dedicated Host and a Dedicated Instance is that a Dedicated Host gives you additional visibility and control over how instances are placed on a physical server. And you have greater visibility into the hardware that the instance is running on.

With a Dedicated Instance, only instances owned by you can run on the hardware, but you have no visibility into the underlying hardware nor control of instance placement.

Dedicated Instance pricing has two components: an hourly per-instance usage fee and a dedicated per-Region fee. (Note that you pay this once per hour regardless of how many Dedicated Instances you're running).

• Dedicated Host (host) – Your instance runs on a physical server with EC2 instance capacity fully dedicated to your use. This is an isolated physical server with configurations that you can control.

For compliance, security, or licensing reasons, some organizations must run their instances on dedicated servers. With Dedicated Hosts, you rent a physical server that is solely dedicated to your instances.

Dedicated Hosts provide visibility and the option to control how you place the instances on your physical server. This facilitates instance deployment using specific location configurations that address corporate compliance and regulatory requirements.

Dedicated Hosts also give you control and visibility into the underlying hardware of the host. By using Dedicated Hosts you can use the BYOL model. There is no additional charge for software usage if you choose to bring your own licenses.

The following table highlights some of the key differences between Dedicated Instances and Dedicated Hosts.

5.Instance states

A physical computer goes through a variety of phases (or states) during both the power-on cycle and then afterward when the machine is powered-on but in a different state, such as sleeping or hibernating. Let's compare a Windows Server to an EC2 instance to see how the different run states compare

A Windows EC2 instance is similar to the traditional Windows Server in that it also has a variety of states that it maneuvers through.

After you launch an instance, it briefly goes into the pending state while registration takes place; then it goes into the running state. The instance remains active until you stop or terminate it. You can't restart an instance after you terminate it. You can create a backup image of your instance while it's running, and launch a new instance from that backup image.

6. Working with AMIs

• AMIs are a Regional resource. When you search for a shared AMI (public or private), you must search for it from the same Region from which it is shared. To make an AMI available in a different Region, copy the AMI to the Region and then share it.
• If your AMI includes one of the following components, you can't make it public (but you can share the AMI with specific AWS accounts): Encrypted volumes, Snapshots of encrypted volumes, Product codes
• Avoid exposing sensitive data. To avoid exposing sensitive data when you share an AMI, read the security considerations in Guidelines for shared Linux AMIs and follow the recommended actions.
• By default, the deprecation date of all public AMIs is set to two years from the AMI creation date automatically. You can choose to set the deprecation date to be sooner than two years. To cancel the deprecation date, or to move the deprecation to a later date, you must make the AMI private by only sharing it with specific AWS accounts
• You are not billed when your AMI is used by other AWS accounts to launch instances. The accounts that launch instances using the AMI are billed for the instances that they launch.

A paid AMI is an AMI that you can purchase from a developer on the AWS Marketplace. The AWS Marketplace is an online store where you can buy software that runs on AWS, including AMIs that you can use to launch your EC2 instance. The AWS Marketplace AMIs are organized into categories, such as Developer Tools, to help you to find products to suit your requirements. To learn more, visit Paid AMIs in the Amazon Elastic Compute Cloud User Guide.

EC2 Image Builder simplifies the building, testing, and deployment of virtual machine and container images for use on AWS or on premises. It can significantly reduce the effort of keeping images up-to-date and secure by providing a simple graphical interface, built-in automation, and AWS-provided security settings. With Image Builder, there are no manual steps for updating an image nor do you have to build your own automation pipeline. When software updates become available, Image Builder automatically produces a new image without requiring users to manually initiate image builds. To learn more, visit EC2 Image Builder. Image Builder is offered at no cost, integrates with AWS Organizations, and can share AMIs across accounts based on your existing AMI sharing mechanisms.

Considerations for sharing AMIs internally
There are some considerations that you should review before sharing AMIs with other, specific AWS accounts. To learn more, expand each of the following six categories.

• There is no limit to the number of AWS accounts with which an AMI can be shared.
• Usage—When you share an AMI, users can only launch instances from the AMI. They can’t delete, share, or modify it. However, after they have launched an instance using your AMI, they can then create an AMI from their instance. Copying shared AMIs—If users in another account want to copy a shared AMI, you must grant them read permissions for the storage that backs the AMI.
• When you tag public or shared resources, the tags you assign are available only to your AWS account; no other AWS account will have access to those tags. For tag-based access control to shared resources, each AWS account must assign its own set of tags to control access to the resource.
• You can share AMIs that are backed by unencrypted and encrypted snapshots. The encrypted snapshots must be encrypted with a customer managed key. You can’t share AMIs that are backed by snapshots that are encrypted with the default AWS managed key. If you share an AMI that is backed by encrypted snapshots, you must allow the AWS accounts to use the customer managed keys that were used to encrypt the snapshots.
• AMIs are a regional resource. When you share an AMI, it is only available in that Region. To make an AMI available in a different Region, copy the AMI to the Region and then share it.
• You are not billed when your AMI is used by other AWS accounts to launch instances. The accounts that launch instances using the AMI are billed for the instances that they launch.

Instance store-backed instances

Instances that use instance stores for the root device automatically have one or more instance store volumes available, with one volume serving as the root device volume. When an instance is launched, the image that is used to boot the instance is copied to the root volume. Note that you can optionally use additional instance store volumes, depending on the instance type.
Any data on the instance store volumes persists as long as the instance is running, but this data is deleted when the instance is terminated (instance store-backed instances do not support the Stop action) or if it fails (such as if an underlying drive has issues).
After an instance store-backed instance fails or terminates, it cannot be restored. If you plan to use Amazon EC2 instance store-backed instances, we highly recommend that you distribute the data on your instance stores across multiple Availability Zones. You should also back up critical data from your instance store volumes to persistent storage on a regular basis.

Amazon EBS-backed instances

Instances that use Amazon EBS for the root device automatically have an Amazon EBS volume attached. When you launch an Amazon EBS-backed instance, an Amazon EBS volume is created for each Amazon EBS snapshot referenced by the AMI you use. You can optionally use other Amazon EBS volumes or instance store volumes, depending on the instance type.

An Amazon EBS-backed instance can be stopped and later restarted without affecting data stored in the attached volumes. There are various instance and volume-related tasks you can do when an Amazon EBS-backed instance is in a stopped state. For example, you can modify the properties of the instance, change its size, or update the kernel it is using. You can attach your root volume to a different running instance for debugging or any other purpose.

Instances launched from an Amazon EBS-backed AMI launch faster than instances launched from an instance store-backed AMI. When you launch an instance from an instance store-backed AMI, all the parts have to be retrieved from Amazon S3 before the instance is available. With an Amazon EBS-backed AMI, only the parts required to boot the instance need to be retrieved from the snapshot before the instance is available. However, the performance of an instance that uses an EBS volume for its root device is slower for a short time while the remaining parts are retrieved from the snapshot and loaded into the volume. When you stop and restart the instance, it launches quickly, because the state is stored in an EBS volume.

6. Networking

Use cases for elastic network interfaces

• Failover – You can manually detach the elastic network interface from a failed or down instance and then attach the interface to a new instance. When you do this, the interface keeps its original IP address and traffic automatically routes to the new instance.
• *Management *– When using multiple elastic network interfaces configured on one instance, you can dedicate one interface for administrative traffic and the other for the workload or business traffic. When isolating the management traffic, the second interface can focus on only managing the workload. Security groups use each interface to isolate the traffic based on port, protocol, or IP address.

When your instance starts, it is auto-assigned a public IP address for users on the internet to connect. When the instance is stopped, the auto-assigned IP address is released back to the public IP address pool. When the instance is restarted, a new unique IP address is reassigned.

Public IP address assignment in the default VPC and in a nondefault VPC work differently. When you launch an instance in a default VPC, a public IP address is assigned automatically. When you launch an instance into a nondefault VPC, it checks an attribute in the subnet that determines whether instances launched into that subnet can receive a public IP address from the public IPv4 address pool. By default, instances launched in a nondefault subnet are not assigned a public IP address.

All of the public IP addresses are assigned from a pool of public IPv4 addresses at Amazon. This public address is not associated with your AWS account. When a public IP address is disassociated from your instance, it is released back into the public IPv4 address pool, and you cannot reuse it. You cannot manually associate or disassociate a public IP (IPv4) address from your instance. Instead, in certain cases, the public IP address from your instance is released or a new IP address is assigned.

Elastic IP addresss

An Elastic IP address is a static public IPv4 address associated with your AWS account in a specific Region. Unlike an auto-assigned public IP address, an Elastic IP address is preserved after you stop and start your instance in a VPC.

Keep the following points in mind when working with static IP addresses:

• If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.
• You can't retain or reserve the current public IP address assigned to the instance using auto-assigned public IP address.
• You cannot convert an auto-assigned public IP address to an Elastic IP address.
• There is a default limit of five Elastic IP addresses per Region per AWS account.
• You are charged a small fee for any Elastic IP address that is not associated to a running instance.

An Elastic IP address remains associated with your AWS account until you release it, and you can move it from one instance to another as needed. You can bring your own IP address range to your AWS account, where it appears as an address pool, and then allocate Elastic IP addresses from your address pool.

*Bring your own IP addresses (BYOIP) in Amazon EC2 *

You can bring part or all of your publicly routable IPv4 or IPv6 address range from your on-premises network to your AWS account. You continue to control the address range, but by default, AWS advertises it on the internet. After you bring the address range to AWS, it appears in your AWS account as an address pool.

To learn more details about the requirements and limitations of bringing your own IP addresses, see Bring your own IP addresses (BYOIP) in Amazon EC2.

IPv6 address

You can optionally associate an IPv6 CIDR block with your VPC and associate IPv6 CIDR blocks with your subnets. The IPv6 CIDR block for your VPC is automatically assigned from the pool of IPv6 addresses at Amazon; you cannot choose the range yourself. At this time, you cannot remove the default IPv4 address and user only native IPv6.