- [Alana] For our employee

directory application, we'll be using photos of

each of our employees. We have to store them somewhere safe. Currently, the only
copy of these photos are saved on my laptop right now. But if my laptop breaks,
then what happens? No more photos. I want to make sure this doesn't happen, so I'm
going to upload the photos to AWS to ensure that the copies exist even if my laptop
is destroyed. This also allows me to access
my photos from anywhere, my home, my phone, a plane,
on a train, everywhere. When I store these
photos in an AWS service, unbeknownst to me, I'm storing
it in a data center somewhere and servers inside that data center. But if a natural
disaster
happens or a fire or let's say a giant lizard
comes out of nowhere, stomps on the data center,
then what do we do? Luckily, AWS has planned for
this event, and many others, including natural disasters and
other unavoidable accidents. The way they planned for
it is through redundancy. AWS clusters data centers
together around the world. So here, AWS might have
a second data center connected to the first data center through redundant high
speed and low latency links. That way, if the first
data center goes down, the second data center
is still up and running. This cluster of data centers is called an Availability
Zone or AZ. An AZ consists of one or more data centers with redundant power,
networking, and connectivity. Unfortunately, sometimes natural disasters like
hurricanes or giant lizards might also extend to
impacting an entire AZ, but AWS has planned for that too - - with redundancy. Like
data centers, AWS
also clusters AZs together and also connects them
with redundant high speed and low-latency links. A cluster of AZs is
simply called a region. In AWS, you get to choose the
location of your resources by picking a region. Regions are generally named by
location so you can easily tell where they are. For example, I could put our
employee photos in a region in Northern Virginia called
the N. Virginia Region. And remember, AWS is not going
to name a region in Germany after Northern Virginia. As a basic rule, there are
four
aspects you need to consider when deciding which AWS region to use: compliance,
latency, price,
and service availability. Let's start with compliance. Before any other factors,
you must first look at your
compliance requirements. You might find that your
application, company, or country that you live in requires you to handle
your data and IT resources in a certain way. Do you have a requirement that your
data must live
in the UK boundaries? Then you should choose the
London Region, full-stop. None of the rest of the
factors even matter. Or if you operate in Canada,
then you may be required to run inside the Canada Central Region. But if you don't
have a
compliance or regulatory control dictating your region, then you can look at the
other factors. For example, our employee photos are not restricted by regulations,
so I can continue looking
at the next factor, which is latency. Latency is all about about how
close your IT resources are to your user base. If I want every employee around the
world to be able to view the
employee photos quickly, then I should place the infrastructure that hosts those
photos
close to my employees. We are all bound by the speed of light. Applied to your
business, that means if all your
users live in Oregon, then it makes sense to
run your application in the Oregon Region. You could run it in the Brazil Region,
but the latency from Oregon to Brazil might impact your users and
creates slower load times. But maybe I really want
to run my application or store my employee photos in Brazil. One problem I might
run
into is the pricing, which is the next factor we'll talk about. The pricing can
vary
from region to region, so it may be that some regions
like the Sao Paolo Region are more expensive than others due to different tax
structures. So even if I wanted to store
my employee photos in Brazil, it might not make sense
from the latency perspective or the pricing perspective. And then finally, the
fourth
factor you'll want to consider is the services you want to use. Often when we
create new
services or new features in AWS, we don't roll out those services to every region
we have right away. Meaning if you want to
begin using a new service on Day One after it launches, then you'll want to make
sure
it operates in the region that you're looking at running
your infrastructure in. To recap, regions, availability zones, and data centers
exist in a
redundant nested sort of way. There are data centers
inside availability zones and availability zones inside regions. And how do you
choose a region? By looking at compliance, latency, pricing, and
service availability.