There's more we want to do with networking on AWS. Because we've already created one subnet and it's associated with the public internet gateway, it's part of our VPC. But now we want to add the data plane. Now we want to add a database to it. But a database does not go, shouldn't go, in the same public access subnet where my web servers are, because I never want anyone from the outside, at least, in my business case, to access a database directly. So, we're going to make another subnet inside my VPC. But this subnet will not have access to the IGW. So this subnet is what we call a private subnet. And Morgan's going to create this and assign it the IP range of 10.10.2.0/24, but shes not going to assign IGW access to this. Go ahead. All right, easy enough. What we're going to do is come in here, and we will just select Subnets. From here, we can create a brand new subnet, and we're going to make this one private instead of public. So I'll click Create subnet, give it a name. We're just going to call this Private Subnet. We'll select the VPC, which is our directory VPC, and then we need to give this a CIDR block. We'll say 10.10.2.0/24. And then select Create, and that's it, we have our subnet. Okay, let's keep going. Now that the subnet's created, now we can go ahead and launch a database. We'll launch an RDS database. And then our application will be able to connect to the database because they live inside the same VPC. But nobody from the outside will be able to connect direct to that database. Go ahead. Well, I've already created a database for us. Blaine's going to show you how to create and configure your database in a future module. So for now, if we take look at our application here, we can see our data is coming directly from our database. So we already have it up and running, we can connect to it, we can connect to our app, but not the database directly through the internet. So, Blaine, that's it, right? What else do we got? Nice. We got a functional application that goes and talks to database, but wait, remember our lizard friend and the idea that I don't want to run in just one Availability Zone? I want to talk about high availability. So for that we want to move beyond just one Availability Zone, into a Multi-AZ strategy. Don't worry, I haven't forgotten about my lizard friend. So what we're going to do, is we're going to create two new subnets, one public and one private, in a separate Availability Zone. This is going to give us that high availability that we need. So first, we're going to create a new subnet. To do that, I'm going to click the Create subnet button and we're going to give this name Public Subnet 2. We're going to select the VPC, which is our directory VPC. And then for the Availability Zone, we have to select US-west-2b since we first launched in 2a. Then we'll give this a CIDR block of 10.10.3.0/24 and then click Create. We'll close that and we'll also create our private subnet. So we'll click Create subnet again, call this Private Subnet 2, assign it to the same directory VPC. Assign that to the same us-west-2b Availability Zone, and then we'll give this is a CIDR range of 10.10.4.0/24. Click Create there, close this. And the last thing that we need to do is we need to associate our route table that allows us to route internet traffic to our public subnet that we just created in our second Availability Zone. So to do that I'm going to select Route Tables. I'm going to find our public route table here and then I'm going to select Subnet Associations. At this point, we need to edit this and associate the new public subnet. So I will select Edit, find public subnet number two, click Save, and that's it. All right, we've created two new subnets and a separate Availability Zone. All right Blaine, we have are highly available network and another Availability Zone, what else are we doing? Great, thanks Morgan. So just to recap what she's done. She doesn't have to change the VPC because the VPC, by definition, already is a multi-Availability Zone structure. All she had to do was add in a new public subnet, which is going to be associated with the same IGW. And she created a new private subnet all in the other Availability Zone. And this one like my other private subnet, does not have IGW access. Now, the last thing that Morgan's got to do as far as launching instances, she's going to go ahead and launch a new EC2 instance in this private subnet, and then change my RDS to a Multi-AZ RDS. That's going to have a standby, running in my other Availability Zone. Go for it. Okay, so now what we need to do is launch an EC2 instance and another database behind it in our second AZ. I've already done that here, I've already shown you how to launch an EC2 instance, and we had to configure our RDS to have a Multi-AZ deployment. Blaine is going to show you that in a later module, so we are good for now. Blaine, let's finish this up. Perfect, now as we could see in the lab, we can connect to this public IP or this public IP. But do you really want your customers to have to choose which EC2 instance they log into? Of course not. That's what load balancers are for. So one more piece to put in here as part of AWS networking is an elastic load balancer, or an ELB. So Morgan's going to launch an ELB and associate that ELB with both of the EC2 instances, so that it doesn't matter which one gets the traffic. They're both going to get an even amount of traffic distributed automatically by the elastic load balancer. Let's see what you've got. Okay. So let's go ahead and create our elastic load balancer, or ELB. From the EC2 Dashboard, if you look on the left-hand side and scroll down, we're going to scroll to Load Balancers. Click Load Balancers and then create a load balancer. Now we need to select our load balancer type. We don't have to worry about this too much. I'm going to select an Application Load Balancer. From here, we need to give it a name. We'll call this DirectoryLoadBalancer. It's internet-facing, and we are going to leave the listeners for port 80 so that people can connect over HTTP to access our website. And now we will select the VPC that we want to launch this ELB into. Ours was the Directory VPC. Next, we have to select the Availability Zones that we will be directing traffic to, which is us-west-2a and us-west-2b. And then we will select the two public subnets in each of those Availability Zones. Next, we have to configure their security settings. We can skip through this and configure the security groups, which we're going to click the web-security-group, which is going to allow us to have that HTTP access over port 80. Next we'll configure the routing. So we have to give a target group. Our target for our elastic load balancer is our two web servers. So I'm going to go ahead and name this target group, webservers. We'll leave the Protocol as HTTP and the Port 80. And select Next for register targets. If you scroll down, we can see our two instances running so we already have our targets where they are supposed to be. I'll go ahead and select both of those and just click Add to registered, and now we can see those have moved up to our active registered targets. Next, I'll review this is everything that we just configured. So we have a load balancer that's internet-facing over port 80 for HTTP. We have our Targets, is our two instances. Lets's go ahead and create this elastic load balancer. All right, we successfully created our elastic load balancer. So, now, we have an endpoint we can access instead of accessing our two instances' IP addresses directly. So if we click Close here, we should be able to grab the endpoint for this load balancer. That's going to be this DNS name right here. So I'm going to go ahead and click copy for our DNS name for our elastic load balancer. Now I'm going to open a new tab and I'm going to paste that DNS name into the address bar. And we can see our application comes up. Now if you remember, when we first introduced this app, we showed you our special info page. So let's browse to that, / info, and now we can see which instance we are running on, and which Availability Zone that instance is running in. We can see here, we have this instance id, and we're running in availability zone us-west-2a. So If I refresh the page, we should see the instance id and the availability zone change, because the elastic load balancer is distributing traffic across our web servers. So I'll go ahead and refresh the page, and just like that, you can see the instance id changed and the availability zone changed. All right, well that's all we have here. Blaine, let's go ahead and wrap this up. That's it for basic networking. We're going to add some more things as this course continues, but right now, let's review what we've got. We've got all the pieces you need to run a successful web application. You've got your VPC, the virtual private cloud. That is going to isolate your traffic from anyone else inside AWS. You've got traffic coming in from the public IGW that is going to go through the elastic load balancer and be distributed to either one of the EC2 instances. The instances are going to all talk to the database. The master database has a standby database in the event that something goes wrong. Well, the only thing that we haven't talked about is what if you want to communicate to your objects, but you don't want to go to it over the public internet? There's one more type of gateway we can add into your VPC and that's called a virtual private gateway. And a virtual private gateway, or a VGW, can be created and attached, and this can even be associated with your private subnets. So that if you've got a DBA, that is connecting over your own on-premises data center, she can connect through the VGW over a VPN connection and never go through the IGW. And that's it. We've got all the pieces you need. Public access, private access, public EC2, private databases, we're looking pretty good.
