This brief course provides an overview of the VPC Reachability Analyzer, a service that allows you to easily test the connectivity between two points of your architecture. We'll look at how the service works and its use case. Then you'll watch a brief demo from the AWS platform which shows how to create and analyze a connection and how to troubleshoot when a destination in your architecture is not reachable.
If you have any feedback or questions, feel free to contact us at email@example.com.
Hello and welcome to this Feature Spotlight. My name is Will Meadows and if you give me just a few minutes of your time. We can go over this super excited new tool for your AWS tool box. Today we are gonna to talk about the VPC Reachability Analyzer, a subtle new addition to AWS that I think everybody needs to know about.
This feature is especially helpful if you are new to AWS or cloud computing in general. Previously, when you first started learning and were introduced to cloud networking you had to remember all of the checkboxes that were required in order to get things to work and connect with each other. Checkboxes like having your security groups set up correctly for outbound traffic having an elastic IP address associated with your instances or just a simple as remembering the place an internet gateway in your VPC.
If you were not able to assemble all the pieces in the right order, you would be marooned alone without any idea why your technology isn't working right. You had to spend hours and hours googling answers to find solutions to problems that might not even be the one you are looking for. That was so frustrating and soul-crushing honestly, especially when you are just trying to learn.
I can remember many times where my learning and productivity were halted because of simple connectivity problems that I was unable to diagnose. AWS has recently introduced the VPC Reachability Analyzer, which allows you to easily test the connectivity between two points of your architecture. It does so, by jumping from an initial connection point and iteratively testing the route between that point and a target, each distinct network point along the way will be checked for connectivity from the previous and in the end you will receive a report that describes any issues that it may have found.
For example, if you wanted to test the connectivity between instance A and instance B within the same subnet it would look something like this, it would begin by starting at your designated entry point instance A, then check to see if there is a ENI attached to that instance, then look for outbound traffic on the security group.
After that, it would begin the journey back to the other instance by checking its security group for inbound rules that apply and next the ENI and finally we arrive at the destination instance, instance B. If the instances were in different subnets, it would also check the NACLs in between to see if they have the appropriate rules as well. That's pretty cool honestly.
What's also super cool is that this technology isn't just limited to EC2 instances. No, there is a large array of available connection types and endpoints you can test connectivity with. You can run a reachability analysis between VPN gateways, instances, network interfaces, internet gateways, VPC endpoints, and even VPC peering connections. And with the VPC peering you can test connectivity between instances and points within different VPCs.
You can even check traffic through your transit gateways, which can be difficult to diagnose problems with sometimes, so this is very handy. You can also test connectivity using both TCP traffic and UDP traffic through each of the available endpoints as well.
Optionally, you can tag your analysis to keep track of the cost even though they are pretty minor at 10 cents per run, that might add up if you are constantly retrying the connection. However, if you have a workload that you are particularly worried about you can of course blast away at it at a fairly impressive speed and only run up a moderate bill. Well, I think you get the point here, let's dive into a quick demo of the service so we can see what it is we are actually working with.
All right, go and click VPC. And in here on the left-hand side, you should be able to see the reachability analyzer, go ahead and click on that. And then we can create a path that we can analyze up here with this orange button. So I'm gonna select some instances and we're gonna check the reachability between these two here. So I'm gonna go and pick one. And these are in the same sub-net to make things easy. You of course can switch between different ones. I'm gonna go and click another instance that we're gonna check and overall that looks pretty good.
Of course, if they note that you can set the destination port that you're looking through or the protocol TCP, UDP, but otherwise go and click create. And here we are, it's starting to create the path it's in the pending state. Give it just a moment and we're gonna refresh here and we should be able to see how well the path did. And it looks like it was not reachable. So let's try to figure out what the problem was.
So if you scroll down here it should give us an explanation and says none of the ingress rules in the following security groups apply. So you can see here kind of what it tried to do but that's, that's something we can totally fix. So how about we give it a go. So let's go click on the security group even told us which one wasn't there and lo and behold, there's no inbound rules.
So how about we create an inbound rule to allow traffic? Let's go ahead and do all TCP. I think that will be just fine. And then we're gonna do from anywhere and I think that's probably good that should let in everything. So let's go and save the rule, it's always important to double check the outbound rules as well, so let's give it a click and it looks like everything's good in here.
So how about we go and go back to the reachability analyzer. And again, it's just as simple as going up to services and clicking on VPC and once again, it will be on the left-hand side so let's go ahead and give that a click and all right. So before it was not reachable, let's go up to actions and tell her to re-analyze that path, just confirm it all up and this will cost 10 cents again. So don't just click it all the time. That does eventually cost something and give it just a moment here.
So you can see our previous state was not reachable and now for this new state, if we go ahead and hit the refresh button and we should be pleasantly surprised and there we go, look, it's a reachable now and you can see down here the path that it was successfully able to navigate to check from the source to the destination. That's pretty fantastic again, this used to be a lot more difficult back in the old and wild West days of the cloud.
Well, I hope you enjoyed this Feature Spotlight, I'm Will Meadows and thanks again for taking your time to hang out here with me. I appreciate it, have a good one.
William Meadows is a passionately curious human currently living in the Bay Area in California. His career has included working with lasers, teaching teenagers how to code, and creating classes about cloud technology that are taught all over the world. His dedication to completing goals and helping others is what brings meaning to his life. In his free time, he enjoys reading Reddit, playing video games, and writing books.