Amazon EC2

Home » AWS Certification Cheat Sheets » AWS Certified SysOps Administrator Associate Cheat Sheets » Amazon EC2


Amazon Elastic Compute Cloud (Amazon EC2) is a service you can use to deploy virtual servers known as “instances” on the AWS Cloud.

Amazon EC2 provides the following features:

  • Virtual computing environments, known as instances.
  • Preconfigured templates for your instances, known as Amazon Machine Images (AMIs), that package the bits you need for your server (including the operating system and additional software).
  • 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 (see below).
  • Storage volumes for temporary data that’s deleted when you stop or terminate your instance, known as instance store volumes (ephemeral / non-persistent data).
  • Persistent storage volumes for your data using Amazon Elastic Block Store (Amazon EBS), known as Amazon EBS volumes.
  • Multiple physical locations for your resources, such as instances and Amazon EBS volumes, 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 your Amazon EC2 resources.

Amazon EC2 Instances

An instance is a virtual server in the cloud. Its configuration at launch is a copy of the AMI that you specified when you launched the instance.

You can launch different types of instances from a single AMI.

An instance type essentially determines the hardware of the host computer used for your instance.

Each instance type offers different compute, memory, and storage capabilities.

Select an instance type based on the amount of memory and computing power that you need for the application or software that you plan to run on the instance.

There are many different families and types of instance available with varying combinations of CPU, memory, storage, and networking capacity.

The following tables shows some examples of the categories and families available:

Amazon EC2 Instance Types

Burstable instances:

  • T3, T3a, and T2 instances, are designed to provide a baseline level of CPU performance with the ability to burst to a higher level when required.
  • Burstable performance instances are the only instance types that use credits for CPU usage.
  • A CPU credit provides for 100% utilization of a full CPU core for one minute.
  • Each burstable performance instance continuously earns (at a millisecond-level resolution) a set rate of CPU credits per hour, depending on the instance size.

T2/T3 unlimited instances:

  • T2/T3 instances are a low-cost, general purpose instance type that provides a baseline level of CPU performance with the ability to burst above the baseline when needed.
  • T2/T3 Unlimited instances can sustain high CPU performance for as long as a workload needs it.
  • The baseline performance and ability to burst are governed by CPU Credits.
  • T2/T3 instances accumulate CPU Credits when they are idle, and consume CPU Credits when they are active.

Amazon EC2 instances can be placed in an Amazon EC2 placement group.

Amazon EC2 instances can be managed through AWS Systems Manager.

You can also use AWS OpsWorks to manage your instances using Chef and Puppet.

AWS Config can be used to record configuration items about Amazon EC2 instances and track changes.

Amazon Machine Images (AMIs)

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

From an AMI, you launch an instance, which is a copy of the AMI running as a virtual server in the cloud. You can launch multiple instances of an AMI.

An Amazon Machine Image (AMI) provides the information required to launch an instance.

You must specify an AMI when you launch an instance.

You can launch multiple instances from a single AMI when you need multiple instances with the same configuration.

You can use different AMIs to launch instances when you need instances with different configurations.

AMIs are specific to a region (you must select the AMI within each region separately).

An AMI includes the following:

  • One or more 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.

You can create your own custom AMIs (also known as golden images) which can included pre-installed software and configuration settings.

AMIs can be public or private.

AMIs are private by default.

Public AMIs that are shared by others can be found on the Amazon Marketplace.

Public AMIs may come at an increased hourly cost, and:

  • May contain preconfigured software (and can include licensing).
  • Can be configured for you so you can get started quickly.

AMIs are stored on Amazon S3 however you cannot see them in the S3 console.

You get charged at S3 rates for the quantity of data stored in the AMI.

Sharing an AMI across accounts

You can share an AMI with specific AWS accounts without making the AMI public.

All you need is the AWS account IDs.

You can only share AMIs that have unencrypted volumes and volumes that are encrypted with a customer managed CMK.

You cannot share an AMI that has volumes that are encrypted with an AWS managed CMK.

If you share an AMI with encrypted volumes, you must also share any CMKs used to encrypt them.

You cannot copy an AMI with an associated billingProduct code that was shared with you from another AWS account. To get around this, launch an instance from the AMI, and then create an AMI from the instance.

Deployment and Provisioning

Amazon EC2 instances can be launched from within the EC2 management console.

You can also launch instances using the RunInstances API.

You can change instance types for EBS backed instances only.

To change the instance type you must stop the instance, change the instance type, and then start it up again.

When you stop and start and EC2 instance, it will generally be moved to different underlying hardware.

Exam tip: You can stop and start an EC2 instance to move it to a different physical host if EC2 status checks are failing or there is planned maintenance on the current physical host.

You can stop and start your instance if it has an Amazon EBS volume as its root device.

When you stop a running instance, the following happens:

  • The instance performs a normal shutdown and stops running; its status changes to stopping and then stopped.
  • Any Amazon EBS volumes remain attached to the instance, and their data persists.
  • Any data stored in the RAM of the host computer or the instance store volumes of the host computer is gone.
  • In most cases, the instance is migrated to a new underlying host computer when it’s started.
  • The instance retains its private IPv4 addresses and any IPv6 addresses when stopped and started (public addresses are released).
  • The instance retains its associated Elastic IP addresses (you’re charged for any Elastic IP addresses associated with a stopped instance).

You can modify the following attributes of an instance only when it is stopped:

  • Instance type.
  • User data.
  • Kernel.
  • RAM disk.

You can change the instance initiated shutdown behavior so it terminates rather than stops the instance.

Configure by modifying the InstanceInitiatedShutdownBehavior.

Termination protection protects against accidental deletion.

The DisableApiTermination attribute controls whether the instance can be terminated using the console, CLI, or API.

Use Amazon Elastic File System (EFS) for mounting a shared filesystem to multiple EC2 instances.

Connecting to your Amazon EC2 instance

Key pairs are used to securely connect to Amazon EC2 instances:

  • A key pair consists of a public key that AWS stores, and a private key file that you store.
  • For Windows AMIs, the private key file is required to obtain the password used to log into your instance.
  • For Linux AMIs, the private key file allows you to securely SSH (secure shell) into your instance.

Common errors:

  • Error “Unprotected private key file”. Private key files must have the permissions set to 400 (use CHMOD on Linux).
  • Error “Host key not found”. User name must be supplied correctly when logging in.

Connection timeout issues:

  • Security group may not be configured correctly (allow TCP port 22 inbound from your computer/network or
  • The CPU load on the EC2 instance could be high preventing the connection completing.

EC2 Launch Issues

InstanceLimitExceeded error – the maximum number of instances in the region has been reached.

Increase your limit or launch in another region.

Limits are based on the instance type and number of vCPUs. See the user guide for more info.

InsufficientInstanceCapacity error – AWS does not have enough on-demand capacity to service the request in the specific Availability Zone.

Resolution options:

  • Wait a few minutes and try again.
  • Try a different instance type.
  • Try launching a smaller number at a time.
  • Try purchasing reserved instances instead.
  • Submit a new request without specifying the Availability Zone.

Instance terminates immediately (goes from pending to terminated ).

This is caused by one of the following:

  • The limit for EBS volumes has been reached.
  • An EBS snapshot is corrupt.
  • The root EBS volume is encrypted and you don’t have permission to access the KMS key to decrypt the data.
  • The instance-store backed AMI that was used to launch the instance is missing a required part.

The EC2 console reports the exact reason in the State Transition Reason description.

IP Addresses

There are three types of IP address that can be assigned to an Amazon EC2 instance

  • Public – public address that is assigned automatically to instances in public subnets and reassigned if instance is stopped/started.
  • Private – private address assigned automatically to all instances.
  • Elastic IP – public address that is static.

Public IPv4 addresses are lost when the instance is stopped but private addresses (IPv4 and IPv6) are retained.

Public IPv4 addresses are retained if you restart the instance.

Elastic IPs are retained when the instance is stopped.

Elastic IP addresses are static public IP addresses that can be remapped (moved) between instances.

All accounts are limited to 5 elastic IP’s per region by default.

AWS charge for elastic IP’s when they’re not being used.

Elastic IP address can mask the failure of an instance by remapping the address to another instance.

Metadata and User Data

User data is data that is supplied by the user at instance launch in the form of a script.

Instance metadata is data about your instance that you can use to configure or manage the running instance.

User data is limited to 16KB.

User data and metadata are not encrypted.

Instance metadata is available at (the trailing “/” is required).

Instance user data is available at:

The IP address is a link-local address and is valid only from the instance.

On Linux you can use the curl command to view metadata and userdata, e.g.

The Instance Metadata Query tool allows you to query the instance metadata without having to type out the full URI or category names.

High Availability

High availability for Amazon EC2 instances is achieved by using Amazon EC2 Auto Scaling with Amazon Elastic Load Balancing – please check the relevant cheat sheets below for more information:

Fault tolerance can be achieved by using RAID 1 with your Amazon EBS volumes – please check the relevant cheat sheet here for more information.

Monitoring and Reporting

Amazon EC2 sends metrics to Amazon CloudWatch and you can use the AWS Management Console, the AWS CLI, or an API to list the metrics that Amazon EC2 sends to CloudWatch.

CloudWatch stores data about a metric as a series of data points. Each data point has an associated time stamp. You can even publish an aggregated set of data points called a statistic set.

By default, each data point covers the 5 minutes that follow the start time of activity for the instance.

If you’ve enabled detailed monitoring (chargeable), each data point covers the next minute of activity from the start time.

You can find the list of standard metrics sent from Amazon EC2 to Amazon CloudWatch at the following link:

Custom metrics:

  • You can publish your own metrics to CloudWatch using the AWS CLI or an API.
  • You can view statistical graphs of your published metrics with the AWS Management Console.
  • Can be used to gather system-level metrics including memory and disk utilization.

Each custom metric is one of the following:

  • Standard resolution, with data having a one-minute granularity.
  • High resolution, with data at a granularity of one second.

Unified CloudWatch Agent

The unified CloudWatch agent enables you to do the following:

  • Collect more system-level metrics from Amazon EC2 instances across operating systems. The metrics can include in-guest metrics, in addition to the metrics for EC2 instances. The additional metrics that can be collected are listed in Metrics Collected by the CloudWatch Agent.
  • Collect system-level metrics from on-premises servers. These can include servers in a hybrid environment as well as servers not managed by AWS.
  • Retrieve custom metrics from your applications or services using the StatsD and collectd protocols. StatsD is supported on both Linux servers and servers running Windows Server. collectd is supported only on Linux servers.
  • Collect logs from Amazon EC2 instances and on-premises servers, running either Linux or Windows Server.

You can download and install the CloudWatch agent manually using the command line, or you can integrate it with SSM.

Logging and Auditing

Amazon EC2 and Amazon EBS are integrated with AWS CloudTrail, a service that provides a record of actions taken by a user, role, or an AWS service in Amazon EC2 and Amazon EBS.

CloudTrail captures all API calls for Amazon EC2 and Amazon EBS as events, including calls from the console and from code calls to the APIs.

If you create a trail, you can enable continuous delivery of CloudTrail events to an Amazon S3 bucket, including events for Amazon EC2 and Amazon EBS.

If you don’t configure a trail, you can still view the most recent events in the CloudTrail console in Event history.

Using the information collected by CloudTrail, you can determine the request that was made to Amazon EC2 and Amazon EBS, the IP address from which the request was made, who made the request, when it was made, and additional details.

Authorization and Access Control

Network access control:

A security group acts as a firewall that controls the traffic allowed to reach one or more instances. When you launch an instance, you assign it one or more security groups. You add rules to each security group that control traffic for the instance. You can modify the rules for a security group at any time; the new rules are automatically applied to all instances to which the security group is assigned.

AWS Identity and Access Management (IAM):

Amazon EC2 supports identity-based policies. Identity-based policies are attached to an IAM user, group, or role. These policies let you specify what that identity can do (its permissions).  For example, you can attach the policy to the IAM user named Paul, stating that he is allowed to perform the Amazon EC2 RunInstances action.

Sharing AMIs cross account:

Amazon EC2 enables you to specify additional AWS accounts that can use your Amazon Machine Images (AMIs) and Amazon EBS snapshots. These permissions work at the AWS account level only; you can’t restrict permissions for specific users within the specified AWS account. All users in the AWS account that you’ve specified can use the AMI or snapshot. Each AMI has a LaunchPermission attribute that controls which AWS accounts can access the AMI.