Bedrock으로 Claude를 쓰면 프롬프트가 Anthropic에 전달되나?

AWS 문서 기준으로 모델 제공사는 Bedrock의 모델 배포 계정에 접근할 수 없어 고객 프롬프트와 응답을 보지 못하고, 콘텐츠는 제공사와 공유되지 않는다. 다만 Claude Fable 5와 5.1은 오남용 탐지를 위해 모든 트래픽을 AWS가 최대 30일 보관하고, 분류기에 걸린 트래픽은 AWS가 사람이 검토할 수 있다. 일부 OpenAI 모델도 분류기에 걸린 트래픽을 최대 30일 보관한다. Enterprise Frontier Safeguards 프로그램 대상 고객은 2026년 12월 31일까지 ZDR이고, 이후에는 같은 30일 보관이 적용된다. Claude 모델의 ZDR 자격은 Anthropic이 관리한다.

Bedrock API 키는 운영 환경에서 써도 되나?

단기 키는 써도 된다. 최대 12시간 유효하고 만든 IAM 주체의 권한을 물려받으며 AWS가 운영용으로 권장한다. 장기 키는 IAM 사용자를 만들어 붙이는 방식이고 탐색용으로만 권장되므로, bedrock:bearerTokenType과 bedrock-mantle:bearerTokenType 조건 키로 LONG_TERM 사용을 막아 두는 것을 권한다.

Bedrock에서 웹 검색이나 코드 실행 도구를 쓸 수 있나?

Anthropic의 서버사이드 도구인 코드 실행, 웹 검색, 웹 페치, advisor는 Bedrock에서 지원하지 않는다. 이 기능이 필요하면 클라이언트 쪽 도구로 직접 구현하거나 직접 API를 검토한다.

AWS Bedrock을 쓰는 이유

AWS 위에서 서비스를 운영하는 팀에 있으면 'Claude 쓰고 싶은데 Anthropic 키 하나 받아서 쓰면 안 되냐'는 질문을 자주 받는다. 반대로 보안팀이나 재무팀에서는 'Bedrock으로 하면 안 되냐'는 말이 먼저 나온다. 양쪽 얘기를 다 들어보면 같은 모델을 어느 문으로 부르느냐의 문제라서, 판단 기준을 한 번 정리해 둔다.

이미 AWS를 쓰는 조직이 Bedrock을 고르는 이유는 모델이 더 좋아서가 아니다. IAM, CloudTrail, VPC, 통합 청구, 리전 통제처럼 이미 굴리고 있는 AWS 운영 체계 안에서 모델 호출을 관리할 수 있어서다. 그 대가로 직접 API에 먼저 나오는 기능이 늦게 오거나 빠지는 부분을 받아들여야 한다. 최신 기능이 제품의 핵심이라면 직접 API나 Claude Platform on AWS가 맞다.

1. 개요

Amazon Bedrock은 여러 회사의 기반 모델을 AWS API 하나로 호출하게 해주는 관리형 서비스다. Anthropic, OpenAI, Meta, Mistral, Cohere 같은 제공사의 모델이 같은 엔드포인트 체계에 올라와 있고, 인증과 과금은 AWS 계정으로 처리된다.

직접 API는 반대다. Anthropic이나 OpenAI에 따로 가입하고, 거기서 발급받은 키로 그 회사 엔드포인트를 부른다. 모델 자체는 같아도 권한, 로그, 청구가 전부 AWS 바깥에 생긴다.

차이가 드러나는 건 모델을 처음 붙일 때다. 사내 챗봇 하나를 붙이려 해도 보안 검토에서 '키는 누가 갖고 있나, 퇴사자 키는 어떻게 회수하나, 누가 토큰을 얼마나 썼나, 프롬프트는 어느 나라에서 처리되나'를 바로 묻는다.

먼저 볼 것은 이 질문들에 지금 무엇으로 답하고 있느냐다. EC2나 S3 접근을 IAM 역할로 주고, CloudTrail로 감사하고, 비용을 AWS 청구서로 받고 있다면 Bedrock은 그 답을 그대로 재사용한다. 직접 API로 가면 같은 답을 따로 하나 더 만들어야 한다.

선택지는 세 가지다. Amazon Bedrock은 AWS가 운영하고 IAM으로 인증하며 AWS 청구서로 정산된다. Claude API나 OpenAI API 같은 직접 API는 제공사가 운영하고 제공사 키로 인증하며 제공사가 청구한다. 마지막으로 Claude Platform on AWS는 Anthropic이 운영하되 청구는 AWS Marketplace로 받는다.

2. 권한은 IAM으로 관리한다

Bedrock 호출 권한은 IAM 정책으로 준다. 애플리케이션이 EKS 파드나 Lambda에서 돈다면 이미 붙어 있는 역할에 bedrock:InvokeModel 같은 액션만 추가하면 된다. 별도 비밀 키를 Secrets Manager에 넣고 돌려가며 교체할 일이 없다.

IAM 서명(SigV4)을 쓰기 어려운 도구를 위해 Bedrock API 키도 있다. 두 종류가 있고 성격이 꽤 다르다.

단기 키

키를 만든 IAM 주체의 권한을 그대로 물려받고, 최대 12시간(또는 세션 만료 중 짧은 쪽)까지 유효하다. AWS 문서가 운영 환경용으로 권장하는 쪽이 이것이다.

장기 키

내부적으로 IAM 사용자를 하나 만들고 그 사용자에 키를 붙인다. 문서에는 탐색용으로만 쓰라고 적혀 있다. 이런 키는 개인 노트북이나 CI 변수에 흩어지기 쉬우니 계정 차원에서 막아 두는 쪽을 권한다.

장기 키 사용을 막는 정책은 bedrock:CallWithBearerToken 액션과 bedrock:bearerTokenType 조건 키로 쓴다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLongTermBedrockKeys",
      "Effect": "Deny",
      "Action": "bedrock:CallWithBearerToken",
      "Resource": "*",
      "Condition": {
        "StringEquals": { "bedrock:bearerTokenType": "LONG_TERM" }
      }
    },
    {
      "Sid": "DenyLongTermMantleKeys",
      "Effect": "Deny",
      "Action": "bedrock-mantle:CallWithBearerToken",
      "Resource": "*",
      "Condition": {
        "StringEquals": { "bedrock-mantle:bearerTokenType": "LONG_TERM" }
      }
    }
  ]
}

API 키를 전부 막고 SigV4만 허용하려면 조건 없이 bedrock:CallWithBearerToken을 Deny 하면 된다. 위 예시처럼 bedrock-mantle 엔드포인트는 액션과 조건 키가 따로 있어서 문장을 하나 더 넣어야 한다.

일단 단기 키를 하나 만들어서 Converse API를 curl로 불러 본다. 토큰 생성기는 기본 자격 증명 체인(~/.aws/credentials, 인스턴스 역할 등)을 쓴다.

$ pip install aws-bedrock-token-generator
$ export AWS_BEARER_TOKEN_BEDROCK=$(python3 -c 'from aws_bedrock_token_generator import provide_token; print(provide_token())')

$ curl -s -X POST \
  "https://bedrock-runtime.us-east-1.amazonaws.com/model/us.anthropic.claude-sonnet-4-6/converse" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $AWS_BEARER_TOKEN_BEDROCK" \
  -d '{"messages":[{"role":"user","content":[{"text":"Hello"}]}]}' \
  | jq '{text: .output.message.content[0].text, stop: .stopReason, usage: .usage}'

응답에서 모델 답변은 output.message.content에, 입출력 토큰 수는 usage에 들어온다. 키는 Authorization 헤더로 가기 때문에 CloudTrail에 키 값이 남지는 않지만, API 호출 자체는 CloudTrail에 기록된다.

처음 붙일 때 걸리기 쉬운 게 모델 ID다. 위처럼 InvokeModel과 Converse 경로로 부르는 Claude는 최근 모델일수록 기본 모델 ID로 온디맨드 호출이 안 되고, us., eu., global. 같은 접두어가 붙은 추론 프로파일 ID로 불러야 한다. 기본 ID를 넣으면 HTTP 400과 함께 이런 메시지가 나온다.

Invocation of model ID anthropic.claude-sonnet-4-5-20250929-v1:0 with on-demand throughput isn't supported. Retry your request with the ID or ARN of an inference profile that contains this model.

메시지가 시키는 대로 앞에 us.나 global.을 붙이면 넘어간다.

Opus 4.7 이후 모델은 호출 경로가 하나 더 있다. Anthropic 문서 기준으로 bedrock-mantle.{region}.api.aws/anthropic/v1/messages 엔드포인트에서 Anthropic 직접 API와 같은 Messages API 형태로 부르고, 모델 ID는 anthropic.claude-opus-5-5처럼 접두어가 없다. 어느 엔드포인트로 부르느냐에 따라 아래의 호출 로깅 범위와 지원 기능이 달라진다.

3. 호출 감사는 CloudTrail과 호출 로깅으로 한다

누가 언제 어떤 모델을 불렀는지는 CloudTrail에 남는다. 다만 CloudTrail에는 프롬프트와 응답 본문이 없다. 본문까지 남기려면 모델 호출 로깅(invocation logging)을 켜야 하고, 이건 기본값이 꺼짐이다.

호출 로깅은 요청과 응답 본문, 메타데이터를 같은 계정, 같은 리전의 CloudWatch Logs나 S3로 보낸다. 본문이 100KB를 넘으면 S3에 별도 객체로 떨어진다. CloudWatch Logs로 보내려면 로그 그룹과 Bedrock이 맡을 IAM 역할을 먼저 만들어 두고 설정한다.

$ aws logs create-log-group --log-group-name /bedrock/invocations --region us-east-1
$ aws logs put-retention-policy --log-group-name /bedrock/invocations \
    --retention-in-days 30 --region us-east-1

$ aws bedrock put-model-invocation-logging-configuration --region us-east-1 \
  --logging-config '{
    "cloudWatchConfig": {
      "logGroupName": "/bedrock/invocations",
      "roleArn": "arn:aws:iam::123456789012:role/BedrockInvocationLogging"
    },
    "textDataDeliveryEnabled": true
  }'

$ aws bedrock get-model-invocation-logging-configuration --region us-east-1

Anthropic은 최소 30일 롤링으로 활동 로그를 남기라고 권한다. 위에서 보존 기간을 30일로 건 이유다. 감사 요건이 더 길면 그에 맞춰 늘린다.

로그 항목에는 호출 주체의 identity.arn이 자동으로 들어간다. 그래서 별도 태깅 없이도 역할이나 사용자별 토큰 사용량을 CloudWatch Logs Insights로 뽑을 수 있다.

fields identity.arn as principal,
       input.inputTokenCount as inTokens,
       output.outputTokenCount as outTokens
| stats sum(inTokens) as totalInput,
        sum(outTokens) as totalOutput,
        count() as calls
        by principal
| sort totalInput desc

결과는 호출 주체(역할 ARN)별 입력 토큰 합계, 출력 토큰 합계, 호출 수가 입력 토큰이 많은 순서대로 나온다.

팀이나 기능 단위로 나누고 싶으면 호출할 때 requestMetadata에 태그를 붙인다. 로그에서 호출자가 직접 채우는 필드는 이것 하나뿐이다.

함정이 하나 있다. 호출 로깅은 bedrock-runtime 엔드포인트 호출만 잡는다. 같은 API라도 bedrock-mantle 엔드포인트로 부르면 현재는 로그에 안 남는다. 로그가 비어 있는데 청구는 나온다면 어느 엔드포인트로 부르고 있는지부터 확인한다.

호출 로그에는 프롬프트 원문이 그대로 들어간다는 점도 알아 둔다. 로그 그룹이나 버킷 접근 권한을 애플리케이션 로그보다 좁게 잡아야 한다.

4. 네트워크와 리전을 AWS 안에서 통제한다

VPC 안의 워크로드라면 PrivateLink 인터페이스 엔드포인트로 Bedrock을 붙여 인터넷을 거치지 않게 할 수 있다. 고객 관리형 KMS 키 암호화, FIPS 140-3 엔드포인트도 쓸 수 있다. 규정 쪽으로는 SOC, ISO, HIPAA 적격, GDPR, CSA STAR Level 2가 Bedrock FAQ에 올라 있다. 이미 AWS 계정 단위로 받아 둔 감사 자료에 Bedrock을 얹어 설명할 수 있다는 게 실무에선 꽤 크다.

리전은 교차 리전 추론 프로파일로 정한다. 요청을 받은 리전 말고 다른 리전에서도 처리할 수 있게 해주는 장치이고, 두 종류가 있다.

지리 단위 프로파일

us., eu., apac. 같은 접두어가 붙는다. 해당 지리 안의 리전에서만 처리되기 때문에 데이터 상주 요건이 있을 때 쓴다.

글로벌 프로파일

global. 접두어다. 전 세계 상업 리전 중 여유 있는 곳으로 보낸다. Claude Sonnet 4.5 이후 모델은 지리 단위(리전) 엔드포인트가 글로벌보다 10% 비싸다. 상주 요건이 없으면 글로벌을 쓴다.

라우팅 자체에 추가 요금은 없고 가격은 호출한 리전 기준이다. 교차 리전 트래픽은 AWS 네트워크를 벗어나지 않고 암호화된다. 실제로 어느 리전에서 처리됐는지는 CloudTrail 이벤트의 additionalEventData.inferenceRegion에 찍힌다.

"additionalEventData": {
    "inferenceRegion": "us-west-2"
}

조직에서 SCP로 리전을 막아 두었다면 여기서 한 번 막힌다. 지리 단위 프로파일은 대상 리전들이 SCP에서 허용돼 있어야 하고, 글로벌 프로파일은 aws:RequestedRegion 값 "unspecified"를 허용해야 한다. 호출 리전은 열어 놨는데 AccessDenied가 난다면 이 부분을 본다.

5. 프라이버시가 이유라면 보관 예외부터 확인한다

'Bedrock은 데이터가 안 남으니까'라는 근거는 절반만 맞다.

기본 원칙은 이렇다. AWS 문서 기준으로 모델 제공사는 모델이 배포된 AWS 측 계정에 접근할 수 없어 Bedrock 로그나 고객 프롬프트를 볼 수 없다. 입력은 기반 모델 개선에 쓰이지 않고 제공사와 공유되지 않는다. Bedrock은 운영자 무접근(ZOA)과 무보관(ZDR) 모델이라 기본적으로 입출력을 저장하지 않는다.

그런데 같은 abuse detection 문서에 예외가 적혀 있다.

OpenAI GPT-5.4, GPT-5.5, GPT-5.6 Sol/Terra/Luna, GPT-6 Astra/Sol/Luna 등은 분류기에 걸린 트래픽을 오남용 탐지용으로 최대 30일 보관한다.
Anthropic Claude Fable 5와 Fable 5.1은 모든 트래픽을 최대 30일 보관하고, 분류기에 걸린 트래픽은 AWS가 사람이 검토할 수 있다.

보관된 데이터는 AWS가 저장하고 처리하며 제3자 모델 제공사와는 공유되지 않는다. 교차 리전 추론을 켜면 보관 데이터는 요청이 처리된 대상 리전에 저장된다. 글로벌 프로파일과 이 모델들을 같이 쓰면 보관 위치가 어디가 될지 모른다는 뜻이라, 상주 요건이 있는 조직은 여기서 걸린다.

Fable 5 계열에는 예외 프로그램이 하나 있다. AWS 문서에 따르면 Enterprise Frontier Safeguards 프로그램 대상 고객은 2026년 12월 31일까지 ZDR을 받고, 그 뒤에는 모든 트래픽이 최대 30일 보관되는 방식으로 바뀐다. 완전한 ZDR 요청 경로는 모델마다 다르다. OpenAI 모델은 AWS 계정팀에 요청하고, Claude 모델의 ZDR 자격은 Anthropic이 관리하므로 Anthropic 계정 담당자에게 문의해야 한다. 그러니 'Bedrock이면 무조건 ZDR'은 틀린 말이다.

이 보관 동작은 AWS의 Data retention 문서 기준으로 리전별로 계정이나 프로젝트 수준의 data_retention_mode로 제어한다. 값은 none, default, aws_review, inherit이고 레거시 값으로 provider_data_share가 있다. 출시 시점 기준 콘솔 UI는 없고 API로 설정한다.

none으로 두면 보관이 필요한 모델 호출은 차단되고 오류가 난다. 반대로 Fable 5와 5.1은 aws_review 이상이어야 호출되기 때문에, 기본 모드에서 부르면 bedrock-runtime에서는 ValidationException, bedrock-mantle에서는 unavailable이 돌아온다. 새 모델로 갈아탔더니 권한도 쿼터도 멀쩡한데 ValidationException이 난다면 이 설정을 먼저 의심한다. Fable 5 이전에 나온 Claude 모델은 보관 정책 변경이 없다.

조직 전체에 정책을 강제하려면 SCP나 IAM 정책에서 조건 키를 쓴다. bedrock-runtime 쪽 계정 설정은 bedrock:DataRetentionMode, bedrock-mantle 쪽 계정과 프로젝트 설정은 bedrock-mantle:DataRetentionMode로 막아야 하므로 두 키를 함께 건다. 보안팀이 SCP로 허용 모드를 고정하고 개별 계정은 그 안에서만 바꾸게 하는 구성이 가능하다.

6. 청구와 용량을 AWS 계약 구조로 묶는다

Bedrock 모델 단가가 직접 API보다 싸다는 근거는 없다. 비용 쪽 이점은 단가가 아니라 계약 구조에서 온다. AWS 청구서 하나로 합쳐지고, 이미 맺어 둔 약정이나 크레딧, 구매 절차를 그대로 탈 수 있다. 새 벤더를 등록하는 데 몇 주씩 걸리는 회사라면 이게 결정적인 이유가 되기도 한다.

용량과 과금 방식은 여러 갈래다. 기본은 토큰 단위 온디맨드이고, 지원 모델에 한해 배치 추론은 온디맨드 대비 50% 저렴하다. 서비스 티어는 Standard, Flex, Priority, Reserved가 있으며 Flex는 Standard 대비 50% 할인, Priority는 75% 프리미엄이다. 처리량을 미리 확보하려면 월 또는 6개월 약정의 Provisioned Throughput을 쓴다.

프롬프트 캐싱도 지원한다. Guardrails 콘텐츠 필터 같은 부가 기능은 별도 과금이고(가격 페이지 요약 기준 텍스트 단위 1,000개당 $0.15), 수치는 바뀔 수 있으니 붙이기 전에 공식 가격표를 확인한다.

7. 직접 API가 나은 경우

여기까지가 Bedrock 쪽 근거다. 반대편도 같은 무게로 봐야 한다. Anthropic 공식 문서의 Bedrock 페이지에는 Bedrock에서 안 되는 기능이 명시돼 있다. 아래 목록은 기존 InvokeModel과 Converse 경로 문서 기준이다. 자동 프롬프트 캐싱 항목은 이 경로 문서에만 적혀 있고, 위에서 말한 Messages API 엔드포인트(Opus 4.7 이후) 문서에는 구조화 출력(structured outputs)이 미지원으로 더 올라 있다.

입력 소스: 이미지와 문서의 URL 소스, Files API
서버사이드 도구: 코드 실행, 웹 검색, 웹 페치, advisor
에이전트 인프라: Agent Skills, MCP connector, programmatic tool calling
API 엔드포인트: Message Batches, Models, Admin, Compliance, Usage and Cost
Claude Managed Agents
서버사이드 fallback(클라이언트 쪽에서 대체 모델로 넘기는 방식으로 대신한다)
자동 프롬프트 캐싱(명시적 cache breakpoint를 써야 한다)
신형 computer use, browser use 툴셋 일부

웹 검색이나 코드 실행을 서버사이드 도구로 쓰는 에이전트를 만들고 있다면, Bedrock에서는 그 부분을 직접 구현하거나 다른 서비스로 붙여야 한다. 같은 SDK니 그대로 옮겨질 거라 보고 시작하면 도구 정의 단계에서 막힐 수 있다.

요청 페이로드도 20MB로 제한된다. 컨텍스트 1M 토큰을 지원하는 모델(Fable 5.1/5, Opus 5.5/5, Sonnet 5.5/5 등)이 있어도, 큰 PDF나 이미지를 여러 장 넣으면 토큰 한도보다 이 제한에 먼저 닿을 수 있다.

모델 폐기 일정도 다르다. 파트너 플랫폼의 폐기 일정은 파트너가 정하기 때문에 Claude API와 날짜가 다를 수 있다. 마이그레이션 계획은 AWS 모델 수명 주기 페이지 기준으로 잡아야 한다.

최신 기능이 나오는 날부터 쓰고 싶다면 직접 API가 맞다. AWS 청구는 유지하고 싶다면 Claude Platform on AWS도 후보다. Anthropic이 운영하고 AWS Marketplace로 청구하며, 문서에는 대개 당일 기능 접근이 된다고 적혀 있다. 통제 방식이 Bedrock과 같은지는 해당 문서로 따로 확인한다.

8. 상황별 선택 기준

상황	권장	이유
워크로드가 AWS에 있고 IAM 역할로 권한을 관리한다	Bedrock	비밀 키 없이 기존 역할에 권한만 추가
호출 주체별 감사와 프롬프트 원문 보관이 요구된다	Bedrock	CloudTrail과 호출 로깅, identity.arn 집계
EU 등 특정 지리에서만 처리해야 한다	Bedrock(지리 단위 프로파일)	처리 리전 제한과 CloudTrail로 확인
인터넷을 거치지 않는 연결이 필요하다	Bedrock	VPC PrivateLink
새 벤더 계약이 어렵고 AWS 약정을 소진해야 한다	Bedrock	AWS 청구와 계약 구조
Anthropic과 OpenAI 등 여러 모델을 바꿔 가며 쓴다	Bedrock	하나의 API, Converse로 교체 용이
웹 검색, 코드 실행 같은 서버사이드 도구가 핵심이다	직접 API	Bedrock 미지원
Files API, MCP connector, Agent Skills를 쓴다	직접 API	Bedrock 미지원
신기능을 출시 당일부터 써야 한다	직접 API 또는 Claude Platform on AWS	Bedrock은 기능 반영이 늦을 수 있음
완전 무보관이 계약 조건인데 Fable 5 계열을 쓴다	보관 정책 확인 후 결정	aws_review 설정이 필수이고 이때 전 트래픽이 최대 30일 보관(ZDR 자격은 별도 확인)

9. 정리

Bedrock은 모델을 고르는 선택이 아니라 운영 체계를 고르는 선택이다. 권한, 감사, 네트워크, 리전, 청구를 이미 AWS로 관리하고 있다면 Bedrock은 그 체계에 모델 호출 하나를 더 얹는 일이 되고, 보안 검토도 빨리 끝난다.

대신 서버사이드 도구와 에이전트 기능 일부가 빠져 있고, 새 기능은 늦게 들어올 수 있다. 데이터 보관도 모델에 따라 예외가 있어서 '프라이버시 때문에 Bedrock'이라는 논리는 쓰려는 모델과 data_retention_mode를 확인한 뒤에야 성립한다. 제품의 핵심이 최신 기능이라면 직접 API를, 운영 통제가 핵심이라면 Bedrock을 고른다.