How would you prove which security group rule permits a request?
After this you can answer: How would you prove which security group rule permits a request?
Say it in 30 seconds
Section titled “Say it in 30 seconds”The deeper answer
Section titled “The deeper answer”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.
Counter-questions
Section titled “Counter-questions”Why reference a security group instead of a task IP?
Would opening all ports be a good incident fix?
What if the rule is present but traffic still times out?
Where in MiniTickets
Section titled “Where in MiniTickets”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/