AWS Networking Fundamentals

thank you very much for coming my name is Perry Wald this is my colleague Tom Adamski we are solutions architects in AWS we've come here today to talk to you about network fundamentals now this is a level 200 session so just a little bit of a level set here we're talking about a basic level of networking we're looking at talking about networking from IP networks addresses routing how to build a V PC if you are familiar with networking but have never used AWS or familiar with AWS but never done networking in AWS this is the level you want if you've already done a lot of deployment inside AWS then this is probably a little bit basic for you so let's get started there's the internet and there's AWS and people tend to use AWS as if it were a kind of data center a virtual data center as a result they deploy things into that data the same kind of stuff as you deploy into your data center on-premise they might be easy to instances that hosts they might be data bases they might be EMR clusters that analytics clusters those things need to live somewhere in a data center and they typically need to talk to the internet so for that we have something called a V PC now when you have gettin accounts you get a default V PC and that default view PC gives you a lot of the things that you need to build your networking in AWS it gives you I P ranges something called a cider range we're going to talk about that it gives you subnets and availability zones for resilience we'll touch on that it gives you rooters to be able to route out to the internet because that's quite useful and it gives you things like security groups and network access lists so I'm going to refer to them as knackles to be able to provide security now the default V PC is a good starting place for when you start with AWS but what we're going to spend the first 15-20 minutes talking about is how you build all those components in the V PC yourself and we're going to hand over to Tom to talk about some of the more complex components that come up with networking so with that in mind I'm going to talk about IP addressing I'm going to talk about creating subnets routing and putting some security around it let's start with IP addressing so this address 170 to 3100 slash 16 this is what you start with in your network in your default V PC and let's just look at that a second that's a useful address I didn't just randomly choose that it splits into two halves one 7231 describes the network half and 0.0 describes the host the actual system on the network once 1731 comes from a range called the RFC 1918 range I'm going to pass over a lot of these things I'm not going to go into too much detail but these are all available to look on the Internet the RFC 1918 range doesn't exist anywhere on the internet it's a private IP range which means that if you use it in your V PC you're not going to conflict with anything on the internet and that's quite important because if you conflict with something on the internet you can't talk to that thing no conflicting is also important on premise so if you're connecting your on premise you're connecting to other V pcs with in AWS then you need to not be using the same address everywhere you need to be using a different set of Sider ranges for each V PC so that you don't overlap and that's going to be quite important because overlapping addresses can't talk to each other easily so just to touch on that slush 16 that / 16 really means 65 thousand odd addresses that's a great place to start lots of space for you to expand and grow what you're running in AWS but if you run within a business that has a networking department it's quite normal that they may ask you to use a smaller range so when choosing the range when choosing the size of the network have a think about how big how many systems you're going to run in that environment and choose the the subnet accordingly so that was a side arranged that's a range of addresses you're going to use inside the network but what do you do with those well let's start again with that VP see that virtual data center as I've talked about it in the cloud that has the side arranged and we want to break that up into availability zones now an availability zone in this case I've highlighted dublin's 3 availability zones availability zones are separate risk domains each of them are one or more data centers those data centers are on different power grids they have different flood profiles we do this so that if something were to affect an availability zone it wouldn't affect multiple availability zones that's really good for resilience but in those availability zones you need to put subnets so that you can talk one to another the subnets in this case are subdivisions of that side arranged in this case one 70/30 1.0.1 and dot-to-dot something / 24 in this case I'm using the first three numbers of the IP address to denote the actual network and I'm using the last number to denote the machine and in this case each subnet can contain about 250 addresses now I mentioned all of these IP things and these are all ipv4 I'm going to brush fairly quickly over ipv6 but basically we're running out of addresses so ipv6 came along which has many more addresses it comes from something it comes from a group big enough for everyone to have a unique address but those addresses don't exist on their own in AWS we run something called a dual stack which means those addresses are overlaid on top of the same instances that your ipv4 addresses are so if you start to use ipv6 every network and every instance will have both an ipv4 and an ipv6 address great so that's a lot about addressing but now we're going to talk about talking between addresses none of this is about security yet that will come later to talk between addresses we need to be able to route and the routing or a route table is a set of rules that tells the system's tells us how to move packets around where to put the next packet now every default VPC has a default route table and that default route table simply says everything in my side arrange is inside my V PC but you can assign different route tables to different subnets and we're going to look at how to do that in a minute but before we do that let's just have a look at where you configure route tables on bbc's you go to the route table tag and you hit my clicker is not working you hit the route table tab and you will get a routes table and as it shows up there 1 7 to 3100 slash 16 is local that means anything in my side arranged in any of the AZ's will talk to one another but what about the internet we said right at the beginning of this that it's really useful to talk to the Internet so the easiest way to work through this is to do some examples we start with your virtual data center your V PC and the internet now there are three things that you need in order to communicate with the Internet you need to have some form of connection to the Internet you need to have a route to the internet and you need to have a public address and if you recall I said that 11731 was a private address it doesn't exist on the Internet so in this case we created a subnet inside that V PC and we say that that subnet is a public subnet now public subnet merely means when I launch an instance that instance as well as getting its private IP address it gets a public IP address in this case 198.50 m dot something now that's great that deals with number one and public IP address number two I need a connection to the Internet so what I do is I create an IG W an Internet gateway and I connect that to my V PC now I have a connection that's two out of three not bad the third thing I need is it route and in this case the 0 0 0 / 0 that means default route that is telling anything in my subnet that the default way of getting out of the subnet the way to get out to any address that isn't inside the subnet is via the igw now that creates something called both inbound and outbound internet access what I've done is I've created a construct where my 198.50 on address can talk to anything on the Internet and anything on the Internet can talk to that one 9 851 address we will put security in later on in this case it's a very typical setup for a web server but another common setup that people want to use is if I want to go out to the internet maybe for a patch update maybe for an API call but I don't want the Internet to get back to my systems by default well in that case I create another subnet but I denote this one as a private subnet not a public subnet private subnet just means stick with the private range don't give me a public address as well well that means I need something to give me access to the Internet and in this case the thing that gives me access to the Internet is a service called in that gateway that Gateway is a one-way valve it allows it allows systems inside AWS inside your V PC to get out to the internet but it only allows responses to requests that have come from inside if a request comes from the internet and tries to get through the NAT gateway it will get rejected the NAT gateway is a one-way valve that only allows responses to requests from inside and in this case I add a default route zero zero zero but I points it towards mine at Gateway I don't point it towards my internet gateway this creates something called outbound internet access systems can get out hosts instances can get out to the internet but the Internet can only respond to requests now so far in a very short space of time we've talked about IP addresses we've talked about routing and we've talked about internet and that gateways but we haven't talked about security so we're going to talk about security next and I'm going to cover three items I'm going to cover security groups network access control lists knackles and I'm going to cover flow logs so let's start pardon me let's start with security groups now security groups are AWS is distributed firewall and the most important thing to know about a distributed firewall or in fact most firewalls is that they are what's called States full that means that a request that comes from one direction automatically sets up permissions for the response to that request from the other direction and that saves you a lot of trouble because it saves you having to set up a set of rules for inbound and outbound access so let's just look at what firewalls do what security groups do we'll start with of a PC and we'll start with seven six seven instances inside that VP say I'm going to choose that four of those instances our web servers and stuff on the internet wants to talk to those web servers and three of those instances are back-end servers and the web servers want to talk to the back-end servers so let's put them in some logical groups in this case I'm going to put them in on my web servers group that's the top one and I'm going to put them in in my backends group that's the bottom one now let's lay some rules over these for the my web servers group I want a rule that says allow web traffic from anywhere that's sort of a sensible thing for a web server but for the back-end group I want a rule that says only allow communication from my web servers I don't want anything else to talk to those back-end servers that's security groups let's look at how you configure them well you go into security groups on the V PC environment and you create them and in this case I created an inbound rule that says port 80 HTTP web traffic is allowed from anywhere and I've assigned that to the my web servers group so the my backends group I have a rule that says traffic is allowed from the my web servers group and in fact if you look I don't give IP addresses I give a specific security group ID and that ID matches the ID of the my web servers group this is a really important feature of security groups especially when you start scaling servers up and down you don't have to worry about IP addresses of the servers if the server's live in the security group then you refer to the security group and that is the decision that we make about firewalling now that didn't move forwards now I've talked about security groups and I'm going to touch on knackles why I say I'm going to touch on that cause it's because really what I want to do is I want to highlight the difference between a security group and the knuckle security groups estate 'fl and they're really firewalls knackles are just network control lists they really should be used only for very coarse-grained decisions like I don't want any traffic from that network or I only want to allow traffic from this particular IP range and most importantly they're stateless just because you've allowed traffic in one direction doesn't mean that the traffic in the other direction is permitted in fact if you don't explicitly allow things in both directions you're going to start getting into difficulties knackles should be relatively short if you start finding that you've built knackles with long complex sets of rules around ports and IP addresses you've probably started configuring security groups instead but we're using knackles so please PLEASE knackles are coarse-grained controls and they only work around the edges of networks now we've talked about the tools for creating security for controlling flow of data but we haven't talked about how you look at it and that's flow logs flow logs work at a VPC level at a subnet level or at an instance level I can inspect any of those three items or all of them and I write my output to either an s3 bucket or a cloud watch log it's really useful for providing visibility into what's going on on my network troubleshooting if I've set up the wrong rule or analyzing traffic flows and I stress analyzing traffic flows because flow logs did not contain the payloads data of your packets they only can't contain the description about the packets the addressing etc the metadata and we're going to look at that in a minute but just before we look at that let's look at how we configure them we go to a VPC we click on the flow logs tab we create a flow log and we say whether the destination is s3 or cloud watch it really is that simple now what does a flow log look like well for anybody who's ever done network troubleshooting its page of numbers but what I'm going to do is I'm going to dive down into one of those and we're just going to translate it into English now I have blurred out a section because that came from my account every flow log also contains the account that the traffic was seen on and that's quite useful if you've got many accounts in this case the flow log tells me the network interface that the data was seen on the source IP address and the source port this is a public IP address in this case and it's coming from a high number port so I know that this is from public address 210 blah blah blah it has the destination IP address and port in this case the destination IP address is inside my V PC and it's port 22 which is SSH it has the number of bytes that was and it tells me whether that was an acceptor or eject now that gives me almost my entire sentence but I have to work one bit out I work out that if it's destined for SSH inside my V PC then this was inbound data from the public internet to SSH that's really useful if I'm not working I can put a flow log on and see why traffic is being blocked now I very very quickly talked about all of the components that go into building a default V PC and I'd strongly encourage you to play with a default V PC but then to set this up yourself because when you set it up yourself you get to choose what all of the variables should be I haven't mentioned DNS and in the last minute I have I'm going to mention DNS inside AWS we provide you with DNS services as well those services are switched on by default although you can switch them off and they provides two things they provide DNS resolution so that your instances inside a V PC can resolve public addresses and addresses of other things in the VPC and they also include the ability for us to assign DNS names to the instances so you don't have to just use IP addresses now that's really worth considering and looking at but I'm not going to go into more detail here I'm just going to say that if you're interested in DNS and not having to manage all of your own DNS it's worth considering looking at route 53 with that I'd like to pass over to Tom who's going to talk about some of the higher level services Thank you very everyone all right so Perry has taken you through setting up your first V PC connecting it to the Internet and securing it and I'm going to go through how you can connect multiple V pcs on AWS and how can you connect your V pcs back to your on-premise environment so we'll start off with the options we have to connect V pcs in your AWS environment in the cloud and we'll look at two options we look at V PC peering and we look at transit gateway well let's start with V PC peering so parry earlier I compared the V PC to the equivalent of your data center on-premise but running in the cloud so V PC peering in that context would be like a piece of fiber or like a leased line between those data centers so if you have two V pcs you want to connect you can establish the peering between them and I can start communicating with each other if you have another V PC that you need to connect with other environments you can create another peering and now the BBC in the middle can talk with both HV pcs however one thing to remember here is V PC peering is a one to one relationship so you can't have this path happening you can't have you can't have traffic traversing a V PC to get to another V PC so if you have a requirement for those edge v pcs to be able to talk to one another you'll need to set up your own DPC peering here and establish a connection between them so let's add a 4 V PC to the mix and if we want to have any to any communication we'll need to add additional pairings in here to have to have that happen so all of the communication is happening privately and the V pcs you're connecting of appearing can be in different accounts and it can even be in different AWS regions so you can connect the V PC in Ireland with a V PC in u.s. finally when you're connecting DPC's to each other appearing you need to make sure that you don't overlap any of the cider ranges you decided to use for your V pcs from a setup point of view establishing a V PC connection is very much a decentralized process so the owner of each V PC is making a decision to establish that pairing with the owner of the other V PC so in this case the owner of the V PC on the on the left he's going to send a peering request to the owner of the VP on the right and then the owner on the VP of the right will accept that request and the peering is established very simple the final step is to update the routing tables on each side to make sure the traffic can flow so if we zoom in to the VP see on the left we now see an additional routing entry in the routing table that's telling us how to reach the IP address range of the VP C on the right and the destination is going to be the peering connection we've just created so last year we've announced the availability of another option for connecting your VP C's together and that's the transit gateway so if we go back to the world before the trans gateway we can see our peering mesh again and it's fine if you have just a few VP C's but once you start getting into tens 12 13 20 V pcs they need to connect to each other it's becoming very complicated to manage plus you will likely hit the limit of the VP see peering savvy PC can have that's 125 so how does trans gateway help us so trans gateway is a distributed managed routing service that you deploy into a region and you can connect and attach VP C's in that same region to your trans the Gateway and then allow for any to any communication from a routing point of view or you can isolate some VP C's to allow them only to talk to each other so if we now add some routing information here and we assume that all our VP C's are in the 1 7 - 1 7 to 16 block how is that how is that routing gonna look like inside our VP C so if we zoom into that routing table we now see a different entry that's pointing to any addresses in the 170 block and saying that those addresses on a reachable via the trans the Gateway so rather than having a single entry per peering like we had before we can now have a single entry sending all the traffic to the trans gateway and then the trans gateway actually has its own routing table with specific information about every single attachment it has including the V PC that was sending traffic from so communication similar to appearing is happening completely privately your transit gateway annual V pcs can be in different AWS accounts however the transit gateway and the bbc's have to be in the same region we've announced end of last year that we are planning for this year to make connectivity between trans gateways in different regions available but that's coming ok so if you're comparing the two and making a decision which one - which one to pick which technology to pick V PC peering or transit gateway here's some ideas you can look at some comparison numbers that you can look to look at but at the in the end is going to come down to the number of connections you can have and how easy it is to manage that environment so if you're configuring all that more than 2012 10 15 V pcs transit gateway is probably something you want to look at okay so we've connected our V pcs on AWS let's start connecting them back to on-premise so we'll go through scenario where we have on-premise environment on the left and we will have our V PC on the right and we'll look at two connectivity options we have AWS site-to-site VPN that's effectively an IPSec VPN tunnel typically running over the internet connecting your V PC to on-premise and the other option is AWS Direct Connect that's a dedicated physical connectivity into the AWS backbone so VPN is often the starting point for many customers it's an easy thing to set up and you can do it you can do it with not a lot of effort so to set up your first ven first of all you need to define the customer gateway and this is going to be the the on-premise end of your VPN connection and this is this could be your router your firewall anything you manage on-premise that supports IPSec on the V PC side you'll create another gateway virtual private gateway that you associate to your V PC and that will be the other side of your VPN connection so once you have those two endpoints you can create your first tunnel you can create your first connection and each VPN connection actually consists out of two separate IPSec tunnels and the reason why these two separate tunnels is because we give you two separate VPN termination endpoints in different availability zones for high availability finally if you're not using a route dynamic routing protocol like BGP for example you would have to update the routing table inside of EPC to tell it how to reach the on-premise range so VPN is great but because it often runs over the internet you might sometimes have some unpredictable experience so if you want more predictable and consistent experience for your connectivity to AWS that's what you would look at AWS direct connect and here first of all we're going to zoom out a little bit from a V PC and look at the larger AWS cloud and then inside we have a V PC we created earlier but outside of those V PC that private environment we have other services these services are managed services that live on the AWS public address space these are things like s3 dynamodb cloud watch for monitoring all those services are outside of your V PC and now we want to use Direct Connect to connect from our on premise environment both to a private V PC but also to some of those services that are on the public address space to do that we would use one of our Direct Connect locations these are locations that we publish on our website you can pick the location that's closest to where your date Center is and in each one of those locations AWS will have a number of my of Reuters that we manage and then you request a port on one of those routers maybe one gig or ten gigabit two seconds and then you can establish physical connectivity to that port either yourself or with the help of an AWS connectivity partner so this is just your physical connection on top of that you now need to start creating your logical connectivity so your virtual interfaces or VLANs on your side so first you can create a private virtual interface that is an interface that gets you connectivity into your private environment into the V PC and for connectivity to outside of that VPC to the public address publicly addressed services you could use the public virtual interface now if you're connecting to more than just a single V PC and you want to use a single logical connection for that you can use AWS direct connect gateway the in that case you would create a single logical virtual interface terminated on the direct connect gateway that then can connect to up to 10 V pcs that live in the same region or in different regions across the world except for China okay so if we now start connecting multiple V pcs and we look at the time before we had trans gateway available if we're connecting our V pcs back to on-premise using AWS site-to-site VPN we would have to create a VPN V PC so each V PC would have its own VPN connection if we had 100 V pcs that means hundred VPN connections actually 200 because there's 200 tunnels if we're connecting back to a thermos using Direct Connect but in that case we could leverage the REC in a gateway and maybe have that single logical interface connecting to up to 10 V PC which runs the Gateway we already know that transfer gateway can help us aggregate the connectivity in a certain region and we can connect up to 5,000 V pcs to a single transit gateway but now it can also help us consolidate that connectivity back to on-premise so instead of setting up a VPN tunnel to every single V PC we can now have a single tunnel going through the trans the Gateway and from there we can reach all the V pcs attached to it we're using Direct Connect and this is currently only available in u.s. we could use Direct Connect gateway to connect a single logical interface to the direct connect gateway and effectively to the trans the Gateway to reach all the bbc's now from a routing point of view it's still very simple so all you need to do is now add an additional entry to tell the V PC how to get to the on-premise address range and you just point it through the trans of Gateway and the transit gateway is going to have its own entry for the connectivity box on premise in this example we're using a VPN but it could be direct connect so we've created a hybrid environment we now have on-premise environment connected to AWS but what about DNS so typically customers would have private domains private zones deployed on-premise as well as only WS and they want to be able to resolve them no matter where they are so for that we have route 53 resolver service that allows you to create resolver endpoints in one of the V PC is connected to on-premise two to be used for dns forwarding so you can do that resolution from on-premise to AWS and vice versa then you can even create your own forwarding rules to specify which domains should stay on AWS and be resolved on AWS and which ones should be forwarded back to your own premise service ok so it's been quite a busy year for networking and we still have quite a few services to go through so I'm going to touch on VPC sharing I'm going to talk about VPC endpoints and finally about Amazon global accelerator so let's start with VPC sharing and VPC sharing is changing the model of how you organize your V pcs so before V PC sharing when you created a V PC had to belong to an AWS account which is a management boundary and all the services you would deploy it into that V PC would have to belong to the same account with V PC sharing we're changing that model so you now have the concept of the owner account and maybe this is an AWS account owned by our networking team or your infrastructure team and they would build all the networking constructs they would create the V PC create the side on the side arrange create the subnets set up all the routing network access control lists set up all the route tables and connectivity to other environments exactly the same way as you would with a regular V PC but it's controlled by that networking or infrastructure team the big difference here is those subnets inside of e PC can be shared with other AWS accounts so maybe now web development team has their own AWS accounts and they can deploy resources ec2 instances for example into a subnets that's been shared with them and they have full control over that resource and they can create security groups around their own resource but they can not make any changes to the resources that were created by the owner of the V PC so for example they can make updates to the routing table or change network access controllers and you can share those subnets with multiple accounts so maybe the nava account is maintaining a database and they're creating an RDS service that you put it in another subnet and maybe there's some application teams that are building their applications deploying them into those subnets none of those teams can touch each other's resources they always manage their own resources but from a networking point of view if they open up the security groups they can now communicate with each other so why would you the PC sharing so first of all you can save on your ipv4 addresses if you're running out of ipv4 addresses and you can create one bigger V PC and put more resources into it you're going to utilize your addresses more efficiently and if you have less B pcs it actually means less interconnectivity you won't have to create as many parents or trans the Gateway connections or connections back to on-premise and you have that nice separation of duties where the owner creates the vbc and participants cannot change it they can't accidentally on purpose add an Internet gateway to establish internet connectivity for example and finally everyone is still built for the resources they create so and if it so happens that the resources live in the same availability zone than the traffic within the same availability zones free of charge okay so I mentioned earlier that we have these services that live outside of the outside of your V PC on the public eight of this address space and we know now that we can use Direct Connect the public virtual interface to access those resources from on-premise but what about accessing them from within your V PC you can do that for an Internet gateway but maybe you don't want to deploy an Internet gateway to your V PC so for that we have different types of endpoints and we'll start we'll start off with gateway endpoints and these endpoints are used purely for s3 and dynamic DynamoDB only for those two services so here we have an example of a V PC communicating with an s3 bucket using the internet gateway well in our scenario we don't want to use an Internet gateway we don't want to use any public IP addresses but we still want to be able to reach us free we can establish a VPC gateway endpoints to s3 and then navigate all the traffic for an update in the routing table through that endpoint to privately communicate with us free without any usage of public IP addresses another type of endpoint we have our interface endpoints and these endpoints are now used by all the other services that are becoming available inside your V PC so an example here is AWS services API so if you want to connect to that service you can use an interface endpoint and instead of doing any routing we will make it look as if that serve this lives inside of your V PC and it will use IP addresses from within your V PC range so when your ec2 instances are connecting to that service that would be connecting to a local IP address and behind the scenes privately transported to the actual service they want to communicate with so this mechanism allows you to also override the publicly public domain name for the service so only inside your V PC it will resolve to your private IP addresses and a lot of customers and partners are using this for sharing their services themselves so you can do it yourself as well and the technology powering V PC endpoints V PC interface endpoints is private link so we allow you to use their technology of self to share your own services with thousands of other VP C's so in this example we have a service maybe this is a HTTP service and you want to share that service with a lot of other bbc's maybe some third parties so you need to put it behind a network load balancer and then make it available as an endpoint service so that other VP C's can subscribe to that service and create endpoints representing your service in their VP C's so again that will be connecting to a local IP address representing your service and be transported to your service hosted in another vbc and using private link allows us to only expose a specific service port that we're connecting to so if it's HTTP it will be just 443 connectivity is only allowed in one direction so only consumers can connect to the service the service provider VPC cannot connect to the consumer of the pcs and finally in this scenario you no longer need to care about IP addresses anymore so those IP addresses in the VP C's can overlap and you can still expose the service this way ok finally a service that's focusing on something slightly different so now we have an application on AWS that's already publicly facing maybe in a region in Europe and we have users from outside of that environment that want to connect publicly to our application and we want to make sure that the experience for those users is as good as possible so Amazon global accelerator is a network based service that you deploy between your users on the internet and the application that's internet-facing hosted on AWS that allows you to optimize the experience for those users and it can cover any type of application running on TCP or UDP why does it matter so if we have a application that's facing the Internet today and we have users connecting from all around the world they'll be traversing a lot of different networks their ISP and some other carriers and there's a potential for these paths to be impacted by some let's call them internet webicon so you don't control the end-to-end experience of that user when you deploy a global accelerator you're able to bring the traffic from your users on to the AWS backbone as close as possible to where your remote users are and then from there the traffic will use the uncongested managed AWS backbone to the actual service running in an AWS region okay so we've covered quite a lot we started with creating a V PC and this could be a regular V PC or a shared V PC we talked about how you can deploy endpoints to communicate with other services AWS services as well as your own services we talked about how you can connect your V PC to the internet it may be optimized that experience using global accelerator we talked about the different types of subnets private subnet public subnet in using nap gateway for allowing outdoor access and we talked about the different connectivity options so connecting back to on-premise using Direct Connect or AWS site-to-site VPN or connecting to other V pcs where they're using peering or using trans gateway so that's a lot to cover a lot that we covered so if you have any questions Perri and I will stay after the session we also can come over and chat with us at the iaws village where we have a networking stand so if you have any networking questions you can come over and chat with us yeah and please make sure thank you and please make sure you fill out the survey and remember the exits are behind me [Applause]

Channel: Amazon Web Services

Views: 335,010

Keywords: AWS, Amazon Web Services, Cloud, cloud computing, AWS Cloud, AWS Summit

Id: hiKPPy584Mg

Length: 40min 8sec (2408 seconds)

Published: Mon Jun 03 2019