중복된 CIDR 환경에서 효과적인 Egress 트래픽 제어를 위한 아키텍처 설계

1. 개요

본 블로그는 AWS Organizations 환경에서 중복된 VPC CIDR로 인해, 다수의 Transit Gateway 및 인터넷 경로를 구성한 기업들이 직면하는 인터넷 트래픽(Egress) 관리 문제를 해결 하는데 도움을 주고자 작성되었습니다. 기업 인수합병, 레거시 네트워크 통합, 또는 대규모 조직 구조 등으로 인해 불가피 하게 중복 IP 주소 공간을 사용하는 환경에서, 효과적으로 Egress 트래픽을 제어하기 위한 아키텍처 설계 가이드를 제공합니다.

문서는 다음과 같은 구조로 구성되어 있습니다.

• Egress 제어를 위한 계층적 접근 방식: NACL, 보안 그룹, AWS Network Firewall, Route 53 DNS Firewall 등 AWS의 핵심 보안 서비스의 동작 방식과 제약을 간략하게 다룹니다..
• 라우팅 문제 분석: 중복 VPC CIDR 환경이 Transit Gateway 라우팅에 미치는 근본적인 제약을 분석하고, Private NAT Gateway와 보조 CIDR을 활용한 해결책을 안내합니다.
• 문제 해결 방안: 앞선 분석을 통합하여 Private NAT Gateway를 활용한 중앙 집중형 보안검사 허브(Inspection VPC) 아키텍처를 도출하고, 트래픽 흐름, 대칭 라우팅 구성, IaC를 통한 자동화, 모니터링 및 문제 해결 방안을 제시합니다.
• 비용 분석: 분산형 모델, 멀티 엔드포인트 모델, 중앙 집중형 모델의 총 소유 비용(TCO)을 비교 분석하고, 중앙 집중형 아키텍처 전환의 재무적 타당성과 ROI 관점의 전략적 가치를 설명합니다.

2. Egress 제어를 위한 계층적 접근 방식

AWS 환경에서 외부로 나가는 트래픽, 즉 Egress 트래픽을 효과적으로 제어하는 것은 데이터 유출 방지, 규제 준수, 악성코드 및 랜섬웨어로부터의 보호를 위한 핵심적인 보안 과제입니다. 성공적인 Egress 제어 전략은 단일 솔루션에 의존하는 것이 아니라, 여러 보안 서비스를 계층적으로 구성하여 심층 방어(Defense-in-Depth) 체계를 구축하는 것에서 시작됩니다.

본 섹션에서는 AWS가 제공하는 네 가지 핵심 보안 서비스인 네트워크 액세스 제어 목록(NACL), 보안 그룹(Security Group), AWS Network Firewall(ANFW), 그리고 Route 53 Resolver DNS Firewall의 기능과 역할을 분석하고, 각 서비스가 Egress 제어 아키텍처에서 어떤 위치를 차지하며 어떤 제약을 가지는지를 설명합니다.

2.1. 경계 방어: 네트워크 액세스 제어 목록 (NACL)

NACL은 Virtual Private Cloud(VPC) 내 서브넷 수준에서 동작하는 보안 계층으로, 서브넷을 오가는 인바운드 및 아웃바운드 트래픽을 제어하는 역할을 합니다. Egress 트래픽 관점에서 NACL은 인스턴스가 위치한 서브넷을 떠나는 트래픽에 대한 첫 번째 방어선으로 기능합니다.

2.1.1. 제어 방식

NACL의 가장 큰 특징은 상태 비저장(Stateless) 방식으로 동작한다는 점입니다. 이는 서브넷을 나가는 아웃바운드 요청을 허용했더라도, 해당 요청에 대한 응답으로 돌아오는 인바운드 트래픽이 자동으로 허용되지 않음을 의미합니다. 따라서 응답 트래픽이 사용하는 임시 포트(Ephemeral Port) 범위(예: 1024-65535)에 대한 인바운드 허용 규칙을 명시적으로 설정해야만 정상적인 통신이 가능합니다.

NACL은 allow(허용)와 deny(거부) 규칙을 모두 지원하여 특정 IP 주소 대역(CIDR)의 접근을 명시적으로 차단할 수 있습니다. 규칙은 1부터 32766까지의 번호를 가지며, 낮은 번호의 규칙부터 순차적으로 평가되어 트래픽이 특정 규칙과 일치하면 즉시 해당 규칙이 적용되고 나머지 규칙은 평가되지 않습니다. 이러한 특성 덕분에 NACL은 알려진 악성 IP 대역이나, 비즈니스상 통신할 필요가 없는 특정 국가의 IP 대역 전체를 서브넷 수준에서 원천 차단하는 광범위한 차단 정책을 구현하는 데 효과적입니다.

2.1.2. 고려사항(제약)

NACL은 강력한 경계 방어 수단이지만, 세분화된 Egress 제어에는 명백한 한계를 가집니다. 첫째, 상태 비저장(Stateless) 특성은 관리의 복잡성을 크게 증가시킵니다. 모든 애플리케이션의 반환 트래픽을 위해 임시 포트 범위를 열어두어야 하므로, 최소 권한 원칙을 정교하게 적용하기 어렵습니다.

둘째, VPC당 NACL은 200개까지 생성 가능하지만, 하나의 NACL에 설정할 수 있는 규칙 수는 기본 20개(인바운드/아웃바운드 각각)로 제한되며, 요청 시 최대 각 40개까지 확장할 수 있습니다. 이 제한은 복잡한 필터링 요구사항을 충족시키기에 부족할 수 있습니다. 또한, 규칙 수가 증가할수록 네트워크 성능에 영향을 줄 수 있습니다.

마지막으로, NACL은 IP 주소, 프로토콜, 포트 번호 기반으로만 트래픽을 제어할 수 있으며, FQDN(Fully Qualified Domain Name)과 같은 L7 수준의 식별자를 기반으로 필터링하는 기능은 제공하지 않습니다.

이러한 한계로 인해 NACL은 Egress 트래픽을 정교하게 제어하기 위한 주력 도구라기보다는, 전체 서브넷에 적용되는 광범위한 ‘거부’ 정책을 설정하는 ‘무딘 도구(Blunt Instrument)’로서의 역할에 가장 적합합니다. 예를 들어, 애플리케이션 서브넷에서 외부로의 SMTP(포트 25) 트래픽을 일괄 차단하거나, 특정 악성 행위와 관련된 것으로 알려진 IP 대역을 차단하는 등의 용도로 활용할 수 있습니다.

2.2. 호스트 수준 방화벽: 보안 그룹 (Security Group)

보안 그룹은 EC2 인스턴스, RDS 인스턴스 등 개별 Elastic Network Interface (ENI) 수준에서 동작하는 가상 방화벽입니다. Egress 트래픽 관점에서 보안 그룹은 인스턴스에서 나가는 트래픽을 제어하는 마지막 관문 역할을 합니다.

2.2.1. 제어 방식

보안 그룹의 가장 중요한 특징은 상태 저장(Stateful) 방식으로 동작한다는 점입니다. 인스턴스에서 나가는 아웃바운드 요청이 보안 그룹 규칙에 의해 허용되면, 해당 요청에 대한 반환 트래픽은 인바운드 규칙과 상관없이 자동으로 허용됩니다. 따라서 NACL과 달리 임시 포트에 대한 복잡한 인바운드 규칙 관리가 필요하지 않습니다.

보안 그룹은 allow 규칙만 지원하며, 명시적으로 허용되지 않은 모든 트래픽은 기본적으로 거부됩니다. 또한, 다른 보안 그룹의 ID를 소스 또는 대상으로 지정할 수 있는 참조 기능을 제공합니다.

1.2.2. 고려사항(제약)

보안 그룹은 상태 저장 기능과 유연성으로 인해 널리 사용되지만, 세밀한 Egress 제어 요구사항을 충족시키기에는 몇가지 제약을 가집니다.

• FQDN/DNS 기반 제어 불가: 보안 그룹 규칙의 대상(Destination)은 IP 주소, CIDR 대역, 접두사 목록(Prefix List), 또는 다른 보안 그룹 ID로만 지정할 수 있습니다. api.github.com과 같은 FQDN을 대상으로 지정할 수 없습니다. 동적으로 IP 주소가 변경되는 최신 클라우드 서비스 및 API에 대한 아웃바운드 트래픽을 제어하는 데 있어 이는 근본적인 제약입니다. 이 문제를 해결하기 위해 고정 EIP(Elastic IP)를 가진 NGINX 포워드 프록시를 별도로 구축하고 해당 프록시의 IP만 보안 그룹에서 허용하는 해결 방법이 사용되기도 하지만, 이는 추가적인 인프라 관리 부담, 지연 시간 증가, 장애 포인트 추가 등의 새로운 문제를 야기합니다.
• DNS 트래픽의 사각지대: 보안 그룹은 VPC의 기본 DNS 해석기(VPC CIDR의 +2 주소, AmazonProvidedDNS)로 향하는 DNS 요청을 차단할 수 없습니다. 따라서 공격자가 DNS 터널링과 같은 기법을 사용하여 보안 그룹의 통제를 완전히 우회하여 데이터를 유출할 수 있는 가능성이 존재 합니다.

이러한 보안 그룹의 FQDN 필터링 불가라는 한계는 AWS Network Firewall과 같은 더 고도화된 Egress 필터링 솔루션의 필요성을 직접적으로 보여주는 기술적 동인(Driver)입니다. 보안 그룹만으로는 도메인 기반의 Egress 제어를 관리 가능하고 안전한 방식으로 구현하는 것이 사실상 불가능 합니다.

2.3. 중앙 집중형 방화벽 : AWS Network Firewall (ANFW)

AWS Network Firewall (ANFW)은 VPC를 보호하기 위한 완전 관리형 네트워크 방화벽 및 침입 방지/탐지 서비스(IPS/IDS)입니다. ANFW는 개별 VPC가 아닌, 여러 VPC의 트래픽을 중앙에서 검사하고 필터링하도록 설계되었으며, Ingress/Egress(North-South, South-North)뿐 아니라, Intra/Inter VPC상의 East/West 검사를 통해서 강력한 중앙 집중형 통제를 가능하게 합니다.

2.3.1. 제어 방식

ANFW는 보안 그룹과 NACL을 뛰어넘는 정교한 제어 기능을 제공합니다.

• 상태 기반 L3-L7 검사: 전통적인 5-튜플 (소스/목적지 IP, 소스/목적지 포트, 프로토콜) 검사를 넘어, FQDN 기반 필터링, 프로토콜 탐지, 암호화되지 않은 웹 트래픽에 대한 웹 필터링 등 L7 수준의 심층 패킷 검사(DPI)를 수행합니다. 이는 보안 그룹의 FQDN 제어 불가 한계를 직접적으로 해결합니다.
• TLS 트래픽 검사: 현재 대부분의 트래픽은 전송간 암호화를 위해서 TLS통신을 사용합니다. 따라서 복호화 없이 악성 행위를 탐지하기가 불가능 합니다. ANFW는 암호화된 트래픽을 복호화하여 검사하는 기능을 지원합니다. 이를 통해 HTTPS 트래픽 내부에 숨겨진 악성 행위나 데이터 유출 시도를 탐지하고 차단할 수 있습니다.
• Suricata 기반 IPS: 오픈소스 IPS 엔진인 Suricata를 통합하여, AWS가 관리하는 위협 인텔리전스 기반 시그니처 또는 사용자가 직접 작성하거나 서드파티에서 제공하는 Suricata 호환 규칙을 사용하여 알려진 취약점 공격, 멀웨어, 무차별 대입 공격 등을 실시간으로 탐지하고 방어할 수 있습니다.
• 중앙 집중식 관리: AWS Firewall Manager와 통합되어 AWS Organizations 내의 모든 계정과 VPC에 걸쳐 방화벽 정책을 중앙에서 일관되게 배포하고 관리할 수 있습니다.
• Active Threat Defense (re:Inforce 2025 발표): re:Inforce 2025에서 발표된 ‘Active Threat Defense’는 기존의 정적 시그니처 기반 방어를 뛰어넘는 동적인 위협 대응 기능을 제공합니다. 이 기능은 AWS가 자체적으로 운영하는 허니팟 네트워크 ‘MadPot’ 등에서 수집한 최신 위협 인텔리전스를 활용하여, 알려진 악성 인프라(멀웨어 C2 서버, 봇넷, 크립토 마이닝 풀 등)와의 통신을 실시간으로 차단합니다. 이 새로운 관리형 규칙 그룹은 보안 운영 부담을 크게 줄여주며, AWS의 글로벌 위협 인텔리전스를 활용하여 Egress 트래픽에 대한 강력하고 자동화된 보호 계층을 추가할 수 있습니다.

2.3.2. 아키텍처적 고려사항 (제약)

ANFW는 단순히 보안 그룹을 대체하는 서비스가 아닙니다. ANFW를 도입하기 위해서는 때로 아키텍처의 변화를 요구하기도 합니다. AWS Network Firewall은 분산형 배포(Distributed), 중앙 집중형 배포(Centralized), 하이브리드 배포 등 다양한 배포 모델을 지원하여 기존 네트워크 토폴로지에 유연하게 적응할 수 있도록 설계되었습니다. 그러나 이러한 유연성에도 불구하고, ANFW의 상태 저장(Stateful) 특성과 L7 심층 패킷 검사(DPI) 기능을 제대로 활용하기 위해서는 네트워크 설계의 핵심 원칙들을 반드시 준수해야 합니다.

가장 중요한 것은 대칭 라우팅(Symmetric Routing) 보장입니다. 특정 세션의 요청 트래픽과 응답 트래픽이 반드시 동일한 ANFW 엔드포인트를 통과해야 하며, 이를 위해 전용 방화벽 서브넷 구성, 라우팅 테이블 설계, 그리고 Transit Gateway를 사용하는 경우에는 ANFW가 배포된 VPC Attachment에 Appliance Mode를 필수적으로 활성화 하여야 합니다. 또한 ANFW 엔드포인트의 배치 위치(VPC 내부 vs 중앙 Inspection VPC)에 따라 트래픽 흐름 패턴이 달라지므로, 기존 애플리케이션의 네트워크 의존성, 지연 시간 요구사항, 대역폭 사용 패턴을 면밀히 분석한 후 최적의 배포 모델을 선택해야 합니다.

특히 중복 CIDR 환경에서는 ANFW의 배포 복잡성이 더 크게 증가합니다. 표준적인 VPC Peering이나 단순한 TGW 연결이 불가능한 상황에서, ANFW를 통한 중앙 집중형 검사를 구현하려면 Private NAT Gateway를 활용한 주소 변환, 보조 CIDR 할당, 다중 라우팅 테이블 조율 등의 고도화된 네트워킹 기법이 동시에 적용되어야 합니다. 이는 단순한 ‘방화벽 추가’가 아닌, 전체 네트워크 아키텍처의 재설계를 의미하며, 구현 전 철저한 설계 검증과 단계적 마이그레이션 계획이 반드시 수반되어야 합니다.

2.4. 게이트 키퍼 : Route 53 Resolver DNS Firewall

Route 53 Resolver DNS Firewall은 네트워크 연결이 시도되기 전인 DNS 해석 단계에서 동작하는 보안 서비스입니다. VPC 내에서 발생하는 DNS 쿼리를 필터링하여 잠재적인 위협을 사전에 차단하는 게이트 키퍼 역할을 합니다.

2.4.1. 제어 방식

DNS Firewall은 도메인 목록을 기반으로 DNS 쿼리에 대해 ALLOW(허용), BLOCK(차단), ALERT(경고) 동작을 정의할 수 있습니다. 이 도메인 목록은 사용자가 직접 정의하는 허용/차단 목록일 수도 있고, AWS가 최신 위협 인텔리전스를 기반으로 관리하는 악성 도메인, C2(Command and Control) 서버 도메인 목록일 수도 있습니다.

특히 re:Invent 2024에서 발표된 ‘Advanced’ 규칙은 머신러닝을 활용하여 기존 시그니처 기반 탐지를 우회하는 DGA(Domain Generation Algorithm)나 DNS 터널링(DNS Tunneling)과 같은 고도화된 위협을 탐지합니다. DGA는 멀웨어가 C2 서버와 통신하기 위해 수많은 도메인 이름을 무작위로 생성하는 기술이며, DNS 터널링은 DNS 쿼리와 응답에 데이터를 숨겨 유출하는 기법입니다.

2.4.2. 고려사항

AWS 기술 블로그”Amazon VPC에서 안전한 DNS 요청 설계하기” 에서 설명하듯, VPC 내부에서 발생하는 Route 53 Resolver(VPC CIDR +2 IP주소)로의 DNS 쿼리는 NAT 게이트웨이나 ANFW와 같은 표준 Egress 경로를 통과하지 않고 AWS 내부의 전용 경로로 처리됩니다. 따라서 공격자는 완벽하게 구성된 중앙 집중형 ANFW 검사 인프라를 DNS 터널링을 통해 우회할 수 있는 가능성이 있습니다.

이러한 보안 우회 가능성을 근본적으로 차단하기 위해, re:Inforce 2025에서 강조된 모범 사례는 네트워크 ACL(NACL)을 사용하여 서브넷에서 외부로 나가는 아웃바운드 UDP/TCP 53번 포트 트래픽을 명시적으로 차단하는 것입니다.(#. Outbound network controls made easy NIS301) VPC 내 워크로드가 Route 53 Resolver를 통해 DNS 쿼리를 수행할 때는 NACL의 영향을 받지 않으므로, 정상적인 Egress 통신은 그대로 유지됩니다.

반면, 이 NACL 규칙은 워크로드가 Resolver를 우회하여 8.8.8.8과 같은 외부 DNS 서버로 직접 쿼리하는 것을 원천적으로 막는 역할을 합니다. 결과적으로 모든 DNS 요청이 DNS Firewall의 통제를 받도록 강제함으로써, DNS 기반 데이터 유출 시도를 효과적으로 방어하는 기반을 마련하게 됩니다.

2.5. 종합: 심층 방어 Egress 전략

네 가지 서비스를 종합하면 다음과 같은 견고한 심층 방어 Egress 전략을 수립할 수 있습니다.

• 1단계 (DNS 해석): Route 53 DNS Firewall
  • 역할: 첫 번째 게이트키퍼. 워크로드가 악성 또는 비인가 도메인을 해석하는 것 자체를 원천 차단하여, 네트워크 패킷이 생성되기 전에 위협을 제거합니다.
• 2단계 (서브넷 경계): 네트워크 ACL (NACL)
  • 역할: 광범위한 거부 정책. 알려진 악성 IP 대역이나 불필요한 프로토콜/포트에 대한 트래픽을 서브넷 수준에서 일괄 차단합니다.
• 3단계 (중앙 검사): AWS Network Firewall (ANFW)
  • 역할: Egress 제어의 핵심 엔진. 중앙 Inspection VPC(제안방안) 또는 분산 배포된 ANFW endpoint를 통해서 NAT G/W로 라우팅 되는 모든 Egress 트래픽에 대해 FQDN 필터링, 심층 패킷 검사, IPS/IDS를 수행하여 정교한 위협을 방어합니다.
• 4단계 (호스트 경계): 보안 그룹 (SG)
  • 역할: 인스턴스 수준에서 허용된 다음 홉(예: TGW Attachment)으로만 트래픽이 나가도록 제한합니다. 또한, SG 참조를 통해 애플리케이션 티어 간의 East-West 트래픽을 정교하게 제어합니다.

표 1: Egress 제어 메커니즘 비교 분석

3. 라우팅 문제 분석 : 중복 VPC CIDR

본 블로그에서 해결 하고자 하는 아키텍처의 가장 큰 기술적 장애물은 다수의 VPC가 동일한 IP 주소 대역(CIDR)을 사용하고 있다는 점입니다. 이 문제는 표준적인 네트워크 연결 방식을 무력화하며, 중앙 집중형 Egress 아키텍처 구현을 가로막는 근본 원인입니다. 본 섹션에서는 이 문제에 대하여 Private NAT Gateway와 보조 CIDR을 활용한 해결 방안과 한계를 알아봅니다.

3.1. Transit Gateway 라우팅 충돌

AWS Transit Gateway(TGW)는 허브-앤-스포크 모델을 통해 수많은 VPC와 온프레미스 네트워크를 연결하는 중앙 라우터 역할을 수행하지만, 명확한 제약 사항이 있습니다. TGW는 중복된 CIDR을 가진 VPC 간의 라우팅을 지원하지 않습니다.

예를 들어, 10.10.0.0/16 CIDR을 사용하는 VPC-A가 이미 TGW에 연결된 상태에서, 동일한 10.10.0.0/16 CIDR을 사용하는 VPC-B를 TGW에 연결하면, TGW는 VPC-B의 라우팅 정보를 자신의 라우팅 테이블에 전파(Propagate)하지 않습니다. TGW 라우팅 테이블에는 10.10.0.0/16 목적지에 대한 경로가 이미 VPC-A로 설정되어 있기 때문에, 동일한 목적지를 가진 새로운 경로를 추가할 수 없어 라우팅 모호성이 발생하기 때문입니다. 이는 AWS의 특정 제약이 아니라, 하나의 라우터가 동일한 목적지 주소에 대해 두 개의 다른 경로를 가질 수 없는 IP 라우팅의 근본 원리에 기인합니다.

이 문제로 인해, 표준적인 VPC Peering 역시 사용할 수 없습니다. 따라서 여러 이유로 중복된 CIDR을 가진 고객분들의 경우, 결국 각 VPC에 독립적인 인터넷 경로를 구성하고, 상호 통신이 필요한 VPC간에 TGW를 여러 대 구성 하는 비효율적이고 비용이 많이 드는 아키텍처를 선택하는 경우가 있습니다.

3.2. 해결방안 : Private NAT Gateway 및 보조 CIDR 패턴

이 라우팅 충돌 문제를 해결하기 위해 검토할 수 있는 것은 각 중복 VPC에 고유하고 라우팅 가능한 보조 IP 공간을 부여하고, Private NAT Gateway와 Load Balancer를 조합하여 트래픽이 TGW에 도달하기 전에 소스 및 목적지 주소를 변환(NAT)하는 것입니다. 이 패턴은 AWS 기술 가이드 문서에서 제시하는 표준 해결책 중 하나입니다.

이 패턴의 핵심은 중복되어 라우팅이 불가능한 IP 주소를 가진 트래픽을 TGW가 이해할 수 있는 고유한 IP 주소로 ‘번역’해주는 것에 있습니다. 이는 양방향 통신을 위해 소스 주소 변환(Source NAT)과 목적지 주소 변환(Destination NAT)이 모두 필요합니다.

3.2.1. 단계별 구현 가이드

다음은 중복 CIDR을 가진 두 VPC(VPC-A, VPC-B) 간의 통신 및 외부 통신을 가능하게 하는 단계별 구현 가이드입니다.

1단계 – 고유한 보조 CIDR 할당: 각 중복 VPC에 TGW 네트워크 전체에서 고유한(Non-overlapping) 보조 CIDR 블록을 추가로 연결합니다. 예를 들어, 두 VPC의 주 CIDR이 10.10.0.0/16으로 동일하다면, VPC-A에는 10.100.1.0/24를, VPC-B에는 10.100.2.0/24를 보조 CIDR로 할당합니다. 이 보조 CIDR은 TGW가 인식하고 라우팅할 수 있는 고유한 주소 공간이 됩니다.

2단계 – 보조 서브넷 생성: 각 VPC 내에서 새로 할당된 보조 CIDR을 사용하여 새로운 서브넷들을 생성합니다. 이 서브넷들은 주소 변환을 위한 네트워크 구성 요소(Private NAT Gateway, Load Balancer)를 배치하는 데 사용됩니다.

3단계 – Private NAT Gateway 배포 (Source NAT): 트래픽을 보내는 소스 VPC(예: VPC-A)의 보조 서브넷에 Private NAT Gateway를 배포합니다. Private NAT Gateway는 인터넷 게이트웨이가 필요 없으며, 내부 트래픽의 소스 IP 주소를 NAT Gateway 자체의 프라이빗 IP(보조 CIDR 대역의 IP)로 변환하는 역할을 합니다. 이를 통해 TGW는 트래픽의 소스를 고유한 주소로 인식하게 됩니다.

4단계 – Load Balancer 배포 (Destination NAT): Egress만 구현한다면 필요하지 않은 부분이지만, 실제로 VPC간 통신이 발생하여야 하기 때문에, 목적지 NAT가 필요하게 됩니다. 트래픽을 받는 목적지 VPC(예: VPC-B)의 보조 서브넷에 Network Load Balancer(NLB) 또는 Application Load Balancer(ALB)를 배포합니다. 이 로드 밸런서는 보조 CIDR 대역의 고유한 IP 주소를 가지게 되며, 로드 밸런서의 대상 그룹(Target Group)에는 실제 애플리케이션 인스턴스(주 CIDR 대역의 IP를 가진)를 등록합니다. 소스 VPC에서는 이 로드 밸런서의 고유 IP로 트래픽을 전송함으로써, 라우팅 불가능한 목적지 주소 문제를 해결합니다.

5단계 – Spoke VPC 라우팅 테이블 구성: 이 단계가 패턴의 핵심입니다. 각 VPC 내의 라우팅 테이블을 정교하게 구성해야 합니다.

• 소스 VPC (VPC-A)의 주 서브넷 라우팅 테이블:
  • 인터넷으로 향하는 모든 트래픽(0.0.0.0/0) 또는 다른 VPC(VPC-B)의 보조 CIDR(10.100.2.0/24)로 향하는 트래픽의 대상을 VPC-A에 생성한 Private NAT Gateway로 지정합니다. 이 규칙은 해당 트래픽이 서브넷을 떠나기 전에 소스 IP 주소 변환을 거치도록 강제합니다.
• 소스 VPC (VPC-A)의 보조 서브넷 (Private NAT Gateway가 위치한) 라우팅 테이블:
  • 인터넷(0.0.0.0/0) 또는 다른 VPC의 보조 CIDR(10.100.2.0/24)로 향하는 트래픽의 대상을 TGW Attachment로 지정합니다. 이를 통해 NAT된 트래픽이 TGW로 전달됩니다.

6단계 – Transit Gateway 라우팅 테이블 구성: TGW 라우팅 테이블의 구성은 매우 간단해집니다. 더 이상 중복되는 주 CIDR을 다룰 필요가 없으며, 고유한 보조 CIDR들만 라우팅하면 됩니다.

• 모든 Spoke VPC에서 오는 트래픽은 TGW를 통해 중앙 Inspection VPC로 전달되도록 0.0.0.0/0 경로를 설정합니다.
• 검사를 마친 트래픽이 목적지 Spoke VPC로 돌아갈 수 있도록, TGW는 각 Spoke VPC의 보조 CIDR에 대한 경로를 가지고 있어야 합니다.

이 두 단계의 주소 변환(Private NAT Gateway를 통한 SNAT, Load Balancer를 통한 DNAT)을 통해, TGW는 완전히 고유하고 라우팅 가능한 소스 및 목적지 주소를 가진 트래픽만 처리하게 됩니다. 이는 중복 CIDR 문제를 근본적으로 해결하고, 중앙 집중형 네트워크 아키텍처를 구현할 수 있는 기반을 마련합니다.

3.3. 구현 시 고려사항 및 장기적 대안

이 패턴은 기술적으로 검증된 해결책이지만, 다음과 같은 복잡성을 수반합니다:

• 운영 복잡성: 각 VPC마다 Private NAT Gateway를 관리해야 하며, 보조 CIDR 할당 및 IP 주소 관리 체계가 필요합니다. 또한 다층 라우팅으로 인해 문제 해결의 복잡성이 증가합니다.
• 성능 영향: 추가적인 NAT 홉으로 인해 지연 시간이 증가(일반적으로 1-2ms)할 수 있으며, Private NAT Gateway 자체의 대역폭 제한(최대 100Gbps)을 고려해야 합니다.
• 비용 영향: VPC별 Private NAT Gateway 비용(시간당 및 데이터 처리), 그리고 VPC 간 통신을 위한 Load Balancer 비용이 추가로 발생합니다.

따라서, 이 패턴은 중복 CIDR 문제를 해결하기 위한 전술적 해결책으로 간주해야 합니다. 장기적인 관점에서는 다음과 같은 근본적인 대안을 고려하는 것이 이상적입니다:

• CIDR 재설계: 신규 VPC에는 반드시 고유한 CIDR을 할당하고, 기존 중복 VPC는 점진적으로 마이그레이션하는 계획을 수립하여 전사적인 IP 관리 정책을 정립합니다.
• AWS PrivateLink 활용: 특정 서비스 간의 통신이 주 목적이라면, NAT 없이 직접 서비스를 연결하여 성능과 보안을 강화하는 PrivateLink 사용을 적극 검토합니다.

4. 효과적인 Egress 트래픽 제어를 위한 아키텍쳐 구현 방안들

4.1. 아키텍처 구현 방안 비교 분석

중복된 CIDR 환경에서 Egress 트래픽 제어를 위한 아키텍처는 크게 세 가지 모델로 구현할 수 있습니다. 각 모델은 비용, 관리 복잡성, 성능 측면에서 장단점이 명확하므로, 조직의 요구사항에 가장 적합한 방식을 선택해야 합니다.

• 모델 A: 중앙 집중형 보안검사 허브: 모든 트래픽을 중앙의 ‘Inspection VPC’로 모아 단일 ANFW에서 일괄적으로 검사하는 AWS 표준 모범 사례입니다.
• 모델 B: 멀티-엔드포인트 분산형 모델 (re:Inforce 2025 소개 ): re:Inforce 2025에서 새롭게 발표된 배포모델입니다. 단일 ANFW 리소스가 여러 Spoke VPC에 논리적 엔드포인트를 배포하여 로컬에서 트래픽을 검사하는 모델입니다.
• 모델 C: 완전 분산형 모델: 각 VPC에 개별 NAT Gateway를 두는 방식에 더해, 각 VPC마다 독립적인 ANFW를 배포하는 모델입니다.

표 2: 아키텍처 구현 방안 비교

4.2. 모델 A: 중앙 집중형 보안검사 허브

4.2.1. 아키텍처 개요

이 아키텍처는 하나의 중앙 ‘허브’ VPC와 다수의 ‘스포크’ VPC로 구성되며, 이들은 AWS Transit Gateway를 통해 연결됩니다.

• 허브: Inspection VPC
  • 이 VPC는 네트워크 보안을 전담하는 중앙 허브 역할을 합니다.
  • 방화벽 서브넷 (Firewall Subnets): 고가용성을 위해 여러 가용 영역(AZ)에 걸쳐 AWS Network Firewall 엔드포인트가 배포되는 전용 서브넷입니다.
  • 공용 서브넷 (Public Subnets): 중앙 집중형 인터넷 Egress를 위해 Public NAT Gateway와 Internet Gateway가 위치하는 서브넷입니다.
  • TGW 연결 서브넷 (TGW Attachment Subnets): Transit Gateway의 ENI가 생성되어 Spoke VPC 및 외부 네트워크와의 연결을 담당하는 서브넷입니다.
• 스포크: 애플리케이션 VPC (Application VPCs)
  • 실제 워크로드가 실행되는 VPC들 입니다.
  • 각 Spoke VPC는 기존의 중복된 주 CIDR을 그대로 유지할 수 있습니다.
  • VPC 외부(인터넷 또는 다른 VPC)와 통신해야 하는 모든 트래픽을 처리하기 위해 *섹션 2에서 설명한 ‘Private NAT Gateway 및 보조 CIDR 패턴’ 을 각 Spoke VPC 내에 구현합니다.
• 연결성: Transit Gateway (TGW)
  • 단일 중앙 TGW가 모든 Spoke VPC와 Inspection VPC를 연결하는 중추 역할을 합니다.
  • TGW는 트래픽 분리 및 검사 라우팅을 위해 여러 개의 라우팅 테이블을 사용하여 정교하게 구성됩니다.

4.2.2. 엔드-투-엔드 트래픽 흐름 분석

1. Egress 트래픽 (Spoke VPC → 인터넷)
   1. 시작: Spoke VPC의 EC2 인스턴스가 인테넷 연결(예:api.github.com)을 시작합니다.
   2. DNS 필터링: DNS 쿼리는 먼저 Route 53 DNS Firewall에서 검사됩니다.
   3. 1차 NAT (SNAT): 인스턴스의 0.0.0.0/0 트래픽은 Spoke VPC 내의 Private NAT Gateway로 라우팅됩니다. 여기서 패킷의 소스 IP는 인스턴스의 원본 IP에서 Private NAT Gateway의 고유한 보조 CIDR IP로 변환됩니다.
   4. TGW 라우팅: NAT 처리된 패킷은 TGW Attachment를 통해 Transit Gateway로 전달됩니다.
   5. 검사 라우팅: TGW는 0.0.0.0/0 경로를 따라 패킷을 Inspection VPC로 보냅니다.
   6. ANFW 검사: Inspection VPC 내에서 패킷은 ANFW 엔드포인트로 라우팅되어 FQDN, 프로토콜 기반의 심층 검사를 받습니다.
   7. 2차 NAT (SNAT): 검사를 통과한 패킷은 Inspection VPC의 Public NAT Gateway로 전달됩니다. 여기서 패킷의 소스 IP는 다시 한번 Public NAT Gateway의 공인 IP로 변환됩니다.
   8. Egress: 최종적으로 패킷은 Internet Gateway를 통해 인터넷으로 나갑니다. 반환 트래픽은 이 경로를 대칭적으로 역행합니다.
2. East-West 트래픽 (Spoke A → Spoke B)
   1. 시작: Spoke A의 인스턴스가 Spoke B의 NLB(고유 보조 CIDR IP 보유)로 연결을 시작합니다.
   2. 1차 NAT (SNAT): Spoke A의 트래픽은 로컬 Private NAT Gateway로 라우팅되어 소스 IP가 Spoke A의 고유 IP로 변환됩니다.
   3. TGW 라우팅: 패킷은 TGW를 통해 Inspection VPC로 전달됩니다.
   4. ANFW 검사: ANFW에서 VPC 간 통신 정책에 따라 트래픽을 검사합니다.
   5. 최종 라우팅: 검사를 통과한 패킷은 TGW를 통해 Spoke B로 라우팅됩니다.
   6. 2차 NAT (DNAT): Spoke B의 NLB는 목적지 주소를 실제 타겟 인스턴스의 중복된 IP로 변환하여 최종 전달합니다.

4.3. 모델 B: 멀티-엔드포인트 분산형 모델 (re:Inforce 2025)

4.3.1. 아키텍처 청사진

이 모델은 re:Inforce 2025에서 발표된 새로운 기능을 기반으로 합니다. 단일 AWS Network Firewall 리소스가 여러 Spoke VPC에 논리적 엔드포인트를 배포하여, 트래픽이 TGW를 거치지 않고 로컬에서 검사되는 방식입니다.

• 중앙 정책, 분산 적용: 방화벽 정책(Rule Group)은 중앙에서 통합 관리하지만, 실제 트래픽 검사는 각 Spoke VPC 내에 위치한 ANFW 엔드포인트에서 수행됩니다.
• Egress 라우팅: 각 Spoke VPC의 애플리케이션 서브넷은 기본 경로(0.0.0.0/0)의 다음 홉으로 로컬 ANFW 엔드포인트를 지정합니다. ANFW 엔드포인트가 위치한 서브넷은 다시 NAT Gateway를 다음 홉으로 지정합니다.

4.3.2. 엔드-투-엔드 트래픽 흐름 분석

1. Egress 트래픽 (Spoke VPC → 인터넷)
   1. 시작: Spoke VPC의 EC2 인스턴스가 api.github.com에 연결을 시작합니다.
   2. DNS 필터링: DNS 쿼리는 Route 53 DNS Firewall에서 검사됩니다.
   3. 로컬 검사: 인스턴스의 0.0.0.0/0 트래픽은 VPC 내의 로컬 ANFW 엔드포인트로 직접 라우팅되어 검사를 받습니다.
   4. NAT 및 Egress: 검사를 통과한 패킷은 VPC 내의 Public NAT Gateway로 전달되어 SNAT 처리된 후, Internet Gateway를 통해 인터넷으로 나갑니다. 이 모델은 TGW를 경유하지 않아 지연 시간이 낮습니다.
2. East-West 트래픽 (Spoke A → Spoke B)
   1. 한계점: 이 모델만으로는 중복 CIDR 환경에서의 VPC 간 통신이 직접적으로 해결되지 않습니다. TGW의 라우팅 기능 없이는 Spoke A가 Spoke B의 주소를 찾을 수 없습니다.
   2. 필요한 해결책: VPC 간 통신을 구현하려면, 이 모델 위에 모델 A와 동일하게 TGW와 Private NAT Gateway 패턴을 추가로 구성해야 합니다. 이 경우, 트래픽은 Spoke A의 로컬 ANFW 엔드포인트에서 1차 검사를 받고, TGW를 통해 Inspection VPC로 가서 2차 검사를 받거나, 또는 복잡한 라우팅을 통해 Spoke B의 로컬 ANFW 엔드포인트로 전달되어야 합니다. 이는 아키텍처를 불필요하게 복잡하게 만들고 비용을 증가시키므로, East-West 트래픽 검사가 필수적인 환경에서는 이 모델이 효과적이지 않을 수 있습니다.

4.4. 모델 C: 완전 분산형 모델

4.4.1. 아키텍처 청사진

각 Spoke VPC에 독립적인 ANFW와 NAT Gateway를 모두 배포하는 모델입니다.

4.4.2. 엔드-투-엔드 트래픽 흐름 분석

• Egress 트래픽 (Spoke VPC → 인터넷): 트래픽 흐름은 모델 B의 Egress 트래픽 흐름과 동일합니다. 모든 검사와 NAT 처리가 각 VPC 내에서 독립적으로 이루어집니다.
• East-West 트래픽 (Spoke A → Spoke B): 모델 B와 마찬가지로, 이 모델은 중복 CIDR 환경에서의 VPC 간 통신 문제를 근본적으로 해결하지 못합니다. VPC 간 통신을 위해서는 별도의 TGW 및 Private NAT Gateway 아키텍처가 필요합니다.

5. 비용분석 : TCO 기반

* 본 비용분석은 각 모델간의 비용 이해를위한 것으로, 모든 조건이 임의로 산정되었습니다. 따라서 실제 환경과는 괴리가있을 수 있습니다. 모델선택을 하기전에 실제 환경에 기반한 비용산정이 별도로 진행 되어야 합니다.

5.1. 각 아키텍처 모델 비용 분석
각 아키텍처 모델의 월간 예상 비용을 10개 VPC, 총 10TB 트래픽을 기준으로 분석했습니다. (US East-1 리전 기준)

5.1.1. 모델 C: 완전 분산형 (As-Is 확장)

• 구분 : 각 10개 VPC에 개별 Public NAT Gateway와 개별 ANFW(2-AZ)를 배포하는 모델.
• 주요 비용:
  • NAT Gateway (10개): $784.80/월
  • ANFW 엔드포인트 (10개, 20-AZ): $5,688/월
  • ANFW 데이터 처리 (10TB): $665.60/월
  • 운영 비용: 가장 높음 (운영 인력 및 소모 시간), 예: $4,700/월

5.1.2. 모델 B: 멀티-엔드포인트 분산형 (가상 시나리오)

• 구분: 중앙 ANFW 리소스 1개, 각 10개 VPC에 ANFW 엔드포인트(2-AZ) 및 Public NAT Gateway 배포. (re:Inforce 2025 발표, 추가 엔드포인트 50% 할인 가정)
• 주요 비용:
  • NAT Gateway (10개): $784.80/월
  • ANFW 엔드포인트 (1 Primary + 9 Secondary): $568.80 + ($568.80 * 0.5 * 9) = $3,128.40/월
  • ANFW 데이터 처리 (10TB): $665.60/월
  • 운영 비용: 중간 (운영 인력 및 소모 시간), 예: $3,000/월

5.1.3. 모델 A: 중앙 집중형 (권장 모델)

• 구분: 중앙 Inspection VPC(ANFW, Public NAT GW), TGW, 각 10개 Spoke VPC에 Private NAT Gateway 배포.
• 주요 비용:
  • 중앙 인프라 (TGW, Public NAT GW): $481.28/월
  • Spoke 인프라 (10x Private NAT GW): $324.00/월
  • 데이터 처리 (TGW, NAT, ANFW): $1,336.00/월
  • 보안 서비스 (ANFW Endpoint, DNS FW): $578.80/월
  • 운영 비용 : 가장 낮음(운영 인력 및 소모시간), 예 : $2,000/월

5.2. 총 소유 비용(TCO) 비교 분석

표 3: 3가지 아키텍처 월간 TCO 비교

3년 TCO 분석 (마이그레이션 비용 $50,000 포함 시):

• 모델 C (완전 분산형): $11,838.40 × 36 = $426,182.40
• 모델 B (멀티-엔드포인트): ($7,588.80 × 36) + $50,000 = $323,196.80
• 모델 A (중앙 집중형): ($4,224.24 × 36) + $50,000 = $202,072.64

분석 결과, 중앙 집중형(모델 A) 아키텍처가 다른 두 모델에 비해 높은 비용 효율성을 보입니다. 멀티-엔드포인트(모델 B) 모델은 TGW 데이터 처리 비용을 절감하지만, 다수의 엔드포인트 시간당 요금으로 인해 여전히 중앙 집중형 모델보다 높은 비용이 요구됩니다. 완전 분산형(모델 C)은 관리 및 비용 측면에서 가장 낮은 효율을 보입니다.

5.3. ROI 관점의 고려사항

TCO 분석이 직접적인 비용 절감 효과를 보여준다면, 투자 수익률(ROI) 관점은 이 아키텍처 전환이 가져오는 무형의 비즈니스 가치를 조명합니다. 단순한 비용 계산을 넘어, 다음과 같은 전략적 이점을 고려해야 합니다.

• 보안 리스크 완화: IBM의 ‘2024년 데이터 유출 비용 보고서‘에 따르면 데이터 유출 사고의 전 세계 평균 비용은 488만 달러에 달하며, 비즈니스 손실이 큰 비중을 차지합니다. 제안된 아키텍처는 ANFW의 FQDN 필터링과 DNS Firewall의 선제적 차단을 통해 데이터 유출, 랜섬웨어 C2 통신, DNS 터널링과 같은 고비용 위협을 직접적으로 완화합니다. 단 한 번의 중대한 보안 사고를 예방하는 것만으로도 전체 아키텍처 전환 비용을 상회하는 가치를 창출할 수 있습니다.
• 운영 효율성 증대: 현재의 분산된 관리 모델은 네트워크 및 보안 엔지니어의 수동 작업을 가중시킵니다. 중앙 집중형 아키텍처는 정책 관리를 일원화하고, IaC(Infrastructure as Code)를 통한 자동화를 도입하여 운영 오버헤드를 상당 부분 줄일 수 있습니다. 또한 숙련된 인력의 시간을 절약하여 더 높은 가치를 창출하는 업무에 집중하게 함으로써, 인적 자원 효율성을 극대화하는 효과를 가져옵니다.
• 규제 준수 및 감사 비용 절감: 중앙에서 모든 Egress 트래픽을 로깅하고 일관된 정책을 적용하는 모델은 ISMS, NIST, SOC2, GDPR 등 다양한 규제 준수 요구사항을 충족하는 데 매우 유리합니다. 이는 감사 대응에 소요되는 시간과 비용을 절감하고, 규제 위반으로 인한 벌금 리스크를 낮추는 실질적인 재무적 이점으로 이어집니다.
• 비즈니스 민첩성 향상: 표준화되고 안전하며 확장 가능한 네트워크 기반을 마련함으로써, 새로운 애플리케이션이나 VPC를 비즈니스 요구에 따라 신속하고 안전하게 배포할 수 있습니다. 이는 시장 변화에 빠르게 대응하고 혁신을 가속화하는 능력으로 직결되며, 장기적인 경쟁 우위 확보에 기여합니다.

6. 마무리

본 블로그에서는 중복 CIDR 환경에서 발생하는 Egress 제어 문제를 해결하기 위한 다각적인 분석과 구체적인 해결책을 제시했습니다.

• 핵심 문제: 중복 CIDR 문제는 TGW 기반의 현대적인 네트워크 아키텍처 구현을 가로막는 근본적인 장애물입니다. 이를 현상황에서 기술적으로 해결하기 위한 ‘Private NAT Gateway 및 보조 CIDR’ 패턴을 소개했습니다. 하지만 이렇게 진행하는 것은 기술적으로는 가능하나, 그 자체로 운영 및 비용 복잡성을 증가시키며 추가적인 장애의 가능성을 야기합니다.
• 최적의 아키텍처 모델: 중복 CIDR 문제가 해결된 후 적용할 수 있는 세 가지 방화벽 배포 모델을 비교 분석한 결과, 모델 A: 중앙 집중형 보안검사 허브가 비용 효율성, 관리 용이성, 그리고 VPC 간 트래픽(East-West)을 포함한 포괄적인 보안 가시성 측면에서 유리한 것으로 평가되었습니다. 멀티-엔드포인트 모델(모델 B)은 지연 시간에 이점이 있지만, 비용과 East-West 트래픽 처리의 복잡성으로 인해 제한적인 경우에만 유용합니다.
• 재무적 타당성: TCO 분석 결과, Private NAT Gateway 도입에 따른 추가 비용을 감안하더라도, 중앙 집중형 모델은 분산형 모델 대비 상당한 운영 비용 절감 효과를 통해 전체 비용을 절감하는 것으로 나타났습니다. 또한, ROI 관점에서 볼 때, 이 투자는 잠재적인 데이터 유출 사고 방지, 규제 준수 강화, 비즈니스 민첩성 확보 등 측정 가능한 비용 절감을 훨씬 뛰어넘는 전략적 가치를 제공합니다.

중앙 집중형 보안검사 허브 아키텍처(모델 A)는 당장 직면한 기술적, 비용적 문제를 개선하고, 향후 비즈니스 확장과 진화하는 보안 위협에 대응할 수 있는 견고하고 확장 가능한 기반을 제공합니다.

하지만, 궁극적으로는 Private NAT Gateway와 같은 임시 방편적 솔루션에 대한 의존도를 점차 줄이고, 체계적인 IP 주소 관리 체계를 구축하여 중복 CIDR 문제 자체를 해소해야 합니다.

이를 통해 아키텍처를 단순화하고, 운영 복잡성을 낮추며, 더욱 안정적이고 확장 가능한 네트워크 기반을 마련할 수 있을 것입니다. 네트워크 아키텍처의 진정한 최적화는 단기적인 기술적 해결책을 넘어, 장기적인 재설계와 표준화를 통해 달성될 수 있습니다.