Users can launch Amazon resources in a specified virtual network by using a Virtual Private Cloud (VPC), which is a virtual network environment. For executing resources like EC2 instances, databases, and load balancers within a particular area of the Amazon cloud, it offers a safe and segregated environment. Using VPC, users may set up network gateways and routers, manage access to instances, and customize their IP address range and network setup. In order to provide extensive security and network administration capabilities, VPC also supports a number of networking features such as subnets, security groups, and network access control lists.
VPC (Virtual Private Cloud)
Amazon VPC is a private cloud that allows users to deploy AWS resources into a virtual network in a safe, isolated environment. Users are able to access all of the features of a traditional private cloud, including the ability to run programs, host websites, and maintain databases but also allows the scalability and convenience of AWS infrastructure. A virtual private cloud (VPC) separates computing resources from other computing resources in the public cloud.
Default and Nondefault VPCs
The AWS account includes pre-configures VPC by default, allowing customers to get started right away. Each Availability Zone has a default subnet. Users do not need to bother about IP ranges or subnets when launching EC2 in the subnet. When a new user arrives to test AWS resources, the default VPC is handy.
AWS also allows users to establish custom VPCs and modify them according to their needs, which is referred to as a nondefault VPC. Users may select an IP range, build a custom subnet, and customize the environment to their preferences. Nondefault subnets are subnets that are generated inside the nondefault VPC and extra subnets that are produced in the default VPC.
Subnet
A virtual private network (VPC) is formed by a number of IP addresses. This range may be subdivided into smaller networks, which are known as subnets. Subnets can be configured according to the user’s wishes. AWS resources may be deployed to whatever subnet we choose. Consider a VPC with an IP address of 10.0.0.0/16, indicating that the VPC’s IP address range is 10.0.0.0–10.0.255.255. This is a massive network with about 65k IP addresses, all of
Fig 1: A big network is spitting into smaller subnets.
which are private. As a result, they are inaccessible via the internet. This VPC network may be separated into several subnets. In Figure 1, every subnet has a CIDR value of 18, indicating that each subnet has 16384 private IPs. Therefore, /16 network can be divided into 4 subnets of /18. Figure 2 shows a simplified layout of a VPC with four subnets and an EC2 instance launched on subnet 1. Using a local area network (LAN), subnets may communicate with one another. For external connection, subnets must be connected to Internet Gateway (IGW).
Fig 2: VPC splitted into 4 subnets.
Private subnet
The subnets that are not connected to the IGW are known as a private subnet. In the Fig 2, subnet 1 and subnet 2 are private subnets. They do not exist on the public internet. As a result, if an EC2 instance is launched into a private subnet, sudo apt update will not work because it is not connected to the internet. It is also more secure as a result of this. DDOS or any other type of attack is not achievable since they do not exist on the internet. Any application’s backend or database can be kept in the private subnet.
Public subnet
Public subnets are connected to IGW. In Fig 2, subnet 3 and 4 are public subnets. For EC2 instances launching into a public subnet, a sudo apt update is possible. Because everyone on the internet may connect to the public subnet, the front end of an application can be stored here.
AWS Private IP Range
An AWS VPC provides a range of private IP addresses when a customer creates it. AWS recommends that customers use the private IPv4 address range specified in RFC 1918 when creating custom VPCs.
| RFC 1918 Range | Example CIDR Block |
| 10.0.0.0 – 10.255.255.255 (10/8 prefix) | VPC must be /16 or smaller, for example, 10.0.0.0/16. |
| 172.16.0.0 – 172.31.255.255 (172.16/12 prefix) | VPC must be /16 or smaller, for example, 172.31.0.0/16. |
| 192.168.0.0 – 192.168.255.255 (192.168/16 prefix) | VPC can be smaller, for example 192.168.0.0/20 |
These three IP ranges are allowed to be private on AWS. A client can, however, build a VPC with a public IP address, which is outside of these ranges. This might result in the VPC’s traffic and security being reduced. As a result, AWS encourages customers to adopt private IP addresses for their VPCs. Customers can select a range based on their requirements. It’s worth noting that the CIDR block must follow the range in this case. For instance, if a client selects range 1, his VPC’s CIDR block must be /16 or less. The term “smaller” refers to the number of IP addresses that can be used. Because the number of possible IP addresses reduces as the CIDR value increases, the possible CIDR values for range 1 may be /18, /21, or /24.
Normal App deploying in the server process
When deploying an app in the AWS VPC, we may maintain the front-end in the EC2 of public subnet 1. Subnets 2 and 3 are private subnets where the backend and database can be placed. When a user hits the load balancer from the internet, the traffic is routed to the front-end. The front-end communicates with the back-end, and the back-end communicates with the database, requiring a back-and-forth connection. However, because the backend and database are located on a private subnet, they are not accessible from the internet. So, how will the front-end communicate with the back-end?
It is possible to do so over the local network. Because both subnets are part of the same larger network, AWS regulations state that they can communicate with each other. It’s as if all of the subnets are linked to a single large switch or router. One of the major benefits of AWS is that it does not charge users if they transfer data via their local network. When a private subnet needs to be updated or changed, bypassing is required.
Fig 3: simplified diagram of an App deploying in the server
Bypassing private subnet
Subnets 3 and 4 are linked to the IGW in Figure 5. Only these two subnets have access to the internet. The database and the back-end are kept in the private subnet 1 and 2, respectively.
Fig 5: NAT gateway connection in the VPC.
However, the backend and database must be upgraded, and dependencies must be installed or altered from time to time. This is accomplished through the deployment of a one-way Network Address Translation (NAT) gateway. It is connected to the internet using IGW after being placed on the public subnet. This NAT gateway is connected to private subnets. The VPC’s route table must be changed to include connections from the private subnet to the NAT gateway for this operation. Private subnets can use this NAT gateway to send requests to the internet and get responses. However, important thing to remember that NAT is a one-way connection, users from the internet do not have access to the private subnet. At the time of setup, the NAT gateway must have an elastic IP address.
NAT Instance
Unlike NAT Gateway and Internet Gateway, a NAT Instance is not a special service offered by AWS. It is just a term for when using an EC2 instance to perform NAT Gateway-like functionality. It is similar to hosting database software on an EC2 instance rather than using Amazon RDS.
Because it is a self-managed instance, configuring routing, updating the software and operating system, and right-sizing instances is the responsibility of the owner. It is generally not recommended unless there is a specific use-case that needs to support this customization.
Similar to a NAT Gateway, a NAT Instance will need to be in a public subnet, and a private subnet will need a route to the NAT Instance to have internet access.
