Claude Platform on AWS와 Bedrock 차이 2026 – 기업 도입 전 데이터 경계 체크리스트

Posted on by

2026년 5월 11일 AWS와 Anthropic은 Claude Platform on AWS를 일반 제공으로 공개했다. 핵심은 “AWS 계정으로 Anthropic의 네이티브 Claude Platform을 쓰는 길”이 생겼다는 점이고, Amazon Bedrock과의 차이는 기능보다 데이터 처리 경계에서 먼저 갈린다.

도입 전에 한 줄로 정리하면 이렇다. 최신 Claude API 기능과 Claude Code 연결성을 빨리 쓰고 싶으면 Claude Platform on AWS를 검토하고, 데이터가 AWS 보안 경계 안에서만 처리돼야 한다면 Bedrock을 먼저 봐야 한다.

이 글은 출시 뉴스 요약이 아니다. 보안팀, 플랫폼팀, 개발 리더가 “우리 회사에서 어느 쪽을 승인해야 하지?”를 판단할 때 보는 체크리스트다. 나도 이런 류의 도입 판단을 볼 때 기능표부터 열면 꼭 길을 잃는다. 먼저 물어야 하는 건 모델 이름이 아니라, 프롬프트와 응답이 어느 운영 주체의 경계에서 처리되는가다.

지금 결론

판단 축 Claude Platform on AWS Claude on Amazon Bedrock
운영 주체 Anthropic이 서비스 운영 AWS가 Bedrock 서비스 운영
데이터 처리 경계 Anthropic 쪽에서 처리, AWS 경계 밖 처리 명시 AWS가 data processor, AWS 경계 안 처리
인증 AWS IAM 또는 workspace API key AWS IAM, Bedrock API key, AWS credential chain
감사 로그 AWS CloudTrail로 activity 캡처 Bedrock/AWS 표준 거버넌스와 로깅 흐름
기능 접근 Claude native API, Managed Agents beta, Skills beta, MCP connector beta, code execution, files API 등 Bedrock의 Claude 모델, Guardrails, Knowledge Bases, PrivateLink, regional data residency 등 AWS managed 기능
맞는 팀 Claude Code, Claude API 최신 기능, 에이전트 기능을 빠르게 실험하는 팀 데이터 레지던시, AWS-only 처리, 기존 Bedrock 거버넌스가 중요한 팀

여기서 실수하기 쉬운 지점은 “둘 다 AWS에서 사니까 보안 경계도 같겠지”라고 보는 것이다. AWS의 FAQ는 Claude Platform on AWS는 Anthropic의 first-party platform을 AWS 진입점으로 쓰는 방식이고, 고객 데이터가 AWS boundary 밖에서 Anthropic에 의해 처리된다고 설명한다. 반대로 Bedrock은 AWS가 데이터를 처리하고 Anthropic이나 제3자와 공유하지 않는다고 설명한다.

그래서 이 선택은 “어느 쪽이 더 좋냐”가 아니다. 승인 기준이 다르다. Claude Platform on AWS는 네이티브 기능 접근성과 AWS 조달/인증 통합이 매력이고, Bedrock은 AWS 안에서 닫히는 거버넌스와 네트워크/레지던시 옵션이 강점이다.

Claude Platform on AWS에서 새로 좋아지는 것

Claude Platform on AWS의 장점은 개발자 경험이다. AWS 발표 기준으로 Messages API, Claude Managed Agents beta, advisor tool beta, web search, web fetch, MCP connector beta, Agent Skills beta, code execution, files API beta 같은 네이티브 Claude Platform 기능을 AWS 계정 경로로 쓸 수 있다.

Claude Code 관점에서도 차이가 있다. Claude Code 문서는 Claude Platform on AWS를 쓰려면 CLAUDE_CODE_USE_ANTHROPIC_AWS=1, ANTHROPIC_AWS_WORKSPACE_ID, AWS_REGION을 설정하고, AWS credential chain 또는 workspace API key로 인증할 수 있다고 설명한다. Bedrock도 Claude Code에서 쓸 수 있지만, 설정 흐름과 모델 ID, provider routing이 다르다.

실무에서는 이 차이가 은근 크다. 개발자가 Claude Code, Agent SDK, files API, code execution, MCP connector를 같은 Anthropic API 감각으로 굴리고 싶다면 Platform on AWS가 훨씬 자연스럽다. 별도 Anthropic 계약이나 청구를 만들기 싫은 회사도 AWS Marketplace와 기존 AWS invoice 쪽으로 비용을 모을 수 있다.

다만 “자연스럽다”는 말이 곧 “보안팀 승인도 쉽다”는 뜻은 아니다. 네이티브 기능이 넓어질수록 확인할 것도 같이 늘어난다. web fetch를 열 것인가, code execution을 어떤 데이터로 허용할 것인가, files API에 어떤 문서 등급까지 올라갈 수 있는가, MCP connector가 어느 외부 시스템까지 닿는가를 별도로 정해야 한다.

Bedrock을 먼저 봐야 하는 경우

Bedrock은 덜 멋있어 보여도 기업 도입에서는 강한 카드다. Anthropic의 Claude on AWS 페이지는 Bedrock 쪽 설명에서 입력, 출력, 추론이 사용자가 통제하는 AWS security boundary 안에서 실행되고 international data locality를 지원한다고 설명한다. AWS FAQ도 strict regional data residency, AWS infrastructure 안에서만 데이터 처리, 여러 foundation model을 하나의 통합 서비스로 쓰는 요구가 있으면 Bedrock이 맞다고 정리한다.

특히 이미 Bedrock Guardrails, Knowledge Bases, PrivateLink, CloudWatch/CloudTrail 기반 통제, 조직 단위 IAM 정책이 깔려 있다면 Platform on AWS로 바로 옮기는 게 꼭 이득은 아니다. 기존 승인 경로를 다시 열어야 하고, data processing boundary 설명을 보안팀과 다시 맞춰야 한다.

내가 운영팀이라면 고객 PII, 금융 원장, 내부 계약서, 소스코드 전체 저장소처럼 민감도가 높은 워크로드는 먼저 Bedrock으로 분류한다. 그 다음 “이 업무가 정말 native Claude Platform 기능을 필요로 하는가?”를 따진다. 필요 없다면 굳이 경계를 넓히지 않는 쪽이 운영상 편하다.

도입 전 보안 체크리스트

첫째, 데이터 등급부터 나눠야 한다. 공개 문서 요약, 개발 문서 초안, 테스트 코드 분석처럼 낮은 민감도 업무는 Platform on AWS 후보가 될 수 있다. 고객 식별정보, 계약 조건, 보안 취약점 세부, 프로덕션 로그처럼 민감한 데이터는 Bedrock 또는 별도 승인 흐름으로 보내는 편이 안전하다.

둘째, 인증 방식을 정해야 한다. Claude Platform on AWS는 IAM principal 또는 workspace API key를 쓸 수 있다. 로컬 개발자는 AWS SSO와 SigV4가 어울리고, 자동화 runner는 IAM role이 깔끔하다. API key는 편하지만 오래 살아 있는 비밀값이 되기 쉽다. 팀에서 키를 쓰기로 했다면 회전 주기, 저장 위치, 유출 대응을 먼저 정해야 한다.

셋째, CloudTrail에서 무엇을 볼지 확인해야 한다. AWS 발표는 Claude Platform on AWS activity가 CloudTrail에 captured 된다고 설명하고, data event logging을 켜면 inference activity도 캡처할 수 있다고 말한다. 기본 management event만 보고 “감사 완료”라고 착각하면 곤란하다. 누가 workspace를 만들었는지와 어떤 추론 요청이 있었는지는 감사 난도가 다르다.

넷째, 도구 기능을 기본 off로 놓고 열어야 한다. web search, web fetch, code execution, files API, MCP connector는 편하지만 유출면도 넓힌다. “Claude가 더 똑똑해진다”가 승인 사유가 되면 안 된다. 어떤 팀, 어떤 데이터, 어떤 로그, 어떤 실패 대응까지 정해졌을 때만 열어야 한다.

다섯째, 모델 별칭을 그대로 두지 않는 게 좋다. Claude Code 문서는 Platform on AWS에서 opus, sonnet, haiku 같은 alias가 workspace의 최신 버전으로 해석될 수 있으니 팀 배포에서는 모델 ID를 명시적으로 pin 하라고 안내한다. 긴 작업이나 재현성이 중요한 업무라면 claude-opus-4-7, claude-sonnet-4-6처럼 고정하는 편이 낫다.

비용보다 먼저 봐야 할 리뷰 부담

이런 플랫폼 선택에서 다들 가격표부터 본다. 물론 중요하다. 하지만 AI 에이전트형 도입에서는 비용보다 리뷰 부담이 먼저 터지는 경우가 많다. code execution이 켜지면 실행 결과를 누가 검토할지, files API로 올라간 문서를 누가 분류할지, MCP connector가 호출한 외부 시스템의 로그를 누가 대조할지 정해야 한다.

Platform on AWS는 빠른 실험과 네이티브 기능 접근에 좋다. 그래서 작은 자동화 팀이 “Claude Code를 AWS 계정 안 청구로 연결하고, workspace 단위로 프로젝트를 나누고, CloudTrail로 활동을 보는” 구조에는 잘 맞는다. 대신 보안팀 입장에서는 Bedrock보다 물어볼 질문이 많다. Anthropic-operated service라는 사실, data processing boundary, beta 기능의 통제 범위가 승인 문서에 남아야 한다.

Bedrock은 반대로 기능 접근이 더 보수적으로 느껴질 수 있다. 하지만 이미 AWS 안에서 통제하고 있는 조직이라면 검토 자료를 만들기 쉽다. PrivateLink, Guardrails, Knowledge Bases, regional data residency처럼 보안팀이 익숙한 단어가 많고, 다른 모델과 함께 쓰는 거버넌스도 잡기 좋다.

우리 팀이 바로 고를 수 있는 판단표

질문 답이 YES면
고객 데이터가 AWS 경계 밖에서 처리되면 안 되는가 Bedrock 우선
regional data residency가 계약 조건인가 Bedrock 우선
PrivateLink, Guardrails, Knowledge Bases가 핵심인가 Bedrock 우선
Claude Managed Agents, Skills, MCP connector beta, code execution을 빨리 써야 하는가 Claude Platform on AWS 검토
Claude Code를 native Claude API 경험에 가깝게 운영하고 싶은가 Claude Platform on AWS 검토
보안팀이 CloudTrail 로그만으로 충분한지 세부 이벤트까지 봐야 하는가 두 옵션 모두 로그 범위 확인 후 결정
API key 없이 IAM role 중심으로 CI를 굴릴 계획인가 두 옵션 모두 가능하지만 설정 방식 비교 필요

개발팀 혼자 결정하면 거의 Platform on AWS로 기울 수 있다. 최신 기능과 Claude Code 연결성이 매력적이니까. 보안팀 혼자 결정하면 거의 Bedrock으로 기울 수 있다. AWS boundary와 managed governance가 편하니까. 둘 다 맞는 말이라서, 이 글의 표를 그대로 승인 회의 질문지로 쓰는 게 낫다.

실수 TOP 5

  1. AWS로 청구된다는 이유만으로 데이터 경계도 Bedrock과 같다고 보는 것.
  2. CloudTrail이 있다는 말만 보고 inference activity 로깅 범위를 확인하지 않는 것.
  3. API key를 임시 테스트용으로 만들고 장기 운영 키처럼 방치하는 것.
  4. opus, sonnet 같은 alias를 팀 표준으로 두고 모델 변경 영향을 추적하지 않는 것.
  5. web fetch, code execution, MCP connector를 한 번에 열고 나중에 정책을 만들려는 것.

이 다섯 개는 기능 문제가 아니라 운영 문제다. 도구가 좋아서 사고가 나는 게 아니라, 좋은 도구를 “어디까지 허용할지” 안 정해서 사고가 난다.

FAQ

Claude Platform on AWS는 Bedrock의 새 이름인가요?

아니다. 둘은 다른 경로다. Claude Platform on AWS는 Anthropic의 네이티브 Claude Platform을 AWS 계정, IAM, billing, CloudTrail 경로와 묶어 쓰는 방식이다. Bedrock은 AWS가 운영하는 Bedrock 서비스 안에서 Claude 모델을 쓰는 방식이다.

데이터 보안만 보면 Bedrock이 무조건 맞나요?

엄격한 AWS-only 처리, regional data residency, PrivateLink 같은 요구가 있으면 Bedrock 쪽이 더 자연스럽다. 다만 모든 워크로드가 그 수준의 통제를 요구하는 건 아니다. 공개 문서 요약이나 내부 개발 생산성 실험처럼 민감도가 낮은 업무라면 Platform on AWS도 검토할 수 있다.

CloudTrail이 있으면 감사는 충분한가요?

충분하다고 바로 말하면 위험하다. AWS 발표는 Platform on AWS 요청이 CloudTrail에 캡처되고, data event logging으로 inference activity를 캡처할 수 있다고 설명한다. 실제 운영에서는 management event와 data event 범위, 보관 기간, SIEM 연동, 민감 데이터 마스킹 여부를 따로 확인해야 한다.

Claude Code에서는 무엇이 달라지나요?

Claude Code 문서 기준으로 Platform on AWS는 CLAUDE_CODE_USE_ANTHROPIC_AWS, workspace ID, AWS region을 설정해 연결한다. Bedrock은 Bedrock provider 설정과 모델 접근 승인 흐름을 탄다. 팀 배포에서는 provider routing, model pinning, 인증 갱신 방식까지 표준화해야 한다.

언제 Platform on AWS를 먼저 써볼 만한가요?

Claude Code, Agent SDK, files API, code execution, MCP connector 같은 네이티브 기능을 빠르게 검증해야 하고, 데이터가 엄격한 AWS-only 경계에 묶이지 않아도 되는 업무라면 먼저 검토할 만하다. 단, beta 기능은 승인 범위와 로그 정책을 좁게 잡고 시작하는 게 좋다.

언제 Bedrock으로 남는 게 낫나요?

고객 데이터, 규제 대상 문서, 프로덕션 로그, 보안 취약점 세부처럼 경계가 중요한 업무라면 Bedrock을 우선 보는 게 보수적이다. 이미 Bedrock Guardrails, Knowledge Bases, PrivateLink, 조직 IAM 정책이 있다면 기존 통제선을 유지하는 장점도 크다.

공식 출처

관련 글