Network Security Troubleshooting Reachability

What Is Network Security Troubleshooting and Reachability Analysis?

Network security troubleshooting in AWS is the disciplined process of taking a symptom — "the application cannot reach the database", "Inspector reports an EC2 reachable from the internet that we thought was private", "DNS lookups for our domain are spiking" — and using the right combination of AWS analyzer services and log sources to find the root cause without guessing. The SCS-C02 exam Task 3.4 explicitly tests network security troubleshooting and reachability analysis because security engineers, not just network engineers, are expected to debug why a security control did or did not work as intended. Network security troubleshooting is also the place where every other Domain 3 topic — security groups, NACLs, AWS Network Firewall, Transit Gateway, Inspector — comes together; if you cannot diagnose a misbehaving control, you cannot prove the workload is actually secured.

The native AWS toolkit for network security troubleshooting is bigger than most engineers realize. You have three reachability analyzers (VPC Reachability Analyzer, Network Access Analyzer, Inspector Network Reachability), three log streams (VPC Flow Logs, WAF logs, Route 53 Resolver query logs), one packet-capture mechanism (Traffic Mirroring), and several log-querying surfaces (CloudWatch Logs Insights, Athena, Security Hub). Each tool answers a different shape of question, and the SCS-C02 exam loves to test whether you can map a question stem to the correct tool in one read. This guide gives you that decision tree and the underlying TCP/IP fundamentals you need to use the tree confidently.

This topic covers Task 3.4 end-to-end: you will build a symptom-to-tool diagnostic decision tree, learn how each reachability analyzer constructs its answer, dive deep into VPC Flow Logs reject codes (BLACKHOLE_ROUTE, ENI_SECURITY_GROUP_RULES_DENY, NACL_RULES_DENY), refresh on TCP/IP basics including ephemeral ports and path MTU discovery, and walk through Traffic Mirroring for full packet capture. By the end of the guide, network security troubleshooting scenarios on SCS-C02 should feel mechanical: you read the symptom, pick the tool, interpret the output, and pick the correct answer.

Why SCS-C02 Cares About Network Security Troubleshooting

Task 3.4 is worth a meaningful slice of Domain 3 (20% of the exam) and is the most "engineer-flavored" task in the entire SCS-C02 blueprint. Where Tasks 3.1, 3.2, and 3.3 ask you to design controls, Task 3.4 asks you to diagnose controls that are already deployed. Question stems read like ticket descriptions: a developer claims a Lambda cannot reach RDS, an auditor flags an S3 bucket as world-readable, an Inspector scan says an instance is reachable that should not be. Your job is to pick the correct reachability analyzer or log source.

A second reason network security troubleshooting dominates Task 3.4 is that AWS released several analyzers (Network Access Analyzer in 2021, Inspector V2 network reachability, Reachability Analyzer cross-account in 2022) specifically to replace ad-hoc shell scripts and aws ec2 describe-* chains. The exam tests whether you know these tools exist and can pick the right one — candidates who default to "tcpdump on the instance" for every network question will lose points to candidates who answer "Reachability Analyzer with a path between the source ENI and destination ENI."

The Diagnostic Decision Tree — Symptom to Tool

The single most testable skill in network security troubleshooting is mapping a symptom to the right tool. Before designing the path-by-path mechanics, internalize this tree.

"Can A reach B right now?" → VPC Reachability Analyzer

When the question gives you a specific source ENI and a specific destination (ENI, internet gateway, transit gateway attachment, VPC endpoint) and asks whether the path works, use VPC Reachability Analyzer. It builds a model of every security group, NACL, route table, peering connection, and TGW route the packet would traverse and either says "reachable" with the path or "not reachable" with the exact blocking element.

"Who could reach my sensitive resource?" → Network Access Analyzer

When the question asks about unintended exposure across a set of resources (for example, "find every EC2 in the production VPC that an internet host could reach on TCP/22"), use Network Access Analyzer. It runs a Network Access Scope (a JSON allow-list of intended paths) and flags every actual path that violates the scope.

"Is this EC2 reachable from outside even with no current traffic?" → Inspector Network Reachability

When the question is a vulnerability-scan flavor — "Inspector reports the instance reachable on port 3306, but I patched it" — use Inspector Network Reachability. It combines open-port detection on the instance OS with a reachability check from the internet (or from a peered VPC) and is what feeds Security Hub findings about exposed compute.

"Connection times out — why?" → VPC Flow Logs ACCEPT/REJECT

When the question is about an actual TCP/UDP failure — timeouts, RSTs, slow connections — turn to VPC Flow Logs. Look at the action field (ACCEPT or REJECT) and, if available, the new v5 fields like pkt-srcaddr/pkt-dstaddr to see asymmetric routing or NAT behavior.

"Layer 7 attack patterns" → WAF logs queried with Athena

When the question concerns HTTP-level attacks (SQLi, XSS, bad bots) on CloudFront/ALB/API Gateway, the answer is AWS WAF logs delivered to S3 and queried with Athena, or sent to CloudWatch Logs and analyzed with Logs Insights.

"DNS exfiltration suspicion" → Route 53 Resolver query logs

When the question mentions DNS tunneling, command-and-control, or unusually long subdomain queries, you want Route 53 Resolver query logs, often correlated with GuardDuty's Backdoor:EC2/C&CActivity.B!DNS finding.

"I need raw packet capture for forensics" → Traffic Mirroring

When the question explicitly asks for packet capture (PCAP), or mentions L4–L7 inspection beyond what flow logs reveal, the answer is VPC Traffic Mirroring to an NLB-fronted security appliance or another ENI.

TCP/IP Fundamentals Every SCS-C02 Candidate Must Refresh

You cannot do network security troubleshooting without TCP/IP basics. SCS-C02 question stems often hinge on whether you remember that NACLs are stateless and need ephemeral port ranges, or that path MTU discovery requires ICMP type 3 code 4 to traverse the firewall.

TCP vs UDP and Stateful vs Stateless

TCP is connection-oriented (three-way handshake SYN → SYN/ACK → ACK, sequence numbers, retransmissions). UDP is connectionless and has no acknowledgment. Security groups are stateful — return traffic is automatically allowed even without an explicit outbound rule. NACLs are stateless — both directions must be allowed, including the ephemeral port range on the response side. This single distinction is the cause of more SCS-C02 wrong answers than any other Layer 4 detail.

Ephemeral Ports — the NACL Trap

When a client at IP 10.0.1.5 opens a TCP connection to a server on :443, the OS picks an ephemeral source port from a range — Linux 32768–60999, Windows 49152–65535, AWS NLB 1024–65535. The server's reply travels back to that ephemeral port. If the NACL on the server's subnet only allows outbound to :80/:443 and not the ephemeral port range, the response is silently dropped and the client sees a TCP timeout. SCS-C02 loves this trap.

OSI Model Quick Reference for the Exam

• L3 (Network) — IP, route tables, NACLs, network ACLs
• L4 (Transport) — TCP/UDP, security groups, AWS Network Firewall stateless rules
• L7 (Application) — HTTP, AWS WAF, AWS Network Firewall stateful Suricata rules, Application Load Balancer

MTU and Path MTU Discovery

The default MTU inside a VPC is 1500 bytes; jumbo frames (9001) work within a placement group or single subnet but not across VPC peering or transit gateway. When fragments are dropped silently, applications see hangs at exactly 1500 bytes of payload — classic symptom of an over-aggressive NACL or AWS Network Firewall rule that drops ICMP Destination Unreachable / Fragmentation Needed. The fix is to allow ICMP type 3 code 4 explicitly.

VPC Reachability Analyzer Deep Dive

VPC Reachability Analyzer is the surgical tool of network security troubleshooting. Given a source resource, a destination resource, an optional protocol (TCP or UDP), and an optional destination port, it traces the entire path through your VPC's data plane and tells you whether the packet would be delivered.

Supported Sources and Destinations

Sources: instance, ENI, internet gateway, VPC endpoint (interface or gateway), TGW attachment, VPN gateway. Destinations: same set plus IP address inside the VPC. Cross-account, cross-VPC, cross-region (since 2022) are supported when both accounts are in the same AWS Organization.

What the Analyzer Evaluates

For each hop, Reachability Analyzer evaluates: source security group egress, source subnet route table, source NACL outbound, intervening peering/TGW route table, destination NACL inbound, destination security group ingress, destination route table for return path. If the path fails, the response includes the explanation type (SECURITY_GROUP_NO_RULE, NACL_NO_RULE, NO_ROUTE, BLACKHOLE_ROUTE, etc.) and the exact resource ID that blocks.

What Reachability Analyzer Does NOT Evaluate

This is heavily exam-tested. Reachability Analyzer is a control-plane simulator. It does not test:

• Application-level reachability (the app could be down even though the network path is open)
• DNS resolution (it works on IP, not on hostname)
• AWS Network Firewall stateful rules (it evaluates stateless rules but only flags stateful as "may be blocked")
• WAF rules
• Operating-system firewalls (iptables, Windows Firewall)

Pricing and Run Cadence

Each path analysis costs $0.10. You can save paths and re-run them on schedule via Lambda or EventBridge for continuous compliance — useful for proving "the database tier is unreachable from the internet" before each deployment.

Network Access Analyzer for Set-to-Set Exposure

AWS Network Access Analyzer is the scope-based sibling of Reachability Analyzer. Where Reachability Analyzer answers "does path A→B work?", Network Access Analyzer answers "across my entire account, what paths exist that match my Network Access Scope definition?"

Network Access Scope JSON

A scope is a JSON document with MatchPaths (paths you want to find) and ExcludePaths (paths you accept). Example: "find every path from any internet gateway to any EC2 in the prod-data VPC on TCP/3306, except those terminating at the bastion ENI." The analyzer crawls every SG, NACL, route table, peering, TGW route, VPC endpoint, and PrivateLink connection and lists every actual path that matches.

AWS-Provided Sample Scopes

AWS ships several pre-built scopes covering common audit questions: "All paths from internet to VPC", "All paths from VPC to internet (potential data exfil)", "All paths between trusted and untrusted VPCs". Most SCS-C02 scenarios about "unintended internet exposure" map to the AWS-provided "Internet to VPC" scope — knowing this saves time on the exam.

Cost and Cadence

Network Access Analyzer is priced per ENI analyzed per analysis run ($0.002 per ENI). Run it weekly via EventBridge as part of compliance reporting; results integrate with Security Hub via custom integrations.

Inspector Network Reachability — Compute Plus Network

Amazon Inspector v2's network reachability rule package is unique because it merges OS-level information (which ports the instance is actually listening on) with VPC-level reachability (whether those ports are reachable from the internet, from peered VPCs, or only from the same subnet).

How Inspector Network Reachability Works

Inspector reads the instance's netstat-equivalent state via SSM, identifies listening ports, and then traces the VPC reachability for each one. Findings have severity tied to exposure level — "port 22 reachable from 0.0.0.0/0" is HIGH, "port 22 reachable from peered VPC" is MEDIUM, "port 22 reachable only from same subnet" is INFORMATIONAL (or no finding).

When to Use Inspector vs Reachability Analyzer

Use Inspector when the question is "tell me which of my fleet of EC2 instances are exposed and on which ports" — Inspector scans your entire fleet continuously. Use Reachability Analyzer when you have a specific suspect path and want to know why it works or fails. The two are complementary: Inspector tells you what is exposed, Reachability Analyzer tells you why.

Findings to Security Hub

All Inspector findings flow into Security Hub via ASFF, so a single EventBridge rule can route Severity.Label = HIGH Inspector network reachability findings into a containment runbook (for example, attach a quarantine SG via SSM Automation).

VPC Flow Logs — The Forensic Workhorse

VPC Flow Logs capture metadata about IP traffic going to and from network interfaces in a VPC. They are the single most important log source for network security troubleshooting that involves intermittent or partial failures.

Format and Versions

Flow Logs come in v2 (default), v3, v4, v5 (latest). v5 adds the critical fields pkt-srcaddr, pkt-dstaddr, traffic-path, and flow-direction which let you distinguish "the packet entered the ENI from the internet" from "the packet entered from a peered VPC". For SCS-C02 troubleshooting, always enable v5 with custom format and include tcp-flags to see SYN-only floods vs full handshakes.

REJECT vs ACCEPT Decoding

The action field is ACCEPT or REJECT. A REJECT can come from a security group, a NACL, or a route absence. To distinguish:

• ENI_SECURITY_GROUP_RULES_DENY (in v5 log-status field) — security group blocked
• NACL_RULES_DENY — NACL blocked (with stateless quirk: you may see the request go through but the response REJECTed, which is the ephemeral-port symptom)
• BLACKHOLE_ROUTE — destination's route table has no route, or has an explicit blackhole

A subtle pattern: if you see ACCEPT in one direction and no corresponding return packet, the return path is broken — usually a missing route in the destination's table or asymmetric routing through TGW.

Where to Send Flow Logs

Three destinations: CloudWatch Logs (good for real-time alarms), S3 (cheap long-term storage, query with Athena), Amazon Data Firehose (real-time stream to a SIEM). For SCS-C02, S3 + Athena is the cost-effective default for forensic queries; CloudWatch Logs Insights is for ad-hoc operational searches with sub-minute latency.

Athena Queries for Common Investigations

SELECT srcaddr, dstaddr, dstport, action, COUNT(*) AS hits
FROM vpcflow
WHERE action = 'REJECT' AND dstport IN (22, 3389)
  AND day BETWEEN '2026/04/20' AND '2026/04/25'
GROUP BY srcaddr, dstaddr, dstport, action
ORDER BY hits DESC LIMIT 50;

This finds the top-50 rejected SSH/RDP probes — the bread-and-butter query of SCS-C02 incident triage.

What VPC Flow Logs Do NOT Capture

Critical for the exam: Flow Logs do not capture (a) traffic to and from the instance metadata service (169.254.169.254), (b) DHCP traffic, (c) traffic to the Amazon DNS server, (d) traffic to a Windows license activation server, (e) traffic between ENIs in the same network interface. For DNS investigations, use Route 53 Resolver query logs. For IMDS abuse detection, use GuardDuty.

Traffic Mirroring for Packet Capture

VPC Traffic Mirroring duplicates network traffic from an ENI and sends it to a target ENI or NLB-fronted security appliance. It is the packet-level tool of network security troubleshooting — when Flow Logs do not give enough detail.

Filter and Session Model

A mirror filter is a set of stateless rules (protocol, source CIDR, destination CIDR, source port, destination port) describing which packets to mirror. A mirror session binds a source ENI, a target (ENI or NLB), a filter, and a session number for ordering. You can mirror inbound, outbound, or both directions, and the captured packets are encapsulated in VXLAN so the target sees the original headers intact.

Supported Source Instances

Traffic Mirroring is supported on Nitro-based EC2 instances (M5/M6/C5/C6/R5/R6/T3/T4 and similar). It is not supported on Xen-based older types (M3/M4/T2). Exam scenarios that say "the legacy fleet runs M4 instances" disqualify Traffic Mirroring as the answer.

Performance Impact

Mirroring traffic consumes ENI bandwidth — both source and destination. AWS recommends mirroring only a sample (e.g., one in ten flows) for high-throughput workloads. The mirror filter can target only specific ports (TLS handshake, suspicious destinations) to keep volume manageable.

Use Cases on SCS-C02

Three flagship use cases:

1. Forensic packet capture during an active incident — pair with a Suricata or Zeek IDS on an isolated VPC.
2. DLP inspection for unencrypted egress on specific ports.
3. Compliance demonstration — prove that traffic to a regulated workload is encrypted by capturing TLS handshakes and showing no plaintext.

Route 53 Resolver Query Logs for DNS Forensics

Route 53 Resolver query logs record every DNS query that VPC resources make through the Amazon Resolver (AmazonProvidedDNS or .2 resolver). They are essential for network security troubleshooting when the symptom is DNS-based — exfiltration via long subdomain queries, command-and-control beaconing, or domain typosquat traffic.

Log Destination and Format

Resolver query logs go to CloudWatch Logs, S3, or Data Firehose. Each record contains the source ENI, source VPC, query name (FQDN), query type (A, AAAA, TXT, etc.), response code (NOERROR, NXDOMAIN, SERVFAIL), and the resolver endpoint that answered. Pair the logs with GuardDuty's DNS-based findings like Backdoor:EC2/C&CActivity.B!DNS and Trojan:EC2/DNSDataExfiltration for high-fidelity detection.

Cross-Account Aggregation

Configure Resolver query logging at the AWS Organizations level and ship to a central S3 bucket; then query with Athena. SCS-C02 explicitly tests organization-wide log aggregation patterns.

What Resolver Query Logs Do NOT See

• Queries that bypass the Amazon Resolver (instances configured with public DNS like 8.8.8.8 directly)
• Queries to a DNS server inside another VPC over peering without using the Resolver

For exam scenarios with bypassed DNS, the answer is to enforce the Amazon Resolver via outbound DNS firewall rules (Route 53 Resolver DNS Firewall) blocking egress on TCP/UDP 53 to non-AWS resolvers.

WAF Logs and Athena for Layer 7 Investigations

AWS WAF logs capture every Web ACL evaluation: which rule matched, which action was taken (ALLOW, BLOCK, COUNT, CAPTCHA, CHALLENGE), the request URI, headers, and the matching rule ID. They are the L7 counterpart to Flow Logs.

Logging Destinations

WAF can ship logs to CloudWatch Logs, S3, or Amazon Data Firehose. For long-term archival and Athena queries, S3 is the canonical pattern. CloudWatch Logs Insights is appropriate for the past few hours of data when investigating an ongoing attack.

Athena Query Patterns

A typical SCS-C02 scenario asks you to identify the top source IPs of blocked SQLi attempts during a window:

SELECT httprequest.clientip AS ip, COUNT(*) AS blocks
FROM waf_logs
WHERE action = 'BLOCK'
  AND terminatingruleid LIKE '%SQLi%'
  AND from_unixtime(timestamp/1000) >= TIMESTAMP '2026-04-25 00:00:00'
GROUP BY httprequest.clientip
ORDER BY blocks DESC LIMIT 10;

Correlating WAF, Flow Logs, and CloudFront Logs

Layer-7 attacks often have L3/L4 fingerprints. A scenario where WAF blocks 99 percent of the SQLi attempts but the remaining 1 percent succeed might require correlating WAF logs (attack patterns), CloudFront access logs (cache and origin behavior), and ALB access logs (origin response codes). SCS-C02 sometimes asks "the team needs to confirm whether any SQLi reached origin" — the answer correlates all three log sources.

CloudWatch Logs Insights — The Operational Companion

CloudWatch Logs Insights lets you run ad-hoc queries on CloudWatch Logs with a purpose-built query language. It is the fast option (sub-minute) when Flow Logs, WAF logs, or Resolver logs are streaming to CloudWatch Logs and you need an answer in the next thirty seconds.

Common Insights Queries for Network Security Troubleshooting

A canonical query for finding rejected SSH attempts in the last hour:

fields @timestamp, srcaddr, dstaddr, dstport, action
| filter dstport = 22 and action = "REJECT"
| stats count() as hits by srcaddr
| sort hits desc
| limit 20

When to Pick Insights vs Athena

Insights is interactive and indexed; Athena is cheaper for cold long-term S3 data. Use Insights for the past 24-72 hours of investigation, Athena for older data and for joining multiple log sources. SCS-C02 questions about cost-optimal long-term forensic queries always answer Athena.

Common SCS-C02 Network Security Troubleshooting Traps

Here are the four canonical traps that derail unprepared candidates.

Trap 1 — SG Cross-Reference Doesn't Cross VPC Peering Without DNS

Security groups in VPC A can reference security groups in VPC B over peering only if (a) both VPCs are peered, and (b) DNS resolution is enabled on the peering connection. If DNS resolution is off, the SG reference resolves to nothing and traffic is silently denied. Reachability Analyzer will catch this; manually inspecting SGs may not.

Trap 2 — NACL Ephemeral Port Deny

Discussed under TCP/IP fundamentals above. The classic symptom: an outbound TCP request to :443 succeeds, but the response is silently dropped because the inbound NACL on the same subnet does not permit the ephemeral port range 1024-65535.

Trap 3 — Route Table Missing Return Path

Asymmetric routing across TGW or VPC peering. The forward path is fine but the destination subnet's route table sends return traffic to the internet gateway instead of back through the TGW. Flow Logs show ACCEPT in one direction and nothing in the other.

Trap 4 — Reachability Analyzer Missing AWS Network Firewall Stateful Rules

Reachability Analyzer evaluates Network Firewall stateless rules but cannot fully evaluate stateful Suricata rules. If your path goes through a Network Firewall stateful rule group with drop rules on specific TLS SNI patterns, Reachability Analyzer will mark the path as "may be reachable" and you will need Flow Logs or Network Firewall logs to confirm.

End-to-End Worked Example — "Lambda Cannot Reach RDS"

Let me walk through a canonical SCS-C02 troubleshooting flow to cement the decision tree.

Symptom. A Lambda function in private subnet subnet-A cannot connect to an RDS for PostgreSQL in private subnet subnet-B of the same VPC. The Lambda CloudWatch Logs show connection timed out after 30 seconds.

Step 1 — Run VPC Reachability Analyzer. Source = Lambda's ENI (find via aws lambda get-function), destination = RDS endpoint ENI, protocol = TCP, port = 5432. Reachability Analyzer returns "Not reachable" with explanation ACL_RULE_NO_MATCH on the inbound NACL of subnet-B. Done — you have the root cause without touching a single packet.

Step 2 — Validate with VPC Flow Logs. To confirm, query Flow Logs for the source ENI:

fields @timestamp, srcaddr, dstaddr, dstport, action
| filter dstaddr like /10.0.2./ and dstport = 5432
| sort @timestamp desc

You see REJECT records with no corresponding ACCEPT. This confirms the NACL is blocking; the next step is fixing the NACL inbound rule for subnet-B.

Step 3 — Re-run Reachability Analyzer. After fixing, re-run. The verdict flips to "Reachable" with the full forwarding path listed.

Why this matters for the exam. SCS-C02 questions sometimes give you intermediate evidence ("Flow Logs show REJECT") and ask "what next?" The answer is Reachability Analyzer to pinpoint the rule, not "manually inspect every NACL." Time-to-root-cause is the win condition.

Putting It Together — The Network Security Troubleshooting Playbook

A complete network security troubleshooting playbook for an SCS-C02 candidate:

1. Read the symptom and pick the tool using the decision tree (Reachability Analyzer, Network Access Analyzer, Inspector, Flow Logs, WAF logs, Resolver logs, or Traffic Mirroring).
2. Confirm with telemetry — Flow Logs, WAF logs, or Resolver logs for whichever layer is at issue.
3. Apply TCP/IP fundamentals — check NACL ephemeral port ranges, return-path routing, MTU/PMTUD on jumbo frames.
4. Use Inspector for fleet-wide reachability — never inspect 200 instances by hand; let Inspector + Security Hub aggregate.
5. Capture packets only when needed — Traffic Mirroring is precise but expensive; reserve for active incidents and DLP.
6. Automate the playbook — wire the analyzers' outputs through EventBridge to Security Hub findings, then to remediation runbooks (e.g., quarantine SG via SSM Automation).

The recurring theme is let AWS native analyzers do the heavy lifting and reserve manual inspection for genuine edge cases the analyzers cannot evaluate (stateful firewall rules, OS firewalls, application listeners). Candidates who default to manual describe-* chains in answers consistently score lower than candidates who pick the right analyzer.

FAQ — Network Security Troubleshooting

Q1: When should I pick VPC Reachability Analyzer over manually checking security groups and NACLs?

Always pick VPC Reachability Analyzer for any path-specific question. It evaluates SGs, NACLs, route tables, peering, TGW routes, VPC endpoints, and Network Firewall stateless rules in one call, returning the exact blocking element. Manual inspection is error-prone and slow; the analyzer costs $0.10 per analysis. SCS-C02 wrong answers often offer manual inspection — recognize it as a distractor.

Q2: How do VPC Reachability Analyzer and Network Access Analyzer differ?

Reachability Analyzer answers "does path A→B work?" — one source, one destination, returns reachable/not reachable with full path. Network Access Analyzer answers "across my account, what paths exist that match my Network Access Scope JSON?" — it crawls every potential path and lists violations. Use Reachability Analyzer for incident response, Network Access Analyzer for periodic compliance audits ("nothing in prod is reachable from internet on TCP/22").

Q3: Why does Inspector say my EC2 is reachable on port 22 even after I patched it?

Inspector's network reachability rule checks whether a network path from the internet exists, regardless of whether the OS service is patched. Patching closes a CVE; it does not close the network path. Use VPC Reachability Analyzer between the internet gateway and the instance ENI to find the SG rule or route allowing the path, then close the path. Inspector and Reachability Analyzer are complementary.

Q4: My VPC Flow Logs show ACCEPT but the application connection still times out. Why?

ACCEPT in Flow Logs means the L3/L4 packet was allowed by SGs and NACLs. It does not mean the application listener accepted it. Possible causes: (1) the OS firewall (iptables, Windows Firewall) drops it; (2) the application is not listening on that port; (3) AWS Network Firewall stateful rule drops the TLS SNI; (4) an ALB target group health check is failing and the target is unhealthy. Investigate at the OS and application layer next, not at the VPC layer.

Q5: Do VPC Flow Logs capture traffic to the EC2 instance metadata service?

No. Flow Logs do not record traffic to 169.254.169.254, the Amazon DNS server, DHCP, or Windows license activation. To detect IMDS abuse, rely on GuardDuty (which generates UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS when the role's credentials are reused outside AWS). Enforce IMDSv2 (token-based) via launch templates and SCPs to prevent the abuse upfront.

Q6: When should I use Traffic Mirroring instead of VPC Flow Logs?

Use Traffic Mirroring when you need raw packet content — deep packet inspection, DLP, IDS analysis, TLS handshake forensics. Use VPC Flow Logs when you only need flow metadata (5-tuple, action, byte/packet counts). Traffic Mirroring is much more expensive and bandwidth-intensive; reserve it for active investigations or compliance use cases that explicitly require packet-level evidence.

Q7: My NACL allows outbound TCP/443 but inbound responses are blocked. What is happening?

This is the NACL ephemeral port trap. NACLs are stateless — the response from the destination on TCP/443 arrives at your client on an ephemeral source port (Linux 32768–60999, Windows 49152–65535). Your inbound NACL must allow that ephemeral port range. The fix is to allow inbound TCP 1024-65535 from the destination CIDR. Security groups, being stateful, do not have this problem.

Q8: How do I detect DNS exfiltration from a compromised EC2?

Enable Route 53 Resolver query logging and ship logs to a central S3 bucket. Pair with GuardDuty, which generates Trojan:EC2/DNSDataExfiltration and Backdoor:EC2/C&CActivity.B!DNS findings on suspicious DNS patterns (long subdomains, known C2 domains, beaconing intervals). Also deploy Route 53 Resolver DNS Firewall with managed domain lists to block outbound queries to malicious domains. Block outbound TCP/UDP 53 to anywhere except the Amazon Resolver to prevent attackers from bypassing your DNS visibility.

Q9: What is the right architecture for forensic packet capture in a multi-account environment?

Configure VPC Traffic Mirroring sessions on suspect ENIs in the source account, with the mirror target as a Network Load Balancer in a dedicated forensic VPC (often in the security tooling account or a separate forensics account). Behind the NLB, run an Auto Scaling Group of Suricata or Zeek sensors that write PCAPs to an S3 bucket with Object Lock in compliance mode for chain-of-custody. Cross-account is achieved via VPC peering or PrivateLink to the NLB.

Q10: How do I prove to an auditor that nothing in my production VPC is reachable from the internet on a sensitive port?

Use AWS Network Access Analyzer with a Network Access Scope that matches MatchPaths: any internet gateway → any ENI in production VPC → port 3306 and ExcludePaths: []. Run the analyzer weekly via EventBridge schedule, ship findings to Security Hub, and store the empty-finding evidence in S3 with Object Lock. The auditor sees a continuous record of zero unintended exposure. SCS-C02 frequently tests this exact pattern.

Summary

The SCS-C02 network security troubleshooting and reachability analysis skill set is a small but precise toolkit: three analyzers (Reachability Analyzer for one path, Network Access Analyzer for set-to-set scopes, Inspector for compute plus path), three log streams (VPC Flow Logs for L3/L4, WAF logs for L7, Route 53 Resolver query logs for DNS), one packet-capture mechanism (Traffic Mirroring), and two query surfaces (CloudWatch Logs Insights for fast operational queries, Athena for cheap long-term forensics). Master the symptom-to-tool decision tree, the TCP/IP fundamentals (especially NACL ephemeral ports and stateful vs stateless), and the four common traps (peering DNS resolution, NACL ephemerals, return-path routing, stateful firewall blind spots), and Task 3.4 questions become mechanical. Always favor native analyzers over manual inspection, validate analyzer verdicts with Flow Logs telemetry, and store forensic evidence with Object Lock for chain-of-custody. Network security troubleshooting is where every other Domain 3 design decision finally gets stress-tested — and where SCS-C02 separates engineers from architects-on-paper.