Mar 24, 2026

마지막 업데이트 Mar 30, 2026

AWS Security Group가 트래픽을 막을 때: 먼저 확인할 것들

AWS 워크로드에 트래픽이 도달하지 않을 때 security group은 가장 먼저 의심되지만, 항상 근본 원인은 아닙니다. 실제 문제는 listener, target, subnet route, NACL, return path, 혹은 운영 중인 실제 source와 destination에 rule이 맞지 않는 데 있을 수 있습니다.

짧게 말하면, 무작정 allow rule을 넓히기 전에 먼저 실제 client-to-target 경로를 그리고, ingress와 egress를 그 경로와 대조해 보는 것이 가장 빠릅니다.

먼저 전체 네트워크 경로를 추적하세요

어느 한 곳에서 port가 열려 보여도 다른 구간에서 트래픽이 막힐 수 있습니다.

그래서 먼저 아래를 식별해야 합니다.

실제 client가 누구인지
어떤 target에 도달해야 하는지
기대하는 port와 protocol이 무엇인지
load balancer, NAT, 중간 hop이 경로를 바꾸는지

이 경로를 모르고 security group만 보면 결국 추측이 됩니다.

security group이 막는 것처럼 보이는 흔한 이유

1. rule이 실제 source와 맞지 않음

가장 흔한 문제는 “rule이 없다”보다 “rule은 있는데 source 가정이 틀렸다”입니다.

잘못된 CIDR, 잘못된 source security group, 잘못된 subnet 가정이 대표적입니다.

2. egress 제한 때문에 return path가 막힘

대부분 ingress부터 보고 멈추지만, egress가 예상보다 좁으면 응답 경로나 downstream call도 실패할 수 있습니다.

3. 다른 네트워크 제어가 같은 경로를 막고 있음

NACL, load balancer listener, target group, route table, subnet 배치가 겉보기엔 security group 문제처럼 보이는 장애를 만들 수 있습니다.

4. workload가 실제로 기대한 곳에서 listen 하고 있지 않음

network rule은 맞지만 애플리케이션이 잘못된 interface나 port에 bind 되어 있으면, 바깥에서는 SG 문제처럼 느껴질 수 있습니다.

5. 경로는 바뀌었는데 rule은 예전 구조에 맞춰져 있음

새 ALB, 새 subnet, 새 instance group, 새 security group attachment로 옮긴 뒤 이전 구조 기준 rule을 그대로 두면, 콘솔상으로는 맞아 보여도 현재 아키텍처에는 틀린 상태가 됩니다.

실전 점검 순서

1. 실제 client, destination, expected port를 확인하세요

security group 콘솔보다 먼저 실제 경로부터 적어야 합니다.

client source
listener 또는 진입 지점
target resource
destination port
response path

이 단계만으로도 상당수 오해가 사라집니다.

2. ingress와 egress를 실제 경로와 비교하세요

경로가 정리됐으면 양방향을 같이 봐야 합니다.

ingress가 실제 source를 허용하는가
egress가 응답이나 downstream call을 허용하는가
지금 보고 있는 security group이 실제로 붙은 SG가 맞는가

여기서 해결되는 경우가 많습니다.

3. 주변 제어를 함께 점검하세요

security group은 혼자 동작하지 않습니다. 아래를 같이 봐야 합니다.

subnet의 NACL
load balancer listener와 target-group 동작
route table
health check
target이 기대한 subnet과 security group에 붙어 있는지

이 중 하나라도 틀리면 SG만 넓혀도 해결되지 않습니다.

4. target process가 실제로 listen 하는지 확인하세요

target이 죽어 있거나 unhealthy 하거나 잘못 bind 되어 있으면, 네트워크 경로 자체가 끊긴 것처럼 보일 수 있습니다.

이 단계부터는 네트워크보다 애플리케이션 점검이 더 중요할 수 있습니다.

5. 그다음에만 rule을 넓히거나 수정하세요

정확한 mismatch를 찾기 전에 rule을 넓히면 잠깐 증상을 가릴 수는 있어도, 구조는 더 헷갈리고 노출은 더 커질 수 있습니다.

조사에 바로 도움이 되는 명령

aws ec2 describe-security-groups --group-ids <sg-id>
aws ec2 describe-network-acls --filters Name=association.subnet-id,Values=<subnet-id>
aws ec2 describe-instances --instance-ids <instance-id>

콘솔 감각보다, 실제 적용된 rule과 NACL, target attachment를 같이 보는 편이 더 정확합니다.

패턴을 찾은 뒤 어떻게 바꿀지

source 가정이 틀린 경우

실제 source CIDR이나 source security group에 맞게 rule을 고치고, 필요 이상으로 넓은 범위를 추가하지 않는 편이 좋습니다.

return path가 문제인 경우

ingress만 넓히지 말고 egress rule이나 downstream 경로를 바로잡아야 합니다.

다른 네트워크 제어가 원인인 경우

실패를 실제로 소유한 NACL, listener, route, target-group 설정을 수정해야 합니다.

app이 잘못 listen 하는 경우

이건 security group 문제가 아니라 애플리케이션이나 배포 문제로 봐야 합니다.

빠른 체크리스트

AWS 워크로드에 트래픽이 도달하지 않을 때는 아래 순서가 가장 실용적입니다.

실제 client-to-target 경로를 그린다
ingress와 egress를 그 경로와 비교한다
NACL, listener, route, target health를 본다
workload가 기대한 곳에서 listen 하는지 확인한다
그다음에만 security group rule을 수정한다

FAQ

Q. security group이 항상 근본 원인인가요?

아닙니다. listener, NACL, route, target health, 애플리케이션 자체도 같은 증상을 만들 수 있습니다.

Q. 가장 빠른 첫 단계는 무엇인가요?

정확한 client-to-target 경로를 그리고, 그 경로와 ingress/egress를 대조하는 것입니다.

Q. rule을 넓혀도 왜 전혀 해결되지 않는 경우가 있나요?

실패 지점이 NACL, route, listener, target health, workload 쪽에 있기 때문입니다.

Q. 언제 SG 수정 대신 다른 곳을 봐야 하나요?

경로와 rule이 기술적으로 맞는데도 트래픽이 실패할 때입니다.

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.