Claude Enterprise를 AWS에서 사용하는 방법(Marketplace, Bedrock, 직접 계약 비교 하기)

안녕하세요 클래스메소드의 이수재입니다.

Claude Enterprise를 도입하려고 할 때, 구독 방법이 여러 가지라 어떤 방식을 선택해야 할지 고민이 되실 수 있습니다.
크게 Anthropic 직접 계약, AWS Marketplace 구독, Amazon Bedrock 세 가지 방법이 있으며, 각각 장단점이 다릅니다.

이 글에서는 세 가지 방법의 차이점과 각 방법의 한계점, 그리고 Bedrock을 사용할 때의 실제 흐름까지 정리해보겠습니다.

읽기 전에

이 글에서는 AWS를 기준으로 하여 Marketplace 구독이나 Bedrock 을 예로 들었지만 다른 클라우드 서비스(Azure, GCP 등)에서도 비슷한 기능을 제공하고 있습니다.
그리고 서비스간에 제공하는 기능의 큰 차이는 없다고 생각합니다.
따라서 "채용하는 방법에 따라서 이런 차이점이 있을 수 있구나, 이런 상황에서 이런 방식을 도입해야하는구나" 로 보시면 좋을 것 같습니다.

세 가지 구독 방법 개요

Anthropic 직접 계약

Anthropic과 직접 계약하여 API 또는 Claude.ai Enterprise UI를 사용하는 방법입니다.
가장 빠르게 최신 모델에 접근할 수 있으며, Anthropic TAM의 직접 지원을 받을 수 있습니다.

AWS Marketplace 구독

AWS Marketplace를 통해 Claude Enterprise를 구독하는 방법입니다.
Anthropic 직접 계약과 동일한 제품이지만, AWS 계정으로 비용이 통합된다는 점이 다릅니다.

Amazon Bedrock

AWS의 완전 관리형 AI 플랫폼으로, Claude를 포함한 100개 이상의 파운데이션 모델을 API로 호출할 수 있습니다.
단순한 모델 API를 넘어, 보안·운영·비용 최적화 기능이 통합된 엔터프라이즈 AI 플랫폼입니다.

비용/구매 관점 비교

직접 계약이 무조건 더 싸지 않을까?

Enterprise 계약은 양측 모두 비공개 협상 가격(custom pricing)이므로, 거래 규모와 조건에 따라 달라질 수 있습니다.
다만 일반적으로 AWS Marketplace에서의 구독 가격과 Anthropic 직접 구독 가격에 차이^[1]는 없습니다.

Anthropic 직접 계약 vs AWS Marketplace vs Bedrock

세 방법의 핵심 차이를 정리하면 다음과 같습니다.

실제로 어떻게 사용하게 되나요?

직접 계약 / Marketplace

두 방법 모두 본질적으로 라이선스(접근권) 구매입니다.
Claude.ai 웹사이트, Claude Code, Claude 앱 등 Anthropic이 만든 제품을 그대로 사용하며, 일반적인 Claude 사용 경험과 동일합니다.
달라지는 것은 요금제·사용 한도·관리 기능 정도입니다.

Bedrock

Bedrock은 API 서비스이기 때문에, 직접 앱이나 서비스를 만들어서 호출하는 구조입니다.
Claude Code 같은 Anthropic 제품을 그대로 사용하는 방식이 아닙니다.

Claude Code를 Bedrock 엔드포인트로 연결하는 방법이 존재하기는 하지만, 공식 지원이 제한적이고 설정이 복잡합니다.
Bedrock의 주된 목적은 Claude Code 사용이 아니라 자체 AI 애플리케이션 개발입니다.

각 방법의 한계점

특징은 알아보았으니 각 방법의 한계점에 대하여 간략하게 알아보자면 다음과 같습니다.

Anthropic 직접 계약

• AWS 크레딧, EDP 할인 적용 불가
• AWS 서비스(CloudWatch, IAM 등)와의 통합을 직접 구현해야 함
• VPC PrivateLink 등 프라이빗 네트워크 구성 불가
• 멀티벤더 모델 사용 시 계약/청구가 분산됨

AWS Marketplace

• 본질적으로 Anthropic 직접 계약과 동일한 제품 → API 커스터마이징 자유도는 낮음
• 주로 사람이 사용하는 UI 중심 제품으로, 프로덕션 AI 애플리케이션 개발에는 적합하지 않음

Bedrock

• 모델 출시 딜레이: Anthropic 직접 API 대비 최신 모델 접근이 수 주~수개월 늦을 수 있음
• 일부 기능 미지원: Anthropic이 출시한 모든 기능이 Bedrock에서 즉시 지원되지 않을 수 있음
• Knowledge Bases 커스터마이징 제한: 청킹 전략 등 고급 RAG 기법 적용이 직접 구현보다 유연하지 않음
• 운용 복잡도: 단순 API 호출 대비 AWS 인프라 지식이 필요함

Bedrock을 선택하는 이유에 대해

일상생활에서 우리가 LLM을 이용하는 방식과 다르기 떄문에 Bedrock을 사용하는 경우와 이유에 대해서 조금 보충하겠습니다.
서두에서 설명했듯이 Bedrock에 국한된 내용이 아닌 다른 클라우드 서비스의 비슷한 포지션을 가진 대부분 서비스에도 통용된다고 생각해주세요.

1. 보안 & 데이터 주권

Bedrock을 이용할 때VPC PrivateLink를 구성하면 데이터가 AWS 내부 네트워크를 벗어나지 않습니다.
또한 AWS는 이미 금융·의료·공공 등 규제 산업에서 수년간 검증된 SOC 2, ISO 27001, HIPAA, PCI DSS 등의 컴플라이언스 인증을 보유하고 있기 때문에, 별도로 AI 서비스에 대한 보안 심사를 진행하는 대신 기존 AWS 계약의 보안 체계 안에서 처리할 수 있습니다.

즉, "새로운 외부 서비스에 데이터를 보내는 것"이 아니라 "이미 승인된 AWS 인프라 안에서 처리하는 것"으로 내부 승인 절차를 간소화할 수 있습니다.

2. 운영 비용

실제로 AI 서비스를 프로덕션에 올리면 반드시 필요해지는 것들이 있습니다.

• 이 API가 얼마나 호출되고 있는가? (모니터링)
• 누가 어떤 목적으로 사용하는가? (접근 제어 및 감사)
• 팀별로 비용이 얼마나 나오는가? (비용 배분)
• 장애가 발생하면 어떻게 알 수 있는가? (알람)

Anthropic 직접 API를 쓴다면 이 모든 것을 별도로 구축해야 합니다. Datadog 같은 모니터링 도구를 연동하거나, API 키를 별도 시스템으로 관리하거나, 사용량 로그를 직접 수집해서 분석하는 파이프라인을 만들어야 합니다.

Bedrock은 이미 CloudWatch, IAM, Cost Explorer, EventBridge 등과 네이티브로 연동되어 있습니다.
이 서비스들은 대부분의 AWS 사용 조직이 이미 쓰고 있기 때문에, AI 서비스를 추가한다고 해서 운영 도구를 새로 도입할 필요가 없습니다. AI 도입의 운영 오버헤드를 최소화할 수 있다는 것이 실질적인 이점입니다.

3. 비용 구조의 유연성

AI API 비용은 사용 패턴에 따라 최적화 방법이 달라집니다.

트래픽이 불규칙하다면 온디맨드(호출당 과금)가 적합하지만, 트래픽이 예측 가능하다면 Provisioned Throughput(프로비저닝된 처리량 요금)으로 할인을 받을 수 있습니다. 또한 실시간 응답이 필요 없는 작업, 예를 들어 수천 건의 문서 분류나 야간 리포트 생성 같은 경우에는 배치 추론을 사용하면 온디맨드 대비 약 20~30% 비용을 절감할 수 있습니다.

Anthropic 직접 API는 기본적으로 온디맨드 방식만 제공합니다. 사용 규모가 커질수록 Bedrock의 유연한 비용 구조가 더 유리해집니다.

추가로, 이미 AWS EDP 계약이 있는 조직이라면 Bedrock 비용이 해당 할인 계약에 포함됩니다.
실질적으로 기존 AWS 투자를 AI 비용에도 활용할 수 있는 셈입니다.

4. 가드 레일(안전망)

AI 모델은 아무리 잘 만들어도 예상치 못한 답변을 할 수 있습니다. 특히 사내 서비스나 고객 대상 서비스에서 모델이 부적절한 발언을 하거나 개인정보를 노출하면 법적·평판적 리스크로 이어집니다.

이를 방지하기 위해 통상적으로는 프롬프트 엔지니어링으로 모델의 행동을 제한하거나, 출력 결과를 후처리하는 코드를 직접 작성합니다. 하지만 이 방법은 완벽하지 않습니다. 프롬프트 인젝션 공격처럼 사용자가 의도적으로 제약을 우회하려 할 경우 모델 레벨에서 막기 어렵습니다.

Bedrock Guardrails는 이 필터링을 모델 호출과 독립적인 레이어에서 처리합니다.
즉, 아무리 교묘한 프롬프트를 사용해도 Guardrails 필터를 통과하지 못하면 모델에 도달하지 않습니다.
또한 모델의 응답도 출력 전에 동일한 필터를 거칩니다.

이 외에 PII 보호 기능도 유용하게 사용할 수 있습니다.

5. Bedrock Agents — 반복 업무의 자동화

LLM을 단순 Q&A에만 쓰는 단계를 넘어, "특정 업무 프로세스 자체를 AI가 처리하게 하고 싶다"는 요구가 생깁니다.
예를 들어 고객 문의가 들어오면 → 관련 정책을 찾고 → 답변을 생성하고 → 티켓 시스템에 결과를 기록하는 일련의 과정을 사람 없이 처리하고 싶은 경우입니다.

Bedrock Agents를 이용하면 이러한 요청의 흐름을오케스트레이션을 AWS가 대신 처리해주는 서비스입니다. 개발자는 "어떤 API를 쓸 수 있는가"만 정의하면, 실제 호출 순서와 맥락 관리는 Agent가 담당합니다. 인프라 프로비저닝도 불필요하여, 비교적 적은 개발 리소스로 자동화 워크플로우를 구축할 수 있습니다.

6. Knowledge Bases(RAG)

범용 LLM은 공개된 정보를 기반으로 학습되어 있기 때문에, 사내 규정·제품 매뉴얼·내부 정책처럼 외부에 공개되지 않은 정보는 알지 못합니다. 이 문제를 해결하는 일반적인 방법이 RAG입니다.

Bedrock Knowledge Bases는 이 파이프라인 전체를 관리형으로 제공합니다.
S3에 문서를 올리면 청킹·임베딩·벡터 저장을 자동으로 처리하며, 응답에 출처 인용도 자동으로 포함됩니다.
사내 문서 기반 챗봇이나 고객 지원 시스템처럼 비교적 명확한 요구사항에서는 직접 구현 없이도 충분한 품질을 얻을 수 있습니다.

Bedrock의 실제 사용 흐름

Bedrock은 결국 Claude API를 AWS 계정 안에서 호출하는 것입니다.
Anthropic API와 기능적으로 거의 같지만, 인증이 IAM, 네트워크가 AWS VPC, 비용이 AWS 청구서로 통합됩니다.

내 앱/서버
    ↓  AWS SDK (boto3, JS SDK 등)
Amazon Bedrock API
    ↓
Claude 모델
    ↓
응답 반환

코드로 보면 다음과 같습니다.

import boto3

client = boto3.client("bedrock-runtime", region_name="us-east-1")

response = client.converse(
    modelId="anthropic.claude-opus-4-5",
    messages=[{"role": "user", "content": [{"text": "안녕?"}]}]
)

print(response["output"]["message"]["content"][0]["text"])

부가 기능들은 모두 선택적으로 추가할 수 있습니다.

내 앱
  ↓
[선택] Guardrails — 입출력 필터링
  ↓
[선택] Agents — 멀티스텝 자동화
  ↓
[선택] Knowledge Bases — RAG
  ↓
Bedrock API → Claude 모델

마무리

세 가지 방법은 각각 다른 상황에 최적화되어 있습니다.

• Anthropic 직접 계약: 최신 모델과 기능을 가장 빠르게 활용하고 싶을 때
• AWS Marketplace: AWS 계정으로 비용을 통합하면서 Claude.ai UI를 팀에 제공하고 싶을 때
• Bedrock: 프로덕션 AI 애플리케이션을 개발하고, AWS 인프라와 깊은 통합이 필요할 때

특히 AWS를 이미 사용 중인 조직이라면, Bedrock은 단순히 모델을 빌리는 것을 넘어 보안·컴플라이언스·운영까지 AWS 생태계 안에서 해결할 수 있다는 점에서 실질적인 이점이 큽니다.

도입 방법 선택에 고민 중이신 분들께 도움이 되었으면 합니다.
잘못된 내용이나 피드백은 must01940@gmail.com 으로 보내주시면 감사합니다.