Forem: AntonNguyen97

How to build your own private cloud on AWS part 2

AntonNguyen97 — Fri, 04 Sep 2020 13:36:36 +0000

Hi! In the previous part, we have created our own private cloud using VPC on AWS. If you haven't read it, make sure you do, before starting this article.

So let's test our VPC. I created 3 EC2 instances in 3 different subnets, as you can see below:

Appus-isolated-subnet-B and Appus-private-subnet-A do not have a public IP address, they only have private ones - 10.0.23.186 and 10.0.12.221.

So let's log into our instance that has a public IP address and try to ping Google.
I have logged into my instance and sent some packages to Google, and as we can see it has an Internet connection:

Let's log into our Appus-private-subnet-A instance through a private IP address. Using the ssh command we can log into it "ssh -i your_key.pem ubuntu@your_private_ip". Now we can ping any host.

As we can see, it is connected to the Internet through the NAT server. But the Internet can not ping our instance since it has no public IP address. So let's exit this server and log into an isolated server.
Using the ssh command we can log into an isolated server - "ssh -i your_key.pem ubuntu@your_private_ip". If we try to ping any Internet host there will be no packages received.

This is it, I hope this article was helpful for you!

How to build your own private cloud on AWS part 1

AntonNguyen97 — Fri, 04 Sep 2020 13:35:56 +0000

In this series of articles, I will show you how to build your own private cloud on AWS. Here, in Appus studio we always put the security of applications of our clients first, so we recommend them getting their own VPC with public, private, and full isolated subnets.
So let’s get started. Open your AWS console and search for VPC. In the left menu bar, you can find “Your VPCs”, left button click on it and all VPCs you have should be visible to you. If you haven't configured your custom one, there is always one default VPC provided by Amazon. Click on “Create VPC” and enter the name of your VPC, CIDR block (range of IP addresses that work in this VPC). In my case, I use this 10.0.0/16 it is 65,536 IP addresses minus 5 reserved by AWS. I will keep all other configurations default because I do not need them.

Now our VPC is created. The next step is to configure Internet Gateway and attach it to our private cloud to have Internet access. On the left menu bar find the “Internet Gateways” tab and by default, there is just one provided by Amazon. Click on “Create internet gateway”, name it, and hit “Create”. Now it has a detached state, to attach it all we need to do is click on “Actions” -> “Attach to VPC” -> and select your VPC.
So we have created our VPC and attached Internet Gateway to it. The next step is to create our subnets. Left click on “Subnets”. By default, it has as many subnets as your region has availability zones. We will create our subnets in two different availability zones. Hit “Create subnet” and fill out the “Name tag” box, choose your VPC, choose one of the availability zones that Amazon provides in your region and enter the CIDR block for this subnet.

Let’s configure the same public subnet but in another availability zone.

Now we need to tick auto-assign public IPv4. Choose your subnet and hit “Actions” -> “Modify auto-assign IP settings” -> “Enable auto-assign public IPv4 addresses”-> “Save”. These steps are for public subnets.
Now we will modify our route table for our subnets to be able to access the Internet. Now go to “Route tables” -> choose your route table -> “Actions” -> “Edit routes” -> “Add route” -> Destination(0.0.0.0/0) and Target Internet Gateway and choose yours -> “Save routes”.
The next step will be to create a private subnet in different availability zones.

And another one:

When a private subnet is created we need to configure the route table for it. On the left menu bar click on “Route tables” -> “Create route table” and create new route tables for first and second private subnets.

Then we need to attach this route table to our private subnet. Click on your private subnet, then “Subnet Associations” -> “Edit subnet associations” then choose private subnet –> “Save”:

So let’s configure isolated subnets in two availability zones.

And another one:

And now we will create a new route table for our isolated subnet:

Now attach it to our isolated subnets:

We have come a long way. Now we will configure NAT for our access to the Internet from private subnet. Click on “NAT Gateways” -> “Create NAT Gateway”. NAT will be attached to public subnets and it needs an Elastic IP address. If you do not have one, just click on “Allocate Elastic IP” -> “Create NAT gateway”

We need 2 Elastic IP addresses for subnets A and B. So I will create another one but with another public subnet. It will take some time for NATs to switch to the available state. If you did everything correctly you will see this:

Now we will attach those NATs to our route tables. We will attach NAT-A to private subnet A and NAT-B to private subnet B:

And for another one:

Finally, we are done and here is the result of our work:

In the next part we will test our environment. See you soon!

Failover Architecture on AWS(Part 4/4)

AntonNguyen97 — Thu, 18 Jun 2020 15:59:18 +0000

Finally, we are here in the last part of this article. Please make sure that you read 3 previous parts and then continue to read this one.
In 3 last parts (part 1/4, part 2/4, part 3/4), we got an SSL certificate using Certificate Manager, configured load balancer, launch templates and an auto-scaling group. The last step is to attach the DNS name of the load balancer to our domain name in Route53.

So navigate to Route53 and then click to your domain and then hit “Create Record set”, create the subdomain or leave just domain itself depends on what kind of an SSL certificate you own. Now, we need to choose our load balancer Alias, hit “Yes” near to “Alias” and in “Alias Target” chose your load balancer it will something like “dualstack…” and then hit “Create”. In the end you must have something like this:

Finally, you can type your domain into a web-browser (https://your-domain.com) search bar and see how load balancer works. You can clearly see which server the load balancer will send you to.

Remember, all these configurations in Route53 may take several minutes to be "Live" on Internet, do not rush to be upset if your site is not working yet.

In my example web-pages will look like this:

As we can see load balancer works well and our connection is secured.
In the end of it all we have built a high availability production environment. All these will make us sure that our service will always on, auto-scaling group will be guarantor of our confidence.
This was the easiest way to configure failover architecture on AWS.

Here in Appus Studio we have several solutions for building a more complex and extensive configuration depends on how cool and large the project is.

I hope that I helped you figure out some points. Thanks for following me in the last four parts!

Failover Architecture on AWS(Part 3/4)

AntonNguyen97 — Thu, 18 Jun 2020 15:29:49 +0000

Hi there! Let’s continue our job. By the way, if you are the new one to this I recommend you to read two previous parts, here and here. In part number three, we will create a launch template and auto-scaling group.

So, go to EC2 service and on the left menu bar in the “Instances” section you can find “Launch Templates”. Click on “Create launch template”. Give a name to your launch template and a description. Then choose any AMI that you want, I will use Ubuntu Server 18.04 LTS (HVM), pick instance type, I will use t2.micro because we do not need a powerful server for this example. Then create a new key pair or choose the one that you already have. I will pick the one that was created early by me. Next, we will choose/create a security group, I will use the one that created in part number two of this article. Also, you can add more volume and network interfaces to it if you want to. For this example, I will not do it. Then click on “Advanced details” all we need here is put the script that will be processed after the system boot.
All it does is updating the system, configure NGINX, and modify the default startup page of NGINX, start NGINX and enable it to start on system booting. Below you can find the text of the script:

Then click on “Create launch template” button. Once you see the green checkmark “Success”, congrats launch template created.
Ok, let’s go back to EC2 service, and on the left menu bar in “Auto Scaling” section you can find “Auto Scaling Group”.
Now, we will create our auto-scaling group. Click on “Create Auto Scaling group” give a name to your ASG(Auto Scaling group) and choose the launch template that was created early. Check all configurations and then hit the “Next” button.

On step number 2 all that we need it is to add more subnets to our ASG, we will choose each of them as I mentioned early we need high availability architecture, so instances will launch in every availability zone randomly.

On step number 3 we will enable load balancing and choose classic load balancer that we configured early. Other options we will leave it by default.

On step number 4 we will configure group size and Scaling policies. As the desired capacity I need 2 instances, the minimum is 2 and maximum capacity 5. For this example, I will choose the desired outcome and leave it to the scaling policy to add and remove capacity as needed to achieve that outcome. The policy name I will leave as “Target tracking Policy”, metric-type – average CPU utilization, target value equals 50.
In this example, I will skip step number 5, in this case we do not need notifications, but you can configure it if you want to.

On step number 6 we need to add tags. I will add Key=Name Value=Appus Studio so our instances will have a name as Appus Studio, you can give any name that you want. Then review all configurations and hit “Create Auto Scaling group” button. Now the auto-scaling group will create new instances, you can go to “Instances” and check it.

Wait until the “Status check” will be “2/2 passed” and then you can go to load balancer section and check for instance status for balancer. Once you see the status is “2 of 2 instances in service” it means all instances have passed health check. You can check the performance of the load balancer by going through the DNS name of the balancer itself (https://your-load-balancer-domain). For now, the page is not secured just because the SSL certificate was issued to the domain name that you specified in part number 1 of this article. We will fix it in the next part of an article.

Further, you can modify all parameters of the auto-scaling group, such as scaling strategy, use a new load balancer, etc.

This is the end of this part and I’m looking forward to seeing you in the next part!

Failover Architecture on AWS(Part 2/4)

AntonNguyen97 — Thu, 18 Jun 2020 15:16:01 +0000

In this part of an article we will create our brand new load balancer. If you are new to this I recommend you to read the first part of this article “Failover Architecture on AWS(Part 1/4)” to be aware of what's going on.
So, let’s go to EC2 service and configure the Load Balancer. On the left menu bar in the section “Load Balancing” you can find “Load Balancers”. Amazon has 3 types of Load Balancers:

Application Load Balancer
Network Load Balancer
Classic Load Balancer

The description each one of them you can find here: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/load-balancer-types.html

Click “Create Load Balancer” and hit “Create” on Classic Load Balancer.
On step 1 we are going to configure Load Balancer’s name, listeners, and VPC configuration. You can give to it any name that you want, add listeners that you need, by the default it is only HTTP port. In our case, we will only open HTTPS port, so I deleted HTTP protocol and add HTTPS protocol to it. So the Load Balancer will listen to port 443 and then forward it to port 80 to instances. Then we are going to enable advanced VPC configuration and add all available subnets because we want a high available system. In my region, it has only three, if your region has more I recommend adding all of them, also you should remember that every zone has a price for it.

On step number 2 we are going to configure a security group. Choose “Create a new security group” give a name to it and a description. I want to open 80, 443, and 22 ports and port 22 allows only for my IP address.
On step 3 we will attach our SSL certificate to Load Balancer. Hit “Choose a certificate from ACM” and in the “Certificate section”, you will see your SSL certificate that requested early. In the Cipher section, I will use the predefined security policy “ELBSecurityPolicy-2016-08”. You can change your security policy but I recommend familiarizing yourself with each of the security policies provided by AWS, also you can create a custom one.
On step number 4 we need to configure health check. It is the part when Load Balancer will ping our instances to make sure they are alive and working. Below you can see my configurations:

So these configurations tell that load balancer will ping port 80 to path “/”, response timeout will be 5 seconds, interval of pinging every 10 seconds, if 5 pings will not have a response that means the instance is not alive and automatically status of it will be “Out of service”, the healthy threshold is 5 times of successful response by instance.
On step 5 you can see all available instances that could be picked by the load balancer, of course, if you have running EC2 instances right now, for now, I will not add any of them because we want it to pick only instances created by the auto-scaling group. All other configurations we will leave it by default.
On step 6 I will create a tag for our load balancer with Key=Name and Value=Appus Studio.
On step 7 review all configurations and click on “Create” button. If you see a green checkmark that tells “Successfully created load balancer” Congrats we have done it!
Next, we will configure launch template and auto-scaling group. All this will be described in the third part of the article.

Failover Architecture on AWS(Part 1/4)

AntonNguyen97 — Thu, 18 Jun 2020 15:06:11 +0000

INTRODUCTION

Nowadays it is important to have highly accessible architecture on production servers to prevent unpleasant situations e.g. service unavailability. So, here in Appus Studio we have some good solutions for it and in this article, I will show the easiest way to configure the failover system in AWS.

Let’s take a look how our sсheme will look like:

In this example, we will use services such as EC2, Route53 and Certificate Manager.
Let’s clarify our next steps:
       1. Request SSL certificate on Certificate Manager
       2. Create Classic Load Balancer
       3. Create Launch Template
       4. Create Auto Scaling group
       5. Attach DNS name of Load Balancer in Route53

After we have outlined our action plan, we can start configuring all of this.
So let’s request for SSL certificate on the Certificate manager. In the search toolbar enter "Certificate Manager" and click on it. Next, you have to choose to import your own SSL certificate or you can request it right here on AWS. The important thing here is you have to own domain name and make sure that you can create a recordset.
Before requesting your certificate, you need to transfer the domain name under the management of AWS. In this article, I will skip that part and you can find a lot of information on how to do it, just "google" it :)
Now, I will request an SSL certificate on AWS. Choose “Request a public certificate” and then hit “Request a certificate”. Then you have to enter your domain e.g. appusthebest.com or you can generate a wildcard SSL certificate by entering *.appusthebest.com it will allow you to have as much as you want subdomains for appusthebest.com, but this certificate will not work for appusthebest.com. In my case, I will create a wildcard SSL certificate for the corporate domain and hit “Next”. For verification, I will choose “DNS validation”. Next, we will need to add a tag to our certificate, you can add anything that you want, in my case this will be Key=Name and Value=appus.thebest then left-click on “Review” and “Confirm and request”. Since the domain name is managed by AWS this is very convenient to confirm that we are truly the owner of the domain name. All I need is to click the arrow near to the domain, then the tab comes off and then click on create a CNAME record in Route53. Once it is confirmed you can see on the Status bar “Issued”. Congrats, we just requested an SSL certificate for our Load Balancer.

On this the first part of the article ends and in the next part I will show how to configure the load balancer. See you!