Security Group을 처음 배울 때 가장 많이 혼동하는 부분이 Stateful 동작입니다. 온프레미스 ACL이나 iptables에 익숙한 엔지니어라면 "응답 트래픽도 아웃바운드 규칙에서 허용해야 하지 않나?"라는 의문이 자연스럽게 생깁니다. 결론부터 말하면 — Security Group에서는 그럴 필요가 없습니다.

확대

연결 추적(Connection Tracking)이란

Security Group은 내부적으로 모든 연결의 상태를 추적합니다. TCP 3-way handshake가 성공해 연결이 수립되면, 이 연결의 응답 패킷은 아웃바운드 규칙을 확인하지 않고 자동으로 허용됩니다. 이것이 Stateful 방화벽의 핵심입니다.

확대

Stateful이 실무에서 의미하는 것

아웃바운드 기본 규칙이 "전체 허용(0.0.0.0/0)"인 경우, Security Group 설정에서 인바운드 규칙만 신경 쓰면 됩니다. 인바운드에서 허용한 연결의 응답은 아웃바운드 설정과 무관하게 돌아갑니다.

아웃바운드를 제한하는 경우 — 예를 들어 DB 서버가 외부 인터넷으로 나가는 것을 막고 싶을 때 — 에는 아웃바운드 규칙을 수정합니다. 이때도 인바운드에서 허용된 연결의 응답은 영향을 받지 않습니다. Stateful이기 때문입니다.

아웃바운드 기본 규칙을 제거하면 어떻게 되나

아웃바운드 규칙을 모두 제거한 경우:

1. 외부에서 이 EC2로 들어오는 인바운드 연결 → 응답 트래픽은 자동 허용 (Stateful)
2. 이 EC2에서 외부로 나가는 아웃바운드 연결 → 차단됨 (규칙 없음)

즉, 아웃바운드 규칙 제거는 "이 서버가 먼저 연결을 시작하는 것"만 막습니다.
외부에서 들어온 연결에 대한 응답은 여전히 나갑니다.

이 동작 원리를 이해하지 못하면 "아웃바운드를 다 막았는데 왜 응답이 가지?"라는 혼란이 생깁니다. 연결을 시작한 방향이 중요한 것이 Stateful의 핵심입니다.

앞에서 "SG는 stateful"이라는 개념을 봤다면, 이번에는 패킷 한 개가 실제로 어느 순서로 평가되는지를 따라갑니다. 이 순서를 알면 "인바운드만 열었는데 왜 응답까지 되지", "SG는 열었는데 왜 timeout이지"를 단계로 좁힐 수 있습니다. 클라이언트가 EC2의 8080으로 붙는 한 번의 연결에서, 보안그룹 안쪽에서는 아래 순서가 일어납니다.

[외부 클라이언트]  TCP SYN → EC2:8080
   │
   ① 패킷이 인스턴스 ENI에 도착
   │    (NACL이 있으면 서브넷 NACL 인바운드를 먼저 통과해야 함)
   │
   ② 인바운드 SG 규칙 평가 — 화이트리스트
   │    → 허용 규칙 중 출발지·포트가 매칭되는 게 하나라도 있나?
   │    → 있으면 통과 / 하나도 없으면 조용히 드롭 (거부 규칙 자체가 없음)
   │
   ③ 연결 추적(conntrack) 등록 — 여기서부터 stateful
   │    → 이 연결의 5-튜플(출발지·목적지 IP/포트/프로토콜)을 상태 테이블에 기록
   │
   ④ 응답 패킷 (EC2 → 클라이언트)
   │    → 아웃바운드 SG 규칙을 보지 않고 conntrack 매칭으로 자동 허용
   │
   ⑤ (NACL이 있으면) 응답은 NACL 아웃바운드도 통과해야 함
   │    → NACL은 stateless라 ephemeral 포트(1024-65535) 허용이 따로 필요
   ▼
[클라이언트]  응답 수신 → 연결 성립

각 단계에서 무슨 일이 일어나고, 막히면 어떤 증상인가:

즉 SG만 보면 "인바운드 ②만 맞으면 응답 ④는 저절로 된다" 가 핵심입니다. 그래서 접속이 안 될 때 Connection timed out이면 ①·②·⑤(경로·인바운드 SG·NACL 응답) 중 하나가 패킷을 삼킨 것이고, Connection refused면 ①②는 통과해 인스턴스까지 도달했으나 그 포트에 앱이 없다는 뜻입니다 — SG/NACL 문제가 아니라 ss -tlnp로 넘어갈 신호입니다.

Security Group만 보고 "열었는데 왜 안 되지?"를 반복하는 것은 그 외 4개의 관문을 확인하지 않았기 때문입니다. 클라우드에서 트래픽이 EC2에 도달하기까지 통과해야 하는 관문은 순서대로 5개입니다.

확대

5단계 진단 순서

확대

각 단계별 점검 포인트

1단계: Security Group

# 확인할 것:
# - 해당 포트가 인바운드 규칙에 있는가?
# - 소스 IP가 허용 범위에 포함되는가?
# - Security Group이 올바른 인스턴스에 붙어있는가?

aws ec2 describe-security-groups --group-ids sg-xxxxx \
  --query 'SecurityGroups[*].IpPermissions'

2단계: Network ACL (NACL)

# NACL은 서브넷 단위로 적용됩니다
# 인스턴스가 속한 서브넷의 NACL을 확인합니다
aws ec2 describe-network-acls \
  --filters "Name=association.subnet-id,Values=subnet-xxxxx" \
  --query 'NetworkAcls[*].Entries' \
  --output table

# 인바운드와 아웃바운드 각각 허용 규칙이 있는지 확인
# Egress: false = 인바운드, true = 아웃바운드
# RuleAction: allow | deny

3단계: Route Table

# 인스턴스가 있는 서브넷의 라우팅 테이블 확인
aws ec2 describe-route-tables \
  --filters "Name=association.subnet-id,Values=subnet-xxxxx" \
  --query 'RouteTables[*].Routes[*].{Dest:DestinationCidrBlock,Target:GatewayId}' \
  --output table

# 0.0.0.0/0 → igw-xxxx : Public 서브넷 (인터넷 직접 연결)
# 0.0.0.0/0 → nat-xxxx : Private 서브넷 (아웃바운드만)
# 경로 없음             : 인터넷 도달 불가

4단계: IGW / NAT GW 상태

# IGW 연결 상태 확인
aws ec2 describe-internet-gateways \
  --filters "Name=attachment.vpc-id,Values=vpc-xxxxx" \
  --query 'InternetGateways[*].{IGW:InternetGatewayId,State:Attachments[0].State}'

# NAT Gateway 상태 확인 (Private 서브넷의 아웃바운드용)
aws ec2 describe-nat-gateways \
  --filter "Name=vpc-id,Values=vpc-xxxxx" \
  --query 'NatGateways[*].{NAT:NatGatewayId,State:State,SubnetId:SubnetId}'

5단계: OS 방화벽

# EC2 내부에서 확인 (SSH 접속 후)
# Amazon Linux 2 / RHEL 계열
sudo firewall-cmd --list-all

# Ubuntu 계열
sudo ufw status verbose

# iptables 직접 확인 (모든 배포판)
sudo iptables -L INPUT -n -v --line-numbers

# 포트가 실제로 리스닝 중인지 확인
sudo ss -tlnp | grep :8080

에러 메시지로 단계 추측하기

Connection timed out (연결 타임아웃, 무반응):
  → Security Group 또는 NACL이 DROP/REJECT 중
  → Route Table에 경로가 없거나 IGW가 없음
  → OS 방화벽이 DROP으로 설정됨

Connection refused (연결 거부):
  → EC2는 도달했지만 해당 포트에서 아무것도 리스닝하지 않음
  → 또는 OS 방화벽이 REJECT로 응답
  → 애플리케이션이 실행되지 않았거나 다른 포트를 사용 중

No route to host:
  → Route Table에 목적지 경로가 없음
  → 또는 NACL이 DENY 응답을 보냄

VPC 모듈에서 두 방화벽의 개념적 차이를 배웠다면, 여기서는 그 차이가 실제 트러블슈팅에서 어떤 함정을 만드는지를 봅니다. NACL의 Stateless 특성은 경험이 없으면 절대 직관적으로 알 수 없습니다.

핵심 비교

NACL Stateless가 만드는 함정 — ephemeral 포트

클라이언트가 TCP 연결을 시작할 때, OS는 임의의 **ephemeral 포트(임시 포트, 1024-65535)**를 소스 포트로 사용합니다. 서버 응답은 이 포트로 돌아가야 합니다.

확대

Security Group이라면 연결 추적을 통해 52341 포트 응답을 자동 허용합니다. NACL은 그렇지 않습니다.

언제 NACL을 쓰고 언제 Security Group을 쓰는가

Security Group으로만 충분한 경우:

• 대부분의 일반 워크로드
• 인스턴스별 세밀한 접근 제어가 필요한 경우
• 다른 Security Group을 소스로 지정하고 싶을 때 (예: app-sg에서 db-sg로만 허용)

NACL을 추가로 사용하는 경우:

• 서브넷 단위로 특정 IP 대역을 명시적으로 차단해야 할 때 (DDoS 방어)
• 규정 준수(Compliance)로 서브넷 경계에서의 명시적 차단 기록이 필요할 때
• Security Group 규칙 한도(기본 60개 per SG)를 초과하는 복잡한 구성

실무 권장 패턴:

기본 NACL은 전체 허용으로 두고 (기본값),
세밀한 접근 제어는 Security Group으로만 관리합니다.
NACL 수정은 ephemeral 포트 함정 때문에 위험하므로
명확한 필요가 있을 때만 건드립니다.

SG도 열었고 Flow Log도 ACCEPT인데 "연결은 되는데 큰 데이터만 멈춘다"는 신고가 옵니다. 이건 규칙 문제가 아니라 패킷 크기 문제입니다. SG/NACL 다섯 관문을 아무리 다시 봐도 안 나오는 이유가 여기 있습니다.

• MTU와 DF 비트: 경로 상 가장 작은 MTU를 넘는 IP 패킷은 쪼개거나(fragment) 버려져야 합니다. TCP는 보통 DF(Don't Fragment) 비트를 세워 보내므로, 중간 라우터는 쪼개는 대신 발신자에게 ICMP type 3 code 4(Fragmentation Needed, MTU 이만큼)를 돌려줘야 합니다. 발신자는 이를 받고 세그먼트 크기를 줄입니다 — 이것이 Path MTU Discovery(PMTUD)입니다.
• 블랙홀의 성립: 그 ICMP를 NACL·SG·중간 방화벽이 막으면, 발신자는 "너무 크다"는 신호를 못 받고 같은 큰 패킷을 계속 재전송하다 조용히 유실합니다. 반면 핸드셰이크·짧은 요청 같은 작은 패킷은 통과하니 "연결은 되는데 큰 응답·업로드만 멈춘다"가 됩니다. VPN·Direct Connect·오버레이 네트워크처럼 터널 헤더로 MTU가 1500보다 줄어드는 구간에서 특히 흔합니다.
• Flow Log 함정: 이 경우 규칙 자체는 통과했으므로 Flow Log에는 ACCEPT로 찍힙니다. REJECT를 찾아 헤매면 원인을 영영 못 만납니다 — ACCEPT인데 안 되는 것이 오히려 단서입니다.
• 두 갈래 대책: ① ICMP Fragmentation Needed(type 3 code 4)를 NACL 인바운드/아웃바운드와 SG에 허용해 PMTUD를 살립니다. ② 그래도 안 되면 MSS clamping으로 애초에 큰 패킷을 안 만듭니다 — 리눅스는 iptables의 TCPMSS --clamp-mss-to-pmtu, 또는 인터페이스 MTU를 경로 최소값(예: 1400)에 맞춰 낮춥니다. TCP는 SYN에서 MSS를 협상하므로, MSS를 낮추면 처음부터 경로에 맞는 크기로만 보냅니다.