Skip to content

How would you prove which security group rule permits a request?

1 min read · main part only; folded sections are optional

After this you can answer: How would you prove which security group rule permits a request?

Start with the actual caller. Browser-to-ALB, ALB-to-API and API-to-Postgres are separate connections. A rule protecting one connection does not authorize the whole request chain.

The ALB reaches API containers on 4000 and web containers on 3000. Internal Service Connect traffic instead uses API proxy port 14000 from the web group, and web proxy port 13000 from the API group. Opening the application port to the wrong caller can both miss the real problem and widen access.

Security groups are stateful: replies to an allowed connection do not need a reverse inbound rule. The database and cache have no outbound rules here, yet replies work. I would inspect the groups attached to the running task’s network interface, rather than assume the intended group was attached. A timeout then points toward route, filtering or listener investigation; a PostgreSQL authentication error proves the connection reached the server.

Why reference a security group instead of a task IP?
Task addresses change on replacement. A source group follows the intended callers without granting the whole subnet access.
Would opening all ports be a good incident fix?
It hides the failed assumption and broadens access. First identify the exact missing source and port; review the smallest correction.
What if the rule is present but traffic still times out?
Check actual attachments, route tables, network ACLs and whether the destination listens on the expected address and port.

Read the path chapter, select the relevant map piece →, then inspect infra/src/security.ts → createSecurityGroups. Work through the related case for a diagnostic example.

Read this book online: https://book.theversehub.in/