AWS Administration - The Definitive Guide - Sample Chapter
AWS Administration - The Definitive Guide - Sample Chapter
AWS Administration - The Definitive Guide - Sample Chapter
P U B L I S H I N G
Yohan Wadia
This book is for those who want to learn and leverage AWS.
Although no prior experience with AWS is required, it is
recommended that you have some hands-on experience
of Linux, web services, and basic networking.
ee
Sa
pl
e
P r o f e s s i o n a l
E x p e r t i s e
D i s t i l l e d
Yohan Wadia
P U B L I S H I N G
Preface
Cloud computing has definitely matured and evolved a lot ever since its conception.
Practically all major industries and top fortune 500 companies today run their
application workloads on clouds to reap all sorts of benefits, ranging from reduced
costs, better availability of their applications, and easier manageability to on-demand
scalability, and much more! At the forefront of this cloud innovation is a market
leader like no other: Amazon Web Services (AWS).
AWS provides a ton of easy-to-use products and services that you can leverage to
build, host, deploy, and manage your applications on the cloud. It also provides a
variety of ways to interact with these services, such as SDKs, APIs, CLIs, and even a
web-based management console.
This book is a one stop shop where you can find all there is to getting started with
the core AWS services, which include EC2, S3, RDS, VPCs, and a whole lot more! If
you are a sysadmin or an architect or someone who just wants to learn and explore
various aspects of administering AWS services, then this book is the right choice for
you! Each chapter of this book is designed to help you understand the individual
services' concepts as well as gain hands-on experience by practicing simple and
easy to follow steps. The chapters also highlight some key best practices and
recommendations that you ought to keep in mind when working with AWS.
Preface
Introducing EC2!
Remember the never ending hassles of a long and tedious procurement process? All
that time you spent waiting for a brand new server to show up at your doorstep so that
you could get started on it? Something we all as sysadmins have gone through. Well,
that all changed on August 25, 2006 when Amazon released the first beta version of
one of its flagship service offerings called the Elastic Compute Cloud or EC2.
EC2 is a service that basically provides scalable compute capacity on an on-demand,
pay-per-use basis to its end users. Let's break it up a bit to understand the terms
a bit better. To start with, EC2 is all about server virtualization! And with server
virtualization, we get a virtually unlimited capacity of virtual machines or, as
AWS calls it, instances. Users can dynamically spin up these instances, as and when
required, perform their activity on them, and then shut down the same while getting
billed only for the resources they consume.
[ 51 ]
EC2 is also a highly scalable service, which means that you can scale up from just
a couple of virtual servers to thousands in a matter of minutes, and vice versaall
achieved using a few simple clicks of a mouse button! This scalability accompanied
by dynamicity creates an elastic platform that can be used for performing virtually any
task you can think of! Hence, the term Elastic Compute Cloud! Now that's awesome!
But the buck doesn't just stop there! With virtually unlimited compute capacity,
you also get added functionality that helps you to configure your virtual server's
network, storage, as well as security. You can also integrate your EC2 environment
with other AWS services such as IAM, S3, SNS, RDS, and so on. To provide your
applications with add-on services and tools such as security, scalable storage and
databases, notification services, and so on and so forth.
Dev/Test environments: With the help of EC2, organizations can now create
and deploy large scale development and testing environments with utmost
ease. The best part of this is that they can easily turn on and off the service as
per their requirements as there is no need for any heavy upfront investments
for hardware.
Backup and disaster recovery: EC2 can be also leveraged as a medium for
performing disaster recovery by providing active or passive environments
that can be turned up quickly in case of an emergency, thus resulting in faster
failover with minimal downtime to applications.
Chapter 3
Understanding images
As discussed earlier, images are nothing more than preconfigured templates that you
can use to launch one or more instances from. In AWS, we call these images Amazon
Machine Images (AMIs). Each AMI contains an operating system which can range
from any modern Linux distro to even Windows Servers, plus some optional
software application, such as a web server, or some application server installed on it.
[ 53 ]
Secondly, an AMI can contain certain launch permissions as well. These permissions
dictate whether the AMI can be launched by anyone (public) or by someone or some
account which I specify (explicit) or I can even keep the AMI all to myself and not allow
anyone to launch instances from it but me (implicit). Why have launch permissions?
Well, there are cases where some AMIs can contain some form of propriety software or
licensed application, which you do not want to share freely among the general public.
In that case, these permissions come in really handy! You can alternatively even
create something called as a paid AMI. This feature allows you to share your AMI to
the general public, however, with some support costs associated with it.
AMIs can be bought and sold using something called as the AWS Marketplace as
wella one stop shop for all your AMI needs! Here, AMIs are categorized according
to their contents and you as an end user can choose and launch instances off any one
of them. Categories include software infrastructure, development tools, business and
collaboration tools, and much more! These AMIs are mostly created by third parties
or commercial companies who wish to either sell or provide their products on the
AWS platform.
[ 54 ]
Chapter 3
AMIs can be broadly classified into two main categories depending on the way they
store their root volume or hard drive:
EBS-backed AMI: An EBS-backed AMI simply stores its entire root device
on an Elastic Block Store (EBS) volume. EBS functions like a network shared
drive and provides some really cool add on functionalities like snapshotting
capabilities, data persistence, and so on. Even more, EBS volumes are not tied
to any particular hardware as well. This enables them to be moved anywhere
within a particular availability zone, kind of like a Network Attached
Storage (NAS) drive. We shall be learning more about EBS-backed AMIs and
instances in the coming chapter.
The following image depicts the deployments of both the instance store-backed and
EBS-backed AMIs. As you can see, the root and data volumes of the instance storebacked AMI are stored locally on the HOST SERVER itself, whereas the second
instance uses EBS volumes to store its root device and data.
[ 55 ]
The following is a quick differentiator to help you understand some of the key
differences between EB-backed and Instance store-backed AMIs:
Root device
EBS backed
Up to 16 TB supported.
Up to 10 GB supported.
Data persistence
Boot time
Costs
Later on, we will be using this Amazon Linux AMI itself and launching our very
first, but not the last, instance into the cloud, so stick around!
[ 56 ]
Chapter 3
Understanding instances
So far we have only being talking about images; so now let's shift the attention over to
instances! As discussed briefly earlier, instances are nothing but virtual machines or
virtual servers that are spawned off from a single image or AMI. Each instance comes
with its own set of resources, namely CPU, memory, storage, and network, which are
differentiated by something called as instance families or instance types. When you
first launch an instance, you need to specify its instance type. This will determine the
amount of resources that your instance will obtain throughout its lifecycle.
AWS currently supports five instance types or families, which are briefly explained
as follows:
[ 57 ]
GPU instances: Similar to the compute optimized family, the GPU instances
are specially designed for handling high CPU-intensive tasks but by using
specialized NVIDIA GPU cards. This instance family is generally used for
applications that require video encoding, machine learning or 3D rendering,
and so on. This group consists of a single instance type called G2, and it can
range between 1 GPU (g2.2xlarge) and 4 GPU (g2.8xlarge).
To know more about the various instance types and their use cases,
refer to http://aws.amazon.com/ec2/instance-types/.
As of late, AWS EC2 supports close to 38 instance types, each with their own set
of pros and cons and use cases. In such times, it actually becomes really difficult
for an end user to decide which instance type is right for his/her application. The
easiest and most common approach taken is to pick out the closet instance type that
matches your application's set of requirements - for example, it would be ideal to
install a simple MongoDB database on a memory optimized instance rather than a
compute or GPU optimized instance. Not that compute optimized instances are a
wrong choice or anything, but it makes more sense to go for memory in such cases
rather than just brute CPU. From my perspective, I have always fancied the general
purpose set of instances simply because most of my application needs seem to get
balanced out correctly with it, but feel free to try out other instance types as well.
On-demand instances
Pretty much the most commonly used instance deployment method, the on-demand
instances are created only when you require them, hence the term on-demand. Ondemand instances are priced by the hour with no upfront payments or commitments
required. This, in essence, is the true pay-as-you-go payment method that we always
end up mentioning when talking about clouds. These are standard computational
resources that are ready whenever you request them and can be shut down anytime
during its tenure.
[ 58 ]
Chapter 3
By default, you can have a max of 20 such on-demand instances launched within
a single AWS account at a time. If you wish to have more such instances, then you
simply have to raise a support request with AWS using the AWS Management
Console's Support tab. A good use case for such instances can be an application
running unpredictable workloads, such as a gaming website or social website. In this
case, you can leverage the flexibility of on-demand instances accompanied with their
low costs to only pay for the compute capacity you need and use and not a dime more!
On-demand instance costs vary based on whether the
underlying OS is a Linux or Windows, as well as in the
regions that they are deployed in.
Consider this simple example: A t2.micro instance costs $0.013 per hour to run in
the US East (N. Virginia) region. So, if I was to run this instance for an entire day, I
would only have to pay $0.312! Now that's cloud power!
Reserved instances
Deploying instances using the on-demand model has but one slight drawback,
which is that AWS does not guarantee the deployment of your instance. Why, you
ask? Well to put it simply, using on-demand model, you can create and terminate
instances on the go without having to make any commitments whatsoever. It is up
to AWS to match this dynamic requirement and make sure that adequate capacity is
present in its datacenters at all times. However, in very few and rare cases, this does
not happen, and that's when AWS will fail to power on your on-demand instance.
In such cases, you are better off by using something called as reserved instances,
where AWS actually guarantees your instances with resource capacity reservations
and significantly lower costs as compared to the on-demand model. You can choose
between three payment options when you purchase reserved instances: all upfront,
partial upfront, and no upfront. As the name suggests, you can choose to pay some
upfront costs or the full payment itself for reserving your instances for a minimum
period of a year and maximum up to three years.
Consider our earlier example of the t2.micro instance costing $0.0013 per hour. The
following table summarizes the upfront costs you will need to pay for a period of
one year for a single t2.micro instance using the reserved instance pricing model:
Payment method
Upfront cost
Monthly cost
Hourly cost
Savings over
on-demand
No upfront
$0
$6.57
$0.009
31%
Partial upfront
$51
$2.19
$0.0088
32%
All upfront
$75
$0
$0.0086
34%
[ 59 ]
Reserved instances are the best option when the application loads are steady and
consistent. In such cases, where you don't have to worry about unpredictable
workloads and spikes, you can reserve a bunch of instances in EC2 and end up
saving on additional costs.
Spot instances
Spot instances allow you to bid for unused EC2 compute capacity. These instances
were specially created to address a simple problem of excess EC2 capacity in AWS.
How does it all work? Well, it's just like any other bidding system. AWS sets the
hourly price for a particular spot instance that can change as the demand for the spot
instances either grows or shrinks. You as an end user have to place a bid on these spot
instances, and when your bid exceeds that of the current spot price, your instances
are then made to run! It is important to also note that these instances will stop the
moment someone else out bids you, so host your application accordingly. Ideally,
applications that are non-critical in nature and do not require large processing times,
such as image resizing operations, are ideally run on spot instances.
Let's look at our trusty t2.micro instance example here as well. The on-demand cost
for a t2.micro instance is $0.013 per hour; however, I place a bid of $0.0003 per hour
to run my application. So, if the current bid cost for the t2.micro instance falls below
my bid, then EC2 will spin up the requested t2.micro instances for me until either I
choose to terminate them or someone else out bids me on the samesimple, isn't it?
Spot instances compliment the reserved and on-demand instances; hence, ideally,
you should use a mixture of spot instances working on-demand or reserved
instances just to be sure that your application has some compute capacity on standby
in case it needs it.
[ 60 ]
Chapter 3
Once you have logged into the AWS Management Console, finding the EC2 option
isn't that hard. Select the EC2 option from under the Compute category, as shown in
the following screenshot:
This will bring up the EC2 dashboard on your browser. Feel free to have a look
around the dashboard and familiarize yourself with it. To the left, you have the
Navigation pane that will help you navigate to various sections and services
provided by EC2, such as Instances, Images, Network and Security, Load
Balancers, and even Auto Scaling. The centre dashboard provides a real-time
view of your EC2 resources, which includes important details such as how many
instances are currently running in your environment, how many volumes, key pairs,
snapshots, or elastic IPs have been created, so on and so forth.
The dashboard also displays the current health of the overall region as well as its
subsequent availability zones. In our case, we are operating from the US West (Oregon)
region that contains additional AZs called as us-west-2a, us-west-2b, and us-west-2c.
These names and values will vary based on your preferred region of operation.
[ 61 ]
Next up, we launch our very first instance from this same dashboard by selecting the
Launch Instance option, as shown in the following screenshot:
On selecting the Launch Instance option, you will be directed to a wizard driven
page that will help you create and customize your very first instance. This wizard
divides the entire instance creation operation into seven individual stages, each stage
having its own set of configurable items. Let's go through these stages one at a time.
There are also a host of other operating systems provided here as well which
includes Ubuntu, SUSE Linux, Red Hat, and Windows Servers.
[ 62 ]
Chapter 3
Each of these AMIs has a uniquely referenced AMI ID, which looks something like
this: ami-e75272d7. We can use this AMI ID to spin up instances using the AWS CLI,
something which we will perform in the coming sections of this chapter. They also
contain additional information such as whether the root device of the AMI is based
on an EBS volume or not, whether the particular AMI is eligible under the Free tier
or not, and so on and so forth.
Besides the Quick Start guide, you can also spin up your instances using the AWS
Marketplace and the Community AMIs section as well. Both these options contain
an exhaustive list of customized AMIs that have been created by either third-party
companies or by developers and can be used for a variety of purposes. But for this
exercise, we are going to go ahead and select Amazon Linux AMI itself from the
Quick Start menu.
Ideally, now you can launch your instance right away, but this will not allow you to
perform any additional configurations on your instance, which just isn't nice! So, go
ahead and click on the Next: Configure instance Details button to move on to the
third stage.
[ 63 ]
Number of instances: You can specify how many instances the wizard
should launch using this field. By default, the value is always set to one
single instance.
Network: Select the default Virtual Private Cloud (VPC) network that is
displayed in the dropdown list. You can even go ahead and create a new
VPC network for your instance, but we will leave all that for later chapters
where we will actually set up a VPC environment.
In our case, the VPC has a default network of 172.31.0.0/16, which means we
can assign up to 65,536 IP addresses using it.
Subnet: Next up, select the Subnet in which you wish to deploy your new
instance. You can either choose to have AWS select and deploy your instance
in a particular subnet from an available list or you can select a particular
choice of subnet on your own. By default, each subnet's Netmask defaults to
/20, which means you can have up to 4,096 IP addresses assigned in it.
[ 64 ]
Chapter 3
Auto-assign Public IP: Each instance that you launch will be assigned a
Public IP. The Public IP allows your instance to communicate with the
outside world, a.k.a. the Internet! For now, select the use Subnet setting
(Enable) option as shown.
IAM role: You can additionally select a particular IAM role to be associated
with your instance. In this case, we do not have any roles particularly created.
Shutdown behaviour: This option allows you to select whether the instance
should stop or be terminated when issued a shutdown command. In
this case, we have opted for the instance to stop when it is issued a
shutdown command.
Enable termination protection: Select this option in case you wish to protect
your instance against accidental deletions.
Once you have selected your values, move on to the fourth stage of the instance
deployment process by selecting the Next: Add Storage option.
[ 65 ]
Try and keep the volume's size under 30 GB to avail the free
tier eligibility.
You can optionally increase the size of the volume and enable add-on features such
as Delete on Termination as per your requirement. Once done, proceed to the next
stage of the instance deployment process by selecting the Next: Tag instance option.
Once your tags are set, click on the Next: Configure Security Group option to
proceed.
[ 66 ]
Chapter 3
You can add additional rules to your security group based on your requirements as
well. For example, in our instance's case, we want the users to receive all inbound
HTTP traffic as well. So, select the Add Rule option to add a firewall rule. This will
populate an additional rule line, as shown in the preceding screenshot. Next, from
the Type dropdown, select HTTP and leave the rest of the fields to their default
values. With our security group created and populated, we can now go ahead with
the final step in the instance launch stage.
[ 67 ]
Select the Create a new key pair option from the dropdown list and provide a
suitable name for your key pair as well. Click on the Download Key Pair option to
download the .PEM file. Once completed, select the Launch Instance option. The
instance will take a couple of minutes to get started. Meanwhile, make a note of the
new instance's ID (in this case, i-53fc559a) and feel free to view the instance's launch
logs as well:
[ 68 ]
Chapter 3
Phew! With this step completed, your instance is now ready for use! Your instance
will show up in the EC2 dashboard, as shown in the following screenshot:
The dashboard contains and provides a lot of information about your instance. You
can view your instance's ID, instance type, power state, and a whole lot more info
from the dashboard. You can also obtain your instance's health information using
the Status Checks tab and the Monitoring tab. Additionally, you can perform power
operations on your instance such as start, stop, reboot, and terminate using the
Actions tab located in the preceding instance table.
Before we proceed to the next section, make a note of your instance's Public DNS
and the Public IP. We will be using these values to connect to the instances from our
local workstations.
[ 69 ]
3. You will be required, however, to enter the User name and the
Private key path, as shown in the following screenshot:
5. Since this is going to be your first SSH attempt using the MindTerm
plugin, you will be prompted to accept an end user license agreement.
6. Select the Accept option to continue with the process. You will be
prompted to accept few additional prompts along the way, which
include the setting up of your home directory and known hosts
directory on your local PC.
[ 70 ]
Chapter 3
7. Confirm all these settings and you should now see the MindTerm
console displaying your instance's terminal, as shown in the
following screenshot:
Using Putty: The second option is by far the most commonly used and one
of my favorites as well! Putty, or PuTTY, is basically an SSH and telnet client
that can be used to connect to your remote Linux instances. But before you
get working on Putty, you will need a tool called PuttyGen to help you
create your private key (*.ppk).
You can download Putty, PuttyGen, and various other SSH
and FTP tools from http://www.chiark.greenend.
org.uk/~sgtatham/putty/download.html.
After creating your private key, follow the next steps to use Putty and PuttyGen:
1. First up, download and install the latest copy of Putty and PuttyGen
on your local desktops.
2. Next, launch PuttyGen from the start menu. You should see the
PuttyGen dialog as shown in the following screenshot.
[ 71 ]
3. Click on the Load option to load your PEM file. Remember, this is
the same file that we downloaded during stage 7 of the instance
launch phase.
4. Once loaded, go ahead and save this key by selecting the Save
private key option.
PuttyGen will probably prompt you with a warning message stating that you
are saving this key without a passphrase and would you like to continue.
5. Select Yes to continue with the process. Provide a meaningful name
and save the new file (*.PPK) at a secure and accessible location. You
can now use this PPK file to connect to your instance using Putty.
[ 72 ]
Chapter 3
Now comes the fun part! Launch a Putty session from the Start menu. You
should see the Putty dialog box as shown in the following screenshot. Here,
provide your instance's Public DNS or Public IP in the Host Name (or IP
address) field as shown. Also make sure that the Port value is set to 22 and
the Connection type is selected as SSH.
[ 73 ]
Using SSH: The third and final method is probably the most simple and
straightforward. You can connect to your EC2 instances using a simple
SSH client as well. This SSH client can be installed on a standalone Linux
workstation or even on a Mac. Here, we will be using our CentOS 6.5
machine that has the AWS CLI installed and configured in it and following
the next steps, we will be able to look into our EC2 dashboard:
1. First up, transfer your private key (*.PEM) file over to the Linux
server using and SCP tool. In my case, I always use WinSCP to
achieve this. It's a simple tool and pretty straightforward to use. Once
the key is transferred, run the following command to change the
key's permissions:
# chmod 400 <Private_Key>.pem
2. Next up, simply connect to the remote EC2 instance by using the
following SSH command. You will need to provide your EC2
instance's public DNS or its public IP address, which can be found
listed on the EC2 dashboard:
# ssh -I <Private_Key>.pem ec2-user@<EC2_Instance_PublicDNS>
[ 74 ]
Chapter 3
[ 75 ]
You should see an 8 GB disk mounted on the root (/) partition, as shown in the
preceding screenshot. Not bad, eh! Let's try something else, like updating the
operating system. AWS Linux AMIs are regularly patched and provided with
necessary package updates, so it is a good idea to patch them from time to time.
Run the following command to update the Amazon Linux OS:
# sudo yum update -y
Why sudo? Well, as discussed earlier, you are not provided with root privileges
when you log in to your instance. You can change that by simple changing the
current user to root after you login; however, we are going to stick with the ec2-user
itself for now.
What else can we do over here? Well, let's go ahead and install some specific
software for our instance. Since this instance is going to act as a web server, we will
need to install and configure a basic Apache HTTP web server package on it.
Type in the following set of commands that will help you install the Apache HTTP
web server on your instance:
# sudo yum install httpd
Once the necessary packages are installed, simply start the Apache HTTP server
using the following simple commands:
# sudo service httpd start
# sudo chkconfig httpd on
You can see the server running after running the preceding commands, as shown in
the following screenshot:
[ 76 ]
Chapter 3
You can verify whether your instance is actually running a web server or not by
launching a web browser on your workstation and typing either in the instance's
public IP or public DNS. You should see the Amazon Linux AMI test page, as shown
in the following screenshot:
There you have it! A fully functional and ready-to-use web server using just a few
simple steps! Now wasn't that easy!
Once the key pair has been created, remember to change its permissions using the
following command:
# chmod 400 <Key_Pair_Name>.pem
[ 77 ]
For creating security groups, you are only required to provide a security group name
and an optional description field along with it. Make sure that you provide a simple
yet meaningful name here:
Once executed, you will be provided with the new security group's ID as the output.
Make a note of this ID as it will be required in the next few steps.
[ 78 ]
Chapter 3
To add a firewall rule, you will be required to provide the security group's name to
which the rule has to be applied. You will also need to provide the protocol, port
number, and network CIDR values as per your requirements:
[ 79 ]
The instance will take a good two or three minutes to spin up, so be patient! Make a
note of the instance's ID from the output of the ec2 run-instance command. We will
be using this instance ID to find out the instance's public IP address using the EC2
describe-instance command as shown:
# aws ec2 describe-instances --instance-ids <Instance_ID>
Make a note of the instance's public DNS or the public IP address. Next, use the key
pair created and connect to your instance using any of the methods discussed earlier.
Cleaning up!
Spinning up instances is one thing; you should also know how to stop and terminate
them! To perform any power operations on your instance from the EC2 dashboard,
all you need to do is select the particular instance and click on the Actions tab as
shown. Next, from the Instance State submenu, select whether you want to Stop,
Reboot, or Terminate your instance, as shown in the following screenshot:
[ 80 ]
Chapter 3
[ 81 ]
And last but not least, have some fun with configuring your instances! Don't stop
just at a simple Web Server; go ahead and set up a full fledge WordPress application
on your instances or launch multiple instances and set up JBoss Clustering among
them and so on. The more you configure and use the instances, the more you will
get acquainted with the terms and terminologies and find out how easy it is working
with AWS! Just remember to clean up your work after it is done.
First and foremost, create and use separate IAM users for working with EC2.
DO NOT USE your standard root account credentials!
Use IAM roles if you need to delegate access to your EC2 account to other
people for some temporary period of time. Do not share your user passwords
and keys with anyone.
Use a standard and frequently deployed set of AMIs as they are tried and
tested by AWS thoroughly.
Make sure that you understand the difference between instance store-backed
and EBS-backed AMIs. Use the instance store with caution and remember
that you are responsible for your data, so take adequate backups of it.
Don't create too many firewall rules on a single security group. Make sure
that you apply the least permissive rules for your security groups.
Stop your instances when not in use. This will help you save up on costs
as well.
Use tags to identify your EC2 instances. Tagging your resources is a good
practice and should be followed at all times.
Save your key pairs in a safe and accessible location. Use passphrases as an
added layer of security if you deem it necessary.
[ 82 ]
Chapter 3
Summary
So, let's wrap up what we have learnt so far! First up, we looked at what exactly
the AWS EC2 service is and how we can leverage it to perform our daily tasks.
Next, we understood a bit about images and instances by looking at the various
instance types and pricing options provided. Finally, we also managed to
launch a couple of instances in EC2 using both the EC2 dashboard as well as the
AWS CLI. We topped it all off with some interesting next steps and a bunch of
recommendations and best practices!
In the next chapter, we will continue with the EC2 service and explore some of
the advanced network, security, and storage options that come along with it, so
stay tuned!
[ 83 ]
www.PacktPub.com
Stay Connected: