2026. 5. 31. 12:53ㆍCloud/AWS
EC2를 띄우고 Security Group만 설정했는데, 같은 Subnet의 다른 인스턴스에서 접근이 됩니다. 반대로 NACL에서 차단했더니 응답 트래픽까지 막혀서 서비스가 중단됐습니다. 두 계층의 동작 방식을 정확히 이해하지 않으면 이런 상황이 반복됩니다.
요약
| 기준 | Security Group | NACL (Network ACL) |
|---|---|---|
| 적용 대상 | ENI (인스턴스/서비스 단위) | Subnet 단위 |
| 상태 추적 | Stateful (응답 자동 허용) | Stateless (인바운드/아웃바운드 각각 규칙 필요) |
| 규칙 유형 | 허용만 가능 (Allow only) | 허용 + 거부 모두 가능 (Allow / Deny) |
| 규칙 평가 | 모든 규칙을 평가하여 허용 여부 결정 | 번호 순서대로 평가, 첫 매칭에서 중단 |
| 기본 동작 | 모든 인바운드 차단, 모든 아웃바운드 허용 | 기본 NACL은 모든 트래픽 허용 |
| 추천 역할 | 인스턴스별 세밀한 접근 제어 | Subnet 경계에서의 광범위한 차단 |
1. 왜 두 계층이 모두 필요한가
AWS VPC의 네트워크 보안은 두 개의 독립적인 방화벽 계층으로 구성됩니다.
- Security Group: 인스턴스(ENI) 수준에서 동작하는 가상 방화벽
- NACL: Subnet 경계에서 동작하는 네트워크 수준 방화벽
하나만 사용해도 트래픽 제어는 가능합니다. 그런데 왜 두 계층을 모두 운영할까요?
Defense in Depth(심층 방어) 원칙 때문입니다. Security Group 설정을 실수로 열어두더라도 NACL이 Subnet 경계에서 차단할 수 있습니다. 반대로 NACL이 너무 넓게 열려 있어도 Security Group이 인스턴스 수준에서 불필요한 접근을 막습니다.
실무에서 흔한 시나리오를 보겠습니다.
개발자가 디버깅을 위해 Security Group에 SSH(22번 포트)를
0.0.0.0/0으로 열었습니다. 작업 후 닫는 것을 잊었습니다. 이때 NACL에서 외부 IP 대역의 22번 포트를 차단하고 있었다면, Security Group이 열려 있어도 실제 접근은 불가능합니다.
2. Security Group이란
Security Group은 ENI(Elastic Network Interface)에 연결되는 가상 방화벽입니다. EC2, RDS, ELB, Lambda(VPC 모드) 등 ENI를 사용하는 모든 리소스에 적용됩니다.
핵심 특성
| 특성 | 설명 |
|---|---|
| 적용 단위 | ENI (하나의 인스턴스에 여러 SG 연결 가능, 최대 5개) |
| 상태 추적 | Stateful — 인바운드 허용 시 응답 아웃바운드 자동 허용 |
| 규칙 유형 | Allow만 가능 (Deny 규칙 없음) |
| 기본 동작 | 인바운드: 모두 차단 / 아웃바운드: 모두 허용 |
| 규칙 평가 | 모든 규칙을 종합 평가 (순서 없음) |
| 참조 방식 | IP CIDR 또는 다른 Security Group ID로 소스/대상 지정 가능 |
Stateful의 의미
Security Group이 Stateful이라는 것은 연결 상태를 추적한다는 뜻입니다.
[외부 클라이언트] → 인바운드 요청 (포트 443) → [EC2]
[EC2] → 응답 트래픽 (임시 포트) → [외부 클라이언트] ← 자동 허용
인바운드 규칙에서 443 포트를 허용하면, 해당 연결의 응답 트래픽은 아웃바운드 규칙과 관계없이 자동으로 허용됩니다. 아웃바운드 규칙을 별도로 설정할 필요가 없습니다.
Security Group 참조
Security Group의 강력한 기능 중 하나는 다른 Security Group을 소스로 참조할 수 있다는 점입니다.
# 예: RDS Security Group 인바운드 규칙
Type: MySQL/Aurora
Port: 3306
Source: sg-0abc1234 (Web Server SG)
이렇게 설정하면 Web Server SG가 연결된 인스턴스만 RDS에 접근할 수 있습니다. IP가 변경되어도 규칙을 수정할 필요가 없습니다.
3. NACL이란
NACL(Network Access Control List)은 Subnet 경계에서 동작하는 네트워크 수준 방화벽입니다. Subnet에 들어오고 나가는 모든 트래픽에 적용됩니다.
핵심 특성
| 특성 | 설명 |
|---|---|
| 적용 단위 | Subnet (해당 Subnet의 모든 리소스에 적용) |
| 상태 추적 | Stateless — 인바운드/아웃바운드 각각 별도 규칙 필요 |
| 규칙 유형 | Allow + Deny 모두 가능 |
| 기본 동작 | 기본 NACL: 모든 트래픽 허용 / 커스텀 NACL: 모든 트래픽 차단 |
| 규칙 평가 | 규칙 번호 순서대로 평가, 첫 매칭에서 중단 |
| 마지막 규칙 | 암묵적 Deny (번호 *) — 어떤 규칙에도 매칭되지 않으면 차단 |
Stateless의 의미
NACL이 Stateless라는 것은 각 패킷을 독립적으로 평가한다는 뜻입니다. 연결 상태를 추적하지 않습니다.
[외부 클라이언트] → 인바운드 요청 (포트 443) → [Subnet] ← 인바운드 규칙 필요
[Subnet] → 응답 트래픽 (임시 포트 1024-65535) → [외부 클라이언트] ← 아웃바운드 규칙도 필요!
인바운드에서 443을 허용했더라도, 응답 트래픽을 위한 아웃바운드 규칙(임시 포트 범위)을 별도로 설정해야 합니다. 이것을 빠뜨리면 요청은 들어오지만 응답이 나가지 못해 타임아웃이 발생합니다.
규칙 번호와 평가 순서
NACL 규칙은 번호가 낮은 것부터 순서대로 평가됩니다. 첫 번째로 매칭되는 규칙이 적용되고 나머지는 무시됩니다.
| 규칙 번호 | 유형 | 프로토콜 | 포트 | 소스 | 허용/거부 |
|---|---|---|---|---|---|
| 100 | 인바운드 | TCP | 443 | 0.0.0.0/0 | ALLOW |
| 110 | 인바운드 | TCP | 22 | 10.0.0.0/16 | ALLOW |
| 120 | 인바운드 | TCP | 22 | 0.0.0.0/0 | DENY |
| * | 인바운드 | 전체 | 전체 | 0.0.0.0/0 | DENY |
이 예시에서 VPC 내부(10.0.0.0/16)에서의 SSH는 규칙 110에서 허용되고, 외부에서의 SSH는 규칙 120에서 차단됩니다. 규칙 번호 사이에 간격(10 단위)을 두는 이유는 나중에 중간에 규칙을 삽입할 수 있도록 하기 위함입니다.
4. 동작 방식 비교
트래픽이 인스턴스에 도달하는 순서
외부에서 EC2로 들어오는 트래픽은 다음 순서로 평가됩니다.
인터넷 → Internet Gateway → Route Table → NACL (인바운드) → Security Group (인바운드) → EC2
응답 트래픽이 나가는 순서:
EC2 → Security Group (아웃바운드, Stateful이므로 자동 허용) → NACL (아웃바운드, Stateless이므로 규칙 필요) → Route Table → Internet Gateway → 인터넷
Stateful vs Stateless 동작 비교
시나리오: 외부 클라이언트가 EC2의 웹 서버(443 포트)에 접속
| 단계 | Security Group | NACL |
|---|---|---|
| 인바운드 요청 (포트 443) | 인바운드 규칙에서 443 허용 확인 | 인바운드 규칙에서 443 허용 확인 |
| 아웃바운드 응답 (임시 포트) | 자동 허용 (Stateful) | 아웃바운드 규칙에서 임시 포트(1024-65535) 허용 필요 |
| 아웃바운드 규칙 누락 시 | 영향 없음 | 응답 차단 → 타임아웃 |
이 차이가 운영에서 가장 많은 혼란을 일으킵니다. NACL에서 인바운드만 열고 아웃바운드 임시 포트를 열지 않으면, 요청은 도달하지만 응답이 나가지 못합니다.
5. 규칙 평가 방식 차이
Security Group: 모든 규칙 종합 평가
Security Group은 순서가 없습니다. 모든 규칙을 확인하여 하나라도 허용하는 규칙이 있으면 트래픽을 허용합니다.
규칙 1: TCP 443 from 0.0.0.0/0 → ALLOW
규칙 2: TCP 22 from 10.0.0.0/16 → ALLOW
규칙 3: TCP 3306 from sg-web-server → ALLOW
(암묵적) 나머지 전부 → DENY
Deny 규칙을 추가할 수 없으므로, "특정 IP만 차단"하는 것은 Security Group만으로는 불가능합니다.
NACL: 번호 순서대로 평가, 첫 매칭에서 중단
NACL은 규칙 번호가 낮은 것부터 순서대로 확인합니다. 첫 번째로 매칭되는 규칙이 적용되면 나머지 규칙은 평가하지 않습니다.
규칙 50: TCP 443 from 203.0.113.5/32 → DENY ← 특정 IP 차단
규칙 100: TCP 443 from 0.0.0.0/0 → ALLOW ← 나머지는 허용
규칙 *: 전체 → DENY ← 기본 차단
이 구조 덕분에 NACL은 "특정 IP를 차단"하는 블랙리스트 방식에 적합합니다. 규칙 50이 규칙 100보다 먼저 평가되므로, 203.0.113.5에서의 443 접근은 차단되고 나머지 IP는 허용됩니다.
6. 적용 범위 차이
| 기준 | Security Group | NACL |
|---|---|---|
| 적용 대상 | 개별 ENI (인스턴스 단위) | Subnet 전체 |
| 같은 Subnet 내 통신 | SG 규칙으로 제어 가능 | NACL 적용 안 됨 (Subnet 경계를 넘지 않으므로) |
| 다른 Subnet 간 통신 | SG 규칙으로 제어 가능 | NACL 적용됨 (Subnet 경계를 넘으므로) |
| 하나의 리소스에 여러 규칙 | SG 여러 개 연결 가능 (최대 5개) | Subnet당 NACL 1개만 연결 |
같은 Subnet 내 통신에서의 차이
같은 Subnet 안의 두 EC2 인스턴스가 통신할 때:
- NACL: 적용되지 않습니다. 트래픽이 Subnet 경계를 넘지 않기 때문입니다.
- Security Group: 적용됩니다. 각 인스턴스의 ENI에서 평가됩니다.
이 차이는 중요합니다. 같은 Subnet 내 인스턴스 간 접근을 제어하려면 Security Group을 사용해야 합니다. NACL로는 불가능합니다.
7. 실무 설계 전략
7.1 역할 분담
실무에서 두 계층의 역할을 명확히 분리하면 운영이 단순해집니다.
| 계층 | 역할 | 예시 |
|---|---|---|
| Security Group | 인스턴스별 세밀한 접근 제어 (화이트리스트) | Web → App: 8080만 허용, App → DB: 3306만 허용 |
| NACL | Subnet 경계에서의 광범위한 차단 (블랙리스트) | 알려진 악성 IP 차단, 불필요한 포트 대역 차단 |
7.2 3-Tier 아키텍처 예시
웹 서비스를 Public Subnet(ALB), Private Subnet(App), Private Subnet(DB)으로 분리한 환경을 가정합니다.
Security Group 설계:
ALB SG:
인바운드: TCP 443 from 0.0.0.0/0
App SG:
인바운드: TCP 8080 from ALB SG (sg-alb)
DB SG:
인바운드: TCP 3306 from App SG (sg-app)
NACL 설계:
Public Subnet NACL:
인바운드: TCP 443 ALLOW from 0.0.0.0/0 (규칙 100)
인바운드: TCP 1024-65535 ALLOW from 0.0.0.0/0 (규칙 110, 응답 트래픽)
아웃바운드: TCP 1024-65535 ALLOW to 0.0.0.0/0 (규칙 100)
아웃바운드: TCP 8080 ALLOW to 10.0.2.0/24 (규칙 110, App Subnet)
Private Subnet (App) NACL:
인바운드: TCP 8080 ALLOW from 10.0.1.0/24 (규칙 100, Public Subnet)
인바운드: TCP 1024-65535 ALLOW from 10.0.3.0/24 (규칙 110, DB 응답)
아웃바운드: TCP 3306 ALLOW to 10.0.3.0/24 (규칙 100, DB Subnet)
아웃바운드: TCP 1024-65535 ALLOW to 10.0.1.0/24 (규칙 110, 응답)
Private Subnet (DB) NACL:
인바운드: TCP 3306 ALLOW from 10.0.2.0/24 (규칙 100, App Subnet만)
아웃바운드: TCP 1024-65535 ALLOW to 10.0.2.0/24 (규칙 100, 응답)
이 구조에서 Security Group은 "누가 누구에게 접근할 수 있는가"를 정의하고, NACL은 "이 Subnet에 어떤 트래픽이 들어올 수 있는가"를 정의합니다.
7.3 NACL을 적극 활용하는 경우
대부분의 환경에서는 Security Group만으로 충분한 접근 제어가 가능합니다. NACL을 적극 활용하는 경우는 다음과 같습니다.
- 특정 IP 차단이 필요할 때: DDoS 공격 소스 IP, 알려진 악성 IP를 Subnet 경계에서 차단
- 컴플라이언스 요구사항: 규제 환경에서 네트워크 계층별 방화벽을 요구하는 경우
- Subnet 간 격리 강화: DB Subnet에 App Subnet 외의 모든 접근을 차단
- 실수 방지 안전망: Security Group 설정 오류에 대한 2차 방어선
8. 운영 시 주의사항
8.1 NACL의 임시 포트(Ephemeral Ports)
NACL은 Stateless이므로 응답 트래픽을 위한 임시 포트를 반드시 열어야 합니다.
| OS | 임시 포트 범위 |
|---|---|
| Linux | 32768-60999 |
| Windows | 49152-65535 |
| ELB | 1024-65535 |
운영 환경에서는 다양한 OS와 서비스가 혼재하므로, 일반적으로 1024-65535 범위를 아웃바운드에 허용합니다.
8.2 Security Group 규칙 수 제한
| 항목 | 기본 한도 |
|---|---|
| VPC당 Security Group 수 | 2,500 |
| SG당 인바운드 규칙 수 | 60 |
| SG당 아웃바운드 규칙 수 | 60 |
| ENI당 연결 가능한 SG 수 | 5 |
규칙 수가 부족하면 Prefix List를 사용하거나, SG 참조 방식으로 규칙을 줄일 수 있습니다.
8.3 NACL 규칙 수 제한
| 항목 | 기본 한도 |
|---|---|
| NACL당 규칙 수 | 인바운드 20개 + 아웃바운드 20개 |
| VPC당 NACL 수 | 200 |
NACL 규칙 수는 Security Group보다 훨씬 적습니다. 세밀한 제어보다는 광범위한 차단 용도로 사용해야 하는 이유입니다.
8.4 자주 하는 실수
- NACL 아웃바운드 임시 포트 누락: 인바운드만 열고 아웃바운드 응답 포트를 열지 않아 타임아웃 발생
- NACL 규칙 순서 오류: 허용 규칙보다 높은 번호에 차단 규칙을 넣어 의도와 다르게 동작
- 커스텀 NACL 생성 후 규칙 미설정: 커스텀 NACL은 기본적으로 모든 트래픽을 차단하므로, 생성 직후 필요한 규칙을 추가해야 함
- 같은 Subnet 내 통신을 NACL로 제어하려는 시도: NACL은 Subnet 경계에서만 동작하므로 불가능
- Security Group에서 특정 IP 차단 시도: Security Group은 Allow만 가능하므로 Deny가 필요하면 NACL 사용
9. 비용 관점
Security Group과 NACL 모두 추가 비용이 없습니다. AWS VPC에 포함된 기본 기능입니다.
다만 간접적인 비용 영향이 있습니다.
| 관점 | 설명 |
|---|---|
| 운영 비용 | NACL 규칙이 복잡해지면 트러블슈팅 시간 증가 |
| 장애 비용 | NACL 임시 포트 누락으로 인한 서비스 중단 |
| 보안 비용 | Security Group만 사용 시 방어 계층이 단일화되어 침해 시 피해 범위 확대 |
10. 자주 나오는 질문
| 질문 | 핵심 답변 |
|---|---|
| SG와 NACL의 가장 큰 차이는? | Stateful vs Stateless. SG는 응답 자동 허용, NACL은 양방향 규칙 필요 |
| 특정 IP를 차단하려면? | NACL 사용. SG는 Allow만 가능하므로 Deny 불가 |
| 같은 Subnet 내 인스턴스 간 제어는? | Security Group. NACL은 Subnet 경계에서만 동작 |
| 트래픽 평가 순서는? | NACL(인바운드) → SG(인바운드) → 인스턴스 → SG(아웃바운드, 자동) → NACL(아웃바운드) |
| 기본 NACL과 커스텀 NACL 차이는? | 기본: 모든 트래픽 허용 / 커스텀: 모든 트래픽 차단 |
11. 정리
- Security Group은 인스턴스(ENI) 단위의 Stateful 방화벽이고, NACL은 Subnet 단위의 Stateless 방화벽입니다.
- Security Group은 Allow만 가능하고 순서 없이 모든 규칙을 평가합니다. NACL은 Allow/Deny 모두 가능하고 번호 순서대로 평가합니다.
- NACL은 Stateless이므로 응답 트래픽을 위한 임시 포트 규칙을 반드시 설정해야 합니다.
- 실무에서는 Security Group으로 세밀한 접근 제어를, NACL로 Subnet 경계의 광범위한 차단을 담당하도록 역할을 분리합니다.
- 같은 Subnet 내 인스턴스 간 통신은 NACL로 제어할 수 없으며, Security Group만 적용됩니다.
관련 글
- AWS VPC란 무엇인가: Subnet, Route Table, Internet Gateway 개념 정리
- Public Subnet과 Private Subnet 차이: Route Table, 보안, 비용 기준으로 정리
참고 문서
'Cloud > AWS' 카테고리의 다른 글
| ALB와 NLB 차이: 언제 어떤 Load Balancer를 선택할까 (0) | 2026.06.01 |
|---|---|
| AWS 3-Tier 아키텍처 설계 예시: Web, App, DB 계층 분리와 운영 전략 (0) | 2026.06.01 |
| Public Subnet과 Private Subnet 차이: Route Table, 보안, 비용 기준으로 정리 (0) | 2026.05.29 |
| NAT Gateway와 VPC Endpoint 차이: 비용, 보안, 트래픽 경로 기준 정리 (0) | 2026.05.29 |
| AWS VPC란 무엇인가: Subnet, Route Table, Internet Gateway 개념 정리 (0) | 2026.05.28 |