Getting started with AWS

Getting Started with
AWS
Jungwon Seo

University of Stavanger

Jungwon Seo
In Norway

From South Korea

Master in CS

Bachelor in CS

3 start-ups

Many random works

Do you like to learn about
new technology?

My ﬁrst reaction : Rejection

The most important thing is
that companies want us to know these:

Have you ever heard
about AWS?

When we run a service..
Server
Database Files
Application

What makes us use it
differently?

# of data + # of requests,
+ # of operations ….
# of users
=

Typical Questions
How can we scale up our service?

Buy a better server?

But until when?

File Server
Files
We need to separate all the
components as much as possible
Application Server
Database Files
Application
DB Server
Database

This is the website that we will test

Database Files
Application
Target Architecture #0
EC2 : working as a web server, database and ﬁle storage
This is the ﬁrst architecture that we will build.

I will assume that we already have an AWS account.
1. Select the region closest to your country
2. Find EC2

This is the main page of EC2
1. Click

1. Click
Choose the OS that you want to use.
I will use Ubuntu.

t2.micro is free but only for one instance.
If you run two or more, you will have to pay.
1. Choose
2. Click

We are skipping the detailed settings.
1. Click

For the ﬁrst time, we need to make a key pair.
Keep it safe!
1. Select
2. Type the name
3. Download
4. Click

This is the result page.
1. Click to check

Now we can see the instance we have launched.
Let’s just think that one instance equals one server.

In AWS, we administrate ports in the AWS console
- not in the server.
1. Click
2. Select (you can also check it from the instance’s details page)
3. Click
4. So far this is the only port that we can access remotely.
5. Click

Let’s add 80 port for HTTP.
1. Click
2. Select HTTP
3. Click

Now we have two open ports (22 and 80)!

Go back to the instance page.
1. Click
3. Check the public IP
2. Select

Now we will connect to the server using “.pem” and “ssh"

Ok, this is the ﬁrst screen that you will see.

I have already made several test codes in my git.
So, let’s use them.
git clone https://github.com/MuchasEstrellas/AWS.git

Move to ‘architecture0’ and run ‘start.sh’
run ‘sh start.sh’

It will install and update many things.
This screen should appear, if it worked correctly.

Now if you type the public IP,
you can check your website publicly.

EC2 : working as a web server and ﬁle storage

RDS : working as a database
Files
Application

This time,
we need to use RDS as the database of our service.
1. Search and Click

Choose MySQL and click next.
1. Click
2. Click
3. Click

Enter the information.
I recommend that you use the same name and password.
uisaws123
1. Type in the following.
2. Click

Make a database.
Again, I recommend that you use the same database name.
1. Enter the db name.

Now, you can see your database.
1. Click

This is the RDS instance that we made.

If you scroll down,
you can see more detailed information.

A couple minutes later, you can see the endpoint of this database.
It means, it will be the address that you can access.
Check the security group whether it is opened to everywhere.
(rule 0.0.0.0/0 means everywhere)

Move to ‘architecture1' directory.
Type ‘start.sh’ with RDS endpoint.

Then the ‘start.sh’ ﬁle will automatically change the DB_HOST  
in the views.py
views.py

You can also get an overview of your database in the RDS page.

No diﬀerence from the client side.  
But this website is receiving the data from RDS.

EC2 : working as a web server


S3 : working as a ﬁle server

This time, we will separate the ﬁle server from EC2.
1. Search and Click

There is a term which is called ‘bucket’.
Let’s just think S3 is like some kind of folder in the cloud.
1. Click

The bucket name should be unique.
Because S3 will make a url with your bucket name.
1. Type in your bucket name.
2. Click

Just skip this at this time.
1. Click

Just skip this too at this time.
1. Click

Okay, let’s create.
1. Click

Okay, here is our new bucket.
However, there is an important thing that we have to know.
Accessing S3 programmatically should be authorized.
Otherwise, anyone can upload and delete your ﬁles.

Let’s use IAM to access S3 programmatically.
1. Search and Click

There are many things to ﬁx for your security,
but let’s skip at this time.
1. Click
Let’s ignore these at this moment, but it is important when you use AWS for a real service.

1. Click
Let’s make a user which will have a permission for S3.

1. Enter the user name
2. Click
3. Click
Remember to click “Programmatic access”

1. Click
You need to make a group ﬁrst.
Users should be in a group.

1. Click
2. Type S3
3. Select S3FullAccess
4. Click
This group will contain the permission for S3.
Users who are in that group will have the same permission.

Select the group that we just made.
1. Click

It is really important to keep your key safe.
Mine is exposed now, but I have deleted it. Don’t try using mine!
1. Download
This is the ID This is the password

Now move to the ‘architecture2’ directory
and run following command. 
sh start.sh <RDS> <ACCESSKEY> <SECRET> <S3_REGION>
RDS endpoint
Access Key Secret Key Region
Then it will edit ‘views.py’ automatically.

But your website will not work properly.
We need to move all the static and media ﬁles (css, js, image) to S3.
<collectstatic.py>
This ﬁle will help.
(like this)

Let’s run!
You have to activate the virtual environment.
Don’t forget to deactivate.

Now we can ﬁnd the static folder in S3.

If you click it,
you can ﬁnd an exact copy of the directory that we had in EC2.

We can see the link.
It means now we can access this css ﬁle publicly.

If you take a look at ‘views.py’, you can ﬁnd a path for S3.
Before
After

One more thing! When a user uploads a picture,
it should be stored in S3.
Take a look at this code.

Okay, now you can ﬁnd the picture that you just uploaded in S3 as well.

All the uploaded images are also from S3.




Route53 : DNS

You must have bought some domain before.
But how can we connect it to our service?

We need to change ‘name server’
to have control of this domain in AWS.

Let’s use ‘Route 53’ to deal with domains.

In my case, uisprogramming.com.
Please use yours!

Okay, this is the default record sets.
Remember the NS values.

In the website where you bought a domain
you can change the name server to the name server
from the previous slides

This GUI can be diﬀerent from site to site.
Just remember that you have to change NamesServer!

Here are four name servers that I copied from AWS route53.

Okay, now it has changed, but it takes a while to be applied completely.
Just go get a drink and continue it tomorrow.

Okay, good morning!
We will test a simple case, which is connecting
'www.uisprogramming.com' to the public IP of your server.

It also takes a while, but not that long.
Go get some coﬀee.

Run ‘start.sh’ in ‘architecture3_4’ with adding your domain.
sh start.sh <RDS_ENDPOINT> <ACCESS_KEY> <SECRET_KEY> <S3_REGION>
<DOMAIN>

Now we can access our website with a domain.




Route53 : DNS

ELB : Load Balancer

Go to the EC2 page and click Load Balancers.
1. Click

Choose Application Load Balancer.

Enter the name, and just set the HTTP port and choose all zones.

If you see this page, just move to next page.

Load Balancer is also a kind of computer.
So we need to manage its port setting from the security group.
1. Select
2. Edit if you need to
3. This time, open only 80(http) port.
4. Click

This is the conﬁguration between ELB and EC2.
2. Click
1. Enter the target name

Okay, so we will register an instance to this target group.
This group is very important for the future auto scaling.
1. Select
2. Click
3. Click

Okay, so let’s check our Load Balancer.

This is the Load Balancer dash board.

This is the target group that we made.

If you click the target group, you can see the targets (instances)
1. Select
2. Click
3. Here you can check whether your instance is working properly or not.

Now, we will redirect our Route53 to ELB 
(not to the public IP of EC2)

Okay, stop. 
We will replace the IP with ELB.
1. Select
2. Select
3. Choose
4. Click

The reason that we have to connect ELB to Route53 is
that we can easily replace our server without any downtime.
When you want to change your server, you just need to change your
instance from the target group.
You don’t need to reconnect your server IP to Route53 anymore.

One more thing, we can also add more instances to this ELB.
Let’s create one more instance like we did in architecture#0.
However, if you use two t2.micro instances, AWS will charge you.
If you don’t want to pay, then just read.

Open one more terminal,  
do the same job that we did in architecture#0

After that, we need to add this instance to our target group.
1. Click
2. Choose
3. Click
4. Click

1. Select
2. Click
3. Click
Add the new instance to our registered targets.

Now, we can see two instances.

Let’s see if both work ﬁne.
We will monitor it with the Nginx access log.

As you can see, there are many “ELB-HealthCheker” logs.
This is the way to separate the healthy instances and the unhealthy
instances from ELB.

If you refresh your website, only one instance will get the request.

If you refresh it again, the other instance will get the request.

Elastic Load Balancer will choose one by one  
so that we can distribute the traﬃc.




Route53 : DNS

ELB : Load Balancer

AWS Certiﬁcate Manager : TLS/SSL certiﬁcate
+

Before we get started, we need to modify the security group of ELB.
1. Click
2. Select
3. Click

2. Click
1. Click
Let’s add an HTTPS port.

1. Click
2. Select 3. Check the values.
4. Click
Now we are opening two ports(80,443) to the world!

We also need to add an HTTPS listener to ELB.
1. Click
2. Select
3. Click
4. Click

Oops, we don’t have a TLS certiﬁcate.
Let’s make that ﬁrst.
!!!!!!

Fortunately, AWS oﬀer an easy way to create a certiﬁcate.
1. Go!

Personally, I think this is the best service of AWS.
1. Click

1. Enter the domain name.  
I recommend that you use ‘*’.
2. Click
Use your domain!!

Since we have already moved our domain to Route53,  
DNS validation is easier than Email validation.
1. Click
2. Click

1. Click
Create a record in Route 53 to validate that you are the owner.

1. Click
It will automatically add the record to your Route53.

1. Click
Good, click continue!

Okay, ﬁnally we got a certiﬁcate.

Back to the ELB dashboard,
Now, we can select the certiﬁcate.
1. Select
2. Click

Now we have two listeners for ELB.

If you type your domain with https, you can see that it works.




Route53 : DNS

ELB : Load Balancer


Elastic Cache(Redis) : Session Storage
+

Session storage
- Cookie : Not secure.

- File storage : Disk I/O + can not be shared with other instance.

- Database : Good, but Disk I/O + additional burden on the database.

- In-memory DB : Highly recommended!
Session data : small and frequently requested

It’s better to make a security group for Redis ﬁrst.
2. Click
1. Click

1. Fill in
2. Fill in like this.
3. Click
Redis will use 6379 port.

Redis can be found in the service called ElastiCache.
1. Choose

We can also use Memcached but I want to use Redis.
1. Click

It’s important to choose t2.micro, otherwise you have to pay.
1. Select
2. Name it
3. Choose t2.micro(free)
4. Choose None
5. Go down

If it is the ﬁrst time, you need to make a subnet group like below.
1. Select
2. Name it
3. Choose all

Select the security group that we just made.
1. Select
2. Click

We can check the endpoint so that we can connect from our service.

As seen in this code, we are using Redis as a session storage.
You can ﬁnd the way to replace the session storage for any kind of
server side languages that you are using.
<DOMAIN> <REDIS_ENDPOINT>

Up until here is the tip of the iceberg.

The real beauty of AWS is auto scaling.

Example
Let’s say we have lunched a mobile game.
Unfortunately, it became too popular.
So we have to add more servers to deal with more users.
The maximum number of concurrent users per hour is 40000.
The minimum number of concurrent users per hour is 1000.
One server can deal with 500 people.
What is the optimal number of servers?

Solution #1 : Maximum number of servers
-> Too expensive, waste of servers for the non-busy time.
Solution #2 : Average number of servers
-> Sounds reasonable, but only government websites can do this  
because users will complain a lot.
Solution #3 : Use auto scaling!
->Yay!

Shit! I can’t do this anymore.
I need some help!
Okay the users are
coming.
I’m sending but
can you handle
them?

Okay the users are
coming.
20 to Jungwon, 20 to Hans,
20 to Simon,
20 to Luca… God damm it! He is
not healthy yet.
Hans : Healthy Simon : Healthy Jungwon : Healthy Luca : Unhealthy
Wait! I’m
coming!!
Phew, thank you
guys!

Okay, they are
starting to go to bed.
Okay, Hans, you can go,
Simon can go.
Luca can go.
Ok, now I can
handle it alone.
Hans : Deleting Simon : Deleting Jungwon : Healthy Luca : Deleting
See you!
Snakkes! Ha det~!

Important!
From this slide AWS will charge you.
If you do not want to pay then just read.




Route53 : DNS

ELB : Load Balancer



Auto Scaling Group : auto scaling !
+
Auto scaling

group

Move to Auto Scaling Groups
1. Click

Let’s make an auto scaling group.
1. Click

As you can see, we have to make a launch conﬁguration ﬁrst.
1. Click

It means, we need to set the initial setting for the instance.
(The instance that will be launched)
1. Click

Choose t2.micro.
1. Select
2. Click

This is the most important part, especially ‘User data’.
Let’s talk more about this.

There are two ways to make  
‘auto scaling group’.

#1. Copy an image (AMI) of your origin instance and let it be used
for the auto scaling group.
AMI
Pros:
- Short launch time (until becoming healthy!)

- No need to install ‘things’  
(they are already there) 
Cons:
- Diﬃcult to apply new updates. 
(To do that requires making another new image.)
Auto Scaling Group

#2. Use a pure instance image and and let it be used
for the auto scaling group.
Pure
Instance
Image
Pros:
- Easy to apply new updates 
(Because when it launches it will install ‘things’.) 
Cons:
- Slow launch time. 
(Because of installations!)
Auto Scaling Group

Both ways are ﬁne, but I prefer option #2.
That’s why I made a ‘start.sh’ ﬁle.

So here is the scenario.
1. Launch
the pure instance
2. Clone  
the service from git
3. Install softwares and  
run the service

Then how can we set it up so that it automatically  
acts like shown on the previous slide?
That’s why we need to set ‘user data’.

Let’s take a look at the user data.
#!/bin/bash

cd /home/ubuntu

git clone https://github.com/MuchasEstrellas/AWS.git

cd /home/ubuntu/AWS/architecture6_7

<REDIS_ENDPOINT>
1. move to the directory that contains the website
2. clone it from git.
3. move to the directory that will be run.
4. run the service.
It’s important to know that 
the user who is running the command above is ‘root’.
(Keep this in mind, just in case you face some path or permission problem.)

Okay here we are again.
1. Enter the name
2. Set the initial command that should be run  
right after the instance has launched
3. Next!

Add 80 port.
3. Next!
1. Click 2. Add

Okay, now we are ready.
1. Click

Just use same key that we made earlier.
1. Click

Okay, now we have to make an actual group.
1. Enter the name
2. Set the number of instances you want to begin with.
3. Add all subnets.
4. Check
5. Add the target group that we made while launching ELB.
6. Both are ﬁne for this test case, but it’s recommended to use ELB  
as long as you are not using classic load balancer.
7. Set it to 10sec (but you can choose how long you want).
8. Click

Let’s go for the ﬁrst option this time. We will add scaling policies later.
1. Next
1. Check

We can set the notiﬁcation, but I will skip.
1. Next

One instance is launching now.
Before we test it, we need to take a brief look at the AWS console.

If you check the target group under the load balancer section,
you can see the new instance.

You can also check the new instance in the instances section.

So, how can we make this auto scaling work?
When should they be scaled out and scaled in?

There are several standards that we can set.
For example the average amount of network “in” and “out”  
or the average cpu utilization.
For this case we will use “average cpu utilization”.

This is very simple.
If the average CPU utilization is over 50% then add one more instance.
If the average CPU utilization is below 40% then remove one instance.
We can also set the range of the number of instances. 
(e.g Min : 1, Max : 5)
Let’s see how it works.

We will use a new service called “cloudwatch”.

Basically this service is mainly used for monitoring our AWS services.
However, we can also set the alarm or event based on our standard.

For the autoscaling, we will use “Alarm”
1. Click
2. Click

1. Search your auto scaling group
2. Choose CPUUtilization.
Let’s choose “CPU Utilization” of “auto scaling group”  
that we have made.

1. Click Next.
And click next.

Okay, let’s set the ﬁrst alarm.
This is about when to add an instance.
1. Put any name.
2. Put any desc.
3. when it’s >= 50%
4. How many datapoints should be detected out of all the data points.
5. Literally, monitoring period and the way to calculate.
6. We will set the action later. (But you can set it now)
7. Create!

So, now we have one alarm that can react based on CPU Utilization.
- If CPU reaches 50% then it will be ALARM.
- If it’s under 50% then it will be OK.
- If there are not enough monitoring data, then it will be INSUFFICIENT.

Create one more for reducing the number of instances.
This time is <= 40.
Create!

Now we have two alarms that can be used for auto scaling.

So let’s set the Scaling Policy using the alarms that we have set.
Go to the autoscaling group dashboard.
2. Click!
3. Click!
1. Select!

We need to use our alarm, so click the box below.
1. Click!

Let’s get started with the case 1: adding the instance.
1. Name it whatever you want.
2. Choose the one that we have made.
3. Action is adding 1 instance.
4. This is for eﬃciently adding new instances. 
(Practically 10 seconds is too short, but for the test case I will go for 10sec)
5. Click!

Okay, it’s set. 
Let’s add a removing policy in the same way as the adding policy.
1. Click!

1. Action is removing 1 instance.
The other steps are the same, except the action part.
2. Click!

Okay, now we have two policies.

But we need to set one more, the range of number of instances!
Minimum number and maximum number of instances.
1. Click
2. Click

1. Scroll Down
2. Set min 1
3. Set max 5
You can make any min and max number of instances  
based on your budget!
4. This is also about the time  
before the next scaling action
5. Scroll up and click save button.

To test and monitor, we will install two softwares.
“htop” and “stress”.

The left screen is htop screen.
The right screen is command for the stress test.

Okay, now cpu utilization of this instance has reached 100%.

If you checked the cloud watch, you can see the “higher cpu” alarm is
on. It may not react quickly, be patient.

Now you can see two instances in your auto scaling group.

As you can see in the target group, there are two instances in the group. 
One is in the initial status.

It’s not healthy yet, it means the load balancer didn’t get the proper
response from that instance yet.

Now it’s healthy, maybe it ﬁnished installing things.

You can also check in the instance dash board.

Now there are three instances because it’s based on average cpu
utilization.
It may switch back and forth between 2 and 3  
because (100%+a%+b% )/3 <= 40%  
but (100%+a% )/2 >= 50%
That’s why cool down time is important!
However, let’s ignore it this time.

Now the stress test is over.
Let’s check if the number of instances will be reduced.

Okay, low cpu alarm has occurred.

The desired number of instances is 2.
However, the current number of instances is 3.

Yeah, it’s shutting down now.

After several minutes, now there is only one instance.

Okay the users are
coming.
20 to Simon,
20 to Luca
Hans : Healthy Simon : Healthy Jungwon : Healthy Luca : Healthy
Phew, thank you
guys!
Ferdinand
Really?
Meanwhile…..

Okay the users are
coming.
20 to Simon,
20 to Luca
Hans : Healthy Simon : Healthy Jungwon : Healthy Luca : Healthy
Phew, thank you
guys!
Ferdinand
Really?

We also need to consider the database
because it is shared by all the instances.

“But we are sharing S3 and Redis too!”

S3 is ﬁne.
Redis is also ﬁne because it is NOSQL.
(It means it is easy to scale out.)
-From AWS
-From Wikipedia

As long as we are using RDBMS  
as a main database,
there are 3 options.

#1 : AWS Aurora
I think this is the best.
However, I'm kind of afraid to migrate the
entire database to the new database.
-From AWS

#2 : Use EC2 and build multi-master manually.
This is what Slack is doing.
If you can do this, this is a good solution.
However, it sounds very diﬃcult to me.

#3 : Separate the Read and Write Database.
I think I can do this.

Let’s try to make a read-replica ﬁrst.

Find the RDS instance that we made before.
1. Click!

Let’s make a replica.
1. Click!

Click the “Create read replica”
1. Click!

Not to get confused, put a diﬀerent name and create it.
1. Click!
2. Go down and  
Create

Now we can see two db instances.

I will just write two endpoints in my python code.
For the read query I will use the ﬁrst url.
For the write query I will use the second url.
1. Read replica db!
1. Master db!

It is not the best way, but I just want you to understand the logic.
If you use other server side framework, there must be some convenient
way to separate the host addresses.
<For the read query>

Still, it doesn’t sound that cool.
For the read-replica,
every time something is written in the master database,
‘read-replica’ has to be written as well.
It means for them it is not that diﬀerent.
Write Read
Write
Master Slave
What’s the
difference for me?

There are several things that you can think
about.
Write operations are occurring less than the read
operations.
One solution to improve the RDS performance is
buying a better instance for Read-Replica.
Read operations are often complicated.
(Join,Union, Order by, Group By  
and amount of data)

Make many read replicas.
Write
25%Read
Write
Master
Slave1
25%Read
Slave2
25%Read
Slave3
25%Read
Slave4

Unfortunately, we can’t use load
balancer or auto scaling.

However, we can use Route 53 to
distribute the requests.


RDS1 : working as a master database


Route53 : DNS

ELB : Load Balancer



RDS2 : working as a slave database

+

Let’s make one more read-replica.

Let’s create one more Record set for the database.

I will name it “db.uisprogramming.com”.
The destination will be one read-replica’s endpoint.
1. Enter “db”.
2. Select CNAME
3. Select No.
4. Set it to 0.
5. Copy and paste one of the  
RDS read replica’s endpoint.
6. Choose Weighted.
7. Set it to 0.
8. Name it to read1.
9. Create!

Make one more record set with a diﬀerent read replica.
More about Weighted Routing policy

Now we need to change the url for the read query.

I just sent a heavy query to test through “new url”,  
as you can see replica2’s cpu is 22%.

Getting started with AWS

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Getting started with AWS

Similar to Getting started with AWS (20)

Recently uploaded

Recently uploaded (20)

Getting started with AWS