아키텍처 케이스 · 6
데이터 전송 요금이 예산을 넘겼다
컴퓨팅과 스토리지는 예상 범위 안인데 청구서가 계속 늘어난다면 원인은 대개 데이터가 지나간 경로입니다. 데이터 전송은 양이 아니라 방향으로 요금이 정해지고, 같은 데이터라도 어느 경계를 넘느냐에 따라 요금 항목이 달라집니다. 이 케이스는 금액 없이 구조만으로 원인을 찾고 경로를 바꿉니다.
학습 목표
- 데이터 전송 요금이 방향에 따라 비대칭이라는 점을 설명하고 방향별로 분류할 수 있습니다.
- NAT 게이트웨이를 지나는 트래픽을 VPC 엔드포인트로 걷어내는 판단을 할 수 있습니다.
- 가용 영역 간 트래픽이 생기는 배치를 찾아내고 줄이는 방법을 설명할 수 있습니다.
- 인터넷 송신량 자체를 줄이는 수단으로 Amazon CloudFront를 선택하는 근거를 댈 수 있습니다.
- 시험 문항에서 비용 한정어가 붙었을 때 경로를 먼저 확인하는 순서를 적용할 수 있습니다.
상황
로그 수집·분석 서비스가 다음 구조로 동작합니다.
- 프라이빗 서브넷의 수집 인스턴스들이 Amazon S3에 로그를 올립니다. VPC 엔드포인트가 없어서 이 트래픽은 NAT 게이트웨이를 지나 인터넷 경로로 나갑니다.
- NAT 게이트웨이는 가용 영역 한 곳에만 있고, 다른 가용 영역의 인스턴스들도 이 NAT를 씁니다.
- 분석 클러스터는 다른 리전에 있고, 원본 로그를 매일 리전 간 복사해 옵니다.
- 대시보드가 원본 이미지와 대용량 리포트를 S3에서 직접 인터넷으로 내려보냅니다. 같은 파일이 여러 번 요청됩니다.
비용을 항목별로 나눠 보니 컴퓨팅과 스토리지는 예측 범위 안이고, 네트워크 관련 항목이 예산의 상당 부분을 차지하고 있었습니다. 팀은 "데이터를 줄일 수는 없다"고 판단하고 있지만, 실제로 줄여야 하는 것은 데이터가 아니라 데이터가 지나는 경계의 수입니다.
데이터 전송은 방향으로 결정된다
원인을 찾기 전에 지도를 먼저 봅니다. 아래 표의 방향 중 어디에 트래픽이 몰려 있는지가 곧 진단입니다.
| 방향 | 과금 | 설계에 주는 함의 |
|---|---|---|
| 인터넷에서 AWS로 (수신) | 대체로 무료 | 데이터를 올리는 것은 비용 요인이 아니다. 마이그레이션 방향이 유리한 이유다 |
| 같은 가용 영역 안, 프라이빗 IP | 가장 저렴한 경로 | 트래픽이 큰 계층 사이는 가급적 같은 가용 영역 안에서 프라이빗 IP로 통신하게 배치한다 |
| 같은 리전, 가용 영역 간 | 과금 | 다중 가용 영역은 가용성을 사지만 전송 요금을 함께 부른다. 넘지 않아도 되는 트래픽을 줄인다 |
| 리전 간 | 과금 | 교차 리전 복제와 리전 간 백업은 항상 비용을 동반한다. 옮길 데이터의 범위를 좁힌다 |
| AWS에서 인터넷으로 (송신) | 가장 큰 항목이 되기 쉽다 | 송신량 자체를 줄이는 수단(캐시·압축·해상도 조정)을 먼저 검토한다 |
| 프라이빗 서브넷에서 NAT 게이트웨이 경유 | 지나는 데이터양이 비용 요인 | AWS 서비스로 가는 트래픽은 VPC 엔드포인트로 걷어낼 수 있다 |
어디로 얼마나 흐르는지 찾기
추측하지 않고 실제 흐름을 확인합니다. VPC 흐름 로그는 네트워크 인터페이스 단위로 5-튜플과 바이트 수를 기록하므로, 어느 인터페이스가 얼마나 보내는지를 집계할 수 있습니다.
aws ec2 create-flow-logs \
--resource-type VPC \
--resource-ids vpc-0123456789abcdef0 \
--traffic-type ALL \
--log-destination-type cloud-watch-logs \
--log-group-name /aws/vpc/flowlogs \
--deliver-logs-permission-arn arn:aws:iam::123456789012:role/FlowLogsRole
# NAT 게이트웨이가 실제로 얼마나 처리하고 있는지 확인합니다.
aws ec2 describe-nat-gateways \
--query 'NatGateways[].[NatGatewayId,SubnetId,State]' \
--output table
요구사항과 제약
| 구분 | 내용 | 설계에 주는 함의 |
|---|---|---|
| 요구 1 | 네트워크 관련 비용을 구조적으로 낮춘다 | 트래픽을 줄이는 것이 아니라 경계를 덜 넘게 만든다 |
| 요구 2 | 수집·분석 기능은 그대로 유지한다 | 데이터를 버리는 방식은 답이 아니다 |
| 요구 3 | 가용성은 낮아지지 않아야 한다 | NAT를 하나로 줄이는 식의 절감은 금지된다 |
| 제약 1 | 로그 원본은 수집 리전에 보관한다 | 리전 간 복사는 필요한 부분만 남긴다 |
| 제약 2 | 대시보드의 응답 지연이 나빠지면 안 된다 | 캐시는 지연을 줄이는 방향이므로 충돌하지 않는다 |
배경 개념은 18장 비용 최적화 · 마이그레이션 · 재해 복구와 4장 VPC 연결과 하이브리드에 있습니다.
후보 설계안 비교
원인이 네 갈래이므로 후보도 갈래별로 놓고 봅니다. 하나를 고르는 문제가 아니라 어떤 조합이 요구 3(가용성)을 깨지 않는가의 문제입니다.
| 항목 | A · NAT를 하나로 통합 | B · S3·DynamoDB용 게이트웨이 엔드포인트 | C · 리전 간 복사 범위 축소 | D · CloudFront로 인터넷 송신 흡수 |
|---|---|---|---|---|
| 줄이는 경로 | NAT 시간 항목만 | NAT를 지나는 데이터양 | 리전 간 전송량 | 오리진의 인터넷 송신량 |
| 가용성 영향 | 나빠진다 — 가용 영역 장애 시 전면 중단 | 영향 없음 | 영향 없음 | 오리진 부하가 줄어 오히려 개선 |
| 가용 영역 간 전송 | 늘어난다 | 줄어든다 | 영향 없음 | 영향 없음 |
| 응답 지연 | 영향 없음 | 영향 없음 또는 개선 | 영향 없음 | 개선 |
| 적용 난이도 | 낮음 | 낮음 — 라우팅 테이블에 경로가 추가된다 | 중간 — 무엇을 옮길지 정해야 한다 | 중간 — 배포와 캐시 정책 설계 |
| 판정 | 오답 — 요구 3 위반 | 채택 | 채택 | 채택 |
선택과 근거
B + C + D를 각각의 경로에 적용하고, NAT는 가용 영역마다 유지합니다.
1 · S3 트래픽을 NAT에서 걷어낸다
프라이빗 서브넷에서 Amazon S3로 가는 트래픽이 NAT 게이트웨이를 지나고 있다면 가장 먼저 고칠 곳입니다. 게이트웨이 엔드포인트를 만들면 라우팅 테이블에 S3 접두사 목록으로 향하는 경로가 추가되고, 그 트래픽은 NAT를 지나지 않습니다.
aws ec2 create-vpc-endpoint \
--vpc-id vpc-0123456789abcdef0 \
--vpc-endpoint-type Gateway \
--service-name com.amazonaws.ap-northeast-2.s3 \
--route-table-ids rtb-0aaa000000000000a rtb-0bbb000000000000b
# 사용 가능한 엔드포인트 서비스와 유형을 확인합니다.
aws ec2 describe-vpc-endpoint-services \
--query 'ServiceDetails[?contains(ServiceName, `s3`)].[ServiceName,ServiceType[0].ServiceType]' \
--output table
| 항목 | 게이트웨이 엔드포인트 | 인터페이스 엔드포인트(PrivateLink) |
|---|---|---|
| 구현 위치 | 라우팅 테이블의 경로 | 서브넷 안의 네트워크 인터페이스 |
| 대상 서비스 | Amazon S3, Amazon DynamoDB | 대부분의 AWS 서비스와 PrivateLink 서비스 |
| DNS | 공용 DNS 이름을 그대로 쓰고 경로만 바뀐다 | 프라이빗 DNS로 이름을 가로챌 수 있다 |
| 온프레미스에서 사용 | 직접 사용 불가 | 가능 — 인터페이스가 VPC 안에 있으므로 |
| 요금 성격 | 경로 추가로 동작한다 | 인터페이스와 처리량이 요금 항목이 된다 |
S3와 DynamoDB만 쓰는 경우에는 게이트웨이 엔드포인트가 자연스러운 선택입니다. 다른 AWS 서비스(예: Systems Manager, Secrets Manager)로 가는 트래픽까지 NAT에서 걷어내려면 인터페이스 엔드포인트가 필요하며, 그때는 엔드포인트 자체의 요금 항목과 NAT를 지나던 데이터양을 비교해 판단합니다.
2 · 가용 영역을 넘는 트래픽 줄이기
NAT는 가용 영역마다 유지하되, 각 가용 영역의 프라이빗 라우팅 테이블이 자기 가용 영역의 NAT를 가리키게 합니다. 이렇게 하면 가용성이 올라가는 동시에 가용 영역을 넘던 트래픽이 사라집니다. 가용성과 비용이 같은 방향으로 개선되는 드문 경우입니다.
| 배치 | 무슨 일이 일어나는가 | 처방 |
|---|---|---|
| NAT 하나 · 프라이빗 서브넷 여럿 | 다른 가용 영역의 트래픽이 전부 경계를 넘는다 | 가용 영역마다 NAT, 라우팅 테이블도 가용 영역별로 |
| 캐시·데이터베이스가 한 가용 영역에만 | 애플리케이션의 모든 조회가 경계를 넘는다 | 읽기 경로를 같은 가용 영역에 두거나 계층을 함께 다중화 |
| 가용 영역별 대상 수 불균형 | 로드 밸런서가 경계를 넘어 분배한다 | 가용 영역별 용량을 맞추고 교차 영역 설정을 의도적으로 정한다 |
| 퍼블릭 IP로 서로 호출 | 같은 리전 안인데도 경로가 길어진다 | 프라이빗 IP나 내부 이름으로 호출하게 바꾼다 |
3 · 리전 간 복사 범위 좁히기
원본 로그 전체를 매일 다른 리전으로 복사하고 있다면, 무엇을 위해 옮기는지를 되물어야 합니다. 분석에 필요한 것이 집계 결과라면, 집계를 원본이 있는 리전에서 수행하고 결과만 옮기는 편이 구조적으로 옳습니다.
- 옮기기 전에 압축하고, 열 지향 형식으로 변환합니다.
- 복제가 필요하다면 전체가 아니라 접두사나 태그로 대상을 한정합니다.
- 복제 원본이 다른 리전에 있으면 그 전송이 원본 계정에 청구됩니다. 계정을 나눠 쓰는 조직에서는 누가 부담하는지를 미리 정합니다.
4 · 인터넷 송신을 CloudFront로 흡수
같은 파일이 여러 번 요청되는데 매번 오리진에서 내보내고 있다면 캐시가 그대로 절감입니다. Amazon CloudFront는 엣지 로케이션에서 콘텐츠를 캐시하고, 캐시 미스가 나면 리전 엣지 캐시를 한 번 더 거칠 수 있어 오리진에 도달하는 요청 자체가 줄어듭니다.
절감의 크기는 캐시 적중률이 결정하고, 적중률은 캐시 키 설계가 결정합니다. 불필요한 쿼리 문자열이나 헤더를 캐시 키에 포함시키면 같은 콘텐츠가 여러 항목으로 나뉘어 적중률이 떨어집니다.
비용과 운영에 미치는 영향
| 처방 | 줄어드는 항목 | 새로 생기는 항목 | 언제 유리한가 |
|---|---|---|---|
| S3 게이트웨이 엔드포인트 | NAT를 지나는 데이터양 | 없음(라우팅 경로가 추가될 뿐) | S3 트래픽이 조금이라도 있으면 거의 항상 |
| 인터페이스 엔드포인트 | NAT를 지나는 데이터양 | 엔드포인트와 처리량 항목 | 해당 서비스 트래픽이 충분히 클 때 |
| 가용 영역별 NAT | 가용 영역 간 전송 | NAT 개수만큼의 시간 항목 | 다중 가용 영역이면 사실상 필수 |
| 리전 간 복사 축소 | 리전 간 전송 | 원본 리전의 처리 자원 | 분석 결과만 필요할 때 |
| CloudFront | 오리진의 인터넷 송신 | CloudFront 요청·전송 항목 | 같은 콘텐츠가 반복 요청될 때 |
운영 측면에서는 가시성이 남는 과제입니다. 비용이 다시 늘어날 때 어디에서 늘어나는지 즉시 알 수 있어야 하므로, 태그로 워크로드를 구분하고 예산 알림을 걸어 둡니다. 구조를 고쳐도 감시가 없으면 다음 분기에 같은 일이 반복됩니다.
설계 체크리스트
경로 점검
가시성
관련 시험 포인트
| 문제문의 신호 | 고르는 것 | 소거하는 것 |
|---|---|---|
| 프라이빗 서브넷의 S3 접근 비용이 크다 | S3 게이트웨이 엔드포인트 | NAT 인스턴스로 교체하는 안 |
| 인터넷으로 같은 콘텐츠가 반복 전송된다 | Amazon CloudFront | 오리진 인스턴스를 키우는 안 |
| 인터넷을 경유하면 안 된다 | VPC 엔드포인트 · PrivateLink · Direct Connect | NAT 게이트웨이 경유 |
| 온프레미스에서 S3에 프라이빗 경로로 접근 | Direct Connect + 인터페이스 엔드포인트 | 게이트웨이 엔드포인트(온프레미스에서 직접 쓸 수 없다) |
| 비용을 줄이되 가용성은 유지 | 가용 영역별 NAT 유지 + 엔드포인트 도입 | NAT를 하나로 통합하는 안 |
| 버킷 소유자가 내려받기 요금을 부담하기 어렵다 | 요청자 지불 설정 | 버킷을 퍼블릭으로 여는 안 |
이어서 볼 곳
- 18장 · 비용 최적화 · 마이그레이션 · 재해 복구 비용 도구와 절감 레버 전체 지도, 데이터 전송 요금 구조를 정면으로 다룹니다.
- 4장 · VPC 연결과 하이브리드 게이트웨이 엔드포인트와 인터페이스 엔드포인트의 구현 위치 차이를 다룹니다.
- 실습 10 · VPC 엔드포인트로 S3 비공개 접근 라우팅 테이블이 어떻게 바뀌는지, 경로가 실제로 옮겨졌는지 확인합니다.
- 케이스 3 · S3 비용이 매달 늘어난다 이동이 아니라 저장에서 새는 비용. 같은 청구서의 다른 항목입니다.
- 케이스 4 · 퍼블릭 서브넷에 데이터베이스를 뒀다 같은 엔드포인트 판단이 보안 관점에서는 어떻게 쓰이는지 비교합니다.
- 비용 최적화 아키텍처 설계 (20%) 과제 진술 4개와 비용 한정어가 가리키는 선택지를 정리했습니다.
공식 문서 출처
- Amazon VPC 사용 설명서 — NAT 게이트웨이 — 지정한 서브넷에 인터페이스를 만든다는 동작과 퍼블릭·프라이빗 NAT의 구분
- Amazon EC2 API 레퍼런스 — CreateVpcEndpoint
— 엔드포인트 유형(
Gateway·Interface)과 라우팅 테이블 연결 - Amazon VPC 사용 설명서 — VPC 흐름 로그 — 기록되는 필드와 바이트 수, 페이로드가 포함되지 않는다는 범위
- Amazon S3 API 레퍼런스 — CopyObject — 복사 원본이 다른 리전이면 데이터 전송이 원본 계정에 청구된다는 서술
- Amazon S3 사용 설명서 — 요청자 지불 버킷 — 기본적으로 버킷 소유자가 내려받기 요금을 부담한다는 서술
- Amazon CloudFront 개발자 안내서 — CloudFront란 — 엣지 로케이션에서 콘텐츠를 캐시해 오리진 요청을 줄인다는 동작
- Amazon CloudFront 개발자 안내서 — Origin Shield — 엣지 로케이션과 리전 엣지 캐시가 별도의 계층으로 존재한다는 서술
- Amazon EC2 API 레퍼런스 — CreateFlowLogs — 흐름 로그 대상 유형과 전달 권한 설정