VPC Security — NACLs, Security Groups & Endpoints

This topic covers the core security mechanisms that control access and traffic flow within and across AWS VPCs. You'll need to distinguish between stateful and stateless components, understand default behaviors, and know when to apply each security layer. These elements appear in nearly every multi-tier architecture scenario on the exam.

Core Concepts

Security Groups

Security Groups are stateful virtual firewalls that control inbound and outbound traffic at the instance level (ENI). When you allow inbound traffic on a specific port, the return traffic is automatically allowed regardless of outbound rules.

• Operate at the instance (ENI) level, not the subnet level
• Support allow rules only - you cannot create deny rules
• All rules are evaluated before deciding whether to permit traffic
• Default behavior: all inbound traffic is denied, all outbound traffic is allowed
• You can specify separate rules for inbound and outbound traffic
• You can reference other Security Groups as source/destination (e.g., allow traffic from SG-12345)
• Changes to Security Group rules take effect immediately
• An instance can be associated with up to 5 Security Groups
• Each Security Group can have up to 60 inbound and 60 outbound rules
• If no Security Group is specified during instance launch, the default Security Group is applied

When to Use Security Groups

• Use as the first line of defense for EC2 instances, RDS databases, ELBs, and other resources with ENIs
• When you need to allow traffic dynamically between application tiers (web → app → database) by referencing Security Groups instead of IP ranges
• When you want stateful filtering - return traffic should automatically be allowed without additional outbound rules
• When you need immediate rule changes without waiting for propagation delays

Network Access Control Lists (NACLs)

NACLs are stateless firewalls that operate at the subnet level. Each rule must explicitly allow both request and response traffic because NACLs do not track connection state.

• Operate at the subnet level - apply to all instances in the subnet
• Support both allow and deny rules
• Rules are evaluated in numerical order (lowest number first) until a match is found
• If no rule matches, the default deny rule (*) applies
• Each subnet must be associated with exactly one NACL
• If you don't explicitly associate a NACL, the subnet uses the default NACL
• Default NACL: allows all inbound and outbound traffic by default
• Custom NACL: denies all inbound and outbound traffic by default until you add rules
• Separate inbound and outbound rules must be configured
• Each NACL can have up to 20 rules (soft limit, can be increased to 40)
• Changes take effect within seconds but may have slight propagation delay

When to Use NACLs

• When you need to explicitly deny traffic from specific IP addresses or ranges (Security Groups cannot deny)
• As a secondary layer of defense in addition to Security Groups for defense-in-depth architectures
• When you need subnet-wide traffic filtering that applies automatically to all current and future instances
• When compliance requires stateless filtering or when you need to control ephemeral port ranges explicitly

VPC Endpoints

VPC Endpoints enable private connections between your VPC and supported AWS services without traversing the public internet, eliminating the need for Internet Gateways, NAT devices, VPN connections, or AWS Direct Connect.

There are two types of VPC Endpoints:

Interface Endpoints (AWS PrivateLink)

• Create an Elastic Network Interface (ENI) with a private IP address in your subnet
• Powered by AWS PrivateLink
• Support most AWS services (e.g., EC2 API, SNS, CloudWatch, Systems Manager, etc.)
• You are charged per endpoint per AZ per hour plus data processing charges
• Can be accessed from on-premises via VPN or Direct Connect
• Require Security Groups to control access
• Support DNS resolution via private DNS names
• Each Interface Endpoint is tied to a specific AZ

Gateway Endpoints

• Create a route table entry that directs traffic to the endpoint target
• Only support Amazon S3 and DynamoDB
• No hourly charges and no data processing fees
• Cannot be accessed from on-premises (VPC-only)
• Use VPC Endpoint Policies (not Security Groups) to control access
• Regional - not tied to a specific AZ
• Must update route tables in each subnet that needs access

When to Use VPC Endpoints

• When instances in private subnets need access to S3 or DynamoDB without a NAT Gateway (use Gateway Endpoint)
• When you need to keep traffic between your VPC and AWS services off the public internet for security or compliance
• When on-premises systems need private access to AWS services via Direct Connect or VPN (use Interface Endpoint)
• When you want to reduce data transfer costs by avoiding NAT Gateway data processing fees for S3/DynamoDB (use Gateway Endpoint)

VPC Endpoint Policies

VPC Endpoint Policies are IAM resource policies that control which AWS principals can use the endpoint to access which resources. They apply to both Gateway and Interface Endpoints.

• Written in JSON using IAM policy syntax
• Do not override or replace IAM user/role policies - they work together
• Default policy allows full access to the service
• You can restrict access to specific S3 buckets, DynamoDB tables, or other resources
• You can restrict access to specific IAM principals (users, roles, accounts)
• Cannot be used to grant permissions - only to limit what's allowed through the endpoint

When to Use VPC Endpoint Policies

• When you want to restrict which S3 buckets or DynamoDB tables can be accessed via a Gateway Endpoint
• When you need to enforce that only specific IAM roles can use the endpoint
• When compliance requires limiting access paths to sensitive data stores
• When you want to prevent data exfiltration by blocking access to buckets outside your organization

Ephemeral Ports and Stateless Filtering

Because NACLs are stateless, you must account for ephemeral ports when configuring outbound rules. When a client initiates a connection, the server responds on an ephemeral port chosen by the client OS.

• Linux kernels (Amazon Linux, etc.): ephemeral port range 32768-60999
• Windows Server 2008+: ephemeral port range 49152-65535
• Elastic Load Balancers: use ephemeral port range 1024-65535
• When allowing inbound HTTP (port 80) in a NACL, you must allow outbound traffic on the ephemeral port range (e.g., 1024-65535) for return traffic
• For outbound requests (e.g., instance calling an external API), you must allow inbound traffic on ephemeral ports for the response

When to Account for Ephemeral Ports

• Whenever you configure custom NACLs - forgetting ephemeral ports is the most common NACL misconfiguration
• When troubleshooting connectivity issues where Security Groups allow traffic but connections still fail
• When designing exam scenarios involving web servers behind NACLs responding to internet clients
• Use the broadest ephemeral range (1024-65535) unless you need tighter OS-specific filtering

Commonly Tested Scenarios / Pitfalls

1. Scenario: An EC2 instance in a private subnet cannot access S3, even though the Security Group allows all outbound traffic and a NAT Gateway exists. The exam asks for the most cost-effective solution.

Correct Approach: Create an S3 Gateway Endpoint and update the route table for the private subnet. Gateway Endpoints are free and provide private access to S3 without requiring a NAT Gateway.

Check first: Confirm the instance needs access specifically to S3 or DynamoDB - only these two services support Gateway Endpoints.

Do NOT do first: Do not add an Internet Gateway or assume the NAT Gateway configuration is broken. The scenario is about eliminating unnecessary costs, not troubleshooting NAT.

Why other options are wrong: Using NAT Gateway works but incurs data processing charges; Interface Endpoints for S3 cost money; Internet Gateway requires public IPs and routes traffic over the internet.

2. Scenario: A web tier must allow HTTP traffic from the internet but deny traffic from a specific malicious IP address. Security Groups are already configured to allow port 80 inbound from 0.0.0.0/0.

Correct Approach: Add a NACL rule with a low rule number (e.g., rule 10) that explicitly denies traffic from the malicious IP before the allow rule.

Check first: Verify whether the requirement is to deny a specific IP or IP range - only NACLs support explicit deny rules.

Do NOT do first: Do not attempt to modify the Security Group - Security Groups cannot deny traffic, only allow it.

Why other options are wrong: Security Groups cannot deny; AWS WAF could work but is more complex and costly for simple IP blocking; removing the allow rule blocks all traffic, not just the malicious IP.

3. Scenario: After creating a custom NACL and associating it with a subnet, instances can no longer communicate with the internet or each other. The exam asks what was missed.

Correct Approach: Custom NACLs deny all traffic by default. You must explicitly add allow rules for both inbound and outbound traffic, including ephemeral port ranges (1024-65535) for return traffic.

Check first: Identify whether a custom or default NACL is in use - default NACLs allow all traffic; custom NACLs deny all traffic until rules are added.

Do NOT do first: Do not start troubleshooting Security Groups or route tables before confirming NACL rules allow the required traffic in both directions.

Why other options are wrong: Security Groups are stateful and don't require explicit return traffic rules; route tables don't block traffic, they direct it; missing IGW would affect internet-bound traffic but not inter-instance communication within the VPC.

4. Scenario: An application tier in a private subnet must call an external API on port 443. The NACL allows outbound 443, but connections still fail. Security Groups allow all outbound traffic.

Correct Approach: The NACL must also allow inbound traffic on ephemeral ports (1024-65535) for the response traffic from the external API. NACLs are stateless and require explicit rules for both request and response.

Check first: Confirm whether the NACL has inbound rules allowing ephemeral ports - this is the most common stateless filtering mistake.

Do NOT do first: Do not assume the Security Group is the issue - Security Groups are stateful and automatically allow return traffic.

Why other options are wrong: Security Groups already allow outbound and auto-allow return traffic; route tables direct traffic but don't filter it; NAT Gateway or Internet Gateway issues would affect all outbound connectivity, not just this specific case.

5. Scenario: A company needs to access EC2 API privately from on-premises via AWS Direct Connect without traversing the public internet. The exam asks which endpoint type to use.

Correct Approach: Create an Interface Endpoint (AWS PrivateLink) for the EC2 service. Interface Endpoints create ENIs with private IPs accessible from on-premises via Direct Connect or VPN.

Check first: Determine whether the service is S3/DynamoDB (Gateway Endpoint) or another AWS service (Interface Endpoint), and whether on-premises access is required (only Interface Endpoints support this).

Do NOT do first: Do not select Gateway Endpoint - Gateway Endpoints only support S3 and DynamoDB and cannot be accessed from on-premises.

Why other options are wrong: Gateway Endpoints don't support EC2 API or on-premises access; using a VPN alone doesn't provide private AWS service access; public endpoints require internet routing and expose traffic.

Step-by-Step Procedures or Methods

Task: Configure a NACL to allow inbound HTTPS traffic from the internet and ensure return traffic works correctly

1. Create or edit the NACL associated with the subnet containing your instances
2. Add an inbound rule with a low rule number (e.g., 100):
   • Type: HTTPS (443)
   • Source: 0.0.0.0/0
   • Action: Allow
3. Add an outbound rule with a low rule number (e.g., 100):
   • Type: Custom TCP
   • Port Range: 1024-65535 (ephemeral ports)
   • Destination: 0.0.0.0/0
   • Action: Allow
4. Verify the default deny rule (*) exists at the end of both inbound and outbound rule lists (automatically present)
5. Confirm instances can receive HTTPS requests and send responses by testing connectivity

Task: Set up a Gateway Endpoint for S3 and restrict access to a specific bucket

1. Navigate to VPC → Endpoints → Create Endpoint
2. Select Service Category: AWS services
3. Search for and select com.amazonaws.[region].s3 with type Gateway
4. Select the VPC where the endpoint will be created
5. Select the route tables for the subnets that need S3 access (routes are auto-added)
6. Under Policy, choose Custom and enter a policy like:

   { "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "s3:*", "Resource": [ "arn:aws:s3:::my-specific-bucket", "arn:aws:s3:::my-specific-bucket/*" ] } ] }

7. Create the endpoint and verify route table entries show a route to the S3 prefix list via the endpoint
8. Test access by running AWS CLI commands from an instance in the associated subnet

Practice Questions

Q1: A web application runs on EC2 instances in a public subnet. The Security Group allows inbound traffic on port 80 from 0.0.0.0/0. A custom NACL is applied to the subnet with the following rules: Inbound Rule 100: Allow TCP 80 from 0.0.0.0/0. Outbound Rule 100: Allow TCP 80 to 0.0.0.0/0. Users report they cannot access the application. What is the issue?
(a) The Security Group is missing an outbound rule for port 80
(b) The NACL is missing an outbound rule for ephemeral ports (1024-65535)
(c) The route table is missing a route to the Internet Gateway
(d) The Security Group is missing an inbound rule for ephemeral ports

Ans: (b)
NACLs are stateless, so return traffic must be explicitly allowed. Web server responses go out on ephemeral ports chosen by the client, typically 1024-65535. The outbound NACL rule must allow this range. (a) is wrong because Security Groups are stateful and auto-allow return traffic. (c) would prevent all internet connectivity, not just HTTP. (d) is wrong because Security Groups don't need ephemeral port rules due to statefulness.

Q2: A company needs to allow EC2 instances in a private subnet to download software updates from the internet but wants to block all inbound internet traffic. The instances must also access DynamoDB without using the internet. What is the most cost-effective solution?
(a) Deploy an Internet Gateway and use Security Groups to block inbound traffic
(b) Deploy a NAT Gateway for internet access and an Interface Endpoint for DynamoDB
(c) Deploy a NAT Gateway for internet access and a Gateway Endpoint for DynamoDB
(d) Deploy a NAT Instance and a Gateway Endpoint for DynamoDB

Ans: (c)
A NAT Gateway allows outbound internet access while blocking unsolicited inbound traffic. A Gateway Endpoint for DynamoDB is free and keeps DynamoDB traffic private without going through the NAT Gateway, reducing data processing costs. (a) is wrong because instances in private subnets cannot use an Internet Gateway without public IPs. (b) is wrong because Interface Endpoints cost money; Gateway Endpoints for DynamoDB are free. (d) would work but is less cost-effective and requires manual management compared to NAT Gateway.

Q3: An organization must deny all traffic from IP address 203.0.113.5 to instances in a VPC, but allow all other traffic on port 443. Security Groups currently allow 443 from 0.0.0.0/0. What should be configured?
(a) Modify the Security Group to remove the allow rule and add specific allow rules for all IPs except 203.0.113.5
(b) Add a NACL rule with a lower rule number than the allow rules that denies 203.0.113.5
(c) Create a new Security Group that allows port 443 from all IPs except 203.0.113.5
(d) Add a NACL rule with a higher rule number than the allow rules that denies 203.0.113.5

Ans: (b)
Security Groups only support allow rules, so you cannot deny specific IPs. NACLs support both allow and deny rules and are evaluated in numerical order. By adding a deny rule for 203.0.113.5 with a lower rule number (e.g., rule 10) than the allow-all rule (e.g., rule 100), the deny takes precedence. (a) and (c) are impossible because Security Groups cannot deny. (d) is wrong because rules are evaluated in order; a deny rule with a higher number would never be reached if a lower-numbered allow rule matches first.

Q4: An application team reports that instances in Subnet A can communicate with instances in Subnet B, but instances in Subnet B cannot initiate connections to instances in Subnet A. Both subnets are in the same VPC. Security Groups allow all necessary traffic. What should you check first?
(a) Route tables for both subnets
(b) NACL inbound rules for Subnet A and outbound rules for Subnet B
(c) Security Group outbound rules for instances in Subnet B
(d) Internet Gateway attachment to the VPC

Ans: (b)
Since connectivity works in one direction but not the other, and Security Groups are confirmed to allow traffic, the issue is likely asymmetric NACL rules. NACLs are stateless and subnet-specific. Subnet A's NACL must allow inbound traffic from Subnet B, and Subnet B's NACL must allow outbound traffic to Subnet A (plus the reverse for return traffic). (a) is wrong because route tables within the same VPC default to local routes that allow inter-subnet communication. (c) is wrong because the problem states Security Groups already allow necessary traffic. (d) is irrelevant for intra-VPC communication.

Q5: A solutions architect needs to provide on-premises servers access to Amazon SNS via AWS Direct Connect without routing traffic over the public internet. Which solution meets this requirement?
(a) Create a Gateway Endpoint for SNS in the VPC
(b) Create an Interface Endpoint for SNS in the VPC and configure private DNS
(c) Configure a VPN connection and use the public SNS endpoint
(d) Use AWS PrivateLink to connect directly from on-premises to SNS

Ans: (b)
SNS is not supported by Gateway Endpoints (only S3 and DynamoDB are). Interface Endpoints powered by AWS PrivateLink create ENIs with private IPs that can be accessed from on-premises via Direct Connect. Private DNS resolution directs SNS API calls to the private endpoint. (a) is wrong because Gateway Endpoints don't support SNS. (c) routes traffic over the internet via the public endpoint, not privately. (d) is incorrect terminology - AWS PrivateLink is implemented via Interface Endpoints, not a separate direct connection from on-premises.

Q6: A company has configured an S3 Gateway Endpoint and updated the route table. Instances in the private subnet still cannot access S3. What is the most likely cause?
(a) The VPC Endpoint Policy denies access to the S3 bucket
(b) The Security Group for the instances blocks outbound HTTPS traffic
(c) The NACL for the subnet blocks outbound traffic on port 443
(d) The S3 bucket policy blocks access from the VPC Endpoint

Ans: (a)
Gateway Endpoints use VPC Endpoint Policies to control access. The default policy allows full access, but if a custom policy was applied, it might restrict which buckets or principals can use the endpoint. Both the endpoint policy and the bucket policy must allow access. (b) is less likely because the question states instances "cannot access S3," implying the endpoint is in place but something blocks it. (c) is possible but less common since custom NACLs require explicit setup. (d) is possible but endpoint policies are evaluated first and are a more common misconfiguration when endpoints are newly created.

Quick Review

• Security Groups: Stateful, instance-level, allow rules only, all rules evaluated, default denies inbound/allows outbound
• NACLs: Stateless, subnet-level, allow and deny rules, evaluated in numerical order, custom NACLs deny all by default
• Ephemeral ports (1024-65535): Must be allowed in NACL outbound rules for inbound connections and inbound rules for outbound connections
• Gateway Endpoints: S3 and DynamoDB only, free, route table entries, no on-premises access
• Interface Endpoints: Most AWS services, creates ENI with private IP, costs money, accessible from on-premises via Direct Connect/VPN
• Default NACL: Allows all inbound and outbound traffic; custom NACL denies all traffic until rules added
• To deny a specific IP, use a NACL deny rule with a lower rule number than allow rules
• Security Groups can reference other Security Groups as source/destination for dynamic multi-tier architectures
• VPC Endpoint Policies restrict access through the endpoint but do not grant permissions - they work with IAM policies
• Changes to Security Groups take effect immediately; NACL changes may have slight propagation delay