AWS 안의 Claude 두 갈래, Bedrock 밖 데이터 경계

AI 요약

• 무슨 일: Anthropic과 AWS가 Claude Platform on AWS를 일반 제공으로 열었습니다.
  • AWS 계정, IAM, CloudTrail, Marketplace 청구로 Claude의 1차 플랫폼 기능을 쓰는 경로입니다.
• 핵심 차이: Bedrock은 AWS가 inference stack을 운영하지만, Claude Platform on AWS는 Anthropic이 운영합니다.
• 실무 영향: 최신 에이전트 기능은 빨리 오지만, 데이터 경계와 컴플라이언스 검토는 Bedrock과 다르게 해야 합니다.
  • 특히 CloudTrail data event logging, request ID 상관관계, AWS compliance coverage 제외 여부를 확인해야 합니다.

Anthropic과 AWS가 2026년 5월 11일 Claude Platform on AWS의 일반 제공을 발표했습니다. 표면적으로는 익숙한 파트너십 뉴스처럼 보입니다. AWS 계정으로 Claude를 쓰고, IAM으로 접근을 제어하고, CloudTrail로 감사하고, AWS Marketplace 청구로 비용을 모으는 방식입니다. 하지만 이번 발표의 진짜 쟁점은 “Claude가 AWS에 들어왔다”가 아닙니다. 같은 AWS 안에서도 Claude를 쓰는 길이 둘로 갈라졌다는 점입니다.

하나는 Amazon Bedrock입니다. AWS가 inference stack을 운영하고, Bedrock의 Converse 또는 InvokeModel API를 통해 Claude 모델을 호출합니다. 다른 하나가 이번에 일반 제공된 Claude Platform on AWS입니다. AWS 계정과 IAM, 청구, CloudTrail은 그대로 쓰지만, 실제 Claude 플랫폼은 Anthropic이 운영합니다. Anthropic의 1차 Messages API, Claude Console, Managed Agents, Agent Skills, MCP connector, code execution, web search/fetch, Files API 같은 기능을 AWS 계정 안에서 여는 구조입니다.

이 차이는 개발자에게 꽤 실질적입니다. 모델 이름이 같아도 API surface가 다르고, 기능 출시 속도가 다르고, 감사 로그를 남기는 방식이 다르고, 데이터 처리자와 컴플라이언스 책임선이 다릅니다. AI 인프라 팀이 “AWS에서 Claude를 쓴다”고 말할 때 이제는 질문을 하나 더 해야 합니다. Bedrock을 말하는가, 아니면 Claude Platform on AWS를 말하는가. 두 선택지는 같은 구매 채널처럼 보이지만 운영 경계는 다릅니다.

AWS 계정으로 들어온 Anthropic 1차 플랫폼

AWS 공식 블로그는 Claude Platform on AWS를 “Anthropic의 native Claude Platform experience를 AWS 계정으로 직접 쓰는 새 서비스”라고 설명합니다. 별도 Anthropic 계정, 별도 계약, 별도 청구 관계를 줄이고, AWS Marketplace와 IAM 안에서 접근하게 만든다는 메시지입니다. AWS는 이를 native Claude platform experience를 제공하는 첫 클라우드 사업자라고 표현했습니다.

포함되는 기능 목록도 중요합니다. AWS 블로그는 Messages API, Claude Managed Agents 베타, advisor tool 베타, web search와 web fetch, MCP connector 베타, Agent Skills 베타, code execution, Files API 베타를 언급합니다. 이는 단순 모델 호출보다 넓은 범위입니다. Anthropic이 최근 밀고 있는 에이전트 플랫폼 기능, 도구 실행, 파일 처리, 웹 컨텍스트, MCP 연결이 함께 들어옵니다.

Anthropic의 문서도 같은 점을 강조합니다. Claude Platform on AWS는 AWS 계정에서 접근하지만 Anthropic-managed infrastructure에서 실행됩니다. AWS는 SigV4 또는 API key 기반 인증, IAM 접근 제어, AWS Marketplace 청구 통합을 제공합니다. 모델 실행과 1차 Claude 플랫폼 기능은 Anthropic 운영 경계에 남습니다.

이 구조가 매력적인 이유는 분명합니다. 기업은 이미 AWS 계정, IAM role, billing account, CloudTrail, Cost Explorer, Marketplace procurement를 갖고 있습니다. AI 팀이 새 모델 공급자를 도입할 때 가장 오래 걸리는 부분은 SDK 호출 코드가 아니라 조달, 권한, 비용 배분, 감사 절차인 경우가 많습니다. Claude Platform on AWS는 그 마찰을 줄이면서도 Anthropic의 1차 API 기능을 빠르게 쓰게 하려는 제품입니다.

하지만 이 편의는 Bedrock과 같은 의미의 “AWS-operated Claude”가 아닙니다. 여기서부터 이번 뉴스의 핵심이 시작됩니다.

같은 AWS, 다른 데이터 처리자

AWS 문서는 Claude Platform on AWS와 Amazon Bedrock의 차이를 표로 분명히 나눕니다. Claude Platform on AWS는 Anthropic이 stack을 운영합니다. API surface는 Anthropic Messages API이고, base URL은 aws-external-anthropic.{region}.api.aws입니다. Rate limit과 quota도 Anthropic이 관리합니다. Data processors는 Anthropic and AWS입니다.

Bedrock은 다릅니다. AWS가 stack을 운영합니다. API surface는 Bedrock Converse 또는 InvokeModel이고, base URL은 bedrock-runtime.{region}.amazonaws.com입니다. Rate limit과 quota는 AWS가 관리합니다. Data processor는 AWS입니다. AWS 문서는 AWS-operated Claude와 Bedrock API가 필요하면 Amazon Bedrock을 보라고 안내합니다.

이 차이는 법무팀과 보안팀에게 작은 문구 차이가 아닙니다. AWS의 Claude Platform on AWS 대 Bedrock 문서는 Claude Platform on AWS가 Anthropic이 제공하는 third-party offering이며, 표준 AWS 컴플라이언스 프로그램, 인증, 감사 보고서 범위에 포함되지 않는다고 명시합니다. FedRAMP High, IL4, IL5, SOC, ISO, HIPAA eligibility 같은 AWS compliance coverage가 필요하거나 AWS가 sole data processor여야 하는 조직은 Bedrock을 선택하라고 안내합니다.

Anthropic 문서에도 운영 특성이 더 직접적으로 적혀 있습니다. 데이터가 AWS 안에 머무르지 않을 수 있고, inference가 Anthropic의 primary cloud로 라우팅될 수 있으며, 하위 서비스가 내부적으로 바뀔 수 있습니다. 요청별 inference_geo로 지리적 inference 위치를 지정할 수 있지만, 이는 Bedrock의 AWS-operated boundary와 같은 말은 아닙니다.

따라서 이 제품은 “AWS 안에서 Anthropic을 산다”에 가깝습니다. AWS는 identity, access, billing, audit entry point를 제공합니다. Anthropic은 Claude platform을 운영합니다. 이 분업을 이해하지 않고 “AWS니까 Bedrock과 같은 데이터 경계겠지”라고 보면 위험합니다.

최신 에이전트 기능과 컴플라이언스의 거래

왜 이런 두 갈래가 생겼을까요. 이유는 기능 속도입니다. Anthropic은 Claude API 위에 에이전트 런타임과 도구 계층을 빠르게 쌓고 있습니다. Managed Agents, Agent Skills, MCP connector, code execution, Files API, web search/fetch, advisor tool 같은 기능은 모델 호출 하나로 끝나는 기능이 아닙니다. 도구 실행, 파일 업로드, 장기 세션, 외부 시스템 연결, 평가와 프롬프트 개발을 포함하는 플랫폼 기능입니다.

Bedrock은 여러 모델 공급자를 AWS 방식으로 통합하는 관리형 플랫폼입니다. 이 구조의 장점은 AWS 운영 경계, AWS 서비스와의 일관성, Guardrails나 Knowledge Bases 같은 Bedrock 생태계 기능, 데이터 레지던시와 컴플라이언스 요구에 맞춘 선택지입니다. 반대로 Anthropic이 1차 플랫폼에서 막 공개한 베타 기능을 같은 날 그대로 제공하는 데에는 구조적 지연이 생길 수 있습니다.

Claude Platform on AWS는 이 간극을 줄입니다. 기업은 AWS 청구와 IAM 안에 머무르면서 Anthropic의 1차 기능을 더 빨리 받을 수 있습니다. AWS 블로그는 Claude Code, Claude Cowork, SDK 클라이언트가 이 workspace를 가리키도록 환경 변수를 설정하는 예시를 보여줍니다. 즉 개발자는 Anthropic의 API 형태에 더 가깝게 작업하고, 플랫폼팀은 AWS 계정의 접근 제어와 비용 관리를 활용합니다.

하지만 그 대가가 데이터 경계입니다. Bedrock의 장점이 AWS-operated inference와 AWS compliance coverage라면, Claude Platform on AWS의 장점은 native Claude API parity와 빠른 기능 접근입니다. 둘 중 어느 쪽이 맞는지는 조직의 AI 워크로드에 따라 달라집니다. 실험적 에이전트, 내부 개발자 도구, 빠른 모델/기능 검증에는 Claude Platform on AWS가 매력적일 수 있습니다. 엄격한 규제 데이터, 명시적인 AWS compliance scope, AWS를 sole processor로 보는 계약 구조가 필요하면 Bedrock이 더 자연스럽습니다.

이것은 “어느 쪽이 더 낫다”의 문제가 아닙니다. 모델 플랫폼 선택이 제품 기능과 통제 경계의 조합이 됐다는 뜻입니다.

감사는 쉬워졌지만 로그 설계는 더 중요해졌습니다

Claude Platform on AWS의 강점 중 하나는 CloudTrail 연결입니다. AWS 블로그는 Claude Platform activity가 CloudTrail에 capture되어 AI usage를 다른 AWS 서비스처럼 monitor, audit, investigate할 수 있다고 설명합니다. 기존 보안 운영팀에게는 큰 장점입니다. 새 공급자 포털만 보는 대신 AWS 계정의 감사 흐름에 Claude 사용 흔적을 일부 넣을 수 있기 때문입니다.

다만 세부 문서를 보면 주의할 점이 있습니다. AWS monitoring 문서는 CloudTrail이 모든 요청을 캡처할 수 있지만, workspace와 vault 작업은 기본 management events로 기록되고, inference, batch, file, skill, model, user profile, Claude Managed Agents 작업은 Data events로 분류된다고 설명합니다. Data events는 명시적 설정이 필요하고 추가 CloudTrail 비용이 발생합니다. 즉 “CloudTrail 지원”과 “모든 inference와 agent event가 기본으로 남는다”는 같은 말이 아닙니다.

또 하나 중요한 점은 request ID입니다. 응답에는 x-amzn-requestid와 request-id가 함께 들어갑니다. 전자는 AWS tooling과 AWS support 조사에 쓰는 request ID이고, 후자는 Anthropic support와 연결되는 secondary ID입니다. 이 구조는 이번 제품의 책임 경계를 그대로 반영합니다. 실제 장애나 이상 사용을 조사할 때 AWS 쪽 이벤트와 Anthropic 쪽 요청을 이어야 합니다.

AI 에이전트 워크로드에서는 이 상관관계가 더 중요해집니다. 단순 채팅 요청이면 한 번의 model call만 보면 됩니다. 하지만 Managed Agents, MCP connector, code execution, Files API가 붙으면 세션, 파일, tool call, 실행 결과, 비용, 승인 상태가 여러 시스템에 퍼집니다. CloudTrail data event logging을 어디까지 켤지, workspace tag를 어떻게 비용 배분에 쓸지, Anthropic usage surfaces와 AWS Cost and Usage Report를 어떻게 맞출지까지 설계해야 합니다.

Reddit r/ClaudeAI 반응도 이 지점을 짚었습니다. 한 게시물은 IAM 인증, AWS billing integration, CloudTrail visibility, 별도 account handling 제거를 장점으로 보면서도, customer data가 AWS security boundary 밖에서 처리된다는 점을 엄격한 data residency와 compliance 요구가 있는 조직의 검토 포인트로 적었습니다. 댓글에서는 web search/fetch만으로는 충분하지 않고, logged-in browser, DOM state, visible actions, review point 같은 에이전트 실행 계층이 필요하다는 의견도 나왔습니다. 기능이 빨라질수록 감사와 실행 통제의 세부 설계가 같이 필요하다는 반응입니다.

Bedrock에서 옮길 때는 코드도 바뀝니다

이 발표를 “엔드포인트만 바꾸면 되는 AWS 서비스 추가”로 이해하면 곤란합니다. AWS의 Bedrock migration 문서는 Bedrock에서 Claude Platform on AWS로 옮기려면 integration 전반이 바뀐다고 설명합니다. SigV4 signing은 계속 지원되지만 signing context, base URL, API format, model IDs, SDK client와 package, streaming format, request headers, region availability가 달라집니다.

Bedrock에서는 base URL이 bedrock-runtime.{region}.amazonaws.com이고, API format은 Bedrock Converse 또는 InvokeModel입니다. Claude Platform on AWS에서는 base URL이 aws-external-anthropic.{region}.api.aws이고, API format은 Anthropic Messages API입니다. 모델 ID도 Bedrock식 anthropic. prefix가 아니라 1차 Claude API와 같은 형태를 씁니다. SDK도 Bedrock SDK 클라이언트가 아니라 AnthropicAWS 같은 platform-specific client를 사용합니다.

이것은 개발자 경험 측면에서 양면성이 있습니다. 이미 Anthropic API를 쓰던 팀은 Claude Platform on AWS가 더 자연스럽습니다. AWS 계정 안에서 조달과 IAM을 붙이면서 기존 Claude API 형태를 유지할 수 있기 때문입니다. 반대로 이미 Bedrock 중심으로 여러 모델을 추상화한 팀은 API와 streaming, model ID, SDK를 다시 맞춰야 합니다. Bedrock의 통합 모델 플랫폼 장점을 포기하는 대신 Claude의 1차 기능을 더 빨리 얻는 구조가 됩니다.

플랫폼팀은 이 선택을 애플리케이션별로 나눌 수 있습니다. 규제 데이터와 고객 PII를 다루는 production inference는 Bedrock에 남기고, 내부 개발자 도구나 에이전트 실험은 Claude Platform on AWS로 빠르게 검증할 수 있습니다. 또는 반대로 Claude의 Managed Agents와 Skills가 핵심인 제품은 Claude Platform on AWS를 채택하되, 민감 데이터는 별도 redaction과 policy gateway를 거치게 할 수 있습니다. 중요한 것은 “AWS 청구서에 나온다”가 아키텍처 경계를 대신하지 않는다는 점입니다.

AI 인프라 경쟁은 구매 채널과 운영 경계로 이동합니다

이번 뉴스가 흥미로운 이유는 모델 경쟁이 점점 플랫폼 경쟁으로 이동하고 있다는 점입니다. 2024년과 2025년에는 어떤 모델이 더 높은 벤치마크 점수를 내는지가 중심이었습니다. 2026년의 기업 AI에서는 그 위에 더 많은 질문이 붙습니다. 최신 모델 기능을 얼마나 빨리 받을 수 있는가. 사내 IAM과 연결되는가. 비용을 팀별로 배분할 수 있는가. agent tool call을 감사할 수 있는가. 데이터가 어느 법적 경계에서 처리되는가. 공급자 지원 요청과 클라우드 이벤트 로그를 어떻게 연결할 수 있는가.

Anthropic은 Claude의 1차 플랫폼 기능을 빠르게 확장하고 있습니다. Managed Agents는 장기 실행 에이전트, Agent Skills는 재사용 가능한 작업 지식, MCP connector는 외부 도구 연결, code execution과 Files API는 실행과 파일 처리를 담당합니다. 이런 기능은 모델 API 하나보다 훨씬 넓은 운영면을 갖습니다. 그래서 AWS 같은 클라우드 계정 안으로 들어오는 것이 중요해졌습니다.

AWS도 한 가지 Claude 경로만 제공하지 않습니다. Bedrock은 AWS-operated model platform입니다. Claude Platform on AWS는 Anthropic-operated native Claude platform을 AWS 계정으로 여는 경로입니다. 두 제품은 경쟁하면서도 서로 보완합니다. Bedrock은 데이터 경계와 AWS 서비스 통합에 강하고, Claude Platform on AWS는 1차 Claude API와 최신 에이전트 기능 접근에 강합니다.

개발자에게 이 변화는 선택지가 늘었다는 뜻이지만, 동시에 추상화가 더 어려워졌다는 뜻입니다. “Claude 호출”이라는 한 줄 뒤에 Bedrock API, Anthropic API, Claude Platform on AWS, direct API, Vertex AI, Microsoft Foundry 같은 경로가 놓입니다. 각 경로는 모델 ID, 기능 지원, rate limit, 로그, 비용, data processor가 다를 수 있습니다. AI SDK나 내부 gateway를 만들 때 이 차이를 숨기기만 하면 나중에 compliance와 incident response에서 문제가 됩니다.

지금 확인할 체크포인트

첫째, 데이터 경계를 먼저 정해야 합니다. 워크로드가 AWS compliance programs, regional data residency, AWS sole data processor 조건을 요구한다면 Bedrock이 더 맞을 수 있습니다. 최신 Claude API 기능, Managed Agents, Agent Skills, MCP connector 같은 1차 플랫폼 기능이 더 중요하다면 Claude Platform on AWS를 검토할 수 있습니다. 다만 이 경우 Anthropic-operated infrastructure와 데이터 처리 조건을 문서화해야 합니다.

둘째, 감사 로그를 기본값으로 가정하지 말아야 합니다. CloudTrail이 지원되더라도 data plane events는 명시적 설정이 필요하고 비용이 붙습니다. inference, file, skill, agent 작업까지 추적할지, workspace별로 scope를 나눌지, AWS::AWSExternalAnthropic::Workspace resource type을 어떻게 설정할지 결정해야 합니다. 최소한 AWS request ID와 Anthropic request ID를 애플리케이션 로그에 함께 남기는 설계가 필요합니다.

셋째, API 이식 비용을 계산해야 합니다. Bedrock에서 Claude Platform on AWS로 옮기면 base URL, API format, model ID, SDK, streaming, request headers가 바뀝니다. 이미 Bedrock 추상화에 투자한 팀이라면 기능 접근 속도와 migration 비용을 비교해야 합니다. 반대로 direct Anthropic API를 쓰던 팀은 AWS 조달과 IAM을 붙이는 경로로 볼 수 있습니다.

넷째, 에이전트 기능을 쓸수록 정책 경계를 더 세밀하게 잡아야 합니다. Managed Agents, code execution, Files API, MCP connector는 단순 텍스트 생성보다 권한 표면이 넓습니다. 어떤 workspace에서 어떤 IAM principal이 어떤 tool과 file 기능을 쓸 수 있는지, tool call 결과와 파일 업로드가 어떤 로그에 남는지, human approval이 어디에 들어가는지 확인해야 합니다.

결론: AWS 안에 들어왔다는 말만으로는 부족합니다

Claude Platform on AWS는 Anthropic과 AWS 모두에게 중요한 제품입니다. Anthropic은 native Claude platform을 기업의 AWS 운영 체계 안으로 밀어 넣을 수 있습니다. AWS는 Bedrock만으로는 포착하기 어려운 1차 Claude API와 빠른 에이전트 기능 수요를 AWS 계정 안에 붙잡을 수 있습니다. 개발자와 플랫폼팀은 AWS IAM, CloudTrail, Marketplace 청구를 유지하면서 Claude의 최신 기능을 더 빨리 시험할 수 있습니다.

하지만 이 편의는 Bedrock과 같은 데이터 경계를 뜻하지 않습니다. Bedrock은 AWS-operated path이고, Claude Platform on AWS는 Anthropic-operated native platform을 AWS에서 여는 path입니다. AWS 문서가 이 차이를 꽤 노골적으로 써둔 이유가 있습니다. AI 인프라에서 가장 중요한 질문은 이제 “어떤 모델인가”만이 아닙니다. “누가 운영하는가”, “누가 데이터를 처리하는가”, “어떤 감사 로그가 기본으로 남는가”, “어떤 컴플라이언스 범위 안에 있는가”입니다.

따라서 이번 발표의 실무적 결론은 단순합니다. Claude를 AWS에서 쓴다고 말하기 전에 경로를 명시해야 합니다. Bedrock인지, Claude Platform on AWS인지, direct API인지에 따라 같은 모델 호출도 운영 책임이 달라집니다. 최신 에이전트 기능을 빨리 얻는 일과 데이터 경계를 단순하게 유지하는 일은 항상 같은 선택지가 아닙니다. 그 긴장을 명확히 드러냈다는 점에서 Claude Platform on AWS는 2026년 AI 인프라 경쟁의 중요한 장면입니다.

출처: Anthropic 공식 발표, Anthropic Claude Platform on AWS 문서, AWS 공식 발표, AWS Claude Platform on AWS vs Bedrock 문서, AWS monitoring 문서, AWS migration 문서.