AWS 네트워크 데이터 전송 및 처리 요금, 아키텍처로 이해하기 [2부: 리전 안의 트래픽]

이 글은 VPC와 가용 영역(Availability Zone, AZ)의 기본 개념과 Elastic Load Balancing, Amazon ElastiCache, Amazon EKS를 운영해 본 경험이 있는 아키텍트와 운영 담당자를 대상으로, 같은 리전 안에서 AZ 경계를 넘는 트래픽이 어디에서 발생하고 어떻게 최적화하는지를 다룹니다.

1부에서는 AWS 네트워크 비용이 데이터 전송 요금과 데이터 처리 요금 두 축으로 결정된다는 점을 살펴보았습니다. 전송 요금은 트래픽이 넘는 경계에 따라 과금됩니다. 처리 요금은 NAT Gateway나 VPC 엔드포인트처럼 트래픽이 지나는 관리형 서비스가 부과합니다. 인터넷으로 나가는 DTO는 서울 리전 기준 GB당 $0.126입니다. 같은 리전의 AZ 간 전송은 양방향에 각각 $0.01가 과금됩니다. 1부가 인터넷 경계에서 발생하는 비용을 다뤘다면 2부는 리전 내부를 다루게 됩니다.

• 1부: 데이터 전송 요금과 데이터 처리 요금의 구조, 청구서에서 비용을 찾는 방법, 인터넷 게이트웨이, 퍼블릭 IPv4 주소, NAT Gateway, VPC 엔드포인트, Amazon CloudFront (링크)
• 2부(이 글): 리전 안의 트래픽. AZ 간 전송 규칙, Application Load Balancer와 Network Load Balancer, 데이터베이스와 캐시 계층(Valkey GLIDE의 AZ 친화도 포함), Amazon EKS
• 3부: VPC 간 연결과 하이브리드. VPC Peering, AWS Transit Gateway, AWS PrivateLink와 Amazon VPC Lattice, AWS Cloud WAN, AWS Direct Connect (링크)

리전 안의 비용은 대부분 AZ 경계에서 발생합니다. GB당 $0.01는 작아 보이지만 애플리케이션 서버, 로드 밸런서, 데이터베이스, 컨테이너 파드가 서로 호출하는 트래픽은 하루 24시간 흐릅니다. 이 글에서는 AZ 간 전송 요금이 과금되는 정확한 규칙을 먼저 정리합니다. 이어서 Application Load Balancer(ALB)와 Network Load Balancer(NLB)의 요금 차이, 데이터베이스와 캐시 계층의 무료 구간과 유료 구간, Amazon EKS의 네트워크 비용을 순서대로 살펴봅니다.

이 글의 요금은 서울 리전(ap-northeast-2) 공개 요금 페이지를 기준으로 합니다. 별도 표기가 없으면 GB당 미국 달러입니다. 월 시간은 730시간, 1TB는 1,024GB로 계산합니다. 요금은 변경될 수 있으므로 설계에 반영하기 전에 각 서비스 요금 페이지에서 최신 요금을 확인하시길 권고드립니다.

1. AZ 간 데이터 전송 요금의 규칙

AZ 간 전송 요금은 트래픽의 양쪽 끝에 각각 과금됩니다. AZ A의 EC2가 AZ B의 EC2로 1GB를 보내면 보내는 쪽에 Out $0.01, 받는 쪽에 In $0.01가 기록되어 합계 $0.02가 됩니다. 응답이 돌아오면 같은 방식으로 다시 $0.02가 과금됩니다. CUR에서 DataTransfer-Regional-Bytes가 자원 하나당 두 줄로 기록되는 이유가 이것입니다. 같은 AZ 안에서 프라이빗 IP로 통신하면 $0입니다.

이 규칙에는 예외가 여럿 있습니다. AZ 경계를 넘어도 전송 요금이 없는 서비스가 있고 같은 AZ라도 요금이 과금되는 경로가 있습니다.

표 1. 같은 리전 안에서 AZ 경계를 넘는 트래픽의 요금 규칙(서울 리전)

계정이 여러 개라면 AZ 이름 대신 AZ ID를 확인하는 것을 권장합니다. ap-northeast-2a 같은 AZ 이름은 계정마다 다른 물리 AZ에 매핑됩니다. apne2-az1 같은 AZ ID는 모든 계정에서 같은 물리 AZ를 가리킵니다. 다른 계정의 VPC와 Peering으로 통신하는 자원을 같은 AZ에 배치하려면 AZ ID 기준으로 서브넷을 맞춰야 합니다.

그림 1. AZ 간 전송 요금은 보내는 자원과 받는 자원에 각각 기록됩니다

2. Elastic Load Balancing

Elastic Load Balancing은 로드 밸런서 노드가 요청을 받은 AZ와 다른 AZ의 대상으로 트래픽을 보낼 수 있습니다. 이 기능이 교차 영역 로드 밸런싱(Cross-Zone Load Balancing)입니다. 로드 밸런서 유형에 따라 기본값과 요금이 다르고, 특히 ALB와 NLB의 차이가 큽니다.

2.1 Application Load Balancer

ALB는 교차 영역 로드 밸런싱이 항상 활성화되어 있습니다. 같은 VPC 안에서 프라이빗 IP로 통신하는 클라이언트와 ALB 노드 사이, ALB 노드와 대상 사이의 트래픽은 AZ가 달라도 데이터 전송 요금이 없습니다. AZ 배치를 신경 쓰지 않아도 되는 유일한 로드 밸런서(Classic Load Balancer 제외)입니다. 대상 그룹 수준에서는 2022년 11월부터 load_balancing.cross_zone.enabled 속성으로 교차 영역을 끌 수 있지만, 이는 지연 시간이나 AZ 독립성을 위한 선택이고 요금에는 영향이 없습니다. 요금은 로드 밸런서 시간당 요금과 LCU(Load Balancer Capacity Unit) 시간당 $0.008로 구성됩니다.

ALB에서 AZ 간 요금이 과금되는 경우는 두 가지입니다. VPC Peering으로 연결된 다른 VPC의 클라이언트가 다른 AZ의 ALB 노드에 접근할 때, 그리고 클라이언트가 퍼블릭 IP로 접근할 때입니다. 시나리오별 상세 요금은 Classic 및 Application Load Balancers의 데이터 전송 비용 살펴보기에서 그림과 함께 확인할 수 있습니다.

2.2 Network Load Balancer

NLB는 ALB와 다르게 일반 EC2 트래픽 규칙을 따릅니다. 클라이언트와 NLB 노드가 다른 AZ에 있으면 양방향에 각각 $0.01가 과금됩니다. 교차 영역 로드 밸런싱을 활성화해 NLB 노드가 다른 AZ의 대상으로 트래픽을 보내면 이 구간에도 양방향 $0.01가 과금됩니다. 클라이언트가 AZ A, NLB 노드가 AZ B, 대상이 다시 AZ A에 있으면 요청 한 방향에서만 AZ 경계를 두 번 넘어 GB당 $0.04가 됩니다. 응답 방향에도 같은 금액이 과금됩니다.

표 2. NLB 트래픽이 AZ 경계를 넘는 시나리오별 요금(서울 리전)

이 요금이 생기는 원인은 NLB의 두 가지 기본값입니다. 첫째, NLB의 DNS 응답은 기본적으로 AZ 친화도(Zonal Affinity) 0%입니다. 클라이언트가 NLB의 DNS 이름을 조회하면 Route 53 Resolver가 모든 AZ의 정상 NLB IP를 돌려줍니다. 클라이언트는 자기 위치와 무관하게 모든 AZ의 노드로 연결하므로 AZ가 세 개라면 요청의 약 3분의 2가 AZ 경계를 넘어갑니다. 둘째, 교차 영역 로드 밸런싱은 로드 밸런서와 대상 그룹 수준에서 모두 기본 비활성화입니다. 대상 분포를 고르게 하려고 이 설정을 활성화하면 노드에서 대상으로 가는 트래픽이 AZ 경계를 넘기 시작합니다.

그림 2. Application Load Balancer와 Network Load Balancer의 AZ 간 트래픽 요금 차이

두 설정을 조정하면 클라이언트에서 대상까지 트래픽을 같은 AZ 안에 묶을 수 있습니다.

첫째, 클라이언트 라우팅 정책을 AZ 친화도(Zonal Affinity)로 변경합니다. NLB 속성 dns_record.client_routing_policy를 availability_zone_affinity로 설정하면 DNS 응답이 클라이언트와 같은 AZ의 NLB IP를 100% 우선합니다. partial_availability_zone_affinity는 85%만 같은 AZ로 보내고 나머지를 다른 AZ로 분산합니다. 클라이언트 AZ에 정상 NLB IP가 없으면 다른 AZ로 넘어가므로 가용성은 유지됩니다. 이 설정은 같은 VPC의 클라이언트뿐 아니라 Transit Gateway나 VPC Peering을 거쳐 내부 NLB에 접근하는 클라이언트에도 같은 원리로 동작합니다.

둘째, 교차 영역 로드 밸런싱을 비활성화 상태로 유지합니다. 로드 밸런서 속성과 대상 그룹 속성 모두 load_balancing.cross_zone.enabled로 제어합니다. 대상 그룹 값은 true, false, use_load_balancer_configuration 중 하나입니다.

# 클라이언트 라우팅 정책을 100% AZ 친화도(Zonal Affinity)로 변경
aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn arn:aws:elasticloadbalancing:ap-northeast-2:111122223333:loadbalancer/net/internal-nlb/0123456789abcdef \
  --attributes Key=dns_record.client_routing_policy,Value=availability_zone_affinity

# 로드 밸런서 수준의 교차 영역 로드 밸런싱 비활성화
aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn arn:aws:elasticloadbalancing:ap-northeast-2:111122223333:loadbalancer/net/internal-nlb/0123456789abcdef \
  --attributes Key=load_balancing.cross_zone.enabled,Value=false

# 대상 그룹이 로드 밸런서 설정을 따르도록 변경
aws elbv2 modify-target-group-attributes \
  --target-group-arn arn:aws:elasticloadbalancing:ap-northeast-2:111122223333:targetgroup/app-tg/0123456789abcdef \
  --attributes Key=load_balancing.cross_zone.enabled,Value=use_load_balancer_configuration

두 설정을 함께 적용하면 클라이언트, NLB 노드, 대상이 같은 AZ 안에서 완결되는 AZ 독립(Availability Zone Independence, AZI) 구성이 됩니다. AZ 간 요금이 사라질 뿐 아니라 한 AZ의 장애가 다른 AZ의 요청에 영향을 주지 않고, 장애 AZ에서 트래픽을 빼내는 영역 전환(Zonal Shift)도 단순해집니다. 대신 AZ마다 대상 수를 비례해서 맞춰야 합니다. 한 AZ의 대상이 부족하면 그 AZ로 들어온 요청이 몰리기 때문입니다. Auto Scaling 그룹의 AZ 균형 유지 기능이 이 역할을 합니다. 상세 절차와 콘솔 화면 예시는 해당 블로그(Optimizing data transfer costs when using AWS Network Load Balancer)에서 확인할 수 있습니다.

그림 3. NLB 기본 설정과 AZ 독립(AZI) 구성의 트래픽 경로

Gateway Load Balancer도 NLB와 같은 규칙을 따릅니다. 교차 영역 로드 밸런싱이 기본 비활성화이고, 활성화하면 어플라이언스로 향하는 AZ 간 트래픽에 리전 데이터 전송 요금이 과금됩니다.

2.3 퍼블릭 IP로 접근하는 내부 클라이언트

퍼블릭 로드 밸런서에 같은 VPC의 클라이언트가 퍼블릭 IP로 접근하는 구성은 ALB와 NLB 모두 요금이 과금됩니다. 트래픽이 인터넷 게이트웨이를 거쳐 왕복하므로 양방향에 $0.01가 과금되고, 이때는 서브넷, AZ, VPC가 어디든 영향이 없습니다. 내부 클라이언트용으로는 별도의 내부 로드 밸런서를 두는 편이 대부분 저렴합니다. 시간당 2GB를 퍼블릭 IP로 보내면 $0.04가 드는데, 서울 리전에서 ALB나 NLB 하나를 추가하는 시간당 요금은 $0.0225입니다. LCU 또는 NLCU 요금이 더해지지만 트래픽이 조금만 늘어도 내부 로드 밸런서가 유리합니다.

3. 데이터베이스 계층의 전송 비용

데이터베이스는 애플리케이션 서버와 가장 많은 트래픽을 주고받는 구성 요소입니다. 초당 수천 건의 쿼리가 AZ 경계를 넘으면 매달 눈에 띄는 금액이 됩니다. 관리형 데이터베이스는 복제와 백업 트래픽 상당 부분을 무료로 처리합니다. 무료 구간과 유료 구간을 정확히 알아야 설계에 반영할 수 있습니다.

3.1 Amazon RDS

EC2와 RDS 인스턴스가 같은 AZ에 있으면 전송 요금이 없습니다. AZ가 다르면 송신과 수신 방향마다 EC2 인스턴스 측에 GB당 $0.01가 과금됩니다. 다음 세 가지 트래픽은 무료입니다. 다중 AZ 배포에서 프라이머리와 스탠바이 사이의 복제, 같은 리전 안의 읽기 전용 복제본으로 향하는 복제, 같은 리전의 S3로 전송되는 스냅샷입니다. 반면 다른 리전의 읽기 전용 복제본으로 향하는 복제, 스냅샷의 리전 간 복사, 자동 교차 리전 백업에는 리전 간 요금이 과금됩니다. 서울에서 us-east-1로 보내면 $0.08, 반대 방향은 $0.02입니다. RDS가 NAT Gateway를 거쳐 인터넷으로 데이터를 보내는 경우는 EC2와 같습니다. DTO $0.126에 NAT Gateway 처리 요금 $0.059가 더해집니다.

그림 4. Amazon RDS를 중심으로 한 데이터 전송 요금과 무료 구간

설계에서 확인할 점은 애플리케이션 서버가 어느 AZ의 엔드포인트에 연결하는지입니다. 다중 AZ 배포에서 쓰기 트래픽은 프라이머리가 있는 AZ로 향합니다. 두 AZ에 배치한 애플리케이션 서버 중 절반은 항상 AZ 경계를 넘습니다. 이 구조는 가용성을 위해 감수하는 비용입니다. 읽기 트래픽은 다릅니다. 읽기 전용 복제본을 애플리케이션 서버와 같은 AZ에 두고 AZ별로 연결하면 읽기 트래픽의 AZ 간 요금이 사라집니다.

3.2 Amazon DynamoDB와 Amazon Redshift

DynamoDB는 인바운드 전송이 무료입니다. 같은 리전 안에서 EC2와 DynamoDB 사이의 전송도 무료입니다. 프라이빗 서브넷에서는 게이트웨이 엔드포인트를 사용해 NAT Gateway 처리 요금까지 제거하는 것을 권장합니다. DynamoDB Accelerator(DAX)를 사용하는 경우 EC2와 DAX 노드가 같은 AZ에 있으면 무료입니다. AZ가 다르면 양방향 $0.01가 과금됩니다. 다른 리전으로 데이터를 보낼 때는 리전 간 요금이 적용됩니다.

Redshift는 같은 리전의 S3와 주고받는 백업, 복원, 로드(COPY), 언로드(UNLOAD) 트래픽이 무료입니다. 스냅샷을 다른 리전으로 복사하면 리전 간 요금이 과금됩니다. 이때도 방향에 따라 요금이 다릅니다. 서울에서 us-east-1로 보내면 $0.08입니다. 반대 방향은 $0.02입니다. 재해 복구를 위해 스냅샷을 두 리전에 유지하는 구조라면 어느 리전을 프라이머리로 삼는지에 따라 복제 비용이 4배 차이 납니다.

3.3 자체 구축 데이터 저장소의 AZ 간 복제 비용

EC2에 직접 구축한 검색 엔진, 인메모리 캐시, NoSQL 클러스터는 상황이 다릅니다. 노드 간 복제 트래픽이 관리형 서비스처럼 면제되지 않습니다. 일반 EC2 트래픽으로 과금됩니다. 세 개 AZ에 노드를 분산한 클러스터는 쓰기 한 건이 들어올 때마다 복제본 수만큼 AZ 경계를 넘습니다. 이 트래픽은 하루 24시간 발생합니다. 1부에서 언급한 고객 사례에서 분기마다 늘어나던 AZ 간 요금의 원인이 이 구조였습니다.

같은 기능을 제공하는 관리형 서비스가 있다면 요금 페이지에서 복제 트래픽 면제 항목을 먼저 확인하는 것을 권고합니다. 자체 구축을 유지해야 한다면 복제본 수, 복제 방식(동기 또는 비동기), 클라이언트가 읽는 노드의 AZ를 점검하는 것을 권고드립니다. AZ 경계를 넘는 트래픽을 줄이는 것이 우선입니다.

4. 캐시 계층: Amazon ElastiCache와 Valkey GLIDE의 AZ 친화도

캐시는 데이터베이스보다 호출 빈도가 높습니다. ElastiCache를 다중 AZ로 구성하면 샤드마다 프라이머리와 복제본이 서로 다른 AZ에 놓입니다. EC2와 ElastiCache 노드가 다른 AZ에 있으면 EC2에서 나가고 들어오는 트래픽에 GB당 $0.01가 과금됩니다. EC2 사이의 통신과 다르게 ElastiCache 노드 쪽에는 요금이 기록되지 않으므로 방향당 $0.01입니다. 대부분의 클라이언트 라이브러리는 읽기 요청을 복제본에 라운드 로빈으로 분산합니다. 복제본이 세 개 AZ에 있으면 읽기 요청의 약 3분의 2가 AZ 경계를 넘습니다. 캐시 읽기 트래픽은 상시 발생하므로 이 비율이 그대로 월 비용이 됩니다.

Valkey GLIDE는 AWS가 개발을 주도하는 Valkey 공식 오픈 소스 클라이언트입니다. GLIDE 1.2부터 AZ 친화도(AZ Affinity) 읽기 전략을 제공합니다. Valkey 8.0에 추가된 availability-zone 서버 설정으로 각 노드의 AZ를 확인한 뒤, 읽기 요청을 클라이언트와 같은 AZ의 노드로 보내는 방식입니다. 자체 구축 Valkey는 8.0 이상에서 노드마다 이 설정을 지정해야 합니다. ElastiCache는 노드의 AZ 매핑을 서비스가 자동으로 채우며, Valkey GLIDE 문서는 ElastiCache for Valkey 7.2 이상을 지원 범위로 명시합니다. Java, Python, Node.js 등 여러 언어를 지원합니다. 읽기 전략은 네 가지입니다.

표 3. Valkey GLIDE의 네 가지 읽기 전략과 AZ 간 트래픽 발생 여부

두 AZ 친화도 전략은 client_az 설정이 필수입니다. 클라이언트가 자기 AZ를 알아야 같은 AZ의 노드를 고를 수 있기 때문입니다. EC2에서는 인스턴스 메타데이터(IMDSv2)의 placement/availability-zone 값을, EKS에서는 노드 레이블 topology.kubernetes.io/zone 값을 시작 시점에 읽어 넣으면 됩니다. Python 클라이언트 설정 예시는 다음과 같습니다.

import asyncio
from glide import (GlideClusterClient, GlideClusterClientConfiguration,
                   NodeAddress, ReadFrom)

async def main():
    config = GlideClusterClientConfiguration(
        addresses=[NodeAddress("clustercfg.my-valkey.abc123.apn2.cache.amazonaws.com", 6379)],
        use_tls=True,
        read_from=ReadFrom.AZ_AFFINITY_REPLICAS_AND_PRIMARY,
        client_az="ap-northeast-2a",  # IMDSv2 또는 노드 레이블에서 읽은 값
    )
    client = await GlideClusterClient.create(config)
    print(await client.get("session:1234"))

asyncio.run(main())

그림 5. 라운드 로빈 읽기와 Valkey GLIDE AZ 친화도 읽기의 트래픽 경로 비교

효과는 읽기 비중에 비례합니다. 초당 250MB를 읽는 클러스터에서 요청의 절반이 AZ 경계를 넘는다고 가정하면 한 달(730시간)에 약 313TB가 AZ를 넘습니다. EC2 측 요금 GB당 $0.01를 적용하면 월 약 $3,200입니다. 이 시나리오는 Valkey 블로그의 AZ 친화도 소개 글의 예시를 서울 리전 요금과 730시간 기준으로 다시 계산한 것입니다. AZ 친화도로 읽기를 같은 AZ에 묶으면 이 금액이 사라집니다. 쓰기는 프라이머리로 가므로 프라이머리와 다른 AZ에 있는 클라이언트의 쓰기 트래픽에는 요금이 남습니다. HotelTrader는 Lettuce 클라이언트를 GLIDE로 교체하면서 AZ_AFFINITY_REPLICAS_AND_PRIMARY 전략과 요청 배칭(여러 번의 HGET을 한 번의 HMGET으로 묶는 방식)을 함께 적용해 AZ 간 전송 비용을 95% 줄이고 평균 지연 시간을 49%(배칭 효과 포함) 개선했습니다. 자세한 과정은 How HotelTrader cut inter-AZ cost 95% and latency by 49% with Valkey GLIDE on Amazon ElastiCache에서 확인할 수 있습니다.

적용 전에 두 가지를 확인하는 것을 권고드립니다. 첫째, 클라이언트가 있는 모든 AZ에 샤드별 복제본이 하나 이상 있어야 합니다. 복제본이 없는 AZ의 클라이언트는 다른 AZ로 폴백하므로 요금이 그대로 과금됩니다. 복제본 수를 AZ 수에 맞추면 노드 비용이 늘어나므로 읽기 트래픽으로 절감되는 금액과 비교해서 결정하는 것을 권고합니다. 둘째, 복제본 읽기는 복제 지연만큼 오래된 값을 돌려줄 수 있습니다. 최신 값이 필요한 키는 PRIMARY 전략의 별도 클라이언트로 읽는 방법이 있습니다.

5. Amazon EKS의 네트워크 비용

Kubernetes는 기본적으로 AZ를 인식하지 않습니다. ClusterIP 타입 Service로 들어온 요청은 kube-proxy가 모든 정상 파드에 고르게 분산합니다. 파드가 세 개 AZ에 퍼져 있으면 요청의 약 3분의 2가 AZ 경계를 넘습니다. 마이크로서비스가 서로 호출하는 구조에서는 호출 단계마다 이 비율이 반복됩니다. 요청 하나가 여러 번 AZ 경계를 넘나드는 셈입니다. 노드 간 트래픽은 EC2 트래픽으로 과금되므로 이 모든 구간에 양방향 $0.01가 과금됩니다.

로드 밸런서에서 파드로 들어오는 경로에도 같은 문제가 있습니다. AWS Load Balancer Controller의 instance 모드는 NodePort로 트래픽을 받은 뒤 kube-proxy가 다시 파드로 전달합니다. 대상 파드가 다른 AZ의 노드에 있으면 추가 홉이 생기고 AZ 간 요금이 과금됩니다. NLB를 사용한다면 앞 섹션의 AZ 친화도(Zonal Affinity)와 교차 영역 설정이 그대로 적용됩니다.

그림 6. EKS에서 AZ 경계를 넘는 트래픽이 발생하는 두 경로

다섯 가지 설정으로 이 트래픽을 줄일 수 있습니다.

첫째, AWS Load Balancer Controller를 IP 모드로 구성합니다. Ingress에는 alb.ingress.kubernetes.io/target-type: ip, LoadBalancer 타입 Service에는 service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip 어노테이션을 지정합니다. 로드 밸런서가 파드 IP로 직접 트래픽을 보내므로 NodePort 홉이 사라집니다.

둘째, Topology Aware Routing을 활성화합니다. Service에 service.kubernetes.io/topology-mode: Auto 어노테이션을 추가하면 kube-proxy가 같은 AZ의 엔드포인트를 우선 선택합니다. Kubernetes 1.33부터 정식 기능이 된 Service 스펙의 spec.trafficDistribution 필드로 같은 동작을 더 단순하게 설정할 수 있습니다. 1.35에서는 값으로 PreferSameZone을 사용하고, 이전 버전의 PreferClose는 같은 뜻의 옛 별칭입니다. 두 방식 모두 각 AZ에 엔드포인트가 고르게 있어야 제대로 동작합니다. topologySpreadConstraints로 파드를 AZ별로 균등 분산하는 것을 권장합니다. 한 AZ에 파드가 없으면 그 AZ의 요청은 다른 AZ로 넘어갑니다. 특정 AZ의 파드만 과부하되는 일도 생길 수 있습니다.

셋째, 서비스 메시를 사용한다면 Istio의 Locality Load Balancing을 활성화합니다. 사이드카가 같은 AZ의 대상을 우선하도록 localityLbSetting을 지정하면 메시 안의 서비스 간 호출에서 AZ 경계를 넘는 비율이 낮아집니다.

넷째, 파드 단위로 AZ 간 트래픽을 측정합니다. Amazon EKS의 Container Network Observability는 Amazon CloudWatch Network Flow Monitor를 기반으로 클러스터 안의 네트워크 흐름을 파드 수준에서 보여 주는 기능입니다. 노드마다 Network Flow Monitor Agent 애드온(aws-network-flow-monitoring-agent)이 데몬으로 실행되어 흐름을 수집하고, EKS 콘솔의 Observability 탭에서 네트워크 모니터링을 켜면 별도 파이프라인 없이 사용할 수 있습니다. 에이전트 애드온 v1.1.0 이상이 필요하고, 이 버전은 Kubernetes 1.28 이상 클러스터에서 사용할 수 있습니다. Network Flow Monitor가 제공되는 리전인지도 함께 확인하는 것을 권장합니다. 흐름 테이블(flow table)은 세 가지 뷰를 제공합니다. Cluster 뷰에서 AZ 경계를 넘는 흐름(Inter AZ)만 필터하고 전송량으로 정렬하면 어느 워크로드 쌍이 AZ 경계를 가장 많이 넘는지 바로 확인할 수 있습니다. External 뷰는 AWS 밖으로 나가는 트래픽을 보여 주므로 NAT Gateway 처리 요금을 만드는 워크로드를 찾는 데 쓰입니다. AWS Service 뷰는 S3, DynamoDB와 주고받는 트래픽을 워크로드별로 보여 줍니다. 같은 데이터는 AWS CLI로도 조회할 수 있습니다.

# 최근 1시간 동안 AZ 경계를 넘은 트래픽 상위 기여 워크로드 조회
aws networkflowmonitor start-query-monitor-top-contributors \
  --monitor-name <monitor-name> \
  --start-time 2026-09-13T00:00:00Z --end-time 2026-09-13T01:00:00Z \
  --metric-name DATA_TRANSFERRED \
  --destination-category INTER_AZ
# destination-category: INTRA_AZ, INTER_AZ, INTER_REGION, INTER_VPC, AMAZON_S3, AMAZON_DYNAMODB, UNCLASSIFIED

위 설정을 적용하기 전과 후에 같은 필터로 흐름 테이블(flow table)을 비교하면 효과를 수치로 검증할 수 있습니다. 활성화 절차는 Container Network Observability in Amazon EKS를, 실제 절감 시나리오는 Track inter-AZ and NAT gateway traffic with EKS Container Network Observability에서 확인할 수 있습니다. Network Flow Monitor의 요금은 요금 문서를 확인하시길 권고드립니다. 각 최적화 방법의 상세 구성은 Amazon EKS Best Practices Guide의 Cost Optimization – Networking에 정리되어 있습니다.

다섯째, 컨테이너 이미지 풀 트래픽도 함께 점검하는 것을 권고합니다. 1부에서 설명한 것처럼 ECR 인터페이스 엔드포인트와 S3 게이트웨이 엔드포인트를 함께 만들어야 노드가 이미지를 받을 때 NAT Gateway 처리 요금이 과금되지 않습니다. 다만 이 조치는 ECR에 있는 이미지에만 효과가 있습니다. Docker Hub나 registry.k8s.io 같은 외부 레지스트리에서 직접 받는 이미지는 여전히 NAT Gateway를 거쳐 인터넷으로 나가므로 처리 요금 $0.059와 DTO $0.126을 합쳐 GB당 $0.185가 과금됩니다.

Amazon ECR의 풀 스루 캐시(Pull Through Cache)가 이 경로를 없앱니다. 외부 레지스트리를 업스트림으로 등록해 두면 첫 풀에서 ECR이 이미지를 가져와 캐시하고, 이후 노드는 같은 리전의 ECR에서 받습니다. 업스트림에서 가져오는 트래픽은 ECR 서비스가 처리하므로 사용자 VPC의 NAT Gateway를 지나지 않습니다. 월 1TB를 외부 레지스트리에서 직접 받던 클러스터라면 월 약 $189가 사라지고, 캐시한 이미지 100GB에 대한 ECR 스토리지 요금 월 $10이 대신 남습니다. Docker Hub의 요청 제한을 피하는 효과도 함께 얻습니다. 업스트림으로는 Amazon ECR Public, Kubernetes 컨테이너 이미지 레지스트리(registry.k8s.io), Quay, Docker Hub, GitHub Container Registry, GitLab Container Registry, Azure Container Registry, 다른 계정이나 리전의 ECR 프라이빗 레지스트리를 지원합니다. Docker Hub처럼 인증이 필요한 업스트림은 자격 증명을 AWS Secrets Manager 시크릿으로 등록합니다.

적용할 때는 이미지 참조를 ECR URI로 바꿔야 합니다. nginx:1.27이 <계정 ID>.dkr.ecr.ap-northeast-2.amazonaws.com/docker-hub/library/nginx:1.27 형태가 되므로 매니페스트와 Helm 값을 함께 수정하는 것을 권장합니다. 리포지토리 생성 템플릿(Repository Creation Template)을 만들어 두면 캐시 리포지토리가 처음 풀 시점에 자동으로 생성됩니다.

6. 2부 체크리스트

표 4. 2부 설계 체크리스트(서울 리전 요금 기준)

마치며

2부에서는 같은 리전 안에서 AZ 경계를 넘는 트래픽의 요금 규칙과 이를 최적화하는 방법을 살펴보았습니다. 핵심은 다음 세 가지입니다.

1. AZ 간 전송 요금은 보내는 자원과 받는 자원에 각각 $0.01가 과금됩니다. 예외를 정확히 알아야 합니다. 같은 VPC의 ALB 트래픽, 인터페이스 엔드포인트와 Transit Gateway 경유 트래픽, RDS의 복제 트래픽은 AZ를 넘어도 무료이고, 퍼블릭 IP 통신은 같은 AZ라도 유료입니다.
2. NLB는 기본값 두 가지가 AZ 간 요금을 만듭니다. 클라이언트 라우팅 정책을 AZ 친화도(Zonal Affinity)로 변경하고 교차 영역 로드 밸런싱을 비활성화 상태로 유지하면 클라이언트에서 대상까지 트래픽이 AZ 안에서 완결됩니다. 이 AZ 독립 구성은 비용과 복원력을 함께 개선합니다.
3. 데이터베이스, 캐시, EKS에서는 읽기 트래픽을 같은 AZ에 묶는 것이 핵심입니다. 읽기 전용 복제본의 AZ별 배치, Valkey GLIDE의 AZ 친화도 읽기 전략, IP 모드, Topology Aware Routing처럼 트래픽을 같은 AZ에 머물게 하는 설정이 있고, CUR과 EKS Container Network Observability로 효과를 수치로 확인할 수 있습니다.

3부에서는 VPC 경계를 넘는 비용을 다룹니다. VPC Peering과 Transit Gateway의 요금 구조, AWS PrivateLink와 Amazon VPC Lattice의 새 엔드포인트 유형, AWS Cloud WAN, 그리고 Direct Connect와 Site-to-Site VPN으로 온프레미스와 us-east-1을 연결할 때의 비용을 살펴봅니다. (3부 링크)

참고 자료

• Amazon EC2 온디맨드 요금 – 데이터 전송
• Elastic Load Balancing 요금
• Elastic Load Balancing FAQ
• Exploring Data Transfer Costs for AWS Network Load Balancers – Networking & Content Delivery Blog
• Optimizing data transfer costs when using AWS Network Load Balancer – Networking & Content Delivery Blog
• Classic 및 Application Load Balancers의 데이터 전송 비용 살펴보기 – AWS 기술 블로그
• Cost Optimization – Networking – Amazon EKS Best Practices Guide
• Container Network Observability in Amazon EKS – Amazon EKS User Guide
• Track inter-AZ and NAT gateway traffic with EKS Container Network Observability – AWS Containers Blog
• Sync an upstream registry with an Amazon ECR private registry (pull through cache) – Amazon ECR User Guide
• Valkey GLIDE 1.2 adds new features from Valkey 8.0, including AZ awareness
• How HotelTrader cut inter-AZ cost 95% and latency by 49% with Valkey GLIDE on Amazon ElastiCache – AWS Database Blog
• Understanding data transfer charges – AWS Data Exports User Guide
• Amazon VPC Announces Pricing Change for VPC Peering