Public vs. Private Subnets

In the context of cloud computing, particularly in AWS subnets are one crucial component that defines the network topology of your infrastructure architecture. Subnets that are a part of VPC define the division of a network that lets users divide the network traffic, security, and utilization of resources. They are of two categories namely public and private subnets though their uses are different in the architecture. Perhaps one of the most critical aspects when designing cloud infrastructure is the ability to comprehend when to apply public and or private subnets.

Key Terminologies

• Virtual Private Cloud (VPC): An Amazon Web Services deployment of a logically isolated virtual network for your AWS account, allowing the instantiation of AWS resources within it.
• Subnet: An IP address within your VPC which can be either an ec2 subnet that connects to the Internet or a private subnet that is not directly accessible.
• Internet Gateway (IGW): An interface for instances to connect in your VPC to the Internet.
• NAT Gateway (Network Address Translation): A service that enables instances that live in a private subnet to access the internet while at the same time denying internet access to the instances.
• Route Table: A set of rules known as routes that show, to where in the network your subnet or gateway will forward your traffic.

Public Subnets in AWS

A public subnet is a subnet within your VPC that has a route to the internet through an Internet Gateway (IGW). Any EC2 instance launched in this subnet can directly send and receive traffic from the internet. Because of this capability, public subnets are best suited for resources that must be reachable by users across the world. For example, if you are hosting a website or an application that customers need to access from their browsers, you would place the servers inside a public subnet. In short, public subnets act as the front-facing layer of your cloud infrastructure.

Use Cases for Public Subnets

1. Web Servers

Web servers are the most common resources hosted in a public subnet. When you create an application, your customers or users need to reach it through the internet. Placing the web servers in a public subnet allows them to respond directly to user requests without extra configuration. A public subnet ensures that the server can download updates, fetch dependencies, and serve website content efficiently. Hosting web servers in this way makes your application globally accessible and ready for customer interaction.

2. Bastion Hosts

A bastion host is a secure server that administrators use to connect to instances inside private subnets. Without a bastion, you would need to expose your private resources to the internet, which creates security risks. Instead, you launch a bastion host in a public subnet. Administrators first log in to the bastion using SSH or other secure methods. From there, they can safely connect to the private servers. This approach provides an extra security layer by limiting direct access to sensitive instances.

3. Load Balancers

Load balancers distribute incoming traffic across multiple servers to ensure high availability and fault tolerance. In AWS, services like the Application Load Balancer (ALB) or Network Load Balancer (NLB) are usually deployed in public subnets. By placing a load balancer in a public subnet, it can receive requests from the internet and forward them to backend servers, which may exist in private subnets. This setup ensures that your application can handle high traffic volumes without downtime, improves performance for users, and adds redundancy in case one server fails.

Private Subnets in AWS

A private subnet is a subnet within your VPC that does not have a direct route to the Internet Gateway (IGW). Instances in this subnet cannot access the internet directly, which enhances their security. Private subnets are ideal for resources that should remain hidden from public access. For example, internal servers, sensitive databases, or backend applications are typically placed in private subnets. By isolating these resources from the internet, you reduce exposure to potential attacks and ensure better control over network traffic.

Use Cases for Private Subnets

1. Databases

Databases often store sensitive or confidential data, such as user information or transaction records. Hosting databases in a private subnet ensures that they are not directly accessible from the internet. Only applications or servers within your VPC can communicate with these databases. This setup reduces the risk of unauthorized access and helps meet compliance requirements.

2. Internal Application Servers

Internal application servers handle backend processes, business logic, or microservices that other components in your infrastructure use. These servers do not need to be publicly accessible. Placing them in a private subnet ensures they can securely communicate with other internal resources, like web servers in public subnets or databases. This isolation strengthens your system’s overall security while maintaining necessary connectivity.

3. Batch Processing Jobs

Some workloads, such as batch processing, data analytics, or financial calculations, require strict security measures. These jobs often involve sensitive data and operate in controlled environments. By running these processes in private subnets, you ensure that no direct internet connection exists, minimizing exposure and preventing accidental data leaks. Private subnets offer a secure environment to execute such high-compliance tasks safely

Step-by-Step Guide: Setting Up Public and Private Subnets in AWS

Create a VPC:

Go to AWS Management Console to the VPC service and then, click on ‘Create VPC’. Set up the information to define your virtual private cloud (VPC) CIDR block range (for example, 10.

Create Subnets:

Build a public subnet by choosing your VPC and assigning a CIDR block from within the VPC range of your choice (for instance 10. 0. 1. 0/24).

It is also possible to design a similar private subnet using a different CIDR block range within VPC range for example 10. 0. 2. 0/24.

Attach an Internet Gateway:

Develop an Internet Gateway and then associate it to your VPC. It also helps allow freedom to instances in your public subnet to freely connect with internet resources.

Configure Route Tables:

For the public subnet, associate a route table with a route to the internet gateway (destination: 0. 0. 0. 0/0 (Target: Internet Gateway).

Regarding the private subnet, do not allow it to have access to the Internet Gateway.

Create a NAT Gateway (optional):

If those instances in your private subnet be required some outgoing access to internet (e. g. , to update their software), create a NAT Gateway in the public subnet. The next step is to assign route in route table for the private subnet which points to the NAT Gateway.

Example Scenario

If there is the idea of constructing a Web application on AWS, for example. The application assumes the presence of a web front end server, an application server, and a database. Here’s how you could structure your network:

• Public Subnet: The web server resides here as it forms part of the internet and has to address users’ requirements from the World Wide Web.
• Private Subnet: Here is the location application server and database are located. They interface with the web server but cannot be directly accessed from the web site. The application server is can freely connect to the internet for update through the NAT Gateway located in the public subnet.

Public vs. Private Subnet

Conclusion

Dispelling the myth about subnets and distinguishing between public and private subnets and how to use them correctly is the key to correct cloud design. When correctly setting subnets you get the leverage of organizing your AWS resources in a right manner enough to protect or separate the ones that should not interrelate while at the same time making the ones that must interact do so fluently.