- Welcome back to this
"AWS TechShift: Migrate & Modernise" video miniseries.
These videos are aimed at independent software vendors
who are currently running on premise
and looking to migrate to the cloud.
It's also aimed at those that have existing architectures
and looking to re-architect to become more cloud native.
In the last video, we replatformed the database layer
from the EC2 instance to Amazon Aurora MySQL.
We also introduced Amazon S3
as a way to store our static image content.
We then added Amazon CloudFront to cache this static content
closer to the end users using the AWS edge locations.
In this video, we are going to focus
on automatically scaling the EC2 instances
that are serving the dynamic web content.
We'll also explore the benefits of infrastructure as code.
(upbeat music)
Up until now, the dynamic content has been served
by a single EC2 instance connected to the database.
To scale the web server and increase resilience,
we need to add more instances.
To do this, we will first introduce
an application load balancer
between the CloudFront distribution and the EC2 instance.
Application load balances are part
of the Elastic Load Balancing family
and operate at layer seven to balance HTTP
and HTTPS traffic.
They can support HTTPS termination
to help manage SSL certificates.
The ELB will balance traffic between the web server nodes
as well as being responsible for determining
the health of instances.
If an instance becomes unhealthy,
it will be taken out of service
and the load balancer won't route traffic to it.
Now that we have the load balancer in place,
we can create more instances
running the same application software behind it.
Note how the new instance
is in a different availability zone
for increased resilience.
To avoid having to install and configure
the application software every time a new instance
is added to the load balancer,
a template of the image instance should be created.
In AWS, this template is called
an Amazon Machine Image, or an AMI.
An AMI contains the operating system,
all its configuration, software packages
and the data ready to create multiple copies
of the same instance.
In this simplified view of the architecture,
we can now use the AMI to create an EC2 auto scaling group.
The auto scaling group, or ASG,
will add and remove instances using the configured AMI
as a template.
The ASG can be configured with a scaling policy
to automatically add or remove instances
based on the specific metric.
It could be the number of requests per second
on the load balancer or the CPU usage
of the instance, for example.
Another benefit to using an ASG is that it can be configured
with a minimum number of healthy instances to maintain.
In this case, we have lost an availability zone
so the ASG has recreated the lost instances
in the other remaining AZ.
This ensures there is no impact
to the performance for end users.
The photo gallery application architecture
now offers scalability
and provides increased resilience and performance.
However, there are more components
than the original single EC2 instance.
Setting up this architecture from scratch manually,
either through the console or via the CLI,
can be time consuming
and creating multiple identical deployments
of the same environment could be challenging.
To address this challenge,
we should define the infrastructure as code.
AWS CloudFormation lets you model, revision
and manage AWS resources by treating infrastructure as code.
Using CloudFormation, you can define your resources
in files using either JSON or YAML syntax.
These files can then be used to deploy copies
of the entire application infrastructure
to facilitate multiple test environments
or individual environments per tenant.
It also serves as a form of documentation,
meaning that the environment can quickly be reprovisioned
in the event of a disaster recovery situation.
It's best to version control your CloudFormation template
in a Git repository.
AWS CodeCommit is a managed source control service
where you can host private Git repositories.
This will ensure your template changes
are version controlled and changes are trapped
with appropriate approvals.
Join us in the next video where we'll summarize
everything we have done so far and look at where to go next.
(upbeat music)