Cloudflare 지출 제한 출시: Workers 비용 상한과 서비스 중단을 구분하기

클라우드 사용량을 차단하는 안전장치를 표현한 생성형 개념 이미지. 실제 Cloudflare 화면이 아니다.

Workers 비용이 급증했을 때 메일만 받고 계속 과금되는 상황을 막을 수 있을까? Cloudflare는 2026년 11월 13일 Workers와 Durable Objects에 사용 차단형 지출 제한을 추가했다. 다만 이를 청구서의 절대 상한으로 이해하면 안 된다. 차단 지연과 제외 비용이 있고, 같은 계정의 다른 서비스도 영향을 받을 수 있다. 공식 발표

알림과 차단은 다른 기능이다

이전의 계정 단위 예산 알림은 비용을 알려줄 뿐 실행을 멈추지 않는다. 새 기능에서는 제품별 지출 제한과 알림을 구분해 선택한다. Workers와 Durable Objects의 한도는 각각 현재 구독 청구 기간에 적용된다. AI Gateway의 추론 비용 제어는 별도 기능이며, Gateway로 라우팅된 요청에 적용된다. 출시 안내

먼저 정할 것은 금액이 아니라 장애 허용 범위다. 개인 실험 서비스라면 차단을 선택할 수 있다. 중단이 곧 고객 장애가 되는 서비스라면 낮은 구간에는 알림을 두고, 차단 여부는 별도 운영 판단으로 다루는 편이 낫다. 이는 기능 보장이 아니라 설계 권고다.

한 Worker의 예산이 아니다

Workers 제한은 계정 안의 Workers 사용량을 합산한다. 특정 Worker나 개발 환경만 선택하는 기능이 아니다. 테스트 Worker가 공용 한도를 소진해 운영 Worker까지 중단시키는 상황을 고려해야 한다.

차단이 적용되면 HTTP뿐 아니라 Cron, Queue 소비자, Email Worker, 다른 Worker나 Durable Object에서 들어오는 호출도 영향을 받는다. HTTP 방문자에게는 오류 1103이 표시될 수 있지만, 이 코드만으로 지출 제한을 원인이라고 확정할 수는 없다.

Worker 실행 없이 제공되는 정적 자산은 계속 서비스될 수 있다. 반면 run_worker_first처럼 코드 실행이 필요한 경로는 실패할 수 있다. 따라서 홈페이지가 열린다는 사실만으로 API와 백그라운드 작업까지 정상이라고 판단하지 않는다. Workers 차단 범위

50달러 제한이 총 청구액 50달러를 뜻하지 않는 이유

한도 계산은 포함 사용량을 차감한 해당 제품의 추정 사용 요금을 기준으로 한다. Workers의 요청·CPU 시간은 포함되지만 구독료와 다른 제품 비용은 별개다. Durable Objects도 저장된 데이터 비용은 제한 밖에 남는다.

계량과 차단 전파에는 시간이 걸린다. 이미 진행 중인 작업이나 집행 실패 때문에 금액이 초과될 수 있다. 또한 현재 기간에 이미 기록된 지출도 평가에 포함되므로, 이미 60달러를 쓴 계정에 50달러 제한을 추가하면 곧바로 중단 조건이 될 수 있다. 비용 계산과 제한 설명

이 때문에 지출 제한을 무제한 트래픽 방어의 유일한 장치로 삼지 않는 편이 좋다. 인증, 요청 제한, 작업량 제한과 함께 사용하고, 비용 경보를 받을 담당자도 정해야 한다.

Durable Objects는 멈춤 이후도 살펴야 한다

Durable Objects 제한은 모든 과금 원인을 정지시키지 않는다. 이미 실행 중인 요청의 실행 시간, 열린 WebSocket의 메시지, 기존 KV 기반 객체의 저장소 작업, 보관 중인 데이터 비용이 계속될 수 있다.

보류된 alarm도 복구 계획에 포함한다. 공식 문서는 예약된 지 7일을 넘긴 alarm이 보류 중 삭제될 수 있다고 설명한다. 서비스가 다시 시작됐다는 것과 지연된 작업이 모두 복구됐다는 것은 별개다. 아직 필요한 작업은 다시 예약해야 한다. Durable Objects 제한과 alarm 복구

CLI 예시: 생성보다 먼저 현재 정책을 확인한다

다음은 공식 cf CLI 문서를 바탕으로 한 예시다. 이 글에서 실제 계정에 실행하거나 과금을 발생시켜 차단을 시험하지 않았다. 계정과 청구 권한을 확인한 환경에서만 사용한다.

기존 정책이 없는지 확인한 뒤, 아래 명령은 Workers 사용 차단 한도를 50달러로 설정한다. 운영 서비스 중단 가능성이 있으므로 그대로 복사해 실행하기 전에 현재 지출과 영향 범위를 검토해야 한다.

threshold-cents는 미국 센트 단위다. 5000은 50달러다. 이 예시에는 notification-email이 없으므로 이메일 알림을 보내는 정책으로 간주하면 안 된다. 알림 전용 정책은 action notification과 수신 주소가 필요하다.

기존 정책 수정은 전체 정책 교체 방식이다. 최신 version과 --if-match를 사용하고, 유지할 이메일 등의 옵션을 빠뜨리지 않는다. 충돌 오류가 나면 최신 정책을 다시 읽는다. CLI 설정과 충돌 처리

설정 완료와 실제 차단 완료를 구분한다

저장 후에는 제품, 금액, 활성화 상태와 수신 주소를 읽어 확인한다. 대시보드의 On은 정책 활성화 상태이지 서비스가 정상 실행된다는 뜻이 아니다. Limit reached 역시 차단 전파 완료를 증명하지 않는다.

복구할 때는 한도를 현재 지출보다 높이거나, 끄거나, 제거하는 방법이 있다. 같은 한도를 껐다 켜도 누적 사용량은 초기화되지 않는다. 초기화 시점은 달력의 매월 1일이 아니라 구독 청구 기간의 시작이다. 상태와 복구 기준

실무 점검은 설정값 조회, HTTP/API와 비동기 작업의 상태, 경보 수신, 복구 이후 누락 작업 확인을 나누어 수행하는 것이 좋다. 임계값 이벤트 기록만으로 메일 전달과 차단 성공을 모두 검증했다고 쓰지 않는다.

새 지출 제한의 가치는 비용과 가용성 사이의 선택을 명시적으로 만들었다는 데 있다. 청구 금액 보증으로 과신하지 않고, 계정 전체의 의존성과 복구 절차까지 함께 설계해야 한다.