Notes

Cloud Data Transfer와 Egress

Cloud data transfer를 ingress/egress, public/private network, zone/region boundary, on-premises connectivity, CDN, NAT, Kubernetes, 비용, 성능, 보안, observability 관점에서 정리한 DevOps 네트워킹 개념 노트

Published: Jun 2, 2026
Updated: Jun 2, 2026
Area: Computer Networks
Type: concept
Series: Cloud Networking
Category: Notes

data-transferegressingressbandwidththroughputlatencyprivate-networkpublic-networkcross-zonecross-regioncdnnatkubernetesobservability

데이터가 이동하는 경로를 먼저 그려야 한다

Cloud에서 data transfer는 단순히 파일을 복사하는 행위만 의미하지 않는다. 사용자, cloud server, object storage, database, Kubernetes cluster, 다른 region, on-premises network 사이에서 발생하는 모든 network communication이 data transfer다.

Data transfer:
한 위치의 data가 network를 통해 다른 위치로 이동하는 것

Cloud data transfer:
user, cloud server, storage, database, region, zone, on-premises network 사이에서
data가 ingress 또는 egress 방향으로 이동하는 것

Cloud data transfer를 이해하려면 다음 질문을 먼저 해야 한다.

1. 데이터가 어디에서 출발하는가?
2. 데이터가 어디로 도착하는가?
3. public network를 지나는가, private network를 지나는가?
4. 같은 zone 내부인가, zone 간인가, region 간인가?
5. internet으로 나가는 egress인가?
6. on-premises와 cloud 사이의 연결인가?
7. 성능 병목은 bandwidth인가, latency인가, packet loss인가?
8. 비용은 ingress에 붙는가, egress에 붙는가?

Data transfer 설계의 핵심은 “얼마나 많은 데이터가 이동하는가”뿐 아니라, 어떤 network path로 이동하는가를 파악하는 것이다.

Data Transfer와 Bandwidth는 다르다

Cloud networking에서 자주 헷갈리는 개념이 data transfer, bandwidth, throughput, latency다.

구분	의미
Data transfer	실제로 이동한 데이터의 양
Bandwidth	단위 시간당 이동할 수 있는 데이터 전송 용량
Throughput	실제로 관측된 전송 속도
Latency	한 지점에서 다른 지점까지 왕복 또는 전달되는 지연 시간

예를 들어 100GB 파일을 cloud storage에서 VM으로 복사했다면 data transfer amount는 100GB다.

Data transferred = 100GB

반면 이 파일을 얼마나 빠르게 옮길 수 있는지는 bandwidth와 throughput의 문제다.

Bandwidth = 10Gbps link
Throughput = 실제로 6Gbps 정도 나옴

Latency는 또 다른 문제다.

Latency:
request를 보내고 response가 돌아오기까지 걸리는 시간

정리하면 다음과 같다.

Data transfer amount:
얼마나 많이 옮겼는가?

Bandwidth:
얼마나 큰 통로를 가지고 있는가?

Throughput:
실제로 얼마나 빠르게 옮겨졌는가?

Latency:
응답까지 얼마나 오래 걸리는가?

Cloud 비용에서는 보통 이동한 양, 특히 outbound data transfer 또는 egress traffic이 중요하다. 성능에서는 bandwidth, throughput, latency, packet loss가 함께 중요하다.

Cloud에서 Data Transfer가 발생하는 경로

Cloud data transfer는 여러 경로에서 발생한다.

1. User → Cloud
2. Cloud → User
3. Cloud Resource → Cloud Resource
4. Zone → Zone
5. Region → Region
6. Cloud → On-premises
7. On-premises → Cloud
8. Cloud → Internet
9. Internet → Cloud
10. Cloud → CDN Edge

같은 “데이터 전송”이라도 다음은 모두 성격이 다르다.

사용자가 웹사이트에 이미지 업로드
VM이 object storage에서 파일 다운로드
Kubernetes pod가 다른 zone의 database에 query
VPC가 on-premises database와 VPN으로 통신
backup data를 다른 region으로 복제
CDN edge가 origin에서 static asset fetch

각 경로는 비용, latency, 보안, routing, architecture 설계가 다르다. 따라서 cloud architecture diagram을 그릴 때는 resource뿐 아니라 data flow도 함께 그려야 한다.

Ingress와 Egress

Cloud data transfer에서 가장 중요한 구분은 ingress와 egress다.

Ingress

Ingress는 cloud 안으로 들어오는 traffic이다.

User / Internet / On-premises
  ↓
Cloud

예시는 다음과 같다.

사용자가 object storage에 파일 업로드
on-premises system이 cloud database에 data push
external API가 cloud service로 webhook 전송
client가 web server에 HTTP request 전송

Ingress는 cloud 안으로 들어오는 traffic이므로 많은 cloud billing model에서 무료이거나 상대적으로 덜 중요한 비용 항목으로 다뤄질 수 있다. 다만 “항상 무료”라고 단정하면 안 되며, provider와 service 정책을 확인해야 한다.

Egress

Egress는 cloud 밖으로 나가는 traffic이다.

Cloud
  ↓
User / Internet / On-premises / Other region

예시는 다음과 같다.

사용자가 cloud server에서 파일 다운로드
web server가 image, JS, CSS를 사용자에게 전송
database backup을 다른 region으로 복사
cloud VM이 외부 API로 response 전송
object storage에서 large file을 외부로 내려받음

Cloud 비용에서 특히 중요한 것은 egress다.

방향	의미	비용 관점
Ingress	cloud로 들어오는 traffic	무료 또는 낮은 비용인 경우가 많음
Egress	cloud 밖으로 나가는 traffic	과금 대상인 경우가 많음

Cloud 비용을 볼 때는 “내가 데이터를 얼마나 저장했는가”뿐 아니라 “그 데이터가 어디로 얼마나 나갔는가”를 반드시 봐야 한다.

Public Network와 Private Network

Data transfer를 이해할 때 두 번째로 중요한 구분은 public network와 private network다.

Public Network

Public network는 internet-facing network다.

Cloud VM
  ↓
Public IP
  ↓
Internet
  ↓
End User

예시는 다음과 같다.

사용자가 public web server에 접속
object storage public endpoint에서 파일 다운로드
public IP를 가진 VM이 internet으로 response 전송
CDN이 public origin으로 fetch

Public network를 사용하면 internet을 통해 접근 가능하므로 편리하다. 하지만 보안과 비용을 신중히 봐야 한다.

장점:
외부 사용자 접근 쉬움
global internet connectivity 사용 가능

주의점:
public exposure
firewall/security group 필요
egress 비용 발생 가능
DDoS와 scanning 노출

Private Network

Private network는 cloud provider 내부 backbone 또는 isolated private connectivity를 사용하는 network다.

Cloud VM A
  ↓ private IP
Cloud VM B

On-premises와 cloud를 private connectivity로 연결할 수도 있다.

On-premises Data Center
  ↓ private link
Cloud VPC / Private Network

Public과 private을 비교하면 다음과 같다.

구분	Public Network	Private Network
접근성	internet에서 접근 가능	private path 또는 private IP 기반
보안	firewall, WAF, security group 필요	외부 노출 감소
비용	public outbound 과금 가능	provider 정책에 따라 다름
성능	internet path 품질에 영향	더 예측 가능한 path 가능
대표 용도	사용자-facing service	internal service, DB, backup, replication

시나리오 1: User와 Cloud 사이

가장 직관적인 data transfer는 사용자가 cloud service에 접속하는 경우다.

User
  ↓ request
Cloud Application
  ↓ response
User

사용자가 웹페이지에 접속하면 다음 data transfer가 발생한다.

User → Cloud:
HTTP request, cookie, header, small payload

Cloud → User:
HTML, CSS, JavaScript, image, font, API response

실제 전송량은 보통 response 방향이 더 크다.

Request:
GET /index.html
수 KB 수준

Response:
HTML + JS + CSS + images
수 MB 이상 가능

즉 사용자-facing web service에서는 egress가 비용과 성능의 핵심이 된다.

Cloud egress:
web server → user
object storage → user
CDN edge → user

이 때문에 CDN이 중요하다. CDN을 사용하면 origin server가 모든 egress를 직접 처리하지 않고, edge server가 사용자 가까이에서 응답할 수 있다.

User
  ↓
CDN Edge
  ↓ cache miss인 경우만
Origin

시나리오 2: Cloud 내부 Resource 간 통신

두 번째 시나리오는 cloud 내부 resource 간 통신이다.

App Server
  ↓
Database

또는 Kubernetes 환경에서는 다음과 같은 구조가 많다.

Kubernetes Pod
  ↓
Internal Service
  ↓
Database

같은 cloud 내부 통신이라고 해서 모두 같은 성격은 아니다. 다음을 구분해야 한다.

같은 VM 내부 통신
같은 subnet 내부 통신
같은 zone 내부 통신
zone 간 통신
region 간 통신
public IP를 통한 내부 통신
private IP를 통한 내부 통신

예를 들어 app server와 database가 같은 zone의 private network 안에 있다면 latency와 비용 측면에서 유리할 수 있다.

Zone 1
├── App Server
└── Database

private IP communication

반대로 app server는 Zone 2에 있고 database primary가 Zone 1에만 있다면 cross-zone traffic이 발생한다.

Zone 2 App
  ↓ cross-zone traffic
Zone 1 DB

MZR 구조에서는 high availability를 위해 zone 간 분산이 필요하지만, cross-zone traffic이 늘어날 수 있다. 따라서 HA와 latency, 비용 사이의 trade-off를 봐야 한다.

시나리오 3: Zone 간 Data Transfer

MZR에서 특히 중요한 것이 zone 간 data transfer다.

Zone 1
  ↕
Zone 2
  ↕
Zone 3

Zone 간 data transfer는 다음 상황에서 발생한다.

App server가 다른 zone의 database에 접근
replica 간 데이터 동기화
distributed database quorum traffic
Kubernetes pod가 다른 zone의 service 호출
cross-zone load balancing
message queue replication
storage replication

Zone 간 통신은 high availability를 위해 필요하지만, 무조건 많을수록 좋은 것은 아니다.

예를 들어 다음 구조는 availability에는 좋지만 cross-zone traffic을 증가시킬 수 있다.

Zone 1: App
Zone 2: App
Zone 3: App

Database primary: Zone 1

이 경우 Zone 2, Zone 3의 app은 write 요청을 위해 Zone 1 DB로 traffic을 보낸다.

Zone 2 App → Zone 1 DB
Zone 3 App → Zone 1 DB

개선 방향은 다음과 같다.

read replica를 zone별 배치
zone-local cache 사용
service mesh locality routing
database leader placement 검토
cross-zone call 최소화

시나리오 4: Region 간 Data Transfer

Region 간 data transfer는 더 큰 지리적 거리를 넘는 전송이다.

Region A
  ↓
Region B

예시는 다음과 같다.

primary region에서 secondary region으로 backup 복제
object storage cross-region replication
multi-region database replication
global application data sync
DR 환경으로 snapshot 복사
analytics region으로 log 전송

Region 간 전송은 zone 간 전송보다 더 큰 latency와 비용을 가질 수 있다.

Zone 간:
같은 region 내부
낮은 latency

Region 간:
서로 다른 geographic location
더 높은 latency
DR, global service, data residency 고려

Region 간 data transfer에서는 다음을 설계해야 한다.

RPO:
얼마나 많은 데이터 손실을 허용할 수 있는가?

RTO:
얼마나 빨리 다른 region에서 복구해야 하는가?

Replication mode:
synchronous인가 asynchronous인가?

Cost:
얼마나 자주, 얼마나 많은 데이터를 복제하는가?

Consistency:
strong consistency가 필요한가 eventual consistency로 충분한가?

시나리오 5: On-Premises와 Cloud 사이

기업 환경에서는 on-premises data center와 cloud 사이의 data transfer가 중요하다.

On-premises Data Center
  ↓
Cloud VPC

대표적인 연결 방식은 다음과 같다.

Public internet
Site-to-site VPN
Private dedicated connection
Direct Link
Transit Gateway

일반적으로 비교하면 다음과 같다.

연결 방식	장점	주의점
Public internet	구성 쉬움	보안, 예측 가능성, latency 변동
VPN	암호화된 tunnel	internet 품질에 영향, throughput 제한 가능
Direct/private link	예측 가능한 성능과 private connectivity	비용, 회선 구성, 운영 절차
Transit gateway	여러 VPC와 on-prem 연결 단순화	routing 설계 필요

On-premises와 cloud 사이 data transfer는 다음 use case에서 자주 발생한다.

hybrid application
database migration
backup to cloud
log shipping
AI/ML data upload
enterprise file transfer
mainframe 또는 legacy system 연동
private API integration

Public Data Transfer와 Private Data Transfer의 비용 차이

Cloud에서 data transfer 비용은 provider마다 다르지만, 일반적으로 다음 패턴이 중요하다.

Ingress:
무료 또는 낮은 비용인 경우가 많음

Public egress:
과금 대상인 경우가 많음

Private/internal transfer:
조건부 무료 또는 별도 정책

Cross-zone/cross-region:
provider와 경로에 따라 과금 가능

Dedicated link:
port, bandwidth, metering 정책 확인 필요

따라서 cloud architecture에서는 다음을 구분해야 한다.

이 traffic은 public egress인가?
private backbone traffic인가?
same-zone private traffic인가?
cross-zone private traffic인가?
internet-facing response인가?
CDN에서 처리되는가?

비용 최적화의 출발점은 “어디서 어디로 데이터가 나가는지”를 그리는 것이다.

Data Transfer 경로를 그리는 방법

Data transfer를 제대로 이해하려면 architecture diagram에서 resource만 그리면 부족하다. 데이터 흐름을 화살표로 그려야 한다.

예를 들어 다음 web application이 있다고 하자.

User
  ↓
CDN
  ↓
Load Balancer
  ↓
App Server
  ↓
Database
  ↓
Object Storage

여기서 data transfer는 여러 방향으로 발생한다.

User → CDN:
HTTP request ingress

CDN → User:
cached response egress

CDN → Origin LB:
cache miss request

LB → App:
internal traffic

App → DB:
query traffic

App → Object Storage:
file read/write

Object Storage → App:
data response

App → External API:
internet egress

External API → App:
internet ingress

이 흐름을 보면 어느 구간이 비용과 성능의 핵심인지 알 수 있다.

High static asset traffic
  ↓
CDN cache hit ratio 중요

High DB traffic
  ↓
App-DB locality 중요

Large backup replication
  ↓
region-to-region transfer 비용과 RPO 설계 중요

성능 관점: Bandwidth, Latency, Packet Loss

Data transfer 성능은 단순히 bandwidth만으로 결정되지 않는다.

Bandwidth

Bandwidth는 전송 가능한 최대 용량이다.

1Gbps
10Gbps
100Gbps

대용량 파일 전송, backup, replication, video delivery에서는 bandwidth가 중요하다.

Latency

Latency는 요청과 응답 사이의 지연이다.

Client → Server → Client

작은 request를 자주 보내는 application은 bandwidth보다 latency에 더 민감하다.

database query
API call
authentication request
microservice call
control plane request

Packet Loss

Packet loss가 있으면 TCP retransmission이 발생하고 throughput이 떨어질 수 있다.

packet loss
  ↓
retransmission
  ↓
effective throughput 감소
  ↓
latency 증가

Jitter

Jitter는 latency의 변동성이다. 실시간 service에서는 중요하다.

voice
video call
gaming
vRAN / telco workload
real-time streaming

정리하면 다음과 같다.

지표	중요한 경우
Bandwidth	대용량 file transfer, backup, video
Latency	API, DB, microservice, user interaction
Packet loss	TCP throughput, streaming 품질
Jitter	voice, real-time, telco workload

TCP 관점에서 보는 Data Transfer

Data transfer 성능을 더 깊게 보면 TCP 동작도 중요하다.

TCP는 reliability를 제공하지만, latency와 packet loss에 민감하다.

TCP connection
  ↓
handshake
  ↓
congestion window 증가
  ↓
packet loss 발생 시 window 감소
  ↓
throughput 감소

대륙 간 data transfer처럼 RTT가 큰 구간에서는 TCP window size와 congestion control이 throughput에 큰 영향을 줄 수 있다.

High bandwidth + high latency
  ↓
BDP 증가

BDP = Bandwidth-Delay Product

Bandwidth가 충분해도 latency가 크고 TCP window가 작으면 link를 충분히 활용하지 못할 수 있다.

큰 pipe가 있지만
TCP가 한 번에 보낼 수 있는 양이 작으면
실제 throughput은 낮아질 수 있음

대용량 전송에서는 다음이 중요하다.

parallel transfer
multi-part upload
TCP tuning
window scaling
regional proximity
dedicated link
object storage transfer tool
compression
delta sync

Cloud Object Storage와 Data Transfer

Cloud object storage는 data transfer가 많이 발생하는 대표 서비스다.

예를 들어 다음 작업은 모두 transfer를 발생시킨다.

object upload
object download
cross-region replication
backup restore
analytics job input
CDN origin fetch
application file serving

Object storage는 storage 비용과 request 비용뿐 아니라 data transfer 비용도 고려해야 한다.

Storage cost:
얼마나 저장했는가?

Request cost:
얼마나 자주 읽고 쓰는가?

Transfer cost:
어디로 얼마나 나갔는가?

이미지 hosting service라면 저장 용량보다 egress가 비용의 핵심이 될 수 있다.

1TB image stored
100TB downloaded per month
  ↓
egress와 CDN 설계가 중요

CDN을 붙이면 반복 다운로드를 edge에서 처리할 수 있어 origin data transfer를 줄일 수 있다.

Database와 Data Transfer

Database는 data transfer를 많이 만들 수 있다.

application query
replication traffic
backup
restore
read replica sync
analytics export
CDC stream
cross-region DR replication

Database traffic의 특징은 단순히 양만 중요한 것이 아니라 latency도 중요하다는 점이다.

App → DB query
  ↓
latency가 증가하면
application response time 증가

특히 app과 DB가 서로 다른 zone 또는 region에 있으면 latency가 증가할 수 있다.

App in Region A
DB in Region B
  ↓
high latency
  ↓
slow transaction

Database는 다음을 고려해야 한다.

app과 DB의 proximity
read replica placement
cross-zone write latency
replication bandwidth
backup window
RPO/RTO
connection pooling
query result size

Data transfer 비용뿐 아니라 application performance까지 함께 봐야 한다.

Kubernetes와 Data Transfer

Kubernetes 환경에서는 data transfer가 더 복잡해진다.

Pod, Service, Node, Ingress, CNI, LoadBalancer, external service 사이에서 traffic이 발생한다.

Client
  ↓
Ingress / LoadBalancer
  ↓
Service
  ↓
Pod
  ↓
Database

Kubernetes에서 확인해야 할 data transfer 경로는 다음과 같다.

Pod → Pod
Pod → Service
Pod → external API
Ingress → Pod
Pod → database
Pod → object storage
Node → image registry
Node → control plane
cross-zone pod traffic

Multi-zone cluster에서는 pod placement가 중요하다.

Pod A in Zone 1
Pod B in Zone 2
  ↓
cross-zone traffic

이미지 pull도 data transfer다.

Node
  ↓
Container Registry
  ↓
Image layers download

대규모 cluster에서 node가 동시에 image를 pull하면 registry와 network에 큰 부하가 생길 수 있다.

rolling update
  ↓
many nodes pull image
  ↓
registry egress + node ingress + startup delay

운영적으로는 다음을 고려할 수 있다.

image layer caching
regional registry
private registry mirror
pre-pull DaemonSet
smaller image
multi-zone registry access

CDN과 Data Transfer

CDN은 data transfer를 최적화하는 대표적인 방법이다.

CDN이 없으면 모든 user-facing data가 origin에서 직접 나간다.

Origin
  ↓
All users

CDN을 사용하면 반복 요청은 edge에서 처리된다.

Origin
  ↓ initial fetch
CDN Edge
  ↓ repeated delivery
Users

이 구조는 다음을 줄일 수 있다.

origin egress
origin bandwidth usage
origin CPU load
long-distance latency
global response time variance

하지만 CDN도 data transfer를 없애는 것은 아니다. 위치를 바꾸는 것이다.

Origin egress 감소
CDN edge egress 증가

따라서 CDN 비용과 origin 비용을 함께 봐야 한다.

CDN request cost
CDN egress cost
origin fetch count
cache hit ratio
purge frequency

Load Balancer와 Data Transfer

Load balancer는 traffic을 backend로 분산하지만, 그 자체로 data path에 들어간다.

Client
  ↓
Load Balancer
  ↓
Backend

따라서 load balancer를 통과하는 traffic도 data transfer다.

MZR 구조에서는 regional load balancer가 여러 zone의 backend로 traffic을 보낼 수 있다.

Regional Load Balancer
  ↓
Zone 1 backend
Zone 2 backend
Zone 3 backend

주의할 점은 cross-zone load balancing이다.

Client request enters Zone 1
  ↓
Load balancer sends to backend in Zone 3
  ↓
cross-zone traffic 발생 가능

Cloud provider와 load balancer 구현에 따라 비용과 latency 영향이 다를 수 있으므로 확인이 필요하다.

NAT/Firewall과 Data Transfer

NAT와 firewall도 data transfer path에 들어간다.

Private subnet에서 internet으로 나가는 traffic은 NAT gateway나 public gateway를 지날 수 있다.

Private App Server
  ↓
NAT Gateway
  ↓
Internet

이때 확인해야 할 것은 다음이다.

NAT gateway throughput limit
NAT gateway cost
public egress cost
single-zone NAT SPOF 여부
firewall throughput
state table limit
connection tracking limit

모든 zone의 private subnet이 하나의 zone에 있는 NAT gateway만 사용하면, 그 zone 장애 시 전체 egress가 끊길 수 있다.

Zone 1 NAT Gateway
↑
Zone 1 app
Zone 2 app
Zone 3 app

Zone 1 failure
  ↓
all egress impacted

MZR에서는 NAT/egress도 zone-aware하게 설계하는 것이 좋다.

보안 관점

Data transfer는 보안 관점에서도 중요하다.

데이터가 이동할 때 다음을 고려해야 한다.

전송 중 암호화
private network 사용 여부
public internet 노출 여부
source/destination 제한
firewall policy
data residency
audit logging
DLP
access control
certificate management

On-premises와 cloud 사이에 민감한 데이터를 전송한다면 public internet으로 plaintext를 보내면 안 된다.

On-premises
  ↓ encrypted tunnel or private link
Cloud

일반적으로 필요한 보안 조치는 다음과 같다.

TLS
VPN
Direct/private connectivity
security group
network ACL
firewall
WAF
IAM
object storage bucket policy
audit log

데이터가 저장되어 있을 때의 보안뿐 아니라, 이동 중인 데이터의 보안도 설계해야 한다.

Data at rest:
저장 중인 데이터 보호

Data in transit:
전송 중인 데이터 보호

Compliance 관점

규제 환경에서는 data transfer가 단순한 비용 문제가 아니다.

다음 질문이 중요할 수 있다.

이 데이터가 어느 region으로 이동하는가?
국외 이전이 발생하는가?
개인정보가 포함되어 있는가?
암호화되어 있는가?
누가 접근할 수 있는가?
로그가 남는가?
backup이 어느 region에 저장되는가?
CDN edge가 어느 국가에서 응답하는가?

특히 multi-region replication이나 CDN 사용 시 데이터가 예상보다 넓은 geographic scope로 이동할 수 있다.

Primary region: Korea
Backup region: Japan
CDN edge: Global
Analytics region: US

이 경우 data residency와 compliance 요구사항을 확인해야 한다.

Data Transfer 비용을 줄이는 방법

Data transfer 비용 최적화는 cloud 비용 관리에서 매우 중요하다.

CDN 사용

반복적으로 다운로드되는 static asset은 CDN에 cache한다.

Origin egress 감소
User latency 감소

Data locality 확보

서로 자주 통신하는 resource는 같은 zone 또는 같은 region에 둔다.

App near DB
Compute near Storage
Analytics near Data Lake

Public path 대신 private path 사용

가능한 경우 private IP, private endpoint, private backbone, Direct Link를 사용한다.

public IP 통신
  ↓
private IP 통신으로 변경

불필요한 cross-region replication 줄이기

모든 데이터를 모든 region에 복제하면 비용이 급증할 수 있다.

필요한 dataset만 복제
RPO/RTO 기준으로 replication 주기 조정

Compression 사용

전송 전 압축 가능한 데이터는 압축한다.

logs
JSON
CSV
text files
backup

Delta sync 사용

전체 파일을 매번 보내지 않고 변경분만 전송한다.

full copy
  ↓
incremental copy

Query result 줄이기

Database나 API에서 필요한 데이터만 가져온다.

SELECT *
  ↓
필요한 column만 SELECT

Image/video 최적화

사용자에게 필요한 해상도와 format만 제공한다.

original 10MB image
  ↓
optimized 300KB WebP

Data Transfer 성능을 개선하는 방법

성능 최적화는 비용 최적화와 비슷하지만 목표가 다르다.

대표적인 방법은 다음과 같다.

사용자 가까운 region 선택
CDN edge 사용
Direct/private connectivity 사용
parallel transfer
multi-part upload
compression
protocol 최적화
HTTP/2 또는 HTTP/3 사용
connection reuse
regional cache
database read replica
message batching
asynchronous transfer

Large file upload에서는 multi-part upload가 유용할 수 있다.

Large file
  ↓ split into parts
part 1, part 2, part 3, ...
  ↓ parallel upload
  ↓
reassemble at destination

API traffic에서는 payload 크기와 latency를 줄이는 것이 중요하다.

large JSON response
  ↓
pagination
field selection
compression
caching

Replication traffic에서는 scheduling이 중요하다.

peak time replication
  ↓
user traffic과 경쟁

off-peak replication
  ↓
network contention 감소

Observability

Data transfer는 보이지 않으면 최적화할 수 없다.

관찰해야 할 지표는 다음과 같다.

지표	의미
Ingress bytes	들어온 데이터 양
Egress bytes	나간 데이터 양
Cross-zone traffic	zone 간 이동량
Cross-region traffic	region 간 이동량
Public egress	internet으로 나간 데이터 양
Private traffic	private network 내부 traffic
CDN cache hit ratio	origin transfer 감소 효과
Top talkers	가장 많은 traffic을 만든 source/destination
Top URLs	가장 많이 전송된 object/API
Throughput	실제 전송 속도
Latency	요청/응답 지연
Packet loss	재전송과 성능 저하 원인
NAT gateway bytes	NAT를 통과한 traffic
Load balancer processed bytes	LB를 통과한 traffic
Registry pull traffic	image pull로 발생한 traffic

Cloud bill을 최적화하려면 다음을 함께 봐야 한다.

billing metric
network metric
application metric
architecture diagram

단순히 “egress 비용이 높다”만 봐서는 부족하다. 어떤 service가, 어느 path로, 왜 그만큼 내보냈는지 파악해야 한다.

Troubleshooting 관점

Data transfer 문제는 다양한 증상으로 나타난다.

파일 전송이 느리다.
특정 region에서만 느리다.
cloud bill에서 egress 비용이 급증했다.
backup window 안에 복제가 끝나지 않는다.
Kubernetes 배포 때 image pull이 느리다.
database replication lag이 증가했다.
CDN cache hit ratio가 낮다.
NAT gateway가 병목이다.

파일 전송이 느린 경우

확인할 항목은 다음과 같다.

source와 destination의 region
bandwidth limit
throughput 측정
latency
packet loss
TCP window
parallel transfer 여부
storage service limit
client upload/download limit
VPN 또는 firewall throughput

Egress 비용이 급증한 경우

가능한 원인은 다음과 같다.

CDN cache miss 증가
large file download 증가
log export 증가
cross-region replication 증가
backup 정책 변경
public IP로 내부 통신
image pull 반복
crawler 또는 bot traffic

확인할 지표는 다음과 같다.

top egress service
top destination
top URL/object
CDN hit ratio
object storage download count
load balancer bytes
NAT gateway bytes
container registry traffic

Cross-zone traffic이 많은 경우

가능한 원인은 다음과 같다.

app과 database가 다른 zone에 있음
load balancer가 zone locality를 고려하지 않음
pod가 특정 zone에 몰림
read replica가 부족함
distributed system quorum traffic
service mesh routing 정책

개선 방향은 다음과 같다.

zone-local routing
topology spread constraints
read replica zone 분산
cache layer 추가
stateful service placement 재검토

Backup이나 replication이 느린 경우

가능한 원인은 다음과 같다.

bandwidth 부족
single-threaded transfer
compression 미사용
large number of small files
high latency path
destination storage write limit
encryption overhead
VPN throughput limit

개선 방향은 다음과 같다.

multi-part transfer
parallelism 증가
compression
batching
incremental backup
dedicated/private link
region proximity 조정
off-peak scheduling

Data Transfer 설계 질문

Cloud architecture를 설계할 때는 다음 질문을 해야 한다.

1. 가장 큰 데이터 흐름은 무엇인가?
2. data source와 destination은 어디인가?
3. ingress인가 egress인가?
4. public network인가 private network인가?
5. 같은 zone인가, 다른 zone인가, 다른 region인가?
6. user-facing traffic인가 internal traffic인가?
7. cache할 수 있는가?
8. 압축하거나 줄일 수 있는가?
9. latency-sensitive한가 throughput-sensitive한가?
10. 보안상 public internet을 지나도 되는가?
11. compliance상 다른 region으로 이동해도 되는가?
12. 비용 metric은 무엇인가?
13. monitoring과 alerting은 준비되어 있는가?

이 질문에 답하면 data transfer를 비용, 성능, 보안, 가용성 관점에서 동시에 설계할 수 있다.

앞선 네트워킹 개념들과의 연결

Load Balancer

Load balancer는 data path에 들어가며, backend로 traffic을 분산한다.

Client
  ↓
Load Balancer
  ↓
Backend

Load balancer를 통과하는 bytes, cross-zone balancing 여부, health check traffic까지 data transfer 관점에서 봐야 한다.

DNS

DNS는 data가 어느 endpoint로 향할지 결정하는 첫 단계다.

app.example.com
  ↓ DNS
regional endpoint 또는 CDN endpoint

DNS routing이 바뀌면 data transfer path도 바뀔 수 있다.

VPC

VPC는 data transfer의 network boundary다.

VPC
├── public subnet
├── private subnet
└── route table

Private IP로 통신하는지, public IP로 나갔다 들어오는지에 따라 비용과 보안이 달라질 수 있다.

Virtual Networking

Virtual networking은 data transfer가 실제 physical network 위에서 어떤 overlay/underlay path를 타는지와 연결된다.

Workload
  ↓
vNIC / vSwitch
  ↓
overlay or private backbone
  ↓
destination workload

NAT와 Firewall

NAT와 firewall은 data transfer path를 통제하고 변환한다.

Private subnet
  ↓
NAT / Firewall
  ↓
Internet

NAT gateway나 firewall throughput이 병목이 될 수 있다.

CDN

CDN은 user-facing data transfer를 edge에서 처리해 origin egress와 latency를 줄인다.

User
  ↓
CDN Edge
  ↓ cache miss only
Origin

MZR

MZR은 zone 간 data transfer와 high availability 설계와 연결된다.

Zone 1
  ↕
Zone 2
  ↕
Zone 3

Zone-aware placement를 하지 않으면 불필요한 cross-zone traffic이 증가할 수 있다.

자칫 실수하기 쉬운 부분

실수	문제
Data transfer를 단순 파일 복사로만 이해	web response, DB query, replication, image pull도 모두 transfer
ingress와 egress를 구분하지 않음	비용 추정이 크게 틀어질 수 있음
public path와 private path를 혼동	보안과 비용, latency가 예상과 달라질 수 있음
같은 cloud 내부면 모두 무료라고 가정	zone, region, public/private path에 따라 달라질 수 있음
app과 DB locality를 고려하지 않음	cross-zone/cross-region latency와 비용 증가
CDN cache hit ratio를 보지 않음	origin egress가 계속 증가할 수 있음
NAT gateway를 single-zone 병목으로 둠	egress 장애와 throughput bottleneck 가능
container image pull traffic을 무시	rolling update 때 registry와 network 부하 증가
observability 없이 비용만 봄	어떤 path가 비용을 만드는지 찾기 어려움

정리

Data transfer는 cloud resource, 사용자, region, zone, on-premises network 사이에서 데이터가 이동하는 모든 network communication을 의미한다.

항목	정리
Data transfer	실제 이동한 데이터 양
Bandwidth	전송 가능한 네트워크 용량
Throughput	실제 관측된 전송 속도
Latency	요청/응답 또는 왕복 지연
Ingress	cloud로 들어오는 traffic
Egress	cloud 밖으로 나가는 traffic
Public transfer	internet-facing path를 통한 전송
Private transfer	private IP, private backbone, dedicated link 기반 전송
Cross-zone transfer	같은 region의 zone 간 전송
Cross-region transfer	서로 다른 region 간 전송
주요 비용 축	public egress, cross-region, large object download, replication
주요 성능 축	bandwidth, latency, packet loss, jitter
주요 최적화	CDN, locality, compression, private path, caching, observability

Data transfer를 제대로 설계하려면 ingress/egress, public/private path, zone/region 경계, bandwidth, latency, 비용, 보안, observability를 함께 고려해야 한다. Cloud architecture에서 데이터가 어디서 어디로 얼마나 이동하는지 보이지 않으면, 비용 최적화와 성능 개선 모두 어렵다.