copyright: years: 2026 lastupdated: "2026-08-24"

keywords: HA: 가동 시간 목표 CISCIS, DR: 복구 시간 목표, CIS 복구 시간 목표, CIS 복구 시점 목표

subcollection: cis

속도 제한 모범 사례

다음 섹션에서는 일반적인 사용 사례에 대한 전형적인 속도 제한 구성을 다룹니다. 제공된 예시 규칙을 결합하고 자신의 시나리오에 맞게 조정할 수 있습니다.

속도 제한의 주요 사용 사례는 다음과 같습니다:

  • 사용자 에이전트, IP 주소, 리퍼러, 호스트, 국가 및 세계 지역과 같은 기준에 기반한 접근 제어를 포함하여 리소스에 대한 세분화된 접근 제어를 시행하십시오.
  • 신원 정보 도용 및 계정 탈취 공격으로부터 보호하십시오.
  • 개별 클라이언트가 수행하는 작업 수를 제한하십시오. 봇에 의한 스크래핑 방지, 민감한 데이터 접근 차단, 신규 계정 대량 생성 방지, 전자상거래 플랫폼에서의 프로그램 기반 구매를 포함합니다.
  • REST API를 자원 고갈(표적 DDoS 공격)로부터 보호하고, 일반적으로 자원의 남용을 방지합니다.
  • 서버 과부하를 방지하고 작업 횟수를 제한하여 API를 GraphQL 보호하십시오.

세분화된 접근 제어 시행

속도 제한을 사용하여 사용자와 애플리케이션이 리소스에 접근하는 방식을 제어할 수 있습니다. 속도 제한은 사용자 에이전트, IP 주소, 리퍼러 또는 호스트와 같은 속성을 기반으로 트래픽을 제한함으로써 애플리케이션이 악용되는 것을 방지하는 데 도움이 됩니다.

다음 각 예시는 특정 액세스 제어 시나리오에 대한 속도 제한 규칙을 구성하는 방법을 보여줍니다.

사용자 에이전트에 의한 요청 제한

특정 사용자 에이전트에 대해 허용되는 요청 수를 제한할 수 있습니다. 다음 규칙 예시는 모바일 앱 사용자가 10분마다 최대 100개의 요청을 할 수 있도록 허용합니다. 또한 데스크톱 브라우저의 속도를 제한하는 별도의 규칙을 생성할 수도 있습니다.

예시—사용자 에이전트별 요청 제한
설정 값
일치 기준 사용자 에이전트와 동일합니다 MobileApp
표현식 http.user_agent eq "MobileApp"
계수 특성 IP
요청률 (요청 수/기간) 10분당 100건의 요청
조치 관리형 인증 확인

특정 IP 주소 또는 ASN 허용

특정 IP 주소 또는 자율 시스템 번호(ASN)를 속도 제한 규칙에 포함하거나 제외함으로써 접근을 제어합니다.

다음 속도 제한 규칙 예시는 동일한 IP 주소로부터 분당 최대 10개의 요청을 허용하며, 해당 IP 주소가 제목 이 인 IP 목록에 포함되지 않은 partner_ips 경우 경로로 /status 요청을 GET 수행합니다.

예시—특정 IP 또는 ASN 허용
설정 값
일치 기준 URI 경로가 와 /status 일치하고 요청 메서드가 와 GET 일치하며 IP 소스 주소가 목록에 포함되지 않음 partner_ips
표현식 http.request.uri.path eq "/status" and http.request.method eq "GET" and not ip.src in $partner_ips
계수 특성 IP
요청률 (요청 수/기간) 10개 요청 / 1분
조치 관리형 인증 확인

리퍼러에 의한 요청 제한

리퍼러 페이지(예: 제3자 광고 또는 외부 웹사이트)에서 발생하는 요청을 제한할 수 있습니다. 이 사용 사례는 간접 서비스 거부( DDoS DoS) 공격의 위험을 줄이고 요청 할당량을 관리하는 데 도움이 됩니다.

예시—리퍼러별 요청 제한
설정 값
일치 기준 URI 경로가 동일하고 /status 요청 메서드가 동일합니다. GET
표현식 http.request.uri.path eq "/status" and http.request.method eq "GET"
계수 특성 헤더 (Referrer). 헤더 HTTP 이름은 의 철자를 틀리게 referrer 사용합니다.
요청률 (요청 수/기간) 10분당 100건의 요청
조치 블록

이 예시 규칙은 고급 속도 제한이 필요합니다.

신원 정보 도용 방지

속도 제한 기능을 사용하여 로그인 엔드포인트를 자격 증명 재사용 공격으로부터 보호할 수 있습니다. 크리덴셜 스터핑은 공격자가 자동화된 스크립트를 사용하여 로그인 양식에 여러 사용자 이름과 비밀번호 조합을 시도할 때 발생합니다. 속도 제한은 동일한 IP 주소에서 반복되는 실패한 로그인 시도를 제한함으로써 이러한 공격을 완화하는 데 도움이 됩니다.

다음 예시는 실패한 로그인 시도 횟수에 따라 제한과 처벌을 강화하는 세 가지 속도 제한 규칙을 보여줍니다.

규칙 1: 초기 보호 임계값

규칙 1은 분당 최대 4회의 로그인 실패 시도를 허용합니다. 한도를 초과하면 시스템이 관리형 도전을 트리거합니다. 이 설정은 합법적인 사용자가 가끔 발생하는 로그인 오류에서 복구할 수 있도록 돕는 동시에 자동화된 봇을 차단합니다.

규칙 1 구성
설정 값
일치 기준 호스트명이 와 example.com 같고 URI 경로가 와 /login 같고 요청 메서드가 와 같습니다. POST
표현식 http.host eq "example.com" and http.request.uri.path eq "/login" and http.request.method eq "POST"
계수 특성 IP
카운터를 증가시킬 때 URI 경로가 이고 /login 메서드가 이며 POST 응답 코드가 (401, 403) 범위에 속함
계수 표현 http.request.uri.path eq "/login" and http.request.method eq "POST" and http.response.code in {401 403}
요청률 (요청 수/기간) 4건의 요청 / 1분
조치 관리형 인증 확인

규칙 2: 중간 보호 기준

규칙 1의 속도 제한에 도달했을 때 정상 사용자가 인증 절차를 통과하면, 규칙 2는 계속해서 로그인 실패 시도를 하는 클라이언트에 대해 추가적인 보호 조치를 적용합니다. 10분 동안 최대 10회의 실패 시도가 허용되며, 이후 다시 관리형 인증 절차가 실행됩니다.

규칙 2 구성
설정 값
일치 기준 호스트명이 와 example.com 같고 URI 경로가 와 /login 같고 요청 메서드가 와 같습니다. POST
표현식 http.host eq "example.com" and http.request.uri.path eq "/login" and http.request.method eq "POST"
계수 특성 IP
카운터를 증가시킬 때 URI 경로가 와 /login 동일하고 요청 메서드가 와 POST 동일하며 응답 상태 코드가 (401, 403) 범위에 속함
계수 표현 http.request.uri.path eq "/login" and http.request.method eq "POST" and http.response.code in {401 403}
요청률 (요청 수/기간) 10건의 요청 / 10분
조치 관리형 인증 확인

규칙 3: 엄격한 보호 기준

규칙 3은 1시간 내 20회 로그인 실패 시 해당 IP 주소를 1일간 차단함으로써 규칙 2의 기준을 초과하는 클라이언트에 대해 더 강력한 제재를 가합니다. 이 규칙은 지속적인 공격 시도에 대한 최종 방어 수단을 제공합니다.

규칙 3 구성
설정 값
일치 기준 호스트는 동일하다 example.com
표현식 http.host eq "example.com"
계수 특성 IP
카운터를 증가시킬 때 URI 경로가 와 /login 동일하고 요청 메서드가 와 POST 동일하며 응답 상태 코드가 (401, 403) 범위에 속함
계수 표현 http.request.uri.path eq "/login" and http.request.method eq "POST" and http.response.code in {401 403}
요청률 (요청 수/기간) 1시간당 20건의 요청
조치 1일간 차단

이 모든 예시 규칙을 사용하려면 비즈니스 플랜 이상이 필요합니다.

이 세 가지 규칙은 규칙 표현(완화 표현이라고도 함)과 별개의 계산 표현을 가집니다. 별도의 카운팅 표현식을 구성할 경우, 해당 일치 기준은 액션이 트리거될 때 사용됩니다. 카운팅 표현식에서는 응답 상태 HTTP 코드 및 HTTP 응답 헤더를 기반으로 한 조건을 포함하여 백엔드 로직과 속도 제한을 통합할 수 있습니다.

또한 두 가지 다른 표현식(카운팅 표현식과 규칙/완화 표현식)을 정의하기로 선택할 수 있습니다

  1. 요율 계산에 사용된 요청들.
  2. 실제로 처리된 요청들.

예를 들어, 규칙 3 예시는 상태 코드 403HTTP 또는 401 를 반환한 에 /login 대한 요청을 POST 고려하여 비율을 계산합니다. 그러나 속도 제한을 초과할 경우, 동일한 IP에서 생성된 CISexample.com 호스트에 대한 모든 요청을 차단합니다.

작업 수 제한

클라이언트가 특정 시간 내에 수행하는 작업 수를 제어하기 위해 속도 제한을 사용할 수 있습니다. 구성하는 규칙은 애플리케이션의 동작 및 위험 프로필에 따라 달라집니다.

다음 예시는 콘텐츠 스크래핑 및 자동화된 활동을 방지하여 시스템 과부하나 데이터 오용을 막는 방법을 보여줍니다. 예를 들어 쿼리 문자열, JSON 본문 매개변수 또는 봇 특성에 따른 요청 제한 등이 있습니다.

쿼리 문자열을 사용하여 콘텐츠 스크래핑 방지

이 예시에서 클라이언트는 쿼리 문자열 매개변수를 통해 전자상거래 웹사이트에서 작업(예: 가격 조회 또는 장바구니에 상품 추가)을 수행합니다. 예를 들어, 클라이언트가 전송하는 일반적인 요청은 다음과 유사할 수 있습니다:

GET https://store.com/merchant?action=lookup_price&product_id=215
Cookie: session_id=12345

보안 팀에서는 봇(봇 관리 기능을 CIS 우회할 수 있는)이 매장 전체 카탈로그를 스크래핑하는 것을 방지하기 위해, 클라이언트가 가격을 조회할 수 있는 횟수에 제한을 설정하는 것을 고려해 볼 수 있습니다.

규칙 1 구성
설정 값
일치 기준 URI 경로가 동일하고 /merchant URI 쿼리 문자열에 포함됨 action=lookup_price
표현식 http.request.uri.path eq "/merchant" and http.request.uri.query contains "action=lookup_price"
계수 특성 IP
요청률 (요청 수/기간) 10개 요청 / 2분
조치 관리형 인증 확인
규칙 2 구성
설정 값
일치 기준 URI 경로가 동일하고 /merchant URI 쿼리 문자열에 포함됨 action=lookup_price
표현식 http.request.uri.path eq "/merchant" and http.request.uri.query contains "action=lookup_price"
계수 특성 IP
요청률 (요청 수/기간) 5분당 20건의 요청
조치 블록

이 두 속도 제한 규칙은 선택된 작업(이 예시에서는 가격 조회)을 수행하는 요청을 일치시키고, 카운팅 특성으로 IP 사용합니다. /login 예시와 마찬가지로, 이 두 규칙은 지속적으로 방문하지만 합법적인 방문자의 경우 오탐을 줄이는 데 도움이 됩니다.

쿼리 문자열 매개변수를 사용하여 product_id 특정 항목의 조회 범위를 제한할 수 있습니다. 쿼리 매개변수를 카운팅 특성으로 추가함으로써, 클라이언트와 무관하게 모든 요청에 걸쳐 비율이 계산됩니다.

다음 예시는 각 항목에 대한 조회 product_id 횟수를 10초 동안 50건으로 제한합니다.

쿼리 문자열을 통한 규칙 제한
설정 값
일치 기준 URI 경로가 일치함 /merchant
표현식 http.request.uri.path eq "/merchant"
계수 특성 쿼리 (product_id)
요청률 (요청 수/기간) 20개 요청 / 10초
조치 블록

이 예시 규칙은 고급 속도 제한이 필요합니다.

예약 및 예약 처리를 담당하는 애플리케이션을 보호하기 위해 동일한 속도 제한 규칙 패턴을 따를 수 있습니다.

요청 본문을 사용하여 콘텐츠 스크래핑 방지

요청 본문을 통해 JSON 형식으로 작업과 그 매개변수를 처리하는 애플리케이션을 고려해 보십시오. 예를 들어, lookup_price 연산은 다음과 같이 보일 수 있습니다:

POST https://api.store.com/merchant
Cookie: session_id=12345
Body:
{
  "action": "lookup_price",
  "product_id": 215
}

이 시나리오에서는 개별 세션의 작업 수를 제한하기 위해 다음과 같은 규칙을 생성할 수 있습니다:

규칙—세션당 조회 작업 제한
설정 값
일치 기준 URI 경로가 와 동일하고 JSON /merchant 문자열이 action 와 동일합니다. lookup_price
표현식 http.request.uri.path eq "/merchant" and lookup_json_string(http.request.body.raw, "action") eq "lookup_price"
계수 특성 쿠키 (session_id)
요청률 (요청 수/기간) 10개 요청 / 2분
조치 관리형 인증 확인

이 예시 규칙은 고급 속도 제한 및 페이로드 검사가 필요합니다.

다음과 같은 규칙을 배포함으로써 요청을 수행하는 클라이언트와 관계없이 product_id 각 항목의 조회 횟수를 제한할 수도 있습니다:

규칙—제품 ID별 조회 요청 제한
설정 값
일치 기준 URI 경로가 와 동일하고 JSON /merchant 필드가 와 action 동일합니다. lookup_price
표현식 http.request.uri.path eq "/merchant" and lookup_json_string(http.request.body.raw, "action") eq "lookup_price"
계수 특성 JSON 필드 (product_id)
요청률 (요청 수/기간) 50개 요청 / 10초
조치 블록

이 예시 규칙은 고급 속도 제한 및 페이로드 검사가 필요합니다.

요청 본문이 JSON 형식이 아닌 경우, 필드와 정규 표현식( matcheshttp.request.body.raw 연산자와 함께)을 사용하여 동일한 목표를 달성할 수 있습니다.

봇의 요청 제한

봇의 자동화된 트래픽을 제어하기 위해 속도 제한을 사용할 수 있습니다. 일반적인 접근 방식은 자동화된 스크래핑 활동을 나타내는 경우가 많은 또는 404 응답 상태 403 코드가 많이 반환되는 요청을 모니터링하는 것이다.

이 상황에서 다음과 유사한 규칙을 구성할 수 있습니다:

규칙—응답 상태 코드에 따라 요청 제한
설정 값
일치 기준 호스트명이 동일합니다 example.com
표현식 http.host eq "example.com"
계수 특성 IP
카운터를 증가시킬 때 응답 상태 코드는 (401, 403)입니다
계수 표현 http.response.code in {401 403}
요청률 (요청 수/기간) 5건의 요청 / 3분
조치 관리형 인증 확인

이 예시 규칙을 사용하려면 비즈니스 요금제 이상이 필요합니다.

자동화된 소스에 의해 수행되는 작업의 속도를 제어하려면, 봇 관리와 함께 사용률 제한 규칙을 적용하는 것을 고려하십시오. 봇 관리 기능을 사용하면 봇 점 수를 매칭 기준의 일부로 활용하여 자동화된 트래픽 또는 자동화 가능성이 높은 트래픽에만 규칙을 적용할 수 있습니다. 예를 들어, 자동화된 트래픽 가능성이 높은 경우 최대 점수(또는 임계값)를 30 로, 자동화된 트래픽의 경우 10 로 설정할 수 있습니다.

속도 제한을 봇 관리와 결합하여 보호 기능을 강화할 수 있습니다. 봇 관리 기능을 사용하면 봇 점 수를 매칭 기준의 일부로 활용하여 자동화된 트래픽 또는 자동화 가능성이 높은 트래픽에만 규칙을 적용할 수 있습니다.

예를 들어, 다음과 같습니다.

  • 봇 점수가 보다 낮은 30 경우 자동화된 트래픽일 가능성이 높습니다.
  • 봇 점수가 미만인 경우 확인된 10 자동화된 트래픽을 나타냅니다.

세션당 요청 수 제한

애플리케이션이 세션 쿠키를 사용하는 경우, 해당 쿠키를 카운팅 특성으로 사용하십시오. 이 방법은 서로 다른 IP에서 온 요청을 동일한 세션 내에 그룹화합니다—분산형 봇 공격 탐지에 유용합니다.

규칙 1

봇 점수가 30 미만인 경우 요청 제한
설정 값
일치 기준 봇 점수가 30 미만이고 URI 쿼리 문자열에 포함된 경우 action=delete
표현식 cis.bot_management.score lt 30 and http.request.uri.query contains "action=delete"
계수 특성 쿠키 (session_id)
요청률 (요청 수/기간) 10개 요청 / 1분
조치 관리형 인증 확인

규칙 2

봇 점수가 10 미만인 경우 요청 제한
설정 값
일치 기준 봇 점수가 10 미만이고 URI 쿼리 문자열에 포함된 경우 action=delete
표현식 cis.bot_management.score lt 10 and http.request.uri.query contains "action=delete"
계수 특성 쿠키 (session_id)
요청률 (요청 수/기간) 5분당 20건의 요청
조치 블록

이 예시 규칙들은 고급 속도 제한 및 봇 관리 기능을 필요로 합니다.

지문 JA3 사용

애플리케이션이 세션 쿠키를 사용하지 않는 경우, 개별 클라이언트를 식별하기 위해 지문을 JA3 사용할 수 있습니다. 지문 은 JA3 Bot Management를 사용하는 고객에게 제공되는 고유 식별자로, 동일한 클라이언트에서 오는 요청을 식별할 수 CIS 있게 합니다. 모든 클라이언트는 자동화 여부와 관계없이 연관된 지문을 가지고 있습니다.

지문 인증을 JA3 사용하여 요청 제한
설정 값
일치 기준 URI 경로가 동일하고 /merchant 봇 점수가 10 미만인 경우
표현식 http.request.uri.path eq "/merchant" and cf.bot_management.score lt 10
계수 특성 JA3 지문
요청률 (요청 수/기간) 10개 요청 / 1분
조치 관리형 인증 확인

이 예시 규칙은 고급 속도 제한 및 봇 관리 기능을 필요로 합니다.

REST API 보호

REST API는 API 요청이 종종 집중적인 처리나 대용량 데이터 조회 작업을 필요로 하기 때문에 백엔드 시스템에 높은 부하를 발생시킬 수 있습니다. 통제되지 않은 API 접근은 성능 저하 또는 서비스 중단을 초래할 수 있습니다. 고급 속도 제한을 사용하여 악용을 방지하고, 대량 공격을 완화하며, 중요한 자원을 보호하십시오.

리소스 보호

대용량 데이터(예: 파일이나 이미지)를 다운로드하는 데 사용될 경우, 요청 GET 자체도 애플리케이션에 부담을 주거나 대역폭을 소모할 수 있습니다.

예를 들어, 다음 엔드포인트를 고려해 보십시오:

GET https://api.store.com/files/<FILE_ID>
Header: x-api-key=9375

정당한 다운로드는 허용하면서 악용을 방지하기 위해, 각 파일에 대해 별도의 규칙을 작성하지 않고도 파일 요청을 제한하는 규칙을 정의할 수 있습니다.

규칙 — 경로별 파일 다운로드 제한
설정 값
일치 기준 호스트명이 와 api.example.com 동일하고 요청 메서드가 와 동일합니다. GET
표현식 http.host eq "api.example.com" and http.request.method eq "GET"
계수 특성 경로
요청률 (요청 수/기간) API 탐색을 통해 제안되거나, 과거 트래픽 분석을 통해 평가된 대로.
조치 블록

이 예시 규칙은 고급 속도 제한이 필요합니다.

이 규칙은 파일당 10분 동안 다운로드 https://api.store.com/files/* 요청을 10회로 제한합니다. 경로를 카운팅 특성으로 사용함으로써, 새로운 <FILE_ID>.마다 새로운 규칙을 생성하는 것을 피할 수 있습니다. 요금은 클라이언트 IP 또는 세션 ID와 무관하게 파일당 기준으로 계산됩니다.

클라이언트 식별자(예: x-api-key 또는 IP)와 Path 결합하여 보호 기능을 더욱 강화할 수 있습니다. 이 접근 방식은 특정 클라이언트가 주어진 파일에 대해 수행할 수 있는 다운로드 횟수를 제한할 수 있게 합니다.

규칙 — 경로 및 헤더로 파일 다운로드 제한
설정 값
일치 기준 호스트명이 와 api.store.com 동일하고 요청 메서드가 와 동일합니다. GET
표현식 http.host eq "api.example.com" and http.request.method eq "GET"
계수 특성 경로 및 헤더 (x-api-key)
요청률 (요청 수/기간) API 탐색을 통해 제안되거나, 과거 트래픽 분석을 통해 평가된 대로.
조치 블록

이 예시 규칙은 고급 속도 제한이 필요합니다.

API GraphQL 보호

API의 GraphQL 서버 과부하 방지는 RESTful API의 과부하 방지 방식과 다를 수 있습니다. 애플리케이션이 구축되는 방식에서 발생하는 가장 큰 문제점 중 하나는 단일 경로가 서버로의 모든 쿼리를 관리하며 GraphQL, 각 요청은 일반적으로 단일 POST 작업(single operation)이라는 점이다. 이는 HTTP 메서드와 URI 경로에 따라 서로 다른 API에 대해 서로 다른 속도 제한을 생성하는 것을 방지합니다.

그러나 RESTful API처럼 메서드와 경로를 사용하는 대신, 요청의 목적은 일반적으로 본문에 포함됩니다. 본문에는 클라이언트가 가져오거나 변경(서버 측 데이터 수정에 대한 GraphQL's 용어에 따름)하려는 데이터에 대한 정보와 함께 작업을 수행하는 데 필요한 추가 데이터가 포함됩니다.

서버 과부하를 방지하려면 다음 접근 방식을 고려하십시오:

  • 특정 사용자가 동일한 GraphQL 작업 이름을 호출할 수 있는 횟수를 제한합니다.
  • 사용자가 요청할 수 있는 쿼리 복잡도의 총량을 제한합니다.
  • 개별 요청의 쿼리 복잡도를 제한하십시오.

다음 예시는 영화 리뷰를 접수하는 애플리케이션을 기반으로 합니다.

POST https://moviereviews.example.com/graphql
Cookie: session_id=12345
Body:
{
  "data": {
    "createReview": {
      "stars": 5,
      "commentary": "This is a great movie!"
    }
  }
}

작업 수 제한

작업 속도를 제한하려면 다음 규칙을 생성하십시오:

작업 횟수를 제한하십시오
설정 값
일치 기준 URI 경로가 일치하고 /graphql 본문에는 포함됨 createReview
표현식 http.request.uri.path eq "/graphql" and http.request.body.raw contains "createReview"
계수 특성 쿠키 (session_id)
요청률 (요청 수/기간) 5건 요청 / 1시간
조치 블록

이 예시 규칙은 고급 속도 제한 및 페이로드 검사가 필요합니다.

쿼리 복잡도의 총량 제한

요청 GraphQL 처리의 복잡성은 크게 달라질 수 있습니다. API가 단일 엔드포인트를 사용하기 때문에, 각 요청이 처리되기 전에 그 복잡성을 판단하기 어려울 수 있습니다.

원본 서버의 자원 고갈을 방지하기 위해, 요청 횟수를 제한하기보다는 시간 경과에 따른 클라이언트당 총 요청 복잡도를 제한하십시오. CIS 속도 제한을 통해 시간 경과에 따른 복잡성을 추적하고 정의된 복잡성 예산을 초과하는 요청을 차단하는 규칙을 생성할 수 있습니다.

이 방법은 원본 서버가 각 요청에 복잡도 점수를 할당하고 해당 점수를 응답 HTTP 헤더에 포함하도록 요구합니다. 속도 제한 메커니즘은 점수 정보를 활용하여 해당 클라이언트의 복잡도 예산을 업데이트합니다.

다음 예시는 시간당 총 복잡도 예산을 1,000으로 정의합니다:

쿼리 복잡도의 총량을 제한하십시오
설정 값
일치 기준 URI 경로에는 포함됩니다 /graphql
표현식 http.request.uri.path eq "/graphql"
계수 특성 쿠키 (session_id)
기간별 점수 1,000
마침표 1시간
응답 헤더 이름 score
조치 블록

이 예시 규칙은 고급 속도 제한 및 페이로드 검사가 필요합니다.

원본 서버가 요청을 처리할 때, 해당 요청을 처리하기 위해 원본 서버가 수행한 작업량을 나타내는 값을 가진 scoreHTTP 헤더를 응답에 추가합니다. 예를 들어, 100입니다. 다음 1시간 동안 동일한 클라이언트는 최대 추가 예산. 900 까지 요청을 수행할 수 있습니다. 이 예산을 초과하는 즉시, 이후 요청은 타임아웃이 만료될 때까지 차단됩니다.

개별 쿼리의 복잡성 제한

API Shield 고객은 악성 쿼리 보호 GraphQL 기능을 사용하여 API를 GraphQL 보호할 수 있습니다. 이 기능은 원본 서버에 과부하를 일으켜 서비스 거부 상태를 유발할 수 있는 쿼리를 수신 GraphQL 트래픽에서 스캔합니다.

들어오는 GraphQL 쿼리의 깊이와 크기를 제한하는 규칙을 생성할 수 있습니다. 이러한 규칙은 성능에 영향을 미치기 전에 의심스럽거나 지나치게 복잡한 쿼리를 차단하는 데 도움이 됩니다.