[Cloud Run][비용] request-based billing과 instance-based billing을 언제 나눠 써야 하나

IT 리서치 노트

[Cloud Run][비용] request-based billing과 instance-based billing을 언제 나눠 써야 하나

Cloud Run은 같은 서비스라도 어떤 billing mode를 쓰는지에 따라 비용 설명이 완전히 달라진다. 2026년 6월 24일 기준 공식 문서를 다시 보면 request-based billing이 기본값이고, instance-based billing은 인스턴스 전체 수명 동안 과금되는 별도 선택이다. 문제는 min instances, concurrency, idle 시간, 긴 요청이 섞이면 두 모드의 체감 비용이 직관과 다르게 보인다는 점이다.

목차

1. 개요
2. 어디서 실제로 막히는가
3. 실무 적용 순서
4. 공식 문서와 예시 화면으로 확인하기
5. 주의사항과 리스크
6. 결론
7. 참고 링크

1. 개요

먼저 결론부터 말하면, 요청이 뜸하고 idle 구간이 긴 서비스는 request-based billing이 기본 출발점이다. 반대로 background 처리, 긴 연결, 일정한 상시 처리량이 있는 서비스는 instance-based billing을 먼저 검토하는 편이 낫다. 특히 min instances와 concurrency를 같이 조정할 때 비용이 달라지는 이유를 이미 본 상태라면, 이번 글은 그보다 한 단계 앞의 billing mode 선택 기준을 정리하는 글로 보면 된다.

비용 비교를 단순히 CPU seconds나 요청 수만으로 보면 실제 청구와 어긋나기 쉽다. Cloud Run pricing docs와 billing settings 문서를 같이 보면, request-based는 per-request fee와 요청 처리 시간 기준이 살아 있고, instance-based는 per-request fee가 없는 대신 인스턴스 전체 생존 시간을 과금한다. RDS를 멈춰도 남는 비용을 점검하는 글처럼, Cloud Run도 '켜져 있는 시간'에 가까운 과금이 언제 생기는지 구분해야 비용 설명이 된다.

2. 어디서 실제로 막히는가

실무에서 가장 흔한 착각은 세 가지다. 첫째, Cloud Run은 서버리스이므로 요청이 없으면 무조건 비용이 0에 가까울 것이라고 생각한다. 둘째, min instances를 켜면 자동으로 instance-based billing이라고 이해한다. 셋째, 장시간 작업이 많아도 request-based billing이 항상 더 싸다고 가정한다. 공식 문서를 다시 보면 세 가지 모두 상황에 따라 틀릴 수 있다.

request-based billing은 기본값이 맞지만, 요청 처리 시점과 시작·종료 시점 외에는 같은 식으로 과금되지 않는다. 그러나 min instances를 올리면 idle 대기 인스턴스 비용이 생기고, long-lived request가 많으면 요청당 과금과 CPU·memory 시간 누적이 빠르게 커질 수 있다. 반대로 instance-based billing은 per-request fee가 없지만 인스턴스가 살아 있는 전체 시간에 과금되므로, 트래픽이 뜸한 서비스라면 오히려 더 비쌀 수 있다.

또 하나 막히는 지점은 팀 안에서 비용 설명 단위가 다르다는 점이다. 어떤 사람은 요청 수를 보고, 어떤 사람은 vCPU seconds를 보고, 어떤 사람은 cold start 때문에 min instances를 올린 뒤 idle 비용을 놓친다. 이렇게 기준이 제각각이면 운영 회고 때 원인을 좁히기 어렵다. 먼저 billing mode를 고르고, 그다음 min instances와 concurrency를 얹는 순서로 봐야 같은 표를 볼 수 있다.

• 오해: 서버리스니까 요청이 없으면 항상 거의 0원일 것이라고 본다.
• 오해: min instances를 켜는 순간 instance-based billing이라고 생각한다.
• 실패: 긴 요청과 background 처리를 request-based 비용표로만 설명한다.
• 누락: per-request fee와 idle 비용, 인스턴스 수명 과금을 한 표로 보지 않는다.

증상	먼저 볼 곳	판단 포인트
트래픽이 적은데 비용이 생각보다 높다	min instances, idle 시간, billing mode	request-based idle 요율인지, instance-based 전체 수명 과금인지 구분한다
장시간 연결 서비스에서 요청 수가 적다	processing duration, long-lived request, concurrency	instance-based가 더 예측 가능할 수 있다
cold start를 줄이려다가 비용이 늘었다	min instances와 idle 비용 구조	request-based와 instance-based를 같이 비교한다

3. 실무 적용 순서

실무에서는 다섯 단계로 보면 정리가 빠르다. 첫째, 서비스가 요청이 있을 때만 잠깐 일하는지, 아니면 인스턴스가 살아 있는 동안 background 성격의 일을 계속 하는지 확인한다. 둘째, cold start를 줄이기 위해 min instances를 올렸는지 본다. 셋째, 장시간 연결이나 오래 걸리는 요청이 있는지 확인한다. 넷째, billing mode를 request-based와 instance-based로 각각 대입해 어떤 지표가 더 설명력이 높은지 본다. 다섯째, concurrency와 min instances를 그 모드 위에 얹어 세부 비용을 계산한다.

1. 서비스가 요청 처리형인지 상시 처리형인지 먼저 나눈다.
2. min instances 사용 여부와 idle 구간 길이를 본다.
3. 긴 요청, streaming, background 처리 여부를 체크한다.
4. request-based와 instance-based 각각으로 비용 설명이 되는지 비교한다.
5. 그다음 concurrency와 최소 인스턴스 수를 조정한다.

예를 들어 트래픽이 드문 admin API나 내부 백오피스 서비스는 request-based가 자연스러운 출발점이다. 반대로 queue consumer, streaming gateway, 지속 연결이 남는 서비스는 instance-based billing을 먼저 깔아두고 계산하는 편이 더 설명력이 좋다. 이 기준을 안 세우고 바로 concurrency만 조정하면 비용 변화 이유를 잘못 해석하기 쉽다.

실제로는 콘솔에서 서비스 설정을 열고 billing mode를 확인하고, min instances 값을 조회하고, concurrency 값을 비교하고, 최근 요청 로그를 확인하고, billing export나 비용 보고서를 같이 읽어야 한다. 이처럼 메뉴를 열고 확인하고 비교하는 순서를 정해두면 왜 request-based로 남길지, 왜 instance-based로 바꿀지 설명이 쉬워진다.

비용 검토 메모 예시

service: api
billing_mode: request-based
min_instances: 1
idle_time_ratio: high
long_lived_requests: low
container_concurrency: 40
note: cold start 억제는 필요하지만 전체 수명 과금까지 갈 이유는 적음

이처럼 billing mode를 먼저 메모에 고정하면, 이후 비용 회고에서 Vercel duration과 memory를 같이 보는 글처럼 어떤 수치를 비교해야 하는지 논리가 선다. Cloud Run도 결국 과금 단위를 먼저 고른 뒤 세부 튜닝을 하는 구조다.

4. 공식 문서와 예시 화면으로 확인하기

가장 먼저 보는 화면은 Cloud Run billing settings 문서다. 여기서 request-based billing이 기본값이고, instance-based billing으로 바꾸면 과금 기준 자체가 달라진다는 점을 확인해야 한다.

Billing settings 문서는 request-based billing이 기본값이고, instance-based billing이 별도 선택이라는 점을 바로 보여 준다.

이 구분을 먼저 잡아야 한다. request-based는 요청 처리 중과 시작·종료 시점 위주로 비용이 잡히고, instance-based는 인스턴스가 살아 있는 전체 시간에 과금된다.

두 번째 화면은 min instances 문서다. idle 비용을 오해하는 경우가 많아서, billing mode와 min instances를 같이 보지 않으면 계산이 틀어진다.

min instances 문서는 request-based billing에서 idle 인스턴스가 더 낮은 요율로 과금되거나 0일 수 있다는 점을 보여 준다.

즉 min instances를 1로 올렸다고 바로 instance-based billing이 되는 것은 아니다. request-based에서도 idle 비용 구조가 따로 있고, 설정 조합에 따라 체감 비용이 달라진다.

세 번째로는 cost optimization 문서의 비교 구간을 본다. 공식 문서가 두 billing mode를 어떤 운영 조건에서 비교하는지 그대로 보는 편이 빠르다.

Cloud Run cost optimization 문서는 request-based와 instance-based의 핵심 차이를 비용 관점에서 비교한다.

여기서 실무 기준이 나온다. 대기 시간이 길고 요청이 뜸한 서비스는 request-based가 유리하고, 백그라운드 작업이나 장시간 연결이 잦으면 instance-based 쪽이 더 맞을 수 있다.

설정 파일에서는 어느 서비스가 어떤 billing mode를 쓰는지 명시적으로 남기는 편이 좋다. 콘솔에서 클릭만 해두면 나중에 왜 그렇게 과금되는지 팀원이 다시 추적하기 어렵다.

서비스 설정 예시는 billing mode와 min instances, concurrency를 한 번에 묶어 기록하는 방식이다.

특히 minScale와 containerConcurrency가 붙은 서비스라면 request-based인지 instance-based인지 같이 적어두어야, idle 비용과 처리량을 한 번에 계산할 수 있다.

마지막 자료는 선택 기준을 빠르게 비교하기 위한 체크표다. 이 표는 실제 비용 계산 전에 어떤 서비스 특성을 먼저 봐야 하는지 정리하는 용도다.

요청 패턴, idle 시간, 장시간 처리 여부를 기준으로 billing mode를 먼저 가른다.

이 비교표를 보고도 판단이 애매하면, 기존 비용 이력에서 요청당 처리 시간과 idle 구간 길이를 먼저 뽑아 보는 편이 낫다. 그다음에 per-request fee와 full-lifecycle fee를 대입한다.

5. 주의사항과 리스크

첫 번째 리스크는 GPU나 장시간 처리 기능처럼 instance-based billing이 사실상 전제가 되는 기능을 request-based 관점으로 설명하는 것이다. 두 번째 리스크는 min instances를 올린 뒤 idle 인스턴스 비용을 잊는 것이다. 세 번째 리스크는 트래픽 특성이 바뀌었는데 billing mode는 그대로 두고 concurrency만 만지는 것이다.

배포 전에 확인할 때는 콘솔에서 billing mode를 다시 열어 보고, min instances와 concurrency를 입력한 값이 맞는지 확인하고, 요청 로그와 비용 리포트를 조회하고, 변경 전후 지표를 비교하는 편이 좋다. 단순히 감으로 '이번엔 더 쌀 것 같다'고 판단하지 말고 같은 메뉴와 같은 로그를 반복 확인해야 한다.

비용 절감 실험을 할 때는 하루 총 요청 수보다 요청 분포를 같이 봐야 한다. 특정 시간대에만 몰리고 나머지 시간은 거의 idle이라면 request-based가 유리할 가능성이 높다. 반대로 항상 조금씩이라도 일하고 오래 사는 인스턴스가 필요하면 instance-based가 더 나을 수 있다.

• GPU 서비스는 instance-based billing이 사실상 필수다.
• min instances를 올리면 idle 비용 구조를 같이 봐야 한다.
• 트래픽 패턴이 바뀌면 billing mode도 다시 비교해야 한다.

6. 결론

Cloud Run 비용 최적화는 concurrency 숫자부터 만지는 작업이 아니다. 먼저 request-based billing과 instance-based billing 중 어떤 과금 모델이 서비스 성격을 더 잘 설명하는지 정해야 한다. 그다음 min instances, idle 시간, 긴 요청, background 처리 여부를 얹어 계산해야 실제 청구와 운영 체감이 맞아떨어진다.

• 트래픽이 뜸하고 idle 구간이 길면 request-based부터 본다.
• 상시 처리와 긴 연결이 많으면 instance-based를 먼저 검토한다.
• billing mode를 먼저 정한 뒤 min instances와 concurrency를 조정한다.

7. 참고 링크

1. https://docs.cloud.google.com/run/docs/configuring/billing-settings
2. https://cloud.google.com/run/pricing
3. https://docs.cloud.google.com/run/docs/tips/services-cost-optimization
4. https://docs.cloud.google.com/run/docs/configuring/min-instances