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 비용은 계속 남는다. (Amazon Web Services, Inc.)
NAT 비용은 네트워크 경로의 비용이다
같은 Private Subnet에서 시작한 트래픽이라도 목적지에 따라 다음처럼 나뉜다.
구조 다이어그램
[Private Workload / AZ-A]
│
├─ IPv4 인터넷·외부 API
│ ├─ Zonal NAT / AZ-A ── IGW ── Internet
│ ├─ Zonal NAT / AZ-B ── Cross-AZ ── IGW ── Internet
│ └─ Regional NAT
│ └─ AZ별 확장 지점 ── IGW ── Internet
│
├─ Amazon S3 / DynamoDB
│ └─ Gateway Endpoint ── AWS Service
│
├─ PrivateLink 지원 AWS·SaaS 서비스
│ └─ Interface Endpoint ENI / 각 AZ ── Service
│
├─ IPv6 지원 인터넷 목적지
│ └─ Egress-only Internet Gateway ── IPv6 Internet
│
└─ IPv6-only Workload → IPv4-only 목적지
└─ DNS64
└─ 64:ff9b::/96
└─ Public NAT Gateway / NAT64
└─ IPv4 DestinationS3와 DynamoDB는 Gateway Endpoint로 NAT 경로를 분리할 수 있다. PrivateLink 지원 서비스는 Interface Endpoint를 사용할 수 있지만 AZ별 시간 요금이 새로 생긴다. IPv6 목적지에는 Egress-only Internet Gateway를 사용할 수 있으나, IPv4-only 목적지까지 가려면 NAT64가 필요하다. (AWS Docs)
NAT 경로 비용식
NAT 비용은 다음과 같이 분해하는 편이 안전하다.
계산식
C_NAT_PATH
= Σz [ceil(H_nat,z) × P_nat_hour,Seoul]
+ B_nat,billed × P_nat_process,Seoul
+ Σleg [B_leg,billed × P_transfer,leg]
+ Σip [H_ip × P_public_ipv4]
+ C_adjacent각 항목의 의미는 다음과 같다.
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 등 대안 구성에서 추가되는 비용
Zonal NAT 하나를 한 달 내내 사용했다면 게이트웨이 하나의 시간 비용이 생긴다. Regional NAT가 같은 기간 세 AZ를 지원했다면 리소스 ID는 하나여도 AZ-hour는 세 배다. 자동 모드에서는 실제로 확장된 AZ, 수동 모드에서는 구성한 AZ를 기준으로 시간 비용을 확인해야 한다. 일부 시간은 1시간으로 올림된다. (Amazon Web Services, Inc.)
월 시간을 무조건 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 진입과 이탈에서 다시 세게 된다. 최종 비용 검증은 CloudWatch 추정치보다 CUR 또는 Cost Explorer의 NAT Data Processed 사용량을 우선한다. Regional NAT 지표는 NatGatewayId와 AvailabilityZone 차원을 함께 봐야 한다. (AWS Docs)
GB와 GiB를 한 계산 안에서 섞지 않는다
AWS 가격표와 청구서는 보통 GB라는 단위를 사용하고 CloudWatch는 원시 Bytes를 제공한다. 계산 Worksheet에서는 다음 중 한 방식을 고정한다.
- CUR·Cost Explorer가 제공하는 청구 GB를 그대로 사용
- 원시 바이트를 쓴다면
GB=10⁹ bytes또는GiB=2³⁰ bytes중 선택한 규칙을 명시 - 두 규칙을 중간에 섞지 않고 마지막에 청구 line item과 오차를 대조
가격표의 GB 수치에 이미 변환한 값을 넣은 뒤 다시 1,024로 나누는 방식도 피해야 한다.
서울 리전에서 무엇이 더해지는가
2026년 8월 21일 서울 리전 스냅샷에서 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 비용이 발생할 수 있다고 명시한다. (Amazon Web Services, Inc.)
같은 리전 AZ 간 EC2 계열 전송은 일반적으로 송신 측과 수신 측에 각각 $0.01/GB가 기록되는 경로가 있다. 그러나 Load Balancer, PrivateLink, VPC Peering 등 경유 리소스에 따라 청구 주체와 면제 조건이 달라질 수 있다. 비용식에 무조건 트래픽 × 2를 넣지 말고 CUR의 APN2-DataTransfer-Regional-Bytes 행과 실제 경계를 대응해야 한다. (Amazon Web Services, Inc.)
2. 인터넷 Data Transfer Out
NAT 처리 요금은 인터넷 전송 요금을 포함하지 않는다. 외부 API나 인터넷 목적지로 데이터를 보내면 EC2 Data Transfer Out의 목적지·월간 구간별 요금이 별도로 적용될 수 있다.
반대로 같은 리전 S3에 파일을 보내는 경우에는 EC2와 S3 사이의 해당 전송 비용이 없더라도, NAT를 경유했다면 NAT 처리 요금은 남을 수 있다. 그래서 목적지 종류를 먼저 분리해야 한다. (Amazon Web Services, Inc.)
3. 공인 IPv4 시간 비용
Public NAT Gateway에는 인터넷 통신을 위한 공인 IPv4가 연결된다. 공인 IPv4는 주소당 시간 비용이 발생한다. Regional NAT가 처리량이나 연결 수에 따라 여러 IP를 사용한다면 실제 IP-hour도 함께 확인해야 한다.
주소 수를 “NAT 개수와 동일하다”고 가정하지 말고 Public IP Insights 또는 APN2-PublicIPv4:InUseAddress 청구 행으로 집계하는 편이 안전하다. (Amazon Web Services, Inc.)
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를 유지한다. (AWS Docs)
다만 선택 전에 다음 조건을 확인해야 한다.
- AZ별 과금은 남는다. 단일 ID와 단일 시간 요금은 같은 뜻이 아니다.
- 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 구성과 다시 계산해야 한다. (AWS Docs)
대안 비교 Matrix
| 선택지 | 고정비 | 변동비 | 가용성 | 운영 부담 | 지원 대상 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 | 트래픽을 없앤 것이 아니라 다른 비용으로 이동했는지 확인 |
Gateway Endpoint는 S3·DynamoDB에 한정되지만 Endpoint 자체의 시간·처리 요금이 없다. Interface Endpoint는 서비스별로 AZ마다 Endpoint ENI가 만들어지고 데이터 방향에 관계없이 처리량 요금이 적용된다. 프로덕션에서는 두 개 이상의 AZ가 권장되므로 가용성 요구가 높을수록 시간 고정비도 커진다. (AWS Docs)
Egress-only Internet Gateway는 IPv6 아웃바운드 연결만 허용하는 상태 저장형 Gateway이며 자체 시간 요금은 없다. 그러나 외부 목적지가 IPv6를 지원해야 하고 인터넷 Data Transfer는 별도다. IPv4-only 목적지에는 DNS64와 NAT64를 사용하며 이 경로에는 다시 NAT Gateway 과금이 적용된다. (AWS Docs)
AWS는 관리 부담과 가용성·대역폭 측면에서 NAT Gateway를 기본적으로 권고한다. NAT Instance를 선택한다면 오래된 NAT AMI가 아니라 현재 Amazon Linux 기반으로 직접 구성해야 하며 이중화·패치·모니터링·Failover를 사용자가 책임진다. (AWS Docs)
Endpoint의 손익분기점은 데이터량만으로 정하지 않는다
Interface Endpoint의 월 비용은 대략 다음과 같다.
계산식
C_INTERFACE
= N_services
× Σaz [ceil(H_endpoint,az) × P_endpoint_hour,Seoul]
+ B_endpoint × P_endpoint_process
+ C_transferNAT에서 Interface Endpoint로 옮길 때의 단순 손익분기점은 다음처럼 볼 수 있다.
계산식
B_break_even
=
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. 공통 입력
| Field | 입력값 | 설명 |
|---|---|---|
| 기준일 | YYYY-MM-DD |
실제 가격 검증일 |
| Region | ap-northeast-2 |
모든 리소스와 가격의 리전 |
| 통화 | USD |
환율 적용 전 |
| 세금 | 포함 / 제외 | 견적과 실제 청구 비교 시 구분 |
| 분석 기간 | 시작일–종료일 | 달력 월인지 임의 기간인지 |
| 단위 | CUR GB / GB / GiB | 하나의 규칙으로 고정 |
| 약정·크레딧 | 금액 또는 제외 | 서비스 원가와 최종 청구를 분리 |
B. Traffic Row
| Row | Source / AZ | Destination | IP Family | Request | Response | 현재 경로 | NAT Type / AZ | Cross-AZ 경계 | Endpoint AZ | Internet Out |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | IPv4 / IPv6 | |||||||||
| 2 | IPv4 / IPv6 | |||||||||
| 3 | IPv4 / IPv6 |
각 행에서 다음을 계산한다.
계산식
NAT 처리량
= NAT를 통과한 Request
+ NAT를 통과한 Response계산식
Cross-AZ 과금량
= Σ 실제로 과금되는 각 AZ 경계의 Bytes계산식
Internet Out
= 인터넷으로 나간 실제 Response·Upload 등
- 해당되는 무료 허용량 또는 면제Request와 Response 중 Endpoint나 캐시로 빠진 데이터는 NAT 처리량에서 제외한다. 반대로 인터넷 Out과 NAT 처리량이 같은 데이터라고 해서 둘 중 하나만 계산해서도 안 된다. 서로 다른 Meter이기 때문이다.
C. 비용 계산
| 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 | NAT Gateway Running Hours, Data Processed | 시간비와 처리량 분리 |
APN2-DataTransfer-Regional-Bytes |
Cross-AZ 비용 확인 | |
| Internet Data Transfer Out | NAT 처리비와 인터넷 전송비 분리 | |
APN2-VpcEndpoint-Hours, APN2-VpcEndpoint-Bytes |
Endpoint 고정비·변동비 | |
APN2-PublicIPv4:InUseAddress |
NAT와 기타 리소스의 IPv4 비용 | |
| NAT Instance EC2·EBS·Data Transfer | 자체 NAT의 전체 비용 | |
| Topology | NAT ID, Zonal/Regional, Automatic/Manual | 과금 단위와 운영 모델 확인 |
| Subnet·Route Table·AZ 매핑 | Cross-AZ Hairpin 탐지 | |
| Regional NAT 지원 AZ와 실제 IP | AZ-hour·IP-hour 확인 | |
| Gateway·Interface Endpoint 목록 | NAT에서 분리 가능한 목적지 | |
| Private DNS·Endpoint Policy | 실제 트래픽이 Endpoint로 가는지 확인 | |
IPv6 CIDR, ::/0, 64:ff9b::/96 |
Native IPv6와 NAT64 경로 확인 | |
| Traffic | BytesInFromSource, BytesInFromDestination |
요청+응답 처리량 추정 |
ActiveConnectionCount |
연결 규모와 포트 사용 확인 | |
ErrorPortAllocation |
포트 부족 여부 | |
| VPC Flow Logs의 Source·Destination·Bytes | 목적지와 원인 워크로드 분류 | |
| Retry·Polling·Artifact·Telemetry 비중 | 제거 가능한 Traffic 확인 | |
| Reliability | AZ 장애 시 Egress 경로 | 비용보다 가용성이 우선인 구간 확인 |
| Regional NAT 확장 시간 허용 여부 | 신규 AZ 배치 시 일시적 Cross-AZ 영향 | |
| 외부 Allowlist IP 요구 | NAT 변경·전환 가능성 | |
| NAT Instance Failover·Patch 기록 | 운영 비용과 장애 위험 산정 | |
| Change Plan | Route 변경 순서와 Rollback | Endpoint·Regional NAT 전환 안전성 |
| 연결 초기화 허용 시간 | NAT 전환 Maintenance Window | |
| 전환 전후 동일 기간 CUR | 절감 여부와 비용 이동 검증 |
Cost Explorer와 CUR에는 NAT 시간·처리량, Inter-AZ Data Transfer, Internet Out, VPC Endpoint 시간·처리량과 공인 IPv4가 서로 다른 사용 유형으로 나타난다. 하나의 “VPC 비용” 합계만 보면 어느 경로가 원인인지 알기 어렵다. (AWS Docs)
어떤 순서로 바꿔야 할까
첫 단계는 NAT를 삭제하는 것이 아니라 목적지별 Traffic Inventory를 만드는 일이다.
- S3·DynamoDB 트래픽을 Gateway Endpoint 후보로 분리한다.
- 반복적으로 큰 비중을 차지하는 지원 서비스를 Interface Endpoint 후보로 분리한다.
- 외부 인터넷 트래픽을 API, Artifact, Telemetry, Update, 사용자 데이터로 나눈다.
- Source와 NAT의 AZ 경계를 확인한다.
- IPv6로 직접 갈 수 있는 목적지와 NAT64가 필요한 목적지를 구분한다.
- 각 대안이 새로 만드는 시간 고정비와 운영 책임을 계산한다.
- 동일한 기간의 CUR로 변경 전후를 비교한다.
이 과정을 거치면 “NAT를 다른 장치로 교체할 것인가”보다 더 정확한 질문을 할 수 있다.
어떤 트래픽은 NAT에서 분리하고 어떤 트래픽은 관리형 NAT에 남기며 어떤 트래픽은 애초에 줄여야 하는가?
이 네트워크 비용을 전체 Placement 판단에 반영하려면 「클라우드를 고르기 전에 워크로드부터 분류해야 하는 이유」와 함께 검토해야 한다.
실제 계산에는 위의 NAT Cost Worksheet를 사용할 수 있다. VPC·Billing·Traffic 경로를 함께 분해하기 어렵다면 확인된 IXC 문의 경로인 https://www.ixc.co.kr/contact/에서 Managed Infrastructure 검토 범위를 문의할 수 있다.