SG·NACL·Network Firewall·PrivateLink로 만드는 VPC 보안과 네트워크 격리
_Category: Network Security_
보안 사고 중 상당수는 "어디서 어디로 트래픽이 흘렀는가"를 추적하지 못해서 발생합니다. AWS에서 네트워크 격리는 방화벽 규칙 몇 줄이 아니라, 계정 → VPC → 서브넷 → ENI에 이르는 다층 경계로 설계됩니다. 이 글에서는 SCS-C03에서 84개 문제가 출제될 만큼 비중이 높은 VPC 네트워크 보안 토픽을 구조적으로 풀어봅니다.
---
VPC 격리의 다층 구조: 계정 → VPC → 서브넷 → ENI
AWS에서 네트워크 격리는 거대한 러시아 마트료시카 인형처럼 겹겹이 쌓인 경계로 구성됩니다.
가장 바깥 경계는 AWS 계정입니다. 서로 다른 계정의 VPC는 명시적으로 연결하지 않는 한 완전히 격리됩니다. 그다음이 VPC입니다. 하나의 계정 안에서도 여러 VPC를 만들어 환경(개발·스테이징·운영)을 분리하거나, 워크로드 특성에 따라 격리할 수 있습니다. VPC 안에서는 서브넷으로 Public Zone과 Private Zone을 나눕니다. Public Subnet은 Internet Gateway(IGW)로 인터넷과 직접 연결되고, Private Subnet은 NAT Gateway를 통해 아웃바운드 트래픽만 허용합니다. 가장 안쪽 경계는 ENI(Elastic Network Interface)입니다. 각 EC2 인스턴스의 ENI에 Security Group이 붙어 인스턴스 단위의 접근 제어가 이루어집니다.
라우팅 관점에서 Route Table은 트래픽의 흐름 방향을 결정합니다. Public Subnet의 Route Table에는 경로가 있고, Private Subnet에는 경로가 있습니다. Route Table이 없으면 아무리 Security Group을 열어도 패킷이 목적지에 도달하지 못합니다. VPC 피어링 문제가 나올 때 "라우팅 테이블에 피어링 경로가 추가되어 있는가"를 항상 확인해야 하는 이유가 여기에 있습니다.
중앙 집중식 네트워크 통제가 필요한 엔터프라이즈 환경에서는 AWS RAM을 통한 Shared VPC 패턴을 사용합니다. 중앙 계정이 서브넷의 CIDR·라우팅·NACL을 통제하면서 각 워크로드 계정은 그 서브넷에서 EC2·RDS 등을 독립적으로 배포할 수 있습니다.
---
Security Group과 Network ACL의 결정적 차이: Stateful vs Stateless
Security Group은 각 직원 자리 옆 출입증 리더기입니다. 누군가 들어오면 인식하고, 나갈 때는 "아까 들어온 사람이구나" 하고 자동으로 허용합니다. 이것이 Stateful(상태 저장)입니다. 반면 Network ACL은 건물 입구 경비실입니다. 들어올 때 규칙 확인, 나갈 때 또 다른 규칙 확인 — 기억하지 않고 매번 새로 판단합니다. 이것이 Stateless(상태 비저장)입니다.
| 항목 | Security Group | Network ACL | |------|---------------|-------------| | 적용 범위 | ENI (인스턴스 수준) | 서브넷 수준 | | 상태 처리 | Stateful — 응답 트래픽 자동 허용 | Stateless — 인바운드·아웃바운드 별도 규칙 필요 | | 기본 동작 | 모두 차단 (명시적 허용만 동작) | 기본 VPC는 모두 허용, 직접 생성 시 모두 차단 | | 규칙 형식 | 허용 규칙만 존재 (거부 불가) | 허용·거부 규칙 모두 가능, 번호 순서대로 평가 | | 참조 방식 | 다른 SG ID를 소스로 참조 가능 (동일 리전) | IP/CIDR만 참조 가능 | | 변경 반영 | 즉시 반영 | 즉시 반영 |
실무에서 중요한 포인트는 Security Group의 "거부 불가" 특성입니다. 특정 IP를 명시적으로 차단하고 싶다면 Security Group만으로는 불가능하고 Network ACL의 DENY 규칙을 사용해야 합니다. 또한 Network ACL은 번호(낮은 번호 우선) 순서대로 규칙을 평가하기 때문에, DENY 규칙을 ALLOW 규칙보다 낮은 번호에 놓아야 효과가 있습니다.
교차 리전 VPC 피어링에서는 Security Group ID 참조가 지원되지 않습니다. 동일 리전 피어링에서는 상대 VPC의 SG ID를 소스로 참조할 수 있지만, 교차 리전이면 반드시 CIDR 블록(예: 10.0.0.0/16)을 소스로 지정해야 합니다.
!보안 그룹(SG) vs 네트워크 ACL
VPC Flow Logs로 트래픽 가시성 확보하기
VPC Flow Logs는 ENI 수준에서 소스 IP·목적지 IP·포트·프로토콜·ACCEPT/REJECT 여부를 기록하여 CloudWatch Logs 또는 S3로 전송합니다. 허용되어야 할 트래픽이 차단될 때 REJECT 필드로 Security Group·NACL 중 어디서 막혔는지 파악할 수 있습니다.
다만 Flow Logs는 ENI 수준 기록이므로 NLB 내부 대상 그룹의 동작은 탐지하기 어렵습니다. PrivateLink 장애 시나리오에서 Interface Endpoint가 정상이지만 트래픽이 도달하지 않을 때, Flow Logs로 원인을 잡지 못하는 이유가 바로 이것입니다. NLB 대상 그룹의 EC2 Security Group이나 NACL에서 차단되고 있어도 Flow Logs는 이를 보여주지 못합니다.
Route 53 Resolver Query Logging을 함께 사용하면 DNS 쿼리 패턴도 가시화할 수 있습니다. 어떤 인스턴스가 알 수 없는 외부 도메인에 쿼리를 보내는지 확인하여 C2(Command & Control) 통신 탐지에 유용합니다.
---
AWS Network Firewall과 GWLB 기반 3rd-party 방화벽
Security Group과 Network ACL이 기본 방어선이라면, AWS Network Firewall은 심층 패킷 검사(DPI)가 가능한 고급 방어선입니다.
Network Firewall은 VPC 안에 전용 Firewall Subnet을 만들고, 트래픽이 이 Firewall Subnet을 반드시 통과하도록 Route Table을 조작하는 방식으로 동작합니다. Stateless 규칙(5-tuple 기반 빠른 매칭)과 Stateful 규칙(IPS/IDS 수준의 심층 검사)을 모두 지원하며, Suricata 호환 규칙을 사용할 수 있습니다. URL 필터링, 도메인 기반 차단(예: 패턴), TLS 검사도 가능합니다.
Gateway Load Balancer(GWLB)는 3rd-party 방화벽 어플라이언스(Palo Alto, Fortinet 등)를 AWS 네트워크에 투명하게 삽입하는 방법입니다. GWLB는 GENEVE 터널링을 사용하여 원본 패킷을 수정하지 않고 방화벽 어플라이언스로 전달합니다. 어플라이언스가 검사를 마치면 GWLB를 통해 원래 목적지로 돌려보냅니다.
| 항목 | AWS Network Firewall | GWLB + 3rd-party Firewall | |------|---------------------|---------------------------| | 관리 주체 | AWS 완전관리형 | 고객이 어플라이언스 직접 관리 | | 커스터마이징 | Suricata 규칙, 도메인 필터링 | 어플라이언스 기능 전체 활용 가능 | | 확장성 | 자동 스케일 아웃 | GWLB가 어플라이언스 풀에 트래픽 분산 | | 적합 시나리오 | 운영 오버헤드 최소화, AWS 네이티브 | 기존 온프레미스 방화벽 정책 그대로 클라우드 이전 | | 가시성 | Network Firewall 알림 → CloudWatch/S3 | 어플라이언스 자체 로그 활용 |
시험에서 "기존 온프레미스 보안 어플라이언스를 그대로 사용하면서 AWS 트래픽을 검사"라는 요구사항이 나오면 GWLB를 선택하고, "AWS 네이티브 IPS로 도메인 기반 필터링"이 필요하면 Network Firewall을 선택하세요.
---
VPC Endpoint와 PrivateLink: 인터넷을 거치지 않는 통신
PrivateLink는 외부 손님이 우리 건물에 들어오지 않고 전용 회의실에서만 만나는 방식입니다. 인터넷 노출 없이 SaaS 서비스나 다른 계정의 서비스를 소비할 수 있습니다.
VPC Endpoint에는 두 가지 유형이 있습니다.
| 항목 | Gateway Endpoint | Interface Endpoint (PrivateLink) | |------|-----------------|----------------------------------| | 지원 서비스 | S3, DynamoDB만 | 대부분의 AWS 서비스 + 커스텀 서비스 | | 구현 방식 | Route Table에 경로 추가 | VPC 안에 ENI(프라이빗 IP) 생성 | | 비용 | 무료 | 시간당 요금 + 데이터 처리 요금 | | 온프레미스 연결 | 불가 (VPC 내부에서만) | 가능 (Direct Connect/VPN 통해 온프레미스에서도 접근) | | Private DNS | 해당 없음 | 활성화 시 서비스 도메인 전체를 VPC Endpoint로 라우팅 |
Interface Endpoint의 Private DNS 설정은 시험 단골 함정입니다. Private DNS를 활성화하면 해당 서비스의 전체 도메인(예: )이 VPC Endpoint IP로 라우팅됩니다. 이 경우 동일 VPC에서 퍼블릭 API에도 접근해야 한다면 의도치 않게 퍼블릭 API 요청이 차단될 수 있습니다. 퍼블릭과 프라이빗 API가 공존하는 환경에서는 Private DNS를 비활성화하고 프라이빗 API용 DNS만 수동으로 구성해야 합니다.
VPC Endpoint Policy는 Endpoint를 통해 접근할 수 있는 리소스 범위를 IAM 정책 언어로 제한합니다. S3 Gateway Endpoint에 정책을 붙여 특정 버킷만 허용하거나, Interface Endpoint 정책으로 특정 API만 호출하도록 제한할 수 있습니다.
AWS Systems Manager Session Manager는 , , 세 가지 Interface Endpoint만 있으면 공용 IP나 Bastion 없이 EC2에 안전하게 접근할 수 있습니다. EC2 Instance Connect Endpoint는 SSH 포트를 인터넷에 열지 않고도 브라우저 기반 SSH 접속을 가능하게 합니다.
---
Transit Gateway·Direct Connect·VPN의 보안 옵션 (MACsec 포함)
멀티 VPC 환경이나 온프레미스 연결이 필요한 경우, Transit Gateway가 허브 역할을 합니다. 수백 개의 VPC와 온프레미스 네트워크를 단일 허브에서 연결하고, Transit Gateway Route Table로 VPC 간 통신 범위를 세밀하게 통제합니다. 개발 VPC와 운영 VPC를 서로 다른 Route Table에 배치하여 격리하거나, Security VPC를 허브로 두고 모든 트래픽이 방화벽을 통과하도록 강제하는 패턴이 자주 출제됩니다.
Direct Connect는 온프레미스와 AWS를 전용 회선으로 연결합니다. MACsec(IEEE 802.1AE)은 Layer 2 홉 단위 암호화를 제공하며, 물리 회선이 도청되더라도 데이터를 보호합니다. 10Gbps·100Gbps 전용 연결 포트에서 활성화할 수 있습니다.
Site-to-Site VPN은 인터넷을 통해 IPsec 터널을 만들어 Direct Connect보다 빠르게 구성할 수 있습니다. Transit Gateway에 연결하면 여러 VPC에 VPN을 손쉽게 확장할 수 있습니다.
AWS Verified Access는 BeyondCorp 스타일의 제로 트러스트 모델입니다. VPN 없이 사용자의 디바이스 상태와 ID를 실시간 검증하여 내부 앱 접근을 허용하며, AWS IAM Identity Center 또는 OIDC 기반 IdP와 통합합니다.
---
시험에서 헷갈리는 VPC 보안 시나리오
84개 문제를 분석해보면 반복적으로 등장하는 함정 패턴이 있습니다.
첫 번째 패턴은 PrivateLink 장애 트러블슈팅입니다. Interface Endpoint가 정상 상태인데 트래픽이 도달하지 않는다면, 서비스 제공자 VPC의 NLB 대상 그룹 EC2 인스턴스의 Security Group과 NACL을 먼저 확인해야 합니다. NLB 자체에는 Security Group이 없지만 뒤의 EC2는 NLB의 프라이빗 IP 또는 VPC CIDR 인바운드를 허용해야 합니다. VPC Flow Logs는 ENI 수준 기록이라 NLB 내부를 보지 못합니다. 점검 순서: 소비자 Endpoint Policy → 제공자 NLB 대상 그룹 SG → NACL.
두 번째 패턴은 교차 리전 VPC 피어링의 Security Group 참조 제약입니다. 동일 리전에서는 상대 VPC의 SG ID를 인바운드 소스로 쓸 수 있지만, 교차 리전에서는 CIDR 블록을 사용해야 합니다.
세 번째 패턴은 Transit Gateway vs AWS RAM VPC 공유 구분입니다. "중앙에서 서브넷을 통제하면서 각 계정이 리소스를 독립 배포"라는 요구사항은 AWS RAM VPC 서브넷 공유입니다. "VPC 간 라우팅 연결"이 필요하면 Transit Gateway입니다.
네 번째 패턴은 DNS Firewall 활용입니다. 악성 도메인으로의 DNS 쿼리를 차단하려면 Route 53 Resolver DNS Firewall을 사용합니다. Security Group이나 NACL은 IP/포트 레이어에서만 동작하므로 도메인 기반 차단에는 적합하지 않습니다.
다섯 번째 패턴은 NLB + mTLS vs ALB 구분입니다. 로드 밸런서에서 TLS를 종료하지 않고 EC2가 직접 mTLS를 처리해야 한다면, TCP 리스너를 가진 NLB를 선택합니다. ALB는 반드시 TLS를 종료하므로 mTLS 패스스루가 불가능합니다.
---
시험 핵심 정리
Security Group은 ENI 수준의 Stateful 방화벽으로 허용 규칙만 존재합니다. Network ACL은 서브넷 수준의 Stateless 필터로 허용·거부 규칙이 모두 있고 번호 낮은 규칙부터 평가합니다. 특정 IP를 명시적으로 차단하고 싶다면 Network ACL의 DENY 규칙을 사용해야 합니다.
Interface Endpoint의 Private DNS를 활성화하면 서비스 도메인 전체가 VPC Endpoint로 라우팅됩니다. 퍼블릭 API와 공존한다면 Private DNS를 비활성화하고 프라이빗 API용 DNS를 수동 구성해야 합니다. Gateway Endpoint(S3·DynamoDB)는 무료·Route Table 방식, Interface Endpoint는 유료·ENI 방식입니다.