同じリージョンなのになぜ料金が出るのか
한국어 원문으로 표시합니다.
한 줄 요약
들어오는 트래픽은 대개 무료이고, 나가는 트래픽과 경계를 넘는 트래픽에 요금이 붙습니다. 이 비대칭을 모르면 청구서가 설명되지 않습니다.
왜 이게 필요했나
다중 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 도입.
- 로그를 다른 리전 수집기로 보냄 → 리전 간 요금. 같은 리전으로 옮김.
요금을 보이게 만든다
전송 요금이 무서운 이유는 액수가 아니라 어디서 나왔는지 보이지 않는다는 것이다. 컴퓨트는 인스턴스마다 이름이 붙어 있어 누가 쓰는지 알 수 있지만, 전송 요금은 "리전 간 전송" 같은 한 줄로 뭉뚱그려져 청구서에 나타난다. 그래서 줄이려면 먼저 보이게 만들어야 한다.
흐름 로그를 켠다. 어느 주소에서 어느 주소로 얼마나 갔는지 기록이 남으면, 요금이 큰 경로를 실제로 지목할 수 있다. 기록 자체에도 비용이 들지만 대개 절감액이 훨씬 크고, 문제를 찾은 뒤에는 표본 비율을 낮춰 두면 된다.
태그를 붙이고 그 단위로 본다. 팀이나 서비스 단위로 나눠 보면, 전체 청구서에서는 안 보이던 한 서비스의 이상한 통신 패턴이 드러난다.
요금이 아니라 전송량으로 관리한다. 단가는 바뀌고 할인도 붙지만, "이 경로로 월 몇 테라바이트가 흐르는가" 는 설계에서 나온 값이라 안정적이다. 설계를 논할 때는 이 숫자로 이야기하는 편이 낫다.
그리고 예상치 못한 급증을 잡을 장치가 필요하다. 요금 알림은 대개 너무 늦게 온다. 월 예산의 절반을 넘었다는 알림이 왔을 때는 이미 며칠치가 나간 뒤다. 전송량 자체를 지표로 두고 평소 대비 몇 배가 되면 알리게 하면 훨씬 빠르다. 특히 조심할 것은 되풀이 호출이 무한히 도는 사고다. 서비스 둘이 서로를 부르는 고리가 생기거나, 재시도가 재시도를 부르면 전송량이 몇 시간 만에 평소의 수십 배가 된다. 이런 사고는 기능적으로는 아무 증상이 없어서 청구서로만 발견되는 일이 잦다. 그래서 서비스 사이의 호출 관계를 그려 두고 고리가 생기지 않는지 확인하는 것이, 요금 관점에서도 신뢰성 관점에서도 같은 값을 한다.
다음에 볼 것
이제 실제로 낭비를 찾아내는 순서를 만듭니다.