비용과 아키텍처 결정 · 데이터 전송 비용 · 이론
같은 리전인데 왜 요금이 나오나
한 줄 요약
들어오는 트래픽은 대개 무료이고, 나가는 트래픽과 경계를 넘는 트래픽에
요금이 붙습니다. 이 비대칭을 모르면 청구서가 설명되지 않습니다.
왜 이게 필요했나
다중 AZ와 CDN은 가용성과 성능을 높이지만 데이터가 경계를 넘는 횟수도 바꿉니다.
컴퓨트 가격만 비교하면 앱과 DB 사이의 반복 통신이나 원본 이그레스가 만든 비용을
놓치므로, 아키텍처의 모든 주요 트래픽 경로를 월간 전송량으로 환산해야 합니다.
어떻게 동작하나
방향과 경계
| 경로 | 요금 |
| --- | --- |
| 인터넷 → 클라우드 (인그레스) | 대개 무료 |
| 클라우드 → 인터넷 (이그레스) | 비쌈 |
| 같은 AZ 안 | 대개 무료 |
| AZ 간 | 양방향 과금 |
| 리전 간 | 과금 |
| VPC 피어링 (같은 리전) | AZ 간 요금과 유사 |
가장 자주 놓치는 것이 AZ 간 요금입니다. 가용성을 위해 다중 AZ 로 짰는데,
앱 서버(AZ-a)와 DB(AZ-b)가 계속 통신하면 그 트래픽 전부가 과금됩니다.
쿼리 하나하나는 작지만 초당 수천 건이면 월 단위로 쌓입니다.
이걸 줄이는 설계
1. AZ 를 의식해 배치한다
같은 AZ 안에서 처리되도록 유도합니다. 쿠버네티스라면 토폴로지 인식 라우팅
(같은 존의 엔드포인트를 우선하는 설정)으로 상당 부분 해결됩니다.
단, 가용성과 맞바꾸는 것이므로 한 존이 죽었을 때의 동작을 확인해야 합니다.
2. 엔드포인트를 쓴다
앞 코스에서 다룬 그것입니다. S3 게이트웨이 엔드포인트는 요금이 없고
NAT 를 우회합니다.
3. CDN 을 앞에 둔다
이그레스가 큰 서비스(이미지·동영상·다운로드)는 CDN 의 캐시 적중이 곧
비용 절감입니다. CDN 의 이그레스 단가가 원본보다 싸고, 애초에 원본까지
안 갑니다.
4. 압축한다
API 응답을 gzip 으로 보내면 전송량이 크게 줍니다. 다만 **스트리밍 응답은
압축하지 않습니다** — 청크가 버퍼에 고여 스트리밍이 스트리밍이 아니게 됩니다.
5. 챙길 것을 챙긴다
로그·메트릭을 다른 리전으로 보내고 있지 않은지, 백업 복제가 필요 이상으로
자주 도는지 확인합니다.
흔한 착각
- "내부 통신은 공짜" — 같은 AZ 안에서만 그렇습니다.
- "압축하면 항상 이득" — CPU 를 씁니다. 이미 압축된 형식(이미지·동영상)은
- "CDN 은 비싸다" — 이그레스가 크면 대개 CDN 이 더 쌉니다. 계산해 보세요.
효과가 없고 낭비입니다.
계산해 보는 습관
숫자를 넣어 보면 감이 잡힙니다.
API 응답 평균 20KB, 초당 500 요청, 한 달 30일= 20KB × 500 × 86,400 × 30= 25,920 GB ≈ 26TB/월이그레스 단가를 GB 당 100원으로 가정하면 약 260만 원/월gzip 으로 5KB 까지 줄이면 약 65만 원/월 — 월 195만 원 절감이런 계산을 설계 회의에서 할 수 있으면 논쟁이 짧아집니다.
"압축하는 게 좋을 것 같다" 가 아니라 "월 195만 원" 이 되기 때문입니다.
현장에서 만나는 모습
- 다중 AZ 구성 후 요금 증가 → AZ 간 트래픽. 배치 전략을 조정.
- 이미지 서비스의 요금 대부분이 이그레스 → CDN 도입.
- 로그를 다른 리전 수집기로 보냄 → 리전 간 요금. 같은 리전으로 옮김.
다음에 볼 것
이제 실제로 낭비를 찾아내는 순서를 만듭니다.