AWS와 GCP 비용 비교 스타트업 서버 구축에서 더 유리한 선택

서버를 처음 구축하는 스타트업에게 클라우드 선택은 기술 스택만큼이나 현금흐름 문제입니다. “월 30만 원이면 되겠지”로 시작했다가, 트래픽이 조금만 늘어도 네트워크 요금과 관리형 서비스 비용이 겹치며 예상보다 빠르게 지출이 커집니다. 특히 AWS와 GCP는 서비스 구성이 비슷해 보여도 과금 단위, 무료 티어, 할인 방식, 네트워크 정책이 달라 실제 청구액이 꽤 다르게 나옵니다.

이 글에서는 “스타트업이 흔히 만드는 1차 버전(웹/API + DB + 캐시 + 오브젝트 스토리지 + 로그/모니터링)”을 기준으로, AWS와 GCP의 비용을 비교하고 어떤 상황에서 어느 쪽이 유리한지를 실전 관점에서 정리합니다.

참고: 아키텍처 자체가 비용을 좌우합니다. 팀 규모와 제품 단계에 따라 모놀리식이 더 경제적인 경우도 많습니다. 관련 글: 마이크로서비스와 모놀리식 아키텍처 비교 스타트업에 맞는 선택 가이드

비교 전에 꼭 알아야 할 비용의 큰 축

클라우드 비용은 보통 아래 5가지로 나뉩니다.

컴퓨트(서버): VM(EC2/Compute Engine), 컨테이너(ECS/EKS/GKE), 서버리스(Lambda/Cloud Functions)
스토리지: 오브젝트(S3/GCS), 블록(EBS/Persistent Disk), 백업/스냅샷
데이터베이스: 관리형 RDB(RDS/Cloud SQL), NoSQL(DynamoDB/Firestore)
네트워크: 인터넷 egress(외부로 나가는 트래픽), 리전 간 전송, 로드밸런서
운영/관측: 로그/메트릭(CloudWatch/Cloud Logging), 알림, APM

스타트업 초기에 가장 자주 “예상 밖으로” 튀는 항목은 네트워크 egress와 로그 저장/조회 비용입니다. 컴퓨트는 대체로 눈에 보이지만, 네트워크와 로그는 “사용량 기반”이라 성장 시점에 급격히 증가합니다.

컴퓨트 비용 AWS vs GCP

1) 온디맨드 VM 가격 감각

AWS: 인스턴스 종류가 매우 다양하고(범용/컴퓨트/메모리/버스트), 리전별 편차도 큽니다. 선택지가 많아 최적화 여지가 큰 대신 초기에 복잡합니다.
GCP: 머신 타입이 비교적 단순하고, 지속 사용 할인(Sustained Use Discount) 같은 자동 할인 개념이 있어 “계속 켜두는 VM”에서 체감이 좋을 때가 있습니다.

실무에서의 결론은 단순합니다.

VM 1~3대 수준에서 “대충 맞춰 쓰는” 단계라면 두 플랫폼의 온디맨드 가격 차이만으로 승부가 나기 어렵고,
**할인 전략(예약/커밋, 스팟/프리엠티블, 오토스케일링)**을 얼마나 빨리 도입하느냐가 더 큽니다.

2) 할인 모델 차이: 예약 vs 커밋

AWS Reserved Instances / Savings Plans: 특정 기간(1년/3년) 커밋으로 할인. 워크로드가 안정적이면 강력합니다.
GCP Committed Use Discounts(CUD): vCPU/메모리 기준으로 커밋하는 방식이 유연한 편이고, GKE/Compute에 적용하기 좋습니다.

스타트업 추천

PMF 이전: 예약보다 스팟/프리엠티블 + 오토스케일이 리스크 대비 효율적
PMF 이후(트래픽 안정): AWS는 Savings Plans, GCP는 CUD로 고정비 절감

3) 컨테이너 운영비: EKS vs GKE

EKS: 컨트롤 플레인 비용(클러스터당 과금) + 워커 노드 비용. 생태계가 넓지만 구성 복잡도가 있습니다.
GKE: 관리형 경험이 좋고, 오토스케일링/노드풀 운영이 편한 편입니다(조직 경험에 따라 체감 차이 큼).

초기 스타트업은 “쿠버네티스 자체가 비용”이 될 수 있습니다. 인프라 인건비까지 포함하면, 단일 VM + Docker Compose가 더 싸게 먹히는 구간이 꽤 길어요.

네트워크 비용이 승부를 가르는 순간

1) 인터넷 egress(가장 큰 함정)

대부분의 서비스는 **나가는 트래픽(이미지/동영상/파일 다운로드, API 응답)**이 늘면서 비용이 폭증합니다.

AWS: S3/EC2에서 인터넷으로 나가는 트래픽에 과금
GCP: GCS/Compute에서 인터넷으로 나가는 트래픽에 과금

중요한 건 “어느 쪽이 더 싸냐”보다도:

CDN(CloudFront/Cloud CDN) 도입 시점
캐시 정책
리전/멀티리전 구성
같은 리전 내 통신 비용

이 네 가지가 실제 청구액을 크게 바꿉니다.

2) 로드밸런서 과금 구조

로드밸런서는 초기에 소액처럼 보이지만, L7(HTTP) 기능을 쓰면 과금 요소가 늘어납니다.

AWS ALB/NLB: 시간당 + 처리량(LCU 등) 기반 요소
GCP Load Balancing: 제품군이 다양하고(글로벌/리전), 기능에 따라 과금 모델이 달라집니다.

트러블슈팅 포인트

“TLS 종료를 어디서 하느냐(ALB/Ingress/앱)”에 따라 비용과 운영 난이도가 달라집니다.
헬스체크/로그까지 켜면 비용이 미세하게 누적됩니다.

데이터베이스 비용 비교: RDS vs Cloud SQL

1) 관리형 RDB는 편하지만 비싸다

AWS RDS: 옵션이 많고 생태계가 성숙. Multi-AZ, Read Replica 등 구성에 따라 비용이 크게 변함.
GCP Cloud SQL: 운영 경험이 단순한 편이지만, 고가용성(HA) 구성 시 비용이 빠르게 증가.

스타트업 현실적인 패턴

초기에 트래픽이 크지 않다면 “HA(이중화)”를 무조건 켜기보다,
- 백업/스냅샷,
- 장애 대응 런북,
- 복구 시간 목표(RTO/RPO) 를 먼저 정하고 비용 대비 리스크를 평가하는 게 좋습니다.

2) 스토리지 IOPS/성능 옵션이 비용을 흔든다

RDB는 CPU/RAM보다 스토리지 타입과 IOPS가 비용을 흔드는 경우가 많습니다.

“느려서 인스턴스 업그레이드”보다
쿼리/인덱스 튜닝, 커넥션 풀, 캐시(Redis)로 해결하면 훨씬 저렴합니다.

오브젝트 스토리지와 CDN: S3 vs GCS

1) 저장 비용보다 중요한 건 요청/전송

오브젝트 스토리지는 GB당 저장 비용보다도

요청 수(GET/PUT)
인터넷 전송(egress)
수명주기 정책(IA/Archive) 이 전체 비용을 좌우합니다.

Best Practice

이미지 썸네일/리사이징을 매 요청마다 하지 말고 결과를 저장
정적 파일은 CDN 캐시 TTL을 길게
로그/원본 파일은 Lifecycle로 저비용 스토리지로 자동 이동

2) 스타트업에서 자주 터지는 케이스

사용자 업로드가 늘었는데, CDN 없이 원본을 직접 내려줌 → egress 폭증
백엔드가 S3/GCS에 자잘한 PUT을 과도하게 발생 → 요청 비용 증가

로그/모니터링 비용: CloudWatch vs Cloud Logging

관측 비용은 “처음엔 공짜 같다가” 서비스가 커질수록 무섭게 오릅니다.

AWS CloudWatch: 로그 수집/보관/조회, 커스텀 메트릭, 알람 등에서 비용이 누적
GCP Cloud Logging/Monitoring: 수집량과 보관, 쿼리/내보내기 정책에 따라 비용이 달라짐

비용 폭탄을 막는 실전 팁

로그 레벨 정책: 개발/스테이징/프로덕션 분리
PII 마스킹: 개인정보가 로그에 들어가면 비용+보안 리스크 동시 증가
샘플링: 고QPS 엔드포인트는 100% 로그가 필요 없는 경우가 많음
보관 기간 최소화: 7일/14일/30일 등 단계적으로
구조화 로그(JSON): 쿼리 효율이 좋아져 운영 시간이 줄어듦

“스타트업 기준”으로 누가 더 유리한가

정답은 “상황에 따라 다름”이지만, 비용만 놓고도 패턴이 있습니다.

AWS가 유리해지기 쉬운 경우

이미 팀에 AWS 경험자가 있고 운영 리스크를 줄이는 게 최우선
서비스/서드파티/매니지드 옵션 선택지가 중요(예: 다양한 DB 엔진, 서드파티 마켓플레이스)
특정 AWS 서비스(예: DynamoDB, SQS, CloudFront)에 강하게 의존하는 아키텍처

GCP가 유리해지기 쉬운 경우

Kubernetes/GKE 중심으로 빠르게 가고 싶고, 운영 단순성이 중요
BigQuery, 데이터 분석/ML 파이프라인을 빠르게 붙일 계획
지속적으로 켜두는 워크로드에서 자동 할인/커밋 모델이 잘 맞는 구성

비용 관점에서의 결론(현실 버전)

초기(트래픽 작음): 플랫폼 차이보다 “구성 선택(HA, LB, 로그, CDN)”이 비용을 결정
성장기(트래픽/데이터 증가): 네트워크 egress와 관측 비용 최적화가 승부
안정기(커밋 가능): AWS Savings Plans vs GCP CUD로 고정비를 크게 낮출 수 있음

간단한 비용 산정 실습 예시: 월 예상 비용을 코드로 뽑아보기

클라우드 공식 계산기(AWS Pricing Calculator, GCP Pricing Calculator)가 가장 정확하지만, 스타트업은 “가설 기반”으로 빠르게 시뮬레이션해야 할 때가 많습니다. 아래는 매우 단순화한 예시로, 컴퓨트 + DB + egress + 로그를 월 비용으로 합산해 감을 잡는 스크립트입니다.

실제 단가는 리전/약정/티어에 따라 달라지므로 숫자는 예시로만 보세요.

from dataclasses import dataclass

HOURS_PER_MONTH = 24 * 30

@dataclass
class CostModel:
    compute_per_hour: float
    db_per_hour: float
    egress_per_gb: float
    logs_ingest_per_gb: float


def estimate_monthly(cost: CostModel, compute_hours: int, db_hours: int, egress_gb: float, logs_gb: float) -> float:
    return (
        cost.compute_per_hour * compute_hours
        + cost.db_per_hour * db_hours
        + cost.egress_per_gb * egress_gb
        + cost.logs_ingest_per_gb * logs_gb
    )


# 예시 단가(가짜): AWS와 GCP를 비슷한 급으로 가정
aws = CostModel(
    compute_per_hour=0.05,   # t계열/버스트급 가정
    db_per_hour=0.12,        # 관리형 DB 소형 가정
    egress_per_gb=0.09,
    logs_ingest_per_gb=0.50,
)

gcp = CostModel(
    compute_per_hour=0.048,
    db_per_hour=0.115,
    egress_per_gb=0.085,
    logs_ingest_per_gb=0.45,
)

# 워크로드 가정
compute_hours = HOURS_PER_MONTH * 2  # VM 2대 24/7
_db_hours = HOURS_PER_MONTH          # DB 1대 24/7
_egress_gb = 800                     # 월 800GB 다운로드
_logs_gb = 60                        # 월 로그 60GB 수집

print("AWS monthly:", estimate_monthly(aws, compute_hours, _db_hours, _egress_gb, _logs_gb))
print("GCP monthly:", estimate_monthly(gcp, compute_hours, _db_hours, _egress_gb, _logs_gb))

이렇게 단순 모델로라도 계산해보면, “컴퓨트 10% 절감”보다 “egress 30% 절감”이 더 큰 효과를 내는 구간이 자주 보입니다.

트러블슈팅 체크리스트: 비용이 갑자기 튀는 원인 TOP 7

CDN 미사용으로 egress 폭증
리전 간 트래픽 발생(예: 앱은 A 리전, DB는 B 리전)
NAT 게이트웨이/라우팅 구성으로 불필요한 경로를 타는 트래픽
로그 레벨 과다(DEBUG가 프로덕션에 남아있음)
오토스케일 최소값 과대(항상 많은 노드가 떠 있음)
스냅샷/백업 보관 기간 무제한
테스트 환경 방치(스테이징이 프로덕션만큼 큼)

비용 이슈를 찾을 때는 “청구서”만 보지 말고, 리소스 단위로 역추적하세요.

AWS: Cost Explorer, CUR(Cost and Usage Report)
GCP: Billing Export(BigQuery), Cost Table

비용 절감 Best Practice: AWS든 GCP든 공통으로 먹히는 것

1) 아키텍처를 단순하게 시작하기

초기에 MSA+K8s로 가면 인프라 비용뿐 아니라 운영 인건비가 큽니다.
단일 서비스(모놀리식) + 관리형 DB + 오브젝트 스토리지 + CDN 정도로 시작해도 충분한 경우가 많습니다.

2) “항상 켜짐” 리소스부터 커밋/예약 검토

24/7로 돌아가는 DB, 기본 서버, 베이스라인 워커
반대로 이벤트성 배치/크론은 스팟/프리엠티블로

3) 로그는 전략적으로

필드 줄이기(특히 request/response body)
샘플링
보관 기간 최소화

4) 네트워크를 설계에 포함하기

같은 리전/같은 존에서 통신하도록 기본 원칙 세우기
정적/미디어는 CDN으로

결론: 스타트업의 “유리한 선택”은 비용표가 아니라 운영 전략에서 결정된다

AWS와 GCP 중 무엇이 더 싸냐는 질문은, 사실 “어떤 워크로드를 어떤 방식으로 운영할 것이냐”로 바뀌어야 합니다.

초기에는 플랫폼 간 단가 차이보다 **구성 선택(HA, LB, CDN, 로그 정책)**이 비용을 좌우합니다.
성장기에는 egress와 관측 비용이 가장 큰 변수로 튀기 때문에, CDN/로그 전략이 곧 비용 전략입니다.
안정기에 들어서면 AWS의 Savings Plans, GCP의 CUD 같은 커밋 할인이 큰 폭의 절감을 만들어냅니다.

결국 “우리 팀이 더 빨리 안전하게 운영할 수 있는 쪽”을 고르고, 위의 체크리스트로 비용이 튀는 지점을 선제적으로 막는 것이 스타트업에게 가장 유리한 선택입니다.