A method for cloud connectivity faults

Why this matters

There is no cable to check. When a packet does not arrive in a cloud, it was stopped by a logical object, and there are only a handful of candidates. That is genuinely good news: connectivity troubleshooting in a cloud is more tractable than on physical infrastructure, provided you work the list rather than guessing.

The reason people find it hard is that all the failures look identical from the client. A security group denial, a missing route, a stopped service and a name-resolution failure can all present as "it hangs" or "connection refused", and guessing between them wastes time. A method separates them quickly.

The lesson

Working the layers deliberately instead of guessing, and writing down what you ruled out

Use a structured approach. Which structure matters less than having one, but the classic troubleshooting method is worth following because the exam is built on it:

1. Identify the problem. What exactly fails, from where, to where, on which port? "The application is down" is not actionable; "instances in subnet A cannot reach the database on port 5432, and instances in subnet B can" is nearly solved already.
2. Establish a theory of probable cause. Start with what changed.
3. Test the theory, with the cheapest test that distinguishes it from the alternatives.
4. Establish a plan of action, considering the effect on everything else.
5. Implement or escalate.
6. Verify full system functionality, and put preventive measures in place.
7. Document findings, actions and outcomes.

Three practices that make this work in a cloud:

• Establish the scope precisely. Does it fail from everywhere or from one subnet? For everyone or one user? Always or intermittently? Since a known time? Each answer eliminates whole categories: a fault affecting one zone is not a security group rule that applies to all of them.
• Ask what changed (objective 3.3). The platform's audit log records every configuration change with a timestamp. Correlating the failure's start against that log is frequently the entire diagnosis.
• Write down what you have ruled out, with the evidence. In a long incident, with several people, the single biggest waste is two engineers testing the same thing an hour apart because nobody recorded the first result.

The four places a cloud packet dies: route table, security group, NACL, host firewall

This is the checklist, and it is the most useful thing in the lesson.

For traffic to flow between two endpoints, every one of these must permit it, in both directions:

1. Route table. Is there a route from the source subnet to the destination, and a route back? Missing return routes are a classic asymmetric failure.
2. Network ACL on both subnets. Stateless — so it needs an inbound rule and an outbound rule, and the return traffic uses ephemeral ports. Forgetting the ephemeral range is the most common NACL fault, and it produces a connection that hangs rather than refuses.
3. Security group on both endpoints. Stateful, so return traffic is automatic; check the destination's inbound rule and the source's outbound rule. Use group-to-group references rather than addresses where possible (objective 4.5).
4. Host firewall inside the guest. Frequently forgotten, because three cloud layers were checked and the operating system's own firewall was not.
5. And the fifth that is not a filter: is the service actually listening? On the right interface and the right port. A service bound to loopback only is unreachable no matter how correct the network is.

Beyond those, in a containerised environment add network policy (objective 4.3), which is invisible to every cloud-level check and blocks traffic that all four layers permit.

Learn to read the symptom, because it narrows the list immediately:

• Connection times out / hangs → traffic is being dropped silently. A security group, a NACL, a missing route, or a firewall configured to drop.
• Connection refused → the packet arrived and nothing was listening, or the host actively rejected it. The network is fine; look at the service.
• Name not resolved → DNS, which is objective 6.4 and a different problem entirely.
• Intermittent failure → one member of a pool is misconfigured, or one zone differs, or an asymmetric path exists.

That first distinction — timeout means blocked, refused means reached — is worth more than any tool.

Reachability analysers and flow logs, and reading a REJECT record correctly

Two cloud capabilities that make this far easier than the equivalent physical task.

Reachability analysers. Provider tools that take a source and a destination and evaluate the entire configured path — routes, gateways, security groups, NACLs, peering — reporting whether traffic can flow and, if not, which object blocks it. They do this statically, without sending a packet, so they work before a workload exists and cannot be confused by an application-layer problem. When available, this is the fastest possible answer to a connectivity question and should be the first thing tried.

Flow logs. Records of traffic accepted and rejected at the network interface, subnet or virtual network level. They are the evidence for what actually happened.

Reading them correctly is a genuine skill:

• A REJECT record tells you a packet arrived at that interface and was denied. That is more informative than it first appears: it proves the packet was routed correctly and reached the destination, so the fault is a security group or NACL and not a routing problem.
• No record at all is the other strong signal: the packet never arrived, so the fault is upstream — routing, a gateway, or a filter earlier in the path.
• ACCEPT records with no application response means the network delivered it and the problem is the service, not the path.
• Check both directions. An ACCEPT inbound with no corresponding outbound flow points at an asymmetric routing or stateless-filter problem.

Flow logs record at the interface, so they cannot show you a packet dropped before reaching it — which is exactly the complementary case the reachability analyser covers. Used together they separate "blocked where" from "never got there".

Then the ordinary tools still apply inside the guest: testing a TCP connection to the specific port, checking what is listening, and tracing the path — with the caveat that many cloud networks suppress ICMP, so a failing ping or traceroute proves nothing.

Name resolution against connectivity, separated before you troubleshoot either

A specific discipline that saves a great deal of time: establish whether the name resolves before investigating whether the host is reachable.

They are different problems with different causes, and the client's error message often does not distinguish them clearly.

The two-step test:

1. Resolve the name and note the address returned.
2. Connect to the address directly, bypassing DNS.

The outcomes are decisive:

• Resolution fails → a DNS problem (objective 6.4). Stop looking at security groups.
• Resolution succeeds, connection to the address fails → a connectivity problem. Work the four-layer checklist.
• Both succeed but the application fails → an application, TLS or authentication problem, not a network one.
• Resolution succeeds but returns the WRONG address → the most interesting case, and a genuinely common cloud fault: a stale record, a split-horizon configuration serving the wrong view, or — importantly — a private endpoint whose DNS is not configured, so the client resolves the service's public address and the traffic goes out through the internet path (objective 1.3). Everything appears to work, more slowly and more expensively, which is why it survives so long.

Resolve from the same host that is failing, not from your laptop. Different hosts use different resolvers and may be in different DNS views, and a name that resolves correctly from your machine tells you nothing about the instance.

Asymmetric routing and the return path nobody checks

The failure that defeats people who have checked everything, because they checked it in one direction.

Asymmetric routing means traffic takes one path outbound and a different one back. Sometimes it works; often it does not, because something on the return path is stateful — a firewall, a NAT gateway, a load balancer — and sees a reply for a connection it never saw begin, so it drops it.

Where it arises in cloud networks:

• Two paths between the same networks — a VPN and a dedicated circuit both active, with routing preferring one direction each way.
• A peering and a transit gateway offering competing paths.
• Route table differences between subnets, so the return traffic from a different subnet takes a different exit.
• Multiple network interfaces on one instance, where the reply leaves through a different interface than the one the request arrived on — a genuinely common and confusing case.
• A misconfigured hybrid path, where on-premises routes cloud-bound traffic over the VPN and the cloud routes replies over a direct connection.

The signature: connections establish sometimes and not others; large transfers fail while small ones succeed; it works from one subnet and not another; and flow logs show the inbound packet accepted with no matching outbound flow, or an outbound flow with no matching return.

Diagnosis is to check the route tables on both sides for the specific prefixes and confirm that the reverse path is the mirror of the forward one. Remember that most-specific prefix wins, so a more specific route elsewhere can silently divert return traffic.

The general lesson, which applies to the whole objective: connectivity is bidirectional, and so is troubleshooting it. Every check in this lesson has a return-path counterpart, and the fault is in the half that was not examined more often than chance would suggest.

What to take into the exam

• Scope it precisely first — from where, to where, which port, since when — and check what changed in the audit log.
• The checklist, both directions: route table → NACL (stateless, ephemeral ports) → security group (stateful) → host firewall → is the service listening. Add network policy for containers.
• Timeout = dropped silently. Refused = reached, nothing listening.
• A REJECT flow-log record proves the packet arrived and was filtered — so it is not a routing problem. No record at all means it never arrived.
• Reachability analysers evaluate the whole configured path statically and name the blocking object.
• Separate name resolution from connectivity before troubleshooting either, and resolve from the affected host. Resolving to the wrong address is the private-endpoint DNS failure.
• Asymmetric routing breaks stateful devices: symptoms are intermittent connections and inbound flows with no matching return.