Amazon AWS Certified Developer Associate – Virtual Private Cloud (VPC) Part 6

8. VPC Flow Logs

I’m here in the AWS console, and I just want to go over to VPCs and I can go in and click on my VPC and I’m going to click on my VPC, the little checkbox and I’m going to go over to Actions and I’m going to create a flow log. So basically flow logs enable you to capture IP traffic, flow information for the network interfaces in your resources. So it’s basically going to capture basically all the traffic and it’s going to report it to Cloud Watch. So right now I don’t have an IAM role set up for Cloud Watch.

So I’m just going to go and click on set up permissions. And what I want to do is I just want to create a new Im role. Here we go, flow logs role. We can view the policy document and it’s basically going to allow me to send this to Cloud Watch. Going to go ahead and hit Allow, and then we can go back into VPCs, go back to my VPC, go to Actions, create my flow log.

And then if I click down here, we’ll now see it says flow logs role. And so now the destination log groups. I’ve actually got no log groups created right now. So again, what I’m probably going to have to do is just go back over here, I’m going to hit cancel. I’m going to go back over into Cloud Watch and we scroll down under Management tools. We’ve got Cloud Watch. And then what I’m going to do is I’m going to go in and create some logs. And so what I’m going to do is go click on logs and I’m going to create a new log group and I’m just going to call it my custom VPC logs.

Go ahead and hit create. So that’s created my log group. And now if I just go back to my VPC management console, I should be able to see that in there, I’m going to click on it and I’m going to create my flow log. And that is literally it. It is literally that simple. So now any traffic that’s going into my VPC is going to be logged. What I might want to try and do is just go back over here and open up my web page again, hit a refresh. And that’s actually struggling to connect right now because I blocked my own IP address in one of the last lectures. So I can just enable my VPN.

As soon as that happens, basically I should be able to access it again. So there we go. And now I can load the web page fine. So Cloud Watch, it’s going to take a little bit of time for the logs to come into Cloud Watch. So I’m in the Cloud Watch console, I’m going to click on logs and click on in here. And I need to create a log stream.

So this log group does not have any log streams. I’m going to go in and create my own log stream. I’m just going to call it my log Stream and hit Create. And there we go. So now we’ve got our log streams in here. Once you’ve got your log stream created, just go back over, refresh the page to your web server and then if you come back to Cloud Watch, you’ll be able to see a log stream that’s been created. And you can see that VPC flow logs is now starting to log all the data that is happening within your VPC. And there we go. Some entries are already in there, so you can definitely log everything that goes on inside your VPC. It’s using VPC flow logs in order to set up a flow log. It’s pretty easy. You just go into your VPC like we saw and you created.

Then you just need to also create an IAM role to give you access to log to Cloud Watch. And then you also need to go in and create your log groups. And then obviously inside our log groups, we had to go in and create our log stream. And then after that, it streams all the data straight into Cloud Watch and we can build monitoring and metrics around it in the normal way in which we would use Cloud Watch. So that is it for this lecture guys. Again, it’s still quite new VPC flow logs, so it may or may not not come up in the exam. But it’s a good thing to know that you can definitely log all the traffic inside your custom VPCs by default using VPC flow logs. So if you have any questions, please let me know. If not, feel free to move on to the next lecture where we summarize everything we’ve learned in this section of the course.

9. VPC Clean Up

Okay, so here I am in the AWS console. I’m going to go over to EC two and I’m going to start deleting my poor little EC two instances. So go into the EC two set.

10. VPC Summary

Okay, so let’s go back to what we learnt in the very first lecture in this section of the course. So think of a VPC as a logical data center within AWS. You can have VPCs in every region in which AWS exists. VPCs can span multiple Availability Zones, but what VPCs can’t do is span multiple regions. So you always have a VPC in a predefined region. VPCs consist of Internet Gateways or virtual private gateways. If you’re doing like a hybrid cloud and you’re using a VPN to connect into your VPC, they consist of route tables, network Access Control lists, subnets, as well as security groups. One subnet always equals one availability zone. I cannot stress this enough. It comes up all the time. Just remember that and you’ll be fine. You cannot span a subnet across multiple Availability Zones. Security groups are stateful, network Access Control lists are stateless. And all we mean by that is when we open up port 80 in a security group, both the Inbound and Outbound rules automatically allow port 80. Whereas if with Network Access Control Lists we have to go in and do allow or deny on both our Inbound and Outbound rules, you can peer VPCs in both the same account and with other AWS accounts.

So you can have a VPC peering arrangement with a completely separate AWS account. That does definitely work. But remember, there’s no such thing as transitive peering. What do we mean by transitive peering? Well, typically this is called a Hub and spoke design. And this is where with Vpca we would have all our central servers. So we’d have things like our Active Directory servers, we’d have our servers that do all our monitoring, we’d have our Antivirus servers, and then they would then peer with different VPCs. So Vpcb might be our production environment, VPCC might be our testing environment, VPC D might be our developer one environment. Vpce might be a second developer environment. And basically, if they need to access Active Directory, or if you’ve got antivirus agents installed on all the servers in these VPCs, they’re going to need to peer back to Vpca.

But if we have Vpcb and we want it to talk to VPCC, it cannot do that through Vpca. There’s no transitive peering. Instead, we have to allow a direct peering connection from Vpcb to VPCC. Moving on to Nat instances. When creating a Nat instance, always remember to disable source and destination checks on the instance. Nat instances have been around for as long as I can remember, whereas Nat gateways are very new. But Nat instances do come up in all the Associate exams. You do have to really know Nat instances inside out, even though really they should start going away. Now, Nat instances must be in a public subnet, and they must have an elastic IP address assigned to them to work. And there must be a route out of the private subnet to the Nat instance.

In order for a Nat instance to be able to work. And the amount of traffic that Nat instances supports depends on the instance size. So if you’re bottlenecking, if you’re using a T two micro for example, and you’ve got huge amounts of outbound traffic to the Internet, or inbound traffic from the Internet, you’re going to need to increase that instance size. And you can create highly available or high availability using auto scaling groups, multiple subnets in different availability zones and scripts to automate failover. So it is definitely possible to have a highly available net instance, but it’s also a pain to set up. And net instances are always behind a security group.

Now, Nat gateways are not necessarily in the exams just yet, because they are very new, but it’s still good to know about them because you’re probably going to use them in the real world. You’d always use Nat gateway over in that instance, in my opinion. I’m sure someone’s going to find a scenario where you wouldn’t do that, but anyway, in most cases you would, and they’re preferred by the corporate or by the enterprise market. They scale automatically up to ten gigabits per second. There’s no need to patch Nat gateways AWS look after them for you. Whereas with a Nat instance you’ve got to run your Yum update all the time to keep them patched. And they’re not associated with security groups, they’re automatically assigned a public IP address.

And when you deploy your net gateway, remember, just as what you do with your Nat instance, you’ve just got to add a route out via your Nat gateway in order for it to work. But there’s no need to disable source destination checks on a Nat gateway. Moving on to our network ACLs. So your VPC automatically comes with a default network ACL as well as a route table when you first create it.

And by default it always allows all inbound and outbound traffic. Then you can go on and create custom network access control lists, but by default, each custom network ACL denies all inbound and outbound traffic. So when you provision it, it’s deny everything, and then you go in and add your rules. And that’s a useful security feature. Each subnet in your VPC must be associated with a network Access control list, just as it must be associated with a route. If you don’t explicitly associate a subnet with a network access control list, then the subnet is automatically associated with the default network ACL.

And again, if you don’t associate it to a root table, it’s going to use your main root table as well. You can associate a network ACL with multiple subnets. However, a subnet can be associated with only one network ACL at a time. And when you associate a network ACL with a subnet, then the previous association is removed. It’s really critical to remember that, especially when you’re going into the professional level exams. So just remember, and we saw it happen in the console. If you remember, as soon as we associated our subnet, it disassociated from our main default network ACL, and then it was associated with the new network or the custom network ACL that we created in the labs.

A network ACL always contains a numbered list of rules that is evaluated in order, starting with the lowest numbered rule first. So you remember if we wanted to deny a specific IP address, we would do a deny first and then we would allow our Http traffic for all other IP addresses. It didn’t work when we had our deny in front of our allow. It didn’t work when we had rule number 100, and then 101 was our deny rule. We wanted to make our deny rule number 99.

A network ACL has separate inbound and outbound rules and each rule can either allow or deny traffic. And that basically means that network ACLs are stateless responses to allow inbound traffic, are subject to rules for outbound traffic, and vice versa. And then finally, if we want to block IP addresses, we’re always going to use network ACL. We’re not going to use security groups because there’s no option to deny traffic in a security group anyway. Moving on to Nats versus Bastions.

So a net is used to provide internet traffic to EC two instances which are in our private subnets, whereas a bastion is used to securely administer EC two instances. So for Linux you’d use SSH, for Windows you’d use RDP, and then you use that bastion to go in and secure your EC two instances in your private subnet. And so in Australia we call them jump boxes. I like to remind people of that simply because a lot of Australians will go in and do the AWS exams and think what the hell’s a bastion host?

And the other reason is it gives you a very good visual aid in that you basically SSH into an EC two instance that’s in your public subnet, and then you jump across into the private network using SSH, and that’s why we call them jump boxes. So basically you’re using your bastion host as a way to jump into the rest of your private network. Moving on to resilient architecture. So basically, if you want resiliency, you’re always going to have to have two public subnets and two private subnets. That’s because one subnet always equals one Availability Zone. And you want to spread these across different Availability Zones. You got to make sure each subnet is in different Availability Zones with elastic load balances. You need to make sure that they are in two public subnets and in two different Availability Zones. In order to ensure resiliency with bastion hosts, you should put them in an auto scaling group with a minimum size of two and then use Route 53. And you can either use round robin or health check to automatically fail over between your bastion host and that will protect you against an individual virtual machine failure as well as an entire availability zone of failing on you.

And then Nat instances are a little bit trickier to make resilient. You need one in a public you need two. One in each public subnet and each with their own public IP addresses. And then you need to write a script to failover between the two instead. Where possible in real life, you just want to use Nat gateways and then Amazon handle the failover for you. And then finally you can monitor what goes on inside your VPCs using VPC flow logs. So that is it for this section of the course, guys.

If you do the essay associate exam first, do remember that you’ve got a very small delta in terms of study to pass the developer and the SysOps Administrator associate. There is a lot of common ground between all three associate exams. And if you know this networking section inside out, you’re so well prepared to not just pass the SA associate, but to pass the other two as well. So if you have any questions, please let me know. If not, feel free to move on to the next section of the course. Thank you.

• Category: Uncategorized