

 Looks like things are really moving forward in our coffee shop.
Though, we had a few eager customers go full steam ahead and yell
their orders at the baristas! Tsk tsk.

 They should be politely asking the cashiers instead. This does bring
up an interesting point, however. It just doesn't make sense to allow
every customer to be able to interact with the baristas in the back.
After all, our baristas need to stay focused on crafting caffeinated
beverages. So, what do we do?

 Well, we need to limit access to the baristas, and let customers

interact only with our cashiers. And wouldn’t you know it, we can
use AWS networking to accomplish that. Specifically, a networking
concept called Amazon Virtual Private Cloud, or VPC. VPCs help you
provision a logically isolated section of the AWS Cloud.

 In this virtual network, you can launch whatever resources you

decide on. More importantly, these resources can be public or
private. Public-facing resources have access to the internet,
whereas private resources do not have internet access.

 This is perfect for our coffee shop. We can make our cashiers
publicly-accessible so they can interact with our customers to take
their order and process payments. We can then prevent our
customers from interacting directly with the baristas by making
them private resources. This means, hey, I can focus on making
drinks! Ahhhhh, refreshing.

 Okay, time to dive into more networking concepts. Good luck!

 Networking components
 So far, you've learned about the AWS Cloud, AWS Regions, and
Availability Zones. Now you will review two more foundational
networking components you will use in the AWS Cloud.











 To reiterate, a VPC, or virtual private cloud, is essentially your own
private network in AWS. When you use a VPC, you can define your
private IP range for your AWS resources and place things, like EC2
instances and elastic load balancers, inside of your VPC.

 Now, you don't just go throwing your resources into one big VPC
network space and then move on. Instead, you place them into
different specific subnets. Subnets are chunks of IP addresses in
your VPC that you can use to group resources together. Subnets,
along with networking rules that we will cover later, control whether
resources are either publicly or privately available.

 This idea of public compared to private access to resources is super

important. For some VPCs, you might have internet-facing resources
that the public should be able to reach, like a public website or a
load balancer, 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. To allow traffic from

the public internet to flow into and out of your VPC, you must attach
what is called an internet gateway to your VPC. An internet gateway
is like a doorway that is open to the public.

 Think of the coffee shop. Without a front door, the customers

couldn't get in and order their coffee. So, you install an entrance,
and the people can enter and exit when coming and going from the
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, when
you don't want an internet gateway attached to your VPC. Instead,
you 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 if the coffee
shop was located inside of a private corporate office building. If I
want to go get coffee, I have to badge in to verify my identity. Then
I can access the internal coffee shop that only people with access to
the building can use. So, if you want to establish an encrypted VPN
connection to your private internal AWS resources, you need to
attach a virtual private gateway to your VPC.
 Now, something to note about the coffee shop in the private
corporate office building is that this office building is shared by
multiple companies, and there are a lot of people who work here.
Even though I have special access to the coffee shop, I still might
have to wait for the elevator, navigate crowded hallways, or stand in
line.

 This is similar to how a VPN works. While it provides a secure

connection, it still routes your traffic through a shared network,
which can sometimes lead to slowdowns, especially when many
people are using it at the same time. It’s not that the VPN itself is
slow or a bad option, but rather you may need higher bandwidth or
a dedicated line in certain scenarios.

 Now, if I had a direct, super-secret magic doorway that led from the
studio straight into the coffee shop, I'd bypass any congestion and
have a reliable, high throughput, coffee connection at any time.
That sounds pretty nice. This is a similar idea behind wanting
dedicated private connection to AWS.

 With AWS, you can achieve that using a service called AWS Direct
Connect. Direct Connect lets you establish a completely private,
dedicated fiber connection from your data center to AWS. It ensures
both security and consistent high performance. You work with a
Direct Connect partner in your area to establish this connection
because, like my magic doorway, Direct Connect provides a physical
line that connects your network to your Amazon VPC. This can help
you meet regulatory and compliance needs, as well as sidestep any
potential bandwidth issues.

 Thanks for listening. I'm gonna hang out here and keep ordering
magic drinks from my magic door. See ya.


 Establishing boundaries around AWS

resources
 When organizing your resources in the AWS Cloud, you need to be
able to group certain functions together and isolate them from the
public, or make them available to the public. You've been
introduced to what Amazon VPCs do. Next, you will review the
benefits.






 Several of the preceding networking components have similar abbreviations and are
often confused. These components are core building blocks that you'll use in many
AWS Cloud solutions.





 Securely connect a remote workforce to

AWS Cloud resources
 Imagine a company with a recent acquisition needing to securely
connect their new remote workforce to their AWS Cloud resources.
Even the largest companies with worldwide remote workers can
quickly scale up and connect to the AWS Cloud. That's where AWS
Client VPN can help.

















 Welcome to your virtual private cloud, or VPC. You can think of it as

a hardened fortress, where nothing goes in or out without explicit
permission via the appropriate gateways. 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: Firewalls,
distributed denial-of-service, or DDoS prevention, encryption, and
 much more. We're gonna talk about these a bit later in the security
section.

 Today, I wanna talk about a few aspects of network hardening

looking at what happens inside the VPC. One of the main reasons 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. The list
gets checked on your way in and on the way out. And just because
traffic is let in doesn't necessarily mean they're gonna let responses
back out. Only explicitly approved traffic can be sent on its way.

 Now, this sounds like great security, but it doesn't answer all of the
network control issues. 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
will have multiple EC2 instances in the same subnet, but they might
have different rules around who can send them messages and 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
frontend 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 like HTTPS to

be accepted but not other types of traffic. If network ACLs 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 to check the list on the way out. With
 security groups, you allow specific traffic in, and by default, all
traffic is allowed out.

 I just described two different things letting good packets in and

keeping bad packets out. The key difference between a security
group and a network ACL is the security group is stateful. That
means, 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.

 Alright, let's start with a couple instances, and 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
doorman 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

packet 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
traffic address is allowed, you can keep going on your journey,
which it is. It's left Instance A and Subnet 1 entirely, so now it must
go through to Subnet 2, where it's checked by Subnet 2's incoming
Network ACL and through the security group of Instance B. Once
through those, Instance B can receive and process the request.

 After the transaction's complete, now it's time to come home. It's
the return traffic pattern. It's the most interesting because this is
where the stateful compared to stateless nature of the different
engines comes 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.

 At the subnet boundary, these network ACLs do not remember

state. Every entrance and exit is checked with the appropriate list.
Stateless controls mean it always checks its list. Instance B's
security group is first to evaluate, and since it's return traffic—and
 this security group saw the original request packet—the return
traffic is allowed. The Network ACL of Subnet 2 goes to evaluate,
and being stateless, it has to check the list again.

 By the way, this is a different list than on the way in. Network ACLs
have rules for both incoming and outgoing and they can be
different. Now on the Instance A side, our packet is inspected as the
stateless Network ACL of Subnet 1 checks the list every time. And
the last check is the security group of Instance A. Again, because
this is return traffic, it doesn't check the list on the way back in. So,
the packet is allowed, and on it goes to complete the flow at
Instance A.

 It might 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. That's why it's important to learn all of this.

 You want to ensure your IT strategy and design includes defining

the rules for your security groups and Network ACLs. That way, your
network design will meet your specific needs while also ensuring
good network security. After all, security is a critical consideration in
all networking for modern architectures.

 Subnets
 A section of a VPC for grouping resources based on security
or operational needs



















 It's time to see how all this networking stuff really works in action. In
this demo, I'm going to walk you through how to set up the network
components you've just learned about.

 Although this might not be something you personally would be

required to do when working with AWS, I still want to show you how
it works with a practical example using the AWS Management
Console so you can wrap your head around it.

 Let's start with the big picture of what we'll be building. We 'll go
through how to create a VPC, public and private subnets, an internet
gateway, and a route table for our public subnets.
 Let’s jump into the first task, which is creating the VPC. In the
search bar, I'll type in VPC, then choose VPC. This brings us to the
VPC dashboard, and I’ll now choose create VPC. On the Create VPC
page, for Resource to create, I will choose VPC Only. For Name tag,
I'll give it a name, like My VPC. And now it asks for something called
a classless inter-domain routing address, or CIDR range. This
address is used to define the block of private IP addresses available
to assign to any resources launched into the VPC. We are going to
use IPv4 addresses. So we can enter a value like this: four numbers
divided by periods like [Link]/16. Then, scroll down and select
Create VPC. With this, every resource in my VPC will get a private IP
address that starts with 10.0, then the second two numbers will vary
from resource to resource, each one having a unique address in the
VPC.

 The next task is to create the subnets. We are going to create both
public and private subnets across two different Availability Zones, or
AZs. This is a best practice to achieve high availability for your
applications. It allows your instances to remain accessible, even if
one AZ experiences an outage, by distributing them across separate
physical locations within the same AWS Region.

 Let's start by creating the private subnets first. Quick refresher, a

subnet is a range of IP addresses in your VPC. You can launch AWS
resources into a specified subnet. Use a public subnet for resources
that must be connected to the internet, and a private subnet for
resources that won’t be connected to the internet.

 I'll start with the private subnet. To create your private subnet, in
the left navigation pane, under Virtual private cloud, choose
Subnets. Then select Create subnet. On the Create subnet page, for
VPC ID, I’ll choose My VPC from the drop-down and then scroll down.
Here under Subnet settings for subnet name, I'll type in Private-
subnet-1. And then for Availability Zone, I will select us-east-1a. For
IPv4 VPC CIDR block, that reflects the VPC CIDR block [Link]/16,
and then we need to find the CIDR block for this subnet. Which will
be [Link]/24. Then we can select, Create subnet. Now our private
subnet has been created, I will select it and then select Actions, and
then select Edit subnet settings. On this page, there is this setting
for Auto-assign IP settings, I want to make sure this is not set,
because enabling this setting would give every resource in the
subnet a public IP. This is a private subnet, so we don’t want that. I’ll
go ahead and select cancel.

 I won't demo the steps for time sake, but I would repeat these steps
to create the second private subnet, placing it in a different
Availability Zone and choosing a different CIDR range, like
[Link]/24. Alright, and our second subnet has been created.
 Next, I'll create the public subnets. To do that I will select Create
subnet. On the Create subnet page, for VPC ID, I will select My VPC
from the drop-down. For Subnet name, I will enter Public-subnet-1.
And then for the Availability Zone, I will us-east-1a. And for IPv4
subnet CIDR block, I will enter [Link]/24. And then I will select
Create subnet. Now our public subnet has been created. In the
Actions menu, I will select Edit subnet settings. And then I will
check the check box for enabling auto-assign public IPv4 address.
This setting, provides a public IPv4 address for all instances or
resources launched into this public subnet. Then, I will choose Save.

 Now I would need to repeat those steps to create the second public
subnet, placing it in a different Availability Zone and choosing a
different CIDR range like [Link]/24.

 Now all four subnets have been created, two public and two private,
spread across two different availability zones for this one VPC. It's
important to note that even though your subnets are labeled Public
1 and Public 2, they are not yet public subnets. First, the VPC needs
an attached internet gateway, which we will attach in the next step.
Then, we need to create the appropriate routes in the route tables.
Again, don't worry too much about remembering all of this.

 So now let's go ahead and get that internet gateway created so that
the public subnets can actually connect to the internet. In the
navigation pane, under Virtual private cloud, I will choose Internet
gateways. Then I will choose Create internet gateway. On the Create
internet gateway page, for Name tag, I will enter in my-ig, and then
select Create internet gateway. Then I will select Actions, and then
Attach to VPC. In the search box, I will select My VPC, and then
choose Attach internet gateway.

 So now the internet gateway is attached to your VPC. Even though

we now have created an internet gateway and it is attached, we still
have to tell instances within the public subnet how to get to the
internet. That’s where the route table comes in.

 A route table contains a set of rules, called routes, that are used to
determine where network traffic is directed. Each subnet in your
VPC must be associated with a route table. The table controls the
routing for that subnet. So, to set up a route table in the console, we
will go to the navigation pane, and then we will select Route tables.

 We need to create a route table to route public traffic to the internet

gateway. I will choose Create route table. And then on this page, for
Name I will enter public-route-table. And then for the VPC, from the
drop-down I will select My VPC and then choose Create route table.
 Now that a route table is created, under the Routes tab there is one
route in your route table that allows traffic within the VPC to flow
within the network, but it does not route traffic outside of the
network. So, we need to add a new route to enable public traffic.

 I will choose Edit routes. And then I will choose Add route. And for
this route, under the Destination, I will enter [Link]/0. And then for
Target, I will select the internet gateway that we just created and
attach to this VPC, and then I will select Save changes.

 Now we need to associate this route table with our public subnets.

 I will choose the Subnet associations tab. And in the Explicit subnet
associations section, I will select Edit subnet associations. And then I
will select Public-subnet-1 and Public-subnet-2. Then I will choose
Save associations. The subnet is now public because it is connected
to the internet through the internet gateway. But the private
subnets do not have that route so they remain private.

 Now that we've created a VPC, four subnets, an internet gateway,

and route tables, how could you filter the traffic coming in and out
of this VPC? That's right, with security groups and network access
control lists, or network ACLS. Remember those CIDR blocks you
created earlier? Well security groups also use CIDR blocks to define
sources or destinations for network traffic. This way, everything is
secure and you decide who can access what resources based on
your needs.

 Building an Amazon VPC in the AWS

Cloud
 Core components covered in this demonstration

 It's helpful to understand how resources are created using the AWS
Management Console. The following is a high-level overview of the
resources and core components created in the preceding
demonstration.




 Folks, we've been talking a lot about how you interact with your
AWS account, the services you deploy, and the applications you
build. But how do your customers interact with your apps?

 Say you are hosting a website. Your customers would typically type
that website’s address into their browser, press the Enter key, and
before you know it, some magic happens—and the site lights up! If
you’re wondering where the magic comes in, it’s like this coin that I
have here right. I take a bite, ptooie! And it's back.

 Well, not quite like that, but I'm going to take you through two
services, which will help the website example make cents. Get it.
The first is Amazon Route 53. Route 53 is a domain name service, or
DNS. DNS acts as a translation service. However, instead of
 translating between languages, DNS translates website names into
Internet Protocol, or IP addresses.

 Humans can read website names and computers can read IP

addresses. This acts as the bridge between the two. As an example
of how it works, we type a website address into our browser and
press the Enter key. The browser contacts Route 53 and asks it for
the corresponding IP address of the site. Let’s say, [Link]. The
browser then knows where to go and gets routed to the website
using that IP address. Additionally, Route 53 can route traffic to
different endpoints using several different routing policies. These
include latency-based routing, geolocation, geoproximity, and
weighted round robin.

 If we take geolocation, for example, this policy directs traffic based

on where the customer is located. So, if a customer is located in
North America, they are routed to one of the North American
Regions. Likewise, if they are located in Ireland, they are routed to
the Dublin Region. You can even use Route 53 to register domain
names. Pick a domain name, check if it’s available, and buy it using
Route 53.

 The other service that comes to the rescue is Amazon CloudFront. If

you remember, we talked about edge locations earlier in the course.
These locations serve content as close to customers as possible,
and one part of that is a content delivery network, or CDN.

 Let’s go back to our Regions 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 deploy our static web assets, like
images and GIFs (or GIFs) in CloudFront's Seattle location. Shorter
distance equals quicker delivery times.

 I hope you are content after learning about these two services. So,
thanks for following along, and I'm going to disappear just like this
red cloth. So let's do this. Just pack it in. Abracadabra! Wow. Magic!



 Customer and laptop

 When you enter the domain name into your browser, this request is
sent to a customer DNS resolver.
 Customer DNS resolver
 The customer DNS resolver asks the company DNS server for the IP
address that corresponds to AnyCompany’s website.
 AnyCompany's DNS server
 The AnyCompany DNS server responds by providing the IP address
for AnyCompany’s website, [Link].







 Customer request
 A customer requests data from the application by going to
AnyCompany’s website.
 Amazon Route 53
 Amazon Route 53 uses DNS resolution to identify
[Link]’s corresponding IP address, [Link]. This
information is sent back to the customer.
 CloudFront
 The customer’s request is sent to the nearest edge location through
CloudFront.
 Application Load Balancer
 Amazon CloudFront connects to the Application Load Balancer,
which sends the incoming packet to an Amazon EC2 instance.
 Customer request
 A customer requests data from the application by going to
AnyCompany’s website.






 Morgan: Welcome back to Cloud in Real Life! We're going to go

over some relatively complex network diagrams and use cases to
reinforce the learning that you've done, but not to worry, you don’t
need to understand it all perfectly yet.

 Rudy: And up until this point, you've been learning about a single
VPC in a single region. However, in the real world, companies often
need much more complex networks to support global customers.
This can mean multiple AWS accounts, multiple AWS Regions,
multiple VPCs...even hybrid cloud deployments. But let's start with a
very common setup - a VPC with a VPN connection.

 Alan: This setup allows a company to securely connect their on-

premises network to their cloud-based resources on AWS. This
essentially creates a private, encrypted tunnel to access data and
applications in the cloud from their physical office location, while
maintaining data security and privacy over the public internet.
Companies often use this for remote employees who need to access
sensitive information that is stored in the AWS cloud.

 Morgan: And while there are definitely benefits to using a VPN to

connect to a VPC, and it works great for many customers, it does
also have a few potential limitations to be aware of. One thing is
that VPN connections do share the bandwidth of the local internet,
so the connection can be prone to slowdowns if you have heavy
payloads of data being sent over the internet to AWS. Another
consideration might be your company requirements to meet certain
compliance or regulatory standards. If you're worried about those
types of things, then you might consider using Direct Connect.

 Rudy: Exactly! Direct Connect is also awesome when lots of data

needs to flow between corporate data centers and AWS. These huge
data transfers can take a long time over the public Internet so some
companies opt for Direct Connect instead. Traffic will be routed from
their corporate data center to a Direct Connect location. It is then
routed to a VPC through a virtual private gateway. All network traffic
flows through this dedicated private connection. This helps to speed
 up data transfers, address application performance and increase a
company's data transfer security.

 Alan: So, when I have taught AWS networking, I get a lot of

questions around when to use VPN or Direct Connect. Rudy, can you
expand on that a little bit to clear it up?

 Rudy: Dude, of course! Yes, yes, you should use VPN when you
need a secure, flexible connection for remote access to your
resources. This is especially true for small-scale data transfers or
when a dedicated connection isn't necessary.

 Morgan: And then it's a good bet to use Direct Connect when you
need much higher bandwidth with a dedicated line like with large
data transfers between your on-premises network and AWS.

 Alan: And there are cases when you need to use both VPN and
Direct Connect, right?

 Rudy: Oh yeah, of course, a common use case for using a VPN

alongside AWS Direct Connect is where you use VPN as a failover for
Direct Connect.

 Morgan: Right, because we have to remember that with Direct

Connect these are physical hard-wired connections. So, if there is
some situation where a line gets cut accidentally or if something
were to happen, you can VPN as a backup connection for failover.
But there are even cases where you may want to failover to a
secondary direct connect line.

 Alan: Sure! In addition to fault tolerance, if a customer wants

Increased bandwidth, they can combine multiple connections to
achieve higher aggregate bandwidth.

 Morgan: Okay great, so that makes sense! Now, what about a real-
world example of a company that needs to deliver content to
several different regions globally? What would that look like?

 Rudy: Well, for companies with customers around the globe or even
offices in different Regions where they need to deliver content, they
could use Amazon CloudFront and Route 53. CloudFront distributes
content from edge locations globally, while Route 53 uses its
latency-based routing capabilities to direct users to the closest AWS
region (based on their location). This ensures they access the
application with the lowest latency, which effectively provides a
seamless experience across multiple Regions.

 Alan: Yeah, let's take a look at how that works. Starting with a user,
they access the company's website using a custom domain, the
 request is then sent to a Route 53 DNS record. Route 53 uses a
routing policy to determine which Region is closest to the user and
then directs them to the appropriate CloudFront edge location. The
edge location then fetches the content from the designated origin
server in the chosen Region. Notice how we're showing an
architecture with multiple AWS Regions, and multiple VPCs!

 Morgan: Right, this is a much more mature architecture than a

single VPC in a single region. Again, you don't need to worry too
much about getting all of this right for now, but it's good to have
context for how customers are using this stuff in the real world.

 Customer network
 The customer network clients and servers need a secure, high-
bandwidth connection for large data transfers and critical
application performance.
 Content router or firewall
 The customer has a content router or firewall connecting their
network to Direct Connect.
 Multiple Direct Connect connections
 In addition to fault tolerance, the customer wanted increased
bandwidth. They can even combine multiple connections to achieve
higher aggregate bandwidth.
 Virtual private gateway
 Using a virtual private gateway, the clients can securely access the
private resources in the Amazon VPC.

 Delivering content to several different Regions globally

 Here is an example of how a company with offices around the

world can deliver content with low latency for a seamless
experience across multiple Regions.

 To learn more about how traffic gets to Regions through CloudFront

and Route 53, choose each of the following four numbered markers.

 Users
 The users access the company's website using a custom domain.
The request is first sent to a Route 53 DNS record.
 Routing policy
 Route 53 uses a routing policy to determine which Region is closest
to the user. Route 53 directs the user to the appropriate CloudFront
edge location.
 Direct to edge locations
 Route 53 directs the user to the CloudFront edge location in the
appropriate Region.
 Content in multiple AZs
 The content is fetched from the designated origin server in the
chosen Region. Also note, the website was built with resources in
multiple Availability Zones for high availability.
