A developer’s guide to cloud networking

My name is Dewan Lightfoot. I am a Developer Advocate here at AWS, focus on cloud networking. The title of this session is A Developer's Guide to Cloud Networking.

Now, I understand we all come from different backgrounds. I myself, I'm a network engineer. So if you start talking network to me, as far as IP addressing routing security, VPCs I understand that. But as a developer, you just wanna develop your applications and they kinda work, right? You don't really want the network to get in your way.

So my goal in this talk, whether you're a developer, you're an engineer or you're an architect is to just simplify things and talk about cloud networking on AWS.

So let's kinda get started. This is a 200 level session. So what does that mean? We expect you to have some fundamental knowledge of networking concepts like IP addressing CIDR notation and security. This is also an interactive session. So I have polls, a couple polls throughout this session where you can kinda join in, answer the questions and we can see how we all can interact and engage and you know, talk about some of the things we are experiencing in our infrastructures.

Now, today's session, we're gonna begin with discussing the AWS global infrastructure. Then we'll move on and talk about some of the Amazon VPC and security basics. Then we'll talk about connecting to your VPCs and your resources in your VPCs. And then after that, we'll talk about hybrid connectivity. Like how do we connect from our data centers to AWS? And then finally is how do we get visibility into our networks in AWS?

So for our first poll today, the question is you could pull out your phone, scan the QR code and if everyone can do that, that'd be great. The question is, what percentage of your day on average is spent troubleshooting the network? Now, if you're a network engineer, of course, this is probably all day or you're architecting or something. But if you're a developer, chances are you might not spend that much time troubleshooting the network. But if you're in a small shop and you're a developer and you kinda have to wear all hats, you may have to do that. So just kinda see where everybody's at and we can discuss this. I'll give everyone a minute to complete the poll and then we'll look at the results.

Alright, the results are in. Um so it looks like, oh, nice, less than 10% of your day is spent troubleshooting the network. That's awesome. You all have some amazing network engineers. That is beautiful. I love to see that. So, thank you.

Um let's move on to our next slide.

Ok. So the AWS global infrastructure, when we talk about deploying our applications on AWS, we have 32 regions. What does that mean? Well, these 32 regions all across the globe is where you're gonna deploy your application. Usually as close as to your customers as possible within those regions. We have something called Availability Zones. We have 102 availability zones. These are where we cluster data centers and I'll talk more about this in a moment. And then finally, we have 600 plus Points of Presence. Those are where you find CloudFront, cloud content delivery networks as well as Route 53 and Global Accelerator.

Now, when we talk about regions, a region is just a geographical area around the world where we actually cluster those availability zones. Usually we have three availability zones in each region. So when we talk about availability zones, these are clustered data centers, we have one data center, sometimes more data centers that are all clustered together to provide fault tolerance and high availability. These availability zones, there are three in each region at least and in those availability zones, they are separated far enough apart just in case there's a flood in that availability zone or some type of earthquake. The next availability zone will still have high availability.

Now building the VPC. I mentioned a region, a region is a geographical area here. I have us-east-1 which is in Virginia. When you log into the console, you select a region and in that region is where your resources like your VPCs live. If you go to another region, your VPCs and your resources in that region will be totally different.

Now you go to, you select your region, then you create your VPC, that VPC will span the entire region. Within our region, I mentioned we have Availability Zones. So a VPC can span multiple Availability Zones but it only lives in one region. And then from there you create your subnets, your subnets go in one Availability Zone and one Availability Zone only. You cannot move that subnet. If you need another subnet, you need to create an additional subnet in another Availability Zone. And then from there you launch your virtual machines or what we call EC2 instances (Elastic Compute Cloud) instances inside of those data centers, which is those Availability Zones that I mentioned. And now you have your networking and you have your high availability. If you are leveraging multiple Availability Zones, that's the basis of how we architect a VPC on AWS.

Now, when we talk about Amazon VPC and security basics, there's some things we need to know. So Amazon Virtual Private Cloud, if we look at this inside of a VPC, the VPC lives in a region. Inside of that VPC, you have your EC2 instances, your Lambda functions, your relational databases and things like that you put inside of your VPC.

Now we recommend that you use private IP addresses inside of that VPC. Outside of your VPC, even with AWS, things like DynamoDB, Amazon DynamoDB, Amazon S3. These are using public IP addresses. So what does that mean if we're trying to connect to our VPC from the internet or from our VPC, connect to S3, we need some way to do that.

So from the internet, nothing can get into your VPC by default. And from your EC2 instances trying to connect to your public services, whether it's DynamoDB or S3 can't do that unless you configure it. So this is the fundamental principles. Your Amazon VPC is basically a high level container that's secured by default. Here's where you configure all of your networking.

So let's go ahead and do that. When you create a VPC in the region, you're gonna start with the CIDR block. The CIDR block can be as large as the /16, which is 65,536 IP addresses or as small as a /28 which is 16 IP addresses within one VPC.

Here, I have listed two Availability Zones in us-east-1, we have six Availability Zones. But to keep things simple, I'm only using two. So once you create your VPC, now, what do you do next, you create your subnets within that VPC. But before that, an additional thing that I wanna talk about is that a VPC can have multiple address blocks.

So if you have, are running Kubernetes workloads or you are, have very large workloads within your VPC and you need additional address blocks or let's say you didn't right size your VPC and you need to add more addresses or CIDR blocks. You can do that up to five for IPv4 and IPv6.

When it comes to IPv6, if you do an Amazon allocated IPv6, you will get one allocated from Amazon or AWS, that's up to five and it will be a flat /56. But you can also bring your own IP.

So now we can talk about CIDR blocks. Let's talk about something else. We have an IP address and for our VPC, for our subnets, what we have here is we have the ability to create an IPv4 only subnet as well as a dual stack. So that means that the subnet will have IPv4 and IPv6, you can also create an IPv6 only subnet. You cannot create an IPv6 only VPC, but you can create an IPv6 only subnet. So you can stack your VPCs.

Once you create a subnet within one Availability Zone from there there's some things you need to know. There are five reserved IP addresses every time you create a subnet. So those, those reserved IP addresses are gonna be your network address, which identifies the network for that subnet, your VPC router, which we'll talk about more about that here in a moment as well as the Route 53 resolver. This is gonna be for DNS within your VPC and then there's one reserved, we reserve that here at AWS and then finally broadcast.

So in a traditional network, when we talk about broadcast, well, that's how you communicate to all IP addresses on one network. In the cloud, that broadcast does not exist. So that's not something you actually have going on inside of your VPC. And in the case of IPv6, we have the same thing.

Now, I'm using the DB8 IPv6 range. This range is for documentation purposes. So this is not something that's gonna be routable.

Now, once you create your subnets and you launch your instances, your instances inside of your subnets, at that point, your instances will have something called an ENI or an Elastic Network Interface. Think of it, this is like your network adapter for your instances. Your instances will get an IP address from that CIDR block within the subnet, same for IPv6.

Now, there's something interesting about this and we'll talk about this here in a moment when it comes to because if you are using a public IPv4 address to communicate on the internet. If you look at your instance, if you do an ifconfig if you're just gonna see the private IP address block for IPv4, but IPv6, you're gonna get what you call a global unique address for IPv6. Those are global unique routable IPv6 addresses.

Now, although they're routable, there's some controls that you can have. So when we talk about subnets, so we can really dive into this is that subnets on a traditional network, in order for these subnets to communicate, they need something called a router for different subnets to kind of communicate. But in a VPC, this is totally different. It doesn't operate like that and I'll show you here in a moment. What I mean when we talk about routing, I have four subnets here by default inside of a VPC. All four of these subnets can communicate. There's something called a main route table for VPC. Whenever you create a VPC, you get this main route table, this route table will have what you call a local route. The local route will be for IPv4 and IPv6. This local route is basically a router within the VPC. It's not one router, it's a collection of routers, but either way it routes the traffic for all of your subnets within your VPC. It handles that for you.

So there's nothing within your VPC that you have to do by default. Now, you can have multiple route tables in a VPC, but you can only have one subnet associated, as a subnet can only be associated with one route table. So when we talk about subnets kind being that security boundary for a VL, it's not like that in the cloud, you mainly control the subnets with routing.

So here we have a local route. If we want a IPv4 subnet to communicate with the D stack is gonna use IPv4 here. And then from my IPv6 only subnet, it will be able to communicate via IPv6 and all of this is due to the local routes that are in the routing table.

Now, we talked about the VPC, we talked about IP addressing, we also talked about subnetting and we talked about routing. The next thing we need to talk about is security. Security in the subnet is a boundary on a traditional network. But in the cloud, the boundary for the subnet is gonna be your network access control list. These are stateless firewalls, meaning that if a client wants to communicate with our instance to SSH to that instance, we need to define a rule inbound traffic is allowed.

So the request goes through, but we also need to, to find a rule outbound, the traffic is allowed. So this means that whenever you're creating a VPC, you create subnets. A subnet will go to the default network access control list. Is there the default network access control list by default allows all traffic in both directions.

If you want to manage controls at the subnet level, you can use network access control list. Normally your network team will put something broadly there to block IP addresses from PACI specific ranges of addresses. But normally you're just gonna leave this broad and just leave it as is because there's another way to control security within your VPC.

Now, I make sure this needs to be in both directions here. The inbound, we are allowing traffic but on an outbound rule, we're denying traffic. So this means when traffic from our instance tries to reply to our client, it will be denied by default due to not having a rule on the outbound.

So if we want to allow traffic from my client, we can add a specific rule allowing that traffic on the inbound. We had the rule on the outbound. But then if you don't do this broadly, you'll have to do this every time for all IP addresses and, and something that so like I mentioned, there's a better way to do this.

And here's where we start talking about security groups, security groups control our access to our instances here, we have a security group that's surrounded our instances, but in reality, it's actually protecting our ENIs or our network interfaces within our instances.

So if we remove our VPC s and we just focus here on our SS and our security group, how does it work? Well, security groups are state for firewalls. That mean if you put a rule in place on the inbound, the reply, the request and the reply will be allowed if you have a rule in place.

So here we have a client that wants to SSH SSH into our instance, it sends a request, the reply will be allowed. Now, what about the outbound on the outbound? We put one on the outbound to inbound to allow traffic in to allow traffic out of our instance. We can use outbound rules.

Here, we have a outbound rule allowing traffic to our web server. And again, the request is sent and the reply will be allowed because it's a state for firewall and these protect our instances.

So if you're trying to provide granular control to your instances or to your VPC s, you're gonna do this with security groups and i'm gonna show you a way that we can even expand on pun this.

So we have a one security group, one instance in our security. What happens if we add another instance to that security group or another one? What we can actually do is reference our security group because right now our instances can communicate via ssh because they have the same security group. But what happens if they wanna ping or send a ac tp request between those instances.

Well, because of this rule that we have in our security group, it won't be allowed. So what we could do if we have some type of auto scaling groups and we're using this in our deployments, what we could do is actually reference the security group itself. And then at that point, we're allowing all traffic between these instances that are in the same security group and then traffic will be allowed and that kinda went too fast.

There we go. Awesome. So here we have two security groups. We have a database server that's in our database tier and a web server that's in our web tier. Of course, we want our clients to be able to communicate with our web server, but we don't want our clients to communicate with our database server. So how can we manage this?

Well, we have two security groups. One for the web server, the web's here and one for our databases. We create a security group allowing traffic to access our web servers. Then we create a security group that allows our web server to access our database servers. But this time, rather than using an IP address, we referenced the web servers security group.

So now we can reference other security groups. So this means that when communicate, when the web server wants to communicate via port 3306 to the database here, traffic will be allowed and since we're self, since we're referencing other security groups, if we're auto skiing, each instance that is added to that security group will also be able to communicate with our database here on a scale up and scale down as well.

Now, connectivity within AWS I mentioned by default, when you try to connect to the VPC, either inbound or outbound, it's secure, right? So how do we get connectivity to the internet?

Here, we have instances in four different subnets. There are three things we need to do to provide connectivity from our instances in our subnet to the internet. The first thing we need to do is attach an internet gateway to our VPC. A internet. A VPC can have one internet gateway. A internet gateway can be attached to one VPC. This is what provides that internet connectivity for your VPC s.

The next thing we need to do is your instances have to have a public IPv4 address or IPv6. Your internet gateway can handle traffic for IPv4 and IPv6. The third thing we need to do, we need to ensure that our route table has a route to the internet gateway.

Now, if you use an IPv6, you have to add a rule for IPv4 and IPv6. This same thing applies for security groups and network access control list. So if you're using dual stack subnets and you're using um ad stack VPC. When you use the security groups, route tables, you have to also think about IPv4 and IPv6 in those route tables if you have dual stack subnets.

So here at this point, our ENI for our instance in the subnet with the 10.0 0.1 0.0 slash 24 has what you call e IP. These elastic IPs can be associated when you launch your instance or you could associate a e uh um elastic IP after the fact. And so this would be like a static IP, a public IP that you will actually keep. So if your instance shuts down or restarts anything, it'll have the same IP when it returns.

Once we have all these three things at that point, your instances can communicate on the internet. Now I mentioned previously about your IPv4 instances having private IP addresses. If you're on your instance, you do it. If config on e zero, what you'll see is a private IP address. But we know that we have a public IP address. What we can do is send a query to the instance metadata service to find out what the public IP is that's attached to this instance is. And so this public IP is actually a 1 to 1 address translation via the internet gateway. So the internet gateway is doing some type of address translation of 1 to 1 for your instances at IPv4.

But at IPv6, your instance will have an IPv6 address. Now I mentioned the IPv4 connected to the internet. Here. We have our public subnets that have a route table. Now, have you all heard the term public subnets, private subnets? Ok. Let me explain this.

So on AWS, if a route table has a route to an internet gateway, it is a public subnet. If it does not have a route to an internet gateway, it is a private subnet. Now, when we talk about connectivity via that, that means that our public subnets will send traffic via the internet gateway and our private subnets will only be able to communicate locally within the VPC. They don't have a route.

So I mentioned that we can have multiple route tables within our VPC. So now this is how we control the some extra security within our VPC. So now we have a public subnets, we associate them with the public route table and then we associate our private subnets with a private route table and we manage routing at that layer to say what can communicate with what. And then we're also adding security with our security groups.

Here, we are communicating via the local route. Here, we have three local routes because we have two IPv, four VPC, s uh IP sv four cider blocks to our VPC. So moving on, connected to the internet, I mentioned public subnets and private subnets.

The next thing I wanna talk about is the NAT gateway. You may have your database here that wants to communicate in the internet to the internet. Well, we know that we don't want those access from the internet, from the public internet and we don't wanna put them in a public subnet.

So what we can do is keep them in a private subnet, create an internet gateway in each of our availability zones because we don't wanna send traffic across the availability zones because of the data transfer charges. And then at that point, we create a route table for each of our subnets in each availability zone. And then you point them to that NAT gateway in that availability zone.

So now when our database servers need to communicate with the internet, they're gonna leverage the route tables in that availability zone is pointing to the NA gateway. And since the NA gateway does the network address translation that's AWS manage, it's sending traffic to the internet gateway via the public route table.

And so now when our answer in our private, so they want to communicate with the internet, they're gonna go via the NAT gateway through the internet gateway to the internet. And so that means that our private subnets are protected. So traffic wants to communicate with them from the internet. It will not be allowed about responses.

Oh responses are allowed as long as you have your network access control is configured correctly. Responses will go through. Awesome. Now, we talked about IPv4, we talked about the NAT gateway. Now we need to talk about egress only or IPv6 egress only internet gateway.

So we may have workloads that are in our private subnets and since they're using that gu a that's globally rout. What if we don't want our workloads to be globally rout? We don't wanna route them on the internet. What we could do is create a routing table that does not have a route to. And in that gateway, we attach it uh egress only in that gateway.

And then at that point, we put a IB I PV six default route pointed to that egress only in, in a gateway. And now traffic will go through the egress only and in the gateway. And if traffic tries to come from the internet will not be allowed. So if you're running I PV six, there's no charge for the internet gateway or the egress only internet gateway.

So we talked about connecting to the internet. What about connecting from the internet? Well, here we have the user, let's call that user. Dean. Dean wants to connect from the internet. There's five things you need to do.

The first thing just like with access to the internet, you need a public IP on your instance. This is the public IP that you're gonna use to communicate with that instance.

The next thing you need to do. You need to ensure for that instance, you have a security group that allows the traffic that you want to communicate to that instance from there.

You need to ensure that your subnet boundary, the network access control is is allowing traffic to that subnet from there.

You need to attach an internet gateway. So traffic is allowed into your VPC through the internet.

And then finally, you need a route for your public subnet that points to the internet gateway. And so at that point, if I wanted to SSH into my instance, I could do that from my user one.

Great. Now at the beginning, I talked about this slide where you have your Amazon VPC services like in EC2 instances, then you have your public services that live outside of your VPC on AWS. How do you connect to those services privately?

Well, one of the questions I get is VPC endpoints, what's the difference between a gateway end point and an interface endpoint? It's often a question I get.

Well, the first difference is that when it comes to gateway endpoints, they provide private connectivity to AWS public services, but only two services. Amazon S3 and Amazon Dynamo DB.

The next difference is if you're connecting to work and you're transferring data to from, to and from S3 from your VPC, you're gonna use a gateway endpoint and that's gonna save on da data transfer chargers because there's no data transfer charges using the gateway endpoint when you're connecting from your VPC to S3.

And then the third thing is when you create your great, your gateway endpoint, you're gonna have a route in your routing table. That's a prefix list that has the IP addresses for Amazon S3 and Dynamo DB. And then now when your instance wants to communicate via S3, it's gonna go through that gateway end point because there's a route in the ta the routing table that points to that gateway endpoint.

And so this allows you to connect privately from your VPC without an internet gateway without a net gateway. And without VPN, the next option is gonna be interface end points, interface end points are pro are powered by private link.

So it provides a private and secure connectivity between your VPC s and AWS services. So we have hundreds of services that you can leverage interface end points for. But essentially what it does is you create an interface endpoint and then that interface endpoint creates a en i within that availability zone within that subnet that looks like it's exactly in the cider block of your subnet.

And so now when i wanna communicate with cloud watch, i'm gonna communicate with that interface endpoint that's in my subnet. And i go to directly privately power by private link to amazon cloudwatch.

So if you think about the differences between a gateway endpoint and the interface endpoint, just think about when it comes to gateway endpoints. i'm using a route in a routing table rather than the interface endpoint is powered by aws privately and i'm gonna have an ip address on it. e and i that i can also use dns to communicate with my services.

Now, traveling also gives us the ability to leverage our own services or customer services or if we wanna expose the service to another customer, but we don't wanna have that bidirectional communication. we just want that unidirectional communication. what we could do is we use a network low balancer. we put our servers in a target group and then from there, we can leverage private link for our consumers to be able to consume our services.

So basically what we do is we use private link and we expose our service and then now that service can be consumed by other consumers from other vpc s other accounts. And this again is without a internet gateway without internet gateway as well as without vpn.

Yes, yes. is that it can probably go between regions, the network low balancer.

Now connecting between vpc s, there's a couple options to do that. The first is gonna be vpc parent. vpc parent creates a 1 to 1 bidirectional communication between two vpc s. think of this as a point to point communication.

Now, every time you wanna connect to another vpc, you gotta create a new point to point communication. So that means you gotta update routing, you gotta manage all these communication between these vpc s. So after you scale beyond a couple of vpc s, this becomes a challenge to manage.

So if you wanna centralize this, you're gonna use the AWS transit gateway, which is gonna be that hub is bo technology where the tra uh transit gateway is the central AWS centralized router or centralized hub to where you attach your vpc s, your vpn s to the transit gateway. And then at that point, you manage the routing between those vpc s centrally via the transit gateway.

And we also talked about private link. So if we need to connect between vpc s in a uni directional fashion, we can also use private link for that tcp communication.

Now, some additional information about connecting between vpc s. What amazon vpc pair, the max pair that you can have is 100 and 25 vpc s but there is no bandwidth. If you use a vpc pair, it's also routed bidirectional connectivity.

In the 48 w transit gateway, you can have 5000 vpc peer attachments to the vpc. And each one of those attachments per availability zone could have 100 gigabytes per attachment. They're routed bidirectional as well through the transit gateway.

And then finally, privately, there's no quota for the number of consumers that can consume your service and it scales up to 100 gigabytes per second per en i in availability zone. And this is also a unidirectional

Now we talked about connecting to your vpc s. We talked about connecting from your vpc s and we also talked about connecting between vpc s. Let's talk about hybrid connectivity.

If you wanna connect from your data center to AWS, there's a couple of options. The first option is gonna be leveraging the vpn gateway. You attach a vpn gateway to one vpc that vpn gateway can attach to one private gateway, can attach to one vpc. And then from there you use AWS site to site vpn to connect to that private gateway between your customer router or firewall. And then for each vpc, you create a new vpn connection.

Now, if you need a more dedicated direct connection to AWS, here's where you're gonna use direct connect. This is gonna go through uh direct connect partner. And then from there you use a direct connect gateway to connect your vpc s and then you have connectivity from your own premises to AWS.

And if you wanna provide high availability, you will have two direct connect connections to your di direct connect gateway which connects to your vpc s.

Now, we can also lev leverage the transit gateway. So the transit gateway allows for vpn connections. So when we're using site to site vpn, we could actually connect directly to the transit gateway as well as if we're using direct connect, we can leverage direct connect and connect directly to a transit gateway.

So rather than managing multiple um virtual private gateways. we manage everything centrally from the transit gateway. And again, if we need high availability, we create a second direct connect connection in a different location.

Now, traffic monitoring and visibility on AWS, there's a couple ways to do this. But before we do that, let's do a poll question. Since we only have about 10% of you that how to manage your networks. I would like to know what's your biggest challenge when it comes to troubleshooting your network problems in the cloud?

Awesome. Looks like the results are in and we can see the results, ok? We cover two of them security groups and knuckles as well as routing. Ok?

So when it comes to traffic visibility options and use cases on AWS, there's two main options that we can use within our VPC. It's gonna be Amazon VPC s prolog as well as Amazon VPC traffic monitor and we'll talk both about both of those in a moment. Ok?

Well, Amazon VPC flow laws, these allow you to get metadata like source destination port to be able to see. Ok. what's communicating on your network? Who are my top talkers? You could take this data, you could send it to Amazon CloudWatch or you can send it to S3. This helps you troubleshoot your network to get that visibility of your network patterns, to understand actually what's actually traversing your network.

These can be assigned at the ENI level. So you wanna get really grain to see what's communicating from your ENI, they can be, they can also go from a little more broadly at the, at the, at the subnet level. So if you wanna capture everything that's coming out of your subnet to determine metadata at the subnet level, and if you wanna go extremely broad, you can actually use VPC flow laws at the VPC level as well.

Now what if you want to do traffic inspection to see? Ok, i i see the metadata but i really wanna be able to look inside those package and understand what's communicating on my network and the type of traffic that's actually traversing.

So what we can use is Amazon VPC traffic mirror. What this, what this is is you configure it on the ENI and you're able to copy this to another ENI instance, gateway low balancer or some other um private third party um partner.

So it takes the communication and then once it has a communication coming into, into the instance that you assign that you want to traffic mirror, it takes a copy of that traffic and then it sends it to the answers that you saw the, the next tool we have.

And i think this tool is really helpful because when you're using AWS, you're looking at your security groups to understand the actual security rules that you have in place, you have your knuckles in place, you have your firewalls in place. You have all these different areas you have to look.

Well, we announce reach ability analyzer which basically looks at your network configuration. it analyze it to determine the path of that communication. For instance, if our ins instance can communicate from our instance to the internet, we can actually look at the entire path.

So we know we start from our instance, then we go to our ENI, then we go out the ENI from our security group. Then from there we go to our network access control list. Then from there we go to our routing table, the internet gateway, it's looking at each hop.

The thing is it's not sending pings, it's actually looking at the configuration to determine, ok, what is your configuration and how should this actually intended path be? And so once it determines, oh, there's an issue with the routing table at that point, it will give you notification to let you know exactly in your path where the problem may lie.

So now you can troubleshoot to add the route to the internet gateway and be able to communicate with the internet which ability analyzer supported by instances and in the gateways, network interfaces and a bunch of other source and destination resources and other intermediate components, you can learn more about this as well.

So that completes today's presentation. My name is Dewan Lightfoot. I thank you all for joining today. If you all have questions i'm here for Q&A and I will take some time to answer your question as well. So, thank you all.