

 The coffee shop is thriving. In fact, the shop has gained quite a
following, and now we’re thinking it’s time to expand. That’s right.
Breaking news: the coffee shop is going international.

 As the shop plans its expansion, there are a few considerations to

keep in mind. First, we need to decide where to open new locations.
We want to reach coffee lovers in different parts of the world, but
we also need to consider factors like local demand, regulations, and
costs. This is like how in AWS, when you are expanding globally,
there are a number of factors to consider when selecting AWS
Regions. In these upcoming lessons, you'll learn all about what goes
into choosing a Region or set of Regions.

 The next step of our coffee shop expansion plan is that we want to
open some lightweight, smaller footprint versions of our shop called
coffee carts. We'll set these up in places like farmers markets,
airports, and event venues. They won't serve every drink or item on
the menu, but they can provide the most popular items quickly and
efficiently. These coffee carts are similar to how AWS edge locations
work. Edge locations offer fast, localized delivery of the most
frequently accessed content. They cache things like images, videos,
and other assets and resources, allowing users to get the content
they need quickly, without waiting for it to be retrieved from a
central location. You'll learn more about these soon.

 Finally, our shop wants to standardize and automate processes so

we can keep our customer satisfaction consistent. No matter which
shop or coffee cart the customer visits, we want them to get the
same great experience. We’ll train staff on the same recipes and
use smart coffee machines that can be programmed remotely and
replicated to all the different locations, making sure that a
cappuccino in Stockholm tastes just like one in Seattle. Similarly,
AWS has infrastructure in place to help businesses scale responsibly
and consistently. In this section, you'll explore how to achieve
consistent deployments across environments and global
deployments using infrastructure as code, or IaC, specifically
focusing on AWS CloudFormation.
 By the end of this section, you'll have a thorough understanding of
the ins and outs of AWS Global Infrastructure, helping you to
achieve robust, scalable, and globally available applications. So,
grab your cup of coffee, and let's dive in.

 Going global with AWS infrastructure

 The coffee shop is expanding to global locations. Navigate
through the following content to review how elements of our coffee
shop expansion represent different parts of the AWS Global
Infrastructure.





 One of the best parts about the AWS Global Infrastructure is that
you have lots of options when it comes to which AWS Region, or
Regions, you deploy your resources in. Before we talk about what
factors into this business decision, I want to touch on an important
security aspect of AWS Regions. Each Region is isolated from every
other Region, in the sense that 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 good thing! Depending on the type of business you are

dealing with and where you operate, you might have to adhere to
 specific compliance regulations that require your data to remain in
one geographical area. For example, if you're working with financial
information in Frankfurt, local data governance laws state that this
financial data cannot leave Germany. The data that is stored in an
AWS Region is subject to the local laws and statutes of the country
where the Region lives. Which is actually our first of four
considerations when choosing a region: compliance.

 Before any of the other factors, you must first look at your
compliance requirements. Do you have a requirement that your
data must live in UK boundaries? Then you should choose the
London Region. The choice is pretty straightforward. None of the
other options really matter. Or, let's say you must run inside of
Chinese borders. Well then, you should choose one of our Regions
located in China. Most businesses 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.

 The second factor is proximity. How close you are to your customer
base is a major factor. If most of your customers live in Singapore,
consider running out of the Singapore Region. You can certainly 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.

 For number three we have feature availability. Sometimes the

closest Region might not have all of the AWS features you want.
Here's one of the cool things about AWS. We're constantly
innovating on behalf of our customers. Every year, AWS releases
lots of new features and products specifically to answer customer
requests and needs. These features are rolled out to regions over
time, so that is also a consideration.

 Finally factor number four is pricing. Even when the services and
features are equal from one Region to the next, some locations are
more cost effective to operate in than others. Things like local tax
structure and energy costs factor into the equation. AWS has a very
transparent, granular pricing that we'll continue to discuss in this
training. But know that each Region has different numbers for
pricing.

 So, to wrap up, you have a lot of options in terms of where to deploy
your resources. Keep these four key factors in mind when choosing
a Region: compliance, proximity, feature availability, and pricing.








 At this point, you’ve seen how user proximity, regulatory

compliance, service availability, and even pricing can play a factor
in selecting an AWS Region. When it comes to infrastructure, you
also want to plan for long-term stability and less or virtually no down
time for your users. So, if your infrastructure has an interruption,
you can switch to redundant or backup infrastructure seamlessly.
This is called building redundant architectures.

 One method for redundancy is an architecture that uses multiple

Availability Zones, or AZs. In a multi-AZ architecture, if an AZ has an
interruption, no worries. Your application will automatically switch
over to the backup AZ you have configured. Even better, if you set it
up correctly, your customers won’t even notice a difference. ‘Cause
let’s be honest, nobody wants their favorite meme site or coffee
shop app to go down! Additionally, multi-AZ architectures can assist
with quicker disaster recovery, improved business continuity, lower
latency, and compliance.

 But as with anything in the world, there are multiple ways to peel an
orange. In fact, you can go one step further and deploy your
application in multiple AWS Regions. So, if a whole Region
experiences an interruption, you can failover to another one. Orange
you glad you chose AWS as your cloud provider?

 Some of you might say, “Wait, wait, wait, Rudy, multi-Region and
multi-AZ deployments? This sounds like some sort of pinball
machine.” Well, yeah, it is exactly like a pinball machine but with a
multi-ball bonus. It can be difficult to juggle multiple pinballs
initially. They are moving in different directions, and you might
stress about keeping track of all of them. However, once you come
up with a strategy and you get some experience, it gets much
easier.

 So, don't worry too much about perfecting your AWS global
infrastructure right off the bat. Just like pinball, planning and
executing multi-AZ and multi-Region deployments gets easier after
you’ve practiced a bit. Who knows, some day you might even get an
AWS infrastructure high score! Just kidding, I don't think that's a
thing. Is that a thing? Oh, it might be a thing. Oh wait..
 Oh, looks like Rudy’s Rhubarb Refresher, trademark, is so popular
that people are making memes of it! However, images are loading
slowly for some people on the app. Let’s fix that by utilizing Amazon
CloudFront. CloudFront is a content delivery network, and it’s
designed to serve content as close to users as possible. This content
can be images, data, videos, applications, APIs—and, in our case—
memes.

 CloudFront uses Edge locations, which are part of our worldwide

Amazon Global Edge Network. These edge locations are actually
separate from Regions and are specifically designed to accelerate
content delivery. Edge locations host other AWS services, like AWS
Global Accelerator and Amazon Route 53. Route 53 is a Domain
Name System, or DNS, that routes end users to internet
applications. Essentially, it converts human-readable URLs to
machine-readable IP addresses. ‘Cause trust me, you don’t want to
have to remember IP addresses by heart.

 And don't forget about AWS Outposts. Say you have a need. And
that need is for speed. More speed than even a Region paired with
CloudFront can achieve. This is where Outposts comes in handy. As
you might recall, Outposts essentially makes it possible for you to
run AWS services on-premises. Look, keep these multi-deployment
concepts and edge services in your brain as you continue to explore
AWS global infrastructure.





 Key elements of AWS Global

Infrastructure
 To review the relationship between Regions, Availability Zones, and
edge locations, choose each of the three numbered markers.

 AWS Regions
 Regions are geographical areas around the world that are made up
of multiple data centers. These data centers provide scalable and
redundant infrastructure for hosting cloud services. Each Region
consists of multiple, isolated locations known as Availability Zones.
Each Region has three or more Availability Zones.
 Availability Zones
 Availability Zones are distinct locations within a Region, each
designed as an independent zone with its own power, networking,
and connectivity. Availability Zones maintain high availability and
 fault tolerance for applications. Each Availability Zones consists of
one or more data centers.
 Edge locations
 Edge locations are strategically placed sites around the world that
cache content to deliver data, video, and applications with lower
latency and higher transfer speeds. Edge locations are considered a
vital part of the AWS content delivery network (CDN) and use
services like CloudFront to efficiently distribute data to end users.





Programmatic access

 Programmatic access includes options like the AWS CLI and AWS SDKs. These options
are best suited for developers and those familiar with coding languages.
 With the AWS CLI, you manage multiple AWS services directly from the command
line. You can automate tasks through scripts.
 AWS SDKs can help integrate AWS services into your applications by providing APIs
for various programming languages. AWS provides documentation and sample code
to help you get started with using SDKs.
 Use cases for AWS CLI actions and SDKs include the following:
 AWS CLI: Automate routine tasks. For example, you might write a script to provide
routine backups for a service such as Amazon Elastic Block Store (Amazon EBS).
 SDKs: Invoke APIs for one part of an application process. For example, you might use
an SDK to store user data in an AWS storage service such as Amazon Simple Storage
Service (Amazon S3).

AWS Management Console

 The AWS Management Console is a web interface that you use for managing AWS
services, offering quick access to services, search functionality, and simplified
workflows. The console is a great option for those new to the cloud or users with
minimal or no development experience.
 Use cases for using the console include the following:
 Billing and cost optimization dashboards and visualizations
 Services focused on graphical representations, like Amazon QuickSight and Amazon
Neptune

Infrastructure as Code

 With IaC tools such as CloudFormation, you can automate resource management
across your organization with AWS service integrations offering efficient and
repeatable resource creation and management.
 Use cases for CloudFormation include the following:
 Managing infrastructure with DevOps such as continuous integration and delivery
(CI/CD) pipelines
 Scaling resources such as Amazon EC2 instances to multi-Region applications in a
consistent, repeatable way
