What is a private subnet? A beginner's guide to the mechanism of a private network

When researching AWS network configuration, you will come across the term "private subnet." It is often introduced as an environment that is not exposed to the Internet, but it is a concept that is difficult to grasp, such as why it is separated and what changes occur when it is separated.

When it comes to issues such as the relationship with VPCs and public subnets, and how to handle internet communications, terminology tends to take precedence, making it difficult to paint an overall picture. As a result, design discussions can proceed without a full understanding of the meaning.

In this article, we will explain private subnets from the perspective of the concept rather than the configuration procedure. We will explain how private subnets work, how they are divided with public subnets, and in what situations they are used so that even AWS beginners can understand.

What is a private subnet?

A private subnet is a subnet that cannot be accessed directly from the Internet. In AWS, multiple subnets are created within a VPC, and routes in the route table are used to separate "places that can be reached directly from outside" and "places that cannot be reached directly." A private subnet falls into the latter category.

It's important to remember here that a private subnet does not mean that you can't do anything with it. It just means that you can't access it directly from the outside, but it doesn't mean that the system is locked down.

As needed, application processing, database connections, access from the internal network, management connections for operations, etc. are established. Rather than reducing what you can do, you are now able to control "how to connect" through design.

The reason why AWS's design requires separate subnets is that the "location" of a network simultaneously affects security and operations. Internet-facing functions are located on the ingress side, while processes and data that need to be protected are located internally. By separating the network structure in this way, even if a problem occurs on the ingress side, the impact is less likely to spread internally.

It is easier to understand private subnets if you think of them as "parts that give shape to the concept" of secure operation on AWS.

Differences from public subnets

The difference between a public subnet and a private subnet is whether it can be directly connected to the Internet.

Public subnets have a route to an Internet gateway and can be directly communicated with from the outside, while private subnets do not have such a route and cannot be directly reached from the outside.

This difference is not simply a distinction between public and private, but is directly related to the division of roles. The public subnet acts as an "entrance" that accepts communications with the outside world. It is common for resources that have contact with the outside world, such as load balancers and bastion servers, to be placed in it.

In contrast, private subnets handle "internal" roles such as application processing and data management. They are areas that are hidden behind the entrance and cannot be directly accessed from the outside.

Another thing to keep in mind is that this is a topic that occurs at a layer before security groups.

Security groups are a mechanism for precisely controlling communication, but subnet separation determines whether or not a route can be reached directly in the first place. No matter how much you restrict it with security groups, as long as it is a structure that can be reached from outside, it still acts as an entrance.

In AWS, the basic order is to first separate roles based on the network structure, and then add controls using security groups.

Why do we need private subnets?

Private subnets are used for more than just the benefit of being private.

At AWS, we minimize contact with the outside world and design our systems with the premise of limiting the scope of impact in the unlikely event of a problem.

Private subnets are an element that embodies this concept in network configuration.

Design concept that does not directly expose the server

There is no reason to have a structure that allows direct access from the outside to servers that do not need to be exposed to the Internet. A private subnet is a mechanism for placing internal processing such as applications and databases in a location that cannot be accessed from the outside in the first place.

The role of the ingress is limited to a load balancer, and the server that handles the actual processing is placed behind it. This separation allows for a design that minimizes contact with the outside world.

The important thing is to "create a structure that does not expose data from the beginning" rather than restricting data communications later. By separating roles at the network configuration stage, it becomes easier to prevent misconfigurations and unexpected disclosure.

The idea of ​​reducing the attack surface

The more resources you expose to the outside world, the greater your chances of being attacked. By using private subnets, you can limit the areas that are directly visible from the internet, reducing your attack surface.

This is a way of thinking that is closer to "reducing the number of places that can be targeted" rather than "strengthening defenses."

In AWS, control by security groups and IAM is important, but organizing the network structure itself is a first step that affects overall security. Private subnets play a role in creating that foundation.

A structure that "limits damage even in the unlikely event of an intrusion"

No matter how many countermeasures you take, the risk of intrusion cannot be reduced to zero. Therefore, when designing AWS, we not only consider how to prevent intrusions, but also how far the impact will be if an intrusion does occur.

By separating the configuration using private subnets, even if a problem occurs on the ingress side, it is less likely to affect internal servers and databases.

In this way, creating a structure in advance that can contain damage in stages leads to stable operation. Rather than being a part of security measures, private subnets can be said to reflect a design approach that assumes risk.

Typical resources placed in private subnets

Private subnets are used to place resources that do not need to be directly accessed from outside. What's important is not the "type" of resource, but rather "how the resource should interact with the outside world." Here we will organize some typical examples.

Database

A database is a typical resource that resides in a private subnet.

In many systems, the database does not need to be accessed directly from the Internet. By assuming that connections will only be made via the application server, the risk of unauthorized access or incorrect operation from outside can be reduced.

In AWS, managed services such as RDS are typically placed in private subnets, limiting communication sources to applications. Narrowing down contact points at the network structure stage leads to stable operation.

Application Server

Application servers are another resource that are often placed in private subnets.

External requests are accepted at an entrance such as a load balancer, and the actual processing is carried out by an internal server.

This approach makes the application itself invisible to the outside world, making it easier to control communication routes. Another benefit is that when scaling or updating, the ingress and processing can be considered separately, making it easier to limit the impact of configuration changes.

Internal batch and management processing

Servers used for periodic batch processing and management are also typically placed in private subnets. These are not directly accessed by end users, but rather play a behind-the-scenes role in supporting business processing and operations.

By placing it in an environment isolated from the Internet, it is possible to design it so that unnecessary disclosure is avoided and only necessary communications are permitted. For administrative processes, the fact that they are "located in a place that cannot be seen from the outside" is a factor in operational security.

What to do if you can't access the Internet

A private subnet is configured so that it cannot be accessed directly from the Internet, but this does not mean that it cannot communicate with the outside world at all. AWS enables necessary processing and operations by limiting communication routes and management methods. Here we will organize common questions and their thinking.

How to handle updates and external communications

There are many situations where servers communicate with the outside world, such as updating the OS or middleware, connecting with external APIs, etc. In a private subnet, the basic principle is to control the route for such communications rather than directing them directly to the Internet.

By clarifying the necessity of communication and clarifying "to which destination and in which direction," unnecessary external connections can be avoided. As a result, it becomes easier to achieve both security and operation.

Why use a NAT Gateway?

NAT Gateway is often used when communicating from a private subnet to the outside world.

By going through the NAT Gateway, the server itself remains invisible from the Internet.

Only outgoing communication is allowed.

The important thing is that the NAT Gateway is not just a communication relay device, but a design element for controlling the direction of communication. By not accepting incoming traffic from the outside and allowing only necessary internal traffic, it can be operated while maintaining the characteristics of a private subnet.

How to manage and operate

If you cannot access the server directly from the Internet, you will need to devise a way to manage the server. Typical methods include connecting via a jump server or using AWS management functions.

What both cases have in common is that it clarifies "who can operate what, by which route." Rather than simply expanding the scope of disclosure for the sake of management, a balance between security and ease of use can be maintained by adopting a configuration that allows management while limiting operational routes.

Common misconceptions and stumbling points

Private subnets are often used without a proper understanding. Here we will summarize common misunderstandings and points that are likely to lead to mistakes when designing and considering them.

Private does not mean completely safe

It is not accurate to think that placing it in a private subnet will make it safe. It does make it impossible to access directly from the Internet, but that alone does not eliminate the risk.

Problems can arise if there is internal misoperation, excessive permissions, or unnecessary communication permissions.

Private subnets are not a "protective mechanism" but a prerequisite for establishing a secure design. You should not rely on them too much and should consider combining them with other measures.

Separation alone is not the end of security measures

In some cases, it may seem like security measures are complete once the subnetwork is separated, but in reality, the design and operation that follows are important.

Unless communication control, authority management, log acquisition, operational rules, etc. are organized, the effectiveness of separate structures will be limited. Private subnets are merely a foundation for building up countermeasures, and are not a complete solution on their own.

Is it necessary even in a small-scale environment?

With small-scale systems, you may wonder whether it is necessary to separate them to this extent. This decision should be made based not on the scale of the system, but on the data being handled and how you plan to operate it in the future.

For example, if you are handling customer data in a production environment or if you anticipate configuration changes later, it will be easier to make adjustments if you separate them from the start.

On the other hand, for testing purposes or temporary environments, simplifying may be a realistic option. The important thing is whether you have made the decision to separate or not.

In what cases should it be adopted?

Private subnets are not required for all systems. What's important is not the size of the environment, but "what you want to protect and how you want to operate it." Here, we will organize typical cases where you should consider adopting a private subnet, as well as cases where simplification is practical.

Production

In a production environment, it is common to consider the configuration assuming a private subnet. By separating the parts that need to be exposed externally from the parts that need to be processed internally, the configuration becomes easier to understand and it becomes easier to make changes and deal with problems during operation.

In particular, for systems that will be in operation for a long period of time, separating them from the start will help reduce adjustment costs later.

Systems that handle customer data

When handling information that should not be leaked to the outside, such as customer information or business data, adopting a private subnet is a viable option. By placing databases and internal processes in a location that is not directly visible from the outside, you can reduce the number of unintended access routes.

In such cases, the advantage is that the configuration can be set up on the premise of "allowing only necessary communications."

If you have audit or security requirements

In systems that require audit compliance or security standards, the network configuration itself may be subject to review. Separating roles using a private subnet makes it easier to explain the configuration and communicate its intent.

This is an effective configuration in situations where "an organized design" is valued rather than the measure itself.

Conversely, cases where it can be made unnecessary or simplified

On the other hand, strict separation is not necessary in all environments. In testing environments, temporary environments, and configurations that do not contain internal data and are intended for external release, it may be easier to operate if the separation is simplified.

The important thing is whether there is a reason for the decision not to separate them. If you have made the choice after sorting out your requirements and objectives, you do not necessarily have to use a private subnet.

Important points to keep in mind when designing private subnets

Private subnets are not intended for use with any particular feature or service.

This is a way of thinking to organize "what should be exposed to the outside and what should be treated as internal" when designing an AWS network. Finally, we will summarize the points to keep in mind when designing.

"Separation" is not the goal

The goal of a private subnet is not simply to separate things. The important thing is to intentionally separate the parts that have contact with the outside world from the parts that need to be protected internally.

Separating the configuration is meaningless if communication and authority are not organized. The essence of design is to aim for a state where you can explain "why this part is not exposed" and "where is the entrance point?"

Design including operation, expansion, and explanation

Creating a network configuration is not the end of the process. You need to consider ongoing operations, future expansion, and how to explain it to stakeholders.

Configuring a system with a private subnet in mind makes it easier to organize the scope of impact when changes or additions occur. Also, because the design intent is visible as a structure, it is easier for people who look at the configuration later to understand. This is an important point, especially for systems that are in operation for a long time.

Points that are easy to get confused about in the initial design

In the initial design, it is easy to decide, "It doesn't seem necessary now, so let's leave it out," or "We can think about it later." However, network configuration is also an element that is difficult to change significantly later.

If there is a possibility that the types of data handled or the scope of disclosure will expand in the future, it may be easier to make adjustments if you separate them from the beginning.

On the other hand, in an environment where the purpose and duration are clear, it is reasonable to make the decision to simplify. The important thing is whether the configuration is the result of deliberation or whether it is a configuration chosen intentionally.

Conclusion

A private subnet is not a mechanism for keeping things hidden from the internet, but rather a way to think about how to separate systems in AWS. By separating the parts that come into contact with the outside world from the parts that need to be processed and managed internally, it not only improves security but also makes it easier to operate and respond to changes.

The important thing is not to decide whether to separate the configurations based on intuition, but to make an intentional choice based on assumptions such as the data to be handled, operation period, future expansion, and accountability.

Understanding private subnets does not mean memorizing the AWS network in detail. When you look at a configuration diagram, the criterion for determining whether you understand it is whether you can explain why this is outside and why this is inside.