Home / Amazon Bedrock 추론 인프라 / 추론 인프라
Module

추론 인프라

Inference Profile, Service Tiers, Batch, Provisioned, Prompt Routing

⏱ 45분 29 / 189

Amazon Bedrock 추론 인프라

Inference Profile · Service Tiers · Batch · Provisioned · Prompt Routing

모델 호출의 비용·성능·가용성을 제어하는 인프라 계층

추론 프로파일부터 서비스 티어, 비용 최적화까지 프로덕션 운영 설계

추론 인프라 개요

단일 리전의 한계 · 3계층 구조

PART 1 · 추론 인프라 개요

API 한 줄 뒤의 인프라 질문

호출 코드는 한 줄 — 처리 위치·순서·비용은 코드 밖에서 결정

호출은 한 줄

python
resp = runtime.converse(
    modelId='anthropic.claude-sonnet-4-6',
    messages=[
        {'role': 'user',
         'content': [{'text': '...'}]},
    ],
)

호출 뒤에서 결정되는 것들

  • 어디서 처리되나 — 어느 리전이 받는가, 그 리전에 용량은 있는가
  • 어떤 우선순위로 처리되나 — 트래픽이 몰릴 때 누가 먼저인가 (SLA)
  • 얼마에 처리되나 — 같은 토큰을 정가로 내는가, 할인·전용 용량을 쓰는가
takeaway

이 세 가지에 답하는 제어 계층이 추론 인프라입니다 — 지정하지 않으면 전부 암묵적 기본값으로 동작합니다.

PART 1 · 추론 인프라 개요

세 가지 문제, 세 가지 해결 계층

modelId='anthropic.claude-sonnet-4-6' 직접 호출의 공백과 각 축의 제어 수단

기본값으로 두면 제어 계층을 쓰면
어디서 단일 리전 고정 — 용량 소진 429 · 리전 장애 시 중단 · 최신 모델 미배포 Inference Profile — 여러 리전에 자동 분산, 막히면 우회
어떤 우선순위로 전 요청 동일 취급 — SLA 없는 베스트 에포트뿐 Service Tier — 요청별 우선순위·SLA 선택
얼마에 전부 On-Demand 정가 — 반복·비긴급 작업도 전액 최적화 방식 — Batch 50% 할인 · Prompt Caching · 전용 용량
takeaway

한 계층이 다른 축의 문제까지 풀어주지는 않습니다 — 세 계층을 독립적으로 조합하는 것이 추론 인프라 설계입니다.

PART 1 · 추론 인프라 개요

추론 인프라 3계층

어디서 · 어떤 우선순위로 · 어떻게 — 세 가지 제어 축

Inference Profile — 어디서 처리할까

요청을 여러 리전에 자동 분산하는 라우팅 (Cross-Region · Global · Application)

Service Tier — 어떤 우선순위로

같은 모델을 다른 우선순위·SLA로 호출 (Reserved · Priority · Standard · Flex)

최적화 방식 — 어떻게 싸고 빠르게

Batch(50% 할인) · Provisioned(전용 용량) · Prompt Caching(반복 절감)

Inference Profile

Cross-Region · Global · Application

PART 2 · Inference Profile

모델을 식별하는 4가지 방법

modelId에 무엇을 넣느냐가 라우팅 범위를 결정

파운데이션 모델 ID

anthropic.claude-sonnet-4-6

  • 단일 리전(In-Region) 고정
  • 트래픽 급증 시 즉시 429
  • 프로덕션 사용 지양

언제 — 단발 테스트·로컬 실험 수준

Global 프로파일

global. 접두사

  • 전 세계 리전 분산 — 최대 처리량
  • ~10% 비용 절감 가능

언제 — 데이터 주권 제약이 없을 때

Application 프로파일

사용자 생성 ARN

  • System-defined를 래핑
  • 태깅 · 비용 추적 · 접근 제어

언제 — 팀/프로젝트별 비용 분리

takeaway

modelId 문자열이 곧 라우팅 선언입니다 — 프로덕션 기본값은 Cross-Region 프로파일입니다.

PART 2 · Inference Profile

Cross-Region 자동 분산

코드 변경 없이 modelId만 바꾸면 끝 — 막힌 리전은 자동 우회

takeaway

한 리전이 막혀도 호출은 실패하지 않습니다 — 가용 리전으로 자동 우회하고, 실제 처리 리전은 원본 리전 CloudTrail 로그의 inferenceRegion 필드로 확인합니다.

PART 2 · Inference Profile

Global vs Cross-Region

갈림길은 데이터 주권 — 제약이 없다면 Global이 처리량 최대

PART 2 · Inference Profile

Application 프로파일로 비용 추적

System-defined를 래핑해 팀별 태그 부여 — 비용 할당·접근 제어·감사의 단위

생성과 호출

python
bedrock = boto3.client('bedrock', region_name='us-east-1')

# Cross-Region 프로파일을 래핑해 팀 태그 부여
response = bedrock.create_inference_profile(
    inferenceProfileName='team-alpha-claude',
    modelSource={'copyFrom': 'us.anthropic.claude-sonnet-4-6'},
    tags=[
        {'key': 'team', 'value': 'alpha'},
        {'key': 'environment', 'value': 'production'},
    ],
)
profile_arn = response['inferenceProfileArn']

# modelId에 프로파일 ARN 전달 — 비용이 팀 태그로 귀속
resp = runtime.converse(
    modelId=profile_arn,
    messages=[{'role': 'user', 'content': [{'text': '안녕하세요'}]}],
)

활용 시나리오

  • 비용 할당 — 팀/프로젝트별 태그로 Cost Explorer 분석
  • 접근 제어 — IAM에서 프로파일 ARN만 허용
  • 워크로드 격리 — 프로덕션/개발 프로파일 분리
  • 감사 — CloudTrail에서 프로파일별 호출 추적

Service Tiers

Reserved · Priority · Standard · Flex

PART 3 · Service Tiers

4단계 Service Tier

같은 모델, 다른 우선순위와 가격 — 지원 티어는 모델별 상이(모델 카드 확인)

항목ReservedPriorityStandardFlex
용량예약 전용 용량On-Demand 우선 큐On-Demand 기본On-Demand 최저가
약정1·3개월없음없음없음
성능처리량·지연 보장 (99.5% uptime)최대 25% 빠른 OTPS베스트 에포트가용 시 처리 (거부 가능)
용도24/7 미션크리티컬스파이크 · 간헐적 크리티컬개발 · 일상 작업배치 · 비긴급 대량
takeaway

위로 갈수록 보장이, 아래로 갈수록 가격이 내려갑니다 — 기본은 Standard, 조정은 요청 단위 serviceTier로 합니다.

PART 3 · Service Tiers

serviceTier 파라미터

요청별로 티어를 동적 지정 — 미지정 시 Standard(default)

Standard (기본)
Flex — 최저 비용
Priority — 우선 처리
Reserved — 예약 보장
PART 3 · Service Tiers

티어 운영 주의점

요청 티어와 실제 서빙 티어의 불일치 가능성

takeaway

요청한 티어와 서빙된 티어는 다를 수 있습니다 — 과금은 ResolvedServiceTier 기준입니다.

Batch Inference

50% 할인 · S3 비동기 대량 처리

PART 4 · Batch Inference

실시간 vs Batch

실시간이 필요한데 저비용이면 Flex, 비동기가 가능하면 Batch가 더 저렴

실시간 (On-Demand)

Standard · Priority · Flex

  • 요청 즉시 응답
  • 토큰당 정가 (Flex는 할인)
  • 동시성 한도 적용
  • 챗봇 · 에이전트 · 대화형 앱

Batch

비동기 Job

  • S3 JSONL → Job → S3 출력
  • On-Demand 대비 50% 할인
  • 동시성 한도와 무관
  • 요약 · 라벨링 · 정기 보고서
takeaway

실시간이면서 저비용이면 Flex, 비동기가 가능하면 Batch가 항상 더 저렴합니다.

PART 4 · Batch Inference

Batch = 50% 할인 비동기 처리

S3 입력 → Job → S3 출력 — 앱은 제출과 수신만

takeaway

50% 할인의 대가는 SLA 없음입니다 — 마감이 있는 작업은 On-Demand에 남깁니다.

PART 4 · Batch Inference

Batch Job 생성

문서 요약 5만 건을 절반 가격으로 — 야간 파이프라인에 최적

python
bedrock = boto3.client('bedrock', region_name='us-east-1')

response = bedrock.create_model_invocation_job(
    jobName='document-summary-batch',
    modelId='us.anthropic.claude-sonnet-4-6',
    roleArn='arn:aws:iam::123456789012:role/BedrockBatchRole',
    inputDataConfig={
        's3InputDataConfig': {
            's3Uri': 's3://my-bucket/batch-input/requests.jsonl',
        },
    },
    outputDataConfig={
        's3OutputDataConfig': {
            's3Uri': 's3://my-bucket/batch-output/',
        },
    },
)

job_arn = response['jobArn']
  • 입력은 S3의 JSONL — 한 줄이 요청 1건: {"recordId": "1", "modelInput": {"messages": [...]}}
  • create_model_invocation_job — 실시간 API가 아닌 비동기 Job 제출
  • roleArn — 입력·출력 S3 버킷을 읽고 쓸 IAM 역할
  • 출력도 S3 — 결과 JSONL이 지정 경로에 저장
  • jobArn으로 상태 폴링 — Completed 후 출력 경로 확인

Provisioned Throughput

MU 전용 용량 · 레거시 모델 전용 예약 방식

PART 5 · Provisioned Throughput

전용 용량 예약

MU(Model Unit) 단위 구매 — 다른 고객 트래픽의 영향을 차단

Model Unit 단위 시간당 과금 — 사용하지 않아도 계속

1·3개월 커밋 · 99.5% uptime 목표 · Cross-Region 프로파일과 조합 불가 (단일 리전 전용)

  • 전용 용량
  • 일관된 지연 시간
  • 초과 트래픽은 429 — 자동 폴백 없음
takeaway

쓰지 않아도 과금되는 전용 용량입니다 — 트래픽이 증명되기 전에는 계약하지 않습니다.

PART 5 · Provisioned Throughput

도입 판단과 설계

트래픽이 증명되기 전에는 On-Demand가 답

판단 신호

데이터로 확인

  • break-even — 월간 On-Demand 토큰 비용 vs MU 시간당 비용
  • InvocationThrottles — CloudWatch에서 스로틀링 지속 발생
  • 두 신호가 겹칠 때만 커밋 검토

설계 원칙

커밋은 최소로

  • 안정적 기저 트래픽만 전용 용량으로
  • 스파이크는 Standard/Priority로 흡수
  • PoC·신규 워크로드는 On-Demand 유지
takeaway

전환 신호는 데이터로 확인합니다 — break-even 분석과 InvocationThrottles 지표가 판단 기준입니다.

PART 5 · Provisioned Throughput

Provisioned 생성과 호출

provisionedModelArn을 modelId에 그대로 전달

레거시 모델 전용 · 삭제 전까지 과금 지속

Provisioned Throughput은 Claude 3.5 Sonnet v2까지의 레거시 모델 전용입니다 — 신형 모델은 Service Tiers를 사용하세요(지원 티어는 모델별 상이 — Reserved는 Sonnet 4.6·Opus 4.6 지원, Opus 4.8·Sonnet 5·Opus 5는 Standard만). 사용 여부와 무관하게 시간당 과금됩니다. Reserved 예약 해지는 셀프서비스가 아니라 AWS 계정팀 요청이 필요합니다 — PoC는 On-Demand로 진행하세요.

python
import boto3

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

# 최소 1개월 커밋 — modelUnits 단위로 전용 용량 확보
# PT는 레거시 모델 전용 — Claude 3.5 Sonnet v2가 지원 상한
response = bedrock.create_provisioned_model_throughput(
    modelUnits=1,
    provisionedModelName='prod-sonnet-legacy',
    modelId='anthropic.claude-3-5-sonnet-20241022-v2:0',
    commitmentDuration='OneMonth',
)
provisioned_arn = response['provisionedModelArn']

# 호출은 동일 — modelId에 프로비저닝 ARN 전달
runtime = boto3.client('bedrock-runtime', region_name='us-east-1')
response = runtime.converse(
    modelId=provisioned_arn,
    messages=[{'role': 'user', 'content': [{'text': '안녕하세요'}]}],
)

운영 전략

적용 순서 · 캐싱 · 에러 핸들링 · VPC · 모니터링

PART 6 · 운영 전략

최적화 적용 순서

무료·즉시 효과부터 — 커밋이 필요한 것은 마지막에

  1. 1
    Cross-Region 프로파일

    무료, 즉시 효과 — 스로틀링·가용성 개선

  2. 2
    Prompt Caching

    반복 시스템 프롬프트가 있으면 입력 토큰 즉시 절감

  3. 3
    서비스 티어 조정

    비실시간 요청을 Flex로 분리

  4. 4
    Batch 전환

    대량 파이프라인 식별 후 50% 할인 적용

  5. 5
    전용 용량 검토

    안정 트래픽 + break-even 도달 시에만 — Reserved(신형) · PT(레거시)

takeaway

순서 원칙은 무료·무커밋 먼저, 커밋은 마지막입니다 — Cross-Region과 캐싱만으로도 대부분 해결됩니다.

PART 6 · 운영 전략

Prompt Caching 원리

한 번 계산한 프리픽스는 KV Cache로 호출 간 재사용 — 새 부분만 계산




요청 ①



시스템 프롬프트 + 매뉴얼 150KB
질문 A "배송 기간은?"

전체 계산

🗄️ 캐시 기록 — 쓰기 1.25×

cachePoint 앞까지의 고정 프리픽스가 캐시 대상




요청 ②



🗄️ 같은 프리픽스 — 캐시 읽기 0.1×
질문 B "환불 규정은?"
← 새 부분만 계산

입력 비용 최대 90% 절감

TTL 기본 5분 — 캐시 히트마다 갱신 · 체크포인트 요청당 최대 4개(system·messages·tools) · AWS 계정 단위 격리




최소 캐시 토큰은 모델마다 다릅니다 — Sonnet 4.6 = 1,024 · Opus 5 = 512 · Opus 4.8 · Sonnet 5 · Haiku 4.5 = 4,096 (Bedrock 기준, 프리픽스가 미만이면 캐시 미적용)


PART 6 · 운영 전략

Prompt Caching 적용

cachePoint 한 줄이 전부 — 시스템 프롬프트·문서를 캐시 지점 앞에

python
# System Prompt Caching — cachePoint 블록으로 캐시 지점 지정
system_prompt = """당신은 고객 서비스 전담 AI입니다.
[매뉴얼: 100KB 정책 문서]
[FAQ: 50KB 자주 묻는 질문]
"""

response = bedrock_runtime.converse(
    modelId='us.anthropic.claude-sonnet-4-6',
    system=[
        {'text': system_prompt},
        {'cachePoint': {'type': 'default'}},  # ← 여기까지 캐싱
    ],
    messages=[
        {'role': 'user', 'content': [{'text': '배송 기간은?'}]}
    ]
)

# 첫 요청: 매뉴얼 + FAQ를 전부 읽고 캐시에 기록
# 두 번째 요청부터: 캐시 재사용 — 입력 토큰 비용 최대 90% 절감
# Bedrock의 Sonnet 4.6은 최소 1,024 토큰부터 캐싱 적용
  • cachePoint 블록 앞까지가 캐시 대상 — 시스템 프롬프트·문서를 앞쪽에 배치
  • 두 번째 요청부터 캐시 재사용 — 입력 토큰 비용 최대 90% 절감
  • Sonnet 4.6은 최소 1,024 토큰부터 캐싱 적용
PART 6 · 운영 전략

Intelligent Prompt Routing — 레거시 전용

복잡도 기반 자동 모델 선택 — 단, 최신 모델은 미지원

Claude 3.x/3.5, Nova Lite/Pro, Llama 3.x만 지원합니다. Claude 4.x 이상(Sonnet 4.6 · Opus 4.8 · Fable 5 등 신형)에서는 사용할 수 없습니다.

Prompt Routing

레거시 모델 전용

  • 같은 패밀리 내 모델 쌍만
  • Claude 3 Haiku ↔ 3.5 Sonnet
  • Nova Lite ↔ Pro · Llama 3.1 8B ↔ 70B
  • Claude 4.x 이상 미지원

AgentCore Gateway 라우팅

최신 대안

  • Gateway Inference Target으로 라우팅
  • 여러 모델을 하나의 엔드포인트 뒤에
  • Claude 4.x 포함 전 모델
  • 모델 패밀리 제한 없음
takeaway

Prompt Routing은 레거시 모델 전용입니다 — 최신 모델 라우팅은 AgentCore Gateway가 대안입니다.

PART 6 · 운영 전략

운영 아키텍처

프라이빗 네트워크 · 재시도 · 캐싱 · 모니터링을 함께 구성

takeaway

네트워크·재시도·캐싱·모니터링은 호출 코드와 함께 처음부터 설계해야 하는 운영 4요소입니다.

PART 6 · 운영 전략

에러 핸들링

프로덕션 안정성 — ThrottlingException 재시도 전략

ThrottlingException 처리 필수

단일 리전 한계 도달 시 발생. 지수 백오프(exponential backoff)로 재시도: 1초 → 2초 → 4초 → 8초. 최대 5회 재시도 권장 (boto3 standard 재시도 모드 기본은 최대 3회 시도). 프로덕션에는 추론 프로파일(Cross-Region) 사용으로 근본 해결.

boto3 재시도 설정

python
import boto3
from botocore.config import Config

# boto3 재시도 설정 — standard 모드는 지수 백오프 + 지터 적용
config = Config(
    retries={
        'max_attempts': 5,   # 총 시도 횟수 (standard 모드 기본 3)
        'mode': 'standard',
    }
)

bedrock_runtime = boto3.client('bedrock-runtime', config=config)

# ThrottlingException은 재시도 대상 — 설정만으로 자동 처리
response = bedrock_runtime.converse(
    modelId='us.anthropic.claude-sonnet-4-6',
    messages=[
        {'role': 'user', 'content': [{'text': '안녕하세요'}]}
    ],
)
PART 6 · 운영 전략

VPC Endpoint

PrivateLink로 인터넷을 거치지 않고 Bedrock 접근 — 데이터 주권

퍼블릭 엔드포인트

  • bedrock-runtime.{region}.amazonaws.com
  • NAT Gateway 등 퍼블릭 경로 경유
  • 프라이빗 연결 요건이 있는 규제 환경에서는 VPC 엔드포인트 권장
  • 구성은 간단, 네트워크 경로 통제는 제한적

언제 — 개발 환경, 테스트용

VPC Endpoint

  • com.amazonaws.{region}.bedrock-runtime
  • PrivateLink로 프라이빗 서브넷에서 직접 접근
  • 데이터가 AWS 내부 네트워크에서만 이동
  • 규정 준수 (HIPAA, PCI-DSS, FedRAMP)

언제 — 프로덕션, 규정 준수 필요

takeaway

규제 환경의 갈림길입니다 — 데이터가 AWS 내부망을 벗어나면 안 되면 VPC Endpoint를 씁니다.

PART 6 · 운영 전략

워크로드별 추론 방식

레이턴시 요구 · 트래픽 패턴 · 비용 목표로 결정

시나리오추론 방식이유
고객 대면 챗봇 (24/7)Reserved 티어SLA · 일관된 응답 시간
변동 트래픽 서비스On-Demand + Cross-Region유연성 + 스로틀링 방지
간헐적 긴급 분석On-Demand Priority예약 없이 우선 처리
야간 대량 문서 처리Batch50% 할인, 시간 무관
에이전트 도구 호출On-Demand Standard/Priority불규칙 호출 패턴
takeaway

정답은 조합입니다 — 레이턴시 요구와 트래픽 패턴이 워크로드별 추론 방식을 정합니다.

PART 6 · 운영 전략

CloudWatch 모니터링

전환 시점을 알려주는 지표들

InvocationThrottles
지속 발생 = Priority/전용 용량(Reserved·PT) 전환 신호
InvocationLatency
응답 시간 — P95 추적으로 티어 효과 확인
InputTokenCount · OutputTokenCount
토큰 사용량 — break-even 분석의 입력값
ServiceTier · ResolvedServiceTier
요청 티어 vs 실제 서빙 티어 차원
inferenceRegion (CloudTrail)
Cross-Region이 실제 처리한 리전 확인
takeaway

지표가 전환 타이밍을 알려줍니다 — 스로틀 · 지연 · 토큰 · 티어 네 축을 상시 추적합니다.

실습 — 추론 최적화

⏱ 45분

워크로드에 맞는 추론 방식을 직접 설정하고 비용을 비교합니다

학습 목표

  • Batch Inference — JSONL 준비부터 잡 생성 · 결과 회수까지
  • 처리량 확보 — Service Tiers와 레거시 PT 비교
  • Prompt Routing 설정과 비용 확인
설정 한 줄의 최적화부터, 약정은 트래픽이 증명한 뒤에.

Inference Profile · Service Tiers · Batch · Provisioned — 워크로드에 맞는 조합이 답입니다.