An application accepts HTTPS traffic, its security group allows port 443, and the connection still times out. Before adding another allow rule, draw the complete conversation. Which interface receives the request? Which subnet boundary does it cross? What destination port does the response use? Those questions make the difference between a useful diagnosis and an increasingly permissive firewall.
Security groups and network access control lists both filter traffic, but they do not evaluate it in the same way. This guide uses a simplified TCP conversation to separate their responsibilities. It is a study example, not a recommendation to copy these ports or addresses into production.
Compare the controls before writing rules
| Decision | Security group | Network ACL |
|---|---|---|
| Where it applies | Associated resources and network interfaces | Traffic entering or leaving an associated subnet |
| Rule actions | Allow rules | Allow and deny rules |
| Return traffic | Stateful: tracked response traffic is allowed | Stateless: responses need their own matching permission |
| Evaluation | Applicable allow rules are combined | Lowest numbered matching rule decides |
A security group is not a subnet-wide firewall. Start by identifying the groups actually associated with the resource. When multiple groups apply, their permissions combine; attaching a restrictive group does not cancel an allow in another group. A new custom group starts with no inbound permissions and an allow-all outbound rule. Do not confuse that with the separate behavior of a VPC's default security group.
Trace an HTTPS request and its response
Imagine a client that selects TCP source port 51514 and connects to a server on destination port 443. On the way back, the server uses source port 443 and destination port 51514. Write both directions before looking at the rules:
Request: client:51514 -> server:443
Response: server:443 -> client:51514For a tracked connection accepted by the server's security group, the response is allowed by its stateful behavior. You do not normally add an outbound security-group rule for the client's ephemeral port merely to permit that response. This does not imply that an unrelated new connection from the server is allowed.
At the server subnet's network ACL, inspect inbound permission for the request and outbound permission for the response. An outbound rule permitting only destination port 443 does not describe the response shown above. The actual ephemeral-port range depends on the client and platform. Port 51514 is an illustrative choice, not a universal range to configure.
Find the first matching ACL rule
Consider an inbound ACL with rule 100 denying traffic from a particular source range and rule 200 allowing HTTPS from a broader range. If a packet matches rule 100, the later allow does not rescue it. Read the rules in numerical order, and evaluate outbound rules separately. Unmatched traffic reaches the final deny rule.
Make a short worksheet for each direction: source, destination, protocol, destination port, matching rule number, and result. This is more useful than asking whether the ACL has an HTTPS rule. If the worksheet says allow but the connection fails, inspect another part of the path rather than assuming the worksheet proves end-to-end connectivity.
Troubleshoot one boundary at a time
- Record the exact client, server, protocol, port, and observed symptom. A timeout and an application error are different evidence.
- Confirm the server's network interface and associated security groups. Check all applicable allows, not just the group with the most familiar name.
- Identify the subnet's associated ACL and trace both directions through its numbered rules.
- Check routing, the intended endpoint, and whether the application is listening. Firewall permission alone does not establish that the complete path works.
- Change only the control supported by the evidence, then repeat the same test and record the result.
Avoid opening every port as a permanent troubleshooting shortcut. It can hide the original cause and leave unnecessary exposure. If a controlled diagnostic change is approved, define its scope and rollback before making it.
Practice decisions instead of memorizing slogans
- Two security groups apply, and one allows the traffic: explain why the other group's absence of that rule is not a deny.
- HTTPS requests enter a subnet but the responses are blocked: use the destination port on the response to investigate the outbound ACL.
- A lower-numbered deny overlaps a later allow: identify the matching rule instead of choosing the most specific-looking description.
Use the AWS Solutions Architect study guide to place these decisions in a wider architecture study plan. For a different authorization layer, read the AWS IAM AccessDenied checklist. A network timeout and an IAM denial should not trigger the same investigation.