보안 그룹(SG) vs 네트워크 ACL(NACL)
AWS SCS-C03 문제풀이를 하면서 IAM 쪽은 감이 잡혔는데, VPC 네트워크 계층 통제인 SG/NACL 구분이 아직 헷갈려서 따로 정리함
핵심 차이
| 구분 | Security Group | Network ACL |
|---|---|---|
| 적용 대상 | 인스턴스(ENI) 단위 | 서브넷 단위 |
| 상태 추적 | Stateful (요청 허용하면 응답은 자동 허용) | Stateless (인바운드/아웃바운드 각각 명시 필요) |
| 규칙 종류 | Allow만 가능 | Allow와 Deny 둘 다 가능 |
| 규칙 평가 | 모든 규칙을 다 확인 후 종합 판단 | 번호 순서대로 평가, 먼저 매치되면 그걸로 확정 |
| 기본값 | 기본적으로 모든 인바운드 거부, 아웃바운드는 허용 | 기본 NACL은 전부 허용 |
Stateless라서 자주 하는 실수
NACL은 상태를 기억하지 못하기 때문에, 인바운드로 요청을 허용해도 그 응답이 나가는 아웃바운드 규칙을 따로 안 열어두면 통신이 끊김 특히 임시 포트(ephemeral port, 1024-65535) 범위를 아웃바운드에서 막아두면 정상 요청의 응답이 막히는 사고가 흔함
언제 뭘 쓰는가
- SG만으로 충분한 경우가 대부분: 인스턴스 단위로 세밀하게 “이 포트만 이 소스에서” 허용하는 게 목적이면 SG로 충분
- NACL이 필요한 경우: 특정 IP를 서브넷 전체에서 명시적으로 차단(Deny)해야 할 때 SG는 Allow만 가능해서 “차단”을 표현할 방법이 없다 — 여기서 NACL의 존재 이유가 명확해짐
실무 판별 팁
- 문제/상황에 “특정 악성 IP를 즉시 차단”이라는 표현이 나오면 → NACL Deny 규칙이 정답 후보 (SG는애초에 Deny가 없어서 원천 배제)
- “인스턴스별로 다른 접근 정책”이라는 표현이 나오면 → SG (서브넷 단위인 NACL로는 인스턴스별 세분화가 안 됨)
더 생각해볼 것들
- 두 계층을 같이 쓸 때, 방어 심도(defense in depth) 관점에서 SG와 NACL 규칙을 어떻게 역할 분담하는 게 좋을까
- NACL 규칙 번호 순서를 잘못 설계해서 생기는 사고 사례를 더 찾아보고 싶음
원본: summary