네트워크 비용은 AWS 청구서에서 간과하기 쉬운 항목이지만, 트래픽이 많은 서비스에서는 상당한 금액이 됩니다. SAA-C03에서 데이터 전송 비용 최적화는 자주 출제되는 주제입니다. "어떤 구성이 네트워크 비용을 줄이는가"라는 질문에 답하려면 데이터가 어디에서 어디로 흐르는지를 이해해야 합니다.
데이터 전송 비용의 기본 규칙
왜 중요한가요? AWS는 데이터를 이동할 때 방향과 경로에 따라 요금을 다르게 부과합니다. 이 규칙을 모르면 예상보다 많은 청구서를 받을 수 있습니다.
규칙을 쉽게 기억하는 방법: "안으로 들어오는 건 무료, 같은 동네는 무료, 멀어질수록 비싸다."
| 방향 | 조건 | 비용 | |------|------|------| | 인바운드 | 인터넷 → AWS | 무료 | | 같은 AZ 내 | 프라이빗 IP 사용 | 무료 | | 같은 AZ 내 | 퍼블릭/탄력적 IP 사용 | 소액 과금 | | 같은 리전, 다른 AZ | 양방향 | GB당 소액 | | 다른 리전 | 양방향 | GB당 더 비쌈 | | AWS → 인터넷 | 아웃바운드 | 가장 비쌈 |
핵심 원칙: 같은 AZ 안에서 프라이빗 IP를 사용하면 전송 비용이 없습니다. 서버 간 통신 시 퍼블릭 IP 대신 프라이빗 IP를 쓰는 것만으로도 비용을 절감할 수 있습니다.
NAT 게이트웨이란 무엇이고 왜 비쌀 수 있나요?
왜 존재하나요? 프라이빗 서브넷의 서버는 인터넷에서 직접 접근할 수 없게 격리되어 있습니다. 하지만 이 서버들도 소프트웨어 업데이트나 외부 API 호출처럼 인터넷으로 나가야 하는 경우가 있습니다. NAT 게이트웨이는 이 나가는 트래픽을 대신 처리해 줍니다.
무엇인가요? 아파트 단지의 공동 우편함과 같습니다. 주민(프라이빗 서버)이 편지를 보낼 때 자기 주소 대신 우편함 주소로 내보내고, 답장은 우편함이 받아서 각 주민에게 전달합니다. 외부에서는 개별 주민의 주소를 알 수 없고, 우편함 주소만 보입니다.
왜 비용이 높아질 수 있나요? NAT 게이트웨이는 두 가지 요금이 동시에 발생합니다. 시간당 사용 요금 (켜져 있는 것만으로도 과금) 데이터 처리 요금 (GB당 과금)
트래픽이 많거나 여러 AZ의 서버가 다른 AZ의 NAT 게이트웨이를 통해 나가면 AZ 간 전송 비용까지 추가됩니다.
NAT 게이트웨이 비용 줄이는 방법
방법 1 — VPC 엔드포인트로 S3·DynamoDB 트래픽 우회:
S3나 DynamoDB는 NAT 게이트웨이를 거치지 않고도 접근할 수 있는 게이트웨이 엔드포인트를 무료로 제공합니다. 모든 S3 트래픽이 NAT 게이트웨이를 통과하면 데이터 처리 비용이 계속 쌓입니다. S3 게이트웨이 엔드포인트를 설정하면 S3 트래픽이 NAT 게이트웨이를 우회하므로 그 비용이 사라집니다.
방법 2 — 각 AZ에 NAT 게이트웨이 배치:
AZ-A의 서버가 AZ-B에 있는 NAT 게이트웨이를 쓰면 AZ 간 전송 비용이 발생합니다. 각 AZ에 NAT 게이트웨이를 하나씩 두고, 해당 AZ의 서버가 같은 AZ의 NAT 게이트웨이를 쓰도록 설정하면 AZ 간 전송 비용이 없어집니다. 단, NAT 게이트웨이 시간당 요금은 AZ 수만큼 늘어납니다.
방법 3 — NAT 인스턴스 (소규모 환경):
트래픽이 매우 적은 환경에서는 관리형 NAT 게이트웨이 대신 EC2 인스턴스를 NAT 인스턴스로 직접 구성할 수 있습니다. 비용은 더 저렴하지만, 가용성 관리·패치·스케일링을 직접 해야 합니다.
VPC 엔드포인트로 비용 절감
왜 존재하나요? VPC 안의 서버가 S3, DynamoDB 같은 AWS 서비스에 접근할 때 인터넷을 거치면 아웃바운드 비용이 발생합니다. VPC 엔드포인트는 AWS 내부 네트워크를 통해 직접 연결하는 사설 전화선과 같습니다. 공중전화(인터넷)를 쓰지 않고 사내 직통 전화를 쓰는 것과 같습니다.
| 유형 | 대상 서비스 | 비용 | |------|-----------|------| | 게이트웨이 엔드포인트 | S3, DynamoDB | 무료 | | 인터페이스 엔드포인트 (AWS PrivateLink) | 기타 AWS 서비스 (SNS, SQS, API Gateway 등) | 시간당 + 데이터 처리 요금 |
S3 게이트웨이 엔드포인트는 무료입니다. S3를 많이 사용하는 환경이라면 반드시 설정해야 합니다. 시험에서 "S3 접근 시 NAT 비용을 줄이는 방법"의 정답은 대부분 이것입니다.
CloudFront로 아웃바운드 비용 절감
왜 존재하나요? S3에서 파일을 직접 전달하면 인터넷 아웃바운드 요금이 계속 발생합니다. CloudFront는 전 세계 엣지 로케이션에 콘텐츠를 캐시하여, 사용자가 오리진(S3)이 아닌 가장 가까운 엣지에서 파일을 받도록 합니다.
왜 저렴한가요? S3 → CloudFront 전송: S3에서 CloudFront로의 오리진 전송은 할인된 요금 적용 (때로는 무료 수준) CloudFront → 사용자: 일반 S3 아웃바운드보다 낮은 요금 캐시 히트율이 높을수록 오리진 요청이 줄어 S3 요청 비용도 절감
예시: 전 세계 사용자에게 동일한 이미지를 제공하는 서비스. S3에서 직접 전달하면 모든 요청이 S3 아웃바운드 요금. CloudFront를 쓰면 첫 번째 요청만 S3를 조회하고, 이후에는 엣지 캐시에서 무료로 서비스.
VPC 피어링 vs Transit Gateway
왜 비교하나요? 여러 VPC를 연결할 때 어떤 방식을 쓰느냐에 따라 비용 구조가 달라집니다.
VPC 피어링은 1:1 연결입니다. 두 VPC를 직접 연결하는 전용 통로를 만드는 것과 같습니다. 연결 시간당 요금이 없고, 데이터 전송 비용만 발생합니다. 하지만 VPC 수가 늘어날수록 피어링 수가 기하급수적으로 늘어납니다 (N개 VPC → N×(N-1)/2개 피어링).
Transit Gateway는 중앙 허브입니다. 모든 VPC가 허브 하나에 연결되면 됩니다 (N개 VPC → N개 연결). 연결 시간당 요금과 데이터 처리 요금이 발생하므로, VPC가 적으면 피어링이 더 저렴합니다. VPC가 많아지면 Transit Gateway가 더 경제적이고 관리가 쉬워집니다.
| 항목 | VPC 피어링 | Transit Gateway | |------|----------|----------------| | 비용 구조 | 데이터 전송만 | 연결 시간당 + 데이터 처리 | | 연결 수 | N×(N-1)/2 | N개 | | 확장성 | 낮음 | 높음 | | 추천 상황 | VPC가 2~3개 | VPC가 4개 이상 |
시험 핵심 정리
"S3 접근 시 NAT 게이트웨이 비용 제거" -- S3 Gateway 엔드포인트 (무료)
"공중전화 대신 사내 직통 전화" -- VPC 게이트웨이 엔드포인트의 비유
"NAT 게이트웨이 AZ 간 비용 방지" -- 각 AZ에 별도 NAT 게이트웨이 배치
"인터넷 아웃바운드 비용 절감" -- CloudFront 경유 콘텐츠 전송
"같은 AZ 전송 무료" -- 프라이빗 IP 사용 필수
"소수 VPC 간 연결, 데이터 비용만" -- VPC 피어링
"많은 VPC 중앙 관리, 시간당 요금 발생" -- Transit Gateway
"인바운드 데이터" -- 항상 무료
S3 Gateway 엔드포인트는 무료 — 비용 절감 문제에서 가장 자주 나오는 정답
CloudFront를 쓰면 S3 아웃바운드보다 저렴하고, 캐시 히트율이 높을수록 추가 절감