Cloud Run 비용이 발생하는 이유와 줄이는 방법

Cloud Run 요금은 요청이 몇 건 들어왔는지만으로 정해지지 않습니다. 같은 요청 수라도 인스턴스를 얼마나 오래 띄워 두었는지, CPU와 메모리를 얼마나 잡았는지, 어떤 청구 설정을 썼는지에 따라 금액이 달라집니다. 요청이 거의 없는데 청구서에 금액이 찍혔다면 대개 이 가운데 하나가 이유입니다.

이 글은 먼저 청구서에서 원인을 읽는 법을 다루고, 그다음 설정을 바꿔 줄이는 방법을 순서대로 다룹니다. 모든 내용은 Google Cloud 공식 문서와 가격표를 2026년 10월 11일에 읽고 정리했고, 10월 12일에 주요 내용을 다시 확인했습니다. 실제 서비스의 요금 데이터나 운영 경험에서 나온 글이 아니며, 비용이 몇 퍼센트 줄어든다는 식의 수치는 근거가 없어 쓰지 않았습니다. 본문의 화면 캡처는 한국어 Google Cloud 콘솔에서 찍은 것으로 메뉴 위치와 항목 이름을 보여 주는 용도이고, 서비스 URL 같은 식별 정보는 가렸습니다. 캡처에 나온 금액이나 사용량은 이 글의 근거가 아닙니다.

설정 변경은 운영 중인 서비스의 응답 속도나 가용성에 영향을 줄 수 있습니다. 그래서 읽기만 하는 확인 방법을 먼저 두고, 변경 방법에는 영향과 되돌리는 방법을 함께 적었습니다.

순서

1. 비용이 어떤 항목에서 생기는지 이해합니다.
2. 요청이 없어도 생기는 비용의 이유를 압니다.
3. 무료 한도가 어디까지 덮는지 확인합니다.
4. 청구 보고서에서 원인을 찾습니다.
5. 최소·최대 인스턴스와 CPU·메모리를 점검합니다.
6. 예산 알림을 걸고, 변경 후 효과를 확인합니다.

Cloud Run 비용은 어떻게 발생할까

Cloud Run은 쓴 자원만큼 비용을 내는 서비스이고, 사용량은 100밀리초 단위로 올림해 계산합니다. 청구서의 합계는 가격표의 항목별 사용량을 합한 뒤 무료 사용량을 뺀 값입니다.

한 인스턴스가 동시에 여러 요청을 처리하도록(동시성 1 초과) 설정하면 요청들이 그 인스턴스의 CPU와 메모리를 나눠 씁니다. 같은 요청이라도 동시성 설정에 따라 필요한 인스턴스 시간이 달라진다는 뜻입니다.

요금이 계산되는 방식은 청구 설정 두 가지로 나뉩니다. 이 선택이 아래의 모든 내용에 영향을 줍니다.

• 요청 기반 과금(기본값): 인스턴스는 요청을 처리할 때와 시작하고 종료할 때에만 과금됩니다. 예전에는 CPU가 요청 처리 중에만 할당됨이라고 불렀습니다.
• 인스턴스 기반 과금: 요청이 없어도 인스턴스의 수명 전체가 과금됩니다. 요청과 별개로 백그라운드 작업을 해야 하는 서비스에 쓰며, 예전에는 CPU가 항상 할당됨이라고 불렀습니다.

콘솔에서는 서비스의 확장 탭에 결제 항목이 있어 현재 설정을 볼 수 있습니다(아래 최소 인스턴스 항목의 캡처에 같이 나옵니다). Cloud Run 작업(job)은 항상 인스턴스 기반 과금입니다. Google은 지난달 트래픽을 보고 요청 기반에서 인스턴스 기반으로 바꾸는 것이 더 싸면 그렇게 추천해 주는 기능도 있다고 안내합니다.

또한 가격은 리전마다 다르고, 원화 등 다른 통화로 결제하면 그 통화로 표시된 SKU 가격이 적용됩니다.

요청이 없어도 비용이 발생하는 이유

요청이 없는데도 비용이 나온다면 아래 중 하나일 가능성이 높습니다. 모든 Cloud Run 서비스가 요청이 없으면 무료인 것은 아닙니다.

• 최소 인스턴스가 1 이상입니다. 최소 인스턴스를 지정하면 Cloud Run은 요청이 없어도 그 수만큼 인스턴스를 계속 켜 둡니다. 이 유휴 인스턴스에는 비용이 붙습니다. 요청 기반 과금에서는 활성일 때보다 낮은 유휴 단가가 적용되고, 최소 인스턴스를 0으로 두면 유휴 인스턴스에는 과금하지 않습니다.
• 인스턴스 기반 과금입니다. 최소 인스턴스가 0이어도 인스턴스가 떠 있는 동안은 요청 처리 중이든 유휴든 기본 단가가 붙습니다.
• 리비전 단위 최소 인스턴스와 태그입니다. 리비전에 최소 인스턴스를 걸고 트래픽 태그까지 붙이면 태그된 리비전이 모두 시작되어 요청이 없어도 유지됩니다. Google은 서비스 단위로 최소 인스턴스를 설정하거나, 필요 없어진 태그를 지우라고 안내합니다.
• 주변 서비스 비용입니다. 컨테이너 이미지를 쌓아 두는 Artifact Registry는 저장한 용량에 요금이 붙고, 로그와 메트릭은 Google Cloud Observability 가격표를, VPC 연결 커넥터는 연산 비용을 따로 냅니다. 이 비용은 Cloud Run 요청 수와 상관없이 생깁니다.

Cloud Run 무료 한도 이해하기

무료 사용량은 청구 설정에 따라 다릅니다. 아래 값은 가격표 기준(미국 아이오와 us-central1 가격 기준)이고, 작성일에 확인한 값이라 바뀔 수 있습니다.

적용 방식에서 놓치기 쉬운 점은 이렇습니다.

• 무료 사용량은 프로젝트별이 아니라 결제 계정 단위로 합산되고 매월 초기화됩니다. 한도를 넘은 사용량만 청구됩니다.
• 무료 사용량은 사용 자원에서 직접 빼는 것이 아니라 지출 기반 할인으로 적용되며, 1단계(Tier 1) 가격으로 계산합니다. 그래서 리전별 가격 차이가 있는 환경에서는 표의 숫자와 실제 면제 금액이 단순 비례하지 않을 수 있습니다.
• 인터넷으로 나가는 데이터는 별도로, 북미 안에서 월 1 GiB가 무료입니다.

가상 계산: 최소 인스턴스 1개를 한 달 켜 두면

다음은 실제 요금이 아니라 명시적인 가정에 따른 가상 계산입니다. 가격은 쓰지 않고, 공식 무료 사용량과 비교한 규모만 봅니다.

가정: 최소 인스턴스 1개, 1 vCPU, 메모리 512 MiB(두 값 모두 기본값), 30일(2,592,000초) 내내 유지.

해석은 이렇습니다. 상시 켜 둔 인스턴스 1개의 한 달 사용량은 무료 사용량보다 훨씬 커서 무료 한도가 대부분을 덮지 못합니다. 다만 요청 기반 과금에서는 유휴 시간에 낮은 단가가 붙고 무료 사용량이 금액 할인으로 적용되므로, 이 표로 실제 청구액을 계산할 수는 없습니다. 실제 금액은 공식 가격 계산기나 청구 보고서로 확인합니다.

Cloud Billing에서 비용 원인 찾기

설정을 바꾸기 전에 어디서 비용이 났는지부터 봅니다. 읽기만 하는 단계라 서비스에 영향이 없습니다.

1. Google Cloud 콘솔의 결제(Billing) 에서 보고서(Reports) 를 엽니다. Google 문서는 이 보고서로 서비스별, 프로젝트별, 리전별 비용을 볼 수 있다고 설명합니다.
2. 기간을 지난달 등으로 정하고, 서비스를 기준으로 묶어 Cloud Run이 비용 상위인지 확인합니다.
3. Cloud Run 안에서는 SKU를 기준으로 나눠 CPU, 메모리, 요청 중 어느 항목이 큰지 봅니다.
4. 리전을 기준으로 묶어 의도하지 않은 리전에서 비용이 나지 않았는지 봅니다.
5. Cloud Run이 아닌 항목(Artifact Registry, 로그, 네트워크 등)이 큰지 따로 구분합니다. 비용이 Cloud Run이 아니라 주변 서비스에서 났다면 Cloud Run 설정을 바꿔도 줄지 않습니다.

표에는 사용 비용 외에 절감 프로그램, 기타 절감, 소계 열이 따로 있으므로 금액을 읽을 때는 어느 열인지 구분합니다.

비용이 한 곳에 모이지 않고 여러 청구서에 나뉘는 경우도 있습니다. 예를 들어 Cloud Run 서비스를 GitHub Actions로 배포한다면 Actions 사용량은 GitHub 쪽에 따로 청구되며, 이쪽을 줄이는 방법은 GitHub Actions 비용 줄이는 방법에 정리했습니다.

Cloud Run 콘솔의 메트릭도 함께 봅니다. Cloud Monitoring은 별도 설정 없이 청구 가능한 컨테이너 인스턴스 시간, CPU와 메모리 할당·사용률 같은 메트릭을 자동으로 수집하고, 완전 관리형 Cloud Run의 메트릭에는 비용이 없다고 Google이 안내합니다. 청구서의 CPU 시간과 이 메트릭이 어긋나면 어떤 서비스나 리비전이 인스턴스를 켜 두고 있는지 찾는 단서가 됩니다.

최소 인스턴스 설정으로 비용 줄이기

최소 인스턴스(Minimum instances)는 요청이 없을 때도 켜 둘 인스턴스의 수입니다. 기본값은 0이고, 값을 올리면 요청이 와도 새 인스턴스를 띄우는 시간을 기다리지 않아 응답이 빨라지는 대신 비용이 늘어납니다.

현재 값부터 읽기 전용으로 확인합니다.

gcloud run services describe SERVICE --region REGION --format export

출력에서 minScale로 끝나는 항목을 찾습니다. 서비스 단위 설정은 metadata.annotations 아래의 run.googleapis.com/minScale, 리비전 단위 설정은 spec.template.metadata.annotations 아래의 autoscaling.knative.dev/minScale로 나옵니다. 둘 다 웹 주소가 아니라 YAML 주석(annotation)의 키 이름이라 브라우저로 열 수 없습니다. 콘솔에서는 서비스를 선택해 확장(Scaling) 탭의 인스턴스 최소 개수 항목에서 볼 수 있습니다. 서비스에 값이 없으면 기본값 0입니다.

줄이는 판단 기준은 이렇습니다.

0으로 바꿀 때의 영향은 콜드 스타트(요청이 없다가 들어올 때 새 인스턴스를 시작하는 시간)입니다. 요청 기반 과금이라면 그 대가로 유휴 비용이 사라집니다. Google은 비용을 줄이려면 최소 인스턴스 수를 평소 트래픽을 처리하는 데 필요한 수에 맞추라고 안내합니다. 가용성 면에서는 최소 인스턴스가 보장이 아니라 최선의 노력(best-effort) 목표이고, 고가용성이 필요하면 3개 이상을 고려하라는 안내도 있습니다.

변경하는 방법입니다. 서비스 단위 설정은 새 리비전을 배포하지 않아도 바로 적용되므로, 응답 지연에 민감한 서비스라면 사용량이 적은 시간에 하는 것이 안전합니다.

gcloud run services update SERVICE --region REGION --min MIN-VALUE

되돌리는 방법: 바꾸기 전에 확인해 둔 이전 값으로 같은 명령을 다시 실행합니다. 값을 바꾸기 전에 서비스 이름, 리전, 기존 값을 메모해 둡니다.

최대 인스턴스 설정 시 주의사항

최대 인스턴스(Maximum instances)는 서비스가 요청에 따라 늘릴 수 있는 인스턴스 수의 상한입니다. 기본값은 리비전당 100개입니다. Google은 이 값을 비용 안전장치로 쓸 수 있다고 설명하고, 갑작스러운 트래픽에서 예산을 지키려면 처음 배포할 때 3 정도로 시작하는 것을 제안합니다. 데이터베이스처럼 동시 연결 수가 제한된 뒷단 서비스를 보호하는 용도로도 씁니다.

대가는 가용성입니다. 한도에 닿아 인스턴스가 모자라면 요청이 대기열에서 기다립니다. 최대 10초 또는 인스턴스 평균 시작 시간의 3.5배 중 더 긴 시간까지 대기하고, 그 안에 처리할 인스턴스가 비지 않으면 429 오류로 실패합니다. 또 이 상한은 짧은 시간 동안 초과될 수 있다고 문서에 적혀 있어서, 비용의 절대 상한이 되지는 않습니다.

그래서 평소 사용량이 낮은 서비스의 비용을 줄이려는 목적보다는, 급증에 대비한 안전장치로 접근합니다. 값을 정하기 전에 평소 최대 트래픽에서 몇 개의 인스턴스가 필요한지 메트릭으로 확인합니다.

gcloud run services update SERVICE --region REGION --max MAX-VALUE

되돌리는 방법: 이전 값으로 다시 설정합니다. 서비스 단위 제한을 없애려면 콘솔 확장 탭의 인스턴스의 최대 개수 항목에서 값을 지우면 기본값으로 돌아갑니다.

CPU와 메모리 설정 최적화

인스턴스 하나의 기본 설정은 vCPU 1개, 메모리 512 MiB입니다. 크게 잡을수록 초당 비용이 올라가므로 실제 사용량보다 과하게 잡은 값이 없는지 봅니다.

CPU와 메모리는 서로 제약이 있습니다. vCPU가 0.08이면 메모리는 최대 512 MiB, 0.5이면 최대 1 GiB, 1이면 최대 4 GiB처럼 조합이 정해져 있고, 1을 넘는 vCPU는 정수여야 합니다.

줄이는 순서는 이렇습니다.

1. Cloud Run 메트릭에서 컨테이너 CPU 사용률과 컨테이너 메모리 사용률을 지난 기간 동안 봅니다. 평균이 아니라 최댓값 근처까지 봐야 합니다.
2. 최대 사용률에도 여유가 크게 남는 자원만 후보로 둡니다.
3. 한 번에 한 가지 값만, 조금씩 줄입니다.
4. 줄인 뒤 응답 시간과 오류를 확인합니다.

위험도 분명합니다. 메모리가 한도를 넘으면 인스턴스가 종료됩니다. 메모리는 실행 파일 적재, 프로세스의 메모리 할당, 파일 시스템에 쓰는 데이터까지 포함해서 모자라지 않아야 하고, 배포한 이미지의 크기는 메모리와 무관합니다. CPU를 너무 줄이면 요청 지연이 늘 수 있습니다. 이 값을 바꾸면 새 리비전이 배포되므로 되돌릴 때도 이전 값으로 다시 배포하면 됩니다.

요청 기반에서 인스턴스 기반으로, 또는 그 반대로 청구 설정을 바꾸는 것도 비용을 바꾸는 선택입니다. 요청이 없을 때 CPU가 할당되지 않으면 백그라운드 작업이 제대로 돌지 않을 수 있어서, 비용만 보고 바꾸지 않습니다.

예산 알림과 비용 모니터링

예산은 두 종류입니다. 이 차이를 모르면 알림을 걸어 놓고 과금이 멈춘다고 오해합니다. 콘솔에서는 결제 메뉴의 Cost control 아래 Budgets & caps에서 만들며, 한국어 콘솔에서도 이 메뉴 이름은 영어로 표시됩니다.

예산 만들기의 첫 단계인 정의에서 알림만과 지출 한도 적용 중 하나를 고르며, 한국어 화면에서는 지출 상한이 지출 한도로 표시됩니다. 지출 한도 적용 옆에는 일부 서비스에서만 쓸 수 있다는 표시가 있습니다.

알림 전용 예산은 지출이 기준을 넘었을 때 알려 줄 뿐입니다. 실제 지출 계산에는 보통 최대 24시간이 걸려서 알림이 늦게 올 수 있고, 한도 아래로 예산 금액을 잡으라는 안내도 있습니다.

지출 상한은 Cloud Run에도 쓸 수 있지만 신중해야 합니다. 상한이 작동하면 그 프로젝트의 Cloud Run 서비스는 트래픽을 처리하지 못하고 5xx 오류를 반환합니다. 작업(job)은 새 실행이 시작되지 않고 진행 중이던 작업도 끝나지 못하며, 워커 풀의 인스턴스는 처리를 멈춥니다. 이미 처리 중인 요청은 끝까지 처리됩니다.

이 기능은 Cloud Run 문서에서 미리보기(Preview)로 표시되어 있습니다. Cloud Billing의 지출 상한 문서에는 이 표기가 따로 보이지 않으므로, 쓰기 전에 콘솔과 두 문서에서 현재 출시 단계를 확인합니다. 월 단위, 프로젝트 하나와 서비스 하나의 범위, 크레딧을 반영하지 않는 추정 총비용 기준이라는 제한도 있습니다. 상한은 다음 예산 기간 초에 자동으로 풀리고, 그 전에 서비스를 재개하려면 Cloud Run 콘솔에서 상한을 해제하거나 조정해야 합니다. 예산 목록 화면의 안내 배너에도 같은 내용이 영어로 나옵니다.

상한이 있어도 비용이 0이 되거나 초과가 없다는 뜻은 아닙니다.

• 반영 지연으로 초과가 생길 수 있습니다. 상한은 추정 비용으로 판단해서 청구 보고서보다 훨씬 빨리 작동하지만 즉시는 아닙니다. 보고 지연 때문에 생긴 초과분은 평소처럼 청구된다고 Google이 밝힙니다. 실제 비용은 보통 하루 안에 보고서에 올라오지만 24시간이 넘게 걸리기도 합니다.
• 고정 비용은 계속 청구됩니다. 서비스를 유지하는 데 필요한 지속적인 고정 비용은 상한이 걸려도 정상적으로 청구되고, 컴퓨트나 스토리지 같은 지속 리소스의 비용은 멈추지 않는다고 설명합니다. Cloud Run 문서에는 VPC 커넥터 VM이 Compute Engine에서 청구되어 지출 상한이 무시하는 대상이라는 안내도 있습니다.
• 범위 밖의 비용은 막지 못합니다. 상한은 프로젝트 하나와 서비스 하나에만 걸리므로, 같은 프로젝트의 이미지 저장소나 로그 같은 다른 서비스의 비용은 포함되지 않습니다.

권장하는 순서는 이렇습니다.

1. 먼저 알림 전용 예산을 프로젝트에 걸어 이상 징후를 빨리 알 수 있게 합니다.
2. 지출 상한은 장애가 나도 감당할 수 있는 서비스(개발·테스트용 등)에서 먼저 시험합니다.
3. 운영 서비스에는 상한이 곧 서비스 중단이 될 수 있고, 걸린 뒤에도 초과분과 고정 비용이 청구될 수 있다는 점을 알고 적용합니다.

설정 변경 후 비용 절감 효과 확인하기

설정을 바꿨다면 효과를 숫자로 확인합니다. 절감 폭은 서비스마다 다르며, 이 글은 어떤 수치도 약속하지 않습니다.

변경한 날짜와 시각, 이전 값, 바꾼 값을 기록해 두고 같은 길이의 기간끼리 비교합니다. 청구액은 반영이 늦으니 변경 직후의 며칠만으로 결론 내리지 않습니다. 응답 지연이나 오류율이 나빠졌다면 비용이 줄었더라도 이전 값으로 되돌립니다.