- Welcome back to this
"AWS TechShift: Migrate to Modernize" video miniseries.
These videos are aimed at independent software vendors
who are currently running on premise
and looking to migrate to AWS.
It's also aimed at those that are looking
to modernize an existing architecture
to become more cloud native.
In the last video, we introduced AWS Control Tower
as our landing zone, and we improved the VPC design
by adding more subnets
that spanned multiple availability zones.
In this video, we are going to look
at moving the database away from the EC2 instance
and onto a managed service.
We will then look at a better way to manage our photos
and our static image content
by using a content delivery network.
(upbeat music)
Our photo gallery application allows users to upload,
tag and search for photos.
It is a monolithic and everything runs on a single server,
including the MySQL database.
At the moment, the photo gallery is all running
on a single EC2 instance inside one AZ in a public subnet.
In the last video, we added private subnets
across multiple availability zones.
It would be more secure for the database layer
to run in one of these private subnets
so that it cannot be accessed
by a public IP on the internet.
Moving the database away from the web tier
would also allow for the web tier
to scale independently, allowing us to add more nodes.
To ensure high availability
and protect against a loss of an instance
or availability zone, we should replicate the database
to another availability zone.
We can build this new architecture
with more EC2 instances.
However, we would have to install, configure
and manage the database engine ourself.
To take away this undifferentiated heavy lifting.
we will instead use an AWS managed database service.
Amazon Aurora is MySQL
and PostgreSQL compatible relational database
built for the cloud that combines this performance
and availability of traditional enterprise databases
with the simplicity and cost effectiveness
of open source databases.
What benefits do you get from using Amazon Aurora?
It's fully managed, so there's no servers to provision,
software to patch, no setup, no configurations
or backups to manage.
It's fault tolerant, it's self-healing
and you get six copies of data
across free availability zones,
as well as continuous backups to Amazon S3.
It's highly secure.
There's network isolation.
You can provide encryption at rest and in transit,
and it complies with a number
of compliance and insurance programs.
Performance and scalability does five times a throughput
of standard MySQL
and three times the throughput of standard Postgres.
You can also scale out by adding up to 15 read replicas.
One of the key features of Amazon Aurora
is a separation of storage and compute.
When you create an Aurora cluster,
it creates a storage volume that is automatically replicated
across multiple availability zones.
This means when data is written
to the primary database instance
Aurora synchronously replicates the data
to six storage nodes across those availability zones.
This provides redundancy and protects against failures.
Compute nodes can be added or removed
from the storage volume as required.
We can easily migrate the existing MySQL database
to Amazon Aurora MySQL and change the connection string
within our application server without other code changes.
We now have a database in a private subnet
with data replicated across multiple availability zones.
We can also scale out the web tier independently.
Now let's focus on users accessing content
from the web tier.
Currently photos are stored and served by the EC2 instance.
This is okay, but if we need to add more instances
to scale the application,
we need to ensure the photos are accessible
by all servers through some form of shared storage
or replicated storage.
We also need to ensure that photos are protected
from the loss of a single instance or an availability zone.
Amazon Simple Storage Service, or S3,
is an ideal place for storing
and serving the photo gallery images.
S3 provides 11 lines of durability
and objects are automatically replicated
across multiple availability zones.
Storage capacity is virtually unlimited
as well as being cost effective,
allowing the volume of the images to grow
with usage increases over time.
Amazon S3 can be accessed via HTTP requests,
meaning the application code can be tweaked
to point image upload and download requests directly to S3,
reducing the demand on the EC2 web server
and improving scalability.
We're going to make one final improvement
to the architecture in this video,
and that's to introduce a caching layer.
Currently the photo application is running in an AWS region.
AWS has regions across the world.
However, users may not be geographically close
to the serving region.
This can introduce latency
and is not optimal for user experience.
In addition to regions,
AWS has hundreds of points of presence, edge locations,
in 90-plus cities across the world.
Amazon CloudFront is a web service
that speeds up the distribution of your static
and dynamic web content, such as HTML, CSS,
JavaScript and image files, to the users.
CloudFront delivers content through these edge locations,
which are often much closer to your end users,
reducing the latency
and improving their application performance.
Back to our architecture diagram.
Let's add in the Amazon CloudFront content delivery network.
Now end users will be directed to CloudFront.
If content, such as images, is already in the edge location,
it'll be served to the end users with the lowest latency.
This will also reduce the requests
to the EC2 instance and the S3 bucket,
helping improve scalability and performance.
Join us in the next video
where we'll look at automatically scaling the EC3 instances
and defining the AWS infrastructure resources as code.
(upbeat music continues)