한 요청에 서로 다른 질문이 존재한다
API 키(API key)는 사용량 계획(usage plan)에서 호출 클라이언트를 구별하고 키별 요청량을 제한하는 식별 수단이다. 요청자가 누구인지 확인하는 인증(authentication)과, 그 요청자가 특정 테넌트(tenant)의 문서를 읽어도 되는지 판단하는 인가(authorization)는 별도 절차다. API 키로 인증이나 인가를 대신하지 않고 IAM 역할(role), Lambda 권한 부여자(Lambda authorizer), Cognito 사용자 풀(user pool) 등 적절한 방식을 사용한다.
따라서 생성형 AI(generative AI, GenAI) API 요청에 키가 있다는 사실만으로 문서 접근을 허용해서는 안 된다. 고객사별 키로 사용량을 구분하더라도 실제 사용자 신원을 확인하고, 요청한 문서와 기능의 접근 권한을 처리 단계에서 검사한다. 앱이 Amazon Bedrock을 호출하는 IAM 역할의 권한과 최종 사용자의 업무 권한도 다르다. 백엔드가 모델을 사용할 수 있어도 사용자가 모든 고객 문서를 읽을 수 있는 것은 아니다.
할당량과 요청 조절은 초과 요청의 완전한 차단을 보장하지 않는다
사용량 계획의 조절(throttling)과 할당량(quota)은 best-effort 방식이므로 클라이언트가 설정값을 넘을 수 있다. 따라서 하루 N회로 설정해도 N+1번째 요청이 반드시 거부되거나 예산을 넘는 요금이 절대 발생하지 않는다고 보장할 수는 없다. 제한값을 설정하는 것과 초과 요청을 빠짐없이 차단하는 것은 다르다.
AWS Budgets는 비용을 모니터링하고, AWS WAF는 API 요청을 관리하는 데 도움을 준다. 두 서비스를 연결하는 것만으로 정확한 비용 상한이 보장되지는 않는다. 업무상 사용량을 엄격하게 제한해야 한다면 앱에서 사용량 확인과 예약을 원자적(atomic)으로 처리하고, 완료 후 정산과 실패 처리를 설계할 수 있다. 이는 별도로 구현하고 검증할 방법이지 사용량 계획의 내장 기능이라는 뜻은 아니다.
제약과 예외
- 적용 범위는 이 문서의 REST API 사용량 계획이다. HTTP API/WebSocket API의 기능·보안 방식으로 자동 확장하지 않는다.
- 요청 조절(throttling)·할당량(quota)은 사용량 계획(usage plan)에 연결된 모든 API 단계(stage)의 요청을 합산해 키별로 적용된다. 따라서 키를 나누거나 공유하는 방식에 따라 집계되는 사용량이 달라진다.
- 키 하나는 여러 계획과 연결할 수 있지만 같은 API 단계에 대해서는 하나의 계획에만 연결할 수 있다.
- 같은 계획의 다른 API에 대한 유효 키가 있다는 이유로 민감 API 권한까지 맡기지 않는다. 공식 모범 사례가 이 범위 문제를 직접 경고한다.
- 키에는 기밀 내용을 넣지 않는다. 요청 헤더가 로깅될 수 있다. 이름이 달라도 값이 같으면 같은 키로 인식된다는 문서 조건도 키 관리에 적용한다.
- API 키(API key)를 사용량 계획(usage plan)에 추가해도 반영에 몇 분이 걸릴 수 있다. 추가 즉시 모든 요청에 적용된다고 가정해 시험하거나 접근 차단을 설계하지 않는다.
적용 범위: 위 제약과 예외를 적용 대상의 현재 공식 문서와 대조한다. 이 해설은 API 실행 성공이나 법적 준수를 보증하지 않는다.
공식 출처와 이어 읽기
용어 확인: 생성형 AI(generative AI, GenAI).