HRISHIK ARYAN PRADHAN

UCSE20014

SEMESTER 6

REPORT:2
AWS Technical Essentials

HP
 AWS Technical Essentials
REPORT SUBMISSION

What Is AWS?
Prior to the advent of the cloud, businesses and organisations hosted
and managed computing, storage, and networking infrastructure in
their own data centres. They frequently assigned whole infrastructure
departments to maintain their data centres, leading to expensive
operations that prevented some workloads and experimentation.

The need for computing, storage, and networking hardware grew as

internet usage proliferated. Some businesses and organisations
couldn't afford the expenses of keeping a sizable physical presence.
Cloud computing was created as a solution to this issue.

With pay-as-you-go pricing, cloud computing is the on-demand

distribution of IT resources over the internet. Businesses no longer
need to manage and maintain their own hardware and data centres
thanks to cloud computing. As an alternative, businesses like AWS own
and maintain data. Instead, organisations like AWS operate and
manage data centres and offer businesses and customers online virtual
data centre technology and services.
Think of a situation where your developers must install a new
application functionality to help distinguish between running workloads
on-premises and in the cloud. The team wants to test the functionality
in a different quality assurance (QA) environment with the same setup
as production before they release. An extra environment in an on-
premises solution necessitates the purchase and installation of
hardware, the connection of essential cables, the provisioning of
electricity, the installation of operating systems, and more. These tasks
can be costly and time-consuming. While the developers wait for the
QA environment, the time it takes to market the new product
lengthens.
Availability Zones

Inside every Region is a cluster of Availability Zones (AZs). An AZ

consists of one or more data centers with redundant power,
networking, and connectivity. These data centers operate in discrete
facilities in undisclosed locations. They are connected using redundant
high-speed and low-latency links.
AZs also have a code name. Since they are located inside Regions, they
can be addressed by appending a letter to the end of the Region code
name. For example:

us-east-1a: An AZ in us-east-1 (N. Virginia Region)

sa-east-1b: An AZ in sa-east-1 (São Paulo Region)
Therefore, if you see that a resource exists in us-east-1c, you can infer
that the resource is located in AZ c of the us-east-1 Region.

Scope AWS services

Depending on the AWS service you use, your resources are either
deployed at the AZ, Region, or Global level. Each service is different, so
you must understand how the scope of a service might affect your
application architecture.

When you operate a Region-scoped service, you only need to select the
Region you want to use. If you are not asked to specify an individual AZ
to deploy the service in, this is an indicator that the service operates on
a Region-scope level. For Region-scoped services, AWS automatically
performs actions to increase data durability and availability.
On the other hand, some services ask you to specify an AZ. With these
services, you are often responsible for increasing the data durability
and high availability of these resources.

Maintain resiliency
To keep your application available, you must maintain high availability
and resiliency. A well-known best practice for cloud architecture is to
use Region-scoped, managed services. These services come with
availability and resiliency built in. When that is not possible, make sure
your workload is replicated across multiple AZs. At a minimum, you
should use two AZs. That way, if an AZ fails, your application will have
infrastructure up and running in a second AZ to take over the traffic.

The AWS Management Console

One way to manage cloud resources is through the web-based console,
where you log in and choose the desired service. This can be the easiest
way to create and manage resources when you first begin working with
the cloud. Below is a screenshot that shows the landing page when you
first log in to the AWS Management Console.

The services are placed in categories, such as Compute, Storage,

Database, and Analytics

On the upper-right corner is the Region selector. If you choose it and

change the Region, you will make requests to the services in the chosen
Region. The URL changes, too. Changing the Region setting directs your
browser to make requests to a different AWS Region, represented by a
different subdomain.

The AWS Command Line Interface (AWS CLI)

Consider the scenario where you run tens of servers on AWS for your
application’s front end. You want to run a report to collect data from all
the servers. You need to do this programmatically every day because
the server details might change. Instead of manually logging in to the
AWS Management Console and then copying and pasting information,
you can schedule an AWS CLI script with an API call to pull this data for
you.

The AWS CLI is a unified tool that you can use to manage AWS services.
You can download and configure one tool that you can use to control
multiple AWS services from the command line and automate them with
scripts. The AWS CLI is open-source, and installers are available for
Windows, Linux, and macOS.

For example, if you run the following API call against a service using
AWS CLI:

aws ec2 describe-instances

you will get the following response:

{
"Reservations": [
{
"Groups": [],
"Instances": [
{
"AmiLaunchIndex": 0,
AWS SDKs

API calls to AWS can also be performed by running code with

programming languages. You can do this by using AWS software
development kits (SDKs). SDKs are open source and maintained by AWS
for the most popular programming languages, such as C++, Go, Java,
JavaScript, .NET, [Link], PHP, Python, and Ruby.

Developers commonly use AWS SDKs to integrate their application

source code with AWS services. For example, consider an application
with a front end that runs in Python. Every time the application receives
a cat photo, it uploads the file to a storage service. This action can be
achieved in the source code by using the AWS SDK for Python. Here is
an example of code you can implement to work with AWS resources
using the Python AWS SDK.
Security and the AWS Shared Responsibility Model
Play Video
When you work with the AWS Cloud, managing security and
compliance is a shared responsibility between AWS and you. To depict
this shared responsibility, AWS created the shared responsibility model.
The distinction of responsibility is commonly referred to as security OF
the cloud versus security IN the cloud.

AWS responsibility

AWS is responsible for security of the cloud. This means AWS protects
and secures the infrastructure that runs the services offered in the AWS
Cloud. AWS is responsible for:

Protecting and securing AWS Regions, Availability Zones, and data

centers, down to the physical security of the buildings
Managing the hardware, software, and networking components that
run AWS services, such as the physical servers, host operating systems,
virtualization layers, and AWS networking components
The level of responsibility AWS has depends on the service. AWS
classifies services into three categories. The following table provides
information about each, including the AWS responsibility.
Category Examples of AWS Services in the Category AWS
Responsibility
Infrastructure services Compute services, such as Amazon Elastic
Compute Cloud (Amazon EC2) AWS manages the underlying
infrastructure and foundation services.
Container services Services that require less management from the
customer, such as Amazon Relational Database Service (Amazon RDS)
AWS manages the underlying infrastructure and foundation
services, operating system, and application platform.
Abstracted services
Services that require very little management from the customer, such
as Amazon Simple Storage Service (Amazon S3)
AWS operates the infrastructure layer, operating system, and
platforms, in addition to server-side encryption and data protection.
Note: Container services refer to AWS abstracting application
containers behind the scenes, not Docker container services. This
enables AWS to move the responsibility of managing the platform away
from customers.

Customer responsibility

Customers are responsible for security in the cloud. When using any
AWS service, you’re responsible for properly configuring the service
and your applications, in addition to ensuring that your data is secure.
Your level of responsibility depends on the AWS service. Some services
require you to perform all the necessary security configuration and
management tasks, while other more abstracted services require you
to only manage the data and control access to your resources. Using
the three categories of AWS services, you can determine your level of
responsibility for each AWS service you use.

Category AWS Responsibility Customer Responsibility

Infrastructure services AWS manages the infrastructure and
foundation services. You control the operating system and application
platform, in addition to encrypting, protecting, and managing customer
data.
Container services AWS manages the infrastructure and foundation
services, operating system, and application platform. You are
responsible for customer data, encrypting the data, and protecting it
through network firewalls and backups.
Abstracted services
AWS operates the infrastructure layer, operating system, and
platforms, in addition to server-side encryption and data protection.
You are responsible for managing customer data and protecting it
through client-side encryption.
Due to the varying levels of effort, customers must consider which AWS
services they use and review the level of responsibility required to
secure each service. They must also review how the shared security
model aligns with the security standards in their IT environment, in
addition to any applicable laws and regulations.
A key concept is that customers maintain complete control of their data
and are responsible for managing the security related to their content.
For example, you are responsible for the following:

Choosing a Region for AWS resources in accordance with data

sovereignty regulations
Implementing data-protection mechanisms, such as encryption and
scheduled backups
Using access control to limit who can access to your data and AWS
resources.

Servers
The first building block you need to host an application is a server.
Servers usually can handle Hypertext Transfer Protocol (HTTP) requests
and send responses to clients following the client-server model, although
any API-based communication also falls under this model. A client is a
person or computer that sends a request. A server handling the requests
is a computer, or collection of computers, connected to the internet
serving websites to internet users.

Servers power your application by providing CPU, memory, and

networking capacity to process users’ requests and transform them into
responses. For context, common HTTP servers include:

 Windows options, such as Internet Information Services

(IIS)
 Linux options, such as Apache HTTP Web Server,
Nginx, and Apache Tomcat
To run an HTTP server on AWS, you must find a service that provides
compute power in the AWS Management Console. You can log in to the
console and view the complete list of AWS compute services.

Choose the right compute option

If you’re responsible for setting up servers on AWS to run your
infrastructure, you have many compute options. You need to know
which service to use for which use case. At a fundamental level, three
types of compute options are available – virtual machines (VMs),
container services, and serverless.

If you have prior infrastructure knowledge, a virtual machine is often be

the easiest compute option to understand. This is because a virtual
machine emulates a physical server and allows you to install an HTTP
server to run your applications. To run virtual machines, you install a
hypervisor on a host machine. The hypervisor provisions the resources
to create and run your VMs.

In AWS, virtual machines are called Amazon Elastic Compute Cloud, or

Amazon EC2. Behind the scenes, AWS operates and manages the host
machines and the hypervisor layer. AWS also installs the virtual
machine operating system, called the guest operating system.
Some AWS compute services use Amazon EC2 or use virtualization
concepts under the hood. You should understand this service before
advancing to container services and serverless compute.

Amazon Elastic Compute Cloud:

Amazon EC2

Amazon EC2 is a web service that provides secure, resizable compute

capacity in the cloud. It allows you to provision virtual servers called
EC2 instances. Although AWS uses the phrase “web service” to describe
it, you are not limited to running just web servers on your EC2 instances.

You can create and manage EC2 instances through the AWS
Management Console, the AWS Command Line Interface (CLI), AWS
software development kits (SDKs), automation tools, and infrastructure
orchestration services.

To create an EC2 instance, you must define the following:

 Hardware specifications, like CPU, memory, network,

and storage
 Logical configurations, like networking location, firewall
rules, authentication, and the operating system of your
choice
When launching an EC2 instance, the first setting you configure is
which operating system you want by selecting an Amazon Machine
Image (AMI).
Amazon Machine Image
In the traditional infrastructure world, the process of spinning up a
server consists of installing an operating system from installation disks,
installation drives, or installation wizards over the network. In the AWS
Cloud, the operating system installation is not your responsibility.
Instead, it's built into the AMI that you choose.

In addition, when you use an AMI, you can select storage mappings, the
architecture type (such as 32-bit, 64-bit, or 64-bit ARM), and additional
software installed.
Relationship between AMIs and EC2 instances

EC2 instances are live instantiations of what is defined in an AMI, much

like a cake is a live instantiation of a cake recipe. If you are familiar with
software development, you can also see this kind of relationship between
a class and an object.

A class is something you model and define, while an object is something

you interact with. In this case, the AMI is how you model and define
your instance, while the EC2 instance is the entity you interact with,
where you can install your web server and serve your content to users.

When you launch a new instance, AWS allocates a virtual machine that
runs on a hypervisor. Then, the AMI you selected is copied to the root
device volume, which contains the image used to boot the volume. In the
end, you get a server that you can connect to and install packages and
additional software on. In the example, you install a web server along
with the properly configured source code of your employee directory
app.
One advantage of using AMIs is that they are reusable. You might
choose a Linux-based AMI and configure the HTTP server, application
packages, and additional software you need to run your application. If
you want to create a second EC2 instance with the same configurations,
you could go through the entire instance creation and configuration
process to match your settings to the first instance. Or, you could create
an AMI from your running instance and use the AMI to start a new
instance. That way, your new instance would have the same
configurations as your current instance, because the configurations set in
the AMIs are the same.

Find AMIs

You can select an AMI from the following categories:

 Quick Start AMIs, which are created by AWS to help you

get started quickly
 AWS Marketplace AMIs, which provide popular open
source and commercial software from third-party vendors
 My AMIs, which are created from your EC2 instances
  Community AMIs, which are provided by the AWS user
community
 Build your own custom image with EC2 Image Builder

Each AMI in the AWS Management Console has an AMI ID, which is
prefixed by “ami-”, followed by a random hash of numbers and letters.
The IDs are unique to each AWS Region.

Amazon EC2 Instance Lifecycle

Now that you know how to select an operating system for your EC2 instance, you are ready to
choose other configurations to create your EC2 instance, such as the
instance type, network, and storage.

For an application like the employee directory application, you need

instances with enough capacity to run web servers and process incoming
customer requests. Your instance sizing will depend on both the
demands of your application and the anticipated size of your user base.

Forecasting server capacity for an on-premises application requires

difficult decisions involving significant up-front capital spending, while
changes to the allocation of your cloud-based services can be made with
a simple API call. Because of the AWS pay-as-you-go model, you can
match your infrastructure capacity to your application’s demand, instead
of the other way around.
Amazon EC2 instance types
Amazon EC2 instances are a combination of virtual processors (vCPUs),
memory, network, and, in some cases, instance storage and graphics
processing units (GPUs). When you create an EC2 instance, you need to
choose how much you need of each of these components.

AWS offers a variety of instances that differ based on performance.

Some instances provide more capacity than others. To get an overview
of the capacity details for a particular instance, you should look at the
instance type. Instance types consist of a prefix identifying the type of
workloads they’re optimized for, followed by a size. For example, the
instance type [Link] can be broken down as follows:

 c5 determines the instance family and generation number.

Here, the instance belongs to the fifth generation of
instances in an instance family that’s optimized for
generic computation.
 large determines the amount of instance capacity.

Instance families
In the example [Link], the first letter, c, stands for compute-optimized.
Compute optimized is one of the many instance families that AWS
offers. Each instance family is optimized to fit different use cases. The
following table describes instance families and some typical workloads.

EC2 instance locations

By default, your EC2 instances are placed in a network called the default
Amazon Virtual Private Cloud (Amazon VPC). This network was
created so that you can easily get started with Amazon EC2 without
learning how to create and configure a VPC.

Any resource you put inside the default VPC will be public and
accessible by the internet, so you shouldn’t place any customer data or
private information in it.

Once you get more comfortable with networking on AWS, you should
change this default setting to choose your own custom VPCs and restrict
access with additional routing and connectivity mechanisms.
Architect for high availability
In the network, your instance resides in an Availability Zone of your
choice. As you learned previously, AWS services that are scoped at the
Availability Zone level must be architected with high availability in
mind.

While EC2 instances are typically reliable, two is better than one, and
three is better than two. Specifying the instance size gives you an
advantage when designing your architecture because you can use more
smaller instances rather than a few larger ones.

If your front end only has a single instance and the instance fails, your
application goes down. On the other hand, if your workload is
distributed across 10 instances and one fails, you lose only 10 percent of
your fleet, and your application availability is hardly affected.

When architecting any application for high availability, consider using at

least two EC2 instances in two separate Availability Zones.

EC2 instance lifecycle

An EC2 instance transitions between different states from the moment you create it until it's
termination.
  1

When you launch an instance, it enters the pending state. When an

instance is pending, billing has not started. At this stage, the instance is
preparing to enter the running state. Pending is where AWS performs all
actions needed to set up an instance, such as copying the AMI content to
the root device and allocating the necessary networking components.

 2

When your instance is running, it's ready to use. This is also the stage
where billing begins. As soon as an instance is running, you can take
other actions on the instance, such as reboot, terminate, stop, and stop-
hibernate.

 3

When you reboot an instance, it’s different than performing a stop action
and then a start action. Rebooting an instance is equivalent to rebooting
an operating system. The instance remains on the same host computer,
and maintains its public and private IP address, in addition to any data
on its instance store.
  4

It typically takes a few minutes for the reboot to complete. When you
stop and start an instance, your instance may be placed on a new
underlying physical server. Therefore, you lose any data on the instance
store that were on the previous host computer. When you stop an
instance, the instance gets a new public IP address but maintains the
same private IP address.
 5
5
When you terminate an instance, the instance stores are erased, and you
lose both the public IP address and private IP address of the machine.
Termination of an instance means that you can no longer access the
machine.
Difference between stop and stop-hibernate
When you stop an instance, it enters the stopping state until it reaches
the stopped state. AWS does not charge usage or data transfer fees for
your instance after you stop it, but storage for any Amazon EBS
volumes is still charged. While your instance is in the stopped state, you
can modify some attributes, like the instance type. When you stop your
instance, the data stored in memory (RAM) is lost.

When you stop-hibernate an instance, AWS signals the operating system

to perform hibernation (suspend-to-disk), which saves the contents from
the instance memory (RAM) to the Amazon EBS root volume.

Consider a scenario where you build a standard three-tier application,

where you have web servers, application servers, and database servers.
Suddenly, the application you built becomes extremely popular. To
relieve some stress on the database that supports your application, you
want to implement a custom backend layer that caches database
information in memory (RAM). You decide to run this custom backend
caching solution on Amazon EC2.
In this scenario, the stop-hibernate feature would be instrumental in
persisting storage. It would prevent you from having to manually create
scripts to save the RAM data before shutting down the server.
Pricing
One of the ways to reduce costs with Amazon EC2 is to choose the right
pricing option for the way your applications run. AWS offers three main
purchasing options for EC2 instances – On-Demand, Reserved, and Spot
Instances.

Pay as you go with On-Demand Instances

With On-Demand Instances, you pay for compute capacity with no long-
term commitments. Billing begins whenever the instance is running, and
billing stops when the instance is in a stopped or terminated state. The
price per second for a running On-Demand Instance is fixed.

For applications that require servers to be running all the time, you are
less likely to benefit from the On-Demand pricing model, simply
because there is no situation where you will need to turn servers off. For
example, you might want the web server hosting the front end of your
corporate directory application to be running 24/7 so that users can
access the website at any time. Even if no users are connected to your
website, you don’t want to shut down the servers supporting the site in
case of potential user activity.
In the case when servers cannot be stopped, consider using a Reserved
Instance to save on costs.
Reserve capacity with Reserved Instances (RIs)

RIs provide you with a significant discount compared to On-Demand

Instance pricing. RIs provide a discounted hourly rate and an optional
capacity reservation for EC2 instances. You can choose between three
payment options – All Upfront, Partial Upfront, or No Upfront. You can
select either a 1-year or 3-year term for each of these options.

Depending on which option you choose, you are discounted differently.

 All Upfront offers a higher discount than Partial Upfront

instances.
 Partial Upfront instances offer a higher discount than
No Upfront.
 No Upfront offers a higher discount than On-Demand.

On-Demand and No Upfront are similar, since both do not require any
upfront payment. However, there is a major difference. When you
choose an On-Demand Instance, you stop paying for the instance when
you stop or terminate the instance. When you stop an RI, you still pay
for it because you committed to a 1-year or 3-year term.

Reserved Instances are associated with an instance type and an

Availability Zone depending on how you reserve it. The discount
applied by a Reserved Instance purchase is not directly associated with a
specific instance ID, but with an instance type.
Save on costs with Spot Instances
Another way to pay for EC2 instances is by using Spot Instances.
Amazon EC2 Spot Instances allow you to take advantage of unused EC2
capacity in the AWS Cloud. They are available at up to a 90% discount
compared to On-Demand prices.

With Spot Instances, you set a limit on how much you would like to pay
for the instance hour. This is compared against the current Spot price
that AWS determines. If the amount you pay is more than the current
Spot price and there is capacity, then you will receive an instance. While
they are very promising from the billing perspective, you must account
for some architectural considerations to use them effectively.

One consideration is that your Spot Instance might be interrupted. For

example, if AWS determines that capacity is no longer available for a
particular Spot Instance or if the Spot price exceeds how much you are
willing to pay, AWS will give you a 2-minute warning before it
interrupts your instance. That means any application or workload that
runs on a Spot Instance must be able to be interrupted.

Because of this unique consideration, inherently fault-tolerant workloads

are typically good candidates to use with Spot Instances. These include
big data, containerized workloads, continuous integration/continuous
delivery (CI/CD), web servers, high-performance computing (HPC),
image and media rendering, and other test and development workloads.

Now that you know how to select an operating system for your EC2
instance, you are ready to choose other configurations to create your
EC2 instance, such as the instance type, network, and storage.

For an application like the employee directory application, you need

instances with enough capacity to run web servers and process
incoming customer requests. Your instance sizing will depend on both
the demands of your application and the anticipated size of your user
base.

Forecasting server capacity for an on-premises application requires

difficult decisions involving significant up-front capital spending, while
changes to the allocation of your cloud-based services can be made
with a simple API call. Because of the AWS pay-as-you-go model, you
can match your infrastructure capacity to your application’s demand,
instead of the other way around.

Amazon EC2 instance types

Amazon EC2 instances are a combination of virtual processors (vCPUs),

memory, network, and, in some cases, instance storage and graphics
processing units (GPUs). When you create an EC2 instance, you need to
choose how much you need of each of these components.

[Link]
AWS offers a variety of instances that differ based on performance.
Some instances provide more capacity than others. To get an overview
of the capacity details for a particular instance, you should look at the
instance type. Instance types consist of a prefix identifying the type of
workloads they’re optimized for, followed by a size. For example, the
instance type [Link] can be broken down as follows:

c5 determines the instance family and generation number. Here, the

instance belongs to the fifth generation of instances in an instance
family that’s optimized for generic computation.
large determines the amount of instance capacity.
Instance families
In the example [Link], the first letter, c, stands for compute-
optimized. Compute optimized is one of the many instance families that
AWS offers. Each instance family is optimized to fit different use cases.
The following table describes instance families and some typical
workloads.

Instance Family Description Use Cases

General purpose Provides a balance of compute, memory, and
networking resources, and can be used for a variety of workloads. Scale
out workloads, such as web servers, containerized microservices,
caching fleets, distributed data stores, and development environments
Compute optimized Ideal for compute-bound applications that
benefit from high-performance processors. High-performance web
servers, scientific modeling, batch processing, distributed analytics,
high-performance computing (HPC), machine/deep learning, ad serving,
highly scalable multiplayer gaming
Memory optimized
Designed to deliver fast performance for workloads that process large
datasets in memory.
Memory-intensive applications, such as high-performance databases,
distributed web-scale in-memory caches, mid-size in-memory
databases, real-time big-data analytics, and other enterprise
applications
Accelerated computing
Use hardware accelerators or co-processors to perform functions such
as floating-point number calculations, graphics processing, or data
pattern matching more efficiently than is possible with conventional
CPUs.
3D visualizations, graphics-intensive remote workstations, 3D
rendering, application streaming, video encoding, and other server-side
graphics workloads
Storage optimized
Designed for workloads that require high, sequential read and write
access to large datasets on local storage. They are optimized to deliver
tens of thousands of low-latency random I/O operations per second
(IOPS) to applications that replicate their data across different
instances.
NoSQL databases, such as Cassandra, MongoDB, and Redis, in-memory
databases, scale-out transactional databases, data warehousing,
Elasticsearch, and analytics
EC2 instance locations

By default, your EC2 instances are placed in a network called the

default Amazon Virtual Private Cloud (Amazon VPC). This network was
created so that you can easily get started with Amazon EC2 without
learning how to create and configure a VPC.

Any resource you put inside the default VPC will be public and
accessible by the internet, so you shouldn’t place any customer data or
private information in it.
Once you get more comfortable with networking on AWS, you should
change this default setting to choose your own custom VPCs and
restrict access with additional routing and connectivity mechanisms.

Architect for high availability

In the network, your instance resides in an Availability Zone of your

choice. As you learned previously, AWS services that are scoped at the
Availability Zone level must be architected with high availability in
mind.

While EC2 instances are typically reliable, two is better than one, and
three is better than two. Specifying the instance size gives you an
advantage when designing your architecture because you can use more
smaller instances rather than a few larger ones.

If your front end only has a single instance and the instance fails, your
application goes down. On the other hand, if your workload is
distributed across 10 instances and one fails, you lose only 10 percent
of your fleet, and your application availability is hardly affected.

When architecting any application for high availability, consider using at

least two EC2 instances in two separate Availability Zones. --

EC2 instance lifecycle

An EC2 instance transitions between different states from the moment
you create it until it's termination.
1
When you launch an instance, it enters the pending state. When an
instance is pending, billing has not started. At this stage, the instance is
preparing to enter the running state. Pending is where AWS performs
all actions needed to set up an instance, such as copying the AMI
content to the root device and allocating the necessary networking
components.

2
When your instance is running, it's ready to use. This is also the stage
where billing begins. As soon as an instance is running, you can take
other actions on the instance, such as reboot, terminate, stop, and
stop-hibernate.

3
When you reboot an instance, it’s different than performing a stop
action and then a start action. Rebooting an instance is equivalent to
rebooting an operating system. The instance remains on the same host
computer, and maintains its public and private IP address, in addition to
any data on its instance store.
4
It typically takes a few minutes for the reboot to complete. When you
stop and start an instance, your instance may be placed on a new
underlying physical server. Therefore, you lose any data on the instance
store that were on the previous host computer. When you stop an
instance, the instance gets a new public IP address but maintains the
same private IP address.

5
When you terminate an instance, the instance stores are erased, and
you lose both the public IP address and private IP address of the
machine. Termination of an instance means that you can no longer
access the machine.

Difference between stop and stop-hibernate

When you stop an instance, it enters the stopping state until it reaches
the stopped state. AWS does not charge usage or data transfer fees for
your instance after you stop it, but storage for any Amazon EBS
volumes is still charged. While your instance is in the stopped state, you
can modify some attributes, like the instance type. When you stop your
instance, the data stored in memory (RAM) is lost.

When you stop-hibernate an instance, AWS signals the operating

system to perform hibernation (suspend-to-disk), which saves the
contents from the instance memory (RAM) to the Amazon EBS root
volume.
Consider a scenario where you build a standard three-tier application,
where you have web servers, application servers, and database servers.
Suddenly, the application you built becomes extremely popular. To
relieve some stress on the database that supports your application, you
want to implement a custom backend layer that caches database
information in memory (RAM). You decide to run this custom backend
caching solution on Amazon EC2.

In this scenario, the stop-hibernate feature would be instrumental in

persisting storage. It would prevent you from having to manually create
scripts to save the RAM data before shutting down the server.

Pricing

One of the ways to reduce costs with Amazon EC2 is to choose the right
pricing option for the way your applications run. AWS offers three main
purchasing options for EC2 instances – On-Demand, Reserved, and Spot
Instances.

Pay as you go with On-Demand Instances

With On-Demand Instances, you pay for compute capacity with no

long-term commitments. Billing begins whenever the instance is
running, and billing stops when the instance is in a stopped or
terminated state. The price per second for a running On-Demand
Instance is fixed.
For applications that require servers to be running all the time, you are
less likely to benefit from the On-Demand pricing model, simply
because there is no situation where you will need to turn servers off.
For example, you might want the web server hosting the front end of
your corporate directory application to be running 24/7 so that users
can access the website at any time. Even if no users are connected to
your website, you don’t want to shut down the servers supporting the
site in case of potential user activity.

In the case when servers cannot be stopped, consider using a Reserved

Instance to save on costs.

Reserve capacity with Reserved Instances (RIs)

RIs provide you with a significant discount compared to On-Demand

Instance pricing. RIs provide a discounted hourly rate and an optional
capacity reservation for EC2 instances. You can choose between three
payment options – All Upfront, Partial Upfront, or No Upfront. You can
select either a 1-year or 3-year term for each of these options.

Depending on which option you choose, you are discounted differently.

All Upfront offers a higher discount than Partial Upfront instances.

Partial Upfront instances offer a higher discount than No Upfront.
No Upfront offers a higher discount than On-Demand.
On-Demand and No Upfront are similar, since both do not require any
upfront payment. However, there is a major difference. When you
choose an On-Demand Instance, you stop paying for the instance when
you stop or terminate the instance. When you stop an RI, you still pay
for it because you committed to a 1-year or 3-year term.

Reserved Instances are associated with an instance type and an

Availability Zone depending on how you reserve it. The discount applied
by a Reserved Instance purchase is not directly associated with a
specific instance ID, but with an instance type.

Save on costs with Spot Instances

Another way to pay for EC2 instances is by using Spot Instances.

Amazon EC2 Spot Instances allow you to take advantage of unused EC2
capacity in the AWS Cloud. They are available at up to a 90% discount
compared to On-Demand prices.

With Spot Instances, you set a limit on how much you would like to pay
for the instance hour. This is compared against the current Spot price
that AWS determines. If the amount you pay is more than the current
Spot price and there is capacity, then you will receive an instance.
While they are very promising from the billing perspective, you must
account for some architectural considerations to use them effectively.
One consideration is that your Spot Instance might be interrupted. For
example, if AWS determines that capacity is no longer available for a
particular Spot Instance or if the Spot price exceeds how much you are
willing to pay, AWS will give you a 2-minute warning before it interrupts
your instance. That means any application or workload that runs on a
Spot Instance must be able to be interrupted.

Because of this unique consideration, inherently fault-tolerant

workloads are typically good candidates to use with Spot Instances.
These include big data, containerized workloads, continuous
integration/continuous delivery (CI/CD), web servers, high-performance
computing (HPC), image and media rendering, and other test and
development workloads.

Now that you know how to select an operating system for your EC2
instance, you are ready to choose other configurations to create your
EC2 instance, such as the instance type, network, and storage.

For an application like the employee directory application, you need

instances with enough capacity to run web servers and process
incoming customer requests. Your instance sizing will depend on both
the demands of your application and the anticipated size of your user
base.

Forecasting server capacity for an on-premises application requires

difficult decisions involving significant up-front capital spending, while
changes to the allocation of your cloud-based services can be made
with a simple API call. Because of the AWS pay-as-you-go model, you
can match your infrastructure capacity to your application’s demand,
instead of the other way around.

Amazon EC2 instance types

Amazon EC2 instances are a combination of virtual processors (vCPUs),

memory, network, and, in some cases, instance storage and graphics
processing units (GPUs). When you create an EC2 instance, you need to
choose how much you need of each of these components.

[Link]
AWS offers a variety of instances that differ based on performance.
Some instances provide more capacity than others. To get an overview
of the capacity details for a particular instance, you should look at the
instance type. Instance types consist of a prefix identifying the type of
workloads they’re optimized for, followed by a size. For example, the
instance type [Link] can be broken down as follows:

c5 determines the instance family and generation number. Here, the

instance belongs to the fifth generation of instances in an instance
family that’s optimized for generic computation.
large determines the amount of instance capacity.
Instance families
In the example [Link], the first letter, c, stands for compute-
optimized. Compute optimized is one of the many instance families that
AWS offers. Each instance family is optimized to fit different use cases.
The following table describes instance families and some typical
workloads.

Instance Family Description Use Cases

General purpose Provides a balance of compute, memory, and
networking resources, and can be used for a variety of workloads. Scale
out workloads, such as web servers, containerized microservices,
caching fleets, distributed data stores, and development environments
Compute optimized Ideal for compute-bound applications that
benefit from high-performance processors. High-performance web
servers, scientific modeling, batch processing, distributed analytics,
high-performance computing (HPC), machine/deep learning, ad serving,
highly scalable multiplayer gaming
Memory optimized
Designed to deliver fast performance for workloads that process large
datasets in memory.
Memory-intensive applications, such as high-performance databases,
distributed web-scale in-memory caches, mid-size in-memory
databases, real-time big-data analytics, and other enterprise
applications
Accelerated computing
Use hardware accelerators or co-processors to perform functions such
as floating-point number calculations, graphics processing, or data
pattern matching more efficiently than is possible with conventional
CPUs.
3D visualizations, graphics-intensive remote workstations, 3D
rendering, application streaming, video encoding, and other server-side
graphics workloads
Storage optimized
Designed for workloads that require high, sequential read and write
access to large datasets on local storage. They are optimized to deliver
tens of thousands of low-latency random I/O operations per second
(IOPS) to applications that replicate their data across different
instances.
NoSQL databases, such as Cassandra, MongoDB, and Redis, in-memory
databases, scale-out transactional databases, data warehousing,
Elasticsearch, and analytics
EC2 instance locations

By default, your EC2 instances are placed in a network called the

default Amazon Virtual Private Cloud (Amazon VPC). This network was
created so that you can easily get started with Amazon EC2 without
learning how to create and configure a VPC.

Any resource you put inside the default VPC will be public and
accessible by the internet, so you shouldn’t place any customer data or
private information in it.
Once you get more comfortable with networking on AWS, you should
change this default setting to choose your own custom VPCs and
restrict access with additional routing and connectivity mechanisms.

Architect for high availability

In the network, your instance resides in an Availability Zone of your

choice. As you learned previously, AWS services that are scoped at the
Availability Zone level must be architected with high availability in
mind.

While EC2 instances are typically reliable, two is better than one, and
three is better than two. Specifying the instance size gives you an
advantage when designing your architecture because you can use more
smaller instances rather than a few larger ones.

If your front end only has a single instance and the instance fails, your
application goes down. On the other hand, if your workload is
distributed across 10 instances and one fails, you lose only 10 percent
of your fleet, and your application availability is hardly affected.

When architecting any application for high availability, consider using at

least two EC2 instances in two separate Availability Zones. --

[Link]
EC2 instance lifecycle

An EC2 instance transitions between different states from the moment

you create it until it's termination.

[Link]
1

1
When you launch an instance, it enters the pending state. When an
instance is pending, billing has not started. At this stage, the instance is
preparing to enter the running state. Pending is where AWS performs
all actions needed to set up an instance, such as copying the AMI
content to the root device and allocating the necessary networking
components.

2
When your instance is running, it's ready to use. This is also the stage
where billing begins. As soon as an instance is running, you can take
other actions on the instance, such as reboot, terminate, stop, and
stop-hibernate.

3
3
When you reboot an instance, it’s different than performing a stop
action and then a start action. Rebooting an instance is equivalent to
rebooting an operating system. The instance remains on the same host
computer, and maintains its public and private IP address, in addition to
any data on its instance store.

4
It typically takes a few minutes for the reboot to complete. When you
stop and start an instance, your instance may be placed on a new
underlying physical server. Therefore, you lose any data on the instance
store that were on the previous host computer. When you stop an
instance, the instance gets a new public IP address but maintains the
same private IP address.

5
When you terminate an instance, the instance stores are erased, and
you lose both the public IP address and private IP address of the
machine. Termination of an instance means that you can no longer
access the machine.
Difference between stop and stop-hibernate

When you stop an instance, it enters the stopping state until it reaches
the stopped state. AWS does not charge usage or data transfer fees for
your instance after you stop it, but storage for any Amazon EBS
volumes is still charged. While your instance is in the stopped state, you
can modify some attributes, like the instance type. When you stop your
instance, the data stored in memory (RAM) is lost.

When you stop-hibernate an instance, AWS signals the operating

system to perform hibernation (suspend-to-disk), which saves the
contents from the instance memory (RAM) to the Amazon EBS root
volume.

Consider a scenario where you build a standard three-tier application,

where you have web servers, application servers, and database servers.
Suddenly, the application you built becomes extremely popular. To
relieve some stress on the database that supports your application, you
want to implement a custom backend layer that caches database
information in memory (RAM). You decide to run this custom backend
caching solution on Amazon EC2.

In this scenario, the stop-hibernate feature would be instrumental in

persisting storage. It would prevent you from having to manually create
scripts to save the RAM data before shutting down the server.
Pricing

One of the ways to reduce costs with Amazon EC2 is to choose the right
pricing option for the way your applications run. AWS offers three main
purchasing options for EC2 instances – On-Demand, Reserved, and Spot
Instances.

[Link]
Pay as you go with On-Demand Instances

With On-Demand Instances, you pay for compute capacity with no

long-term commitments. Billing begins whenever the instance is
running, and billing stops when the instance is in a stopped or
terminated state. The price per second for a running On-Demand
Instance is fixed.

For applications that require servers to be running all the time, you are
less likely to benefit from the On-Demand pricing model, simply
because there is no situation where you will need to turn servers off.
For example, you might want the web server hosting the front end of
your corporate directory application to be running 24/7 so that users
can access the website at any time. Even if no users are connected to
your website, you don’t want to shut down the servers supporting the
site in case of potential user activity.
In the case when servers cannot be stopped, consider using a Reserved
Instance to save on costs.

Reserve capacity with Reserved Instances (RIs)

RIs provide you with a significant discount compared to On-Demand

Instance pricing. RIs provide a discounted hourly rate and an optional
capacity reservation for EC2 instances. You can choose between three
payment options – All Upfront, Partial Upfront, or No Upfront. You can
select either a 1-year or 3-year term for each of these options.

Depending on which option you choose, you are discounted differently.

All Upfront offers a higher discount than Partial Upfront instances.

Partial Upfront instances offer a higher discount than No Upfront.
No Upfront offers a higher discount than On-Demand.
On-Demand and No Upfront are similar, since both do not require any
upfront payment. However, there is a major difference. When you
choose an On-Demand Instance, you stop paying for the instance when
you stop or terminate the instance. When you stop an RI, you still pay
for it because you committed to a 1-year or 3-year term.

Reserved Instances are associated with an instance type and an

Availability Zone depending on how you reserve it. The discount applied
by a Reserved Instance purchase is not directly associated with a
specific instance ID, but with an instance type.

Save on costs with Spot Instances

Another way to pay for EC2 instances is by using Spot Instances.

Amazon EC2 Spot Instances allow you to take advantage of unused EC2
capacity in the AWS Cloud. They are available at up to a 90% discount
compared to On-Demand prices.

With Spot Instances, you set a limit on how much you would like to pay
for the instance hour. This is compared against the current Spot price
that AWS determines. If the amount you pay is more than the current
Spot price and there is capacity, then you will receive an instance.
While they are very promising from the billing perspective, you must
account for some architectural considerations to use them effectively.

One consideration is that your Spot Instance might be interrupted. For

example, if AWS determines that capacity is no longer available for a
particular Spot Instance or if the Spot price exceeds how much you are
willing to pay, AWS will give you a 2-minute warning before it interrupts
your instance. That means any application or workload that runs on a
Spot Instance must be able to be interrupted.

Because of this unique consideration, inherently fault-tolerant

workloads are typically good candidates to use with Spot Instances.
These include big data, containerized workloads, continuous
integration/continuous delivery (CI/CD), web servers, high-performance
computing (HPC), image and media rendering, and other test and
development workloads.
Networking defined
Networking is how you connect computers around the world and allow
them to communicate with one another. In this course, you’ve already
seen a few examples of networking. One is the AWS Global
Infrastructure. AWS built a network of resources using data centers,
Availability Zones, and Regions.
Networking basics

One way to think about networking is to think about sending a letter.

When you send a letter, you provide the following three elements:

 The payload, or letter, inside the envelope.

 The address of the sender in the From section.
 The address of the recipient in the To section.

Each address must contain specific information, such as:

 Name of sender and recipient

 Street
 City
 State or province
 Zip, area, or postal code
 Country

You need all parts of an address to ensure that your letter gets to its
destination. Without the correct address, postal workers cannot properly
deliver the letter. In the digital world, computers handle the delivery of
messages in a similar way. This is called routing.
IP addresses
To properly route your messages to a location, you need an address. Just
like each home has a mailing address, each computer has an IP address.
However, instead of using the combination of street, city, state, zip code,
and country, the IP address uses a combination of bits, 0s and 1s.

Here is an example of a 32-bit address in binary format:

It’s called 32-bit because you have 32 digits. Feel free to count!
IPv4 notation
Typically, you don’t see an IP address in its binary format. Instead, it’s
converted into decimal format and noted as an Ipv4 address.

In the following diagram, the 32 bits are grouped into groups of 8 bits,
also called octets. Each of these groups is converted into decimal format
separated by a period.

In the end, this is what is called an Ipv4 address. This is important to

know when trying to communicate to a single computer. But remember,
you’re working with a network. This is where CIDR notation comes in.
CIDR notation
[Link] is a single IP address. If you want to express IP addresses
between the range of [Link] and [Link], how can you do
that?

One way is to use Classless Inter-Domain Routing (CIDR) notation.

CIDR notation is a compressed way of specifying a range of IP
addresses. Specifying a range determines how many IP addresses are
available to you.

CIDR notation is shown here.

It begins with a starting IP address and is separated by a forward slash
(the “/” character) followed by a number. The number at the end
specifies how many of the bits of the IP address are fixed. In this
example, the first 24 bits of the IP address are fixed. The rest are
flexible.

32 total bits subtracted by 24 fixed bits leaves 8 flexible bits. Each of

these flexible bits can be either 0 or 1, because they are binary. That
means that you have two choices for each of the 8 bits, providing 256 IP
addresses in that IP range.

The higher the number after the /, the smaller the number of IP addresses
in your network. For example, a range of [Link]/24 is smaller than
[Link]/16.

When working with networks in the AWS Cloud, you choose your
network size by using CIDR notation. In AWS, the smallest IP range
you can have is /28, which provides 16 IP addresses. The largest IP
range you can have is a /16, which provides 65,536 IP addresses.
Amazon VPC

A virtual private cloud (VPC) is an isolated network that you create in

the AWS Cloud, similar to a traditional network in a data center. When
you create a VPC, you must choose three main factors:

Name of the VPC.

Region where the VPC will live. Each VPC spans multiple Availability
Zones within the selected Region.
IP range for the VPC in CIDR notation. This determines the size of your
network. Each VPC can have up to four /16 IP ranges.
Using this information, AWS will provision a network and IP addresses
for that network.

High availability with a VPC

When you create your subnets, keep high availability in mind. To
maintain redundancy and fault tolerance, create at least two subnets
configured in two Availability Zones.

As you learned earlier, remember that “everything fails all of the time.”
With the example network, if one of the AZs fails, you will still have
your resources available in another AZ as backup.

Reserved IPs
For AWS to configure your VPC appropriately, AWS reserves five IP
addresses in each subnet. These IP addresses are used for routing,
Domain Name System (DNS), and network management.

For example, consider a VPC with the IP range [Link]/22. The VPC
includes 1,024 total IP addresses. This is divided into four equal-sized
subnets, each with a /24 IP range with 256 IP addresses. Out of each of
those IP ranges, there are only 251 IP addresses that can be used
because AWS reserves five.
Gateways

Internet gateway
To enable internet connectivity for your VPC, you must create an
internet gateway. Think of the gateway as similar to a modem. Just as a
modem connects your computer to the internet, the internet gateway
connects your VPC to the internet. Unlike your modem at home, which
sometimes goes down or offline, an internet gateway is highly available
and scalable. After you create an internet gateway, you attach it to your
VPC.

Virtual private gateway

A virtual private gateway connects your AWS VPC to another private
network. Once you create and attach a virtual private gateway to a VPC,
the gateway acts as anchor on the AWS side of the connection. On the
other side of the connection, you will need to connect a customer
gateway to the other private network. A customer gateway device is a
physical device or software application on your side of the connection.
Once you have both gateways, you can then establish an encrypted VPN
connection between the two sides.
Amazon EC2 instance store
Amazon EC2 instance store provides temporary block-level storage for
an instance. This storage is located on disks that are physically attached
to the host computer. This ties the lifecycle of the data to the lifecycle of
the EC2 instance. If you delete the instance, the instance store is deleted,
as well. Due to this, instance store is considered ephemeral storage.
Read more about it in the AWS documentation.

Instance store is ideal if you host applications that replicate data to other
EC2 instances, such as Hadoop clusters. For these cluster-based
workloads, having the speed of locally attached volumes and the
resiliency of replicated data helps you achieve data distribution at high
performance. It’s also ideal for temporary storage of information that
changes frequently, such as buffers, caches, scratch data, and other
temporary content.
Amazon Elastic Block Storage (Amazon EBS)
As the name implies, Amazon EBS is a block-level storage device that
you can attach to an Amazon EC2 instance. These storage devices are
called Amazon EBS volumes. EBS volumes are essentially drives of a
user-configured size attached to an EC2 instance, similar to how you
might attach an external drive to your laptop. EBS volumes act similarly
to external drives in more than one way.

 Most Amazon EBS volumes can only be connected with

one computer at a time. Most EBS volumes have a one-
to-one relationship with EC2 instances, so they cannot be
shared by or attached to multiple instances at one time.
(Recently, AWS announced the Amazon EBS multi-
attach feature that enables volumes to be attached to
multiple EC2 instances at one time. This feature is not
available for all instance types, and all instances must be
in the same Availability Zone. Read more about this
scenario in the EBS documentation.)
  You can detach an EBS volume from one EC2 instance
and attach it to another EC2 instance in the same
Availability Zone, to access the data on it.
 The external drive is separate from the computer. That
means, if an accident occurs and the computer goes
down, you still have your data on your external drive. The
same is true for EBS volumes.
 You’re limited to the size of the external drive, since it
has a fixed limit to how scalable it can be. For example,
you might have a 2-TB external drive, which means you
can only have 2 TB of content on it. This relates to EBS
as well, since a volume also has a max limitation of how
much content you can store on it.

Scale Amazon EBS volumes

You can scale Amazon EBS volumes in two ways.

 Increase the volume size, as long as it doesn’t increase

above the maximum size limit. For EBS volumes, the
maximum amount of storage you can have is 16 TB. If
you provision a 5-TB EBS volume, you can choose to
increase the size of your volume until you get to 16 TB.
 Attach multiple volumes to a single Amazon EC2
instance. EC2 has a one-to-many relationship with EBS
volumes. You can add these additional volumes during or
after EC2 instance creation to provide more storage
capacity for your hosts.

Amazon EBS use cases

Amazon EBS is useful when you must retrieve data quickly and have
data persist long-term. Volumes are commonly used in the following
scenarios.
  Operating systems: Boot/root volumes to store an
operating system. The root device for an instance
launched from an Amazon Machine Image (AMI) is
typically an Amazon EBS volume. These are commonly
referred to as EBS-backed AMIs.
 Databases: A storage layer for databases running on
Amazon EC2 that rely on transactional reads and writes.
 Enterprise applications: Amazon EBS provides reliable
block storage to run business-critical applications.
 Throughput-intensive applications: Applications that
perform long, continuous reads and writes.

Amazon EBS volume types

Amazon EBS volumes are organized into two main categories – solid-
state drives (SSDs) and hard-disk drives (HDDs). SSDs provide strong
performance for random input/output (I/O), while HDDs provide strong
performance for sequential I/O. AWS offers two types of each.

The following chart can help you decide which EBS volume is the right
option for your workload.

Amazon EC2 instance store

Amazon EC2 instance store provides temporary block-level storage for

an instance. This storage is located on disks that are physically attached
to the host computer. This ties the lifecycle of the data to the lifecycle
of the EC2 instance. If you delete the instance, the instance store is
deleted, as well. Due to this, instance store is considered ephemeral
storage. Read more about it in the AWS documentation.
Instance store is ideal if you host applications that replicate data to
other EC2 instances, such as Hadoop clusters. For these cluster-based
workloads, having the speed of locally attached volumes and the
resiliency of replicated data helps you achieve data distribution at high
performance. It’s also ideal for temporary storage of information that
changes frequently, such as buffers, caches, scratch data, and other
temporary content.

Amazon Elastic Block Storage (Amazon EBS)

As the name implies, Amazon EBS is a block-level storage device that

you can attach to an Amazon EC2 instance. These storage devices are
called Amazon EBS volumes. EBS volumes are essentially drives of a
user-configured size attached to an EC2 instance, similar to how you
might attach an external drive to your laptop. EBS volumes act similarly
to external drives in more than one way.

Most Amazon EBS volumes can only be connected with one computer
at a time. Most EBS volumes have a one-to-one relationship with EC2
instances, so they cannot be shared by or attached to multiple
instances at one time. (Recently, AWS announced the Amazon EBS
multi-attach feature that enables volumes to be attached to multiple
EC2 instances at one time. This feature is not available for all instance
types, and all instances must be in the same Availability Zone. Read
more about this scenario in the EBS documentation.)
You can detach an EBS volume from one EC2 instance and attach it to
another EC2 instance in the same Availability Zone, to access the data
on it.
The external drive is separate from the computer. That means, if an
accident occurs and the computer goes down, you still have your data
on your external drive. The same is true for EBS volumes.
You’re limited to the size of the external drive, since it has a fixed limit
to how scalable it can be. For example, you might have a 2-TB external
drive, which means you can only have 2 TB of content on it. This relates
to EBS as well, since a volume also has a max limitation of how much
content you can store on it.
Scale Amazon EBS volumes

You can scale Amazon EBS volumes in two ways.

Increase the volume size, as long as it doesn’t increase above the

maximum size limit. For EBS volumes, the maximum amount of storage
you can have is 16 TB. If you provision a 5-TB EBS volume, you can
choose to increase the size of your volume until you get to 16 TB.
Attach multiple volumes to a single Amazon EC2 instance. EC2 has a
one-to-many relationship with EBS volumes. You can add these
additional volumes during or after EC2 instance creation to provide
more storage capacity for your hosts.
Amazon EBS use cases
Amazon EBS is useful when you must retrieve data quickly and have
data persist long-term. Volumes are commonly used in the following
scenarios.

Operating systems: Boot/root volumes to store an operating system.

The root device for an instance launched from an Amazon Machine
Image (AMI) is typically an Amazon EBS volume. These are commonly
referred to as EBS-backed AMIs.
Databases: A storage layer for databases running on Amazon EC2 that
rely on transactional reads and writes.
Enterprise applications: Amazon EBS provides reliable block storage to
run business-critical applications.
Throughput-intensive applications: Applications that perform long,
continuous reads and writes.
Amazon EBS volume types

Amazon EBS volumes are organized into two main categories – solid-
state drives (SSDs) and hard-disk drives (HDDs). SSDs provide strong
performance for random input/output (I/O), while HDDs provide strong
performance for sequential I/O. AWS offers two types of each.

The following chart can help you decide which EBS volume is the right
option for your workload.

Amazon EC2 instance store

Instance store is ephemeral block storage. This is preconfigured storage
that exists on the same physical server that hosts the EC2 instance and
cannot be detached from Amazon EC2. You can think of it as a built-in
drive for your EC2 instance.

Instance store is generally well-suited for temporary storage of

information that is constantly changing, such as buffers, caches, and
scratch data. It is not meant for data that is persistent or long-lasting. If
you need persistent long-term block storage that can be detached from
Amazon EC2 and provide you more management flexibility, such as
increasing volume size or creating snapshots, then you should use
Amazon EBS.

Amazon EBS

Amazon EBS is meant for data that changes frequently and needs to
persist through instance stops, terminations, or hardware failures.
Amazon EBS has two types of volumes – SSD-backed volumes and HDD-
backed volumes.

SSD-backed volumes have the following characteristics:

Performance depends on IOPS (input/output operations per second).

Ideal for transactional workloads, such as databases and boot volumes.
HDD-backed volumes have the following characteristics:
Performance depends on MB/s.
Ideal for throughput-intensive workloads, such as big data, data
warehouses, log processing, and sequential data I/O.
Here are a few important features of Amazon EBS that you need to
know when comparing it to other services.

It is block storage.
You pay for what you provision (you have to provision storage in
advance).
EBS volumes are replicated across multiple servers in a single
Availability Zone.
Most EBS volumes can only be attached to a single EC2 instance at a
time.
Amazon S3

If your data doesn’t change that often, Amazon S3 might be a cost-

effective and scalable storage solution for you. Amazon S3 is ideal for
storing static web content and media, backups and archiving, and data
for analytics. It can also host entire static websites with custom domain
names.

Here are a few important features of Amazon S3 to know about when

comparing it to other services:
It is object storage.
You pay for what you use (you don’t have to provision storage in
advance).
Amazon S3 replicates your objects across multiple Availability Zones in
a Region.
Amazon S3 is not storage attached to compute.
Amazon Elastic File System (Amazon EFS) and Amazon FSx

In this module, you’ve already learned about Amazon S3 and Amazon

EBS. You learned that S3 uses a flat namespace and isn’t meant to serve
as a standalone file system. You also learned most EBS volumes can
only be attached to one EC2 instance at a time. So, if you need file
storage on AWS, which service should you use?

For file storage that can mount on to multiple EC2 instances, you can
use Amazon Elastic File System (Amazon EFS) or Amazon FSx. The
following table provides more information about each service.

Application Management
When operating a website like the Employee Directory Application on
AWS, you might have questions like:

How many people are visiting my site day to day?

How can I track the number of visitors over time?
How will I know if the website is having performance or availability
issues?
What happens if my Amazon Elastic Compute Cloud (EC2) instance runs
out of capacity?
Will I be alerted if my website goes down?
You need a way to collect and analyze data about the operational
health and usage of your resources. The act of collecting, analyzing, and
using data to make decisions or answer questions about your IT
resources and systems is called monitoring.

Monitoring provides a near real-time pulse on your system and helps

answer the questions listed above. You can use the data you collect to
watch for operational issues caused by events like overuse of resources,
application flaws, resource misconfiguration, or security-related events.

Think of the data collected through monitoring as outputs of the

system, or metrics.

Use metrics to solve problems

The AWS resources that host your solutions create various forms of
data that you might be interested in collecting. Each individual data
point that a resource creates is a metric. Metrics that are collected and
analyzed over time become statistics, such as average CPU utilization
over time showing a spike.
One way to evaluate the health of an Amazon EC2 instance is through
CPU utilization. Generally speaking, if an EC2 instance has a high CPU
utilization, it can mean a flood of requests. Or, it can reflect a process
that has encountered an error and is consuming too much of the CPU.
When analyzing CPU utilization, take a process that exceeds a specific
threshold for an unusual length of time. Use that abnormal event as a
cue to either manually or automatically resolve the issue through
actions like scaling the instance.

This is one example of a metric. Other examples of metrics EC2

instances have are network utilization, disk performance, memory
utilization, and the logs created by the applications running on top of
Amazon EC2.

Types of metrics

Different resources in AWS create different types of metrics. An

Amazon Simple Storage Service (Amazon S3) bucket would not have
CPU utilization like an EC2 instance does. Instead, Amazon S3 creates
metrics related to the objects stored in a bucket, like the overall size or
the number of objects in a bucket. Amazon S3 also has metrics related
to the requests made to the bucket, such as reading or writing objects.

Amazon Relational Database Service (Amazon RDS) creates metrics

such as database connections, CPU utilization of an instance, or disk
space consumption. This is not a complete list for any of the services
mentioned, but you can see how different resources create different
metrics.

You could be interested in a wide variety of metrics depending on your

resources, goals, and questions.

Monitoring benefits

Monitoring gives you visibility into your resources, but the question
now is, "Why is that important?" This section describes some of the
benefits of monitoring.

Respond to operational issues proactively before your end users are

aware of them. Waiting for end users to let you know when your
application is experiencing an outage is a bad practice. Through
monitoring, you can keep tabs on metrics like error response rate and
request latency. Over time, the metrics help signal when an outage is
going to occur. This enables you to automatically or manually perform
actions to prevent the outage from happening, and fix the problem
before your end users are aware of it.

Improve the performance and reliability of your resources. Monitoring

the various resources that comprise your application provides you with
a full picture of how your solution behaves as a system. Monitoring, if
done well, can illuminate bottlenecks and inefficient architectures. This
helps you drive performance and improve reliability.
Recognize security threats and events. When you monitor resources,
events, and systems over time, you create what is called a baseline. A
baseline defines what activity is normal. Using a baseline, you can spot
anomalies like unusual traffic spikes or unusual IP addresses accessing
your resources. When an anomaly occurs, an alert can be sent out or an
action can be taken to investigate the event.

Make data-driven decisions for your business. Monitoring keeps an eye

on IT operational health and drives business decisions. For example,
suppose you launched a new feature for your cat photo app and now
you want to know if it’s being used. You can collect application-level
metrics and view the number of users who use the new feature. With
your findings, you can decide whether to invest more time into
improving the new feature.

Create more cost-effective solutions. Through monitoring, you can view

resources that are being underused and rightsize your resources to
your usage. This helps you optimize cost and make sure you aren’t
spending more money than necessary.

Visibility

AWS resources create data that you can monitor through metrics, logs,
network traffic, events, and more. This data comes from components
that are distributed in nature, which can lead to difficulty in collecting
the data you need if you don’t have a centralized place to review it all.
AWS has done that for you with a service called Amazon CloudWatch.

Amazon CloudWatch is a monitoring and observability service that

collects data like those mentioned in this module. CloudWatch provides
actionable insights into your applications, and enables you to respond
to system-wide performance changes, optimize resource usage, and get
a unified view of operational health.

You can use CloudWatch to:

Detect anomalous behavior in your environments

Set alarms to alert you when something is not right
Visualize logs and metrics with the AWS Management Console
Take automated actions like scaling
Troubleshoot issues
Discover insights to keep your applications healthy
Capacity issues

Availability and reachability is improved by adding one more server.

However, the entire system can again become unavailable if there is a
capacity issue. This section looks at load issue for both types of systems
discussed – active-passive and active-active.
Vertical scaling

If too many requests are sent to a single active-passive system, the

active server will become unavailable and hopefully failover to the
passive server. But this doesn’t solve anything.

With active-passive, you need vertical scaling. This means increasing

the size of the server. With EC2 instances, you select either a larger
type or a different instance type. This can only be done while the
instance is in a stopped state.

In this scenario, the following steps occur:

Stop the passive instance. This doesn’t impact the application because
it’s not taking any traffic.
Change the instance size or type, and then start the instance again.
Shift the traffic to the passive instance, turning it active.
Stop, change the size, and start the previous active instance since both
instances should match.
When the number of requests reduces, the same operation must be
done. Even though there aren’t that many steps involved, it’s actually a
lot of manual work. Another disadvantage is that a server can only scale
vertically up to a certain limit. When that limit is reached, the only
option is to create another active-passive system and split the requests
and functionalities across them. This could require massive application
rewriting.
This is where the active-active system can help. When there are too
many requests, this system can be scaled horizontally by adding more
servers.

Horizontal scaling

As mentioned, for the application to work in an active-active system,

it’s already created as stateless, not storing any client sessions on the
server. This means that having two servers or having four wouldn’t
require any application changes. It would only be a matter of creating
more instances when required and shutting them down when traffic
decreases. The Amazon EC2 Auto Scaling service can take care of that
task by automatically creating and removing EC2 instances based on
metrics from Amazon CloudWatch.

You can see that there are many more advantages to using an active-
active system in comparison with an active-passive. Modifying your
application to become stateless enables scalability.

ELB with EC2 Auto Scaling

The ELB service integrates seamlessly with EC2 Auto Scaling. As soon as
a new EC2 instance is added to or removed from the EC2 Auto Scaling
group, ELB is notified. However, before it can send traffic to a new EC2
instance, it needs to validate that the application running on the EC2
instance is available.

This validation is done by way of the ELB health checks feature.

Monitoring is an important part of load balancers, because they should
route traffic to only healthy EC2 instances. That’s why ELB supports two
types of health checks.

Establishing a connection to a backend EC2 instance using TCP, and

marking the instance as available if the connection is successful.
Making an HTTP or HTTPS request to a webpage that you specify, and
validating that an HTTP response code is returned.
Traditional scaling versus auto scaling

With a traditional approach to scaling, you buy and provision enough

servers to handle traffic at its peak. However, this means that at night
time, for example, you might have more capacity than traffic, which
means you’re wasting money. Turning off your servers at night or at
times where the traffic is lower only saves on electricity.

The cloud works differently with a pay-as-you-go model. You must turn
off the unused services, especially EC2 instances that you pay for on-
demand. You could manually add and remove servers at a predicted
time. But with unusual spikes in traffic, this solution leads to a waste of
resources with over-provisioning or a loss of customers due to under-
provisioning.
The need here is for a tool that automatically adds and removes EC2
instances according to conditions you define – that’s exactly what the
EC2 Auto Scaling service does.

Amazon EC2 Auto Scaling

The Amazon EC2 Auto Scaling service adds and removes capacity to
keep a steady and predictable performance at the lowest possible cost.
By adjusting the capacity to exactly what your application uses, you
only pay for what your application needs. And even with applications
that have steady usage, EC2 Auto Scaling can help with fleet
management. If an EC2 instance has an issue, EC2 Auto Scaling can
automatically replace the instance. This means that EC2 Auto Scaling
helps both to scale your infrastructure and ensure high availability.

Configure EC2 Auto Scaling components

Three main components of EC2 Auto Scaling are as follows:

Launch template or configuration: What resource should be

automatically scaled?
EC2 Auto Scaling Group: Where should the resources be deployed?
Scaling policies: When should the resources be added or removed?
Launch templates
Multiple parameters are required to create EC2 instances – Amazon
Machine Image (AMI) ID, instance type, security group, additional
Amazon Elastic Block Store (EBS) volumes, and more. All this
information is also required by EC2 Auto Scaling to create the EC2
instance on your behalf when there is a need to scale. This information
is stored in a launch template.

You can use a launch template to manually launch an EC2 instance. You
can also use it with EC2 Auto Scaling. It also supports versioning, which
allows for quickly rolling back if there's an issue or a need to specify a
default version. This way, while iterating on a new version, other users
can continue launching EC2 instances using the default version until
you make the necessary changes.

[Link]
You can create a launch template in one of three ways.

The fastest way to create a template is to use an existing EC2 instance.

All the settings are already defined.
Another option is to create one from an already existing template or a
previous version of a launch template.
The last option is to create a template from scratch. The following
options will need to be defined: AMI ID, instance type, key pair, security
group, storage, and resource tags.
Another way to define what Amazon EC2 Auto Scaling needs to scale is
by using a launch configuration. It’s similar to the launch template, but
it doesn’t allow for versioning using a previously created launch
configuration as a template. Nor does it allow for creating one from an
already existing EC2 instance. For these reasons and to ensure that
you’re getting the latest features from Amazon EC2, AWS recommends
that you use a launch template instead of a launch configuration.

EC2 Auto Scaling groups

The next component that EC2 Auto Scaling needs is an EC2 Auto Scaling
Group. An auto scaling group helps you define where EC2 Auto Scaling
deploys your resources. This is where you specify the Amazon VPC and
subnets the EC2 instance should be launched in. EC2 Auto Scaling takes
care of creating the EC2 instances across the subnets, so select at least
two subnets that are across different Availability Zones.

With Auto Scaling groups, you can specify the type of purchase for the
EC2 instances. You can use On-Demand only, Spot only, or a
combination of the two, which allows you to take advantage of Spot
instances with minimal administrative overhead.

To specify how many instances EC2 Auto Scaling should launch, you
have three capacity settings to configure for the group size.
Minimum: The minimum number of instances running in your Auto
Scaling group, even if the threshold for lowering the amount of
instances is reached.
Maximum: The maximum number of instances running in your Auto
Scaling group, even if the threshold for adding new instances is
reached.
Desired capacity: The amount of instances that should be in your Auto
Scaling group. This number can only be within or equal to the minimum
or maximum. EC2 Auto Scaling automatically adds or removes instances
to match the desired capacity number.
THE END.