NAT 비용은 네트워크 경로의 비용이다
AWS NAT Gateway 비용은 시간 단가 하나로 정해지지 않습니다. 실제 청구액은 Gateway가 켜져 있던 시간, NAT를 통과한 요청과 응답 데이터, 그 앞뒤의 Data Transfer 경로, 공인 IPv4와 Endpoint 같은 인접 구성이 함께 쌓인 결과입니다.
따라서 NAT 비용을 분석할 때는 “NAT Gateway가 몇 개 있는가”보다 어떤 워크로드가 어느 AZ에서 어떤 목적지로 얼마나 통신하는지를 먼저 그립니다. S3·DynamoDB 트래픽, 특정 AWS API, 일반 IPv4 인터넷, IPv6 목적지는 각각 다른 경로와 대안으로 이어집니다.
Regional NAT Gateway도 이 원칙을 바꾸지 않습니다. Regional NAT는 단일 ID와 자동 AZ 확장으로 다중 AZ 운영을 단순하게 만듭니다. 그러나 활성화되거나 구성된 AZ마다 시간 요금이 붙고 처리 데이터와 Data Transfer, 공인 IPv4 비용은 그대로 남습니다.[2]
같은 Private Subnet에서 시작한 트래픽이라도 목적지에 따라 경로가 갈립니다. S3와 DynamoDB는 Gateway Endpoint로 NAT 경로에서 떼어 냅니다. PrivateLink 지원 서비스는 Interface Endpoint를 쓰지만 AZ마다 시간 요금이 새로 붙습니다. IPv6 목적지에는 Egress-only Internet Gateway를 쓰고, IPv4-only 목적지까지 가려면 NAT64가 필요합니다.[3]
NAT 경로 비용식
NAT 비용은 다섯 항목으로 분해하는 편이 안전합니다. NAT 경로 총비용은 아래 계산 항목으로 정리합니다. 각 항목의 뜻은 다음과 같습니다.
Zonal NAT 하나를 한 달 내내 썼다면 게이트웨이 하나의 시간 비용이 붙습니다. Regional NAT가 같은 기간 세 AZ를 지원했다면 리소스 ID는 하나여도 AZ-hour는 세 배입니다. 자동 모드에서는 실제로 확장된 AZ를, 수동 모드에서는 구성한 AZ를 놓고 시간 비용을 확인합니다. 일부 시간은 1시간으로 올림됩니다.[1][2]
월 시간을 무조건 730시간으로 넣지 않습니다. 730시간은 연평균 계산에 편리한 값일 뿐 실제 청구 기간이 아닙니다. 30일인 달은 720시간, 31일인 달은 744시간, 윤년이 아닌 2월은 672시간입니다. 중간에 만들거나 지웠다면 실제 프로비저닝 시간을 넣습니다. Regional NAT에서는 이 시간을 다시 AZ별로 나눕니다. 한 AZ가 월 중간에 추가됐다면 모든 AZ에 같은 월간 시간을 넣어서는 안 됩니다.
NAT 처리량은 Outbound 하나만 뜻하지 않습니다. NAT Gateway는 목적지로 나가는 요청과 돌아오는 응답을 모두 처리합니다. 요청 1GB를 보내고 응답 3GB를 받았다면 처리량 추정치는 4GB입니다. CloudWatch로 추정할 때는 BytesInFromSource와 BytesInFromDestination 한 쌍, 또는 BytesOutToDestination과 BytesOutToSource 한 쌍 가운데 하나만 씁니다. 네 지표를 모두 더하면 같은 패킷을 NAT 진입과 이탈에서 두 번 세게 됩니다.[6]
최종 비용 검증은 CloudWatch 추정치보다 CUR이나 Cost Explorer의 NAT Data Processed 사용량을 앞세웁니다. Regional NAT 지표는 NatGatewayId와 AvailabilityZone 차원을 함께 봅니다.[5]
GB와 GiB를 한 계산 안에서 섞지 않습니다. AWS 가격표와 청구서는 보통 GB를 쓰고 CloudWatch는 원시 Bytes를 줍니다. 워크시트에서는 CUR·Cost Explorer가 주는 청구 GB를 그대로 쓰거나, 원시 바이트를 쓴다면 GB=10⁹ bytes와 GiB=2³⁰ bytes 가운데 고른 규칙을 명시합니다. 두 규칙을 중간에 섞지 않고 마지막에 청구 line item과 오차를 대조합니다. 가격표의 GB 수치에 이미 변환한 값을 넣은 뒤 다시 1,024로 나누는 방식도 피합니다.
- H_nat,z
- Zonal NAT의 게이트웨이별 사용 시간이거나 Regional NAT의 AZ별 지원 시간입니다.
- B_nat,billed
- NAT를 실제로 통과해 청구된 요청·응답 데이터입니다.
- B_leg,billed
- Cross-AZ, 인터넷 Out, 리전 간 전송처럼 과금 대상이 된 각 경로의 데이터입니다.
- H_ip
- NAT에 연결된 실제 공인 IPv4의 사용 시간입니다.
- C_adjacent
- Interface Endpoint나 NAT Instance처럼 대안 구성에서 새로 붙는 비용입니다.
- NAT 경로 총비용
- C_NAT_PATH = Σz ceil(H_nat,z) × P_nat_hour + B_nat,billed × P_nat_process + Σleg (B_leg,billed × P_transfer,leg) + Σip (H_ip × P_public_ipv4) + C_adjacent
비용의 원인에서 지속 관리까지 — 지출을 업무와 자원 단위로 나누고 영향도를 확인한 조치와 예산 가드레일을 운영에 연결합니다.
서울 리전에서 무엇이 더해지는가
서울 리전 가격표에서 NAT Gateway는 시간당 $0.059, 처리 데이터는 GB당 $0.059입니다. 여기에 실제 경로에 따라 세 항목이 더해집니다.[1]
첫째는 AZ 경계를 넘는 비용입니다. Private Workload가 AZ-A에 있고 Zonal NAT가 AZ-B에 있으면 워크로드와 NAT 사이의 요청과 응답이 AZ 경계를 지납니다. AWS VPC 가격 페이지도 EC2와 NAT가 다른 AZ에 있으면 Data Transfer 비용이 붙는다고 밝힙니다. 같은 리전 AZ 간 EC2 계열 전송은 대개 송신 측과 수신 측에 각각 $0.01/GB가 기록되는 경로가 있습니다. 다만 Load Balancer, PrivateLink, VPC Peering 등 경유 리소스에 따라 청구 주체와 면제 조건이 달라집니다. 비용식에 무조건 트래픽 × 2를 넣지 말고 CUR의 APN2-DataTransfer-Regional-Bytes 행과 실제 경계를 짝지어야 합니다.[1][5][7]
둘째는 인터넷 Data Transfer Out입니다. NAT 처리 요금은 인터넷 전송 요금을 포함하지 않습니다. 외부 API나 인터넷 목적지로 데이터를 보내면 EC2 Data Transfer Out의 목적지·월간 구간별 요금이 따로 붙습니다. 반대로 같은 리전 S3에 파일을 보내는 경우에는 EC2와 S3 사이의 전송 비용이 없더라도 NAT를 지났다면 NAT 처리 요금이 남습니다. 그래서 목적지 종류를 먼저 갈라야 합니다.[1]
셋째는 공인 IPv4 시간 비용입니다. Public NAT Gateway에는 인터넷 통신을 위한 공인 IPv4가 붙고, 공인 IPv4는 주소당 시간 비용이 붙습니다. Regional NAT가 처리량이나 연결 수에 따라 여러 IP를 쓴다면 실제 IP-hour도 함께 확인합니다. 주소 수를 NAT 개수와 같다고 가정하지 말고 Public IP Insights나 APN2-PublicIPv4:InUseAddress 청구 행으로 집계하는 편이 안전합니다.[5]
Regional NAT Gateway가 바꾼 선택지
기존 다중 AZ Zonal NAT 구성에서는 대개 다섯 가지가 필요했습니다. 각 AZ의 공용 서브넷, AZ마다 두는 NAT Gateway, Private Subnet별 로컬 NAT 경로, NAT 서브넷에서 Internet Gateway로 가는 경로, 그리고 새 AZ를 추가할 때마다 하는 NAT·Route Table 수정입니다.
Regional NAT는 VPC 단위의 단일 NAT ID를 줍니다. 공용 서브넷에 NAT를 배치하지 않아도 됩니다. 자동 모드에서는 워크로드의 네트워크 인터페이스가 있는 AZ를 감지해 확장하고 축소합니다. 각 AZ에서는 가능한 한 해당 AZ의 Regional NAT 지점을 써서 zonal affinity를 유지합니다.[2]
다만 고르기 전에 일곱 조건을 확인합니다. AZ별 과금은 그대로 남습니다. Private NAT는 지원하지 않으므로 Transit Gateway·VPN·온프레미스 연결에서 사설 주소 변환이 필요하면 Zonal NAT를 검토합니다. 새 AZ 확장에 최대 60분이 걸리며 그동안 다른 AZ에서 처리되므로 실제 Cross-AZ 경로를 확인합니다. Constrained AZ는 지원하지 않습니다. 수동 모드에서는 AZ와 IP 확장을 운영자가 관리합니다. 기존 NAT에서 전환하면 연결이 초기화되므로 유지보수 시간과 외부 Allowlist IP 변경 여부가 필요합니다. 공인 IPv4 수가 늘 수 있어, Regional NAT가 AZ당 최대 32개 IP를 지원하는 만큼 연결 규모와 IP-hour를 함께 봅니다.
Regional NAT는 주로 다중 AZ NAT 운영의 복잡성과 잘못된 라우팅 가능성을 줄이는 선택지입니다. 비용 판단은 같은 AZ 수와 처리량, 공인 IP, 전송 경로를 넣어 Zonal 구성과 다시 계산합니다.[2]
대안 비교 Matrix
여덟 선택지를 같은 축에 놓고 봅니다. 고정비와 변동비, 가용성, 운영 부담, 지원 트래픽, 주의할 조건입니다.
Gateway Endpoint는 S3·DynamoDB에 한정되지만 Endpoint 자체의 시간·처리 요금이 없습니다. Interface Endpoint는 서비스별로 AZ마다 Endpoint ENI가 생기고 데이터 방향과 관계없이 처리량 요금이 붙습니다. 프로덕션에서는 두 개 이상의 AZ가 권장되므로 가용성 요구가 높을수록 시간 고정비도 커집니다.[3]
Egress-only Internet Gateway는 IPv6 아웃바운드 연결만 허용하는 상태 저장형 Gateway이며 자체 시간 요금이 없습니다. 그러나 외부 목적지가 IPv6를 지원해야 하고 인터넷 Data Transfer는 별개입니다. IPv4-only 목적지에는 DNS64와 NAT64를 쓰며 이 경로에는 다시 NAT Gateway 과금이 붙습니다.[1][8]
AWS는 관리 부담과 가용성, 대역폭을 들어 NAT Gateway를 기본으로 권합니다. NAT Instance를 고른다면 오래된 NAT AMI가 아니라 현재 Amazon Linux 기반으로 직접 구성해야 하며 이중화와 패치, 모니터링, Failover를 사용자가 책임집니다.[4]
선택지 | 고정비 | 변동비 | 가용성 | 운영 부담 | 지원 대상 Traffic | 주의할 조건 |
|---|---|---|---|---|---|---|
| Zonal NAT Gateway | Gateway × 사용 시간 | NAT 처리량, Data Transfer, IPv4 | AZ 내부 관리형 이중화. 다중 AZ는 AZ별 구성 필요 | 낮음~중간 | 일반 IPv4 인터넷, Public·Private NAT | 다른 AZ의 NAT를 공유하면 비용과 장애 범위가 커진다 |
| Regional NAT Gateway | 활성·구성 AZ × 사용 시간 | NAT 처리량, Data Transfer, 실제 IPv4 | 자동 모드에서 AZ 확장과 zonal affinity | 낮음 | 일반 Public IPv4 인터넷 | Private NAT 불가, 확장 지연, 전환 시 연결 초기화 |
| Gateway Endpoint | Endpoint 추가 비용 없음 | Endpoint 처리 비용 없음 | AWS 관리 | 낮음 | 같은 리전 S3·DynamoDB | 다른 서비스에는 적용되지 않고 VPC 밖으로 확장하는 데 제약 |
| Interface Endpoint / PrivateLink | 서비스 × Endpoint AZ × 시간 | Endpoint 처리량, 필요한 Data Transfer | 다중 AZ 구성 시 향상 | 중간 | 지원 AWS 서비스·SaaS·Endpoint Service | 서비스가 많고 트래픽이 적으면 고정비가 커진다 |
| Native IPv6 + Egress-only IGW | Gateway 비용 없음 | 인터넷 Data Transfer 등 | AWS 관리 | 중간 | IPv6를 지원하는 목적지 | 애플리케이션·DNS·방화벽·외부 의존성의 IPv6 지원 필요 |
| DNS64 + NAT64 | NAT Gateway 시간과 IPv4 | NAT 처리량과 전송 | NAT 구성에 따름 | 중간 | IPv6-only Source에서 IPv4-only Destination으로 | NAT 비용이 남고 DNS64·64:ff9b::/96 경로가 필요 |
| NAT Instance | EC2·EBS·IPv4·HA 인스턴스 | 전송량, 인스턴스 사용량 | 직접 이중화·Failover 설계 | 높음 | 일반 NAT와 커스텀 네트워크 기능 | 패치·용량·장애·포트 고갈·복구를 직접 책임 |
| NAT가 필요한 트래픽 축소 | Cache·Mirror·Endpoint 등의 구성비 | 줄어든 트래픽과 새 구성 비용 | 구성에 따라 다름 | 중간 | 반복 다운로드, Polling, Retry, Telemetry, Artifact | 트래픽을 없앤 것이 아니라 다른 비용으로 옮긴 것은 아닌지 확인 |
Endpoint의 손익분기점은 데이터량만으로 정하지 않는다
Interface Endpoint의 월 비용은 대략 C_INTERFACE = N_services × Σaz ceil(H_endpoint,az) × P_endpoint_hour + B_endpoint × P_endpoint_process + C_transfer 입니다. NAT에서 Interface Endpoint로 옮길 때의 단순 손익분기점은 Interface Endpoint 고정 시간 비용을 (회피되는 NAT 처리 단가 + 회피되는 전송 단가 − Endpoint 처리 단가)로 나눈 값입니다.
분모가 0 이하라면 데이터량이 늘어도 비용만으로는 Endpoint가 유리해지지 않습니다. 이 계산에는 여섯 가지를 따로 반영합니다. Endpoint가 필요한 서비스 개수, 프로덕션에서 필요한 Endpoint AZ 수입니다. 나머지는 Endpoint가 피하는 Cross-AZ 또는 인터넷 경로, Private DNS와 보안 정책의 가치입니다. 이어서 확인할 항목은 NAT Gateway가 다른 트래픽 때문에 어차피 유지되는지 여부, 그리고 Endpoint 도입 뒤에도 남는 NAT 최소 고정비입니다.
NAT를 완전히 지우지 못하는 환경에서 Endpoint가 줄이는 것은 보통 NAT의 일부 처리량입니다. 이때는 Endpoint 시간 고정비와 줄어드는 변동비를 나란히 놓고 비교합니다.
관측에서 복구와 개선까지 이어지는 운영 — 서비스 지표와 경보를 기준으로 대응하고 변경 이력과 사후 보고를 다음 개선에 연결합니다.
Decision Matrix
현재 트래픽이 어떤 형태인지에 따라 먼저 열어 볼 선택지가 달라집니다. 아래 아홉 줄은 트래픽 형태와 그때 검토할 대안, 이어서 확인할 항목을 짝지은 것입니다.
현재 Traffic | 먼저 검토할 선택지 | 다음 확인 항목 | 판단 이유 |
|---|---|---|---|
| 같은 리전 S3·DynamoDB 비중이 큼 | Gateway Endpoint | Route Table, Endpoint Policy, 기존 연결 전환 | Endpoint 자체의 시간·처리 요금이 없고 NAT 처리 경로를 분리한다 |
| 소수 AWS API·SaaS로 지속적으로 많은 트래픽 | Interface Endpoint | 서비스 지원 여부, AZ 수, Private DNS, 손익분기점 | Private path와 접근 통제를 얻는 대신 서비스·AZ별 고정비가 붙는다 |
| 여러 불특정 IPv4 인터넷 목적지 | Zonal 또는 Regional NAT | AZ 수, Private NAT 필요 여부, Allowlist IP, 운영 방식 | Endpoint로 일반 인터넷 전체를 대체하지 못한다 |
| 다중 AZ Public NAT 운영이 자주 바뀜 | Regional NAT | 자동·수동 모드, 지원 AZ, 확장 지연, IP 정책 | NAT와 Route Table 운영을 단순화하면서 AZ별 affinity를 준다 |
| 온프레미스·TGW 경로에 사설 NAT 필요 | Zonal Private NAT | 라우팅, AZ 이중화, 주소 중복 | Regional NAT는 Private NAT를 지원하지 않는다 |
| 목적지와 애플리케이션이 IPv6 지원 | Native IPv6 + Egress-only IGW | DNS, Security Group, NACL, 외부 API, 관측 도구 | NAT44 처리 경로를 쓰지 않아도 된다 |
| IPv6-only Source가 IPv4-only API 호출 | DNS64 + NAT64 | DNS64, 64:ff9b::/96, Public NAT, 테스트 | IPv6-only 워크로드를 유지하지만 NAT 비용은 남는다 |
| 낮거나 간헐적인 트래픽이며 커스텀 기능 필요 | NAT Instance 후보 | EC2 사양, HA, Failover, 패치, Source/Destination Check | 관리형 비용 대신 운영 책임과 용량 위험을 인수한다 |
| Artifact·패키지·로그·Retry가 NAT 사용량 대부분 | Traffic 자체 축소 | Cache hit, 재시도, 전송 빈도, 압축, Mirror | 네트워크 장치를 바꾸기 전에 불필요한 바이트를 줄인다 |
NAT Cost Worksheet
워크시트는 세 블록입니다. A는 모든 계산에 공통으로 들어가는 입력입니다. B는 목적지별 Traffic Row이고 C는 비용 항목별 계산식입니다.
B의 Traffic Row는 한 줄에 하나의 경로를 적습니다. 열은 Source와 AZ, Destination, IP Family, Request, Response, 현재 경로, NAT Type과 AZ, Cross-AZ 경계, Endpoint AZ, Internet Out입니다.
각 행에서 세 값을 계산합니다. NAT 처리량은 NAT를 통과한 Request와 Response의 합입니다. Cross-AZ 과금량은 실제로 과금되는 각 AZ 경계 Bytes의 합입니다. Internet Out은 인터넷으로 나간 실제 Response와 Upload에서 해당되는 무료 허용량이나 면제를 뺀 값입니다.
Request와 Response 가운데 Endpoint나 캐시로 빠진 데이터는 NAT 처리량에서 뺍니다. 반대로 인터넷 Out과 NAT 처리량이 같은 데이터라고 해서 둘 중 하나만 계산해서도 안 됩니다. 서로 다른 Meter이기 때문입니다.
- 기준일
- 실제 가격을 검증한 날짜입니다. 가격표는 바뀌므로 계산마다 다시 확인합니다.
- Region
- 모든 리소스와 가격이 속한 리전입니다. 서울 리전은 ap-northeast-2입니다.
- 통화
- 환율을 적용하기 전의 표시 통화입니다.
- 세금
- 견적과 실제 청구를 비교할 때 포함인지 제외인지를 구분해 적습니다.
- 분석 기간
- 시작일과 종료일입니다. 달력 월인지 임의 기간인지를 함께 적습니다.
- 단위
- CUR GB, GB, GiB 가운데 하나로 고정한 규칙입니다.
- 약정·크레딧
- 서비스 원가와 최종 청구를 나누기 위해 금액을 적거나 제외로 표시합니다.
Cost Component | Formula |
|---|---|
| Zonal NAT 시간 | Σ Gateway별 rounded hours × $0.059 |
| Regional NAT 시간 | Σ AZ별 rounded support hours × $0.059 |
| NAT 처리 | CUR NAT processed GB × $0.059 |
| Cross-AZ | Σ billed leg GB × 해당 Data Transfer rate |
| Internet Out | 해당 GB × 서울 리전 목적지·구간별 rate |
| Public IPv4 | 실제 IP hours × $0.005 |
| Gateway Endpoint | $0 endpoint hour + $0 endpoint processing |
| Interface Endpoint 시간 | 서비스 수 × AZ별 endpoint hours × $0.013 |
| Interface Endpoint 처리 | 실제 processed GB × 적용 tier |
| NAT Instance Compute | 인스턴스별 실행 시간 × 서울 On-Demand rate |
| NAT Instance 기타 | EBS + IPv4 + Transfer + Monitoring + HA Replica |
| 운영 비용 | 패치·장애 대응·Failover 테스트·On-call에 투입하는 내부 비용 |
분석 전에 확보해야 할 Metric Checklist
지표는 다섯 영역으로 나눠 모읍니다. Billing과 Topology, Traffic, Reliability, Change Plan입니다.
Cost Explorer와 CUR에는 NAT 시간과 처리량, Inter-AZ Data Transfer, Internet Out, VPC Endpoint 시간과 처리량, 공인 IPv4가 서로 다른 사용 유형으로 나타납니다. 하나의 “VPC 비용” 합계만 보면 어느 경로가 원인인지 알기 어렵습니다.[5]
영역 | 확보할 항목 | 분석 목적 |
|---|---|---|
| Billing | NAT Gateway Running Hours, Data Processed | 시간비와 처리량 분리 |
| Billing | APN2-DataTransfer-Regional-Bytes | Cross-AZ 비용 확인 |
| Billing | Internet Data Transfer Out | NAT 처리비와 인터넷 전송비 분리 |
| Billing | APN2-VpcEndpoint-Hours, APN2-VpcEndpoint-Bytes | Endpoint 고정비와 변동비 |
| Billing | APN2-PublicIPv4:InUseAddress | NAT와 기타 리소스의 IPv4 비용 |
| Billing | NAT Instance EC2·EBS·Data Transfer | 자체 NAT의 전체 비용 |
| Topology | NAT ID, Zonal/Regional, Automatic/Manual | 과금 단위와 운영 모델 확인 |
| Topology | Subnet·Route Table·AZ 매핑 | Cross-AZ Hairpin 탐지 |
| Topology | Regional NAT 지원 AZ와 실제 IP | AZ-hour와 IP-hour 확인 |
| Topology | Gateway·Interface Endpoint 목록 | NAT에서 분리 가능한 목적지 |
| Topology | Private DNS·Endpoint Policy | 실제 트래픽이 Endpoint로 가는지 확인 |
| Topology | IPv6 CIDR, ::/0, 64:ff9b::/96 | Native IPv6와 NAT64 경로 확인 |
| Traffic | BytesInFromSource, BytesInFromDestination | 요청과 응답을 합한 처리량 추정 |
| Traffic | ActiveConnectionCount | 연결 규모와 포트 사용 확인 |
| Traffic | ErrorPortAllocation | 포트 부족 여부 |
| Traffic | VPC Flow Logs의 Source·Destination·Bytes | 목적지와 원인 워크로드 분류 |
| Traffic | Retry·Polling·Artifact·Telemetry 비중 | 제거 가능한 Traffic 확인 |
| Reliability | AZ 장애 시 Egress 경로 | 비용보다 가용성이 앞서는 구간 확인 |
| Reliability | Regional NAT 확장 시간 허용 여부 | 신규 AZ 배치 시 일시적 Cross-AZ 영향 |
| Reliability | 외부 Allowlist IP 요구 | NAT 변경과 전환 가능성 |
| Reliability | NAT Instance Failover·Patch 기록 | 운영 비용과 장애 위험 산정 |
| Change Plan | Route 변경 순서와 Rollback | Endpoint·Regional NAT 전환 안전성 |
| Change Plan | 연결 초기화 허용 시간 | NAT 전환 Maintenance Window |
| Change Plan | 전환 전후 동일 기간 CUR | 절감 여부와 비용 이동 검증 |
어떤 순서로 바꿔야 할까
첫 단계는 NAT를 지우는 것이 아니라 목적지별 Traffic Inventory를 만드는 일입니다. S3·DynamoDB 트래픽을 Gateway Endpoint 후보로 떼어 내고, 반복적으로 큰 비중을 차지하는 지원 서비스를 Interface Endpoint 후보로 떼어 냅니다. 외부 인터넷 트래픽은 API, Artifact, Telemetry, Update, 사용자 데이터로 나눕니다.
그다음 Source와 NAT의 AZ 경계를 확인하고, IPv6로 곧장 가는 목적지와 NAT64가 필요한 목적지를 가릅니다. 각 대안이 새로 만드는 시간 고정비와 운영 책임을 계산한 뒤, 같은 기간의 CUR로 변경 전후를 비교합니다.
이 과정을 거치면 “NAT를 다른 장치로 바꿀 것인가”보다 정확한 질문에 이릅니다. 어떤 트래픽은 NAT에서 떼어 내고, 어떤 트래픽은 관리형 NAT에 남기며, 어떤 트래픽은 애초에 줄여야 하는가입니다.
