Introduction to Network Architecture in AWS Cloud Deployment
Introduction to Network Architecture in AWS Cloud Deployment
In this article, take a look at an intro to network architecture in AWS cloud deployment.
Join the DZone community and get the full member experience.Join For Free
Networking becomes a very important part of cloud deployment. When it comes to availability, Bandwidth requirements, Security and also when satisfying some nonfunctional requirements we need at least a basic understanding of networking in a cloud environment.
Over the last decade. AWS has become the most popular cloud infrastructure platform. Hence I have done some research based on how networking is handled in AWS cloud environments.
When I started searching what I could find was articles related to different components in AWS networking architecture. After going through each one of them I need to connect these dots and get an overall understanding of how these things work as a collection.
Let’s assume that you have a requirement of creating an application in an AWS environment. You will be using AWS EKS to deploy your application pods and for database requirements, you will be using AWS RDS. So following is a basic architecture that you will come up with when it comes to networking.
Well of course if you are new to AWS and networking most of the above terms will be new to you. But during this blog post, I will explain what these components are and how they interact with each other.
VPC (Virtual Private Cloud)
A VPC is a virtual network specific to you within AWS for you to hold all your AWS services. It is a logical data center in AWS. As you can see in the above diagram
VPC contains gateways, route tables, network access control lists (ACL), subnets and security groups. Then the question comes why we need a VPC. The simple answer is security. Through a VPC we can restrict the type of traffic, IP addresses, Users. Also, it gives us the capability to hide some of our services that need not be exposed to the public internet.
When you create a VPC, you must specify a range of IPv4 addresses for the VPC in the form of a Classless Inter-Domain Routing (CIDR) block; for example, 10.0.0.0/16. This is the primary CIDR block for your VPC. We can divide this IP block into several parts and assign them availability zones(AZ) using subnets. AWS VPC there can be public subnets as well as private subnets. Pods and services deployed in public subnets are automatically assigned with public IP addresses.
Normally in a production deployment, we create subnets covering at least two Availability Zones as depicted in the above diagram.
Internet gateways make communication between components inside the VPC and internet possible. This works in both ways. The external parties from the internet can access the VPC through the internet. Also components inside the VPC can access the internet. An internet gateway supports IPv4 and IPv6 traffic. It imposes no availability risks or bandwidth constraints on your network traffic.
NAT simply means Network address translation. When a local (private) IP address needs to access the internet its IP address needs to be translated to the global IP address. This is done by the NAT gateway. But there is a limitation when compared to Internet Gateway. Although components in the VPC can access the internet through NAT. External parties cannot access the VPC through NAT.
This also does the same thing as the NAT gateway but this only supports IPv6.
A route table consists of rules of how network traffic gets directed. Let's explain this with an example.
The destination is the pattern which the requested destination IP should match. Target is the place that the request will be routed if the request matches the specified IP pattern.
For example if the request destination IP is 10.0.0.1 that request will be routed internally to the VPC. For any other IP addresses that do not match the (10.0.0.0/16) such as 172.20.185.31 that request will be routed to the internet gateway(igw-12345678901234567). For IPv6 range if the request destination matches with 2001:db8:1234:1a00::/56 that will be routed internally. For all other IPv6 addresses they will be routed to the Egress only gateway (eigw-aabbccddee1122334).
Route tables are associated with subnets. One or more subnets can be associated with one Route table.
If the route table has specified destination 0.0.0.0/0 to be routed to the internet gateway. And if we have associated that route table to some subnet we can call that subnet a public subnet. In all the other cases it will be a private subnet.
Security groups are capable of controlling your inbound and outbound traffic. You can specify ports and protocols that are allowed to communicate with the components inside a security group.
Let's Connect the DOTs
Now let’s move it to the provided architecture diagram. In the diagram you can see two availability zones inside the VPC. Normally in a production setup we use at least two availability zones. If one zone went down the system should be still able to survive using the other. This is done using the subnets. When creating a subnet you need to specify the availability zone. In the above example, we have created one public subnet and one private subnet for each zone. Private subnets will be used for deploying RDS instances. When creating the RDS instance we need to specify a subnet group. Here we need to specify a subnet group which at least has two subnets on different availability zones. Here we have used two private subnets as a subnet group.
AWS EKS is the Kubernetes service provided by AWS. We can use it to deploy load balancer services as well as application back end pods. The load balancers should be able to access the internet as well as someone should be able to access load balancers through the internet. Due to that as per the above diagram, they are deployed in a public subnet. Each of those two subnets has route tables that have an entry associated with the internet gateway.
On the other hand, Kubernetes backend pods need not be accessed directly from the internet. But for tasks like pulling docker images, those pods should have access to the internet. So as we discussed earlier for these types of use cases we use NAT gateway. There should be a route table as follows that is associated with the subnet.
When considering the RDS we have another entity that needs to be discussed. That is the security group. If the database is MySQL the port that exposes the database service will be 3306. And the protocol will be TCP. All incoming traffic within the security group will be allowed by default. We can restrict the traffic from external sources as follows. The same can be done for outgoing traffic.
I hope this document will help you to get an overall understanding of AWS networking architecture. There can be requirements to change the accessibility level of components in a cloud environment. In that case, anyone will need a proper understanding of all the above concepts. Please let me know if you have any concerns related to the above content that I have created.
Opinions expressed by DZone contributors are their own.