Amazon Bedrock Claude 서울 리전 in-region 추론 설정에서 가장 흔한 오해는 클라이언트의 region_name을 ap-northeast-2로 지정하면 요청이 서울 안에서 처리된다는 생각이다. 요청을 받는 리전과 실제로 추론을 처리하는 리전은 다를 수 있다. 처리 위치를 정하는 요소는 model ID의 접두사와 엔드포인트 유형이다.
AWS는 2026년 9월 29일 서울·싱가포르 in-region 추론 발표 블로그에서 서울 리전에서 Claude Opus 5와 Claude Sonnet 5를 in-region 추론으로 호출할 수 있다고 발표했다. 조건은 bedrock-runtime 엔드포인트와 접두사 없는 model ID다. 같은 서울 리전에서 global. 접두사가 붙은 ID를 쓰면 cross-Region 라우팅 대상이 된다. Anthropic 문서가 다루는 bedrock-mantle 엔드포인트의 In-Region 목록에는 서울이 들어 있지 않다.
이 글은 2026-10-01 기준 공개 문서를 근거로 한다. 요청이 서울 밖에서 처리되는 원인을 유형별로 나누고, 원인별 해결책과 방식별 비교를 거쳐 운영 단계에서 확인할 항목까지 이어서 설명한다.
목차
서울 리전 in-region 추론이 보장하는 범위
in-region 추론은 요청을 지정한 AWS 리전 한 곳에서만 처리하는 방식이다. 발표 블로그는 요청이 그 리전을 벗어나지 않는다고 설명하고, cross-Region 추론과의 차이를 한 문장으로 적는다.
"Unlike cross-Region inference profiles, there is no routing layer."
라우팅 계층이 없다는 말은 두 가지 결과로 이어진다. 데이터 처리 위치가 호출한 리전으로 고정되는 대신, 처리량도 그 리전의 용량으로 제한된다. 다른 리전의 여유 용량을 빌려 쓰는 경로가 없는 구조다.
과금과 쿼터도 리전 단위로 묶인다. 블로그 원문은 "Billing follows standard on-demand pricing for the Region you call."과 "Requests are subject to per-Region service quotas."다. 쿼터 소비, CloudWatch 지표, CloudTrail 로그가 모두 같은 리전 범위로 기록된다는 점도 함께 명시되어 있다. 운영 측면에서 보면 서울 in-region 워크로드의 모니터링 대상은 전부 ap-northeast-2 콘솔과 API 안에 모인다.
서울과 싱가포르에서 쓸 수 있는 모델
발표 블로그와 AWS 모델 카드의 bedrock-runtime 가용성 표를 합치면 두 리전의 상태는 다음과 같다.
| 리전 | Claude Opus 5 | Claude Sonnet 5 |
|---|---|---|
| ap-northeast-2 (서울) | In-Region 지원, Geo 미지원, Global 지원 | In-Region 지원, Geo 미지원, Global 지원 |
| ap-southeast-1 (싱가포르) | In-Region 미지원, Global만 지원 | In-Region 지원 |
Claude Opus 5 모델 카드에 따르면 Opus 5의 출시일은 2026-07-24이고, context window는 1M tokens, max output은 128K다. 싱가포르에서 데이터가 리전 안에 머물러야 하는 워크로드라면 선택지는 Sonnet 5로 좁혀진다.
발표 블로그가 서울 in-region 모델로 명시한 것은 이 두 모델뿐이다. 다른 Claude 모델의 서울 in-region 여부는 각 모델 카드의 가용성 표에서 직접 확인해야 한다.
요청이 서울 밖에서 처리되는 세 가지 원인
"서울 리전을 지정했는데 처리 리전이 서울이 아니다"라는 문제는 원인이 세 유형으로 나뉜다. model ID 접두사, 엔드포인트 유형, 모델과 리전의 조합이다. 아래 흐름은 요청 하나가 in-region으로 처리되기까지 통과해야 하는 조건을 순서대로 나타낸다.
flowchart TD
A[서울 리전 클라이언트 요청] --> B{엔드포인트}
B -->|bedrock-mantle| X[서울 In-Region 목록에 없음]
B -->|bedrock-runtime| C{model ID 접두사}
C -->|global.| G[Global cross-Region 라우팅]
C -->|us. eu. au. in.| H[Geo 프로필: 서울 미지원]
C -->|접두사 없음| D{서울 in-region 지원 모델}
D -->|Opus 5, Sonnet 5| OK[ap-northeast-2에서 처리]
D -->|그 외| Y[모델 카드 확인 필요]원인 1: model ID 접두사가 라우팅을 바꾼다
Bedrock의 Claude model ID는 접두사로 라우팅 방식을 구분한다. Claude Sonnet 5 모델 카드에 나온 ID 체계는 세 갈래다.
- 접두사 없음(
anthropic.claude-sonnet-5): In-Region 추론 global.anthropic.claude-sonnet-5: Global cross-Region 추론us.,eu.,au.,in.접두사: 해당 지역 단위 Geo 추론
Opus 5도 같은 구조로, Global ID는 global.anthropic.claude-opus-5다. 서울 행에서 두 모델 카드 모두 Geo를 미지원으로 표기하고, Geo inference ID 목록에 한국용 접두사는 없다. 서울 리전 클라이언트에서 선택 가능한 ID는 사실상 접두사 없는 in-region ID와 global. ID 둘이다.
문제가 생기는 지점은 global. ID다. 코드나 설정 파일에 한 번 들어간 Global ID는 region_name이 ap-northeast-2여도 cross-Region 라우팅을 탄다. 해결책은 model ID를 접두사 없는 형태로 바꾸고, 배포 파이프라인에서 접두사가 붙은 ID를 거르는 것이다.
원인 2: bedrock-mantle 엔드포인트는 서울 in-region을 지원하지 않는다
Bedrock에서 Claude를 호출하는 엔드포인트는 bedrock-runtime과 bedrock-mantle 두 계열이다. 모델 카드의 bedrock-mantle 표에서 In-Region을 지원하는 리전은 us-east-1, us-gov-west-1, eu-north-1, eu-west-1, ap-southeast-4 다섯 곳뿐이다. 서울은 이 목록에 없다.
Claude in Amazon Bedrock 문서가 이 차이를 헷갈리게 만드는 원인이기도 하다. 이 문서는 bedrock-mantle 엔드포인트의 Messages API를 다루고, 엔드포인트 패턴은 https://bedrock-mantle.{region}.api.aws/anthropic/v1/messages다. Python에서는 pip install -U "anthropic[bedrock]"로 설치한 뒤 AnthropicBedrockMantle 클라이언트를 쓴다. 이 문서의 리전 표에서 ap-northeast-2의 Endpoint types는 "Global"만 적혀 있고, "In-region only" 표기는 없다.
Anthropic 문서만 읽고 `AnthropicBedrockMantle`로 서울을 호출하면 in-region 경로를 쓸 수 없다. 서울 in-region은 AWS 모델 카드의 `bedrock-runtime` 표에서만 지원으로 표시된다. 해결책은 엔드포인트를 `https://bedrock-runtime.{region}.amazonaws.com` 계열로 고정하는 것이다.
세 번째 유형은 설정 실수보다 요구사항 충돌에 가깝다. 싱가포르에서 Opus 5를 쓰려는 경우처럼 모델이 해당 리전의 in-region을 지원하지 않으면 Global 외에 선택지가 없다.
기능 요구도 경로를 흔든다. 모델 카드 기준 bedrock-runtime 엔드포인트는 Messages, Converse, Invoke API를 지원하고 Responses, Chat Completions는 지원하지 않는다. bedrock-runtime에서 쓸 수 없는 기능은 Intelligent prompt routing, Count tokens, Structured outputs다. Sonnet 5 카드 기준 Service Tier는 Standard만 지원하고 Priority, Flex, Reserved는 지원 대상이 아니다.
Structured outputs가 필요해 bedrock-mantle로 옮기려는 판단은 해결책이 되지 않는다. Anthropic 문서는 bedrock-mantle 경로에서도 Structured outputs를 지원하지 않는다고 적고, Files API, 서버 측 도구(code execution, web search, web fetch, advisor), Agent Skills·MCP connector, Message Batches도 같은 목록에 올려 두었다. 두 경로 모두 이 기능이 없으므로 서울 in-region을 유지하려면 애플리케이션 쪽에서 출력 형식을 검증하는 방식으로 설계를 바꿔야 한다.
bedrock-runtime으로 서울 in-region 추론 설정하기
서울 in-region 호출에 필요한 설정은 세 가지로 요약된다. 리전은 ap-northeast-2, 엔드포인트는 bedrock-runtime, model ID는 접두사 없는 형태다. 발표 블로그는 boto3 Converse API와 Anthropic SDK 두 가지 예제를 제공한다.
boto3 Converse API
발표 블로그의 서울 예제는 modelId에 접두사 없는 anthropic.claude-opus-5를 지정한다.
import boto3
bedrock_runtime = boto3.client(
service_name="bedrock-runtime",
region_name="ap-northeast-2"
)
response = bedrock_runtime.converse(
modelId="anthropic.claude-opus-5",
messages=[
{ "role": "user",
"content": [
{ "text": " Can you explain the features of Amazon Bedrock?"
}
]
}
],
inferenceConfig={
"maxTokens": 4096
}
)
if 'output' in response:
blocks = response['output']['message']['content']
print('\n'.join(b.get('text', '') for b in blocks if 'text' in b))`service_name`과 `region_name`, `modelId` 세 값이 in-region 조건을 모두 담고 있다. 이 중 하나라도 바뀌면 처리 위치가 달라질 수 있으므로, 운영 환경에서는 세 값을 코드에 흩어 두지 말고 한 설정 모듈에서 관리하는 편이 변경 추적에 유리하다.
Anthropic SDK를 쓰는 애플리케이션은 base_url을 bedrock-runtime 서울 엔드포인트의 /anthropic 경로로 지정한다. 인증 토큰은 aws_bedrock_token_generator의 provide_token으로 서울 리전용으로 만들어 api_key로 넘긴다.
from anthropic import Anthropic
from aws_bedrock_token_generator import provide_token
token = provide_token(region="ap-northeast-2")
client = Anthropic(
base_url="https://bedrock-runtime.ap-northeast-2.amazonaws.com/anthropic",
api_key=token,
)
response = client.messages.create(
model="anthropic.claude-sonnet-5",
max_tokens=1024,
messages=[{"role": "user", "content": "Can you explain the features of Amazon Bedrock?"}],
)
print(response)이 예제는 AnthropicBedrockMantle이 아니라 일반 Anthropic 클라이언트에 base_url을 넘기는 형태다. 기존에 Anthropic API를 직접 쓰던 코드라면 클라이언트 생성부만 바꾸고 messages.create 호출은 그대로 둘 수 있다. provide_token의 region과 base_url의 리전이 서로 같아야 한다는 점을 코드 리뷰 항목에 넣어 둔다.
배포 전 model ID 가드
원인 1을 막는 가장 단순한 방법은 호출 직전에 model ID를 검사하는 것이다. 아래 helper는 발표 블로그에 명시된 리전·모델 조합만 허용하고, 모델 카드에 나온 cross-Region 접두사를 거부한다.
IN_REGION_MODELS = {
"ap-northeast-2": {"anthropic.claude-opus-5", "anthropic.claude-sonnet-5"},
"ap-southeast-1": {"anthropic.claude-sonnet-5"},
}
CROSS_REGION_PREFIXES = ("global.", "us.", "eu.", "au.", "in.")
def resolve_in_region_model(region: str, model_id: str) -> str:
if model_id.startswith(CROSS_REGION_PREFIXES): # ← cross-Region ID 차단
raise ValueError(f"cross-Region 추론 ID 사용 불가: {model_id}")
if model_id not in IN_REGION_MODELS.get(region, set()): # ← 확인된 조합만 허용
raise ValueError(f"{region} in-region 미확인 모델: {model_id}")
return model_idboto3.client의 modelId나 client.messages.create의 model에 이 함수의 반환값을 넘기면 된다. 허용 목록은 2026-09-29 발표 기준이므로, 모델 카드가 갱신되면 이 딕셔너리도 함께 수정한다.
인증과 SCP로 리전 경계 고정하기
코드 수준의 가드는 개발자 실수를 막지만, 계정 단위의 강제력은 없다. 조직 차원에서 리전 경계를 지키려면 IAM 정책과 SCP가 필요하다. 발표 블로그에는 IAM 정책 예시와 AWS CLI 호출 예시가 없으므로, 아래 내용은 Anthropic 문서와 AWS cross-Region 문서에 나온 조건을 기준으로 한다.
인증 방식별 권장도
Anthropic 문서는 인증 방법을 세 가지로 구분한다.
| 방식 | 문서의 권장도 | 문서에 적힌 조건 |
|---|---|---|
| Bedrock service role | 권장 | — |
| IAM assumed role | — | 허용된 model ARN에만 bedrock-mantle:CreateInference 부여 |
| Bearer token | 가장 덜 권장 | 최대 12시간 |
이 표는 bedrock-mantle 경로를 다루는 문서의 내용이라는 점에 유의한다. bedrock-mantle:CreateInference는 mantle 엔드포인트용 액션이며, bedrock-runtime 서울 in-region 호출에 필요한 IAM 액션은 발표 블로그에 예시가 없다. Anthropic SDK 예제의 provide_token이 발급하는 토큰이 위 분류 중 어디에 해당하는지도 블로그에 적혀 있지 않다.
장기 키 사용을 막는 정책 조건은 문서에 구체적으로 나온다. 관리자는 bedrock:BearerTokenType 조건이 단기 토큰과 일치하지 않으면 bedrock:CallWithBearerToken을 거부하는 정책을 걸어 장기 키 호출을 차단할 수 있다.
SCP 조건과 cross-Region 추론
AWS cross-Region 추론 문서의 비교표는 방식별 SCP 요건을 명시한다. Geographic cross-Region 추론은 SCP에서 프로필의 모든 destination 리전을 허용해야 한다. Global cross-Region 추론은 SCP에서 "aws:RequestedRegion": "unspecified"를 허용해야 한다.
데이터가 서울에 머물러야 하는 조직이라면 이 요건을 거꾸로 읽으면 된다. Global 추론을 쓰지 않기로 했다면 SCP에 unspecified 허용을 추가할 이유가 없다. 여러 팀이 한 조직을 공유하는 환경에서는 in-region 전용 OU를 분리해 이 허용 조건을 넣지 않는 구성을 검토할 만하다.
[추론 프로필 지원 리전 문서](https://docs.aws.amazon.com/bedrock/latest/userguide/inference-profiles-support.html)에 따르면 cross-Region 프로필은 opt-in 리전으로도 라우팅될 수 있고, 프롬프트와 출력이 어뷰즈 탐지 목적으로 opt-in 리전에 저장될 수 있다. 국내 처리 요건이 있는 금융·의료·공공 워크로드에서 `global.` ID가 섞이면 이 조건에 그대로 노출된다. 접두사 없는 in-region ID로 고정하고, SCP에서 Global용 허용 조건을 넣지 않는 방식으로 위험을 차단한다.
서울 리전 관점에서 세 방식을 같은 속성으로 놓으면 차이가 분명해진다. 각 칸은 발표 블로그, 모델 카드, cross-Region 문서에 나온 값만 옮겼다.
| 항목 | In-Region | Geo cross-Region | Global cross-Region |
|---|---|---|---|
| 서울 지원 (Opus 5·Sonnet 5) | 지원 | 미지원 | 지원 |
| model ID 형태 | anthropic.claude-sonnet-5 |
us./eu./au./in. 접두사 |
global.anthropic.claude-sonnet-5 |
| 라우팅 | 라우팅 계층 없음 | 프로필의 destination 리전 | cross-Region, opt-in 리전 포함 가능 |
| 요금 표현 (원문) | standard on-demand pricing for the Region you call | Standard pricing | Approximately 10% savings |
| 로그 위치 | 호출한 리전 | source 리전 (처리 리전은 inferenceRegion) |
source 리전 (처리 리전은 inferenceRegion) |
요금 문구가 문서마다 다른 이유
요금은 문서마다 기준점이 다르게 쓰여 있어 혼동하기 쉽다. AWS cross-Region 문서는 Global을 Geo의 Standard pricing 대비 "Approximately 10% savings"로 설명한다. Anthropic 문서는 반대 방향에서 Global을 "No pricing premium"으로, Regional을 "Regional endpoints carry a 10% pricing premium over global endpoints."로 적는다. Anthropic 문서가 지역 단위 inference profile로 나열한 것은 US, EU, JP, AU이며, 이 문서는 bedrock-mantle 경로 기준이다.
서울 `bedrock-runtime` in-region 호출에 10% 할증이 붙는지는 두 문서 어디에도 명시되어 있지 않다. 발표 블로그와 두 모델 카드에도 서울 in-region의 입력·출력 토큰 단가는 없고, 블로그는 호출한 리전의 표준 온디맨드 요금을 따른다고만 적는다. 비용 산정 전에는 AWS Bedrock 요금 페이지에서 서울 리전 단가를 직접 확인해야 한다.
데이터 처리 위치가 요건이면 In-Region이 유일한 선택지다. 서울에서는 Geo 프로필이 없으므로 "국내는 아니어도 아시아 권역 안에서 처리"라는 중간 선택도 불가능하다. 데이터 위치 제약이 없고 리전 용량 한계를 피하고 싶다면 Global이 후보가 되지만, opt-in 리전 라우팅과 저장 조건을 수용할 수 있는지 먼저 판단한다.
운영 단계에서 확인할 항목
서울 in-region을 적용한 뒤에는 모니터링과 장애 대응의 기준이 cross-Region과 달라진다. 라우팅 계층이 없으므로 서울 리전 용량과 쿼터가 곧 서비스 처리량의 상한이다.
쿼터와 용량
요청은 리전별 서비스 쿼터를 적용받고, 쿼터 소비도 서울 리전 범위로 집계된다. 트래픽이 늘어날 워크로드라면 서울 리전의 Bedrock 쿼터를 사전에 확인하고 필요하면 상향 요청을 준비한다. Sonnet 5는 Standard Service Tier만 지원하므로 Priority나 Reserved 같은 등급으로 처리량을 확보하는 방법은 모델 카드 기준으로 선택지에 없다.
CloudWatch 지표와 CloudTrail 로그
발표 블로그는 in-region 요청의 CloudWatch 지표와 CloudTrail 로그가 호출한 리전에 기록된다고 설명한다. 대시보드와 알람은 ap-northeast-2에 구성하면 된다.
cross-Region 요청이 섞였는지 검증할 때는 CloudTrail 이벤트의 additionalEventData.inferenceRegion 필드를 본다. AWS 문서에 따르면 모든 cross-Region 추론 요청은 source 리전에 기록되고, 실제 처리 리전은 이 필드로 확인한다. 서울 CloudTrail에 이 필드가 서울 외 리전으로 찍힌 이벤트가 있다면 어딘가에서 global. ID가 쓰였다는 신호다. 감사 주기에 이 필드를 조회하는 쿼리를 넣어 두면 설정 변경으로 인한 이탈을 늦지 않게 잡아낸다.
장애 시 전환 판단
서울 리전 용량이 부족하거나 장애가 생겼을 때 `global.` ID로 전환하면 요청은 처리되지만 cross-Region 라우팅으로 바뀐다. 데이터 레지던시 요건이 있는 서비스에서 이 전환은 규정 위반이 될 수 있으므로, 자동 폴백 로직에 Global ID를 넣지 않는다. 전환이 필요하다면 요건 담당자의 승인 절차를 장애 대응 런북에 명시해 둔다.
관련 글
- Claude Code 모노레포 토큰 최적화 — LSP 컨텍스트 폭발 방지 실전 설정법 – 모노레포에서 Claude Code 세션당 토큰 소비가 급증하는 원인과 해결법을 다룬다. CLAUDE.md 계층 설계, 경로 범위 규칙, L…
- Claude Code LSP 설정 완전 가이드 — TypeScript·Python 언어 서버 5단계 연동 – Claude Code에서 LSP를 설정하면 코드 컨텍스트 파악 정확도가 올라가고 토큰 소비가 줄어든다. TypeScript와 Python …
- Claude API 토큰 비용 70% 절감한 3가지 실전 전략: 프롬프트 캐싱·배치 API·컨텍스트 압축 – 월 300만 원 나오던 Claude API 비용을 프롬프트 캐싱, 배치 API, 컨텍스트 압축 세 가지 조합으로 90만 원대까지 줄인 과정…
자주 묻는 질문
서울 리전에서 Geo 추론 프로필을 쓸 수 있나?
Opus 5와 Sonnet 5 모델 카드 모두 서울 행에서 Geo를 미지원으로 표기한다. Geo inference ID는 us., eu., au., in. 네 개뿐이다. 서울 리전 클라이언트의 선택지는 in-region과 Global 두 가지다.
AnthropicBedrockMantle 클라이언트로 서울 in-region을 호출할 수 있나?
bedrock-mantle의 In-Region 지원 리전 목록에 서울은 없다. Anthropic 문서의 리전 표도 ap-northeast-2를 Global로만 표기한다. 서울 in-region은 bedrock-runtime 엔드포인트로 호출해야 한다.
서울 in-region 요금은 Global보다 비싼가?
서울 bedrock-runtime in-region에 할증이 붙는지는 공개 문서에 명시되어 있지 않다. 발표 블로그는 호출한 리전의 표준 온디맨드 요금을 따른다고만 적는다. 정확한 단가는 AWS Bedrock 요금 페이지에서 서울 리전 기준으로 확인한다.
서울 in-region에서 Structured outputs를 쓸 수 있나?
모델 카드 기준 bedrock-runtime은 Structured outputs를 지원하지 않는다. Anthropic 문서도 bedrock-mantle 경로의 미지원 기능에 Structured outputs를 포함한다. 출력 형식 검증은 애플리케이션 코드에서 처리하는 구조가 필요하다.
서울 in-region 적용 전 체크리스트와 정리
서울 리전에서 Claude 요청을 국내에서 처리하려면 리전 지정만으로는 부족하다. 처리 위치를 결정하는 것은 bedrock-runtime 엔드포인트와 접두사 없는 model ID의 조합이고, 이 조합이 확인된 모델은 2026-09-29 발표 기준 Claude Opus 5와 Sonnet 5다. global. ID와 bedrock-mantle 엔드포인트는 각각 cross-Region 라우팅과 in-region 미지원이라는 이유로 서울 in-region 경로에서 벗어난다. 운영 단계에서는 라우팅 계층이 없다는 특성 때문에 쿼터와 용량이 처리량 상한이 되며, CloudTrail의 inferenceRegion 필드가 이탈 여부를 검증하는 기준이 된다.
- 엔드포인트가
https://bedrock-runtime.ap-northeast-2.amazonaws.com계열인지 확인 - model ID가
anthropic.claude-opus-5또는anthropic.claude-sonnet-5처럼 접두사 없는 형태인지 점검 global.,us.,eu.,au.,in.접두사를 배포 전 가드로 차단- Anthropic SDK 사용 시
provide_token의region과base_url리전 일치 여부 검토 - Structured outputs, Count tokens 등
bedrock-runtime미지원 기능 의존 여부 파악 - SCP에
"aws:RequestedRegion": "unspecified"허용이 들어가 있지 않은지 확인 bedrock:BearerTokenType조건으로 장기 bearer token 차단 정책 적용- 서울 리전 서비스 쿼터와 CloudWatch 알람 구성
- CloudTrail
additionalEventData.inferenceRegion정기 조회 쿼리 등록 - 장애 대응 런북에서 Global ID 자동 폴백 제외
이어서 다룰 주제로는 Bedrock SCP aws:RequestedRegion 조건을 조직 OU 단위로 설계하는 방법이 먼저다. Bedrock API 키 bearer token의 수명 관리와 장기 키 차단 정책도 인증 운영과 직결되는 영역이다. bedrock-runtime vs bedrock-mantle 두 엔드포인트의 기능 차이는 Global 추론 요금과 함께 비교해 두면, 데이터 레지던시 요건이 없는 워크로드의 엔드포인트 선택 기준으로도 쓸 수 있다.
{ “@context”: “https://schema.org”, “@type”: “FAQPage”, “mainEntity”: [ { “@type”: “Question”, “name”: “서울 리전에서 Geo 추론 프로필을 쓸 수 있나?”, “acceptedAnswer”: { “@type”: “Answer”, “text”: “Opus 5와 Sonnet 5 모델 카드 모두 서울 행에서 Geo를 미지원으로 표기한다. Geo inference ID는 `us.`, `eu.`, `au.`, `in.` 네 개뿐이다. 서울 리전 클라이언트의 선택지는 in-region과 Global 두 가지다.” } }, { “@type”: “Question”, “name”: “AnthropicBedrockMantle 클라이언트로 서울 in-region을 호출할 수 있나?”, “acceptedAnswer”: { “@type”: “Answer”, “text”: “`bedrock-mantle`의 In-Region 지원 리전 목록에 서울은 없다. Anthropic 문서의 리전 표도 ap-northeast-2를 Global로만 표기한다. 서울 in-region은 `bedrock-runtime` 엔드포인트로 호출해야 한다.” } }, { “@type”: “Question”, “name”: “서울 in-region 요금은 Global보다 비싼가?”, “acceptedAnswer”: { “@type”: “Answer”, “text”: “서울 `bedrock-runtime` in-region에 할증이 붙는지는 공개 문서에 명시되어 있지 않다. 발표 블로그는 호출한 리전의 표준 온디맨드 요금을 따른다고만 적는다. 정확한 단가는 AWS Bedrock 요금 페이지에서 서울 리전 기준으로 확인한다.” } }, { “@type”: “Question”, “name”: “서울 in-region에서 Structured outputs를 쓸 수 있나?”, “acceptedAnswer”: { “@type”: “Answer”, “text”: “모델 카드 기준 `bedrock-runtime`은 Structured outputs를 지원하지 않는다. Anthropic 문서도 `bedrock-mantle` 경로의 미지원 기능에 Structured outputs를 포함한다. 출력 형식 검증은 애플리케이션 코드에서 처리하는 구조가 필요하다.” } } ] }