- While AWS is built of many individual building blocks
and a lot of them can be used atomically on their own,
it's really designed as an ecosystem
and meant to be used as that ecosystem.
And there's a great example
of how these services synergize together
using an elastic load balancer,
EC2 instances
and then the auto scaling service
that we're gonna be talking about now.
So the auto scaling for EC2 is AZ scoped
just like the EC2 instances
that it's going to launch and destroy on your behalf.
However, it also supports multiple AZs
similar to load balancers
that you might be associating your EC2 instances with.
And the purpose of auto scaling is horizontal scaling
for your EC2 instances.
So what is horizontal scaling?
Well, in order to understand that
let's first explain vertical scaling.
Vertical scaling is when you add or remove resources
from a single EC2 instance, like resizing it
or adding an extra EBS volume or upsizing a volume.
Many of those types of operations
are going to generate some sort of outage.
Horizontal scaling's a little bit different.
This is where you add and remove discrete instances
because they're all performing similar tasks.
And so from an infrastructure perspective
where we have a two-tier application, load balancer,
and then auto scaled group of EC2 instances.
When the inbound traffic or load or latency
or whatever metric we're using as a KPI.
When that increases beyond a certain threshold
we can then add EC2 instances to address that
and reduce it back to a tolerant level.
But auto scaling is an elastic feature.
It's not just for scaling out.
It is also for scaling in.
And so when that traffic load decreases
down below other levels,
you can remove instances.
And so it is a great cost optimization feature.
In addition to being performant and efficient.
In order to design an auto scaled infrastructure
we need to talk a little bit about a scaling plan.
And a scaling plan starts with a scaling strategy.
A scaling strategy is a spectrum.
On one end, we have availability.
If you're optimizing for availability
you are going to want to have as many instances as possible.
On the other end of the spectrum, we have cost.
And that's the trade off between the two.
If you wanna have more instances
to handle all that traffic all the time,
you're gonna have to pay more for it.
And so if you are trying to optimize for cost
you are gonna want to deploy the fewest instances required
to get the job done.
And many organizations end up somewhere in the middle
on this spectrum
with optimizing for cost,
but recognizing that the auto scaling service
does not scale instantaneously
and so it might be a good idea
to have a few extra resources on hand.
Now, this scaling plan is what's defined by the customer
and this can be translated directly
into parameters and configuration for auto scaling.
Rules and limits for the minimum number of instances,
the maximum number of instances, and so forth.
And then AWS will take that configuration and parameters
and turn that into a combination
of dynamic and predictive scaling.
And we're gonna talk about those two terms coming up.
The auto scaling architecture
is broken up into several pieces.
The first of these is not specifically part
of the auto scaling service.
It's actually part of the EC2 service
and it's called a launch template.
The launch template is basically a set of default values
in order to launch an EC2 instance.
And so the launch template is gonna answer the question of:
what am I gonna launch?
The auto scaling group itself
is the sticky glue that holds the whole service together.
This is what defines limits in associations.
Minimum instances, maximum instances,
associations with target groups, and so on.
Scaling policies are gonna determine when
or under which conditions you launch or destroy resources
according to cloud watch metrics.
And finally scheduled actions also define when you scale
but according to a calendar or clock
instead of specific metrics,
and they can be used in conjunction
with the auto scaling policies.