Understanding AWS VPC Security Features at Once: How to Design a Secure Cloud Network

1. VPC and Subnets: The Starting Point of Security Boundaries

A VPC is a logically isolated virtual network that you define. To draw a parallel with an on-premises environment, it’s similar to creating your company’s internal network within AWS.

However, creating a single VPC doesn’t complete your security. What’s important is how you divide the inside of the VPC.

The most basic approach is to separate public subnets and private subnets.

Public Subnets

A public subnet is a subnet that has a route to an internet gateway.

Typically, the following resources are located here:

ALB
Bastion Host
NAT Gateway
Some services that require direct external access

Private Subnets

A private subnet is configured so that it cannot be directly accessed from the internet.

Typically, the following resources are located here:

Application servers
Databases
Internal API servers
EKS Nodes
ECS Services
ElastiCache
OpenSearch

From a security perspective, the important principle is simple.

Only resources that need to be directly exposed to the outside should be placed in a public subnet; the rest should be placed in a private subnet if possible.

In particular, databases generally do not need to be in a public subnet.

The most common mistake in practice is, “It’s just for testing, let’s open it publicly for a moment.” The problem is that this setting often remains in production.

VPC security begins with correctly designing where resources are placed, rather than with complex security equipment.

2. Route Tables: Controlling Traffic Flow Paths

Within a VPC, route tables determine where traffic moves.

Even if a subnet appears private, if its route table has a default route pointing to an internet gateway, it becomes a structure capable of external communication.

For example, if there is routing like the following, that subnet has a public character.

0.0.0.0/0 -> Internet Gateway

Conversely, typical routing for a private subnet is as follows:

0.0.0.0/0 -> NAT Gateway

In this case, instances in the private subnet can go out to the internet, but direct connections from the internet to those instances are not possible.

That is, patch downloads, package installations, and external API calls are possible, but it’s not a structure where external users can directly connect to the server.

Route tables may not feel like a security feature because they don’t appear as “allow/deny rules” like security groups or Network ACLs. However, they are actually a very important feature in VPC security.

Incorrect routing can expose your internal network to the outside.

When performing a VPC security review, you must check the following items:

Does the database subnet have an Internet Gateway route?
Is the internal application subnet unnecessarily directly connected to the internet?
Is outbound traffic via NAT Gateway controlled?
Have unexpected network paths been created through Transit Gateway, VPC Peering, or VPN connections?

When conducting a VPC security review, you should not only look at security groups but also at route tables.

Actual attack paths are created when “allowed ports” and “open routing” are combined.

3. Security Groups: Virtual Firewalls at the Resource Level

Security groups are the most frequently used feature in VPC security.

They are attached to various resources such as EC2, RDS, ALB, ENI, and VPC Endpoints to control inbound and outbound traffic.

A key characteristic of security groups is that they are stateful.

For example, if an EC2 instance sends an HTTPS request to the outside, the response traffic is allowed even if it’s not explicitly specified in the inbound rules.

Conversely, traffic coming into an EC2 instance from the outside must be allowed by an inbound rule.

Dangerous Security Group Examples

The following settings are very dangerous in a production environment.

SSH 22번 포트      0.0.0.0/0 허용
RDP 3389번 포트    0.0.0.0/0 허용
MySQL 3306번 포트  0.0.0.0/0 허용
모든 아웃바운드    0.0.0.0/0 허용

While often seen in test environments, these settings are extremely risky in production.

Specifically, opening SSH and RDP to the entire internet can make them targets for brute-force attacks, weak account attacks, and exploitation of exposed keys.

Recommended Security Group Design

A good approach is to restrict access based on source IP or other security groups.

For example, an ALB security group can allow ports 80 and 443 to the internet.

However, the application server security group should only allow traffic coming from the ALB security group, not the internet.

The RDS security group should only allow ports 3306 or 5432 traffic coming from the application server security group.

The general flow is as follows:

사용자 -> ALB -> 애플리케이션 서버 -> 데이터베이스

In this case, the database does not need to know the user’s IP directly, nor does it need to be exposed to the internet.

It only needs to receive traffic from the application server.

Security groups are not just about opening ports.

Security groups are a feature that expresses trust relationships between application layers at the network level.

4. Network ACL: A Secondary Line of Defense at the Subnet Level

Network ACLs (NACLs) are access control features that operate at the subnet level.

While security groups operate at the resource level, Network ACLs control traffic at the subnet boundary.

Security groups and Network ACLs have the following differences:


Category	Security Group	Network ACL
Application Unit	Resource or ENI	Subnet
Operation Mode	Stateful	Stateless
Rule Type	Allow rules	Allow and Deny rules
Primary Purpose	Resource-level control	Subnet-level secondary control

The term “stateless” means that requests and responses are treated separately.

For example, even if inbound port 80 is allowed, communication may fail if outbound traffic for the response is not allowed.

Network ACLs are more suitable for broad, subnet-level control rather than fine-grained application control.

For instance, you can block a specific malicious IP range across an entire subnet or restrict a particular subnet from communicating on any port other than specified ones.

However, trying to handle all security with Network ACLs can complicate operations.

In practice, security groups are generally used as the primary control mechanism, and Network ACLs are used as a secondary line of defense or a guardrail.

5. Internet Gateway and NAT Gateway: Securely Separating Internet Connectivity

For a VPC to communicate with the internet, an Internet Gateway is required.

However, the presence of an Internet Gateway does not mean all resources are exposed to the internet.

Actual internet access depends on the following factors:

Presence of a public IP
Route tables
Security groups
Network ACLs
Internet Gateway attachment status

Resources in a public subnet can communicate directly with the outside via an Internet Gateway.

Conversely, resources in a private subnet typically go out to the internet via a NAT Gateway.

A NAT Gateway allows private subnet resources to initiate outbound connections to the internet, but it prevents direct inbound connections from the external internet to private instances.

This structure is very important.

For example, application servers may need internet access for OS updates or external API calls.

However, internet users do not need direct access to the application servers.

In this case, using a NAT Gateway allows you to create the following structure:

프라이빗 서버 -> NAT Gateway -> Internet Gateway -> 인터넷

That is, it’s a structure that allows outbound communication but blocks direct inbound connections.

However, a NAT Gateway alone does not provide complete security.

A NAT Gateway is not fundamentally a security device that performs fine-grained inspection of outbound traffic or blocks by domain.

Therefore, in critical environments, it is recommended to design it with the following features:

AWS Network Firewall
Proxy server
Route 53 Resolver DNS Firewall
Egress filtering
VPC Flow Logs

6. VPC Endpoint and PrivateLink: Accessing AWS Services via Private Network

Many AWS services are accessed via public endpoints.

For example, consider situations where an EC2 instance accesses S3, ECS fetches ECR images, or an application calls Secrets Manager.

In security-critical environments, it’s best to access AWS services via AWS’s internal network path, avoiding the internet if possible.

The feature used for this is VPC Endpoint.

VPC Endpoints can be broadly categorized into two types:

Gateway Endpoint

Gateway Endpoints are typically used for the following services:

Amazon S3
Amazon DynamoDB

Using a Gateway Endpoint allows access to S3 and DynamoDB from within the VPC without the need for a separate Internet Gateway or NAT Gateway.

Interface Endpoint

Interface Endpoints operate based on AWS PrivateLink, allowing access to AWS services via private IP addresses.

They can typically be used for the following services:

AWS Systems Manager
AWS Secrets Manager
Amazon ECR
Amazon CloudWatch Logs
AWS STS
AWS KMS
Amazon ECS
Some services related to Amazon EKS

The security advantages of VPC Endpoints are significant:

Reduces internet exposure.
Reduces reliance on NAT Gateway.
Endpoint policies can restrict accessible actions.
S3 bucket policies can allow requests only through specific VPC Endpoints.
Restricts access paths even if credentials are stolen externally.

For example, you can create a security policy like this:

This S3 bucket is only accessible via a specific VPC Endpoint in our VPC.

This makes it difficult to access S3 directly from the external internet even if credentials are stolen.

VPC Endpoints should not be viewed solely for cost savings.

In reality, they are a powerful security design element that reduces data exfiltration paths.

7. AWS Network Firewall: Managed Firewall at the VPC Level

While security groups and Network ACLs are very useful for basic network control, they have limitations for advanced security inspection.

For example, if you have the following requirements, you might consider AWS Network Firewall:

Domain-based filtering
Stateful traffic inspection
Intrusion detection and prevention
Centralized egress control
Blocking suspicious external communication
Inter-VPC traffic inspection

AWS Network Firewall is a managed network firewall service that can be applied to a VPC.

It provides stateful firewall capabilities and intrusion detection and prevention features, and can be used in a structure that filters traffic from Internet Gateway, NAT Gateway, VPN, and Direct Connect paths.

In practice, it is often used for outbound traffic control.

Many companies are sensitive to inbound security but relatively lax about outbound security.

However, after a breach, malware often communicates with external C2 servers, or internal data is exfiltrated, typically via outbound connections.

Therefore, for critical VPCs, the following policies should be considered:

Route all internet outbound traffic from private subnets through Network Firewall.
Allow external communication only to permitted domains or IP ranges.
Block suspicious protocols or abnormal ports.
Collect firewall logs to CloudWatch Logs, S3, Security Lake, etc.

Network Firewall is not just an “expensive firewall.”

It can be seen as a core feature for VPC egress control and centralized security policy enforcement.

8. VPC Flow Logs: Basic Visibility Feature for Recording Network Flows

The most dangerous state in security is “not knowing what’s happening.”

If you can’t tell which IP communicated with which IP, which ports were allowed, or which traffic was denied within a VPC, incident response becomes very difficult.

VPC Flow Logs is a feature that collects IP traffic information at the VPC, subnet, and network interface levels.

Collected logs can be sent to the following destinations:

Amazon CloudWatch Logs
Amazon S3
Amazon Data Firehose

Flow Logs can be used for the following analyses:

Checking if a specific EC2 instance communicated with an unfamiliar external IP.
Identifying traffic denied by security groups or Network ACLs.
Analyzing if unused ports are continuously being called.
Detecting attempts to directly access databases.
Understanding outbound traffic flow via NAT Gateway.
Tracing an attacker’s movement path during a breach.

However, Flow Logs do not store the entire content of packets.

That is, they do not show HTTP bodies or file contents.

Instead, they provide the following flow information:

Source IP
Destination IP
Source port
Destination port
Protocol
Allow or deny status
Bytes transferred
Packets transferred
Time information

Therefore, Flow Logs are more like a “network entry/exit logbook” than a “network CCTV.”

They record who moved where and through which door.

In production environments, it is recommended to enable Flow Logs for at least critical VPCs or subnets.

From a security perspective, it’s important to analyze REJECT logs along with ACCEPT logs.

Denied traffic can be a clue to attack attempts, misconfigurations, or application failures.

9. Traffic Mirroring: When Packet-Level Analysis is Needed

While VPC Flow Logs provide network flow information, Traffic Mirroring is a feature that delivers actual traffic copies to security analysis devices.

For example, traffic generated from an ENI of a specific EC2 instance can be copied and sent to the following systems:

IDS
NDR
Packet analysis systems
Forensic devices
Security monitoring systems

Traffic Mirroring is useful for security incident analysis, intrusion detection, compliance, and network troubleshooting.

However, it is not a feature that is absolutely necessary for all environments.

In typical web service operations, Flow Logs and application logs are often sufficient.

But it can be useful in environments such as:

Financial institutions or environments where security monitoring is critical
Environments requiring packet-level intrusion detection
Environments performing zero-trust network analysis
Environments needing detailed traffic analysis of specific servers during a breach

It’s important to note that because Traffic Mirroring is a traffic copying feature, cost, performance, privacy, and storage policies must be considered together.

Rather than indiscriminately replicating all traffic, it’s better to selectively mirror only critical segments.

10. Reachability Analyzer: A Feature to Verify Actual Connection Paths

VPC security settings involve multiple interacting elements.

Because the following elements are combined, human visual inspection alone can lead to oversights:

Security Groups
Network ACLs
Route Tables
NAT Gateway
Internet Gateway
Transit Gateway
Load Balancer
Network Firewall
VPC Endpoint

Reachability Analyzer is a tool that analyzes whether a specific source can network-reach a destination.

For example, it can answer questions like:

Can this EC2 instance access RDS on port 3306?
Is this ENI reachable from the internet?
Can the Bastion Host SSH into internal servers?
Can only the application server access RDS?
Does a path exist for a specific subnet to go out to the external internet?

If reachable, it shows the path step-by-step; if unreachable, it identifies which component blocked the connection.

In practice, Reachability Analyzer is excellent for troubleshooting but also very useful for security validation.

Using Reachability Analyzer before and after making significant changes in a production environment can help assess the security impact of network changes.

11. Network Access Analyzer: Finding Unintended Network Access

While Reachability Analyzer is a tool for checking connectivity between a specific source and destination, Network Access Analyzer is a feature that finds unintended network access paths from a broader perspective.

For example, it can perform scope-based analysis such as:

Are there any network interfaces accessible from the internet?
Are there any paths accessible to internal resources from outside a specific VPC?
Are there any unintended VPC Peering paths?
Are there any paths accessible to the database layer from an external network?

Since it’s difficult for humans to check all resource combinations one by one, the ability to find network paths through static analysis is very useful for security audits.

Especially in organizations operating multiple accounts, VPCs, and subnets, exception settings accumulate over time.

Typical examples include:

Ports initially opened for testing
Temporarily created VPC Peering connections
Undeleted security group rules
Public access paths remaining after operational handover
Unnecessarily broad CIDR allowances
Temporary VPN connections
Unnecessarily remaining Transit Gateway routings

Such settings often remain only in the actual environment, not in documentation.

Network Access Analyzer helps find these hidden access paths.

VPC security is not a one-time setup.

It requires periodic verification of “Is our network currently open only as intended?”

12. DNS Security and Route 53 Resolver-based Control

In network security, looking only at IP and port is insufficient.

Actual malware or internal systems often communicate with the outside via domain names.

Therefore, controlling and logging DNS requests is also important.

In an AWS environment, the following features can be utilized:

Route 53 Resolver Query Logs
Route 53 Resolver DNS Firewall
Network Firewall
Proxy-based domain control

For example, if an internal EC2 instance suddenly queries a suspicious domain, it could indicate malware infection or an attempt at data exfiltration.

You can also block requests going to domains not allowed by internal company policies.

DNS security is particularly relevant to outbound security.

Simply opening port 443 in a security group doesn’t tell you which domains are being accessed.

Using Network Firewall, proxies, DNS Firewall, and Resolver Query Logs together can help you better understand and control external communication.

13. Practical Design Example for VPC Security

Let’s consider a typical 3-tier web service architecture with well-configured security.

Public Subnet

Only resources that need direct external connectivity are placed in the public subnet.

ALB
NAT Gateway
Bastion Host or Session Manager alternative configuration

Private Application Subnet

Actual application workloads are placed in the private application subnet.

EC2
ECS Service
EKS Worker Node
Application servers
Internal API servers

Private Data Subnet

Data layers that should not be directly exposed externally are placed in the private data subnet.

RDS
ElastiCache
OpenSearch
Internal-only data stores

In this architecture, the security flow is as follows:

사용자
  -> ALB
    -> 애플리케이션 서버
      -> 데이터베이스

Security design can be applied as follows:

Users access only ALB on port 443.
ALB accesses application servers only on specific ports.
Application servers access databases only on specific ports.
Databases are not directly exposed to the internet.
Internet outbound traffic from private servers is controlled via NAT Gateway or Network Firewall.
Access to S3, DynamoDB, ECR, Secrets Manager, Systems Manager uses VPC Endpoints if possible.
VPC Flow Logs record network flows.
Reachability Analyzer and Network Access Analyzer check for unintended paths.

The core of this architecture is not to block all resources strictly, but to clearly open only the necessary flows.

Security is not “block everything.” It’s about allowing only the paths necessary for the service to function normally, and not opening the rest.

14. Common VPC Security Mistakes

Here are common VPC security mistakes observed in practice:

1. Opening SSH and RDP to 0.0.0.0/0

This is the most common and dangerous setting.

In a production environment, it’s best to use AWS Systems Manager Session Manager or configure access only from a restricted VPN or internal company IPs.

2. Making RDS Public

RDS generally does not need to be directly exposed to the internet.

It should be configured to be accessible only from application servers.

3. Unconditionally Allowing All Outbound Traffic

Due to default security group settings, all outbound traffic is often allowed in production.

However, for critical systems, where traffic can go out should also be controlled.

4. Not Enabling VPC Flow Logs

If an incident occurs and there are no logs, analysis becomes very difficult.

Even considering costs, it’s highly recommended to enable logs for critical segments.

5. Thinking VPC Endpoints are Unnecessary

Relying on the internet or NAT Gateway for accessing services like S3, DynamoDB, ECR, and Secrets Manager can create unnecessary external paths and costs.

6. Judging Safety Solely by Security Group Names

Even if names like private-sg, db-sg, or secure-sg are used, it’s dangerous if the actual rules are open.

You should look at the actual inbound and outbound rules, not just the names.

15. VPC Security Review Checklist

When reviewing a VPC in a production environment, it’s good to check the following items:

[ ] 퍼블릭 서브넷과 프라이빗 서브넷이 명확히 분리되어 있는가?
[ ] 데이터베이스가 퍼블릭 서브넷에 있지 않은가?
[ ] 라우트 테이블에 불필요한 0.0.0.0/0 경로가 없는가?
[ ] SSH, RDP가 전체 인터넷에 열려 있지 않은가?
[ ] 보안 그룹이 다른 보안 그룹을 참조하도록 설계되어 있는가?
[ ] Network ACL이 의도치 않게 너무 넓게 열려 있거나 너무 강하게 막혀 있지 않은가?
[ ] 프라이빗 리소스의 AWS 서비스 접근에 VPC Endpoint를 사용하고 있는가?
[ ] S3 버킷 정책에서 특정 VPC Endpoint 조건을 사용할 수 있는가?
[ ] VPC Flow Logs가 활성화되어 있는가?
[ ] Flow Logs가 S3 또는 CloudWatch Logs로 적절히 저장되고 있는가?
[ ] Network Firewall 또는 egress filtering이 필요한 환경인가?
[ ] Reachability Analyzer로 주요 경로를 검증했는가?
[ ] Network Access Analyzer로 의도하지 않은 인터넷 노출 경로를 점검했는가?
[ ] Transit Gateway, VPC Peering, VPN 연결로 인해 내부망이 과도하게 연결되어 있지 않은가?
[ ] 보안 그룹과 라우트 테이블 변경 이력이 관리되고 있는가?

As this checklist shows, VPC security is not completed by a single feature.

It must be configured in layers by combining multiple features.

16. VPC Security Summarized in One Page

VPC security features can be summarized by role as follows:

Area	Key Feature	Security Purpose
Network Isolation	VPC, Subnet	Separation of public/private areas
Path Control	Route Table	Control of traffic movement paths
Resource Firewall	Security Group	Instance, DB, ALB unit access control
Subnet Firewall	Network ACL	Subnet unit allow/deny
Internet Connectivity	Internet Gateway, NAT Gateway	Separation of external connection structure
Private AWS Service Connection	VPC Endpoint, PrivateLink	Access to AWS services without traversing the internet
Advanced Firewall	AWS Network Firewall	Outbound control, IDS/IPS, domain filtering
Flow Logs	VPC Flow Logs	Network communication records
Packet Analysis	Traffic Mirroring	Packet-level security analysis
Path Validation	Reachability Analyzer	Verification of reachability for specific paths
Exposure Analysis	Network Access Analyzer	Detection of unintended access paths
DNS Security	Route 53 Resolver Query Logs, DNS Firewall	Domain-based communication logging and blocking

—

Conclusion: VPC Security is “Architectural Design”

AWS VPC security is not merely about writing firewall rules.

It is about designing the network architecture.

You must divide public and private areas, control routing, restrict communication between resources with security groups, create a secondary line of defense at the subnet level with Network ACLs, reduce internet paths with VPC Endpoints, perform advanced traffic control with Network Firewall, gain visibility with Flow Logs and Traffic Mirroring, and verify unintended paths with Reachability Analyzer and Network Access Analyzer.

Good VPC security design may seem complex, but the principles are simple:

Minimize what is exposed externally.
Allow internal communication only between necessary targets.
Control paths going out to the internet.
Log all important traffic flows.
Periodically verify that settings are working as intended.

In the cloud, networks can be opened with a few clicks.

Thus, security incidents can also start with a few clicks.

Conversely, by properly understanding and combining VPC security features, many incidents can be prevented in advance.

AWS security’s first line of defense is not just IAM.

A securely designed VPC is also a very powerful first line of defense.

References

AWS VPC Security

Security groups for your VPC

Control traffic to subnets using Network ACLs

VPC Flow Logs

AWS PrivateLink and VPC endpoints

AWS Network Firewall

Reachability Analyzer

Network Access Analyzer