Amazon AWS Certified Advanced Networking Specialty – Networking & AWS Primer Part 9

25. Understanding Route53 Outbound Endpoints

Hey everyone and welcome back. In today’s video we’ll be discussing about the Route 53 outbound endpoints. Now, one thing that you should remember that Route 53 solely cannot send the queries to a customer managed authorized DNS servers which is hosted on premise or within the VPC. So this can be better understood with a diagram over here where let’s say you have a group of EC to instance, and this EC to instance sends a query asking for the a record for the domain of on premise internal. Now, Route 53 basically says that all right, I do not really have that record in my hosted zone, nor can I forward it to the other DNS. So it might happen that there is one more DNS which has this record.

So we cannot configure Route 53 to automatically forward the request of the domain which is not in its hosted zone to an external DNS server. And this is the reason why if you have a set up similar to what we were discussing, the architecture looks something similar to this, where within your etc resolve corner, you will have the DNS entries belonging to two servers. One would be the . 2 server, which is the Route 53 DNS, and second would be the custom DNS server.

So if on premise that internal is not resolvable by Route 53, the request goes to the second server, which is your custom DNS server. Now that custom DNS server, it necessarily does not really need to be within your VPC, it can even be in your on premise. But you need to have some kind of a VPN or some kind of a direct connect so that the easy to instance will be able to send the request to the DNS server which is external. So now what Route 53 outbound endpoints allows us to do is it allows us to set only one DNS entry within the resolve conve.

So how it works is now the EC to instance sends the data to Route 53 DNS, saying that I need to have the a record for on premise internal. So now we make use of Route 53 endpoint. So this Route 53 endpoint can be configured to forward the request to the external DNS server. So here it says that all the requests for domain internal should be forwarded to a specific IP address. So this IP address can belong to your on premise DNS server.

So when you send a request to Route 53 DNS and there is an outbound endpoint associated with it, then your request, depending upon the configuration of your outbound endpoint, it will be forwarded to your on premise DNS or any other DNS that you might have within your organization. So let me quickly show you a demo because that will really help us understand in a quicker way. So I’m in my Route 53 console and here you see I only have two zones. One is of Local and second is of Kplabs internal. So basically in one of the VPC that I have, if I quickly do an Nslookup on host one, NYC three example, you see I am able to resolve it and the resolver is 172, 310 two.

So basically this is the IP address of the route 53. Now, if you can directly query there, you see it is getting perfectly resolved. However, if you see over here there is no zone of example. Now, what exactly is happening here is that I have an outbound endpoint which is created. So this is the outbound endpoint. Now let me open this up. Now there are two IP addresses which are associated with the outbound endpoint and there is one rule which is configured here and the type is forward. So let me quickly open up the rule here. So what this rule says if you see the rule is outbound hyphen example and it says that for any query which the route 53 receives for the domain of example, it should forward those queries to an IP address which is 107, 23191, 187. So this is very similar to the architecture that we were discussing. So any query which the route 53 receives and the query domain is example, then it will be forwarded to your custom DNS server. And this is the IP address of the DNS server. Now, if you look here, it’s 91 dot 187 and this is our DNS server, this is 91 dot 187. So within the DNS server, let me quickly show you. If I go to bind and I go to zones, I have one zone of DB, NYC three. And within this zone I have an entry over here which is host one, dot NYC three, dot example. com, and the value is ten dot 128 dot 100 dot 10 one. Now, if you quickly remember, let me quickly run the NS, lookup again, you see it is ten, 128, 1010 one. So what is happening here is that we have an outbound endpoint over here. This outbound endpoint has a rule that we were discussing.

So this is the rule and this rule states that any request which route 53 receives, for example, it should be forwarded to this specific IP address. So this IP address is basically the custom DNS server. Now this custom DNS server will resolve that entry and the data would be forwarded back to the client. So this is of type forward. So if I can quickly go to the outbound endpoint, all it is doing is that it is forwarding that request. You see, it is forwarding that request to the specific target IP address that we have been defining. So now what we do not have to do is we do not have to set custom DNS servers within the etc resolve conf. And this type of architecture is quite simple because here you can have multiple conditions. So for example. com domain you can forward the request to this specific rule if it is some different domain, then you can forward it to a different DNS server altogether. So now you don’t really have to hardcore all the DNS server within your result con.

All you have to put is you need to have the zero two address which comes by default within the easy two instances and that’s about it. So this is a great way of configuring things. I hope you understood at a high level overview about what Route 53 outbound endpoints are all about. Now, one difference when you compare it with the inbound endpoints, if you remember in inbound endpoints we use to forward the request to the IP address of the end point. All right? However, in outbound endpoint we cannot forward it to the IP address of the outbound endpoint. This is very important to remember. The request should be forwarded to the zero dot two address only. All right? So basically here I have the subnet of 172 310 dot two as the DNS, so the subnet is 172 310 00:16. So the zero two becomes the DNS. So all the query should be forwarded to the zero two year.

You cannot forward it to the IP address of the outbound endpoint. However, if you talk about inbound endpoint, we have to forward it to the inbound endpoints directly. Now, this type of architecture of outbound endpoints is typically used by the EC to instance within your VPC which wants to maybe connect to the on premise DNS servers or certain custom DNS servers. Now, when you talk about inbound endpoints, then the inbound endpoints are typically used by the servers which are residing in on premise to know the IP address associated with the DNS, which is typically maybe your Route 53 private hosted zones or ELB DNS, et cetera. All right? So again, outbound endpoints are typically used by the EC. Two instances within your VPC and inbound endpoints are typically used by the DNS server or by the servers within your on premise. So I hope at the high level overview you understood what the outbound endpoints are all about. I hope this video has been formed for you and I look forward to see you in the next video.

26. Creating first Route53 Outbound Endpoint

Hey everyone and welcome back. Now in the earlier video of route 53 outbound endpoints we had a high level overview on what outbound endpoints are all about. So in today’s video we’ll implement the outbound endpoints and we’ll look into what are the steps and configuration which are needed for that to happen. Now before we go ahead and configure the outbound endpoints you should have the DL server up and running. I hope you remember that during the video of inbound endpoints we had configured the bind DNS server and that DNS server was responding perfectly. So in today’s video what I have done is I have created certain local zones within the bind. If I can quickly show you within etc bind if I go to zone and within here I have created the zone of example. So it basically has two entries here primarily that we’ll be using for testing. One is host one NYC three dot example and second is host two NYC three example. So these entries are resolvable by the bind server that we have created. All right, so if you quickly want to check so let me quickly open up the file and I’ll copy one of the entries over here and let’s quickly do an S lookup of that entry 212701.

All right. And if you see from the local DNS server this entry is perfectly resolvable. That means my bind server which is running over here, it is able to resolve this entry. Now in case if you want to replicate this kind of a setup, there are two configurations that you need to put. First is you will have to edit this file which is named convey local. So if I can quickly show you so within named conve local by default you will not have anything here. So you will have to add these two entries which basically here we are specifying the file path also. So the file path is etc bind zones and within zones there is a DB NYC three example and same for the other one where you have a file of etc bind zones DB 1028. So you need to copy this up again, I’ll be providing all of these configuration after this video so you can replicate it. So the first thing, just copy this specific file within named convey local and once you have done that create a new directory called as zones.

And within this directory you need to basically create two files. I’ll be providing these two files so you can directly copy those files within this directory and make sure you have the proper permissions which is bind and bind for the files that you copy. All right, these are the only things that you need to do and definitely after this go ahead and check the configuration with named hyphen checkcons and restart your bind server. So now we know that whatever bind server that we have currently present this bind server responds to the example. com domain however, from the EC two instances. So, looking into our architecture from the EC to instances, basically this EC two instances are configured to send the query to the dot two address of Route 53. Now, since there is no example. com zone within the Route 53, these easy to instances will not be able to get the response back. So let’s try it out. If I quickly do a Nslookup, in fact, let’s use the earlier one and this time I’ll direct it to 172, 310 two.

All right, you see, it says that the server can’t find host one dot NYC three dot example. com. So now we are in a similar architecture because we have one DNS server. This DNS server is our bind server. Now, what we want is that when the easy two instances sends the request to Route 53, and if Route 53 does not have the response of the request that it sends, then it should forward it to the custom DNS server. Now, by default, Route 53 cannot do that. We need to make use of the Route 53 outbound endpoints. So let’s go back to the Route 53 console and within the outbound endpoints, we’ll go ahead and create an outbound endpoint over here. So I’ll call it as my outbound endpoint. Now, within the VPC, I’ll associate with the VPC where our EC two instance is and the security group I’ll use the default security group. Now, IP address will just use the default IP address and we’ll click on Submit. Oops, we forgot to choose the Availability Zone. Same here. We’ll be adding it into different Availability Zone. And once you click on Submit, your outbound endpoint status is creating. So let’s quickly wait for a moment here. Great. So it has been around two minutes and our outbound endpoint status has changed from creating to operational. Now, if I click on the outbound endpoint over here below, there is an option for rules. So let’s go ahead and create a new rule. So I’ll call it as my outbound hyphen rule. Now, the rule type here would be Forward. That basically means that if the Route 53 receives a specific request for say, example, then it should forward that request. All right? So here you can specify the domain. In my case, it is Example. So I’ll put it as example here. Now, the VPC that basically uses the rule is the one where our EC two instances would be present. And the target IP address here will basically specify the IP address of my DNS server. All right? So this is the DNS server. So if Route 53 receives the request for example, then it should forward it to the custom DNS server.

And our IP address for a custom DNS server is 107, 23191, 187. So I’ll copy it up here. Port remains 53 and we can go ahead and click on Submit. Great. So our rule is created now. So once the rule is created, you can run the Nslookup command here and basically now after you run the Nslookup command you see that it is able to resolve the domain. Now here the resolver is 172 310 two. So this is basically the route 53 address. So this basically means that our outbound rule is configured successfully. Now one important difference to note is that when you configure inbound endpoint then the request should always be directed towards the IP address of the inbound endpoint.

However for the outbound endpoint you should not direct the request to the IP address of the outbound endpoint. The request should always go to the route 53 which is in my case 172 310 two. Again this address will change depending upon your VPC. So what I’ll do is, at the end of this video, I’ll basically take a zip file of my entire directory over here, and I’ll upload it after this video so that you can copy the named convey local. You can even copy the zones directory and in case if you are doing the inbound endpoints practical you can directly copy the namely convey options so it becomes easier for you to replicate it. So this is the high level overview about the route 53 outbound endpoints. I hope this video has been informative for you and I look forward to see you in the next video.

27. AppStream 2.0

Hey everyone and welcome back. In today’s video we’ll be discussing about the App Stream 20. Now, App Stream 20 basically allows us to centrally manage our desktop application and securely deliver them to any computer. So this can be understood in a better way with a simple use case. So the use case is related to software vendor. So you have a software vendor who can use use the App Stream 2. 0 service to deliver the trials as well as demos and trainings for their application with no downloads or installations. And this is very important. Let’s say that you are in a meeting and a specific software vendor wants to give you a demo and even you want to explore on how exactly that application might look like. And that application works only on Windows and you are running Mac currently. So you cannot really run that application within your Mac. So you have to do some kind of a virtualization or something similar. So App Stream 2. 0 really solves that use case in a very simple way where you can actually use that application from your browser. So let’s jump directly into the demo and look into how exactly this would look like.

So I’m in my App Stream 2. 0 console and let’s click on Try it now. So the first time you will have to accept the terms and conditions. So just click on Agree and continue. So here you see there are many applications over here. So you have Eclipse, eclipse, many of you might have used it, you have a Firefox browser, you have a free cat, et cetera, et cetera. And even if you have some custom application which is running in your Windows, and you want it in such a way that it should be able to be accessible via browser, so the user can use it, so you can basically use the App Stream 2. 0 service. Let’s look into eclipse. So I’ll just click on the Eclipse here. So currently you see the Eclipse IDE is loading. So this is very similar. Like when you double click on Eclipse in Windows, you will have something quite similar. So I’ll just click on Allow over here and I’ll maximize it. So this is the eclipse ID. Now, you can do everything that you can typically do when the Eclipse is installed.

So in the software vendor example that we were discussing, instead of them giving the demo, what they can do is they can put their application to App Stream and all the users, they can connect to the application from their individual browser and they will be able to use it similar to how they might be doing when they are installing the application. So let’s say if I just click on create a new Java project, everything remains the same. So I hope you understood at a high level overview about what App Stream service is. So again, if you have an application in Windows, you can put it to app Stream 2. 01 great thing about this is that you do not really have to manage the back end service that is done by App Stream. Now along with that do remember that in exams you might get a use case where an organization wants to stream their application so that it gets accessible from browser. So for such kind of use cases App Stream 2. 0 is something that you should answer straight away. Again you will not be asked technically on how exactly you can put the application but you should be aware about the use cases where App Stream 2. 0 hit.

• Category: Uncategorized