In the previous post we went over how to create a Network Load Balancer, in this post we are going to create one of types of load balancer AWS offers.  We are going to create a Application Load Balancer, this balancer  is designed to work best with the typical line of business web applications.  It deals mostly with the requests/response scenarios on the web, therefore it supports the HTTP, and HTTPS protocols exclusively.  It can be setup to respond to the routes that configured or the hosts.  It all depends on how your web applications serves the client.  In a way it's the easiest load balancer type to understand because it deals with headers, URLs,  routes,  parameters, query strings and etc.

Before we create the load balancer we need to create more than one instances with a web server because we need to test that the load balancer is able to switch.

1. Create four instances with the user data to create Apache Web Servers with these commands in the User Data for instance, if you need the full instruction on how to create instances with User Data you can read this post . 

 In the previous post we went over how to create a Classic Load Balancer, in this post we are going to create one of types of load balancer AWS offers.  We are going to create a Network Load Balancer, this balancer  is for websites that require high performance and low latency websites, think of streaming data.  If your website needs real time streaming data, this is probably the load balancer for you. It supports layer 4 protocols such as UDP, TLS and TCP protocols. If you need a static IP or Elastic IP assigned to your load balancer this is your only choice because the other two load balancer does not give you the option to assign Elastic IPs.

Before we create the load balancer we need to create more than one instances with a web server because we need to test that the load balancer is able to switch.

1. Create two instances with the user data to create Apache Web Servers with these commands in the User Data for instance, if you need the full instruction on how to create instances with User Data you can read this post

 In the previous post we went over what a load balancer is, in this post we are going to create one of types of load balancer AWS offers.  We are going to create a Classic Load Balancer, this balancer is not recommended by Amazon, you should only create this if you have to support EC2-Classic instances.

Before we create the load balancer we need to create more than one instances with a web server because we need to test that the load balancer is able to switch.

1. Create two instances with the user data to create Apache Web Servers with these commands in the User Data for instance, if you need the full instruction on how to create instances with User Data you can read this post

 If your website starts to become popular, especially if it's not static you might noticed that the performance is starting to degrade.  The most logical step is to scale your architecture with a load balancer.  AWS offers three types of load balancers, there are:

• Application Load Balancer
• Protocols (HTTP, HTTPS)
• Specializes in web applications, deals with traffic at the request level (layer 7)
• Supports query strings, path routing, parameter routing, IP routing
• Supports IP addresses, Lamda Functions (serverless, microservices), and containers
• Network Load Balancer
• Protocols(TCP, TLS, UDP, TCP_UDP) - Layer 4
• When high performance and low latency is required
• TLS offloading
• Elastic IPs can be assigned
• Classic Load Balancer
• Protocols (TCP, SSL, HTTP, HTTPS) - Layer 4, 7
• Old generation, not recommended unless you are running EC2-Classic instance

 In the world of AWS you have to be familiar with the different features and what they are called.  Well two very important building blocks of all the services that AWS offers are the S3 and the IAM Role.  S3 is basically an object storage repository that are called buckets, but it is more than just a storage, you can turn to the storage into a static website. We'll get into that later. It's public facing, so you can access it over the internet. 

IAM Role is an identity that you can assign policies to and that role assumes the permission.  Therefore only instances with a role that has a policy to access S3 can assume that role and have access to the S3.

So let's start creating the assets on the diagram above:

 In the previous post  we created a public and private subnet in our VPC.  In this post we are going to create a NAT gateway so that our private instances can access the internet.  That's useful when there's a need to update the instance.  For example if we ping google.com right now there will be 100% package lost in our private instance because we cannot get to the internet.  After we attach the instance to the NAT gateway we will be able to ping google.

It would go on for a while but eventually it would say the package is lost.

Now let's create our NAT Gateway, it is important that we delete the NAT Gateway if it's not in use because you have to pay for it.

 In most scenarios you don't want to expose all of your servers to be public facing.  You probably want to configure your network so that only the server that is hosting your web application is public facing.  What you want to do is put your web application on the public subnet and your backend servers on the private subnet.  This private subnet can access the internet through a NAT gateway for software updates and other functions that require internet access.  However, the outside world cannot establish a connection to servers in the private subnet.  The NAT gateway resides in the public subnet, acting as a bridge between the public subnet and private subnet.

 In the previous post we associated our Elastic IP with an instance directly.  In this post we are going to take another approach to assign our Elastic IP to our instance.  In this approach we will create an Elastic Network Interface and associate it with our instance instead.  In the first approach the Elastic IP replaces the public IP because we associate it directly to the instance. But if we create an Elastic Network Interface we are essentially adding a second interface in our instance with two IPs, eth0 is the main network interface and eth1 will be the second interface.  It's like having two network interface in the physical world but this time it's virtualized in AWS.

Here are the steps to create a network interface:

1. Create an Elastic IP, follow this post if you don't know how.

If you look at the instance description you will see that there's no Elastic IP address assignment, so if you stop and start the instance you will get a new public IP, and there's only one network interface (eth0). By the time we are finish with this post the instance will have tow network interfaces and an Elastic IP.

 In the last post we created our ACME Bank database in MySQL, the next step is to get the values from the Values table in the Asp.Net Core WebApi controller.  

Let's create some test data so that we could retrieve the values from the database.  The Values table could contain anything.  So I am going to store famous philosophers throughout history.  These philosophers are so famous that they only have one name: 

You can run the SQL insert statement below to seed the data in MySQL:

INSERT INTO acmebank.Values (
    Name
)
VALUES
    (
        'Socrate'
    ),
    (
        'Plato'
    ),
    (
        'Spock'
    ),
    (
	'Thanos'
    );

So your Values table should look like this when you executed the insert query

 When an instance is created in AWS a public and private IP is assigned to the instance.  The private IP does not change, but the public IP address changes each time the instance reboot or is stopped.  On reboot you might be lucky enough to grab the same public IP, but it's not guaranteed.  But on stoppage you will definitely be assigned a new public IP.

That's probably not a good thing a real world situation, that's where an Elastic IP comes into play.  An Elastic IP is a static IP that when assigned does not change.  However, there's no free lunch so you will be charged for it.  So only create one if you really need it.  I would recommend that you use the public DNS instead when you are not in production.  Say the development and test environment.  You might want to spend some money on the staging environment to mirror production as close as possible.

In the following section I will show you how to create an Elastic IP and assign it to an instance.  You probably want to delete it after you create it if you do not want to pay.  Only keep it if you want to use it.