AWS에서 트래픽을 막는 방화벽은 두 층입니다. **보안 그룹(Security Group)**과 네트워크 ACL(NACL). 둘 다 인바운드·아웃바운드 규칙을 갖지만 동작 방식이 달라서, 차이를 모르면 "규칙을 분명히 열었는데 접속이 안 되는" 상황에 빠집니다.
핵심 차이
| 항목 | 보안 그룹 | 네트워크 ACL |
|---|---|---|
| 적용 단위 | 인스턴스(ENI) | 서브넷 전체 |
| 상태 | stateful(상태 저장) | stateless(무상태) |
| 규칙 | 허용(allow)만 | 허용·거부(deny) 모두 |
| 평가 순서 | 모든 규칙 종합 | 규칙 번호 순, 먼저 매칭된 것 적용 |
| 기본값 | 인바운드 전부 차단 | 기본 NACL은 전부 허용 |
가장 자주 발목 잡는 건 stateful vs stateless입니다. 보안 그룹은 인바운드를 허용하면 그에 대한 응답(아웃바운드)이 자동 허용됩니다. 반면 NACL은 무상태라 인바운드를 열어도 응답이 나가는 아웃바운드 규칙을 따로 열어야 합니다. 흔히 임시 포트 범위(1024-65535)를 아웃바운드에 열지 않아 응답이 막힙니다.
트래픽이 거치는 순서
들어오는 패킷은 서브넷의 NACL을 먼저 통과한 뒤 인스턴스의 보안 그룹을 만납니다.
TEXT
요청 → NACL(서브넷, 무상태) → 보안 그룹(인스턴스, 상태저장) → EC2
즉 한쪽이라도 막으면 통신이 안 됩니다. 둘 다 통과해야 패킷이 인스턴스에 도착합니다.
실무 설계 — 둘을 어떻게 조합하나
- 기본 방어선은 보안 그룹 — 대부분의 접근 제어는 보안 그룹으로 합니다. stateful이라 규칙이 단순하고, 인스턴스 단위로 세밀하게 통제할 수 있습니다.
- 보안 그룹은 SG 참조로 묶기 — 웹 서버 SG가 DB SG의
3306만 허용하도록, IP 대신 소스에 다른 보안 그룹을 지정합니다. 인스턴스가 늘어도 규칙을 안 고쳐도 됩니다. - NACL은 서브넷 단위 광역 차단에만 — 특정 악성 IP 대역을 서브넷 전체에서 막거나(
deny), 프라이빗 서브넷의 인바운드를 통째로 제한하는 등 굵직한 규칙에 씁니다. 보안 그룹은deny를 못 하니 차단은 NACL의 몫입니다. - NACL을 쓸 땐 응답 포트를 잊지 말기 — 인바운드
443을 열었다면 아웃바운드에 임시 포트 범위(1024-65535)를 함께 엽니다.
규칙이 너무 많거나 NACL을 과하게 쓰면 디버깅이 어려워집니다. **"세밀한 허용은 보안 그룹, 광역 차단은 NACL"**이 기본 원칙입니다.
요점 정리
- 보안 그룹 = 인스턴스 단위·stateful·허용만, NACL = 서브넷 단위·stateless·허용/거부.
- 패킷은 NACL → 보안 그룹 순으로 둘 다 통과해야 도착한다.
- 일상적 접근 제어는 보안 그룹(SG 참조 활용), 광역 차단은 NACL.
- NACL은 무상태라 응답용 임시 포트 아웃바운드를 꼭 열어야 한다.
보안 그룹과 NACL을 직접 구성하고 접속이 막히는 원인을 추적하는 실습은 클라우드 트랙에서 회원가입 없이 무료로 할 수 있습니다.