Amazon Elastic Compute Cloud (Amazon EC2) provides scalable computing capacity in the Amazon Web Services (AWS) Cloud.

Features of EC2

• Virtual computing environments, known as instances
• Preconfigured templates(including operating system and other softwares) for your instances, known as Amazon Machine Images (AMIs)
• Various configurations of CPU, memory, storage, and networking capacity for your instances, known as instance types
• Secure login information for your instances using key pairs
• Storage volumes for temporary data that's deleted when you stop, hibernate, or terminate your instance, known as instance store volumes
• Persistent storage volumes, known as Amazon Elastic Block Store (Amazon EBS) -volumes
• Multiple physical locations for your resources, known as Regions and Availability Zones
• A firewall that enables you to specify the protocols, ports, and source IP ranges that can reach your instances using security groups
• Static IPv4 addresses for dynamic cloud computing, known as Elastic IP addresses
• Metadata, known as tags that you can create and assign to the instance
• Virtual networks you can create that are logically isolated from the rest of the AWS Cloud, known as virtual private clouds (VPCs)

Amazon Machine Image (AMI)

An Amazon Machine Image (AMI) is a template that contains a software configuration (for example, an operating system, an application server, and applications). You can launch an instance from an AMI.

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.
  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.
• A block device mapping that specifies the volumes to attach to the instance when it's launched.

AMIs are regional. You can only launch an instances with an AMI in that region.
All AMIs are categorized as either backed by Amazon EBS, which means that the root device for an instance launched from the AMI is an Amazon EBS volume, or backed by instance store, which 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.

You can deregister an AMI when you have finished using it. After you deregister an AMI, existing instances launched from the AMI are not affected. Therefore, if you are also finished with the instances launched from these AMIs, you should terminate them.

Root device volume

The kind of root device for an instance is determined by the storage volume it uses.
The root device for an instance launched from the AMI is an instance store volume created from a template stored in Amazon S3.
The root device for an instance launched from the AMI is an Amazon EBS volume created from an Amazon EBS snapshot.
The AMI that you specify when you launch your instance determines the type of root device volume that your instance has.
Instances with Amazon EBS volumes for the root device default to stop, and instances with instance-store root devices are always terminated as the result of an instance shutdown.
You can convert an instance store-backed Linux AMI that you own to an Amazon EBS-backed Linux AMI. However, you can't convert an instance store-backed Windows AMI to an Amazon EBS-backed Windows AMI and you cannot convert an AMI that you do not own. Create an instance store-backed Linux AMI

Instance store volumes / Local storage volumes

You can configure instance store volumes at launch time with block device mapping. After these volumes have been added to and mapped on your instance, they are available for you to mount and use.
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.
If your instance fails, or if your instance is stopped or terminated, the data on these volumes is lost, and cannot be restored.
Instance attributes, such as the kernel, RAM disk, user data, and instance type, are fixed for the life of an instance.
Best used for temporary data.
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 Amazon EC2 instance store-backed AMIs, each time you customize an AMI and create a new one, all of the parts are stored in Amazon S3 for each AMI. So, the storage footprint for each customized AMI is the full size of the AMI.

EBS volumes

When an EC2 instance is stopped, the instance performs a normal shutdown. All of the Amazon EBS volumes remain attached.
When an instance is terminated, the instance performs a normal shutdown. The root device volume is deleted by default. You can change the default behavior to ensure that the volume persists after the instance terminates. The instance itself is also deleted. But any attached Amazon EBS volumes are preserved by default.
When an instance is in a stopped state, you can attach or detach Amazon EBS volumes. You can also create an AMI from the instance, and you can change the kernel, RAM disk, user data , and instance type.
Instances launched from an Amazon EBS-backed AMI launch faster than instances launched from an instance store-backed AMI, because only the parts required to boot the instance are 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.
For Amazon EBS-backed AMIs, each time you customize an AMI and create a new one, only the changes are stored. So the storage footprint for subsequent AMIs you customize after the first is much smaller.

Instances

An instance is a virtual server in the cloud.
An instance type essentially determines the hardware of the host computer used for your instance. Each instance type offers different compute and memory capabilities.
You are not charged for additional instance usage while the instance is in a stopped state. However, you're still charged for volume storage.

Instance Types

Instance Purchasing Options

Tenancy: Whether your instance runs on shared (default) or single-tenant (dedicated) hardware.

On-Demand Instances

Pay, by the second, for the instances that you launch.
There is a limit on the number of running On-Demand Instances per AWS account per Region. On-Demand Instance limits are managed in terms of the number of virtual central processing units (vCPUs) that your running On-Demand Instances are using. For example, with a Standard instance limit of 256 vCPUs, you could launch 32 m5.2xlarge instances (32 x 8 vCPUs)

There is a limit to the number of Reserved Instances that you can purchase per month in a region or an availability zone.

On-Demand Capacity Reservations

On-Demand Capacity Reservations enable you to reserve capacity for your Amazon EC2 instances in a specific Availability Zone for any duration. By creating Capacity Reservations, you ensure that you always have access to EC2 capacity when you need it, for as long as you need it.

Capacity Reservations is independent from the billing discounts offered by Savings Plans or regional Reserved Instances. It does not offer you less cost. Billing discounts for Savings Plans and regional Reserved Instances apply to Capacity Reservations. However, billing discounts for zonal Reserved Instances do not apply to Capacity Reservations.

The number of instances for which you are allowed to reserve capacity is based on your account's On-Demand Instance limit.

Capacity Reservations are not transferable from one AWS account to another. However, you can share Capacity Reservations with other AWS accounts.

Capacity Reservations can't be created in placement groups

Capacity Reservations can't be used with Dedicated Hosts

Payment

When the Capacity Reservation is active, you are charged the equivalent On-Demand rate whether you run the instances or not. When you run an instance that matches the attributes of a reservation, you just pay for the instance and nothing for the reservation.

Capacity Reservations are billed at per-second granularity. This means that you are charged for partial hours.

Scheduled Reserved Instances

Scheduled Reserved Instances (Scheduled Instances) enable you to purchase capacity reservations that recur on a daily, weekly, or monthly basis, with a specific start time and duration, for a one-year term. Scheduled Instances are a good choice for workloads that do not run continuously, but do run on a regular schedule.

You pay for the time that the instances are scheduled, even if you do not use them.

Currently AWS cancel the plan of Scheduled Reserved Instances. Instead, you use On-Demand Capacity Reservations to reserve capacity.

Savings Plans

Reduce your Amazon EC2 costs by making a commitment to a consistent amount of usage, in USD per hour, for a term of 1 or 3 years.

Reserved Instances

Reduce your Amazon EC2 costs by making a commitment to a consistent instance configuration, including instance type and Region, for a term of 1 or 3 years.

You cannot exceed your regional running On-Demand Instance limit by purchasing regional Reserved Instances. Indeed, before purchasing regional Reserved Instances, make sure your On-Demand Instance limit matches or exceeds the number of regional Reserved Instances you intend to own. However, you can exceed your running On-Demand Instance limit by purchasing zonal Reserved Instances—a Reserved Instance that is purchased for a specific Availability Zone.

The scope does not affect the price. You pay the same price for a regional or zonal Reserved Instance.

Upfront payment

The payment you make at the start of the reservation term.
You can pay all upfront, partial upfront, or no upfront. You can save more money making a higher upfront payment for Reserved Instances.

Offering class

Offering class determines whether a reserved instance can be exchanged or modified.
Some attributes of both standard reserved instances and convertible reserved instances can be modified.
Standard: These provide the most significant discount, but can only be modified. Standard Reserved Instances can't be exchanged.
Convertible: These provide a lower discount than Standard Reserved Instances, but can be exchanged for another Convertible Reserved Instance with different instance attributes.

Spot Instances

Request unused EC2 instances, which can reduce your Amazon EC2 costs significantly.
The hourly price for a Spot Instance is called a Spot price. The Spot price of each instance type in each Availability Zone is set by Amazon EC2, and is adjusted gradually based on the long-term supply of and demand for Spot Instances.
Your Spot Instance runs whenever capacity is available and the maximum price per hour for your request exceeds the Spot price.

There are scenarios where it can be useful to run Spot Instances in an Amazon EMR cluster.

You can use EC2 console to view the Spot price history for the past three months.

Spot Instance pool

A set of unused EC2 instances with the same instance type, operating system, Availability Zone, and network platform.

Spot Instance Request

You request for a Spot Instance by a spot instance request. The request provides the maximum price per hour that you are willing to pay for a Spot Instance. If you don't specify a maximum price, the default maximum price is the On-Demand price. When the maximum price per hour for your request exceeds the Spot price, Amazon EC2 fulfills your request if capacity is available. A Spot Instance request is either one-time or persistent. Amazon EC2 automatically resubmits a persistent Spot Instance request after the Spot Instance associated with the request is terminated. Your Spot Instance request can optionally specify a duration for the Spot Instances.

Spot Fleet

A set of Spot Instances that is launched based on criteria that you specify.
By default, Spot Fleets are set to maintain target capacity by launching replacement instances after Spot Instances in the fleet are terminated. You can submit a Spot Fleet as a one-time request, which does not persist after the instances have been terminated.

A Spot Fleet allows you to automatically request and manage multiple Spot instances that provide the lowest price per unit of capacity for your cluster or application, like a batch processing job, a Hadoop workflow, or an HPC grid computing job. You can include the instance types that your application can use. You define a target capacity based on your application needs (in units including instances, vCPUs, memory, storage, or network throughput) and update the target capacity after the fleet is launched. Spot fleets enable you to launch and maintain the target capacity, and to automatically request resources to replace any that are disrupted or manually terminated.

Spot Fleet = spot instances + on-demand

Spot Instance interruption

The interruption notice be given when the Spot price exceeds the maximum price for your request or capacity is no longer available. It means your Spot Instance will be terminated, stopped, or hibernated in two minutes.

EC2 instance rebalance recommendation

Amazon EC2 emits an instance rebalance recommendation signal to notify you that a Spot Instance is at an elevated risk of interruption.

Dedicated Hosts

Pay for a physical host whose capacity is fully dedicated to running your instances, and bring your existing per-socket, per-core, or per-VM software licenses to reduce costs.

The instances that run on a Dedicated Host can only be launched in a VPC.
You cannot launch Dedicated Hosts into placement groups.
Up to two On-Demand Dedicated Hosts per instance family, per Region can be allocated.

You pay per second for active Dedicated Host, regardless of the quantity or the size of instances that you choose to launch on it.

You must have active Dedicated Hosts in your account before you can purchase reservations. Each reservation can cover one or more hosts that support the same instance family in a single Availability Zone.

Dedicated Instances

Dedicated Instances are Amazon EC2 instances that run in a virtual private cloud (VPC) on hardware that's dedicated to a single customer.

Each instance that you launch into a VPC has a tenancy attribute. It can be:

• default, which means your instance runs on shared hardware.
• dedicated, which means your instance runs on single-tenant hardware.
• host, which means your instance runs on a Dedicated Host, which is an isolated server with configurations that you can control.
  default cannot be changed to dedicated or host after launched
  dedicated or host cannot be changed to default after launched
  dedicated can be changed to host after launched
  host can be changed to dedicated after launched

Each VPC has a related instance tenancy attribute. It can be:

• default, which means an instance launched into the VPC runs on shared hardware by default unless you specify a different tenancy explicitly.
• dedicated, which means an instance launched into the VPC is a Dedicated Instance by default unless you specify a different tenancy explicitly.
  default cannot be changed to dedicated after created
  dedicated can be changed to default after created

Pay, by the hour, for instances that run on single-tenant hardware.

Capacity Reservations – Reserve capacity for your EC2 instances in a specific Availability Zone for any duration.

Dedicated Instances that belong to different AWS accounts are physically isolated at a hardware level, even if those accounts are linked to a single payer account. However, Dedicated Instances may share hardware with other instances from the same AWS account that are not Dedicated Instances.

When you launch an Amazon EBS-backed Dedicated Instance, the EBS volume doesn't run on single-tenant hardware.

Dedicated Hosts VS Dedicated Instances

There are no performance, security, or physical differences between Dedicated Instances and instances on Dedicated Hosts.

When using dedicated hosts, users pay for the physical server instead of the instance. Each type of dedicated hosts has certain numbers of sockets and physical cores, on which you can run any numbers of different instances up to the core capacity. Indeed, users have additional visibility and control over how instances are placed on a physical server. They can manage sockets, physical cores, and VM software licenses. Also, they can consistently deploy new instances to the same physical server.

Instance Lifecycle

Instance Lifecycle

Instance launch

When you launch an instance, it enters the pending state. AWS use instance type to determine the hardware of the host computer for your instance, and use AMI to boot the operating system and other dependencies of your instance. After the instance is ready for you, it enters the running state.

Launch instances using an EC2 Fleet

An EC2 Fleet contains the configuration information to launch a fleet—or group—of instances. In a single API call, a fleet can launch multiple instance types across multiple Availability Zones, using the On-Demand Instance, Reserved Instance, and Spot Instance purchasing options together.

The EC2 Fleet attempts to launch the number of instances that are required to meet the target capacity specified in your request. If you specified a total maximum price per hour, it fulfills the capacity until it reaches the maximum amount that you’re willing to pay. The fleet can also attempt to maintain its target Spot capacity if your Spot Instances are interrupted.

An EC2 Fleet request can't span AWS Regions. You need to create a separate EC2 Fleet for each Region.
An EC2 Fleet request can't span different subnets from the same Availability Zone.

Instance start and stop (Amazon EBS-backed instances only)

When you stop your instance, it enters the stopping state, and then the stopped state. Any Amazon EBS volumes remain attached to the instance (but not the host computer). AWS don't charge usage or data transfer fees for your instance after you stop it, but they do charge for the storage for any Amazon EBS volumes.

When you start your instance, it enters the pending state, and AWS move the instance to a new host computer (though in some cases, it remains on the current host). You lose any data on the instance store volumes on the previous host computer.

When you start your instance, it retains its private IPv4 or IPv6 address, and any elastic network interface configurations associated with this private IP address. If its old public IP address is not an Elastic IP, it will probably change.

When you stop and start a Windows instance, the EC2Config service performs tasks on the instance, such as changing the drive letters for any attached Amazon EBS volumes.

If your instance is in an Auto Scaling group, the Amazon EC2 Auto Scaling service marks the stopped instance as unhealthy, and may terminate it and launch a replacement instance.

When you stop a ClassicLink instance, it's unlinked from the VPC to which it was linked. You must link the instance to the VPC again after starting it.

By default, when you initiate a shutdown from an Amazon EBS-backed instance (for example, using the shutdown or poweroff command), the instance stops. You can change this behavior so that it terminates instead. Using the halt command from an instance does not initiate a shutdown (the instance does not terminate).

Instance Hibernate (Amazon EBS-backed instances only)

When you hibernate an instance, AWS signal the operating system to perform hibernation (suspend-to-disk). The hibernation freezes all of the processes, saves the contents from the instance memory (RAM) to your Amazon EBS root volume, and then performs a regular shutdown. They persist the instance's Amazon EBS root volume and any attached Amazon EBS data volumes. When you start the instance, the instance boots up and the operating system reads in the contents of the RAM from the EBS root volume, before unfreezing processes to resume its state.

In most cases, the instance is migrated to a new underlying host computer when it's started.

AWS don't charge usage for a hibernated instance when it is in the stopped state, but we do charge while it is in the stopping state. They also charge for the storage for any Amazon EBS volumes, including storage for the RAM data.

Hibernation is only supported by specific EC2 and EBS types, and you can't change the instance type or size of an instance with hibernation enabled.. It is available for On-Demand Instances and Reserved Instances. It is not available for Spot Instances. To use hibernation, the root volume also must be large enough and encrypted to ensure the protection of sensitive content that is in memory at the time of hibernation. You must enable hibernation at launch, you cannot enable hibernation on an existing instance (running or stopped).

If you create a snapshot or AMI from an instance that is hibernated or has hibernation enabled, you might not be able to connect to the instance.

You cannot hibernate an instance that is in an Auto Scaling group or used by Amazon ECS.

AWS do not support keeping an instance hibernated for more than 60 days.

AWS may update upgrades and security patches, which can conflict with existing hibernated instances.

Instance Reboot

Rebooting an instance is equivalent to rebooting an operating system. The instance remains on the same host computer and maintains its public DNS name, private IP address, and any data on its instance store volumes.

Rebooting an instance doesn't start a new instance billing period; per second billing continues without a further one-minute minimum charge.

Instance Retirement

An instance is scheduled to be retired when AWS detects the irreparable failure of the underlying hardware hosting the instance. You will receive an email when AWS schedule your instance for retirement. When you receive the email, your instance may already be unreachable. If luckily your instance is reachable, you need to backup your instance to AMI as soon as possible.

If your instance root device is an Amazon EBS volume, the instance is stopped, and you can start it again at any time to retrieve your data. If your instance root device is an instance store volume, the instance is terminated, and cannot be used again.

Instance Termination

When you've decided that you no longer need an instance, you can terminate it. You can't connect to or recover a terminated instance. After an instance is terminated, resources such as tags and volumes are gradually disassociated from the instance and may no longer be visible on the terminated instance after a short while.

To prevent an instance from being terminated accidentally by someone using the AWS Management Console, the CLI, and the API, you can enable termination protection for the instance. By default, termination protection is disabled for your instance, and it controls the instance attribute DisableApiTermination, which determines whether the instance can be terminated using the console, CLI, or API. You can enable/disable termination protection at instance launch or when the instance is running or stopped. You can't enable termination protection for Spot Instances. The DisableApiTermination attribute also does not prevent Amazon EC2 Auto Scaling from terminating an instance.

Termination for EBS-backed Instance

By default, Amazon EBS root device volumes are automatically deleted when the instance terminates. However, by default, any additional EBS volumes that you attach at launch, or any EBS volumes that you attach to an existing instance persist even after the instance terminates. This behavior is controlled by each volume's DeleteOnTermination attribute, which controls whether the volume is deleted or preserved when you terminate the instance it is attached to. You can change the value of the DeleteOnTermination attribute for a volume when you launch the instance or while the instance is running.

The DeleteOnTermination attribute of a root volume can be set by the creator of an AMI as well as by the person who launches an instance. When the attribute is changed by the creator of an AMI or by the person who launches an instance, the new setting overrides the original AMI default setting.

By default, when you initiate a shutdown from an Amazon EBS-backed instance, the instance stops. You can changes the InstanceInitiatedShutdownBehavior attribute in order to controls whether the instance stops or terminates when you initiate shutdown from within the instance itself. You can modify the setting of this attribute while the instance is running or stopped.

Instance Reboot

You can create an Amazon CloudWatch alarm that monitors an Amazon EC2 instance and automatically recovers the instance if it becomes impaired due to an underlying hardware failure or a problem that requires AWS involvement to repair. A recovered instance is identical to the original instance, including the instance ID, private IP addresses, Elastic IP addresses, and all instance metadata. If the impaired instance is in a placement group, the recovered instance runs in the placement group. If your instance has a public IPv4 address, it retains the public IPv4 address after recovery.

During instance recovery, the instance is migrated during an instance reboot, and any data that is in-memory is lost.

The recover action only supports instances with specific instance types, in a virtual private cloud, backed by only EBS volumes, and Uses default or dedicated instance tenancy.

The automatic recovery process attempts to recover your instance for up to three separate failures per day.

EC2 Storage

Every time you launch an instance from an AMI, a root storage device is created for that instance. The root storage device contains all the information necessary to boot the instance. Y

Block Storage Mapping

When you create a block device mapping, you specify the information for each block device that you need to attach to the instance: The storage device can be instance storage or EBS volume.

f your instance type supports one instance store volume, and your AMI has mappings for two instance store volumes, then the instance launches with one instance store volume.

If you launch an instance with instance store volumes mapped, and then stop the instance and change it to an instance type with fewer instance store volumes and restart it, the instance store volume mappings from the initial launch still show up in the instance metadata. However, only the maximum number of supported instance store volumes for that instance type are available to the instance.

When you modify an EBS volume, you can't decrease its size.

AMI block device mapping

Each AMI has a block device mapping that specifies the block devices to attach to an instance when it is launched from the AMI.

For an EBS-backed AMI, you can add EBS volumes and instance store volumes using a block device mapping. For an instance store-backed AMI, you can add instance store volumes only by modifying the block device mapping entries in the image manifest file when registering the image.

After a block device is attached to an instance, it must be mounted by the operating system before you can access the storage device. When a block device is detached from an instance, it is unmounted by the operating system and you can no longer access the storage device. The instance type determines which instance store volumes are formatted and mounted by default. The block device driver for the instance determines which devices are used when the volumes are formatted and mounted.

Amazon EBS

Amazon EBS provides durable, block-level storage volumes that you can attach to a running instance. EBS volume persists independently from the running life of an instance.

You can use a block device mapping to specify additional EBS volumes when you launch your instance, or you can attach additional EBS volumes after your instance is running.

Multiple volumes can be attached to an instance. You can also detach an EBS volume from one instance and attach it to another instance. You can dynamically change the configuration of a volume attached to an instance.

See more about AWS EBS

Amazon EC2 instance store

Many instances can access storage from disks that are physically attached to the host computer. This disk storage is referred to as instance store.

Instance store provides temporary block-level storage for instances. The data on an instance store volume persists only during the life of the associated instance. The data in an instance store persists for rebooting, but will be lost if you stop, hibernate, or terminate the instance.

If you create an AMI from an instance, the data on its instance store volumes isn't preserved and isn't present on the instance store volumes of the instances that you launch from the AMI.

You can specify the instance store volumes for your instance only when you launch it. You can't attach instance store volumes to an instance after you've launched it.

Amazon EFS file system

Amazon EFS provides scalable file storage for use with Amazon EC2. You can create an EFS file system and configure your instances to mount the file system. You can use an EFS file system as a common data source for workloads and applications running on multiple instances.

See more about AWS EFS

Amazon S3

Amazon EC2 uses Amazon S3 to store EBS snapshots and instance store-backed AMIs.

Every object stored in Amazon S3 is contained in a bucket. Objects stored in the buckets have a unique key value and are retrieved using a URL.

Amazon EC2 also uses Amazon S3 to store snapshots (backup copies) of the data volumes.

EC2-Classic VS EC2-VPC

With EC2-Classic, your instances run in a single, flat network that you share with other customers. The EC2-Classic platform was introduced in the original release of Amazon EC2. Accounts created after 2013-12-04 do not support EC2-Classic, so you must launch your Amazon EC2 instances in a VPC. If your account does not support EC2-Classic, AWS creates a default VPC for you. By default, when you launch an instance, we launch it into your default VPC.

If an AWS account supports only EC2-VPC, any IAM accounts associated with this AWS account also support only EC2-VPC, and use the same default VPC as the AWS account.

Use AMIs in Amazon VPC that are registered within the same region as your VPC.

An EC2 instance launched in a VPC using an Amazon EBS-backed AMI maintains the same IP address when stopped and restarted, which is different from launched an EC2-Classic

You can't use the security groups that you've created for use with EC2-Classic with instances in your VPC. The rules that you create for use with a security group for a VPC can't reference a security group for EC2-Classic, and vice versa.

Elastic IP addresses pool are separated for EC2-Classic and EC2-VPC. You can't associate an Elastic IP address that you allocated for use with a VPC with an instance in EC2-Classic, and vice- versa.

You can migrate some resources from EC2-Classic platform to be used with a VPC. For example, Before migrating an Elastic IP address, you must disconnect all instances from it.

Security Group for EC2-Classic

• After you launch an instance in EC2-Classic, you can't change its security groups. However, you can add rules to or remove rules from a security group
• You can't change the outbound rules for an EC2-Classic security group

Firewall for EC2-Classic

• If you create a custom firewall configuration in EC2-Classic, you must create a rule in your firewall that allows inbound traffic from port 53 (DNS)—with a destination port from the ephemeral range—from the address of the Amazon DNS server; otherwise, internal DNS resolution from your instances fails

VM Import/Export

VM Import/Export enables you to import virtual machine (VM) images from your existing virtualization environment to Amazon Machine Images (AMI) / EC2 instances, and then export them back to your virtualization environment.
VM Import/Export also enables you to import your disks as Amazon EBS snapshots. Then you can attach EBS volumes created from these snapshots to you instances.
When performing import tasks, VM Import/Export stores data of each different task temporarily in a separated intermediate EBS volume.

Advantages

• Enables you to leverage your investments in the VMs that you have built to meet your IT security, configuration management before bringing them into Amazon EC2
• Migrate existing applications and workloads to Amazon EC2
• Import your VM image catalog to Amazon EC2
• Create a disaster recovery repository for VM images

Steps

1. Export your VM / disk using one of the supported formats.
2. Upload the VM image / disk to AWS S3.
3. Start the image / instance / snapshot import task.

Linux AMI virtualization types

Linux Amazon Machine Images use one of two types of virtualization: paravirtual (PV) or 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.

Paravirtual guests traditionally performed better with storage and network operations than HVM guests because they could leverage special drivers for I/O that avoided the overhead of emulating network and disk hardware, whereas HVM guests had to translate these instructions to emulated hardware.

Placement Group

How a group of interdependent instances are spread out across underlying hardware.

There is no charge for creating a placement group.

Cluster Placement Group:

Packs instances close together inside an Availability Zone. This strategy enables workloads to achieve the low-latency network performance necessary for tightly-coupled node-to-node communication that is typical of HPC applications.

Partition Placement Group

Spreads your instances across logical partitions such that groups of instances in one partition do not share the underlying hardware with groups of instances in different partitions. This strategy is typically used by large distributed and replicated workloads, such as Hadoop, Cassandra, and Kafka.
Can have a multi-AZ setup within the same region.

Spread Placement Group:

Strictly places a small group of instances across distinct underlying hardware to reduce correlated failures.