(upbeat music)
- [Jeremy] EC2 stands for Elastic Compute Cloud,
and the word of the day is elastic.
An auto-scaling policy can tell AWS
that when an event occurs,
such as our instant CPU usage goes above 80%
for five minutes to stretch our one server into two,
and then we can tell it to shrink back down again
to one server when things have calmed down again.
Your application needs to be designed in a way
that if 1 or 2 or 10 clones
of your single server come online,
that your application can load balance your traffic
across all these new servers.
Now this is called horizontal scaling.
If you think of a busy grocery store,
the manager will open several new checkout lanes
to reduce wait time.
When the rush is over,
they'll close those extra checkout lanes.
This is different than vertical scaling
which would handle the problem
by still only having a single checkout lane,
but just putting a faster cashier
and speeding up the conveyor belt.
Vertical scaling in AWS is fairly easy,
you just stop your running EC2 instance,
which you know, will cause a little downtime,
and change the instance to a larger, faster server
with more CPU cores and RAM,
but this has it's limits,
and all large applications use horizontal scaling
to handle an increase in traffic.
We're not going to set up Auto Scaling for this course,
but we will create an AMI snapshot
of our current running server
and create a clone of it manually,
which is one of the first steps
to setting up Auto Scaling anyway.
If you'd like to dive deeper into Auto Scaling,
I recommend our AWS course on automation and optimization.
Okay, if you're totally new to these concepts
of horizontally scaling servers in your application design,
search our catalog for AWS high availability,
and we have a few courses that'll show you
how to keep your application running
when a single server fails,
or when that single server gets overloaded
due to high demand.
Finish out this course first though,
because you're going to need to know a bit more
about storage and networking in AWS
to get a full understanding of the material
that's presented in those courses,
so let's jump into the console
and I'll show you how to clone our existing server.
In the EC2 console,
on the left, click on Instances,
and select your running instance.
Then click on the actions pull down above it
and take a look at a few of these options.
Under the instant state pull down,
you can stop and start the instance,
and you'll also see a reboot option.
Now if you stop an instance,
you won't be charged for the compute time
while the instance is stopped,
but you will be charged
for the storage costs of its hard drive,
which are pretty minimal.
You can click to start and bring the instance back up again.
If you click reboot,
it'll force a software reboot of the virtual machine.
Okay, now check this out,
these are different actions in AWS,
if you stop and start an instance,
this virtual machine will actually move
to another physical server in the availability zone.
So do this
if you're having problems connecting to the instance
because it could be a hardware failure on the AWS side.
Back in the detail pain, click on the status checks tab.
You'll notice the system status check
is failing if there's a hardware failure,
but it takes a few minutes for AWS to see the problem,
so you might notice the problem before the alarm goes off.
If you reboot an instance, it'll come up faster,
but it stays on the same physical server it was on before.
Okay, click on actions again,
and select Image,
and then select Create Image.
For image name, type AWS demo,
and you'll see an option here that says no reboot.
AWS needs to reboot the virtual machine
to take a proper image of it,
so this properly shuts down the file system
and lets AWS take a clean image of the virtual machine,
but it does cause a little bit of downtime.
If you select no reboot, well, good luck to you.
Click the Create Image button,
and then click Close.
On the left hand sub menu,
click on AMIs, underneath the image header.
You'll see a spinner next to our AMI
while AWS reboots the instance and takes a snapshot of it.
When the AMI image says that it's available,
click on it, and click on the launch button.
Now we're back on the EC2 launch screen,
but we're launching a new server based on our server image.
Select t2 micro again,
and then click the next configure instance details button.
Under subnet, select an availability zone
that's different from the other instance,
so my other instance was in US east 1a,
so now I'm going to pick US east 1b.
Click Next, and then click Next again,
and then click Next one final time
to configure the security group.
Under assigned security group,
I want to select an existing security group,
and I'm going to select launch wizard 2,
because that's the security group
that my other instances using.
You'll notice in the rules that HTTP
is now open to the entire internet.
Click Review and Launch, and click Launch.
This time, I'm going to choose an existing key pair,
and I'm going to make sure
that I'm selecting my AWS demo key pair
that I used for my other instance.
Select the acknowledge checkbox, and click Launch Instances.
Click View Instances.
You'll see that our other instance is now spinning up.
This instance is in availability zone 1b,
whereas my original instance is in availability zone 1a.
And I'm also going to edit the name
and call this web server 2.
Click on the new instance and click on the description tab,
and then copy its public DNS.
In a new browser tab,
type http:// and paste in the DNS name.
You'll see the default Apache site again,
because remember,
this server is a clone of the server that we just set up.
An AMI image is a great way to take a snapshot in time
of your server in its full configuration
and then launch new instances to say,
handle a spike in traffic,
or restore the instance to a previous state
if it gets messed up somehow.
Let's leave both instances running,
but remember to come back
after you're done and click on Actions,
Instant State, Terminate,
and delete both instances
so that you're not running up your bill.
(gentle music)