Professional Documents
Culture Documents
EC2
EC2
service is and does and how to configure an EC2 instance, so let's get
started.
As EC2 is one of the most common services used throughout AWS, I will
discuss this service in greater detail over the other services that I will cover
in this course.
EC2 is the most common compute service that AWS offers, as it allows you
to deploy virtual servers within your AWS environment; and most people
will require a server in one form or another as a part of their solution. There
are a number of elements in creating your EC2 instance, which I want to
break down and explain. This will hopefully help to define how the service
works and answer a number of questions that you may have.
The EC2 service can be broken down into the following sections:
The first point I want to cover are AMIs, Amazon Machine Images. These
are essentially templates of pre-configured EC2 instances which allow you
to quickly launch a new EC2 instance based on the configuration within the
AMI. This prevents you from having to install an operating system or any
other common applications that you might need to install on a number of
other EC2 instances. From a high-level perspective, an AMI will include an
operating system and applications, along with any custom configuration.
AWS provides a large number of AMIs covering different operating
systems, from Linux to Red Hat to Microsoft Windows, among others.
When configuring your EC2 instance, selecting your AMI is the first
configuration choice you will need to make. You can also create your own
AMI images to help you speed up your own deployments.
For example, you would start with selecting an AWS AMI, let's say a Linux
server. Once it is up and running, you may then need to install a number of
your own custom applications and make specific configuration changes.
Now if you needed another server to perform the same functionality, you
could go through the same process of selecting a Linux AWS AMI and,
again, manually installing your applications and make your configurations.
Or, once you have made those changes on the first server, you can then
simply create a brand new AMI of that instance with all the applications
installed and configurations already made. Then if you need another server
of the same configuration, all you would need to do is to select your custom
AMI as the base image for your instance and it will launch the Linux
server, your custom applications already installed, and any configurations
already made.
As you can see, this has many benefits and certainly comes in useful when
we start to look at autoscaling later in this course. In addition to both AWS-
managed and your own custom AMIs, you could also select an AMI from
the AWS marketplace. The AWS marketplace is basically an online store
that allows you to purchase AMIs from trusted vendors like Cisco, Citrix,
Alert Logic, etc. These vendor AMIs may have specific applications and
configurations already made, such as instances that are optimized with
built-in security and monitoring tools or contain database migration
systems. Lastly, community AMIs also exist, which are a repository of
AMIs that have been created and shared by other AWS members.
Let's now take a look at instance types. Once you have selected your AMI
from any of the different sources already discussed, you must then select an
instance type. An instance type simply defines the size of the instance from
a CPU, memory, storage, and networking perspective. Having this
flexibility of varied instances allows you to select the most appropriate size
or power of a virtual server that you need for optimal performance with
your applications.
These different instance types are categorized into different family types
that offer distinct performance benefits which, again, helps you to select the
most appropriate instance for your needs. Within each of these instance
families, you will have a range of instance types with varied CPU, memory,
storage, and networking performance. These instance families can be
summarized as follows.
on-demand instances
reserved instances
spot instances
dedicated instances
and dedicated hosts
1. All upfront; the complete payment for the one- or three-year reservation
is paid. This offers the largest discount and no further payment is
required, regardless of the number of hours the instance is used.
2. Partial upfront; a smaller upfront payment is made, and then a discount
is applied to any hours used by the instance during the term.
3. No upfront; no upfront or partial payments are made, and the smallest
discount of the three models is applied to any hours used by the
instance.
Shared tenancy; this option will launch your EC2 instance on any
available host with the specified resources required for your selected
instance type, regardless of which other customers and users also have
EC2 instances running on the same host, hence the shared tenancy
name. Advanced security mechanisms are in place to prevent one EC2
instance accessing another on the same host. How this security is
applied and operated is out of scope of this course and is maintained by
AWS themselves.
Dedicated tenancy includes both dedicated instances and dedicated
hosts.
o Dedicated instances are hosted on hardware that no other customer
can access. It can only be accessed by your own AWS account. You
may be required to launch your instances as a dedicated instance due
to internal security policies or external compliance controls.
Dedicated instances do incur additional charges due to the fact you
are preventing other customers from running EC2 instances on the
same hardware, and so there will be unused capacity.
o Dedicated hosts; dedicated hosts are effectively the same as
dedicated instances, however, they offer additional visibility and
control over how you place your instances on the physical host. This
allows you to use the same host for a number of instances that you
want to launch. Also, dedicated hosts allow you to align with any
compliance and regulatory requirements.
If you do not need to address any compliance issues that require dedicated
tenancy, then I would recommend using shared tenancy to reduce your
overall costs.
During the configuration of your EC2 instance, there is a section called user
data, which allows you to enter commands that will run during the first boot
cycle of that instance. This is a great way to automatically perform
functions upon boot, such as to pull down any additional software you want
installing from any software repositories you may have. You could also
download and get the latest OS updates during boot. For example, you
could enter yum update /y for a Linux server, which will then update its
own software automatically at time of boot.
As a part of the configuration when setting up an EC2 instance, you are
asked to select and configure your storage requirements. Selecting storage
for your EC2 instance will depend on what you intend to use the instance
for and how critical the data is. Storage for EC2 can be classified between
two distinct categories:
1. persistent storage
2. and ephemeral, which is temporary storage
Let's look at system status checks first. If this fails, then is likely to be an
issue with the underlying host rather than a configuration issue with your
EC2 instance itself. Common issues that trigger system status checks to fail
are loss of power, loss of network connectivity, and hardware ad software
issues on the underlying host. Basically, a system status check failure is out
of your control as the fault lies with the components that AWS are
responsible for. The best way to resolve this would be to stop the instance
and restart. This is likely to cause the instance to launch on another physical
host, resolving the issue. Do not reboot the instance, as this will cause the
instance to continue running on the same physical server.
Let's now take a look at the instance status checks. These differ from
system status checks; as if this failed, then it would likely require your
input to help resolve the issue. This check looks at the EC2 instance itself,
rather than focusing on the underlying host. Common issues that trigger this
check to fail are incorrect network configuration, corrupt file systems,
exhausted memory, or an incompatible kernel. These faults will require you
to troubleshoot and resolve the issue. For example, changing the network
configuration.
That brings us to the end of this lecture on EC2. Like I mentioned
previously, this was going to be the longest and the most in-depth lecture
simply due to this being a key compute service.
If you would like some hands-on experience with EC2, then we do offer
two labs in which you can practice creating your own EC2 instances for
both Linux and Windows. Coming up in the next lecture, I will discuss
elastic load balancing and auto scaling.