In the previous post we created an EC2 instance in AWS in this post we are going to connect to that instance on a Linux workstation or server with SSH.

Here are the steps to connect to the EC2 instance using SSH on Linux, this will also work on a Mac as well:

1. Navigate to the folder that contains the key pair file that you've downloaded in the previous post, I store it in the folder /aws/EC2/KeyPair/ folder , so I would type cd /aws/EC2/KeyPair then type ls to see the file in the folder

 In the previous post we created a load balancers with the target groups, rules, and instances to handle HTTPS traffic.  In this post we are going to set up our DNS records in Route 53. So go to the Route 53 dashboard, click on your domain

1. Click on "Create record"

 In the previous post we created four instances with a Launch Template. In this post we are going to add DNS records in Route 53 and configure our Application Load Balancer with our certificates.

Before we start creating stuff let's take a step back and look at how we want to configure the website.  Let's say a bank wants to branch out into investing, so it wants to dedicate to instances to it's investing arm.  In our architecture we would have two target groups, one target group handling traffic for https://acmebanking.com and the other target group handling traffic for https://investing.acmebanking.com

We are going to register all four instances on the load balancer.

1. So now we ready to create an Application Load Balancer, give it a name and for the listener add an HTTPS listener to the existing one

 In the previous post we created our certificates in the Certificate Manager, in this post we are going to create four instances using a Launch Template so that we could use it in our load balancer.  

1. We are actually going to use "Launch Template" to create our instances, so click on "Launch Templates" under "Instances" in the EC2 Dashboard

3. Give your template a name, then scroll down to AMI type

 In this post we are going to set up our website to serve up https traffic so that our traffic can be encrypted.  In this post the first part of the series we are going to request a certificate from the Certificate Manager in AWS.

1. The first thing we need to do is create a certificate, In the AWS search field search for Certificate Manager then click on the drop down auto complete choice.

 In this pose we are going to implement auto scaling on our instances.  Auto scaling is a feature on AWS that automatically scaled horizontally either based on metrics or the health of an instance. In this post we are going to setup auto scaling on an Application Load Balancer.  

1. The first thing we have to do is setup an Auto Scaling Group under "Auto Scaling" click on "Auto Scaling Groups"

 In the previous post we went over how to create a Application Load Balancer, based on routes in the URL.  In this post we are going to change the rules so that it directs traffic based on host names.  For example we could have acmebanking.com route to target group 1 and accounts.acmebanking.com route to target group 2.  It's the same concept as the previous setup but instead of routes, we are using hostnames instead.

In order to implement this solution we need to setup a record in Route 53, which is AWS domain registration service.  You can follow along with the DNS names, but if you have a hostname registered with AWS that's even better.

1. So the first thing you want to do is go to Route 53 dashboard, go to Hosted Zones

 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

 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 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

 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.

 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.

 CloudWatch is a service on AWS that is used to monitor services on AWS via metrics.  In addition to monitoring resources.  CloudWatch can be used to set alarms and perform some actions on the instance when a certain condition is met.  In this post we are going to set an alarm on our instance if CPU utilization gets to a certain threshold.  Which is a typical safeguard that most environments have, there are several actions that you can take when the threshold is met, in our case we are going to terminate the instance if the CPU utilization reaches 75%. 

The following shows you how to set a CloudWatch alarm on our Linux instance:

1. Click on "Monitoring" tab in the "Instances" page, then click on the "Create Alarm" button

 User Data in an instance allows you run commands while your instance boots up.  In the previous posts we just plain vanilla instances so far.  But in this post we are going to install the Apache Httpd service when we create our instance using User Data.

Here are the steps to create an instance with User Data:

An instance metadata is data about your instance that you can use to configure your instances.  They are divided into categories.  Anyone who have access to the instance can view the metadata, therefore you should not store anything sensitive that could be accessed such as "User Data"

You can get more information here at Amazon's website:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html

You can access your metadata with this URL http://169.254.169.254/latest/meta-data/

Here are the steps to retrieve your instance data:

 1.  Connect to your AWS Linux instance and type curl http://169.254.169.254/latest/meta-data/

 In this post we are going to connect to a Windows instance using RDP.  In order for us to connect to the Windows instance we need to get the password for the server using the key pair that we downloaded from the last post when we created the instance, the .pem file.

Here are the steps to connect to the Windows instance using RDP:

1.  Navigate the EC2 "Instances" page, check the instance and click "Connect"

2. On the next screen click on "Get Password"