할당량 및 한도

이 페이지에는 ID 및 액세스 관리(IAM)에 적용되는 할당량과 한도가 나와 있습니다. 할당량과 한도는 전송할 수 있는 요청 수 또는 생성할 수 있는 리소스 수를 제한할 수 있습니다. 한도는 리소스 식별자의 길이 등 리소스의 속성도 제한할 수 있습니다.

할당량이 필요한 양보다 적다면 Google Cloud 콘솔을 사용하여 프로젝트의 할당량 상향을 요청할 수 있습니다. Google Cloud 콘솔에서 특정 할당량 변경을 요청할 수 없는 경우 Google Cloud 지원팀에 문의하세요.

한도는 변경할 수 없습니다.

할당량

기본적으로 다음 IAM 할당량은 직원 ID 제휴 할당량을 제외한 모든 Google Cloud 프로젝트에 적용됩니다. 직원 ID 제휴 할당량은 조직에 적용됩니다.

기본 할당량
IAM API
읽기 요청(예: 정책 가져오기) 분당 6,000
쓰기 요청(예: 정책 업데이트) 분당 600
워크로드 아이덴티티 제휴
읽기 요청(예: 워크로드 아이덴티티 풀 가져오기) 프로젝트별 분당 600
클라이언트당 분당 6,000
쓰기 요청(예: 워크로드 아이덴티티 풀 업데이트) 프로젝트별 분당 60
클라이언트당 분당 600
직원 ID 제휴(미리보기)
만들기/삭제/삭제 취소 요청 조직별 분당 60개
읽기 요청(예: 직원 ID 풀 가져오기) 조직별 분당 120개
업데이트 요청 (예: 직원 ID 풀 업데이트) 조직별 분당 120개
주체 삭제/삭제 취소 요청 (예: 직원 ID 풀 주체 삭제) 조직별 분당 60개
조직당 직원 ID 풀 100
Service Account Credentials API
사용자 인증 정보 생성 요청 분당 60,000
JSON 웹 토큰(JWT) 또는 blob 서명 요청 분당 60,000
보안 토큰 서비스 API
교환 토큰 요청(비직원 ID 제휴) 분당 6,000
교환 토큰 요청(직원 ID 제휴)(미리보기) 조직별 분당 60,000개
서비스 계정
서비스 계정 수 100

한도

IAM은 리소스에 다음 한도를 적용합니다. 이러한 한도를 변경할 수 없습니다.

한도
커스텀 역할
조직의 커스텀 역할1 300
프로젝트의 커스텀 역할1 300
커스텀 역할의 ID 64바이트
커스텀 역할 제목 100바이트
커스텀 역할 설명 300바이트
커스텀 역할의 권한 3,000
커스텀 역할 제목, 설명, 권한 이름의 총 크기 64KB
정책 및 역할 바인딩 허용
리소스별 허용 정책 1
단일 허용 정책 내 모든 역할 바인딩의 도메인 및 Google 그룹2 250
단일 정책 내 모든 역할 바인딩 및 감사 로깅 예외의 총 주 구성원(도메인 및 Google 그룹 포함) 수3 1,500명
역할 바인딩 조건 표현식의 논리 연산자 12
동일한 역할과 주 구성원이 있지만 조건 표현식이 다른 허용 정책의 역할 바인딩 20
거부 정책 및 거부 규칙
리소스별 거부 정책 500
리소스별 거부 규칙 500
모든 리소스의 거부 정책에 있는 도메인 및 Google 그룹4 500
모든 리소스의 거부 정책에 있는 주 구성원의 총 개수(도메인 및 Google 그룹 포함)4 2500
단일 거부 정책의 거부 규칙 500
거부 규칙 조건 표현식의 논리 연산자 12
서비스 계정
서비스 계정 ID 30바이트
서비스 계정 표시 이름 100바이트
서비스 계정의 서비스 계정 키 10
직원 ID 제휴(미리보기)
풀당 직원 ID 풀 공급업체 200
풀당 직원 ID 풀 주체 삭제 100,000
워크로드 아이덴티티 제휴 및 직원 ID 제휴(미리보기) 속성 매핑
매핑된 주체 127바이트
매핑된 직원 ID 풀 사용자 표시 이름 100바이트
매핑된 속성 총 크기 8,192바이트
맞춤 속성 매핑 수 50
단기 사용자 인증 정보
사용자 인증 정보 액세스 경계의 액세스 경계 규칙입니다. 10
액세스 토큰의 최대 수명5

3,600초(1시간)

1 프로젝트 수준에서 만든 커스텀 역할은 조직 수준의 한도 계산에 포함되지 않습니다.

2 이러한 한도에서 도메인 및 Google 그룹은 다음과 같이 계산됩니다.

  • 도메인의 경우 IAM은 허용 정책의 역할 바인딩에서 각 도메인의 모든 등장을 계산합니다. 2개 이상의 역할 바인딩에 나타난 도메인을 중복 삭제하지 않습니다. 예를 들어 허용 정책에 domain:example.com 도메인만 포함되어 있고 도메인이 허용 정책에 10번 표시되면 제한에 도달하기 전에 다른 240개의 도메인을 추가할 수 있습니다.
  • Google 그룹의 경우 각 고유 그룹은 허용 정책에 그룹이 표시된 횟수와 관계없이 한 번만 계산됩니다. 예를 들어 허용 정책에 group:my-group@example.com라는 그룹만 포함되어 있고 그룹이 허용 정책에 10번 표시되면 제한에 도달하기 전에 249개의 다른 고유 그룹을 추가할 수 있습니다.

3 이 한도의 목적에 따라 IAM은 허용 정책의 역할 바인딩에서 각 주 구성원뿐 아니라 허용 정책이 데이터 액세스 감사 로깅에서 제외되는 주 구성원의 모든 등장을 카운트합니다. 2개 이상의 역할 바인딩에 나타난 주 구성원을 중복 삭제하지 않습니다. 예를 들어 허용 정책에 group:my-group@example.com 주 구성원에 대한 역할 바인딩만 포함되어 있고 이 주 구성원이 50개의 역할 바인딩에 나타난 경우 허용 정책에서 다른 1,450명의 주 구성원을 역할 바인딩에 추가할 수 있습니다.

IAM 조건을 사용하거나 매우 긴 식별자가 있는 여러 주 구성원에게 역할을 부여하면 IAM에서 정책의 주 구성원을 더 적게 허용할 수 있습니다.

4 IAM은 리소스에 연결된 모든 거부 정책에서 각 주 구성원의 모든 노출을 집계합니다. 2개 이상의 거부 규칙 또는 거부 정책에 표시되는 주 구성원은 중복 삭제하지 않습니다. 예를 들어 리소스에 연결된 거부 정책에 user:alice@example.com 주 구성원에 대한 거부 규칙만 포함되었고 이 주 구성원이 20개의 거부 규칙에 표시된 경우에는 리소스의 거부 정책에 다시 2,480개의 주 구성원을 추가할 수 있습니다.

5OAuth 2.0 액세스 토큰의 경우 최대 수명을 12시간(43,200초)까지 연장할 수 있습니다. 최대 수명을 확장하려면 토큰의 수명을 연장해야 하는 서비스 계정을 식별한 다음 constraints/iam.allowServiceAccountCredentialLifetimeExtension 목록 제약조건을 포함하는 조직 정책에 이러한 서비스 계정을 추가합니다.