AWS network troubleshooting is easier when the question is classified before a tool is opened. VPC Flow Logs provide metadata about observed IP flows. Reachability Analyzer evaluates whether AWS configuration permits a path. CloudWatch network-monitoring features measure performance and availability over time. Other tools, such as Network Access Analyzer and traffic mirroring, answer broader policy or packet-level questions.<\/p>\n
The current AWS Certified CloudOps Engineer – Associate<\/a> exam includes networking, monitoring, analysis, and troubleshooting, so operators should know which evidence type to collect first. A sound AWS VPC<\/a> model is the foundation: subnets, route tables, security groups, network ACLs, gateways, endpoints, and network interfaces determine the paths that the diagnostic tools are observing or analyzing.<\/p>\n A VPC Flow Log can be enabled for a VPC, subnet, or network interface. At the VPC or subnet scope, AWS records flows for the network interfaces within that scope. The flow log can capture accepted traffic, rejected traffic, or both, and publish records to destinations such as CloudWatch Logs, Amazon S3, or Amazon Data Firehose.<\/p>\n A record can include source and destination addresses, source and destination ports, protocol, interface identifiers, packet and byte counts, timestamps, traffic direction, action, and additional optional metadata. Custom log formats let teams include the fields that are useful for their analytics and troubleshooting process.<\/p>\n Flow Logs are useful when the question is \u201cDid the network interface observe a flow that matches this conversation?\u201d They provide evidence that can be queried at scale without requiring a packet capture on every host.<\/p>\n An That means a An VPC Flow Logs are not packet captures and do not contain application payload. They aggregate metadata over a capture interval and are published after processing, so they are not a live wire-level trace. Depending on configuration, the maximum aggregation interval can be one minute or ten minutes, and delivery to the selected destination takes additional time.<\/p>\n This affects incident analysis. If an operator checks immediately after one failed connection and sees no record yet, that absence is not enough to conclude that no traffic occurred. Time windows should include the capture and publication delay.<\/p>\n Flow Logs also have documented exclusions and special cases, so they should not be treated as a complete record of every packet in every AWS network path. When payload, flags, retransmissions, or application protocol details are required, a different diagnostic method may be necessary.<\/p>\n Reachability Analyzer performs static analysis of the AWS network configuration between a selected source and destination. It does not transmit test packets. Instead, it models supported components such as routes, security groups, network ACLs, gateways, peering relationships, transit components, and endpoints to determine whether the configured path should be reachable.<\/p>\n If the path is reachable, the analysis shows the modeled path through the supported resources. If the path is not reachable, it identifies the blocking component or configuration condition. This makes it valuable when a complex VPC would otherwise require manually opening several route tables and security objects.<\/p>\n Use it when the question is \u201cDoes AWS configuration allow traffic from this source to this destination on this protocol and port?\u201d That is different from asking whether the application is healthy or whether packets are being lost at runtime.<\/p>\n A path can be configuration-reachable while the connection still fails. The destination process may be stopped, an operating-system firewall may block the port, DNS may resolve to the wrong address, a certificate may be invalid, or an application dependency may be overloaded. Reachability Analyzer does not execute the application conversation.<\/p>\n The opposite distinction also matters. Flow Logs can show traffic attempts and their VPC-level action, but they do not explain every route and policy that created the path. A configuration analysis can reveal a wrong route or security relationship before the operator spends time searching traffic records.<\/p>\n A good troubleshooting sequence often begins with Reachability Analyzer when the architecture itself is in doubt, then uses observed traffic evidence to confirm what actually happened during the failure. When the path crosses subnets, inspect both directions: stateful security groups automatically allow response traffic for an established flow, while stateless network ACLs need matching rules for the return path. Route-table asymmetry can also break a conversation even when the forward path looks correct.<\/p>\n CloudWatch Network Flow Monitor provides near-real-time network performance visibility for actual TCP flows from workloads that run the required agents. It can surface metrics such as packet loss, latency, retransmissions, and data transfer, and can help attribute whether an underlying AWS network health issue is associated with the monitored flow.<\/p>\n This solves a different problem from Reachability Analyzer. A route can be completely valid while users experience intermittent latency or packet loss. Network Flow Monitor helps investigate the quality of the runtime path, not merely whether the configuration makes a connection possible.<\/p>\n CloudWatch also includes other network-monitoring capabilities, such as Internet Monitor for internet-facing user experience and Network Synthetic Monitor for synthetic network measurements. Choose the monitor that matches the traffic domain being investigated rather than treating \u201cCloudWatch networking\u201d as one feature.<\/p>\n Reachability Analyzer is point-to-point: choose a source and destination and analyze that path. Network Access Analyzer answers a broader governance question. A Network Access Scope defines patterns of network access that should be found or excluded, and the service statically analyzes the account and Region to produce findings for matching paths.<\/p>\n This is useful for questions such as \u201cWhich resources can reach the internet?\u201d or \u201cAre there network paths into a sensitive subnet that violate our intended segmentation?\u201d The analysis uses automated reasoning over supported AWS configuration; it does not send traffic and therefore cannot detect transient packet loss or service outages.<\/p>\n Network Access Analyzer is especially useful before and after network changes because it can validate a policy at scale. It complements, rather than replaces, the point troubleshooting performed with Reachability Analyzer.<\/p>\n Sometimes the operator needs packet headers and payload details rather than flow summaries. VPC Traffic Mirroring can copy traffic from supported elastic network interfaces to analysis appliances or services. Host-based tools such as Packet capture is powerful but expensive to interpret at scale. Start with the least invasive evidence that can answer the question. If Reachability Analyzer reveals a missing route, a packet capture is unnecessary. If Flow Logs show Security and privacy controls matter as well. Mirrored traffic can contain sensitive application data, so capture scope, destination access, retention, and encryption should be governed deliberately.<\/p>\n A disciplined workflow can move upward through the stack. First verify DNS and endpoint selection when name resolution is involved. Use Reachability Analyzer for the configured AWS path. Check Flow Logs for observed accepted or rejected traffic. Use Network Flow Monitor or other CloudWatch monitoring when loss and latency are suspected. Then inspect host firewalls, socket listeners, TLS, application logs, and downstream dependencies.<\/p>\nUse VPC Flow Logs for observed flow metadata<\/h2>\n
Interpret ACCEPT and REJECT carefully<\/h2>\n
ACCEPT<\/code> action indicates that the recorded traffic was accepted by the relevant VPC networking controls represented by the log. A REJECT<\/code> indicates that traffic was rejected; common examples include security-group or network-ACL decisions, although AWS also documents cases such as packets arriving after a connection was closed.<\/p>\nREJECT<\/code> record is a strong clue, not a complete root-cause statement. Correlate the interface, direction, address, port, protocol, security groups, and network ACLs. Remember that security groups are stateful while network ACLs are stateless, so return traffic can behave differently when ACL rules are incomplete.<\/p>\nACCEPT<\/code> record also does not prove the application worked. It proves the VPC networking layer accepted that flow. The process might not be listening, TLS may fail, the application might reject the request, or a downstream dependency may be unhealthy.<\/p>\nKnow the limits and timing of Flow Logs<\/h2>\n
Use Reachability Analyzer for point-to-point configuration analysis<\/h2>\n
Separate configured reachability from runtime health<\/h2>\n
Use Network Flow Monitor for performance of real workload traffic<\/h2>\n
Use Network Access Analyzer for broader policy questions<\/h2>\n
Move to packet-level evidence only when metadata is insufficient<\/h2>\n
tcpdump<\/code> can also capture packets locally when access and operating conditions permit.<\/p>\nACCEPT<\/code> but the TLS handshake repeatedly fails, packet-level or application-level diagnostics may become appropriate.<\/p>\nBuild a troubleshooting chain from configuration to application<\/h2>\n