AWS offers a massive range of services for every business, starting with basic

elements, like compute, storage, and network security tools, through complex
solutions like blockchain, machine learning, or artificial intelligence, and robot
development platforms, all the way through very specialized tool sets, like video
production management systems, and orbital satellites you can rent by the
minute.

All that, however, is way more than we have time to cover in a foundational class
like this one. So, let's simplify the conversation by starting with the fundamental
cloud compute model.

Almost all modern computing centres around a basic client-server model. Now I
know it can be more complicated than that, so let's take a look at our coffee
shop.

This coffee shop is going to give us some real-world metaphors to help you
understand why AWS can change the way your IT operates.

Let's make Morgan the server, the barista. And I am the client, the customer. I
make a request. In this case, it is for coffee. Now in the computing world, the
request could be anything. It could be rain pattern analysis in South Africa, or the
latest x-rays of your knee, or videos of kittens. Whatever is the business,
basically a customer makes a request, and with permissions, the server responds
to that request. All I want is a caffeinated beverage.

Morgan represents the server part of the client-server model. In AWS, she would
be called an Amazon Elastic Compute Cloud, or EC2, an EC2 instance, a virtual
server. So, from an architectural point of view, the transaction we did is really
simple to explain. I, the user, made a request to Morgan, the server. Morgan
validated that the request was legitimate, in this case, did I give her money?
Then she returned a response, which in this case, is a berry blaster with extra
caramel shots.

Now in the real world, applications can get more complicated than just a single
transaction with a single server. In a business solution that is more mature, it can
get beautifully complex.

To avoid this complexity, we're going to start simple. We will build this discussion
out so that it is easy for anyone to understand how these concepts build on each
other. So, by the end, those complex concepts, they'll be easy to understand.
Let's start with a key concept to AWS, and that is, you only pay for what you use.

This principle makes sense when you run a coffee shop. Employees are only paid
when they're in the store working. If Rudy and Morgan are off the clock, well
then, they don't get paid. The store owner simply decides how many baristas are
needed and then just pays for the hours they work. For example, the coffee shop
is about to release a new drink, the Pumpkin Monster Spice. In anticipation of this
launch, you could always staff your shop with a dozen baristas all day long, just
in case you suddenly get an unexpected rush at some point in the day. Only, let's
be honest. For most of your day, you don't have near enough customers to justify
paying for all those employees.

And yet, the is exactly what happens in an on-premises data centre. You can't
just snap your fingers and triple your capacity. At AWS, you don't pre-pay for
anything. And you don't have to worry about capacity constraints.

When you need instances, or baristas, you just click a button, and you have
them. And when you don't need them, another click, and they go away, and you
stop paying for them. The same way you don't pay for employees for hours that
they're not working.

So, pay for what you need, becomes the first key value of many for running your
business on AWS. And that is really why we're here, to help you understand how
AWS is built to help you run your business better.

We hope you stick around for the entire course, as we dive deeper into these
concepts, and help launch you on your journey to being a Cloud Practitioner.

What is a client-server model?

You just learned more about AWS and how almost all of modern computing uses
a basic client-server model. Let’s recap what a client-server model is.

In computing, a client can be a web browser or desktop application that a

person interacts with to make requests to computer servers. A server can be
services, such as Amazon Elastic Compute Cloud (Amazon EC2) – a type of
virtual server.
For example, suppose that a client makes a request for a news article, the score
in an online game, or a funny video. The server evaluates the details of this
request and fulfils it by returning the information to the client.

Cloud Computing

Before we get deeper into the pieces and parts of AWS, let's zoom out and get a
good working definition of cloud. Cloud computing is the on-demand delivery of
IT resources over the internet with pay-as-you-go pricing. Let's break this down.
On-demand delivery indicates that AWS has the resources you need, when you
need them. You don't need to tell us in advance that you're going to need them.
Suddenly you find yourself needing 300 virtual servers. Well, just a few clicks and
launch them. Or you need 2000 terabytes of storage. You don't have to tell us in
advance, just start using the storage you need, when you need it. Don't need
them anymore, just as quickly, you can return them and stop paying
immediately. That kind of flexibility is just not possible when you're managing
your own data canters.

The idea of IT resources is actually a big part of the AWS philosophy. We often get
asked why AWS has so many products and the answer is really simple: Because
businesses need them. If there are IT elements that are common across a
number of businesses, then this is not a differentiator.

Take a MySQL database as an example. If your business runs a MySQL database,

does your ability to install the MySQL engine make you a better company than
your competitors? Well, probably not that. Do you keep backups in a way that
makes you superior to other players in your vertical? Again, doubtful. The data
inside your database, now that's critically different. The way you build your
tables and manage the structures, absolutely separates you from the
competition. But the engine is just the engine.

At AWS, we call that the undifferentiated heavy lifting of IT. Tasks that are
common, often repetitive and ultimately time-consuming; these are the tasks
AWS wants to help you with. So, you can focus on what makes you unique. Over
the internet, seems simple enough, but it implies that you can access those
resources using a secure webpage console or programmatically.

No additional contracts or sales calls are needed. With pay-as-you-go pricing, we

re-emphasize what we pointed out here in the coffee shop. You don't staff a shop
with employees 24 hours a day at the same levels you do during peak hours. In
fact, some hours, you might not even staff them at all. So why pay for developer
environments, for example, on weekends, if your developers aren't working on
the weekends?

Deployment models for cloud computing

When selecting a cloud strategy, a company must consider factors such as
required cloud application components, preferred resource management tools,
and any legacy IT infrastructure requirements.
The three cloud computing deployment models are cloud-based, on-premises,
and hybrid.
To learn more about deployment models
Hybrid deployment
 Connect cloud-based resources to on-premises infrastructure.
 Integrate cloud-based resources with legacy IT applications.
In a hybrid deployment,
cloud-based resources are connected to on-premises infrastructure. You might
want to use this approach in a number of situations. For example, you have
legacy applications that are better maintained on premises, or government
regulations require your business to keep certain records on premises.

For example, suppose that a company wants to use cloud services that can
automate batch data processing and analytics. However, the company has
several legacy applications that are more suitable on premises and will not be
migrated to the cloud. With a hybrid deployment, the company would be able to
keep the legacy applications on premises while benefiting from the data and
analytics services that run in the cloud.
Cloud-based deployment

 Run all parts of the application in the cloud.

 Migrate existing applications to the cloud.
 Design and build new applications in the cloud.
In a cloud-based deployment model, you can migrate existing applications to
the cloud, or you can design and build new applications in the cloud. You can
build those applications on low-level infrastructure that requires your IT staff to
manage them. Alternatively, you can build them using higher-level services that
reduce the management, architecting, and scaling requirements of the core
infrastructure.

For example, a company might create an application consisting of virtual servers,

databases, and networking components that are fully based in the cloud.

On-premises deployment

 Deploy resources by using virtualization and resource management tools.

 Increase resource utilization by using application management and
virtualization technologies.
On-premises deployment is also known as a private cloud deployment. In this
model, resources are deployed on premises by using virtualization and resource
management tools.

For example, you might have applications that run on technology that is fully
kept in your on-premises data centre. Though this model is much like legacy IT
infrastructure, its incorporation of application management and virtualization
technologies helps to increase resource utilization.

Benefits of cloud computing

Consider why a company might choose to take a particular cloud computing
approach when addressing business needs.
To learn more about the benefits, expand each for the following six categories.

Trade upfront expense for variable expense

Upfront expense refers to data centres, physical servers, and other resources
that you would need to invest in before using them. Variable expense means you
only pay for computing resources you consume instead of investing heavily in
data centres and servers before you know how you’re going to use them.

By taking a cloud computing approach that offers the benefit of variable

expense, companies can implement innovative solutions while saving on costs.

Stop spending money to run and maintain data centres

Computing in data centres often requires you to spend more money and time
managing infrastructure and servers.

A benefit of cloud computing is the ability to focus less on these tasks and more
on your applications and customers.
Stop guessing capacity
With cloud computing, you don’t have to predict how much infrastructure
capacity you will need before deploying an application.
For example, you can launch Amazon EC2 instances when needed and pay only
for the compute time you use. Instead of paying for unused resources or having
to deal with limited capacity, you can access only the capacity that you need.
You can also scale in or scale out in response to demand.

Benefit from massive economies of scale

By using cloud computing, you can achieve a lower variable cost than you can
get on your own.

Because usage from hundreds of thousands of customers can aggregate in the

cloud, providers, such as AWS, can achieve higher economies of scale. The
economy of scale translates into lower pay-as-you-go prices.
Increase speed and agility
The flexibility of cloud computing makes it easier for you to develop and deploy
applications.

This flexibility provides you with more time to experiment and innovate. When
computing in data centres, it may take weeks to obtain new resources that you
need. By comparison, cloud computing enables you to access new resources
within minutes.

Go global in minutes
The global footprint of the AWS Cloud enables you to deploy applications to
customers around the world quickly, while providing them with low latency. This
means that even if you are located in a different part of the world than your
customers, customers are able to access your applications with minimal delays.

Later in this course, you will explore the AWS global infrastructure in greater
detail. You will examine some of the services that you can use to deliver content
to customers around the world.

Module 2 Introduction
Learning objectives
In this module, you will learn how to:
 Describe the benefits of Amazon EC2 at a basic level.
 Identify the different Amazon EC2 instance types.
 Differentiate between the various billing options for Amazon EC2.
 Summarize the benefits of Amazon EC2 Auto Scaling.
 Summarize the benefits of Elastic Load Balancing.
 Give an example of the uses for Elastic Load Balancing.
 Summarize the differences between Amazon Simple Notification Service
(Amazon SNS) and Amazon Simple Queue Service (Amazon SQS).
 Summarize additional AWS compute options.

we are going to talk at a high level about a service called Amazon Elastic
Compute Cloud or EC2. If you remember from our coffee shop, the employees
are a metaphor for the client/server model where a client sends a request to the
server; the server does some work, and then sends a response. That example is
for the coffee shop. But the same idea applies to other businesses. Your
business, whether it be in healthcare, manufacturing, insurance, or delivering
video content to millions of users all around the world, are also using this model
to deliver products, resources, or data to your end users. And you're going to
need servers to power your business and your applications. You need raw
compute capacity to host your applications and provide the compute power that
your business needs. When you're working with AWS, those servers are virtual.
And the service you use to gain access to virtual servers is called EC2.

Using EC2 for compute is highly flexible, cost effective, and quick when you
compare it to running your own servers on premises in a data center that you
own. The time and money it takes to get up and running with on-premises
resources is fairly high. When you own your own fleet of physical servers, you
first have to do a bunch of research to see what type of servers you want to buy
and how many you'll need. Then you purchase that hardware up front. You'll wait
for multiple weeks or months for a vendor to deliver those servers to you. You
then take them to a data center that you own or rent to install them, rack and
stack them, and wire them all up. Then you make sure that they are secure and
powered up and then they're ready to be used. Only then can you begin to host
your applications on top of these servers. The worst part is, once you buy these
servers you are stuck with them whether you use them or not.

With EC2, it's much easier to get started. AWS took care of the hard part for you
already. AWS already built and secured the data centres. AWS has already bought
the servers, racked and stacked them, and they are already online ready to be
used. AWS is constantly operating a massive amount of compute capacity. And
you can use whatever portion of that capacity when you need it. All you have to
do is request the EC2 instances you want, and they will launch and boot up,
ready to be used within a few minutes. Once you're done, you can easily stop or
terminate the EC2 instances. You're not locked in or stuck with servers that you
don't need or want. Your usage of EC2 instances can vary greatly over time. And
you only pay for what you use. Because with EC2, you only pay for running
instances, not stopped or terminated instances.

EC2 runs on top of physical host machines managed by AWS using virtualization
technology. When you spin up an EC2 instance, you aren't necessarily taking an
entire host to yourself. Instead, you are sharing the host with multiple other
instances, otherwise known as virtual machines. And a hypervisor running on the
host machine is responsible for sharing the underlying physical resources
between the virtual machines. This idea of sharing underlying hardware is called
multitenancy. The hypervisor is responsible for coordinating this multitenancy
and it is managed by AWS. The hypervisor is responsible for isolating the virtual
machines from each other as they share resources from the host. This means
EC2 instances are secure. Even though they may be sharing resources, one EC2
instance is not aware of any other EC2 instances also on that host. They are
secure and separate from each other.

Luckily, this is not something you, yourself, need to set up. But it's important to
know the idea of multitenancy and have a high level understanding of how this
works. EC2 gives you a great deal of flexibility and control. Not only can you spin
up new servers or take them offline at will, but you also have the flexibility and
control over the configuration of those instances.

When you provision an EC2 instance, you can choose the operating system
based on either Windows or Linux. You can provision thousands of EC2 instances
on demand. With a blend of operating systems and configurations to power your
business' different applications.
Beyond the OS, you also configure what software you want running on the
instance. Whether it's your own internal business applications, simple web apps,
or complex web apps, databases or third party software like enterprise software
packages, you have complete control over what happens on that instance. EC2
instances are also resizable. You might start with a small instance, realize the
application you are running is starting to max out that server, and then you can
give that instance more memory and more CPU. Which is what we call vertically
scaling an instance.

In essence, you can make instances bigger or smaller whenever you need to. You
also control the networking aspect of EC2. So what type of requests make it to
your server and if they are publicly or privately accessible is something you
decide.

We will touch more on this later in the course in detail. Virtual machines are not a
new thing. But the ease of provisioning EC2 instances allows for programmers
and businesses to innovate more quickly. AWS has just made it much, much
easier and more cost effective for you to acquire servers through this Compute
as a Service model. There's a lot more to learn about EC2. We talked about
virtualization and the types of software you can run on an EC2 instance. But
there is more you can configure with EC2 as well.

Amazon Elastic Compute Cloud (Amazon EC2)

Amazon Elastic Compute Cloud (Amazon EC2)(opens in a new tab) provides
secure, resizable compute capacity in the cloud as Amazon EC2 instances.
Imagine you are responsible for the architecture of your company's resources
and need to support new websites. With traditional on-premises resources, you
have to do the following:
 Spend money upfront to purchase hardware.
 Wait for the servers to be delivered to you.
 Install the servers in your physical data center.
 Make all the necessary configurations.
By comparison, with an Amazon EC2 instance you can use a virtual server to run
applications in the AWS Cloud.
 You can provision and launch an Amazon EC2 instance within minutes.
 You can stop using it when you have finished running a workload.
 You pay only for the compute time you use when an instance is running,
not when it is stopped or terminated.
 You can save costs by paying only for server capacity that you need or
want.
How Amazon EC2 works
To learn more, choose each numbered marker.
Launch
First, you launch an instance. Begin by selecting a template with basic
configurations for your instance. These configurations include the operating
system, application server, or applications. You also select the instance type,
which is the specific hardware configuration of your instance.

As you are preparing to launch an instance, you specify security settings to

control the network traffic that can flow into and out of your instance. Later in
this course, we will explore Amazon EC2 security features in greater detail.
Connect
Next, connect to the instance. You can connect to the instance in several ways.
Your programs and applications have multiple different methods to connect
directly to the instance and exchange data. Users can also connect to the
instance by logging in and accessing the computer desktop.
Use
After you have connected to the instance, you can begin using it. You can run
commands to install software, add storage, copy and organize files, and more.

Amazon EC2 Instance Types

Now that we've learned about EC2 instances and the crucial role they play in
AWS, let's talk about the different types of EC2 instances that are available.
Thinking back to our coffee shop analogy, you'll remember that EC2 instances
are like our employees and that they serve client requests. If we want to have a
cafe that can serve a lot of customers, then we're probably going to need
multiple employees, right? And they all can't just be cashiers. We also need
someone to make the drinks, someone to handle the food, and maybe someone
to do that cool latte art that our customers love so much. Like any business,
there are a variety of tasks that need to be done, and they often require different
skillsets.

If we want our business to operate as efficiently as possible, it's important to

make sure that an employee's skillset suits their role. In the same way that our
coffee shop has different kinds of employees, AWS has different types of EC2
instances that you can spin up and deploy into your AWS environment.

Each instance type is grouped under an instance family and are optimized for
certain types of tasks. Instance types offer varying combinations of CPU,
memory, storage, and networking capacity, and give you the flexibility to choose
the appropriate mix of resources for your applications. The different instance
families in EC2 are general purpose, compute optimized, memory optimized,
accelerated computing, and storage optimized.

General purpose instances provide a good balance of compute, memory, and

networking resources, and can be used for a variety of diverse workloads like
web service or code repositories.

Compute optimized instances are ideal for compute-intensive tasks like gaming
servers, high performance computing or HPC, and even scientific modeling.

Similarly, memory optimized instances are good for memory-intensive tasks.

Accelerated computing are good for floating point number calculations, graphics
processing, or data pattern matching, as they use hardware accelerators.

And finally, storage optimized are good for, can you guess it? Workloads that
require high performance for locally stored data.

Now, if we map this back to our coffee shop, our cashier becomes a memory
optimized EC2 instance, baristas become compute optimized instances, and our
latte art employee is an accelerated computing instance type. And there you
have it, EC2 instance types.
Amazon EC2 instance types
Amazon EC2 instance types(opens in a new tab) are optimized for different tasks.
When selecting an instance type, consider the specific needs of your workloads
and applications. This might include requirements for compute, memory, or
storage capabilities.
To learn more about Amazon EC2 instance types, expand each of the following
five categories.
General purpose instances provide a balance of compute, memory, and
networking resources. You can use them for a variety of workloads, such as:
 application servers
 gaming servers
 backend servers for enterprise applications
 small and medium databases
Suppose that you have an application in which the resource needs for compute,
memory, and networking are roughly equivalent. You might consider running it
on a general purpose instance because the application does not require
optimization in any single resource area.
Compute optimized instances are ideal for compute-bound applications that
benefit from high-performance processors. Like general purpose instances, you
can use compute optimized instances for workloads such as web, application,
and gaming servers.

However, the difference is compute optimized applications are ideal for high-
performance web servers, compute-intensive applications servers, and dedicated
gaming servers. You can also use compute optimized instances for batch
processing workloads that require processing many transactions in a single
group.
Memory optimized instances are designed to deliver fast performance for
workloads that process large datasets in memory. In computing, memory is a
temporary storage area. It holds all the data and instructions that a central
processing unit (CPU) needs to be able to complete actions. Before a computer
program or application is able to run, it is loaded from storage into memory. This
preloading process gives the CPU direct access to the computer program.
Suppose that you have a workload that requires large amounts of data to be
preloaded before running an application. This scenario might be a high-
performance database or a workload that involves performing real-time
processing of a large amount of unstructured data. In these types of use cases,
consider using a memory optimized instance. Memory optimized instances
enable you to run workloads with high memory needs and receive great
performance.
Accelerated computing instances use hardware accelerators, or
coprocessors, to perform some functions more efficiently than is possible in
software running on CPUs. Examples of these functions include floating-point
number calculations, graphics processing, and data pattern matching.

In computing, a hardware accelerator is a component that can expedite data

processing. Accelerated computing instances are ideal for workloads such as
graphics applications, game streaming, and application streaming.
Storage optimized instances are designed for workloads that require high,
sequential read and write access to large datasets on local storage. Examples of
workloads suitable for storage optimized instances include distributed file
systems, data warehousing applications, and high-frequency online transaction
processing (OLTP) systems.

In computing, the term input/output operations per second (IOPS) is a metric that
measures the performance of a storage device. It indicates how many different
input or output operations a device can perform in one second. Storage
optimized instances are designed to deliver tens of thousands of low-latency,
random IOPS to applications.

You can think of input operations as data put into a system, such as records
entered into a database. An output operation is data generated by a server. An
example of output might be the analytics performed on the records in a
database. If you have an application that has a high IOPS requirement, a storage
optimized instance can provide better performance over other instance types not
optimized for this kind of use case.

Amazon EC2 Pricing

We talked about EC2 instance types, but you're all probably wondering how
much is this gonna cost me? Well, don't fret. For EC2, we have multiple billing
options available.

The first one and the one that most people are familiar with is called On-
Demand. What that means is that you only pay for the duration that your
instance runs for. This can be per hour or per second, depending on the instance
type and operating system you choose to run. Plus, no long-term commitments
or upfront payments are needed. This type of pricing is usually for when you get
started and want to spin up servers to test out workloads and play around. You
don't need any prior contracts or communication with AWS to use On-Demand
pricing. You can also use them to get a baseline for your average usage, which
leads us to our next pricing option, Savings Plan.

Savings Plan offers low prices on EC2 usage in exchange for a commitment to a
consistent amount of usage measured in dollars per hour for a one or three-year
term. This flexible pricing model can therefore provide savings of up to 72% on
your AWS compute usage. This can lower prices on your EC2 usage, regardless of
instance family, size, OS, tenancy, or AWS region. This also applies to AWS
Fargate and AWS Lambda usage, which are serverless compute options that we
will cover later in this course.

Another option is Reserved Instances. These are suited for steady-state

workloads or ones with predictable usage and offer you up to a 75% discount
versus On-Demand pricing. You qualify for a discount once you commit to a one
or three-year term and can pay for them with three payment options: all upfront,
where you pay for them in full when you commit; partial upfront, where you pay
for a portion when you commit; and no upfront, where you don't pay anything at
the beginning.

The next option is Spot Instances, and they allow you to request spare Amazon
EC2 computing capacity for up to 90% off of the On-Demand price. The catch
here is that AWS can reclaim the instance at any time they need it, giving you a
two-minute warning to finish up work and save state. You can always resume
later if needed. So when choosing Spot Instances, make sure your workloads can
tolerate being interrupted. A good example of those are batch workloads.

And finally, we have Dedicated Hosts, which are physical hosts dedicated for
your use for EC2. These are usually for meeting certain compliance requirements
and nobody else will share tenancy of that host.
Amazon EC2 pricing
With Amazon EC2, you pay only for the compute time that you use. Amazon EC2
offers a variety of pricing options for different use cases. For example, if your use
case can withstand interruptions, you can save with Spot Instances. You can also
save by committing early and locking in a minimum level of use with Reserved
Instances.
To learn more Amazon EC2 pricing, choose each of the following five categories.
On-Demand Instances are ideal for short-term, irregular workloads that cannot
be interrupted. No upfront costs or minimum contracts apply. The instances run
continuously until you stop them, and you pay for only the compute time you
use.

Sample use cases for On-Demand Instances include developing and testing
applications and running applications that have unpredictable usage patterns.
On-Demand Instances are not recommended for workloads that last a year or
longer because these workloads can experience greater cost savings using
Reserved Instances.

Reserved Instances are a billing discount applied to the use of On-Demand

Instances in your account. There are two available types of Reserved Instances:
 Standard Reserved Instances
 Convertible Reserved Instances
You can purchase Standard Reserved and Convertible Reserved Instances for a 1-
year or 3-year term. You realize greater cost savings with the 3-year option.

Standard Reserved Instances: This option is a good fit if you know the EC2
instance type and size you need for your steady-state applications and in which
AWS Region you plan to run them. Reserved Instances require you to state the
following qualifications:
 Instance type and size: For example, m5.xlarge
  Platform description (operating system): For example, Microsoft
Windows Server or Red Hat Enterprise Linux
 Tenancy: Default tenancy or dedicated tenancy
You have the option to specify an Availability Zone for your EC2 Reserved
Instances. If you make this specification, you get EC2 capacity reservation. This
ensures that your desired amount of EC2 instances will be available when you
need them.

Convertible Reserved Instances: If you need to run your EC2 instances in

different Availability Zones or different instance types, then Convertible Reserved
Instances might be right for you. Note: You trade in a deeper discount when you
require flexibility to run your EC2 instances.

At the end of a Reserved Instance term, you can continue using the Amazon EC2
instance without interruption. However, you are charged On-Demand rates until
you do one of the following:
 Terminate the instance.
 Purchase a new Reserved Instance that matches the instance attributes
(instance family and size, Region, platform, and tenancy).

AWS offers Savings Plans for a few compute services, including Amazon
EC2. EC2 Instance Savings Plans reduce your EC2 instance costs when
you make an hourly spend commitment to an instance family and Region
for a 1-year or 3-year term. This term commitment results in savings of up
to 72 percent compared to On-Demand rates. Any usage up to the
commitment is charged at the discounted Savings Plans rate (for
example, $10 per hour). Any usage beyond the commitment is charged at
regular On-Demand rates.
The EC2 Instance Savings Plans are a good option if you need
flexibility in your Amazon EC2 usage over the duration of the
commitment term. You have the benefit of saving costs on running
any EC2 instance within an EC2 instance family in a chosen Region
(for example, M5 usage in N. Virginia) regardless of Availability
Zone, instance size, OS, or tenancy. The savings with EC2 Instance
Savings Plans are similar to the savings provided by Standard
Reserved Instances.

Unlike Reserved Instances, however, you don't need to specify up

front what EC2 instance type and size (for example, m5.xlarge), OS,
and tenancy to get a discount. Further, you don't need to commit to
a certain number of EC2 instances over a 1-year or 3-year term.
Additionally, the EC2 Instance Savings Plans don't include an EC2
capacity reservation option.

Later in this course, you'll review AWS Cost Explorer, which you can
use to visualize, understand, and manage your AWS costs and
usage over time. If you're considering your options for Savings
Plans, you can use AWS Cost Explorer to analyse your Amazon EC2
usage over the past 7, 30, or 60 days. AWS Cost Explorer also
provides customized recommendations for Savings Plans. These
recommendations estimate how much you could save on your
monthly Amazon EC2 costs, based on previous Amazon EC2 usage
and the hourly commitment amount in a 1-year or 3-year Savings
Plan.

Spot Instances are ideal for workloads with flexible start and end
times, or that can withstand interruptions. Spot Instances use
unused Amazon EC2 computing capacity and offer you cost savings
at up to 90% off of On-Demand prices.

Suppose that you have a background processing job that can start
and stop as needed (such as the data processing job for a customer
survey). You want to start and stop the processing job without
affecting the overall operations of your business. If you make a Spot
request and Amazon EC2 capacity is available, your Spot Instance
launches. However, if you make a Spot request and Amazon EC2
capacity is unavailable, the request is not successful until capacity
becomes available. The unavailable capacity might delay the launch
of your background processing job.

After you have launched a Spot Instance, if capacity is no longer

available or demand for Spot Instances increases, your instance
may be interrupted. This might not pose any issues for your
background processing job. However, in the earlier example of
developing and testing applications, you would most likely want to
avoid unexpected interruptions. Therefore, choose a different EC2
instance type that is ideal for those tasks.

Dedicated Hosts are physical servers with Amazon EC2 instance

capacity that is fully dedicated to your use.

You can use your existing per-socket, per-core, or per-VM software

licenses to help maintain license compliance. You can purchase On-
Demand Dedicated Hosts and Dedicated Hosts Reservations. Of all
the Amazon EC2 options that were covered, Dedicated Hosts are the
most expensive.

Scaling Amazon EC2

So we have a good idea now on the basics of EC2 and how it can
help with any compute needs, like making coffee. Well, like
metaphorically making coffee. The coffee represents the, whatever
your instance is producing. The next thing we want to talk about is
another major benefit of AWS, scalability and elasticity, or how
capacity can grow and shrink, based on business needs.

Here is the on-prem data center dilemma. If your business is like

99% of all businesses out in the world, your customer workloads
vary over time: perhaps over a simple 24-hour period, or you might
have seasons where you're busy, and weeks that are not in demand.
If you're building out a data center, the question is, what is the right
amount of hardware to purchase? If you buy for the average
amount, the average usage, you won't be wasting money on
average. But when the peak loads come in, you won't have the
hardware to service the customers, especially during the critical
moments to expect to be making all your results.

Now, if you buy for the top max load, you might have happy
customers, but for most of the year, you'll have idle resources.
Which means your average utilization is very low. And I've seen data
centres with average utilization under 10%, just out of fear of
missing peak demand. So how do you solve the problem on-
premises? Well, the truth is, you can't. And here's where AWS
changes the conversation entirely.

What if you could provision your workload to exactly the demand,

every hour, every day? Well, now you have happy customers,
because they can always get the services they want. And you have
a happy financial officer because they get the ROI your company
needs.

And here's how it works. Morgan is behind the counter. She's taking
orders and we have a decoupled system. Morgan isn't doing all of
the work here, so we need somebody making the drinks. It looks like
Rudy's up. Now, the first problem I want to solve, is the idea that we
plan for a disaster. There's a great quote by Werner Vogels that
says, "Everything fails all the time, so plan for failure and nothing
fails." Or in other words, we ask ourselves what would happen if we
lost our order taking instance? Well, we'd be out of business until
we'd get another person to work the line, sorry, another instance up
and running.

So here is where AWS makes it really simple. Using the same

programmatic method we used to create the original Morgan, we
can create a second Morgan. So, if one fails, we have another one
already on the front line and taking orders. The customers never
lose service. Well, don't forget about the backend. Let's make our
processing instances redundant as well. So that gets our regular
operating capacity. We now have a highly available system, with no
single point of failure. And as long as the number of customers in
line stays the same, we're good. But you know that's going to
change, right? So, let's take a look at what's going to happen when
we have a rush of customers, an increase in demand.

Scalability involves beginning with only the resources you need

and designing your architecture to automatically respond to
changing demand by scaling out or in. As a result, you pay for only
the resources you use. You don’t have to worry about a lack of
computing capacity to meet your customers’ needs.

If you wanted the scaling process to happen automatically, which

AWS service would you use? The AWS service that provides this
functionality for Amazon EC2 instances is Amazon EC2 Auto
Scaling.

Amazon EC2 Auto Scaling

If you’ve tried to access a website that wouldn’t load and frequently

timed out, the website might have received more requests than it
was able to handle. This situation is similar to waiting in a long line
at a coffee shop, when there is only one barista present to take
orders from customers.

Amazon EC2 Auto Scaling enables you to automatically add or

remove Amazon EC2 instances in response to changing application
 demand. By automatically scaling your instances in and out as
needed, you can maintain a greater sense of application availability.
Within Amazon EC2 Auto Scaling, you can use two approaches:
dynamic scaling and predictive scaling.
 Dynamic scaling responds to changing demand.
 Predictive scaling automatically schedules the right number of
Amazon EC2 instances based on predicted demand.

To scale faster, you can use dynamic scaling and predictive scaling
together.

Now there are two ways to handle growing demands. You can scale up, or scale
out. Scaling up means adding more power to the machines that are running,
which might make sense in a few cases but think about it. When you have an
increase in customers, a bigger instance of Morgan really can't take a customer's
order any faster. Because that depends on the customer more than Morgan.

"I'll take an espresso. Oh, wait, is that organic? Make it a soy latte? Actually, I
don't know. Do you just have tea?"

What we need are, well, more Morgans. Customers? Oh, no! Looks like the
processing instances are about to get overloaded. So let's scale them as well.

Obvious question is obvious. How come they are more order taking instances
than order makers?

Well, in this case, the amount of work you can get done is still more than the
order machines can send your way. You don't have a backlog. So no reason to
add more worker instances. This is one of the great things about decoupling the
system. You can end up with exactly the right amount of power for each part of
your process, rather than over provisioning to solve a separate problem. Okay,
looks like we just cleared that rush.

Now here is where AWS really makes a difference to your business. All these
extra workers that are sitting around idle, if you don't need them, send them
home or stop the instances. Amazon EC2 Auto Scaling. Adds instances based on
demand and then decommissions instances when they are no longer needed.
This means that every minute of the day, you always have the correct number of
instances. Happy customers. Happy CFO. Happy architecture.

Example: Amazon EC2 Auto Scaling

In the cloud, computing power is a programmatic resource, so you can take a
more flexible approach to the issue of scaling. By adding Amazon EC2 Auto
Scaling to an application, you can add new instances to the application when
necessary and terminate them when no longer needed.
Suppose that you are preparing to launch an application on Amazon EC2
instances. When configuring the size of your Auto Scaling group, you might set
the minimum number of Amazon EC2 instances at one. This means that at all
times, there must be at least one Amazon EC2 instance running.
When you create an Auto Scaling group, you can set the minimum number of
Amazon EC2 instances. The minimum capacity is the number of Amazon EC2
instances that launch immediately after you have created the Auto Scaling
group. In this example, the Auto Scaling group has a minimum capacity of one
Amazon EC2 instance.

Next, you can set the desired capacity at two Amazon EC2 instances even
though your application needs a minimum of a single Amazon EC2 instance to
run.
If you do not specify the desired number of Amazon EC2 instances in an Auto
Scaling group, the desired capacity defaults to your minimum capacity.
The third configuration that you can set in an Auto Scaling group is
the maximum capacity. For example, you might configure the Auto Scaling
group to scale out in response to increased demand, but only to a maximum of
four Amazon EC2 instances.
Because Amazon EC2 Auto Scaling uses Amazon EC2 instances, you pay for only
the instances you use, when you use them. You now have a cost-effective
architecture that provides the best customer experience while reducing
expenses.
Directing Traffic with Elastic Load Balancing

So, we solved the scaling problem with Amazon EC2 Auto Scaling. But now we've
got a bit of a traffic problem, don't we? Let's take a look at the situation. When
customers come into the coffee shop, right now they have three options for
which cashier to talk to place an order. And oddly enough, most of them are
lining up in one line, causing an uneven distribution of customers per line. Even
though we have other cashiers waiting to take orders, standing around doing
nothing. Customers come in and aren't sure exactly where to route their order. It
would help a lot if we added a host to the situation.

A host stands at the door and when customers come into the coffee shop, they
tell them which line to proceed to for placing their order. The host keeps an eye
on the cashier's taking orders and counts the number of people in line each
cashier is serving. Then it will direct new customers to the cashier that has the
shortest line, that's the least bogged down, thus allowing the lines to be even
across cashiers and helping customers be served in the most efficient manner
possible.

The same idea applies to your AWS environment. When you have multiple EC2
instances all running the same program, to serve the same purpose, and a
request comes in, how does that request know which EC2 instance to go to? How
can you ensure there's an even distribution of workload across EC2 instances? So
not just one is backed up while the others are idle sitting by. You need a way to
route requests to instances to process that request. What you need to solve this
is called load balancing.

A load balancer is an application that takes in requests and routes them to the
instances to be processed. Now, there are many off the shelf load balancers that
work great on AWS. And if you have a favourite flavour that already does exactly
what you want, then feel free to keep using it. In which case it will be up to your
operations team to install, manage, update, scale, handle fail over, and
availability. It's doable. Odds are what you really need is just to properly
distribute traffic in a high performance, cost-efficient, highly available,
automatically scalable system that you can just set and forget.

Introducing Elastic Load Balancing. Elastic Load Balancing, or ELB, is one of the
first major managed services we're going to talk about in this course. And it's
engineered to address the undifferentiated heavy lifting of load balancing. To
illustrate this point, I need to zoom out a bit here. To begin with, Elastic Load
Balancing is a regional construct, and we'll explain more of what that means in
later videos. But the key value for you is that because it runs at the Region level
rather than on individual EC2 instances, the service is automatically highly
available with no additional effort on your part.

ELB is automatically scalable. As your traffic grows, ELB is designed to handle

the additional throughput with no change to the hourly cost. When your EC2 fleet
auto-scales out, as each instance comes online, the auto-scaling service just lets
the Elastic Load Balancing service know that it's ready to handle the traffic, and
off it goes. Once the fleet scales in, ELB first stops all new traffic, and waits for
the existing requests to complete, to drain out. Once they do that, then the auto-
scaling engine can terminate the instances without disruption to existing
customers.
ELB is not only used for external traffic. Let's look at the ordering tier, and how it
communicates with the production tier. Right now, each front-end instance is
aware of each backend instance. And if a new back-end instance comes online, in
this current architecture, it would have to tell every front-end instance that it can
now accept traffic. This is complicated enough with just half a dozen instances.
Now imagine you have potentially hundreds of instances on both tiers. Each tier
shifting constantly based on demand. Just keeping them networked efficiently is
impossible.

Well, we solve the back-end traffic chaos with an ELB as well. Because ELB is
regional, it's a single URL that each front-end instance uses. Then the ELB directs
traffic to the back end that has the least outstanding requests. Now, if the back-
end scales, once the new instance is ready, it just tells the ELB that it can take
traffic, and it gets to work. The front end doesn't know and doesn't care how
many back-end instances are running. This is true decoupled architecture.

There's even more that the ELB can do that we'll learn about later, but this is
good enough for now. The key is choosing the right tool for the right job, which is
one of the reasons AWS offers so many different services. For example, back-end
communication. There are many ways to handle it and ELB is just one method.
Next, we'll talk about some other services that might work even better for some
architectures.

Elastic Load Balancing is the AWS service that automatically distributes

incoming application traffic across multiple resources, such as Amazon EC2
instances.
A load balancer acts as a single point of contact for all incoming web traffic to
your Auto Scaling group. This means that as you add or remove Amazon EC2
instances in response to the amount of incoming traffic, these requests route to
the load balancer first. Then, the requests spread across multiple resources that
will handle them. For example, if you have multiple Amazon EC2 instances,
Elastic Load Balancing distributes the workload across the multiple instances so
that no single instance has to carry the bulk of it.
Although Elastic Load Balancing and Amazon EC2 Auto Scaling are separate
services, they work together to help ensure that applications running in Amazon
EC2 can provide high performance and availability.
Example: Elastic Load Balancing
Low-demand period
Here’s an example of how Elastic Load Balancing works. Suppose that a few
customers have come to the coffee shop and are ready to place their orders.
If only a few registers are open, this matches the demand of customers who
need service. The coffee shop is less likely to have open registers with no
customers. In this example, you can think of the registers as Amazon EC2
instances.
High-demand period
Throughout the day, as the number of customers increases, the coffee shop
opens more registers to accommodate them.
Additionally, a coffee shop employee directs customers to the most appropriate
register so that the number of requests can evenly distribute across the open
registers. You can think of this coffee shop employee as a load balancer.

Messaging and Queuing

Let's talk about messaging and queuing. In the coffee shop, there are cashiers
taking orders from the customers and baristas making the orders. Currently, the
cashier takes the order, writes it down with a pen and paper, and delivers this
order to the barista. The barista then takes the paper and makes the order. When
the next order comes in, the process repeats. This works great as long as both
the cashier and the barista are in sync. But what would happen if the cashier
took the order and turned to pass it to the barista and the barista was out on
break or busy with another order? Well, that cashier is stuck until the barista is
ready to take the order. And at a certain point, the order will probably be dropped
so the cashier can go serve the next customer.

You can see how this is a flawed process, because as soon as either the cashier
or barista is out of sync, the process will degrade, causing slow downs in
receiving orders and failures to complete orders at all. A much better process
would be to introduce some sort of buffer or queue into the system. Instead of
handing the order directly to the barista, the cashier would post the order to
some sort of buffer, like an order board.

This idea of placing messages into a buffer is called messaging and queuing. Just
as our cashier sends orders to the barista, applications send messages to each
other to communicate. If applications communicate directly like our cashier and
barista previously, this is called being tightly coupled.

A hallmark trait of a tightly coupled architecture is where if a single component

fails or changes, it causes issues for other components or even the whole
system. For example, if we have Application A and it is sending messages
directly to Application B, if Application B has a failure and cannot accept those
messages, Application A will begin to see errors as well. This is a tightly coupled
architecture.

A more reliable architecture is loosely coupled. This is an architecture where if

one component fails, it is isolated and therefore won't cause cascading failures
throughout the whole system. If we coded the application to use a more loosely
coupled architecture, it could look as follows.

Just like our cashier and barista, we introduced a buffer between the two. In this
case, we introduced a message queue. Messages are sent into the queue by
Application A and they are processed by Application B. If Application B fails,
Application A doesn't experience any disruption. Messages being sent can still be
sent to the queue and will remain there until they are eventually processed.

This is loosely coupled. This is what we strive to achieve with architectures on

AWS. And this brings me to two AWS services that can assist in this regard.
Amazon Simple Queue Service or SQS and Amazon Simple Notification Service or
SNS. But before I dive into those two services, let me just order a to-go coffee on
our cafe website. Done. All right, well, that's great. I should get a message when
that order is ready.

First up, let's discuss Amazon SQS. SQS allows you to send, store, and receive
messages between software components at any volume. This is without losing
messages or requiring other services to be available. Think of messages as our
coffee orders and the order board as an SQS queue. Messages have the person's
name, coffee order, and time they ordered. The data contained within a message
is called a payload, and it's protected until delivery. SQS queues are where
messages are placed until they are processed. And AWS manages the underlying
infrastructure for you to host those queues. These scale automatically, are
reliable, and are easy to configure and use.

Now, Amazon SNS is similar in that it is used to send out messages to services,
but it can also send out notifications to end users. It does this in a different way
called a publish/subscribe or pub/sub model. This means that you can create
something called an SNS topic which is just a channel for messages to be
delivered. You then configure subscribers to that topic and finally publish
messages for those subscribers. In practice, that means you can send one
message to a topic which will then fan out to all the subscribers in a single go.
These subscribers can also be endpoints such as SQS queues, AWS Lambda
functions, and HTTPS or HTTP web hooks.

Additionally, SNS can be used to fan out notifications to end users using mobile
push, SMS, and email. Taking this back to our coffee shop, we could send out a
notification when a customer's order is ready. This could be a simple SMS to let
them know to pick it up or even a mobile push.
In fact, it looks like my phone just received a message. Looks like my order is
ready. See you soon.

Monolithic applications and microservices

Applications are made of multiple components. The components communicate

with each other to transmit data, fulfill requests, and keep the application
running.
Suppose that you have an application with tightly coupled components. These
components might include databases, servers, the user interface, business logic,
and so on. This type of architecture can be considered a monolithic
application.
In this approach to application architecture, if a single component fails, other
components fail, and possibly the entire application fails.
To help maintain application availability when a single component fails, you can
design your application through a microservices approach.

In a microservices approach, application components are loosely coupled. In this

case, if a single component fails, the other components continue to work
because they are communicating with each other. The loose coupling prevents
the entire application from failing.
When designing applications on AWS, you can take a microservices approach
with services and components that fulfill different functions. Two services
facilitate application integration: Amazon Simple Notification Service (Amazon
SNS) and Amazon Simple Queue Service (Amazon SQS).

Amazon Simple Notification Service (Amazon SNS) is a publish/subscribe

service. Using Amazon SNS topics, a publisher publishes messages to
subscribers. This is similar to the coffee shop; the cashier provides coffee orders
to the barista who makes the drinks.
In Amazon SNS, subscribers can be web servers, email addresses, AWS Lambda
functions, or several other options.
In the next lesson, you will learn more about AWS Lambda.
To review two examples of how to use Amazon SNS, choose the arrow buttons to
display each one.

Step 1
Publishing updates from a single topic

Suppose that the coffee shop has a single newsletter that includes updates from
all areas of its business. It includes topics such as coupons, coffee trivia, and new
products. All of these topics are grouped because this is a single newsletter. All
customers who subscribe to the newsletter receive updates about coupons,
coffee trivia, and new products.
After a while, some customers express that they would prefer to receive separate
newsletters for only the specific topics that interest them. The coffee shop
owners decide to try this approach.

Step 2
Publishing updates from multiple topics

Now, instead of having a single newsletter for all topics, the coffee shop has
broken it up into three separate newsletters. Each newsletter is devoted to a
specific topic: coupons, coffee trivia, and new products.
Subscribers will now receive updates immediately for only the specific topics to
which they have subscribed.
It is possible for subscribers to subscribe to a single topic or to multiple topics.
For example, the first customer subscribes to only the coupons topic, and the
second subscriber subscribes to only the coffee trivia topic. The third customer
subscribes to both the coffee trivia and new products topics.
Amazon Simple Queue Service (Amazon SQS) is a message queuing
service.
Using Amazon SQS, you can send, store, and receive messages between
software components, without losing messages or requiring other services to be
available. In Amazon SQS, an application sends messages into a queue. A user or
service retrieves a message from the queue, processes it, and then deletes it
from the queue.
To review two examples of how to use Amazon SQS, choose the arrow buttons to
display each one.
Example 1: Fulfilling an order

Suppose that the coffee shop has an ordering process in which a cashier takes
orders, and a barista makes the orders. Think of the cashier and the barista as
two separate components of an application.
First, the cashier takes an order and writes it down on a piece of paper. Next, the
cashier delivers the paper to the barista. Finally, the barista makes the drink and
gives it to the customer.
When the next order comes in, the process repeats. This process runs smoothly
as long as both the cashier and the barista are coordinated.
What might happen if the cashier took an order and went to deliver it to the
barista, but the barista was out on a break or busy with another order? The
cashier would need to wait until the barista is ready to accept the order. This
would cause delays in the ordering process and require customers to wait longer
to receive their orders.
As the coffee shop has become more popular and the ordering line is moving
more slowly, the owners notice that the current ordering process is time
consuming and inefficient. They decide to try a different approach that uses a
queue.

Example 2: Orders in a queue

Recall that the cashier and the barista are two separate components of an
application. A message queuing service, such as Amazon SQS, lets messages
between decoupled application complements.
In this example, the first step in the process remains the same as before: a
customer places an order with the cashier.
The cashier puts the order into a queue. You can think of this as an order board
that serves as a buffer between the cashier and the barista. Even if the barista is
out on a break or busy with another order, the cashier can continue placing new
orders into the queue.
Next, the barista checks the queue and retrieves the order.
The barista prepares the drink and gives it to the customer.
The barista then removes the completed order from the queue.
While the barista is preparing the drink, the cashier is able to continue taking
new orders and add them to the queue.

Additional Compute Services

EC2 instances are virtual machines that you can provision with minimal friction
to get up and running on AWS. EC2 is great for all sorts of different use cases like
running basic web servers to running high performance computing clusters and
everything in between.

That being said, though EC2 is incredibly flexible, reliable, and scalable,
depending on your use case, you might be looking at alternatives for your
compute capacity. EC2 requires that you set up and manage your fleet of
instances over time. When you're using EC2, you are responsible for patching
your instances when new software packages come out, setting up the scaling of
those instances as well as ensuring that you've architected your solutions to be
hosted in a highly available manner. This is still not as much management as you
would have if you hosted these on-premises. But management processes will still
need to be in place.

You might be wondering what other services does AWS offer for compute that are
more convenient from a management perspective. This is where the term
serverless comes in. AWS offers multiple serverless compute options. Serverless
means that you cannot actually see or access the underlying infrastructure or
instances that are hosting your application. Instead, all the management of the
underlying environment from a provisioning, scaling, high availability, and
maintenance perspective are taken care of for you. All you need to do is focus on
your application and the rest is taken care of.

AWS Lambda is one serverless compute option. Lambda's a service that allows
you to upload your code into what's called a Lambda function. Configure a
trigger and from there, the service waits for the trigger. When the trigger is
detected, the code is automatically run in a managed environment, an
environment you do not need to worry too much about because it is
automatically scalable, highly available and all of the maintenance in the
environment itself is done by AWS. If you have one or 1,000 incoming triggers,
Lambda will scale your function to meet demand. Lambda is designed to run
code under 15 minutes so this isn't for long running processes like deep learning.
It's more suited for quick processing like a web backend, handling requests or a
backend expense report processing service where each invocation takes less
than 15 minutes to complete.

If you weren't quite ready for serverless yet or you need access to the underlying
environment, but still want efficiency and portability, you should look at AWS
container services like Amazon Elastic Container Service, otherwise known as
ECS. Or Amazon Elastic Kubernetes Service, otherwise known as EKS.

Both of these services are container orchestration tools, but before I get too far
here, a container in this case is a Docker container. Docker is a widely used
platform that uses operating system level virtualization to deliver software in
containers. Now a container is a package for your code where you package up
your application, its dependencies as well as any configurations that it needs to
run. These containers run on top of EC2 instances and run in isolation from each
other similar to how virtual machines work. But in this case, the host is an EC2
instance. When you use Docker containers on AWS, you need processes to start,
stop, restart, and monitor containers running across not just one EC2 instance,
but a number of them together which is called a cluster.

The process of doing these tasks is called container orchestration and it turns out
it's really hard to do on your own. Orchestration tools were created to help you
manage your containers. ECS is designed to help you run your containerized
applications at scale without the hassle of managing your own container
orchestration software. EKS does a similar thing but uses different tooling and
with different features.

Both Amazon ECS and Amazon EKS can run on top of EC2. But if you don't want
to even think about using EC2s to host your containers because you either don't
need access to the underlying OS or you don't want to manage those EC2
instances, you can use a compute platform called AWS Fargate. Fargate is a
serverless compute platform for ECS or EKS. That's a bit high level and it might
be confusing, so let's clear that up.

If you are trying to host traditional applications and want full access to the
underlying operating system like Linux or Windows, you are going to want to use
EC2. If you are looking to host short running functions, service-oriented or event
driven applications and you don't want to manage the underlying environment at
all, look into the serverless AWS Lambda. If you are looking to run Docker
container-based workloads on AWS, you first need to choose your orchestration
tool. Do you want to use Amazon ECS or Amazon EKS? After you choose your
tool, you then need to choose your platform. Do you want to run your containers
on EC2 instances that you manage or in a serverless environment like AWS
Fargate that is managed for you?

Those are just some of your compute options with AWS and it's not even a
complete list. Check out the notes for more information on AWS compute
services as well as others that we didn't get to talk about in this video.

Serverless computing
Earlier in this module, you learned about Amazon EC2, a service that lets you run
virtual servers in the cloud. If you have applications that you want to run in
Amazon EC2, you must do the following:
1. Provision instances (virtual servers).
2. Upload your code.
3. Continue to manage the instances while your application is running.

Comparison between computing with virtual servers (thinking about servers and
code) and serverless computing (thinking only about code).
The term “serverless” means that your code runs on servers, but you do not
need to provision or manage these servers. With serverless computing, you can
focus more on innovating new products and features instead of maintaining
servers.
Another benefit of serverless computing is the flexibility to scale serverless
applications automatically. Serverless computing can adjust the applications'
capacity by modifying the units of consumptions, such as throughput and
memory.
An AWS service for serverless computing is AWS Lambda.
AWS Lambda(opens in a new tab) is a service that lets you run code without
needing to provision or manage servers.
While using AWS Lambda, you pay only for the compute time that you consume.
Charges apply only when your code is running. You can also run code for virtually
any type of application or backend service, all with zero administration.
For example, a simple Lambda function might involve automatically resizing
uploaded images to the AWS Cloud. In this case, the function triggers when
uploading a new image.
How AWS Lambda works
 1. You upload your code to Lambda.
2. You set your code to trigger from an event source, such as AWS services,
mobile applications, or HTTP endpoints.
3. Lambda runs your code only when triggered.
4. You pay only for the compute time that you use. In the previous example
of resizing images, you would pay only for the compute time that you use
when uploading new images. Uploading the images triggers Lambda to
run code for the image resizing function.
In AWS, you can also build and run containerized applications.

Containers provide you with a standard way to package your application's code
and dependencies into a single object. You can also use containers for processes
and workflows in which there are essential requirements for security, reliability,
and scalability.
To review an example on how containers work, choose the arrow buttons.
Step 1
One host with multiple containers

Suppose that a company’s application developer has an environment on their

computer that is different from the environment on the computers used by the IT
operations staff. The developer wants to ensure that the application’s
environment remains consistent regardless of deployment, so they use a
containerized approach. This helps to reduce time spent debugging applications
and diagnosing differences in computing environments.

Step 2
Tens of hosts with hundreds of containers

When running containerized applications, it’s important to consider scalability.

Suppose that instead of a single host with multiple containers, you have to
manage tens of hosts with hundreds of containers. Alternatively, you have to
manage possibly hundreds of hosts with thousands of containers. At a large
scale, imagine how much time it might take for you to monitor memory usage,
security, logging, and so on.

Amazon Elastic Container Service (Amazon ECS)

Amazon Elastic Container Service (Amazon ECS)(opens in a new tab) is a
highly scalable, high-performance container management system that enables
you to run and scale containerized applications on AWS.
Amazon ECS supports Docker containers. Docker(opens in a new tab) is a
software platform that enables you to build, test, and deploy applications quickly.
AWS supports the use of open-source Docker Community Edition and
subscription-based Docker Enterprise Edition. With Amazon ECS, you can use API
calls to launch and stop Docker-enabled applications.
Amazon Elastic Kubernetes Service (Amazon EKS)
Amazon Elastic Kubernetes Service (Amazon EKS)(opens in a new tab) is a
fully managed service that you can use to run Kubernetes on AWS.
Kubernetes(opens in a new tab) is open-source software that enables you to
deploy and manage containerized applications at scale. A large community of
volunteers maintains Kubernetes, and AWS actively works together with the
Kubernetes community. As new features and functionalities release for
Kubernetes applications, you can easily apply these updates to your applications
managed by Amazon EKS.
AWS Fargate
AWS Fargate (opens in a new tab) is a serverless compute engine for
containers. It works with both Amazon ECS and Amazon EKS.
When using AWS Fargate, you do not need to provision or manage servers. AWS
Fargate manages your server infrastructure for you. You can focus more on
innovating and developing your applications, and you pay only for the resources
that are required to run your containers.

Module 2 Summary
In Module 2, you learned about the following concepts:
 Amazon EC2 instance types and pricing options
 Amazon EC2 Auto Scaling
 Elastic Load Balancing
 AWS services for messaging, containers, and serverless computing

First things first, what is cloud computing and what does AWS offer? We define
cloud computing as the on-demand delivery of IT resources over the internet
with pay-as-you-go pricing. This means that you can make requests for IT
resources like compute, networking, storage, analytics, or other types of
resources, and then they're made available for you on demand. You don't pay for
the resource upfront. Instead, you just provision and pay at the end of the
month.

AWS offers services and many categories that you use together to create your
solutions. We've only covered a few services so far, you learned about Amazon
EC2. With EC2, you can dynamically spin up and spin down virtual servers called
EC2 instances. When you launch an EC2 instance, you choose the instance
family. The instance family determines the hardware the instance runs on.

And you can have instances that are built for your specific purpose. The
categories are general purpose, compute optimized, memory optimized,
accelerated computing, and storage optimized.

You can scale your EC2 instances either vertically by resizing the instance, or
horizontally by launching new instances and adding them to the pool. You can set
up automated horizontal scaling, using Amazon EC2 Auto Scaling.

Once you've scaled your EC2 instances out horizontally, you need something to
distribute the incoming traffic across those instances. This is where the Elastic
Load Balancer comes into play.
EC2 instances have different pricing models. There is On-Demand, which is the
most flexible and has no contract, spot pricing, which allows you to utilize
unused capacity at a discounted rate, Savings Plans or Reserved Instances,
which allow you to enter into a contract with AWS to get a discounted rate when
you commit to a certain level of usage, and Savings Plans which apply to AWS
Lambda, and AWS Fargate, as well as EC2 instances.

We also covered messaging services. There is Amazon Simple Queue Service or

SQS. This service allows you to decouple system components. Messages remain
in the queue until they are either consumed or deleted. Amazon Simple
Notification Service or SNS, is used for sending messages like emails, text
messages, push notifications, or even HTTP requests. Once a message is
published, it is sent to all of these subscribers.
You also learned that AWS has different types of compute services beyond just
virtual servers like EC2. There are container services like Amazon Elastic
Container Service, or ECS. And there's Amazon Elastic Kubernetes Service, or
EKS. Both of which are container orchestration tools. You can use these tools with
EC2 instances, but if you don't want to manage that, you don't need to.

You can use AWS Fargate, which allows you to run your containers on top of a
serverless compute platform. Then there is AWS Lambda, which allows you to
just upload your code, and configure it to run based on triggers. And you only get
charged for when the code is actually running. No containers, no virtual
machines. Just code and configuration.

Module 3 Introduction
Learning objectives
In this module, you will learn how to:
 Summarize the benefits of the AWS Global Infrastructure.
 Describe the basic concept of Availability Zones.
 Describe the benefits of Amazon CloudFront and edge locations.
 Compare different methods for provisioning AWS services.

I want to talk to you about high availability. Say you wanna grab a cup of coffee
at the cafe, but today is not just a normal day in our city. Today, there is a parade
coming to march down our street in celebration of all of the wonderful cloud
migrations that have been successful. This parade is going to march right in front
of our shop. This is great because who doesn't love to look at floats and balloons
and have someone throw candy at them from the street? But this is also bad
because while the parade is coming down the street, our customers who are
driving to come get coffee will be diverted and won't be able to stop by the shop.
This will drive sales down and also make customers unhappy.

Luckily for us, we thought ahead. We thought long ago what would happen if for
some reason our customers couldn't make it into the shop temporarily? Like if
there was a parade or if there's a flood or some other event that blocks us from
getting into the shop? Well, no matter the reason, we need to be highly available
for our customers.

So, I'll let you in on a secret. This isn't our coffee shop's only location. The cafe is
actually a chain and we have locations all around the city. That way, if a parade
comes down the street, or if there was a power outage on our block, no worries.
Customers can still get their coffee by visiting one of our shops just a few blocks
away. We still make money and they get their coffee. All is well.

AWS has done a similar thing with how the AWS global infrastructure is set up.
It's not good enough to have one giant data center where all of the resources
are. If something were to happen to that data center, like a power outage or a
natural disaster, everyone's applications would go down all at once. You need
high availability and fault tolerance.
Turns out, it's not even good enough to have two giant data centers. Instead,
AWS operates in all sorts of different areas around the world called Regions.
We're going to talk about this in depth in upcoming videos. In the meantime, I'm
gonna sit here and relax, because I know my business is highly available
regardless of any parades blocking the street.
Building a global footprint
To understand the AWS global infrastructure, consider the coffee shop. If an
event such as a parade, flood, or power outage impacts one location, customers
can still get their coffee by visiting a different location only a few blocks away.
This is similar to how the AWS global infrastructure works.

AWS Global Infrastructure

To understand the global infrastructure AWS, I wanna begin with your
fundamental business need. You have an application that you have to run, or
content you need stored, or data you need analyzed. Basically you have stuff
that has to live and operate somewhere. Now historically, businesses had to run
applications in their own data centers, 'cause they didn't have a choice. Once
AWS became available, companies like yours could now run their applications in
other data centers they didn't actually own.

But the conversation is so much more than that, 'cause I want you to understand
a fundamental problem with any data center, doesn't matter who built it or who
owns it. Events can happen that could cause you to lose connection to that
building. If you run your own data center, you have to figure out how to answer
the question of what will you do when disaster strikes your building. You could
run a second data center, but real estate prices alone could stop you, much less
all the duplicate expense of hardware, employees, electricity, heating and
cooling, security. Most businesses simply end up just storing backups
somewhere, and then hope for the disaster to never come. And hope is not a
good business plan.

AWS answers the question of what happens when disaster strikes by building our
data centers in large groups we call Regions, and here's how it's designed.

Throughout the globe, AWS builds Regions to be closest to where the business
traffic demands. Locations like Paris, Tokyo, Sao Paulo, Dublin, Ohio. Inside each
Region, we have multiple data centers that have all the compute, storage, and
other services you need to run your applications. Each Region can be connected
to each other Region through a high speed fiber network, controlled by AWS, a
truly global operation from corner to corner if you need it to be. Now before we
get into the architecture of how each Region is built, it's important to know that
you, the business decision maker, gets to choose which Region you want to run
out of. And each Region is isolated from every other Region in the sense that
absolutely no data goes in or out of your environment in that Region without you
explicitly granting permission for that data to be moved. This is a critical security
conversation to have.

For example, you might have government compliance requirements that your
financial information in Frankfurt cannot leave Germany. Well this is absolutely
the way AWS operates outta the box. Any data stored in the Frankfurt Region
never leaves the Frankfurt Region, or data in the London region never leaves
London, or Sydney never leaves Sydney, unless you explicitly, with the right
credentials and permissions, request the data be exported.

Regional data sovereignty is part of the critical design of AWS Regions. With data
being subject to the local laws and statutes of the country where the Region
lives. So with that understanding, that your data, your application, lives and runs
in a Region, one of the first decisions you get to make is which Region do you
pick? There's four business factors that go into choosing a Region.

Number one, compliance. Before any of the other factors, you must first look at
your compliance requirements. Do you have a requirement your data must live in
UK boundaries? Then you should choose the London Region, full stop. None of
the rest of the options matter. Or let's say you must run inside Chinese borders.
Well then, you should choose on of our Chinese Regions. Most businesses,
though, are not governed by such strict regulations. So if you don't have a
compliance or regulatory control that dictates your Region, then you can look at
the other factors.

Number two, proximity. How close you are to your customer base is a major
factor because speed of light, still the law of the universe. If most of your
customers live in Singapore, consider running out of the Singapore Region. Now
you certainly can run out of Virginia, but the time it takes for the information to
be sent, or latency, between the US and Singapore is always going to be a factor.
Now we may be developing quantum computing, but quantum networking, still
some ways away. The time it takes light to travel around the world is always a
consideration. Locating close to your customer base, usually the right call.

Number three, feature availability. Sometimes the closest Region may not have
all the AWS features you want. Now here's one of the cool things about AWS. We
are constantly innovating on behalf of our customers. Every year, AWS releases
thousands of new features and products specifically to answer customer requests
and needs. But sometimes those brand new services take a lot of new physical
hardware that AWS has to build out to make the service operational. And
sometimes that means we have to build the service out one Region at a time. So
let's say your developers wanted to play with Amazon Braket, our new quantum
computing platform. Well then, they have to run in the Regions that already have
the hardware installed. Eventually, can we expect it to be in every Region? Well,
yeah, that's a good expectation, but if you wanna use it today, then that might
be your deciding factor.

Number four, pricing. Even when the hardware is equal one Region to the next,
some locations are just more expensive to operate in, for example, Brazil. Now
Brazil's tax structure is such that it costs AWS significantly more to operate the
exact same services there than in many other countries. The exact same
workload in Sao Paulo might be, let's say, 50% more expensive to run than out of
Oregon in the United States. Price can be determined by many factors, so AWS
has very transparent granular pricing that we'll continue to discuss in this class.
But know that each Region has a different price sheet. So if budget is your
primary concern, even if your customers live in Brazil, you might still wanna
operate in a different country, again, if price is your primary motivation.

So four key factors to choose a Region: Compliance, proximity, feature

availability, and pricing. When we come back, we'll look at the moving parts
inside a Region.
Selecting a Region
When determining the right Region for your services, data, and applications,
consider the following four business factors.
To learn more Regions, expand each of the following four categories.
Compliance with data governance and legal requirements
Depending on your company and location, you might need to run your data out
of specific areas. For example, if your company requires all of its data to reside
within the boundaries of the UK, you would choose the London Region.

Not all companies have location-specific data regulations, so you might need to
focus more on the other three factors.

Proximity to your customers

Selecting a Region that is close to your customers will help you to get content to
them faster. For example, your company is based in Washington, DC, and many
of your customers live in Singapore. You might consider running your
infrastructure in the Northern Virginia Region to be close to company
headquarters and run your applications from the Singapore Region.

Available services within a Region

Sometimes, the closest Region might not have all the features that you want to
offer to customers. AWS is frequently innovating by creating new services and
expanding on features within existing services. However, making new services
available around the world sometimes requires AWS to build out physical
hardware one Region at a time.

Suppose that your developers want to build an application that uses Amazon
Braket (AWS quantum computing platform). As of this course, Amazon Braket is
not yet available in every AWS Region around the world, so your developers
would have to run it in one of the Regions that already offers it.

Pricing
Suppose that you are considering running applications in both the United States
and Brazil. The way Brazil’s tax structure is set up, it might cost 50% more to run
the same workload out of the São Paulo Region compared to the Oregon Region.
You will learn in more detail that several factors determine pricing, but for now
know that the cost of services can vary from Region to Region.

If a Region is where all of the pieces and parts of your application live, some of
you might be thinking that we never actually solved the problem that we
presented in the last video. Let me restate the problem. You don't want to run
your application in a single building because a single building can fail for any
number of unavoidable reasons.

You may be thinking, if my business needs to be disaster proof, then it can't run
in just one location. Well, you're absolutely correct. AWS agrees with that
statement and that's why our Regions are not one location. To begin with, AWS
has data centers, lots of data centers, all around the world, and each Region is
made up of multiple data centers.

AWS calls a single data center or a group of data centers, an Availability Zone or
AZ. Each Availability Zone is one or more discrete data centers with redundant
power, networking, and connectivity. When you launch an Amazon EC2 instance,
it launches a virtual machine on a physical hardware that is installed in an
Availability Zone. This means each AWS Region consists of multiple isolated and
physically separate Availability Zones within a geographic Region.

But we don't build Availability Zones right next to each other because if a large
scale incident were to occur, like a natural disaster, for example, you could lose
connectivity to everything in that Availability Zone. The question what happens
in case of a disaster matters and if you are familiar with disaster recovery
planning, you might even have an idea of where we are going with this.

If you only run one EC2 instance, it only runs in one building, or one Availability
Zone and a large scale disaster occurs, will your application still be able to run
and serve your business? The obvious solution to this is to run multiple EC2
instances, just like we showed in the scaling example earlier. But the main thing
is don't run them in the same building. Don't even run them in the same street,
push them as far apart as you can before the speed of light tells you to stop if
you still want low latency communication. Turns out that the speed of light will
let us move these Availability Zones tens of miles apart from each other and still
keep single digit millisecond latency between these Availability Zones. Now, if a
disaster strikes, your application continues just fine because this disaster only
knocked over some of your capacity, not all.

And as we saw in the last section, you can rapidly spin up more capacity in the
remaining Availability Zones, thus allowing your business to continue operating
without interruption. And as a best practice with AWS, we always recommend
you run across at least two Availability Zones in a Region. This means
redundantly deploying your infrastructure in two different AZs.

But there's more to Regions than just places to run EC2. Many of the AWS
services run at the Region level, meaning they run synchronously across multiple
AZs without any additional effort on your part. Take the ELB we talked about
previously. This is actually a regional construct. It runs across all Availability
Zones, communicating with the EC2 instances that are running in a specific
Availability Zone. Regional services are by definition already highly available at
no additional cost of effort on your part.

So as you plan for high availability, any service that is listed as a regionally
scoped service, you'll already have that box checked. When we come back, let's
look at going outside the Regions for additional solutions.
Availability Zones
Spotlight on the us-west-1 Region. Northern California, Oregon, and GovCloud
(US-West) are separate Regions. The Northern California Region is called us-west-
1, and this Region contains three AZs (1a, 1b, and 1c). Then, within each AZ
there are three data centers.
An Availability Zone is a single data center or a group of data centers within a
Region. Availability Zones are located tens of miles apart from each other. This is
close enough to have low latency (the time between when content requested
and received) between Availability Zones. However, if a disaster occurs in one
part of the Region, they are distant enough to reduce the chance that multiple
Availability Zones are affected.
To review an example of running Amazon EC2 instances in multiple Availability
Zones, choose the arrow buttons.

Step 1
Amazon EC2 instance in a single Availability Zone
Suppose that you’re running an application on a single Amazon EC2 instance in
the Northern California Region. The instance is running in the us-west-1a
Availability Zone. If us-west-1a were to fail, you would lose your instance.

Step 2
Amazon EC2 instances in multiple Availability Zones
A best practice is to run applications across at least two Availability Zones in a
Region. In this example, you might choose to run a second Amazon EC2 instance
in us-west-1b.

Step 3
Availability Zone failure
If us-west-1a were to fail, your application would still be running in us-west-1b.

Edge Locations
One of the great things about the AWS global infrastructure, is the way it's
engineered to help you better serve your customers. Remember when selecting
a Region, one of the major criteria was proximity to your customers, but what if
you have customers all over the world or in cities that are not close to one of our
Regions? Well, think about our coffee shop. If you have a good customer base in
a new city, you can build a satellite store to service those customers.

You don't need to build an entire new headquarters or from an IT perspective, if

you have customers in Mumbai who need access to your data, but the data is
hosted out of the Tokyo Region, rather than having all the Mumbai-based
customers, send requests all the way to Tokyo, to access the data, just place a
copy locally or cache a copy in Mumbai. Caching copies of data closer to the
customers all around the world uses the concept of content delivery networks, or
CDNs.

CDNs are commonly used, and on AWS, we call our CDN Amazon CloudFront.
Amazon CloudFront is a service that helps deliver data, video, applications, and
APIs to customers around the world with low latency and high transfer speeds.
Amazon CloudFront uses what are called Edge locations, all around the world, to
help accelerate communication with users, no matter where they are.

Edge locations are separate from Regions, so you can push content from inside a
Region to a collection of Edge locations around the world, in order to accelerate
communication and content delivery. AWS Edge locations, also run more than
just CloudFront. They run a domain name service, or DNS, known as Amazon
Route 53, helping direct customers to the correct web locations with reliably low
latency.

But what if your business wants to use, AWS services inside their own building?
Well sure. AWS can do that for you. Introducing AWS Outposts, where AWS will
basically install a fully operational mini Region, right inside your own data center.
That's owned and operated by AWS, using 100% of AWS functionality, but
isolated within your own building. It's not a solution most customers need, but if
you have specific problems that can only be solved by staying in your own
building, we understand, AWS Outposts can help.

All right, there is so much more that we can say about AWS global infrastructure,
but let's keep it simple and stop here. So here's the key points. Number one,
Regions are geographically isolated areas, where you can access services
needed to run your enterprise. Number two, Regions contain Availability Zones,
that allow you to run across physically separated buildings, tens of miles of
separation, while keeping your application logically unified. Availability Zones
help you solve high availability and disaster recovery scenarios, without any
additional effort on your part, and number three, AWS Edge locations run
Amazon CloudFront to help get content closer to your customers, no matter
where they are in the world.
Edge locations
An edge location is a site that Amazon CloudFront uses to store cached copies of
your content closer to your customers for faster delivery.
To learn more, choose each of the numbered markers.
 1. Origin
Suppose that your company’s data is stored in Brazil, and you have
customers who live in China. To provide content to these customers,
you don’t need to move all the content to one of the Chinese
Regions.
2. Edge location
Instead of requiring your customers to get their data from Brazil,
you can cache a copy locally at an edge location that is close to
your customers in China.
3. Customer
When a customer in China requests one of your files, Amazon
CloudFront retrieves the file from the cache in the edge location and
delivers the file to the customer. The file is delivered to the
customer faster because it came from the edge location near China
instead of the original source in Brazil.

How to Provision AWS Resources

We've been talking about a few different AWS resources as well as the AWS
global infrastructure. You may be wondering, how do I actually interact with
these services? And the answer is APIs. In AWS, everything is an API call. An API
is an application programming interface. And what that means is, there are pre
determined ways for you to interact with AWS services. And you can invoke or
call these APIs to provision, configure, and manage your AWS resources.

For example, you can launch an EC2 instance or you can create an AWS Lambda
function. Each of those would be different requests and different API calls to
AWS. You can use the AWS Management Console, the AWS Command Line
Interface, the AWS Software Development Kits, or various other tools like AWS
CloudFormation, to create requests to send to AWS APIs to create and manage
AWS resources.
First, let's talk about the AWS Management Console. The AWS Management
Console is browser-based. Through the console, you can manage your AWS
resources visually and in a way that is easy to digest. This is great for getting
started and building your knowledge of the services. It's also useful for building
out test environments or viewing AWS bills, viewing monitoring and working with
other non technical resources. The AWS Management Console is most likely the
first place you will go when you are learning about AWS.

However, once you are up and running in a production type environment, you
don't want to rely on the point and click style that the console gives you to
create and manage your AWS resources. For example, in order to create an
Amazon EC2 Instance, you need to click through various screens, setting all the
configurations you want, and then you launch your instance. If later, you wanted
to launch another EC2 Instance, you would need to go back into the console and
click through those screens again to get it up and running. By having humans do
this sort of manual provisioning, you're opening yourself up to potential errors.
It's pretty easy to forget to check a checkbox or misspell something when you
are doing everything manually.

The answer to this problem is to use tools that allow you to script or program the
API calls. One tool you can use is the AWS Command Line Interface or CLI. The
CLI allows you to make API calls using the terminal on your machine. This is
different than the visual navigation style of the Management Console. Writing
commands using the CLI makes actions scriptable and repeatable. So, you can
write and run your commands to launch an EC2 Instance. And if you want to
launch another, you can just run the pre-written command again. This makes it
less susceptible to human error. And you can have these scripts run
automatically, like on a schedule or triggered by another process.

Automation is very important to having a successful and predictable cloud

deployment over time. Another way to interact with AWS is through the AWS
Software Development Kits or SDKs. The SDKs allow you to interact with AWS
resources through various programming languages. This makes it easy for
developers to create programs that use AWS without using the low level APIs, as
well as avoiding that manual resource creation that we just talked about. More on
that in a bit.
Ways to interact with AWS services
To learn about ways to interact with AWS services choose each of the following
three tabs.
AWS Management Console
AWS Command Line Interface
Software development kits
The AWS Management Console is a web-based interface for accessing and
managing AWS services. You can quickly access recently used services and
search for other services by name, keyword, or acronym. The console includes
wizards and automated workflows that can simplify the process of completing
tasks.

You can also use the AWS Console mobile application to perform tasks such as
monitoring resources, viewing alarms, and accessing billing information. Multiple
identities can stay logged into the AWS Console mobile app at the same time.
All right, let's continue to talk about how to interact with AWS. You have the AWS
Management Console, the CLI, and the SDKs, which are all sort of do it yourself
ways to provision and manage your AWS environment. If you want to provision a
resource, you can log into the console and point and click, you can write some
commands, or you can write some programs to do it. There are also other ways
you can manage your AWS environment using managed tools like AWS Elastic
Beanstalk, and AWS CloudFormation.

AWS Elastic Beanstalk is a service that helps you provision Amazon EC2-based
environments. Instead of clicking around the console or writing multiple
commands to build out your network, EC2 instances, scaling and Elastic Load
Balancers, you can instead provide your application code and desired
configurations to the AWS Elastic Beanstalk service, which then takes that
information and builds out your environment for you. AWS Elastic Beanstalk also
makes it easy to save environment configurations, so they can be deployed
again easily. AWS Elastic Beanstalk gives you the convenience of not having to
provision and manage all of these pieces separately, while still giving you the
visibility and control of the underlying resources. You get to focus on your
business application, not the infrastructure.

Another service you can use to help create automated and repeatable
deployments is AWS CloudFormation. AWS CloudFormation is an infrastructure as
code tool that allows you to define a wide variety of AWS resources in a
declarative way using JSON or YAML text-based documents called
CloudFormation templates. A declarative format like this allows you to define
what you want to build without specifying the details of exactly how to build it.
CloudFormation lets you define what you want and the CloudFormation engine
will worry about the details on calling APIs to get everything built out.

It also isn't just limited to EC2-based solutions. CloudFormation supports many

different AWS resources from storage, databases, analytics, machine learning,
and more. Once you define your resources in a CloudFormation template,
CloudFormation will parse the template and begin provisioning all the resources
you defined in parallel. CloudFormation manages all the calls to the backend
AWS APIs for you. You can run the same CloudFormation template in multiple
accounts or multiple regions, and it will create identical environments across
them. There is less room for human error as it is a totally automated process.

To recap, the AWS Management Console is great for learning and providing a
visual for the user. The AWS Management Console is a manual tool. So right off
the bat, it isn't a great option for automation. You can instead use the CLI to
script your interactions with AWS using the terminal. You can use the SDKs to
write programs to interact with AWS for you or you can use manage tools like
AWS Elastic Beanstalk or AWS CloudFormation.
AWS Elastic Beanstalk
With AWS Elastic Beanstalk, you provide code and configuration settings, and
Elastic Beanstalk deploys the resources necessary to perform the following tasks:
  Adjust capacity
 Load balancing
 Automatic scaling
 Application health monitoring
AWS CloudFormation
With AWS CloudFormation, you can treat your infrastructure as code. This means
that you can build an environment by writing lines of code instead of using the
AWS Management Console to individually provision resources.
AWS CloudFormation provisions your resources in a safe, repeatable manner,
enabling you to frequently build your infrastructure and applications without
having to perform manual actions. It determines the right operations to perform
when managing your stack and rolls back changes automatically if it detects
errors.

Module 3 Summary
In Module 3, you learned about the following concepts:
 AWS Regions and Availability Zones
 Edge locations and Amazon CloudFront
 The AWS Management Console, AWS CLI, and SDKs
 AWS Elastic Beanstalk
 AWS CloudFormation
Awesome stuff, I mean, we covered a lot of ground in here. And I don't mean that
just because we talked about AWS global infrastructure.

But seriously, we covered how logical clusters of data centers make up

Availability Zones, Availability Zones in turn make up Regions, and those are
spread globally. You then choose what Regions and Availability Zones you want to
operate out of and as a best practice, you should always deploy infrastructure
across at least two Availability Zones. And some AWS services like Elastic Load
Balancing, Amazon SQS, and Amazon SNS already do this for you.

We also talked about Edge locations and how you can deploy content there to
speed up delivery to your customers. We even touched upon edge devices like
AWS Outposts which allow you to run AWS infrastructure right in your own data
center.

Another thing we discussed was how to provision AWS resources through various
options, such as the AWS Management Console, the SDK, CLI, AWS Elastic
Beanstalk, and AWS CloudFormation, where you learned how you can set up your
infrastructure as code.

I hope you learned how globally available AWS is and how easy it is to get
started with provisioning resources.
Additional resources
Review these resources to learn more about the concepts that were explored in
Module 3.
 Global Infrastructure (opens in a new tab)
 Interactive map of the AWS Global Infrastructure (opens in a new tab)
 Regions and Availability Zones (opens in a new tab)
 AWS Networking and Content Delivery Blog (opens in a new tab)
 Tools to Build on AWS (opens in a new tab)
 AWS Customer Stories: Content Delivery
Module 4 Introduction
Learning objectives
In this module, you will learn how to:
 Describe the basic concepts of networking.
 Describe the difference between public and private networking resources.
 Explain a virtual private gateway using a real-life scenario.
 Explain a virtual private network (VPN) using a real-life scenario.
 Describe the benefit of AWS Direct Connect.
 Describe the benefit of hybrid deployments.
 Describe the layers of security used in an IT strategy.
 Describe the services customers use to interact with the AWS global
network.

If we think back to our coffee shop or AWS account, things by now should be
running smoothly. Although, what if we had a few eager customers who wanted
to give their orders directly to the baristas instead of the cashier out in front?
Well, it doesn't make sense to allow every customer to be able to interact with
our baristas since they are focused on brewing some fresh caffeinated
beverages. So what do we do?

That's right, kids, say it with me, Amazon Virtual Private Cloud, or VPCs, as
they're affectionately known. A VPC lets you provision a logically isolated section
of the AWS Cloud where you can launch AWS resources in a virtual network that
you define. These resources can be public facing so they have access to the
internet, or private with no internet access, usually for backend services like
databases or application servers. The public and private grouping of resources
are known as subnets and they are ranges of IP addresses in your VPC.

Now, in our coffee shop, we have different employees and one is a cashier. They
take customers' orders and thus we want customers to interact with them, so we
put them in what we call a public subnet. Hence they can talk to the customers
or the internet. But for our baristas, we want them to focus on making coffee and
not interact with customers directly, so we put them in a private subnet.

Connectivity to AWS
A VPC, or Virtual Private Cloud, is essentially your own private network in AWS. A
VPC allows you to define your private IP range for your AWS resources, and you
place things like EC2 instances and ELBs inside of your VPC.

Now you don't just go throw your resources into a VPC and move on. You place
them into different subnets. Subnets are chunks of IP addresses in your VPC that
allow you to group resources together. Subnets, along with networking rules we
will cover later, control whether resources are either publicly or privately
available. What we haven't told you yet is there are actually ways you can
control what traffic gets into your VPC at all. What I mean by this is, for some
VPCs, you might have internet-facing resources that the public should be able to
reach, like a public website, for example.

However, in other scenarios, you might have resources that you only want to be
reachable if someone is logged into your private network. This might be internal
services, like an HR application or a backend database. First, let's talk about
public-facing resources. In order to allow traffic from the public internet to flow
into and out of your VPC, you must attach what is called an internet gateway, or
IGW, to your VPC.

An internet gateway is like a doorway that is open to the public. Think of our
coffee shop. Without a front door, the customers couldn't get in and order their
coffee, so we install a front door and the people can then go in and out of that
door when coming and going from our shop. The front door in this example is like
an internet gateway. Without it, no one can reach the resources placed inside of
your VPC.

Next, let's talk about a VPC with all internal private resources. We don't want just
anyone from anywhere to be able to reach these resources. So we don't want an
internet gateway attached to our VPC. Instead, we want a private gateway that
only allows people in if they are coming from an approved network, not the
public internet. This private doorway is called a virtual private gateway, and it
allows you to create a VPN connection between a private network, like your on-
premises data center or internal corporate network to your VPC.

To relate this back to the coffee shop, this would be like having a private bus
route going from my building to the coffee shop. If I want to go get coffee, I first
must badge into the building, thus authenticating my identity, and then I can
take the secret bus route to the internal coffee shop that only people from my
building can use. So if you want to establish an encrypted VPN connection to
your private internal AWS resources, you would need to attach a virtual private
gateway to your VPC.

Now the problem with our super secret bus route is that it still uses the open
road. It's susceptible to traffic jams and slowdowns caused by the rest of the
world going about their business. The same thing is true for VPN connections.
They are private and they are encrypted, but they still use a regular internet
connection that has bandwidth that is being shared by many people using the
internet.

So what I've done to make things more reliable and less susceptible to
slowdowns is I made a totally separate magic doorway that leads directly from
the studio into the coffee shop. No one else driving around on the road can slow
me down because this is my direct doorway; no one else can use it. What, did
you not have a secret magic doorway into your favorite coffee shop? All right,
moving on. The point being is you still want a private connection, but you want it
to be dedicated and shared with no one else. You want the lowest amount of
latency possible with the highest amount of security possible.

With AWS, you can achieve that using what is called AWS Direct Connect. Direct
Connect allows you to establish a completely private, dedicated fiber connection
from your data center to AWS. You work with a Direct Connect partner in your
area to establish this connection, because like my magic doorway, AWS Direct
Connect provides a physical line that connects your network to your AWS VPC.
This can help you meet high regulatory and compliance needs, as well as
sidestep any potential bandwidth issues. It's also important to note that one VPC
might have multiple types of gateways attached for multiple types of resources
all residing in the same VPC, just in different subnets.
Thanks for listening. I'm gonna sit here and keep ordering coffees from my magic
door. See ya.
Amazon Virtual Private Cloud (Amazon VPC)
Imagine the millions of customers who use AWS services. Also, imagine the
millions of resources that these customers have created, such as Amazon EC2
instances. Without boundaries around all of these resources, network traffic
would be able to flow between them unrestricted.
A networking service that you can use to establish boundaries around your AWS
resources is Amazon Virtual Private Cloud (Amazon VPC)(opens in a new
tab).
Amazon VPC enables you to provision an isolated section of the AWS Cloud. In
this isolated section, you can launch resources in a virtual network that you
define. Within a virtual private cloud (VPC), you can organize your resources into
subnets. A subnet is a section of a VPC that can contain resources such as
Amazon EC2 instances.
Internet gateway
To allow public traffic from the internet to access your VPC, you attach
an internet gateway to the VPC.

Internet gateway icon attached to a VPC that holds three EC2 instances. An
arrow connects the client to the gateway over the internet indicating that the
client's request has gained access to the VPC.
An internet gateway is a connection between a VPC and the internet. You can
think of an internet gateway as being similar to a doorway that customers use to
enter the coffee shop. Without an internet gateway, no one can access the
resources within your VPC.
What if you have a VPC that includes only private resources?
Virtual private gateway
To access private resources in a VPC, you can use a virtual private gateway.
Here’s an example of how a virtual private gateway works. You can think of the
internet as the road between your home and the coffee shop. Suppose that you
are traveling on this road with a bodyguard to protect you. You are still using the
same road as other customers, but with an extra layer of protection.
The bodyguard is like a virtual private network (VPN) connection that encrypts
(or protects) your internet traffic from all the other requests around it.
The virtual private gateway is the component that allows protected internet
traffic to enter into the VPC. Even though your connection to the coffee shop has
extra protection, traffic jams are possible because you’re using the same road as
other customers.
A virtual private gateway enables you to establish a virtual private network (VPN)
connection between your VPC and a private network, such as an on-premises
data center or internal corporate network. A virtual private gateway allows traffic
into the VPC only if it is coming from an approved network.
AWS Direct Connect
AWS Direct Connect(opens in a new tab) is a service that lets you to establish
a dedicated private connection between your data center and a VPC.
Suppose that there is an apartment building with a hallway directly linking the
building to the coffee shop. Only the residents of the apartment building can
travel through this hallway.
This private hallway provides the same type of dedicated connection as AWS
Direct Connect. Residents are able to get into the coffee shop without needing to
use the public road shared with other customers.

A corporate data center routes network traffic to an AWS Direct Connect location.
That traffic is then routed to a VPC through a virtual private gateway. All network
traffic between the corporate data center and VPC flows through this dedicated
private connection.
The private connection that AWS Direct Connect provides helps you to reduce
network costs and increase the amount of bandwidth that can travel through
your network.

Subnets and Network Access Control Lists

Welcome to your VPC. You can think of it as a hardened fortress where nothing
goes in or out without explicit permission. You have a gateway on the VPC that
only permits traffic in or out of the VPC. But that only covers perimeter, and
that's only one part of network security that you should be focusing on as part of
your IT strategy.

AWS has a wide range of tools that cover every layer of security: network
hardening, application security, user identity, authentication and authorization,
distributed denial-of-service or DDoS prevention, data integrity, encryption,
much more. We're gonna talk about a few of these key pieces. And if you really
wanna know more about security, please follow the links in this page to be
directed to more information and additional training on how to lock your
infrastructure down tighter than Aunt Robin's secret lemon pie recipe, and ain't
nobody getting that recipe.

Today, I wanna talk about a few aspects of network hardening looking at what
happens inside the VPC. Now, the only technical reason to use subnets in a VPC
is to control access to the gateways. The public subnets have access to the
internet gateway; the private subnets do not. But subnets can also control traffic
permissions. Packets are messages from the internet, and every packet that
crosses the subnet boundaries gets checked against something called a network
access control list or network ACL. This check is to see if the packet has
permissions to either leave or enter the subnet based on who it was sent from
and how it's trying to communicate.

You can think of network ACLs as passport control officers. If you're on the
approved list, you get through. If you're not on the list, or if you're explicitly on
the do-not-enter list, then you get blocked. Network ACLs check traffic going into
and leaving a subnet, just like passport control. The list gets checked on your
way into a country and on the way out. And just because you were let in doesn't
necessarily mean they're gonna let you out. Approved traffic can be sent on its
way, and potentially harmful traffic, like attempts to gain control of a system
through administrative requests, they get blocked before they ever touch the
target. You can't hack what you can't touch.

Now, this sounds like great security, but it doesn't answer all of the network
control issues. Because a network ACL only gets to evaluate a packet if it crosses
a subnet boundary, in or out. It doesn't evaluate if a packet can reach a specific
EC2 instance or not. Sometimes, you'll have multiple EC2 instances in the same
subnet, but they might have different rules around who can send them
messages, what port those messages are allowed to be sent to. So you need
instance level network security as well.

To solve instance level access questions, we introduce security groups. Every

EC2 instance, when it's launched, automatically comes with a security group.
And by default, the security group does not allow any traffic into the instance at
all. All ports are blocked; all IP addresses sending packets are blocked. That's
very secure, but perhaps not very useful. If you want an instance to actually
accept traffic from the outside, like say, a message from a front end instance or a
message from the Internet. So obviously, you can modify the security group to
accept a specific type of traffic. In the case of a website, you want web-based
traffic or HTTPS to be accepted but not other types of traffic, say an operating
system or administration requests.
If NACLs are a passport control, a security group is like the doorman at your
building, the building being the EC2 Instance, in this case. The doorman will
check a list to ensure that someone is allowed to enter the building but won't
bother check the list on the way out. With security groups, you allow specific
traffic in and by default, all traffic is allowed out. Now, wait a minute, Blaine. You
just described two different engines each doing the exact same job. Let good
packets in, keep bad packets out. The key difference between a security group
and a network ACL is the security group is stateful, meaning, as we talked about,
it has some kind of a memory when it comes to who to allow in or out, and the
network ACL is stateless, which remembers nothing and checks every single
packet that crosses its border regardless of any circumstances.

You know, this metaphor is important to understand. So I wanna illustrate the

round trip of a packet as it goes from one instance to another instance in a
different subnet. Now, this traffic management, it doesn't care about the
contents of the packet itself. In fact, it doesn't even open the envelope, it can't.
All it can do is check to see if the sender is on the approved list.
All right. Let's start with instance A. We wanna send a packet from instance A to
instance B in a different subnet, same VPC, different subnets. So instance A
sends the packet. Now, the first thing that happens is that packet meets the
boundary of the security group of instance A. By default, all outbound traffic is
allowed from a security group. So you can walk right by the doormen and leave,
cool, right. The packet made it past the security group of instance A. Now it has
to leave the subnet boundary. At the boundary, the passport must now make it
through passport control, the network ACL. The network ACL doesn't care about
what the security group allowed. It has its own list of who can pass and who
can't. If the target address is allowed, you can keep going on your journey, which
it is.

So now we have exited the original subnet and now the packet goes to the target
subnet where instance B lives. Now at this target subnet, once again, we have
passport control. Just because the packet was allowed out of its home country
does not mean that it can enter the destination country or subnet in this case.
They both have unique passport officers with their own checklists. You have to be
approved on both lists, or you could get turned away at the border. Well, turns
out the packet is on the approved list for this subnet, so it's allowed to enter
through the network ACL into the subnet. Almost there. Now, we're approaching
the target instance, instance B. Every EC2 Instance has their own security group.
You wanna enter this instance, the doorman will need to check to see if you're
allowed in, and we're on the list. The packet has reached the target instance.

Once the transaction's complete, now it's just time to come home. It's the return
traffic pattern. It's the most interesting, because this is where the stateful versus
stateless nature of the different engines come into play. Because the packet still
has to be evaluated at each checkpoint. Security groups, by default, allow all
return traffic. So they don't have to check a list to see if they're allowed out.
Instead, they automatically allow the return traffic to pass by no matter what.
Passport control here at the subnet boundary, these network ACLs do not
remember state. They don't care that the packet came in here. It might be on a
you-can't-leave list. Every ingress and egress is checked with the appropriate list.
The package return address has to be on their approved list to make it across the
border. Made it to the border of the origin subnet, but we have to negotiate
passport network ACL control here as well. Stateless controls, means it always
checks its list.
The packet pass the network ACL, the subnet level, which means the packets
now made it back to instance A but the security group, the doorman is still in
charge here. The key difference though is these security groups are stateful. The
security group recognizes the packet from before. So it doesn't need to check to
see if it's allowed in. Come on home.

Now, this may seem like we spent a lot of effort just getting a packet from one
instance to another and back. You might be concerned about all the network
overhead this might generate. The reality is all of these exchanges happen
instantly as part of how AWS Networking actually works. If you wanna know the
technology that makes all that possible, well, then you need to sign up for a
completely different set of trainings. Good network security will take advantage
of both network ACLs and security groups, because security in-depth is critical
for modern architectures.
To learn more about the role of subnets within a VPC, review the following
example from the coffee shop.
First, customers give their orders to the cashier. The cashier then passes the
orders to the barista. This process allows the line to keep running smoothly as
more customers come in.
Suppose that some customers try to skip the cashier line and give their orders
directly to the barista. This disrupts the flow of traffic and results in customers
accessing a part of the coffee shop that is restricted to them.

To fix this, the owners of the coffee shop divide the counter area by placing the
cashier and the barista in separate workstations. The cashier’s workstation is
public facing and designed to receive customers. The barista’s area is private.
The barista can still receive orders from the cashier but not directly from
customers.
A cashier, a barista, and three customers in line. The icon for the first customer
in line has an arrow pointing to cashier showing that the customer gives their
order to the cashier. Then the cashier icon has an arrow pointing to barista icon
showing that the cashier forwards the customer's order to the barista. The last
customer in line tries to give their order directly to the barista, but they're
blocked from doing so.
This is similar to how you can use AWS networking services to isolate resources
and determine exactly how network traffic flows.
In the coffee shop, you can think of the counter area as a VPC. The counter area
divides into two separate areas for the cashier’s workstation and the barista’s
workstation. In a VPC, subnets are separate areas that are used to group
together resources.
Subnets
A subnet is a section of a VPC in which you can group resources based on
security or operational needs. Subnets can be public or private.
Public subnets contain resources that need to be accessible by the public, such
as an online store’s website.
Private subnets contain resources that should be accessible only through your
private network, such as a database that contains customers’ personal
information and order histories.
In a VPC, subnets can communicate with each other. For example, you might
have an application that involves Amazon EC2 instances in a public subnet
communicating with databases that are located in a private subnet.
Network traffic in a VPC
When a customer requests data from an application hosted in the AWS Cloud,
this request is sent as a packet. A packet is a unit of data sent over the internet
or a network.
It enters into a VPC through an internet gateway. Before a packet can enter into a
subnet or exit from a subnet, it checks for permissions. These permissions
indicate who sent the packet and how the packet is trying to communicate with
the resources in a subnet.
The VPC component that checks packet permissions for subnets is a network
access control list (ACL)(opens in a new tab).
Network ACLs
A network ACL is a virtual firewall that controls inbound and outbound traffic at
the subnet level.
For example, step outside of the coffee shop and imagine that you are in an
airport. In the airport, travelers are trying to enter into a different country. You
can think of the travelers as packets and the passport control officer as a
network ACL. The passport control officer checks travelers’ credentials when they
are both entering and exiting out of the country. If a traveler is on an approved
list, they are able to get through. However, if they are not on the approved list or
are explicitly on a list of banned travelers, they cannot come in.

Each AWS account includes a default network ACL. When configuring your VPC,
you can use your account’s default network ACL or create custom network ACLs.
By default, your account’s default network ACL allows all inbound and outbound
traffic, but you can modify it by adding your own rules. For custom network ACLs,
all inbound and outbound traffic is denied until you add rules to specify which
traffic to allow. Additionally, all network ACLs have an explicit deny rule. This rule
ensures that if a packet doesn’t match any of the other rules on the list, the
packet is denied.
Stateless packet filtering
Network ACLs perform stateless packet filtering. They remember nothing and
check packets that cross the subnet border each way: inbound and outbound.
Recall the previous example of a traveler who wants to enter into a different
country. This is similar to sending a request out from an Amazon EC2 instance
and to the internet.
When a packet response for that request comes back to the subnet, the network
ACL does not remember your previous request. The network ACL checks the
packet response against its list of rules to determine whether to allow or deny.

After a packet has entered a subnet, it must have its permissions evaluated for
resources within the subnet, such as Amazon EC2 instances.
The VPC component that checks packet permissions for an Amazon EC2 instance
is a security group(opens in a new tab).
Security groups
A security group is a virtual firewall that controls inbound and outbound traffic for
an Amazon EC2 instance.
By default, a security group denies all inbound traffic and allows all outbound
traffic. You can add custom rules to configure which traffic should be allowed;
any other traffic would then be denied
For this example, suppose that you are in an apartment building with a door
attendant who greets guests in the lobby. You can think of the guests as packets
and the door attendant as a security group. As guests arrive, the door attendant
checks a list to ensure they can enter the building. However, the door attendant
does not check the list again when guests are exiting the building
If you have multiple Amazon EC2 instances within the same VPC, you can
associate them with the same security group or use different security groups for
each instance.
Stateful packet filtering
Security groups perform stateful packet filtering. They remember previous
decisions made for incoming packets.
Consider the same example of sending a request out from an Amazon EC2
instance to the internet.
When a packet response for that request returns to the instance, the security
group remembers your previous request. The security group allows the response
to proceed, regardless of inbound security group rules.
With both network ACLs and security groups, you can configure custom rules for
the traffic in your VPC. As you continue to learn more about AWS security and
networking, make sure to understand the differences between network ACLs and
security groups.

A packet travels over the internet from a client to the internet gateway and into
the VPC. Then the pack goes through the network access control list and
accesses the public subnet, where two EC2 instances are located.
VPC component recall
Recall the purpose of the following four VPC components. Compare your
response by choosing each VPC component flashcard.
To practice recalling VPC components, select each of the following flashcards by
choosing them.

Global Networking
We've been talking a lot about how you interact with your AWS infrastructure.
But how do your customers interact with your AWS infrastructure? Well, if you
have a website hosted at AWS, then customers usually enter your website into
their browser, hit Enter, some magic happens, and the site opens up.

But how does this magic work? Well, just like this magic coin that I have here,
you know, you take a bite, and it's, it's back. Well, not quite like that, but I'm
going to take you through two services, which would help in the website case.
The first one being Route 53. Route 53 is AWS's domain name service, or DNS,
and it's highly available and scalable. But wait, what is DNS, you say? Think of
DNS as a translation service. But instead of translating between languages, it
translates website names into IP, or Internet Protocol, addresses that computers
can read.
For example, when we enter a website address into our browser, it contacts
Route 53 to obtain the IP address of the site, say, 192.1.1.1, then it routes your
computer or browser to that address. If we go further, Route 53 can direct traffic
to different endpoints using several different routing policies, such as latency-
based routing, geolocation DNS, geoproximity, and weighted round robin. If we
take geolocation DNS, that means we direct traffic based on where the customer
is located. So traffic coming from say North America is routed to the Oregon
Region, and traffic in Ireland is routed to the Dublin Region, as an example.

You can even use Route 53 to register domain names, so you can buy and
manage your own domain names right on AWS.

Speaking of websites, there is another service which can help speed up delivery
of website assets to customers, Amazon CloudFront. If you remember, we talked
about Edge locations earlier in the course, these locations are serving content as
close to customers as possible, and one part of that, is the content delivery
network, or CDN. For those who need reminding, a CDN is a network that helps to
deliver edge content to users based on their geographic location.

If we go back to our North America versus Ireland example, say we have a user
in Seattle, and they want to access a website, to speed this up, we host the site
in Oregon, and we deploy our static web assets, like images and GIFs in
CloudFront in North America. This means they get content delivered as close to
them as possible, North America in this case, when they access the site. But for
our Irish users, it doesn't make sense to deliver those assets out of Oregon, as
the latency is not favorable. Thus we deploy those same static assets in
CloudFront, but this time in the Dublin Region. That means they can access the
same content, but from a location closer to them, which in turn improves
latency.

I hope you're content after learning about these two services. Thanks for
following along, and I'm going to disappear just like this red cloth. Tada!
Domain Name System (DNS)
Suppose that AnyCompany has a website hosted in the AWS Cloud. Customers
enter the web address into their browser, and they are able to access the
website. This happens because of Domain Name System (DNS) resolution.
DNS resolution involves a customer DNS resolver communicating with a
company DNS server.
You can think of DNS as being the phone book of the internet. DNS resolution is
the process of translating a domain name to an IP address.
A client connects to a DNS resolver looking for a domain. The resolver forwards
the request to the DNS server, which returns the IP address to the resolver.
For example, suppose that you want to visit AnyCompany’s website.
1. 1
When you enter the domain name into your browser, this request is sent to a
customer DNS resolver.
2. 2
The customer DNS resolver asks the company DNS server for the IP address that
corresponds to AnyCompany’s website.
3. 3
The company DNS server responds by providing the IP address for
AnyCompany’s website, 192.0.2.0.
Amazon Route 53
Amazon Route 53(opens in a new tab) is a DNS web service. It gives
developers and businesses a reliable way to route end users to internet
applications hosted in AWS.
Amazon Route 53 connects user requests to infrastructure running in AWS (such
as Amazon EC2 instances and load balancers). It can route users to infrastructure
outside of AWS.
Another feature of Route 53 is the ability to manage the DNS records for domain
names. You can register new domain names directly in Route 53. You can also
transfer DNS records for existing domain names managed by other domain
registrars. This enables you to manage all of your domain names within a single
location.
In the previous module, you learned about Amazon CloudFront, a content
delivery service. The following example describes how Route 53 and Amazon
CloudFront work together to deliver content to customers.
Example: How Amazon Route 53 and Amazon CloudFront deliver content

Suppose that AnyCompany’s application is running on several Amazon EC2

instances. These instances are in an Auto Scaling group that attaches to an
Application Load Balancer.
1. A customer requests data from the application by going to AnyCompany’s
website.
2. Amazon Route 53 uses DNS resolution to identify AnyCompany.com’s
corresponding IP address, 192.0.2.0. This information is sent back to the
customer.
3. The customer’s request is sent to the nearest edge location through
Amazon CloudFront.
4. Amazon CloudFront connects to the Application Load Balancer, which
sends the incoming packet to an Amazon EC2 instance.