Building VPC Security and Network Isolation with Security Groups, Network ACLs, Network Firewall, and PrivateLink
_Category: Network Security_
Many security incidents stem from a single blind spot: not being able to trace where traffic actually went. In AWS, network isolation is not just a handful of firewall rules — it is a layered boundary architecture that spans account → VPC → subnet → ENI. In this post, we unpack VPC network security, one of the highest-weight topic areas on the SCS-C03 exam, in a structured and practical way.
---
VPC Isolation's Layered Architecture: Account → VPC → Subnet → ENI
Think of AWS network isolation as a set of Russian nesting dolls — each boundary neatly contained within the next.
The outermost boundary is the AWS account. VPCs belonging to different accounts are completely isolated from each other unless you explicitly establish connectivity. Inside an account, you can create multiple VPCs to separate environments (dev, staging, prod) or isolate workloads by function.
Within a VPC, subnets divide the space into a Public Zone and a Private Zone. Public Subnets connect directly to the internet through an Internet Gateway (IGW), while Private Subnets permit only outbound traffic through a NAT Gateway. The innermost boundary is the ENI (Elastic Network Interface). A Security Group attached to each EC2 instance's ENI enforces access control at the instance level.
From a routing perspective, the Route Table determines where traffic is directed. A Public Subnet's Route Table contains a entry; a Private Subnet's Route Table contains . No matter how permissively you configure a Security Group, packets cannot reach their destination without the correct Route Table entry. This is exactly why, when troubleshooting VPC peering, you must always verify that the peering route has been added to both sides' Route Tables.
For enterprise environments that require centralized network governance, the Shared VPC pattern via AWS RAM is a common approach. A central networking account controls subnet CIDRs, routing, and Network ACLs, while individual workload accounts independently deploy EC2 instances, RDS databases, and other resources within those shared subnets.
---
Security Groups vs. Network ACLs: The Stateful vs. Stateless Divide
Imagine a Security Group as a badge reader beside each employee's desk. When someone walks in, the reader recognizes them; when they leave, it automatically lets them out because it remembers they entered. This is Stateful — connection state is tracked. A Network ACL, by contrast, is the security guard at the building entrance. Entry is checked against one set of rules; exit is checked against a completely different set, with no memory of prior decisions. This is Stateless.
| Attribute | Security Group | Network ACL | |-----------|---------------|-------------| | Scope | ENI (instance level) | Subnet level | | State handling | Stateful — return traffic is automatically allowed | Stateless — separate inbound and outbound rules required | | Default behavior | Deny all (only explicit allow rules take effect) | Default VPC allows all; custom NACLs deny all by default | | Rule types | Allow only (no deny rules) | Both allow and deny rules; evaluated in numbered order | | Source reference | Can reference another Security Group ID (same region) | CIDR/IP only | | Change propagation | Immediate | Immediate |
A critical practical point: Security Groups cannot explicitly deny traffic. If you need to block a specific IP address, you must use a Network ACL DENY rule — a Security Group alone cannot do it. Also, because Network ACL rules are evaluated in ascending numerical order, any DENY rule must be assigned a lower number than a conflicting ALLOW rule in order to take effect.
In cross-region VPC peering, Security Group ID references are not supported. Within the same region, you can use the peer VPC's SG ID as an inbound source. Across regions, you must specify a CIDR block (e.g., ) as the source instead.
!Security Group versus Network ACL
Gaining Traffic Visibility with VPC Flow Logs
VPC Flow Logs capture source IP, destination IP, port, protocol, and ACCEPT/REJECT status at the ENI level, then ship the records to CloudWatch Logs or S3. When traffic that should be permitted is being dropped, the REJECT field helps you pinpoint whether a Security Group or a Network ACL is responsible.
However, because Flow Logs operate at the ENI level, they cannot see inside an NLB's target group. This is a common SCS-C03 trap: in a PrivateLink troubleshooting scenario, the Interface Endpoint appears healthy but traffic never reaches the backend. Flow Logs will not surface this issue. The EC2 instances behind the NLB — with their own Security Groups and Network ACLs — may be silently dropping packets, but those drops do not appear in Flow Logs because they occur at a layer below what Flow Logs captures.
Combining VPC Flow Logs with Route 53 Resolver Query Logging gives you DNS-level visibility as well. You can identify which instances are querying unknown external domains — an invaluable signal for detecting Command and Control (C2) communications in the early stages of an incident.
---
AWS Network Firewall vs. GWLB-Based Third-Party Firewalls
If Security Groups and Network ACLs are your first line of defense, AWS Network Firewall is the advanced perimeter with deep packet inspection (DPI) capabilities.
Network Firewall works by provisioning a dedicated Firewall Subnet inside your VPC and manipulating Route Tables so that all relevant traffic is forced through that subnet. It supports both Stateless rules (fast 5-tuple matching) and Stateful rules (IPS/IDS-grade deep inspection), and it accepts Suricata-compatible rule groups. You can enforce URL filtering, domain-based blocking (e.g., patterns like ), and TLS inspection.
Gateway Load Balancer (GWLB) is the preferred mechanism for inserting third-party firewall appliances (Palo Alto Networks, Fortinet, etc.) transparently into your AWS network. GWLB uses GENEVE tunneling to forward original packets to the appliance without modification. After the appliance completes its inspection, GWLB routes the packets back to their original destination.
| Attribute | AWS Network Firewall | GWLB + Third-Party Firewall | |-----------|---------------------|-----------------------------| | Management | Fully managed by AWS | Customer manages the appliance fleet | | Customization | Suricata rules, domain filtering | Full feature set of the appliance | | Scalability | Automatic scale-out | GWLB distributes traffic across an appliance pool | | Best fit | Minimize ops overhead; AWS-native posture | Lift-and-shift existing on-premises firewall policies | | Visibility | Network Firewall alerts → CloudWatch / S3 | Appliance-native logging |
On the exam: when the requirement is "use our existing on-premises security appliance to inspect AWS traffic," choose GWLB. When the requirement is "AWS-native IPS with domain-based filtering," choose Network Firewall.
---
VPC Endpoints and PrivateLink: Communicating Without Touching the Internet
PrivateLink is like hosting a guest in a private meeting room without ever letting them into the main building. SaaS services or services from other AWS accounts can be consumed entirely over private networking, with no internet exposure.
There are two types of VPC Endpoints:
| Attribute | Gateway Endpoint | Interface Endpoint (PrivateLink) | |-----------|-----------------|----------------------------------| | Supported services | S3 and DynamoDB only | Most AWS services + custom services | | Implementation | Adds a route to the Route Table | Creates an ENI with a private IP inside the VPC | | Cost | Free | Hourly + data processing charges | | On-premises access | Not supported (VPC-internal only) | Supported (accessible via Direct Connect or VPN) | | Private DNS | N/A | When enabled, routes the entire service domain to the VPC Endpoint |
The Interface Endpoint's Private DNS setting is a frequent exam trap. When Private DNS is enabled, the entire service domain (e.g., ) is resolved to the VPC Endpoint's private IP. If the same VPC also needs to reach public APIs on that domain, enabling Private DNS may unintentionally block those public requests. In environments where both private and public APIs must coexist, disable Private DNS and manually configure DNS only for the private API endpoints.
VPC Endpoint Policies let you scope down which resources are reachable through an Endpoint, using IAM policy syntax. You can attach a policy to an S3 Gateway Endpoint to allow only specific buckets, or restrict an Interface Endpoint to allow calls to only certain APIs.
AWS Systems Manager Session Manager requires just three Interface Endpoints — , , and — to provide secure EC2 access without a public IP or a Bastion host. EC2 Instance Connect Endpoint enables browser-based SSH access without exposing port 22 to the internet.
---
Transit Gateway, Direct Connect, and VPN Security Options (Including MACsec)
In multi-VPC or hybrid environments, Transit Gateway acts as the central hub. It connects hundreds of VPCs and on-premises networks through a single attachment model, and Transit Gateway Route Tables give you fine-grained control over which VPCs can communicate with each other. Common exam patterns include: isolating dev and prod VPCs by placing them in separate Route Tables, and using a centralized Security VPC as a hub so that all inter-VPC traffic must pass through a firewall.
Direct Connect provides a dedicated private circuit between on-premises and AWS. MACsec (IEEE 802.1AE) adds Layer 2 hop-by-hop encryption to that circuit. Even if the physical line is tapped, the data remains protected. MACsec is available on 10 Gbps and 100 Gbps dedicated connection ports.
Site-to-Site VPN establishes an IPsec tunnel over the internet and can be provisioned much faster than Dir