AWS에서 방화벽이라고 하면 많은 사람들이 Security Group이나 AWS WAF를 먼저 떠올립니다. 하지만 Security Group은 리소스 단위 접근 제어에 가깝고, AWS WAF는 웹 요청을 검사하는 웹 애플리케이션 방화벽입니다.
이번 글에서는 웹방화벽인 AWS WAF는 제외하고, VPC 네트워크 트래픽을 검사하고 통제하는 AWS Network Firewall을 중심으로 정리해보겠습니다.
AWS Network Firewall이란?
AWS Network Firewall은 Amazon VPC 안에서 동작하는 관리형 네트워크 방화벽 서비스입니다.
쉽게 말하면 VPC 안팎으로 이동하는 트래픽을 중앙에서 검사하고, 허용하거나 차단할 수 있는 서비스입니다. 기존 온프레미스 환경에서 사용하던 방화벽, IDS, IPS 개념을 AWS VPC 환경에 맞게 관리형 서비스로 제공한다고 볼 수 있습니다.
AWS Network Firewall은 다음과 같은 상황에서 사용합니다.
| 사용 목적 | 설명 |
| 인터넷 아웃바운드 통제 | Private Subnet의 서버가 외부 인터넷으로 나가는 트래픽 검사 |
| 인바운드 트래픽 검사 | 인터넷에서 VPC 내부로 들어오는 트래픽 필터링 |
| VPC 간 트래픽 검사 | 여러 VPC 사이의 통신을 중앙 방화벽에서 검사 |
| 악성 도메인/IP 차단 | 알려진 악성 IP, 의심 도메인, 봇넷 통신 차단 |
| 침입 탐지/차단 | Suricata 호환 룰을 활용한 IDS/IPS 성격의 검사 |
| 중앙 보안 아키텍처 | Transit Gateway와 함께 중앙 검사 VPC 구성 |
Security Group과 무엇이 다른가?
AWS를 처음 배울 때는 Security Group만으로도 방화벽처럼 보입니다. 하지만 Security Group과 AWS Network Firewall은 목적이 다릅니다.
| 구분 | Security Group | AWS Network Firewall |
| 적용 단위 | EC2, ENI, RDS, ALB 등 리소스 단위 | VPC 트래픽 경로 |
| 동작 방식 | Stateful 접근 제어 | Stateless + Stateful 트래픽 검사 |
| 주요 목적 | 어떤 리소스에 누가 접근 가능한지 제어 | 네트워크 흐름 자체를 검사하고 차단 |
| 룰 수준 | IP, 포트, 프로토콜 중심 | IP, 포트, 프로토콜, 도메인, Suricata 룰 등 |
| 로깅 | 제한적 | Flow Log, Alert Log, TLS Log 지원 |
| 대표 사용처 | EC2는 ALB에서만 접근 허용 | 모든 아웃바운드 인터넷 트래픽 검사 |
Security Group은 “이 서버의 443 포트는 ALB에서만 접근 가능하다”처럼 리소스 접근 제어에 강합니다.
반면 AWS Network Firewall은 “이 VPC에서 외부로 나가는 모든 트래픽을 검사하고, 악성 도메인이나 의심스러운 패턴은 차단하겠다”에 가깝습니다.
즉, Security Group을 대체하는 서비스가 아니라 Security Group 위에 추가하는 네트워크 보안 계층입니다.
AWS Network Firewall의 핵심 구성 요소
AWS Network Firewall을 이해하려면 네 가지 구성 요소를 알아야 합니다.
AWS Network Firewall
├─ Firewall
├─ Firewall Policy
├─ Rule Group
│ ├─ Stateless Rule Group
│ └─ Stateful Rule Group
└─ Firewall Endpoint
1. Firewall
Firewall은 실제로 VPC에 배포되는 방화벽 리소스입니다.
방화벽을 생성하면 선택한 VPC와 가용 영역에 방화벽 엔드포인트가 생성됩니다. 이 엔드포인트는 트래픽이 지나가야 하는 검사 지점 역할을 합니다.
중요한 점은 AWS Network Firewall을 생성했다고 해서 트래픽이 자동으로 검사되는 것은 아니라는 점입니다.
트래픽이 방화벽 엔드포인트를 지나가도록 Route Table을 수정해야 합니다.
2. Firewall Policy
Firewall Policy는 방화벽에 어떤 규칙을 적용할지 정의하는 정책입니다.
Firewall Policy 안에는 Stateless Rule Group과 Stateful Rule Group을 연결할 수 있습니다.
쉽게 말하면 Firewall이 실제 장비라면, Firewall Policy는 그 장비에 적용할 보안 정책 묶음입니다.
Firewall
↓
Firewall Policy
↓
Rule Group
3. Rule Group
Rule Group은 실제 검사 규칙의 모음입니다.
AWS Network Firewall의 Rule Group은 크게 두 종류로 나뉩니다.
| 구분 | 설명 |
| Stateless Rule Group | 각 패킷을 독립적으로 검사 |
| Stateful Rule Group | 연결 흐름을 추적하면서 트래픽 검사 |
Stateless Rule
Stateless Rule은 각 패킷을 독립적으로 검사합니다.
예를 들어 다음과 같은 규칙을 만들 수 있습니다.
- 특정 출발지 IP 차단
- 특정 목적지 IP 차단
- 특정 프로토콜 차단
- 특정 포트 차단
Stateless Rule은 빠르게 동작하지만, 연결 상태를 깊게 이해하지는 않습니다. 따라서 단순한 IP, 포트, 프로토콜 기반 필터링에 적합합니다.
Stateful Rule
Stateful Rule은 트래픽 흐름을 추적하면서 검사합니다.
예를 들어 클라이언트가 서버에 연결을 시작했고, 그 응답이 어떤 흐름에 속하는지를 이해합니다. 그래서 단순 패킷 필터링보다 더 정교한 보안 정책을 만들 수 있습니다.
Stateful Rule에서는 Suricata 호환 규칙을 사용할 수 있습니다. Suricata는 오픈소스 IDS/IPS 엔진으로, 네트워크 위협 탐지와 차단에 자주 사용됩니다.
예를 들어 다음과 같은 정책을 구성할 수 있습니다.
- 특정 도메인으로 나가는 트래픽 차단
- 악성 IP와의 통신 차단
- 알려진 공격 시그니처 탐지
- 의심스러운 네트워크 패턴 차단
4. Firewall Endpoint
Firewall Endpoint는 실제 트래픽이 지나가는 검사 지점입니다.
AWS Network Firewall을 VPC에 배포하면 가용 영역별로 방화벽 엔드포인트가 생성됩니다. 이후 Route Table에서 트래픽의 다음 홉을 이 엔드포인트로 지정해야 합니다.
예를 들어 Private Subnet의 EC2가 인터넷으로 나가는 구조를 생각해보겠습니다.
일반적인 구조는 다음과 같습니다.
Private Subnet EC2
↓
NAT Gateway
↓
Internet Gateway
↓
Internet
AWS Network Firewall을 넣으면 다음처럼 바뀝니다.
Private Subnet EC2
↓
AWS Network Firewall Endpoint
↓
NAT Gateway
↓
Internet Gateway
↓
Internet
즉, 방화벽은 트래픽 경로에 끼워 넣는 방식으로 동작합니다.
대표 아키텍처 1: 아웃바운드 트래픽 검사
가장 많이 사용하는 구조는 Private Subnet의 서버가 인터넷으로 나갈 때 AWS Network Firewall을 통과하게 만드는 방식입니다.
Private Subnet
↓
Network Firewall Endpoint
↓
NAT Gateway
↓
Internet Gateway
↓
Internet
이 구조에서는 EC2, ECS, EKS 노드, Lambda ENI 등이 외부 인터넷으로 나갈 때 방화벽을 거칩니다.
활용 예시는 다음과 같습니다.
| 예시 | 설명 |
| 악성 도메인 차단 | 서버가 C2 서버나 악성 도메인으로 통신하지 못하게 차단 |
| 비인가 포트 차단 | 80, 443 외의 외부 통신 제한 |
| 외부 API 접근 통제 | 허용된 API 도메인만 접근 허용 |
| 데이터 유출 방지 | 의심스러운 외부 목적지로 나가는 트래픽 탐지 |
특히 운영 환경에서는 “서버가 외부 인터넷으로 아무 곳이나 나갈 수 있는 구조”가 위험합니다. AWS Network Firewall은 이런 아웃바운드 트래픽을 중앙에서 통제할 수 있게 해줍니다.
대표 아키텍처 2: 인바운드 트래픽 검사
인터넷에서 VPC 내부로 들어오는 트래픽을 검사할 수도 있습니다.
Internet
↓
Internet Gateway
↓
Network Firewall Endpoint
↓
Public 또는 Private Subnet
↓
Application
다만 이 구조를 사용할 때는 라우팅 설계가 중요합니다. 인바운드 방향만 방화벽을 거치고 응답 트래픽은 다른 경로로 나가면 비대칭 라우팅 문제가 발생할 수 있습니다.
방화벽은 트래픽 흐름을 추적하기 때문에, 들어오는 경로와 나가는 경로가 일관되게 설계되어야 합니다.
대표 아키텍처 3: 중앙 검사 VPC
여러 VPC를 운영하는 조직에서는 각 VPC마다 방화벽을 따로 두기보다, 중앙 검사 VPC를 구성하는 경우가 많습니다.
Spoke VPC A
Spoke VPC B
Spoke VPC C
↓
Transit Gateway
↓
Inspection VPC
↓
AWS Network Firewall
↓
NAT Gateway / Internet Gateway
이 구조의 장점은 보안 정책을 중앙에서 관리할 수 있다는 것입니다.
여러 애플리케이션 VPC가 있더라도 인터넷으로 나가는 트래픽을 중앙 검사 VPC로 모은 뒤, AWS Network Firewall에서 일괄 검사할 수 있습니다.
다만 이 구조는 Transit Gateway, Route Table, NAT Gateway, 방화벽 엔드포인트 라우팅을 함께 설계해야 하므로 단일 VPC 구조보다 복잡합니다.
AWS Network Firewall에서 가능한 보안 정책
AWS Network Firewall에서는 다양한 방식으로 트래픽을 제어할 수 있습니다.
| 정책 유형 | 예시 |
| IP 기반 제어 | 특정 IP 대역 차단 또는 허용 |
| 포트 기반 제어 | 22, 3389 등 위험 포트 차단 |
| 프로토콜 기반 제어 | TCP, UDP, ICMP 등 제어 |
| 도메인 기반 제어 | 특정 도메인으로 나가는 트래픽 차단 |
| 시그니처 기반 탐지 | 알려진 공격 패턴 탐지 |
| 관리형 룰 사용 | AWS가 제공하는 Managed Rule Group 사용 |
| Suricata 룰 사용 | 자체 IDS/IPS 룰 적용 |
예를 들어 운영 서버가 외부로 나갈 때 다음과 같은 정책을 만들 수 있습니다.
허용:
- 회사에서 사용하는 패키지 저장소
- AWS API 엔드포인트
- 운영에 필요한 외부 SaaS API
차단:
- 알려진 악성 IP
- 의심 도메인
- 불필요한 외부 포트
- 비인가 국가 또는 네트워크 대역
로깅과 모니터링
방화벽은 차단만큼이나 로그가 중요합니다.
AWS Network Firewall은 다음과 같은 로그를 남길 수 있습니다.
| 로그 유형 | 설명 |
| Flow Log | 방화벽을 통과한 트래픽 흐름 정보 |
| Alert Log | Stateful Rule에 의해 탐지 또는 차단된 이벤트 |
| TLS Log | TLS 검사와 관련된 이벤트 |
로그는 보통 다음 목적지로 보낼 수 있습니다.
- Amazon CloudWatch Logs
- Amazon S3
- Amazon Data Firehose
운영 환경에서는 최소한 Alert Log는 활성화하는 것이 좋습니다. 보안 이벤트가 발생했을 때 어떤 출발지에서 어떤 목적지로 통신하려 했는지 확인할 수 있기 때문입니다.
대규모 환경에서는 S3에 로그를 저장하고 Athena로 분석하거나, Firehose를 통해 SIEM으로 전달하는 구성이 자주 사용됩니다.
설계할 때 주의할 점
AWS Network Firewall은 강력하지만, 잘못 설계하면 비용과 운영 복잡도가 커질 수 있습니다.
1. 라우팅이 핵심이다
AWS Network Firewall은 생성만으로 동작하지 않습니다.
반드시 Route Table에서 트래픽이 방화벽 엔드포인트를 지나가도록 구성해야 합니다.
잘못된 생각:
방화벽을 만들면 자동으로 VPC 트래픽이 검사된다.
정확한 이해:
방화벽 엔드포인트를 트래픽 경로에 넣어야 검사된다.
2. 대칭 라우팅을 고려해야 한다
Stateful 검사를 사용하는 경우 요청과 응답이 동일한 방화벽 경로를 지나도록 설계해야 합니다.
비대칭 라우팅이 발생하면 방화벽이 트래픽 흐름을 제대로 추적하지 못할 수 있습니다.
3. 가용 영역별로 설계해야 한다
AWS Network Firewall은 가용 영역별 엔드포인트를 사용합니다.
운영 환경에서는 단일 AZ가 아니라 여러 AZ에 방화벽 엔드포인트를 배치하고, 각 AZ의 트래픽은 같은 AZ의 방화벽 엔드포인트를 지나가도록 설계하는 것이 좋습니다.
이렇게 하면 가용성을 높이고 불필요한 교차 AZ 트래픽 비용도 줄일 수 있습니다.
4. 비용을 반드시 고려해야 한다
AWS Network Firewall은 방화벽 엔드포인트 시간 요금과 데이터 처리량 요금이 발생합니다.
또한 NAT Gateway, Transit Gateway, 로그 저장 비용까지 함께 고려해야 합니다.
특히 모든 아웃바운드 트래픽을 방화벽으로 보내는 구조에서는 데이터 처리량이 많아질수록 비용이 커질 수 있습니다.
따라서 다음과 같은 기준으로 설계하는 것이 좋습니다.
- 모든 트래픽을 검사할 것인가?
- 인터넷 방향 트래픽만 검사할 것인가?
- VPC 간 트래픽도 검사할 것인가?
- 로그를 전부 저장할 것인가, Alert Log만 저장할 것인가?
- 중앙 검사 VPC를 둘 것인가, 각 VPC에 분산 배치할 것인가?
AWS Network Firewall을 언제 써야 할까?
다음 상황이라면 AWS Network Firewall 도입을 검토할 만합니다.
| 상황 | 도입 필요성 |
| 운영 서버의 인터넷 아웃바운드를 통제해야 한다 | 높음 |
| 여러 VPC의 외부 통신을 중앙에서 검사해야 한다 | 높음 |
| 보안 감사에서 네트워크 트래픽 검사 요구가 있다 | 높음 |
| 악성 IP/도메인 통신을 차단해야 한다 | 높음 |
| 단순히 EC2 포트만 열고 닫으면 된다 | 낮음 |
| 웹 공격만 막고 싶다 | AWS WAF 영역이므로 별도 검토 |
즉, AWS Network Firewall은 “웹 요청 방어”보다 “VPC 네트워크 트래픽 검사”에 적합합니다.
웹 애플리케이션의 SQL Injection, XSS, URI 기반 차단은 AWS WAF가 담당하고, VPC 내부 리소스의 네트워크 통신 통제는 AWS Network Firewall이 담당한다고 이해하면 됩니다.
실무형 권장 구성
일반적인 운영 환경에서는 다음과 같은 구성을 추천합니다.
Public 영역
- ALB, NAT Gateway, Internet Gateway
Private 영역
- EC2, ECS, EKS, RDS 등 실제 워크로드
보안 영역
- AWS Network Firewall Endpoint
- Firewall Policy
- Stateful Rule Group
- Alert Log 저장
아웃바운드 중심 구성은 다음과 같습니다.
Private Subnet Workload
↓
Route Table
↓
AWS Network Firewall Endpoint
↓
NAT Gateway
↓
Internet Gateway
↓
Internet
이렇게 구성하면 Private Subnet의 서버가 외부로 나가는 모든 트래픽을 방화벽에서 검사할 수 있습니다.
운영 체크리스트
AWS Network Firewall을 운영할 때는 다음 항목을 점검하는 것이 좋습니다.
[ ] 보호할 트래픽 범위가 명확한가?
[ ] Route Table이 방화벽 엔드포인트를 경유하도록 설정되어 있는가?
[ ] 요청과 응답 경로가 대칭으로 구성되어 있는가?
[ ] AZ별 방화벽 엔드포인트가 구성되어 있는가?
[ ] Stateful Rule과 Stateless Rule의 역할이 구분되어 있는가?
[ ] Alert Log가 활성화되어 있는가?
[ ] 로그 저장 위치와 보관 기간이 정해져 있는가?
[ ] 비용 산정에 엔드포인트, 데이터 처리량, NAT Gateway, 로그 비용이 포함되어 있는가?
[ ] 보안 정책 변경 절차가 정해져 있는가?
[ ] 테스트 환경에서 차단 정책을 먼저 검증했는가?
마무리
AWS Network Firewall은 VPC 환경에서 네트워크 트래픽을 중앙에서 검사하고 통제하기 위한 관리형 방화벽 서비스입니다.
Security Group이 리소스 단위의 기본 접근 제어라면, AWS Network Firewall은 VPC 트래픽 흐름 자체를 검사하는 보안 계층입니다.
특히 운영 환경에서 외부 인터넷으로 나가는 트래픽을 제한하거나, 여러 VPC의 트래픽을 중앙에서 검사해야 한다면 AWS Network Firewall은 매우 유용한 선택지가 됩니다.
다만 방화벽을 생성하는 것보다 더 중요한 것은 라우팅 설계입니다. 트래픽이 방화벽 엔드포인트를 지나가도록 Route Table을 정확히 구성해야 하며, Stateful 검사를 사용할 경우 대칭 라우팅도 반드시 고려해야 합니다.
정리하면 AWS Network Firewall은 다음과 같이 이해할 수 있습니다.
Security Group = 리소스 단위 접근 제어
Network ACL = 서브넷 단위 보조 통제
AWS Network Firewall = VPC 트래픽 검사 및 차단
웹방화벽이 웹 요청을 검사한다면, AWS Network Firewall은 VPC 네트워크 흐름을 검사합니다. 이 차이를 이해하면 AWS 보안 아키텍처를 훨씬 명확하게 설계할 수 있습니다.
'클라우드' 카테고리의 다른 글
| AWS Client VPN이란? 원격 사용자를 AWS VPC에 안전하게 연결하는 관리형 VPN (0) | 2026.06.13 |
|---|---|
| Bastion Host 없이 EC2에 접속하기: AWS Session Manager와 EC2 Instance Connect Endpoint (0) | 2026.06.13 |
| Amazon ECS 보안 점검 항목 정리: 태스크 정의에서 반드시 확인해야 할 7가지 설정 (0) | 2026.06.12 |
| AWS 태그 설계 가이드: 비용, 보안, 운영을 연결하는 가장 기본적인 거버넌스 (1) | 2026.06.10 |
| EC2 Image Builder 이해하기: 골든 AMI를 자동으로 만들고 관리하는 AWS 서비스 (1) | 2026.06.09 |
