Hello, my name is Dimitria Crawford, and in this lesson we will review native AWS Services. AWS comes with specific services that you'll have to create your network environment from. And with this, we're able to actually set up several different types of network security. There are capabilities that are built into this particular network environment and what this network environment is called is our VPC, our Virtual Private Cloud. So if we type in VPC, in the search bar the first thing we'll see on our list is VPC isolated cloud resources. Let's go to the VPC dashboard. From the VPC dashboard you'll notice that there's several services that we have available to us. If you look on the left-hand side under the VPC dashboard, you'll notice that we have the virtual private cloud and several items that we could set up there. We have security, network analysis, DNS firewall, network firewall, Virtual Private Network VPN, AWS cloud WAN, transit gateways, and traffic mirroring. Now, a lot of these are very detailed and advanced, and that go beyond the cloud practitioner level. However, whenever setting up a VPC, there's a basic foundation of security that we have to have and those are NACLs, Network Access Controls and security groups. If we go under the security category we'll find the network ACLs and security groups. The difference between the two is if we were to compare this to a neighborhood, a community of homes, and there's a gate that's protecting entry into the community, this would be your NACLs. This is protecting the entrance and the exit of your virtual private cloud. Security groups is the protections that are applied to your specific home. So in this case, security groups are the protections of what go in and out of our AWS Services, for example, EC2s. If you are running a database server and you want protection specifically for that database server, then we're gonna set up security groups. However, if we want protections for everything that's flowing in and out of our VPC, then we're gonna set up NACLs. As a best practice, you're going to set up both and use both for different reasons. So let's go ahead and take a look at network access controls, we'll start there. By default, you're going to have default security controls already set up for your default VPC. If you create additional VPCs then you're gonna have to create your own security groups and NACLs within those as well. So if we actually check the box for our default VPC, we'll notice that there are six subnets that are attached to this VPC. But if we go down to the bottom, we have details, and the two we want to take a look at are inbound rules and outbound rules. Inbound rules, we are defining what type of traffic are we allowing into our VPC. By default, you'll see that we're allowing all traffic, all protocols, from any port range, from any IP address and it's allowed. Below that you'll see a implicit deny. So if I wanted to say that I do not want to allow SSH into my VPC, what I would have to do is actually add an inbound rule here. So if I want to edit inbound rules I can add a new rule and give it a rule number, and the importance of the rule number is that these are gonna go in order. So if I want something to occur before the other, I have to put the number ahead of it. So it'll be number 90. In this case, I'm gonna make this 200 and I have to tell it what type of traffic. So these are the ports. You can either go by port number or the actual name of the port. So let's say I want to allow SSH, it will already have port 22 for me so I don't have to put the port there. I can say every source is allowed in or I could give a specific subnet that I want to allow in, or a specific IP address. For security best practices you want to confine the list of resources. So you don't wanna allow everything in. So let's say I have five specific IP addresses that will be allowed to SSH into my VPC, then I only want to give those specific five IP addresses. Then, am I allowing or denying? In this case I'm going to allow. Now what is the problem we have here? My first line says that I'm allowing any traffic. Second line says that I'm only allowing specific people if I had my IP addresses here to SSHN. So I'm gonna remove that first line right now. If I were to save these changes the only thing that would be allowed in is for the purpose of SSH, and that would be the rule. Here's the thing about network access controls. You're gonna have to define what's allowed in and what's allowed out. So if you have a database that a person is connecting to and they're able to go in, but you don't have anything that allows anything to come back out, they may not receive any activity from that database because there isn't an outbound rule, but that's specifically for NACLs. So in this case, I'm gonna save the changes, but now I also have to go to my outbound rule, edit outbound rules and I would have to add a new rule that would allow and it doesn't have to match the numbers from the other side. I have to allow SSH out as well. Now, I would have the ability to only allow SSH in or out of my VPC. Now is this what I have set up normal? No, not for NACLs. We're gonna have a lot more there as far as rules. For example, we may want to allow port 84 HTTP in port 443. So there are various ones. You're a little bit more granular, a lot more is allowed as far as what comes in and out of your VPC, because it's not just about one instance, it's everything that's functioning within that VPC. So we wanna make sure we do allow all of the services that we're running, the capability to actually communicate in and out of our VPC if necessary. For example, if we have websites that we're running off of our web servers, well, if we don't allow port 80, no one's going to be able to connect to your website. So those are things to consider and proper troubleshooting skills that you might want to take a look at if you're having trouble with connectivity.
