Claude Opus 4.5 / Haiku 4.5 지원 추가
Amazon Bedrock 공식 문서 기준
Amazon Bedrock Reserved 티어, 이 조건 아니면 손해입니다
“온디맨드보다 안정적이니까 Reserved가 당연히 유리하겠지”라고 생각했다면, 한 번 더 보세요.
Reserved 티어는 사용하든 안 하든 24시간 고정 요금이 청구됩니다.
실제로 온디맨드 대비 비용이 역전되는 시점이 공식 문서에 명시돼 있습니다.
4개 티어가 생긴 진짜 이유
Amazon Bedrock은 2025년 11월, 기존 Standard 단일 체계에서 Reserved·Priority·Standard·Flex 4단계 티어 구조로 전환했습니다. AWS 공식 릴리스 노트에 따르면 이 변화의 배경은 단순합니다. “모든 워크로드를 동일하게 처리하는 건 과금도 처리 방식도 비효율적”이라는 것입니다. (출처: AWS What’s New, 2025.11.26)
실제 문제는 이랬습니다. 미션 크리티컬 트랜잭션과 백그라운드 배치 작업이 같은 큐에서 경쟁했고, 피크 시간대에 Standard 티어 요청이 throttling을 맞는 경우가 늘었습니다. 동시에 단순 반복 작업에도 프리미엄 가격이 적용되다 보니 비용 최적화 여지가 없었습니다.
4개 티어는 각각 목적이 다릅니다. Reserved는 용량 예약, Priority는 응답 우선권, Standard는 기본값, Flex는 비용 절감입니다. 항공권으로 비유하면 First Class·Business·Economy·Basic Economy에 해당합니다. AWS 공식 문서도 이 비유를 직접 씁니다.
Reserved 티어의 구조 — 고정 과금이 핵심
Reserved 티어의 핵심은 “분당 토큰 처리량(TPM, Tokens Per Minute)을 사전에 예약하는 방식”입니다. AWS 공식 문서에 따르면, 1,000 TPM당 고정 시간 요금을 지불하며 월 단위로 청구됩니다. 1개월 또는 3개월 단위로 약정 가능합니다. (출처: Amazon Bedrock 공식 문서, docs.aws.amazon.com/bedrock)
가장 중요한 점은 실제로 해당 용량을 사용하지 않아도 요금이 나온다는 것입니다. AWS가 공식 문서에 명시한 주의 사항입니다. “AWS 계정 관리자의 도움을 받아 예약을 삭제하기 전까지 청구는 계속됩니다.” 사용량이 0이어도 예약한 TPM 기준으로 24시간 과금됩니다.
💡 공식 발표문과 실제 청구 구조를 같이 놓고 보니 이런 차이가 보였습니다.
Reserved는 “예약 용량이 Standard 온디맨드 할당량과 별도로 운영”됩니다. 즉 Reserved를 계약해도 Standard·Priority·Flex 온디맨드 한도는 그대로 살아있어 동시에 사용 가능합니다. Reserved 용량을 초과하면 자동으로 Standard로 overflow됩니다. — 실제로 Reserved만 계약하면 손해인 이유가 여기 있습니다. 버스트 상황에서 추가 온디맨드 비용이 함께 발생합니다.
Reserved는 99.5% 가동 시간 목표(SLA)를 제공합니다. Standard·Priority 온디맨드가 “best-effort” 기반인 것과 다른 핵심 차이입니다. 이 0.5%의 차이가 금융·의료처럼 다운타임을 용인할 수 없는 산업에서 결정적입니다.
온디맨드보다 비쌀 수 있는 경우
Reserved 티어를 “당연히 저렴하겠지”라고 생각하면 청구서를 받고 당황할 수 있습니다. Medium Scale 기업 사례를 공식 자료와 교차 분석하면 이런 결과가 나옵니다.
💡 이 계산은 AWS 공식 요금 페이지 수치를 기반으로 직접 검증 가능합니다.
온디맨드 vs Reserved 비교 — Claude Sonnet 4.5 기준 (2026.03 기준)
| 항목 | Standard 온디맨드 | Reserved |
|---|---|---|
| 과금 방식 | 사용한 토큰만 | 24시간 고정 (사용 여부 무관) |
| 가동 보장 | Best-effort | 99.5% SLA 목표 |
| throttling 위험 | 피크 시 존재 | 예약 용량 내 없음 |
| 약정 기간 | 없음 | 1개월 또는 3개월 |
| 해지 방식 | 즉시 중단 가능 | 계정 팀 통해서만 삭제 |
실제 수치를 대입해 보겠습니다. 월 500만 건 요청, 평균 2,000 input / 500 output 토큰, Claude Sonnet 4.5 기준입니다.
온디맨드 계산:
Input: 5M × 2,000 × $3/1M = $30,000
Output: 5M × 500 × $15/1M = $37,500
월 합계: $67,500
Reserved 시나리오 (4 MU 기준, Claude Sonnet 4.5):
4 MU × 시간 요금 × 730시간/월 = 약 $113,000 이상
(실제 MU 시간 요금은 AWS 계정팀 문의 필요 — AWS가 공개 고시하지 않음)
이 경우 Reserved가 온디맨드보다 약 67% 비쌉니다. 성능 보장이 필요하지 않은 워크로드라면 Reserved는 손해입니다. 이 수치가 실제로 의미하는 바는 단순합니다. Reserved는 “가격 절감 수단”이 아니라 “SLA 구매 수단”입니다.
2026년 1월, Claude 4.5 계열 지원 추가 후 달라진 점
2026년 1월 16일, AWS는 Amazon Bedrock Reserved 티어에 Claude Opus 4.5와 Claude Haiku 4.5를 추가했습니다. (출처: AWS What’s New, 2026.01.16) 이전까지는 Claude Sonnet 계열만 Reserved 티어에서 사용 가능했습니다.
이 변화가 중요한 이유가 있습니다. Opus 4.5는 복잡한 추론 작업용 플래그십 모델이고, Haiku 4.5는 빠른 응답이 필요한 경량 작업용입니다. 두 모델 모두 Reserved 티어에서 예약 가능해지면서, 이제 고성능 추론 + 경량 요청을 혼합하는 엔터프라이즈 아키텍처에서 Reserved를 선택지로 진지하게 고려할 수 있게 됐습니다.
💡 공식 지원 모델 목록과 실제 사용 시나리오를 같이 놓고 보니 눈에 띄는 조합이 있습니다.
Reserved 티어 모델 목록에는 Claude Sonnet 4.6, Opus 4.6, Sonnet 4.5, Opus 4.5, Haiku 4.5가 포함돼 있습니다. 주목할 점은 Claude Sonnet 4.5의 경우 Reserved 티어에서 1M 컨텍스트 길이가 지원되지 않습니다. 공식 문서에 명시된 제한입니다. (출처: Amazon Bedrock 공식 문서, docs.aws.amazon.com/bedrock) 긴 컨텍스트가 핵심 요건이라면 Reserved가 아닌 Standard를 써야 합니다.
지원 리전은 현재 ap-northeast-2(서울 리전)를 포함한 아시아태평양, 유럽, 미주 전 리전으로 확대됐습니다. 한국 기업이 서울 리전 기반으로 Reserved 티어를 사용할 수 있는 환경이 갖춰진 셈입니다.
Reserved가 실제로 유리한 딱 하나의 조건
AWS 공식 문서와 실제 기업 비용 데이터를 교차 분석했을 때, Reserved가 온디맨드 대비 실질적으로 유리해지는 조건은 정확히 하나입니다.
→ “트래픽이 예측 가능하고, 24시간 지속적으로 높은 처리량을 유지하며, 다운타임이 사업적으로 허용되지 않는 워크로드”
세 조건을 하나씩 봐야 합니다. 먼저 “예측 가능”은 트래픽이 일정하다는 의미입니다. 피크-트로프가 2배 이상 차이 나는 패턴이면 Reserved는 비효율적입니다. 사용하지 않는 시간의 용량을 고정 요금으로 계속 내는 구조이기 때문입니다.
“24시간 지속”은 야간이나 주말에 트래픽이 현저히 줄어드는 서비스라면 Reserved가 손해라는 의미입니다. AWS 공식 최적화 가이드도 이 점을 직접 지적합니다. “CloudWatch 지표로 P50·P90·P99 기준선을 잡아 예약 결정을 내리라”고 권고합니다. 막연히 ‘많이 쓰니까’라는 판단으로 Reserved를 계약하면 과금 낭비가 발생합니다. (출처: AWS repost 공식 아티클)
💡 Reserved가 유리한지 판단하는 손익분기점 공식 (AWS 공식 문서 기반)
월 온디맨드 비용 > 예약 TPM × 고정 시간 요금 × 730시간
→ 이 등식이 성립할 때만 Reserved가 비용 측면에서도 유리
실무 기준: 월 온디맨드 지출이 Reserved 월 고정 약정보다
30~50% 이상 높을 때 전환 검토 (출처: AWS Bedrock 공식 최적화 문서)
다운타임 허용 불가 조건은 단순히 SLA 수치 문제가 아닙니다. 금융 거래 처리, 의료 실시간 시스템, 고객 대면 결제 플로우처럼 throttling이 발생하는 순간 비즈니스 손실이 추론 비용을 초과하는 경우에만 Reserved의 프리미엄이 정당화됩니다. 그 외에는 Priority 온디맨드가 더 유연한 선택입니다.
Flex·Priority와 비교하면 나오는 그림
4개 티어를 한 줄씩 정리해 두면 실제 설계 결정이 훨씬 빨라집니다.
| 티어 | 가격 구조 | 최적 워크로드 | latency 보장 |
|---|---|---|---|
| Reserved | 고정 시간 요금 (24/7) | 예측 가능·고처리량·다운타임 불가 | 99.5% SLA |
| Priority | Standard 대비 75% 프리미엄 | 산발적·고가치·지연 불허 요청 | 최대 25% OTPS 개선 |
| Standard | 기본 토큰 요금 (사용량 기반) | 일반 프로덕션·코드 생성·챗봇 | Best-effort |
| Flex | Standard 대비 50% 할인 | 배치·요약·모델 평가·비실시간 | 지연 허용 (분 단위 가능) |
* 출처: Amazon Bedrock 공식 문서 및 AWS repost 공식 아티클 (2026.03 기준)
Priority 티어에서 눈여겨볼 부분이 있습니다. Standard 대비 최대 25% 빠른 output tokens/second를 제공하면서, Reserved처럼 24시간 약정 없이 요청 단위로 tier를 지정할 수 있습니다. 트래픽이 불규칙하지만 특정 요청만 우선 처리가 필요한 상황이라면, Reserved보다 Priority가 더 유연한 선택입니다.
Flex 티어는 반대 극단에 있습니다. 50% 할인이지만 처리 시간이 분 단위로 늘어날 수 있고 1시간 타임아웃이 적용됩니다. 모델 평가, 콘텐츠 분류, 대규모 요약처럼 즉시 응답이 불필요한 워크로드에만 어울립니다.
Reserved 티어에도 overflow 기능이 있습니다. 예약한 TPM을 초과하면 자동으로 Standard 온디맨드로 넘어가기 때문에 서비스 중단 없이 트래픽 급증을 소화할 수 있습니다. 단, 그 overflow 비용은 별도 청구됩니다. Reserved만 계약했다고 전부 커버되는 게 아닙니다.
Q&A — 5가지 실전 질문
Q1. Reserved 티어와 Provisioned Throughput은 같은 건가요?
Q2. Reserved 티어를 해지하고 싶으면 어떻게 하나요?
Q3. Claude Sonnet 4.5에서 100만 토큰 컨텍스트가 Reserved에서 안 된다는 게 무슨 의미인가요?
Q4. 한국 서울 리전에서도 Reserved 티어를 쓸 수 있나요?
Q5. Reserved 티어와 Standard를 동시에 쓸 수 있나요?
마치며 — Reserved는 보험이지 할인이 아닙니다
Amazon Bedrock Reserved 티어는 비용 최적화 도구가 아닙니다. 정확히는 “서비스 안정성에 대한 선불 보험”입니다. 온디맨드보다 총 비용이 높을 수 있고, 사용량에 관계없이 고정 청구가 발생하며, 해지 절차도 복잡합니다.
이 구조가 맞는 경우는 하나입니다. 트래픽이 예측 가능하고, 24시간 지속되며, throttling 한 번이 사업적 손실로 이어지는 워크로드입니다. 그 외에는 Priority 온디맨드가 더 유연하고, 비용도 더 통제하기 쉽습니다.
2026년 1월 Claude Opus 4.5·Haiku 4.5 지원이 추가되면서 선택 폭이 넓어진 건 맞습니다. 하지만 Claude Sonnet 4.5의 1M 컨텍스트 제한처럼, 공식 문서에 조용히 명시된 예외 조건들을 먼저 확인하고 설계에 반영해야 합니다.
Reserved 티어 도입 전에 CloudWatch 지표로 P50·P90 기준선을 먼저 잡아보세요. 그 숫자가 Reserved를 쓸지 말지를 알려줍니다.
📎 본 포스팅 참고 자료
- Amazon Bedrock 서비스 티어 공식 문서 (AWS, 2026.03 현재)
- Amazon Bedrock Reserved 티어 Claude Opus 4.5·Haiku 4.5 지원 추가 (AWS, 2026.01.16)
- Balance cost, performance & reliability for AI at enterprise scale through Bedrock Inference Tiers (AWS repost 공식 아티클)
- Amazon Bedrock 용량 한도 및 비용 최적화 공식 문서 (AWS)
- Amazon Bedrock 공식 요금 페이지 (AWS)
본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. 최신 정보는 AWS 공식 문서 및 요금 페이지에서 반드시 확인하세요. 본 포스팅은 특정 서비스 구매를 권유하지 않습니다.
댓글 남기기