- Welcome back to this
"AWS TechShift: Migrate and Modernize" video miniseries.
These videos are aimed at independent software vendors
who are currently on premise and looking
to migrate to the cloud.
It's also aimed at those that are looking
to modernize the architecture
of an existing application to become more cloud native.
In the last video, we explored the benefits
of migrating to the cloud
and also introduced our monolithic photo gallery
as a case study application.
In this video, we are going to explore the concept
of a landing zone and look at how to build
our virtual private cloud, or our VPC,
which will form the base network
of our application resources.
(upbeat music)
When starting out in AWS,
customers are faced with many design decisions.
For example, do you have one AWS account
or split out into multiple separate accounts?
If you choose to use multiple accounts,
are these separated by team, by environment
or by application?
Other decisions include how to give access
to the account, how to structure the networking,
how to implement logging, auditing, and security guardrails.
When you start out with an AWS account,
there is nothing in it,
no resources, no users, no controls.
It is up to you to put together your own starting baseline.
This is called a landing zone.
To help customers quickly establish
a multi-account landing zone following AWS best practices,
we created a service called AWS Control Tower.
Control Tower automates the work involved
in setting up a landing zone.
Control Tower is opinionated guidance
on what the landing zone should look like,
delivered as a service in the console developed by AWS.
Control Tower takes best practices
and makes it very simple to deploy
all of these automatically.
The Control Tower automated landing zone
enables and configures AWS Cloud Trail and AWS Config
to log to an Amazon S3 bucket
located in a log archive account.
It also provides federated access to accounts
using AWS Single Sign-On.
It enables guardrails to protect the resources deployed
by AWS Control Tower
and detects non-compliance across multiple accounts.
Finally, it supports lifecycle events,
which allows you to configure
any additional custom automation
as part of a new account creation,
such as your default network configuration.
You can then build out your multi-account environment
from this starting baseline
and begin provisioning your application resources.
Now we have used Control Tower
to configure our landing zone.
Let's go back to our photo gallery application.
Before we can provision our EC2 instance
to run our application,
we first need to build a VPC which will contain
the networking constructs and subnets.
A VPC is created in a particular AWS region
and given an IP CIDR range.
In this case, we've created the VPC in eu-west-1,
which is in Ireland
and given a 10.0.0.0/16 CIDR range.
This means any resources provisioned
inside the VPC must be within this IP range.
Multiple VPCs can be created
within a region within an AWS account.
But in this example, we will just use one.
Within each AWS region,
there are multiple availability zones.
In this case, there are three.
Inside a VPC, you can provision subnets.
A subnet cannot span availability zones
so we must create multiple subnets,
in this case, one for each availability zone.
An internet gateway can be attached to a VPC
to allow access in and out of the internet.
This will allow end users to access our application.
So far, we have introduced public subnets,
which have a route directly to the internet gateway.
We are now adding in additional private subnets,
again, one for each availability zone,
which will not have a route to the internet gateway.
Instead, to allow resources in the private subnets
to still access the internet,
we will provision NAT gateways in the public subnets
and add a route from the private subnets
to those NAT gateways.
The NAT gateway means that traffic
can get out to the internet for things like software patches
but won't allow access to resources from the internet.
The private subnets are now ready for our database layer,
something that we will look at in more detail
in the next video.
Join us in the next video to explore
replatforming in database layer
and to optimize the delivery of static web content.
(upbeat music)