LEARN. PRACTICE. GROW.Write the diagnostic question
A tool helps only when the question identifies source, destination, address family, protocol, port and reference time. If the client fails over IPv6, an IPv4 result does not answer the question. Reachability Analyzer builds a configuration model and neither sends packets nor observes the data plane. Even on a dual-stack interface, it includes only IPv4. Use the model to identify configuration hypotheses, then confirm relevant behavior through appropriate evidence. In the ticket, separate what was analyzed, what was observed and what remains unconfirmed. This lets the next team continue without repeating analysis with different filters and comparing results that do not share the same scope.
Paths the model does not cover
For TCP through a TGW route table, Reachability Analyzer analyzes only forward traffic. A batch missing acknowledgements can still have a return-path problem. A path through a GWLB endpoint also excludes the load balancer and targets: that segment needs separate analysis. Network Firewall 5-tuple rules are supported, but that support does not validate domain lists or Suricata rules. Read informational messages and component limitations. If a filter requires an appliance and COMPONENT_FILTER_RESTRICTION appears, the conclusion concerns the filtered path. Removing the filter can help investigate a bypass, but it does not prove compliance with the inspection requirement you just removed from the analysis.
Interpret exposure findings
Network Access Analyzer seeks paths matching the defined scope; it is not a functional test of every service. Analysis is static, limited to IPv4 TCP/UDP and resources in the analyzed account and Region. Do not generalize to the entire organization, IPv6 or a Direct Connect circuit excluded from the model. Findings are unidirectional. The service also does not analyze Network Firewall rules and can report a path blocked by an effective rule. This permits neither automatic false-positive closure nor an intrusion declaration. Reconcile the path, applied policy version and a controlled test. Document gaps so the committee knows exactly which boundaries received evidence and which remain under investigation.
The Flow Logs contract
A Flow Log has scope, destination, filters, format and aggregation. It does not capture instance queries to the Amazon DNS server or every infrastructure traffic type. If you need the original destination when dstaddr represents the ENI primary IPv4 address, include pkt-dstaddr and retain context. Custom format has defined ordering and its version is the highest among selected fields. Do not assume default ordering in a parser for a different format. Changing fields of an existing Flow Log requires transition to a resource with the needed configuration; a new query cannot create historical information never collected. Test the consumer with new-format examples and confirm delivery before retiring the previous configuration.
Aggregation and timing precision
tcp-flags is a supported-flag bitmask, not a packet sequence. Value 3 can result from aggregated SYN and FIN and does not establish one packet carrying both. Zero can occur with ACK traffic lacking supported flags; it does not erase the packets count. Similarly, start and end have precision limits and are not individual capture timestamps. Distinguish flow time from destination delivery: typical publication times are not per-record guarantees. When logs are missing, inspect status and DeliverLogsErrorMessage. Access error points toward publishing permissions or trust. Avoid changing production routing merely because telemetry arrived late; first collect evidence connecting failure to the path you intend to change.
Acceptance and RUN handover
In a short window, prepare gates beforehand: expected configuration, per-family tests, return routing, effective policy, log delivery and functional outcome. A batch case may require recipient acknowledgement and duplication controls before retrying. Assign each gate an owner, deadline and evidence, and reserve time for rollback with validation. In handover, include applied filters, interface IDs, observed interval, tool limitations and any open hypothesis. Absence of findings only makes sense with known coverage. The report should support a defensible decision from available evidence, not turn every green signal into an availability promise. After the change, check that new resources remain included in the observation mechanisms and that the receiving team can reproduce the checks.
from functools import reduce
from operator import or_
def aggregate_supported_flags(observed):
# Inputs are already the supported values in this teaching model.
return reduce(or_, observed, 0)
assert aggregate_supported_flags([2, 1]) == 3
assert aggregate_supported_flags([1, 2]) == 3
assert aggregate_supported_flags([18, 1]) == 19
assert aggregate_supported_flags([0, 0, 0]) == 0
assert aggregate_supported_flags([2, 4]) == 6
print("five aggregation checks passed; packet order cannot be recovered")
The TCP path through TGW appears reachable, but the batch receives no acknowledgement. Analyze return routing, correlate a controlled attempt and respect the rollback deadline.
Common pitfalls
Extrapolating IPv4 to IPv6; confusing bitmasks with sequences; closing findings without testing the unmodeled control.
Related topics: Network Firewall inspection · Incidents and acceptance criteria
A conclusion is only as broad as the evidence supporting it.
Reference: How Reachability Analyzer works · ANS-C01