Security Groups vs NACLs: 어떤 걸 써야 할까?
Security Group은 인스턴스 레벨의 Stateful 방화벽, NACL은 서브넷 레벨의 Stateless 방화벽입니다. 차이점과 선택 기준을 SAA-C03 시험 관점에서 정리합니다.
관련 시험 도메인
- Domain 1: Design Secure Architectures
핵심 요약 (BLUF)
Security Group은 인스턴스 레벨의 Stateful 방화벽, NACL은 서브넷 레벨의 Stateless 방화벽입니다. Security Group은 허용만 가능하고 응답이 자동 반환되며, NACL은 허용/거부가 가능하지만 응답도 명시적으로 허용해야 합니다.
시험 팁
시험 핵심: Security Group = Stateful (응답 자동), NACL = Stateless (응답도 규칙 필요), NACL은 규칙 번호 순서대로 평가
Security Group과 NACL의 핵심 차이
한눈에 비교
| 비교 항목 | Security Group | NACL |
|---|---|---|
| 적용 레벨 | 인스턴스 (ENI) | 서브넷 |
| 상태 | Stateful | Stateless |
| 규칙 유형 | 허용(Allow)만 | 허용(Allow) + 거부(Deny) |
| 규칙 평가 | 모든 규칙 종합 평가 | 번호 순서대로 평가 |
| 응답 트래픽 | 자동 허용 | 명시적 허용 필요 |
| 기본 동작 | 모든 인바운드 거부, 모든 아웃바운드 허용 | 기본 ACL: 모두 허용 |
| 연결 수 | 인스턴스당 여러 개 | 서브넷당 1개 |
| 비용 | 무료 | 무료 |
Stateful vs Stateless: 가장 중요한 차이
Stateful (Security Group)
[클라이언트] ─────► [EC2]
요청 (포트 80)
[클라이언트] ◄───── [EC2]
응답 (자동 허용)
인바운드: 포트 80 허용 → 응답은 아웃바운드 규칙 없어도 자동으로 나감
Stateless (NACL)
[클라이언트] ─────► [EC2]
요청 (포트 80)
인바운드 규칙 필요!
[클라이언트] ◄───── [EC2]
응답 (임시 포트)
아웃바운드 규칙 필요!
인바운드 + 아웃바운드 모두 명시적으로 허용해야 함
시험 팁
암기 포인트: "State"는 "상태 기억"을 의미합니다. Security Group은 요청을 기억해서 응답을 자동 허용, NACL은 기억 못해서 둘 다 규칙 필요!
Security Group: 인스턴스 레벨 방화벽
특징
- 적용 대상: EC2, RDS, Lambda(VPC), ElastiCache 등의 네트워크 인터페이스(ENI)
- 허용 규칙만: 거부(Deny) 규칙이 없음 → 특정 IP 차단 불가
- 여러 개 연결 가능: 인스턴스당 최대 5개 (요청 시 16개까지)
- 소스로 Security Group 지정 가능: IP 대신 다른 Security Group 참조
기본 동작
새로 생성한 Security Group:
├── 인바운드: 모든 트래픽 거부 (기본)
└── 아웃바운드: 모든 트래픽 허용 (기본)
규칙 평가 방식
모든 규칙을 종합 평가합니다. 여러 Security Group이 연결되면 모든 규칙이 합쳐집니다.
Security Group A: 포트 22 허용
Security Group B: 포트 80 허용
→ 결과: 포트 22 + 포트 80 모두 허용
Security Group 규칙 예시
웹 서버용 Security Group
| 유형 | 프로토콜 | 포트 | 소스/대상 | 설명 |
|---|---|---|---|---|
| 인바운드 | TCP | 80 | 0.0.0.0/0 | HTTP 허용 |
| 인바운드 | TCP | 443 | 0.0.0.0/0 | HTTPS 허용 |
| 인바운드 | TCP | 22 | 10.0.0.0/8 | SSH (내부만) |
| 아웃바운드 | 전체 | 전체 | 0.0.0.0/0 | 모든 아웃바운드 허용 |
Security Group을 소스로 참조
IP 대신 다른 Security Group을 소스로 지정할 수 있습니다.
Web-SG (웹 서버):
└── 인바운드: 포트 80, 소스 = ALB-SG
ALB-SG에 연결된 리소스만 웹 서버에 접근 가능
→ IP 변경에 유연하게 대응!
NACL: 서브넷 레벨 방화벽
특징
- 적용 대상: 서브넷 전체 (서브넷 출입 트래픽)
- 허용 + 거부 규칙: 특정 IP 명시적 차단 가능
- 서브넷당 1개만: 여러 NACL 연결 불가
- 규칙 번호로 우선순위: 낮은 번호가 먼저 평가
기본 동작
기본 NACL (VPC 생성 시 자동):
├── 인바운드: 규칙 100 - 모든 트래픽 허용
├── 아웃바운드: 규칙 100 - 모든 트래픽 허용
└── * (별표): 모든 트래픽 거부 (매칭 안 되면 최종 거부)
커스텀 NACL (새로 생성 시):
├── 인바운드: * - 모든 트래픽 거부 (기본)
└── 아웃바운드: * - 모든 트래픽 거부 (기본)
시험 팁
시험 포인트: 기본 NACL은 모두 허용, 커스텀 NACL은 모두 거부가 기본입니다!
규칙 평가 방식
규칙 번호 순서대로 평가하며, 매칭되면 즉시 적용하고 나머지는 무시합니다.
규칙 100: 포트 22 허용
규칙 200: 포트 22 거부
→ 결과: 포트 22 허용 (규칙 100이 먼저 매칭)
규칙 100: 포트 22 거부
규칙 200: 포트 22 허용
→ 결과: 포트 22 거부 (규칙 100이 먼저 매칭)
NACL 규칙 예시
웹 서버 서브넷용 NACL
| 규칙 번호 | 유형 | 프로토콜 | 포트 | 소스/대상 | 허용/거부 |
|---|---|---|---|---|---|
| 인바운드 | |||||
| 100 | TCP | 80 | 0.0.0.0/0 | 허용 | |
| 110 | TCP | 443 | 0.0.0.0/0 | 허용 | |
| 120 | TCP | 22 | 10.0.0.0/8 | 허용 | |
| 130 | TCP | 1024-65535 | 0.0.0.0/0 | 허용 | |
| * | 전체 | 전체 | 0.0.0.0/0 | 거부 | |
| 아웃바운드 | |||||
| 100 | TCP | 80 | 0.0.0.0/0 | 허용 | |
| 110 | TCP | 443 | 0.0.0.0/0 | 허용 | |
| 120 | TCP | 1024-65535 | 0.0.0.0/0 | 허용 | |
| * | 전체 | 전체 | 0.0.0.0/0 | 거부 |
임시 포트(Ephemeral Ports)가 중요한 이유
클라이언트가 서버에 연결할 때 응답을 받을 임시 포트가 할당됩니다.
클라이언트 → 서버: 목적지 포트 80
서버 → 클라이언트: 목적지 포트 = 임시 포트 (1024-65535)
운영체제별 임시 포트 범위:
| OS | 포트 범위 |
|---|---|
| Linux | 32768-60999 |
| Windows | 49152-65535 |
| AWS NAT Gateway | 1024-65535 |
시험 팁
실수 방지: NACL 아웃바운드에 임시 포트(1024-65535)를 허용하지 않으면 응답이 차단됩니다!
트래픽 흐름 순서
외부 → EC2 (인바운드)
인터넷
↓
[1] NACL 인바운드 규칙 평가
↓ (통과)
[2] Security Group 인바운드 규칙 평가
↓ (통과)
EC2 인스턴스
EC2 → 외부 (아웃바운드)
EC2 인스턴스
↓
[1] Security Group 아웃바운드 규칙 평가
↓ (통과)
[2] NACL 아웃바운드 규칙 평가
↓ (통과)
인터넷
서브넷 내부 통신
같은 서브넷 내 EC2 간 통신:
- NACL: 평가 안 함 (서브넷을 벗어나지 않음)
- Security Group: 평가함 (인스턴스 레벨)
언제 무엇을 사용할까?
Security Group만으로 충분한 경우
- 인스턴스별 세밀한 접근 제어가 필요할 때
- 특정 IP를 차단할 필요가 없을 때
- Security Group 참조로 동적 IP 대응이 필요할 때
NACL이 필요한 경우
- 특정 IP/IP 대역 차단이 필요할 때 (DDoS, 악성 IP)
- 서브넷 레벨의 기본 방어선이 필요할 때
- 규정 준수를 위한 2계층 보안이 필요할 때
권장 아키텍처: 2계층 보안
┌─────────────────────────────────────────┐
│ VPC │
│ ┌─────────────────────────────────────┐│
│ │ 퍼블릭 서브넷 ││
│ │ NACL: 알려진 악성 IP 차단 ││
│ │ ┌───────────────────────────────┐ ││
│ │ │ EC2 (웹 서버) │ ││
│ │ │ SG: 80, 443 허용 │ ││
│ │ └───────────────────────────────┘ ││
│ └─────────────────────────────────────┘│
│ ┌─────────────────────────────────────┐│
│ │ 프라이빗 서브넷 ││
│ │ NACL: 프라이빗 서브넷 간 통신만 ││
│ │ ┌───────────────────────────────┐ ││
│ │ │ RDS (데이터베이스) │ ││
│ │ │ SG: 3306, 소스=웹서버SG │ ││
│ │ └───────────────────────────────┘ ││
│ └─────────────────────────────────────┘│
└─────────────────────────────────────────┘
필터링되지 않는 트래픽
Security Group과 NACL 모두 다음 트래픽은 필터링하지 않습니다:
- Amazon DNS (Route 53 Resolver)
- DHCP
- EC2 인스턴스 메타데이터 (169.254.169.254)
- Amazon Time Sync Service
- Windows 라이선스 활성화
- VPC 라우터의 예약 IP 주소
SAA-C03 시험 출제 포인트
- ✅ Stateful vs Stateless: Security Group = Stateful (응답 자동), NACL = Stateless (응답도 규칙 필요)
- ✅ 적용 레벨: Security Group = 인스턴스, NACL = 서브넷
- ✅ 규칙 평가: Security Group = 모두 종합, NACL = 번호 순서대로
- ✅ 거부 규칙: Security Group = 허용만, NACL = 허용+거부
- ✅ 임시 포트: NACL에서 응답 트래픽을 위해 1024-65535 허용 필요
시험 팁
시험 문제 예시: "EC2 인스턴스가 인터넷에서 HTTP 요청을 받지만 응답을 보내지 못합니다. Security Group 아웃바운드는 모두 허용입니다. 원인은?" → 정답: NACL 아웃바운드에 임시 포트(1024-65535)가 허용되지 않음 (NACL은 Stateless!)
자주 묻는 질문 (FAQ)
Q: Security Group에서 특정 IP를 차단할 수 있나요?
아니요. Security Group은 허용 규칙만 지원합니다. 특정 IP를 차단하려면 NACL의 거부(Deny) 규칙을 사용해야 합니다.
Q: NACL 규칙 번호는 어떻게 설정하는 게 좋나요?
100 단위로 증분하는 것이 좋습니다 (100, 200, 300...). 나중에 중간에 규칙을 삽입해야 할 때 (예: 150) 유연하게 대응할 수 있습니다.
Q: 기본 NACL과 커스텀 NACL의 차이는?
- 기본 NACL: VPC 생성 시 자동 생성, 모든 트래픽 허용이 기본
- 커스텀 NACL: 사용자가 생성, 모든 트래픽 거부가 기본
Q: 같은 서브넷 내 EC2 간 통신에 NACL이 적용되나요?
아니요. NACL은 서브넷 경계에서만 적용됩니다. 같은 서브넷 내 통신은 Security Group만 적용됩니다.
Q: Security Group을 소스로 참조하면 어떤 장점이 있나요?
IP 주소가 변경되어도 규칙을 수정할 필요가 없습니다. 예를 들어 Auto Scaling으로 인스턴스가 추가/삭제되어도 해당 Security Group에 연결되어 있으면 자동으로 접근이 허용됩니다.
Q: 두 가지를 모두 사용해야 하나요?
Security Group은 필수, NACL은 선택입니다. 하지만 **2계층 보안(Defense in Depth)**을 위해 둘 다 사용하는 것이 권장됩니다. 특히 특정 IP 차단이 필요하면 NACL이 필수입니다.