Introduction to AWS Cloud

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 fulfills it by returning
the information to the client.

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.

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.

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.

Cloud Computing
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 (3) cloud computing deployment models are cloud-based, on-premises, and
hybrid.

To learn more about deployment models, choose each of the following three tabs.

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 center. Though this model is much like legacy IT infrastructure, its incorporation
of application management and virtualization technologies helps to increase resource
utilization.

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.
Questions to self: What are legacy applications? Examples of legacy applications?

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 (6) categories.

Trade upfront expense for variable expense

Upfront expense refers to data centers, 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 centers 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 centers

Computing in data centers 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

(accumulate/amass/store) 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
(install/organize) applications.

This flexibility provides you with more time to experiment and innovate. When computing in
data centers, 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 (install/organize) applications to
customers around the world quickly, while providing them with low latency (expectancy). 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.

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.

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
[commands/request/demands].

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.

Amazon EC2 Instance [Command] Types

Amazon EC2 instance types or families
Amazon EC2 instance types 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 [command/request/order] types, expand each
of the following five (5) categories.

General purpose instances provide a (good) 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 (calculate/process) 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.
Keyword: high performing processer, high performance, compute intensive, many transactions

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.
Keyword: high performing databases, large amount of data memory
[recollection/recall/remembrance]

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 [fast-tracked] computing instances are ideal for workloads such as graphics
applications, game streaming, and application streaming.
Keyword: Accelerated, expedite data processing, floating-point calculations
Questions to self: What are floating pint calculations?

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

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. Reserved Instances require a
commitment of either 1 year or 3 years. The 3-year option offers a larger discount.

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

Region: 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).


EC2 Instance Savings Plans

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.

***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.
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 analyze 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
Scalability
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.

Major benefit of AWS, scalability and elasticity, or how capacity can grow and shrink, based on
business needs.
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 gonna 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.

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 or request/commands 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 [commands/request], 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.

Elastic Load Balancing

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 [like a host]. 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.

Ensuring that no single Amazon EC2 instance has to carry the full workload on its own.

Elastic Load Balancing is the AWS service that automatically distributes incoming application traffic across
multiple resources, such as Amazon EC2 instances. This helps to ensure that no single resource becomes
overutilized.

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 [such as a host] 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.

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)

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.

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.

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.

The correct response option is Amazon Simple Notification Service (Amazon SNS).

Amazon SNS is a publish/subscribe service. Using Amazon SNS topics, a publisher publishes messages to
subscribers.

The other response options are incorrect because:

 Amazon Simple Queue Service (Amazon SQS) is a message queuing service. It does not use the
message subscription and topic model that is involved with Amazon SNS.
 Amazon EC2 Auto Scaling enables you to automatically add or remove Amazon EC2 instances in
response to changing application demand.
 Elastic Load Balancing is the AWS service that automatically distributes incoming application traffic
across multiple resources, such as Amazon EC2 instances.

Amazon Simple Queue Service (Amazon SQS)

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.

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. Lambda, Lambda, Lambda!

AWS Lambda
AWS Lambda is a service that lets you run code without needing to provision (prep) 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.

 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
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.
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.
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) is a highly scalable, high-performance
container management system that enables you to run and scale containerized applications on
AWS. **Please explain containerized applications.
Amazon ECS supports Docker containers. Dockers 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) is a fully managed service that you can
use to run Kubernetes on AWS.
Kubernetes 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.

You want to deploy and manage containerized applications. Which service should you use?
Amazon Elastic Kubernetes Service (Amazon EKS).

Amazon EKS is a fully managed Kubernetes service. Kubernetes is open-source software

that enables you to deploy and manage containerized applications at scale.

The other response options are incorrect because:

 AWS Lambda is a service that lets you run code without provisioning or managing
servers.
 Amazon Simple Queue Service (Amazon SQS) is a service that enables you to send,
store, and receive messages between software components through a queue (line).
 Amazon Simple Notification Service (Amazon SNS) is a publish/subscribe service.
Using Amazon SNS topics, a publisher publishes messages to subscribers.

AWS Fargate
AWS Fargate 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.

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

 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.

 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.
You want to use an Amazon EC2 instance for a batch processing workload. What would be
the best Amazon EC2 instance type to use?
The correct response option is Compute optimized.

The other response options are incorrect because:

 General purpose instances provide a balance of compute, memory, and networking resources. This
instance family would not be the best choice for the application in this scenario. Compute optimized
instances are more well suited for batch processing workloads than general purpose instances.
 Memory optimized instances are more ideal for workloads that process large datasets in memory,
such as high-performance databases.
 Storage optimized instances are designed for workloads that require high, sequential read and write
access to large datasets on local storage. The question does not specify the size of data that will be
processed. Batch processing involves processing data in groups. A compute optimized instance is
ideal for this type of workload, which would benefit from a high-performance processor.

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 want to 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.

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.

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.

To understand the global infrastructure AWS, 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. Once AWS became available, companies like
yours could now run their applications in other data centers they didn't actually own.

I want you to understand a fundamental problem with any data center: 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. This is absolutely the way AWS operates out of
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 [control] 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 are four (4) business factors that
go into choosing a Region.

1. 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 one 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.

2. 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.
 3. 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. 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 want to use it today, then that might be
your deciding factor.

4. 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 want to operate in a different
country, again, if price is your primary motivation.

Four (4) 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.