Network Diagrams in AWS
Diagrams are a very important starting point for planning your cloud infrastructure. DevOps engineers start with a visual representation of the required cloud infrastructure before they turn it into code.
Goal: The goal of this post is to get comfortable in the creation and interpretation of cloud networking diagrams. You will learn how to identify the AWS resources that are required to be used in the diagram, and learn to place the resources correctly in the diagram, such as
load balancers, and
The first thing to understand in our journey is to know what a Virtual Private Cloud (VPC) actually means. A VPC is simply a network segment or a container that is isolated from the other networks. So any EC2s or devices that you deploy within a VPC can easily talk with each other but they cannot reach other networks such as the internet unless you create specific routing to allow this.
Thanks to VPCs you can have several completely independent networks within your AWS account. For example, production and development, where you may want to have complete separate and isolated network traffic.
VPCs can be split further into smaller network segments known as: subnets. And then you can apply routing rules to those subnets, for example, to allow internet traffic to one subnet but not another.
Another benefit of the subnets that you get from the Cloud, is that you can have one subnet in a separate data center or AZ than another subnet. This is known as high-availability. Because if you lose electricity/network connectivity to one of your subnets, you can still see the other subnets within your VPC, and if you design your application correctly, you will be able to continue normal operations.
Our target network diagram
Shown here is our target network deployment, which is going to have two public subnets and two private subnets within a VPC. The public ones with have two-way internet access, whereas the private subnets will have one-way traffic only.
Ultimately, we are trying to build a diagram that contains all the elements of a web application deployment: including a Elastic Load Balancer, Web Servers where our application will be running, Networking elements like: Internet Gateways and NAT Gateways and finally the whole network itself which is made up of a VPC, Public and Private subnets, and routing rules.
Sign up for LucidChart with your account
email@example.com, create a blank document. Click on
Shapes to see available shapes and select
AWS 2017 and
AWS 2019 tools. This will allow you to draw a large variety of AWS resources into your diagrams.
Draw Containers: You almost always start with a container shape. The very first container we are going to use is the
AWS Cloud Container. This cloud container just represents your account and all the resources it can access. It is just a visual to show you that this is your AWS account and if there are resources outside of the AWS account, then this gives you a way to represent them in the diagram. One example of things that lie outside are Users. And what this means is that if you have a web application that you are running, the users mean the web visitors and those are going to be obviously outside the cloud, they just come from the internet in this case.
Now, once you have created your account, the very first container that we need to create is the Region. A local business may be entirely contained in a region. So, if all your applications are always going to be deployed in the AWS Northern California region ( us-west-1 ) -for example- then you don’t need to specify this in your diagrams because all your co-workers will already know this.
The exception would be if you are designing a multi-region architecture, say, for Disaster Recovery reasons. In this case, it’s certainly useful to specify the region you are talking about, in your diagrams.
In our case, we will keep things simple and stick with only one Region. Typically, when we have only one region in the diagram, we don’t represent it.
Draw Availability Zones: You can think of an AZ like a Data Center. This AZ is within the region that you are working in. When designing systems with high-availability, you should have more than one AZ. Now, so far, even though we have two AZs within a region, within an AWS account, we really haven’t created anything that could be translated into code. Because AZs are already available, they are already there, you just get to use it.
Virtual Private Clouds and Subnets: VPCs and subnets within that cloud follow the same rules as traditional networking. A virtual private cloud is a pool of networked cloud resources. It can span more than one availability zone. The equivalent of this would be a data center. However, thanks to availability zones, VPCs can span more than one physical building. This is an amazing feature that protects against real world disasters like electrical failures, fires and similar events.
The CIDR block indicates the available IP addresses that you will have to deploy resources within this network, such as Web Servers, Database Servers, etc. Each one of these will require their own ip address. So in this 10.0.0.0/16 means to reserve the top 16 bits for the network and the remaining 16 bits available for your ip addresses - about 65000 ip addresses, which is plenty for most use cases.
Now, a subnet is simply a small subset of those ip addresses, available in our example. But why do I need a subnet? What is the purpose? Well, a subnet creates logical separation between resources, say separate production from development, it can easily block or allow access to and from resources through routing, and it can help you by providing services such as public internet access to a specific set of resources and not to others. So, back to our example, if our VPC is 10.0.0.0/16, we know that top 16 are reserved for network, so we can then use 10.0.1.0/24 - meaning that the top 3 octets or top 24 bits are constant. Thus, our available IP addresses are 255 for this subnet. I could technically create 255 of this smaller subnets without our VPC by doing 10.0.2.0/24, 10.0.3.0/24.
- the main goal of VPC is to provide private IP address space for your network and resources.
- a subnet is a smaller chunk of that ip address space.
- the /00 at the end of an address represents the number of bits that are constant for this VPC or subnet from left to right.
- having subnets helps you with routing and providing services to and from your resources.
- lastly, remember to create networks and subnets with future expansion in mind.
- A subnet is a subset of the overall VPC network and it only exists in a single availability zone, unlike its parent network, the VPC.
- A subnet contains resources, and can be assigned
access rightsthat apply to all resources within that subnet.
- Subnets can be public or private. Public subnets are accessible to external users. Private subnets are only accessed internally by other resources within your cloud container.
Use IP addresses for routing traffic:
- Use IP addresses as the “keys” for routing traffic. We can route traffic to stay within the VPC, or within a particular subnet, for security reasons.
- For example, a database or any sensitive data will be placed in a private subnet. A public server, like a web server, can be placed in a public subnet. Routing rules applied to a subnet allow us to define access to all resources placed inside that subnet.
So, by now we have created the subnets, but the real value of creating these subnets is to use the IP addresses in these subnets to define our routing traffic. What does that mean? If we have a routing table, you can use that routing table to say:
hey I want this traffic to stay within my VPC, or this traffic to just go to this one subnet or that subnet. That’s the basics of networking. What we do with that is that we use it as an element of security. So, in our private subnets, we are going to deploy, let’s say, a database, something that has very sensitive and critical data for your business, you don’t want that exposed to the internet. However, if you have a web server showing the applications and talking about your company, obviously then, you want people outside to be able to see this information and say,
hey this is a public facing server, we want everybody to be able to see this server. You would put such a server, in what we call the public subnet. In that subnet, what you are going to have is, this server running and receiving inbound internet traffic from any source. Obviously, it is a web server and you want that to be accessible from anywhere. Now you don’t want that to happen to your database server or anything that is sensitive for your company. So there comes the concept of private subnet. This is where you are going to deploy your sensitive data, and then we are going to use routing rules and security groups which will help you block access to these things.
Up until now we have seen that a VPC is a networking container. It is completely isolated from the world, there is no way to get in here. So, how is our subnets public if we can’t access it? What we need is a service called internet gateway. The sole purpose of internet gateway is to provide inbound and outbound traffic to our VPC. That doesn’t mean everybody can get in just yet, we are going to get to that part, but we need this component to be able to access the VPC. (Obviously it doesn’t make sense if you create resources in a data center that belongs to AWS somewhere in west coast if you cannot access that from your company or from your home. So this internet gateway is going to provide us with a way to go in and out. Now, you may ask, what if I only have private resources in this VPC? Could I use this Cloud if I don’t have anything to share with the public? Lets say I am running a human resources application - something internal and specific that only belongs to your internal company and may not be shared with anybody else, - can I still use the cloud in this case? The answer is yes. In this case however, you will not have an internet gateway, you would probably have a VPN connection or a direct connect connection into your cloud.
With what I have described above, it appears that we cannot provide internet access to our private servers - because sometimes those servers may need to contact outside services like S3 for some files or to download patches from the internet etc. A good example of this is Amazon S3 service is actually a public service - which means that if you want to access that from your private subnet, you need a way to get out and be able to access this service. So, even though we are calling them “private subnets”, what ever resources we put in there still needs to have a way to have outbound internet access.
If I just created a VPC and I wanted to provide internet access to it, I should first create an IGW, attach the IGW to VPC, and create a route to the IGW and associate it with your subnets.
Software Defined Networking: What we have created here it’s called Software Defined Networking. That is, using APIs and already-existing physical infrastructure to create our own networking layer on top, with our own privacy rules, our own routing and our own Private IP Space.
Summary Internet Gateway:
- An internet gateway is a resource that enables inbound and outbound traffic from the internet to your VPC.
- An internet gateway allows external users access to communicate with parts of your VPC.
- If you create a private VPC for an application that is internal to your company, you will not need an internet gateway.
Network Address Translation (NAT) Gateway:
A NAT or Network Address Translation Service is used to provide outbound internet access to resources in your private subnets. What it does is, it translates incoming public traffic into private traffic. And it itself needs to have public internet access to be able to do that. So, remember to place it in a public subnet.
It provides outbound-only internet gateway for private services to access the internet. This keeps the private service protected from inbound connections, but allows it to connect to the internet in order to perform functions such as downloading software updates. The NAT gateway serves as an intermediary to take a private resource’s request, connect to the internet, and then relay the response back to the private resource without exposing that private resource’s IP address to the public.
Note: Place NAT Gateways inside the public subnets and not the private subnets. NAT gateways need to be in the public subnet so that they can communicate with the public internet, and handle requests from resources that are in a private subnet.