Bedrock Mantle 기반 GPT‑5.6 연동부터 cached Web Search, AWS PrivateLink 전용망, 관측성과 비용 운영까지

생성형 AI 코딩 에이전트를 엔터프라이즈 기업 환경에 도입할 때는 모델 성능만큼 인증, 데이터 경로, 네트워크 격리, 비용 배분과 감사 가능성이 중요합니다. Codex는 이제 ChatGPT 데스크톱 앱의 Codex 보기, Codex CLI, IDE 확장, Codex SDK와 codex exec 같은 로컬 워크플로에서 Amazon Bedrock을 모델 공급자로 사용할 수 있습니다. 개발자는 익숙한 Codex 경험을 유지하면서 AWS 클라우드 환경의 AWS Identity and Access Management(IAM), Bedrock 사용량 기반 과금과 AWS PrivateLink를 결합할 수 있습니다.

여기서 가장 중요한 사실은 Codex의 OpenAI GPT‑5.x 요청이 기존 bedrock-runtime이 아니라 Amazon Bedrock Mantle의 OpenAI-compatible Responses API로 전송된다는 점입니다. 따라서 기존 Claude/Bedrock 예제의 InvokeModel, Converse, bedrock:InvokeModel, Runtime용 VPC endpoint와 model invocation logging을 그대로 복사하면 잘못된 구성이 됩니다. 이 글에서는 실제 Codex 경로를 먼저 구성한 뒤, 보안, 관측, 전용망 통신, 비용 효율적 운영으로 확장합니다.

Codex on Amazon Bedrock 개요

Codex는 코드를 읽고 쓰고 검토하며, 로컬 sandbox에서 명령을 실행하고 테스트 결과를 바탕으로 다음 작업을 이어가는 코딩 에이전트입니다. Amazon Bedrock 연동에서는 로컬 Codex 클라이언트가 내장 amazon-bedrock provider를 통해 Bedrock Mantle의 /openai/v1/responses에 요청합니다. 모델 추론 요청 경로에 OpenAI가 호스팅하는 Responses API는 포함되지 않으며, 인증과 청구는 AWS에서 처리합니다. 자세한 제품 경계는 OpenAI의 Codex on Amazon Bedrock 가이드와 AWS GPT‑5.6 시작 가이드에서 확인할 수 있습니다.

그림 1. ChatGPT 데스크톱, Codex CLI, IDE 확장과 Codex SDK는 같은 로컬 설정을 읽습니다. 추론 요청은 Codex 내장 provider에서 Bedrock Mantle의 OpenAI-compatible Responses API로 전달됩니다.

그림 1A. 사내 개발자와 CI의 Codex 요청이 AWS 인증을 거쳐 Bedrock Mantle의 Responses API와 GPT-5.6으로 전달되는 전체 참조 아키텍처입니다. 로컬 실행 경계, 고객 계정의 identity context, AWS 관리형 Bedrock 영역과 regional metric 경로를 분리해 보여 줍니다.

Runtime과 Mantle을 차이

Bedrock에 gpt-oss 모델이 있다는 사실도 Codex의 공식 모델 지원과는 별개입니다. 일반 애플리케이션은 OpenAI SDK에 Bedrock base URL을 넣거나 gpt-oss를 Runtime API로 직접 호출할 수 있지만, Codex의 공식 경로는 내장 amazon-bedrock provider와 아래 지원 GPT‑5.x 모델입니다. Codex 설정에 일반 OpenAI SDK 예제의 OPENAI_BASE_URL 또는 OPENAI_API_KEY를 섞으면 안됩니다.

사전 준비: 모델, 리전과 권한

2026년 8월 14일 현재 Codex 공식 가이드가 열거하는 정확한 모델 ID와 각 AWS 모델 카드의 컨텍스트 윈도우, 상용 In-Region 제공 리전을 합치면 다음과 같습니다. 서울 리전(ap-northeast-2)은 이 목록에 없습니다.

모델마다 리전이 다르므로 모델, config.toml의 리전, PrivateLink endpoint가 있는 리전이 일치해야 합니다. 이 글의 예제는 GPT‑5.6 Sol을 사용할 수 있는 us-east-1을 기준으로 합니다. 광범위한 Mantle 출시 공지와 달리, 로컬 Codex 실행 환경은 현재 Mantle GovCloud endpoint를 지원하지 않는다고 전용 가이드가 명시합니다.

현재 모델 접근 문서에 따르면 올바른 권한이 있으면 Bedrock foundation model 접근은 기본 활성화됩니다. OpenAI 모델은 AWS Marketplace product key가 없는 모델에 포함되므로 Marketplace 구독 권한을 OpenAI 모델 사용의 필수 조건으로 오해하지 마십시오. 다만 적용 약관, 계정 상태, 지원 리전과 IAM 권한은 충족해야 합니다. 빠른 검증에는 AWS 관리형 정책 AmazonBedrockMantleInferenceAccess를 참고할 수 있지만, 운영 환경에서는 실제 principal, project와 모델 범위에 맞는 최소 권한 정책으로 줄이는 것이 좋습니다.

1. AWS 인증과 Codex 설정

Codex는 다음 순서로 AWS 인증을 찾습니다.

1. AWS_BEARER_TOKEN_BEDROCK
2. AWS SDK credential chain

즉, 환경에 만료된 AWS_BEARER_TOKEN_BEDROCK이 남아 있으면 정상적인 AWS profile보다 먼저 선택됩니다. API key에서 IAM role이나 AWS IAM Identity Center(SSO)로 전환할 때는 이 변수를 제거해야 합니다. ChatGPT 로그인과 OpenAI 발급 API key는 이 provider의 모델 인증에 사용되지 않습니다.

그림 2. 간단한 시험에는 Bedrock API key가 편리하지만, 운영 환경에는 만료되는 AWS 자격 증명과 조직의 SSO, role 체계를 권장합니다.

그림 2A. Bedrock API key의 bearer token 경로와 IAM Identity Center, AWS SDK credential chain의 role 경로를 분리합니다. Bearer 경로에는 permission-only action인 bedrock-mantle:CallWithBearerToken과 실제 API action인 bedrock-mantle:CreateInference가 모두 필요하고, SigV4 경로는 CreateInference 권한으로 합류합니다.

방법 A: Bedrock API key

Bedrock API key는 단기 key와 장기 key로 나뉩니다. 단기 key는 장기 key보다 안전한 빠른 검증 수단이며 세션 수명 또는 최대 12시간 동안 유효합니다. 운영 환경에서는 자동으로 갱신할 수 있는 IAM role, SSO 자격 증명을 우선하고, IAM user와 연결되는 장기 key는 탐색, 개발 목적으로 한정하는 것이 안전합니다.

export AWS_BEARER_TOKEN_BEDROCK="<your-bedrock-api-key>"
export AWS_REGION="us-east-1"

방법 B: AWS SDK credential chain

AWS CLI profile, IAM Identity Center(SSO), credential_process, web identity, 컨테이너 자격 증명과 표준 AWS access-key 환경 변수를 사용할 수 있습니다. 예를 들어 SSO profile을 사용한다면 다음과 같습니다.

aws sso login --profile codex-bedrock
export AWS_PROFILE="codex-bedrock"
export AWS_REGION="us-east-1"

정적 access key를 소스 저장소나 config.toml에 넣지 마십시오. CI runner에서는 OIDC 또는 workload role처럼 짧게 만료되는 자격 증명을 사용하고, 권한에 bedrock-mantle:CreateInference가 포함되는지 확인합니다.

Codex CLI 설치

OpenAI Codex 공식 저장소의 최신 설치 방법 중 하나를 선택합니다. 아래는 Mac과 Linux용 공식 설치 스크립트이며, 조직의 소프트웨어 반입 정책에 따라 npm이나 Homebrew 방식을 사용할 수도 있습니다.

# Mac 또는 Linux
curl -fsSL https://chatgpt.com/codex/install.sh | sh

# 대안: npm install -g @openai/codex
# 대안: brew install --cask codex

codex --version

보안 통제 환경에서는 스크립트의 출처와 다운로드 artifact를 사내 검증 절차로 확인하거나 승인된 package mirror를 사용합니다.

config.toml에 내장 provider 지정

최신 Codex를 설치하거나 업데이트한 뒤 ~/.codex/config.toml에 다음을 추가합니다.

model_provider = "amazon-bedrock"
model = "openai.gpt-5.6-sol"
web_search = "cached"

[model_providers.amazon-bedrock.aws]
region = "us-east-1"
# profile = "codex-bedrock"  # 명명된 AWS profile을 고정할 때

공개된 Codex 설정 문서가 내장 provider에서 지원하는 AWS 설정 항목은 profile과 region입니다. Private DNS를 끈 뒤 임의 VPC endpoint URL을 base_url로 주입하는 방식은 공식 Codex 경로가 아닙니다.

ChatGPT 데스크톱 앱이나 IDE 확장은 shell 환경을 상속하지 않을 수 있습니다. 이때 로컬 ~/.codex/.env에 AWS 환경 변수를 두고 앱을 완전히 재시작합니다. 민감한 key가 든 파일의 소유권과 권한을 제한하고 백업·동기화 대상에서도 제외하십시오.

AWS_BEARER_TOKEN_BEDROCK=<your-bedrock-api-key>
AWS_REGION=us-east-1

저장소 루트에서 Codex CLI를 실행합니다.

cd <your-repository>
codex

먼저 /status를 입력해 provider ID가 amazon-bedrock, model이 openai.gpt-5.6-sol인지 확인하고, 별도로 config.toml의 리전이 us-east-1인지 점검합니다. /status가 리전 표시까지 보장하는 것은 아닙니다. 이어서 파일을 변경하지 않는 짧은 요청으로 첫 추론을 검증합니다.

현재 저장소의 구조를 읽고, 파일을 변경하지 말고 세 문장으로 요약해 줘.

모델 응답이 정상적으로 streaming되고 수 분 뒤 AWS/BedrockMantle의 Inferences가 증가하면 기본 연결이 완료된 것입니다. 데스크톱·IDE에서는 설정 변경 후 새 작업 또는 새 세션을 시작해야 기존 세션의 provider 상태와 섞이지 않습니다.

Codex CLI 0.147.0부터 cached web search 지원

최신 Codex CLI 0.147.0 릴리스부터 Amazon Bedrock 세션은 cached web search를 지원합니다. 이는 Bedrock Responses 요청에 포함되는 text-only hosted web-search tool입니다. Codex가 현재 웹사이트를 직접 방문하는 live search나 별도의 indexed external web access와는 범위가 다릅니다. Bedrock provider에서 live 또는 indexed를 요청해도 지원되는 cached mode로 전환되며, 조직의 managed requirements가 cached mode를 금지하면 web-search tool 자체가 비활성화됩니다. 정확한 provider 동작은 OpenAI의 병합된 구현 PR에서 확인할 수 있습니다.

다만 같은 날 확인한 OpenAI의 Amazon Bedrock feature matrix는 아직 web-search를 unavailable로 표시해 릴리스 정보보다 갱신이 늦습니다. 따라서 확정된 지원 범위는 Codex CLI 0.147.0의 cached search이며, 이를 데스크톱 앱, IDE 확장, Codex SDK 전체의 지원으로 확대하지 않습니다. 조직 배포에서는 설치된 CLI 버전과 실제 검색 호출을 함께 검증하십시오.

Amazon Bedrock Web Search는 GPT‑5.4, GPT‑5.5와 GPT‑5.6 계열의 Responses API에서 지원되며 us-east-1, us-east-2, us-west-2에서 처리됩니다. 실제 사용 리전은 Web Search 리전과 선택한 모델 리전의 교집합이어야 합니다. 사용자 정의 최소 권한 IAM policy에는 다음 두 action이 필요합니다. 현재 AWS 관리형 AmazonBedrockMantleInferenceAccess v5에는 두 action이 포함되지만 ExternalWebAccess는 포함되지 않습니다.

{
  "Effect": "Allow",
  "Action": [
    "bedrock-websearch:InvokeSearch",
    "bedrock-websearch:InvokeFetch"
  ],
  "Resource": "*"
}

Codex CLI 0.147.0의 cached mode는 Responses tool에 external_web_access: false를 전달해 Amazon Bedrock의 리전별 web index와 cache를 사용합니다. Cache-only 경계를 유지하려면 ExternalWebAccess 권한을 허용하지 않습니다. 일반 Codex의 web-search 기본 mode는 permission profile에 따라 달라질 수 있으므로, Bedrock 배포에서는 위 예제처럼 web_search = "cached"를 명시하는 편이 안전합니다. 웹 검색을 허용하지 않는 환경에서는 다음처럼 끕니다.

web_search = "disabled"

작동 여부는 /status만으로 판단하지 말고, 출처가 필요한 질문을 요청해 검색 결과와 citation이 반환되는지 확인합니다. Cached search는 사전에 색인된 결과를 사용하므로 급변하는 정보의 실시간성은 보장하지 않습니다. 검색 결과를 최종 사용자에게 제공하는 애플리케이션은 AWS가 반환한 source citation과 link를 유지해야 합니다. 또한 검색 결과는 신뢰할 수 없는 외부 입력으로 취급하고, prompt injection과 잘못된 출처를 검토한 뒤 코드나 shell 명령에 반영합니다.

Web Search는 모델 token과 별도로 query 단위로 과금됩니다. 2026년 8월 14일 미국 3개 리전의 공식 가격표는 query당 $0.012, 즉 1,000 query당 $12이며 한 turn에서 모델이 여러 search를 실행할 수 있습니다. 예산은 “사용자 질문 수”가 아니라 실제 Web Search query 수와 모델 token을 함께 기준으로 잡아야 합니다.

2. 상태, 토큰과 비용을 분리하여 관측

기존 Claude Code 예제의 /cost 화면을 Codex에 그대로 대입하면 안 됩니다. Codex에 동등한 /cost 명령은 공식 문서에 없으며, /status는 연결된 provider·model과 로컬 세션 상태를 확인하는 용도입니다. 실제 청구는 Bedrock이 처리한 input, cache write, cache read와 output token을 기준으로 AWS 도구에서 확인합니다. Web Search를 사용하면 query 비용도 별도로 더해집니다.

그림 3. /status는 설정 검증에, CloudWatch와 Cost Explorer·CUR는 운영량과 청구 검증에 사용합니다.

2026년 8월 14일 Amazon Bedrock 가격표의 미국 리전 Standard·in-region, 272K 이하 구간 가격은 다음과 같습니다. 단위는 100만 token당 USD이며 세금과 PrivateLink 비용은 포함하지 않습니다.

그림 4. 반복되는 저장소 맥락과 지침이 실제 cache read로 처리되면 입력 대비 약 90% 낮은 단가가 적용됩니다. cache write는 일반 input보다 25% 높습니다.

세 모델의 최신 모델 카드는 모두 1M 컨텍스트 창을 표시합니다. 가격 페이지는 272K를 초과하는 1M long-context 구간에 GPT‑5.6 Sol $11/$13.75/$1.10/$49.50, Terra $4.40/$5.50/$0.44/$19.80, Luna $0.44/$0.55/$0.044/$1.98을 각각 input/cache write/cache read/output 순서로 게시하고 있습니다. 요청 길이에 따라 단가가 달라지므로 배포 직전에 모델 카드와 가격표를 함께 확인해야 합니다.

Bedrock Mantle의 GPT‑5.6 모델은 prompt caching을 지원합니다. 그러나 애플리케이션 수준에서 cache checkpoint를 수동 제어하는 예제와 Codex 내장 provider의 동작을 동일시해서는 안 됩니다. 실제 절감 여부는 AWS측 token metric과 청구 데이터를 기준으로 검증하십시오.

3. 보안과 데이터 보존의 실제 경계

AWS는 Bedrock에 전송된 prompt와 completion을 모델 학습에 사용하지 않으며 OpenAI에 공유하지 않는다고 설명합니다. 그렇다고 “요청을 전혀 저장하지 않는다”는 뜻은 아닙니다. Effective data_retention_mode가 default일 때 Responses API는 store=true가 기본이며, 이 경우 input과 output을 요청 source 리전에 암호화해 30일 보관합니다. Mode가 none이면 store=false가 기본이고 store=true는 거부됩니다. 자세한 상태 저장과 retention mode의 관계는 Mantle Responses 저장 문서와 data retention 문서를 함께 확인하십시오. store=false는 고객이 이후 조회할 수 있는 response state 보관을 끄지만, 그 자체가 완전한 Zero Data Retention(ZDR)을 보장하지는 않습니다.

또한 abuse detection 정책에 따라 분류기가 표시한 GPT‑5.4, GPT‑5.5, GPT‑5.6 traffic을 AWS가 자동화된 offline abuse detection 목적으로 최대 30일 보관할 수 있습니다. eligible account의 full ZDR 가능 여부와 account/project data_retention_mode는 AWS account team 및 조직의 규정 담당자와 확인해야 합니다. 공개 Codex 설정 가이드는 각 Codex 요청의

값을 사용자가 직접 강제하는 항목을 제공하지 않으므로 “Codex는 항상 30일 저장한다” 또는 “Codex는 기본적으로 ZDR이다”라고 단정하지 않는 것이 정확합니다.

그림 5. 검증 가능한 통제를 겹쳐 사용합니다. 기존 Runtime의 Guardrails 강제 적용 문서를 Mantle Responses 요청에 근거 없이 확대 적용하지 않습니다.

Bedrock Guardrails의 계정 수준 강제 적용 문서는 주로 InvokeModel과 Converse 경로를 설명합니다. 2026년 8월 14일 현재 Codex 내장 provider의 Mantle Responses 요청에 Guardrail identifier를 직접 지정하는 공식 구성은 문서화되어 있지 않습니다. 따라서 기존 글의 “Guardrail 설정 후 Codex prompt가 차단되는 화면”을 검증 없이 재현해서는 안 됩니다. 추가 입력·출력 검사가 필요하면 지원되는 별도 검사 API나 검증된 gateway를 설계하고, streaming, tool call, 오류와 재시도 계약까지 통합 테스트해야 합니다.

모델 호출 외에 Codex 자체의 로컬 권한도 별도로 통제해야 합니다. /etc/codex/requirements.toml 또는 MDM으로 sandbox, approval, MCP와 plugin 사용 범위를 강제하고, 저장소의 AGENTS.md는 작업 지침으로 사용합니다. 모델 경로가 PrivateLink라고 해서 로컬 shell 명령의 권한까지 자동 제한되는 것은 아닙니다.

4. Mantle 모니터링과 감사 범위

Codex의 Bedrock 요청은 CloudWatch namespace AWS/BedrockMantle에 계량됩니다. Inferences와 InferenceClientErrors는 account, project, model, project+model 수준으로 게시됩니다. 집계용 TotalInputTokens, TotalOutputTokens는 account, project, model 수준이며, 요청별 분포를 위한 InputTokens, OutputTokens는 project+model 수준에서만 제공됩니다. 기존 AWS/Bedrock dashboard만 보고 “호출이 없다”고 판단하지 마십시오. 자세한 metric 정의는 Mantle CloudWatch 문서에 있습니다.

그림 6. 수량 metric, API 감사 event, prompt, response content log는 서로 다른 데이터입니다.

Mantle의 CreateInference는 CloudTrail data event입니다. management event처럼 기본 수집되지 않으며, trail 또는 event data store에 bedrock-mantle.amazonaws.com과 Bedrock Mantle resource type을 대상으로 advanced event selector를 명시적으로 구성해야 합니다. Data event 수집에는 추가 비용이 발생합니다. 요청의 customer metadata는 event에 그대로 남을 수 있으므로 secret, token, 개인정보를 metadata에 넣지 마십시오. 구성 방법은 CloudTrail의 Mantle 로깅 문서를 따릅니다.

Cached web search를 사용하면 bedrock-websearch:InvokeSearch와 InvokeFetch도 별도의 CloudTrail data event입니다. 역시 기본 수집되지 않고 추가 비용이 발생합니다. Web Search monitoring 문서에 따르면 event에는 identity, 시간, action, 리전이 기록되지만 query text, URL과 raw search result는 기록되지 않습니다. 위 CreateInference의 metadata는 Responses 요청의 customer metadata이고, Runtime 전용 비용 기능인 requestMetadata와는 다른 필드입니다.

더 중요한 제한은 일반 Bedrock Model Invocation Logging이 현재 bedrock-runtime operation만 지원하고 Mantle Responses API를 수집하지 않는다는 점입니다. 기존 글의 CloudWatch Logs Insights prompt, response query를 Codex에 그대로 복사하면 데이터가 나타나지 않습니다. 필요한 관측성을 다음처럼 나눕니다.

• 처리량 token, client error: AWS/BedrockMantle metric
• 누가 언제 API를 호출했는지: 명시적으로 활성화한 CloudTrail data event
• 네트워크가 endpoint를 통과했는지: VPC Flow Logs와 DNS, TLS 검증
• prompt, response content 감사: 조직 규정과 데이터 최소화를 고려한 별도, 검증된 계층

5. AWS PrivateLink로 모델 추론 경로 사설화

AWS는 2026년 2월 12일 Bedrock Mantle의 OpenAI API endpoint에 PrivateLink 지원을 추가했습니다. Codex에서 만들어야 하는 interface endpoint 서비스 이름은 다음과 같습니다.

com.amazonaws.<region>.bedrock-mantle

bedrock-runtime endpoint는 Codex GPT‑5.x 추론을 받지 않습니다. Mantle의 model, project API도 bedrock-mantle endpoint가 처리합니다. 별도 com.amazonaws.<region>.bedrock endpoint는 Mantle 밖의 Bedrock control plane API를 실제로 호출하는 경우에만 검토합니다.

그림 7. 온프레미스 개발자는 Direct Connect 또는 Site-to-Site VPN과 하이브리드 DNS를 사용합니다. VPC 안의 VDI, EC2, CI runner라면 Resolver inbound endpoint와 온프레미스 연결 구간을 생략할 수 있습니다. Codex CLI 0.147.0에서 검증된 Bedrock hosted cached web search는 같은 Mantle Responses 요청에 포함됩니다. 공용 경로 차단 표시는 Private DNS 검증과 egress 차단 또는 aws:SourceVpce 정책을 적용했을 때의 목표 상태입니다.

그림 7A. 고객 계정, VPC, 두 가용 영역의 private subnet, endpoint ENI와 AWS 관리형 Bedrock 영역을 명시한 배포 토폴로지입니다. DNS 질의 plane과 HTTPS data plane을 분리하고, com.amazonaws.<region>.bedrock-mantle endpoint 뒤에서 PrivateLink가 Mantle Responses API로 이어집니다.

5.1 Amazon VPC와 DNS 준비

보안 그룹, subnet, IP 주소 유형과 endpoint별 DNS option의 일반 요건은 AWS의 interface endpoint 생성 가이드를 함께 확인합니다.

1. 사용할 모델과 같은 지원 리전에 VPC를 선택합니다. 이 예제는 us-east-1입니다.
2. VPC의 DNS resolution과 DNS hostnames를 활성화합니다.
3. 운영 환경에서는 서로 다른 두 AZ에 endpoint용 private subnet을 준비합니다.
4. endpoint security group의 inbound TCP 443을 Codex host의 source security group 또는 사내 개발망 CIDR로 제한합니다.
5. 제한적인 NACL을 사용한다면 HTTPS와 반환 traffic의 ephemeral port를 포함한 왕복 경로를 점검합니다.

온프레미스에서는 AWS Direct Connect 또는 Site-to-Site VPN으로 endpoint VPC까지 양방향 route가 있어야 합니다. 사내 DNS는 bedrock-mantle.us-east-1.api.aws 질의를 두 AZ의 Amazon Route 53 Resolver inbound endpoint로 조건부 전달합니다. AWS의 VPC·온프레미스 DNS 해석 가이드가 명시하듯, VPC의 “CIDR+2” resolver 주소로 온프레미스 질의를 직접 보내는 구성은 지원되지 않습니다.

5.2 Interface endpoint 생성

AWS console에서 VPC → Endpoints → Create endpoint를 사용할 수 있고, CLI로는 다음과 같이 생성할 수 있습니다. 실제 ID를 명시적으로 바꾸고, 기존 endpoint, subnet, security group을 read-only 명령으로 확인한 뒤 실행하십시오.

aws ec2 create-vpc-endpoint \
  --region us-east-1 \
  --vpc-id vpc-xxxxxxxx \
  --vpc-endpoint-type Interface \
  --service-name com.amazonaws.us-east-1.bedrock-mantle \
  --subnet-ids subnet-aaaaaaaa subnet-bbbbbbbb \
  --security-group-ids sg-xxxxxxxx \
  --private-dns-enabled \
  --policy-document file://bedrock-mantle-vpce-policy.json

Private DNS가 활성화되면 Codex가 원래 사용하는 표준 hostname bedrock-mantle.us-east-1.api.aws가 endpoint ENI의 private IP로 해석됩니다. Codex의 base_url을 바꾸지 않아도 되는 것이 이 패턴의 핵심입니다.

Interface endpoint를 만드는 것만으로 Bedrock public endpoint가 비활성화되지는 않습니다. Private DNS가 실제로 endpoint ENI로 해석되는지 검증하고, 공용 egress를 제거하거나 aws:SourceVpce 조건의 명시적 Deny/SCP를 적용해야 “이 endpoint를 통과한 요청만 허용”하는 경계가 됩니다.

5.3 Endpoint policy와 identity policy

Endpoint policy는 IAM identity policy를 대신하지 않고 추가 gate로 평가됩니다. AWS 문서가 제시하는 Mantle 최소 endpoint policy는 다음과 같습니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Principal": "*",
      "Effect": "Allow",
      "Action": ["bedrock-mantle:CreateInference"],
      "Resource": "*"
    }
  ]
}

운영 환경에서는 endpoint policy의 principal과 identity policy를 실제 Codex IAM role, project와 model에 맞게 좁힙니다. bedrock-mantle:Model condition key와 aws:SourceVpce를 이용해 모델과 endpoint를 제한할 수 있습니다. CreateInference는 추론의 핵심 action이고, 모델·project 조회나 운영 도구에는 필요한 범위의 Get:*, List:* action이 추가될 수 있습니다. API key를 사용하면 key에 연결된 IAM principal과 bedrock-mantle:CallWithBearerToken 권한도 함께 검토합니다. 조건 없는 광범위 managed policy를 동시에 부여하면 좁은 Allow만으로 네트워크 경로가 강제되지 않으므로, permissions boundary, SCP 또는 명시적 Deny까지 포함해 정책 전체를 평가하십시오.

5.4 DNS, HTTPS와 실제 추론 검증

그림 8. 엔드포인트 생성부터 DNS 해석, 실제 추론과 Allow/Deny 검증까지의 순서를 보여 줍니다.

먼저 hostname이 public address가 아니라 endpoint ENI에 실제 할당된 private IPv4 주소를 반환하는지 확인합니다. 아래는 IPv4 endpoint 예제이며, IPv6 또는 dual-stack endpoint를 사용한다면 해당 ENI의 실제 주소 유형과 비교합니다.

dig +short bedrock-mantle.us-east-1.api.aws

결과가 describe-network-interfaces 등으로 확인한 endpoint ENI의 실제 private IPv4 주소와 일치해야 합니다. 이어서 TCP 443 연결, Codex /status, 짧은 실제 prompt 순서로 확인합니다. Provider ID amazon-bedrock과 선택한 모델이 /status에 표시되고, 실제 prompt에는 정상적인 streaming 응답이 돌아와야 합니다. VPC Flow Logs에서는 source에서 endpoint ENI로 향한 ACCEPT traffic을, opt-in CloudTrail data event에서는 CreateInference를 확인합니다. ICMP ping은 interface endpoint 검증 방법이 아닙니다.

차단 시험이 필요하다면 운영 endpoint가 아닌 별도 test endpoint에서 bedrock-mantle:CreateInference를 일시적으로 Deny하고 Codex의 403/AccessDenied를 확인한 즉시 정책을 복구합니다. Endpoint policy 변경은 전파에 수분이 걸릴 수 있습니다.

PrivateLink가 의미하지 않는 것

이 구성은 Bedrock Mantle Responses traffic을 사설화합니다. Codex CLI 0.147.0에서 확인되는 cached web search는 같은 Responses 요청에 포함되는 Bedrock hosted tool이며, Codex 클라이언트에 live web egress를 열어 주는 기능이 아닙니다. 반면 Codex 설치·업데이트, Git remote, package registry, MCP 기반 검색·브라우저 도구, plugin, AWS SSO, STS credential refresh까지 자동으로 PrivateLink를 통과하는 것은 아닙니다. 완전한 egress 제한 환경에서는 각각 사내 mirror, proxy, 별도 VPC endpoint를 설계해야 합니다. STS를 사설화한다면 Regional STS endpoint와 com.amazonaws.<region>.sts를 함께 사용합니다. PrivateLink도 Responses API의 service-side data retention 정책이나 검색 결과를 외부 입력으로 다뤄야 한다는 보안 원칙을 바꾸지 않습니다.

6. 팀별 비용 배분과 예산 운영

Bedrock Mantle은 Projects와 default project를 지원하고, CloudWatch는 project/model 차원을 제공합니다. Project tag를 활성화하면 Cost Explorer와 Cost and Usage Report(CUR)에서 분석할 수 있습니다. 그러나 2026년 8월 14일 현재 Codex 내장 amazon-bedrock provider의 공개 설정은 aws.profile과 aws.region만 설명하며, 호출마다 project를 선택하는 설정은 문서화하지 않습니다.

그림 9. Project는 workload 단위, IAM principal attribution은 사용자, role, team 단위 집계를 보완합니다. Codex의 project selector는 아직 문서화되지 않았습니다.

그림 9A. Codex 요청의 IAM principal·session tag와 Mantle project를 서로 다른 비용 귀속 축으로 유지합니다. 사용량은 CloudWatch, Cost Explorer, CUR로 집계하고, AWS Budgets의 임계값 대응은 검증한 IAM 또는 SCP action과 별도의 reversal 경로로 분리합니다.

IAM principal 비용 배분은 bedrock-runtime뿐 아니라 bedrock-mantle의 Responses API와 Chat Completions API도 지원합니다. IAM user·role identity는 자동으로 집계되고, principal tag와 STS session tag를 활성화하면 Cost Explorer와 CUR 2.0에서 사용자, role, team, cost center별로 볼 수 있습니다. 가장 세밀한 단위는 identity 또는 tag별 usage type/일이며 요청별 비용은 아닙니다. Shared role에서 사용자 단위가 필요하면 Identity Provider의 session tag를 전달하고 role trust policy에 sts:TagSession을 허용합니다. 태그는 principal의 첫 Bedrock 호출 뒤 Billing에 표시되며, 비용 배분 태그로 활성화한 뒤 반영까지 최대 24시간이 걸리고 비소급적입니다. Caller identity가 필요한 CUR 2.0 export는 새로 만들어야 합니다.

반면 요청별 metadata tagging은 현재 bedrock-runtime 전용이고 Mantle에는 지원되지 않습니다. 따라서 현실적인 단계는 다음과 같습니다.

1. 환경조직별 AWS account 또는 role을 분리하고 최소 권한을 적용합니다.
2. IAM principal·session tag를 AWS Billing의 cost allocation tag로 활성화하고, caller identity ARN을 포함하는 새 CUR 2.0 export를 만듭니다.
3. Default project와 가능한 project tag를 Cost Explorer/CUR에 활성화합니다.
4. AWS/BedrockMantle의 account/project/model token과 error를 dashboard로 만듭니다.
5. AWS Budgets action을 구성하고, 임계값 초과 시 자동 또는 수동 승인으로 적용할 IAM policy/SCP와 실행 role을 사전에 테스트합니다. 완료된 action의 해제(reversal)는 AWS Budgets의 Action history나 API에서 별도로 수행합니다.
6. Codex에 공식 project 선택 기능이 추가되면 팀별 project로 마이그레이션합니다.

Interface endpoint에는 AZ별 시간 요금과 처리 데이터 요금이 추가됩니다. NAT Gateway 제거에 따른 절감만 보지 말고, endpoint 수, AZ 수, 처리량, 하이브리드 연결과 DNS 운영 비용을 전체 비용 모델에 포함하십시오.

7. AWSome AI Gateway를 선택적으로 적용합니다

여러 팀이 Codex, Claude Code와 Cowork를 함께 운영할 때는 인증, 예산, 모델 접근과 사용량을 한곳에서 관리할 수 있습니다. 이 과정에서 필자(박규태 AI Specialist SA)는 AWS Specialist SA, GenAIIC 동료들과 함께 MIT-0 오픈소스 샘플 AWSome AI Gateway를 개발해 공개했습니다. 로그인 뒤 Cognito가 발급한 id_token을 Admin API가 JWKS로 검증하고 /v1/auth/exchange에서 Virtual Key(VK)로 교환합니다. Codex custom Responses provider는 이 VK를 gateway proxy에 제시하고, proxy는 팀·사용자·앱별 예산, Rate Limit, 모델 접근·라우팅과 사용량 추적을 적용합니다. 이어 허용한 필드만 IRSA 기반 upstream 자격 증명으로 다시 구성하는 re-origination으로 클라이언트 VK와 Bedrock 자격 증명을 분리합니다.

그림 10. Codex의 직접 연결을 기본 경로로 유지하면서, AWSome AI Gateway가 OIDC/VK, re-origination, 예산·접근 정책·라우팅과 사용량 통제를 추가하는 구조입니다.

그림 10A. AWSome AI Gateway 샘플의 참조 배포를 펼친 그림입니다. ap-northeast-2의 Admin API가 Cognito id_token을 검증해 VK를 발급하고 gateway proxy가 VK를 검증한 뒤, IRSA 기반 upstream 자격 증명으로 us-east-2의 Bedrock Mantle에 요청을 다시 보냅니다. 선택형 서버사이드 검색에서는 proxy가 도구를 주입, 가로채고 us-east-1의 AgentCore Gateway Web Search 결과를 Mantle 요청으로 전달합니다.

필요하면 AWSome AI Gateway가 요청에 검색 도구를 주입하고, 모델의 tool call을 가로채 AgentCore Gateway의 Web Search Tool connector를 호출한 뒤 결과를 모델에 재투입할 수 있습니다. 이는 1절의 Mantle hosted cached Web Search와 다른 선택 기능입니다. 샘플의 기본 배포는 gateway service를 ap-northeast-2, Codex용 Mantle backend를 us-east-2, AgentCore managed Web Search를 us-east-1에 두므로 데이터 레지던시·리전 간 지연·비용을 함께 검토해야 합니다. Codex의 공식 기본 경로는 여전히 내장 amazon-bedrock provider의 직접 연결이며, 게이트웨이를 쓸 때만 Quickstart에 문서화된 별도 custom Responses provider를 사용합니다. 저장소가 밝히듯 현재 구현은 sample/prototype이며 production-ready 제품이 아니므로, 실제 적용 전 보안·가용성·버전 호환성을 검증해야 합니다.

그림 11. 실제 AWS 콘솔 또는 AWSome AI Gateway 화면이 아닌 운영 모니터링 블루프린트입니다. Dashboard와 alarm은 AWS/BedrockMantle, Cost Explorer/CUR, opt-in CloudTrail과 검증된 AWSome AI Gateway 자체 metric처럼 출처가 확인된 신호만 사용해야 합니다.

그림 11A. AWS/BedrockMantle의 inference·token·4xx metric은 CloudWatch alarm으로, opt-in CloudTrail data event와 VPC Flow Logs, gateway event는 감사, 경로 이상 분석으로, Cost Explorer, CUR, Budgets는 예산 대응으로 연결합니다. Prompt, response content logging은 Mantle 기본 관측 경로에 포함하지 않습니다.

8. 지원 기능과 제한 확인

Bedrock provider를 쓰면 모델 backend가 바뀌지만 모든 OpenAI cloud 기능이 함께 제공되는 것은 아닙니다. 최신 공식 feature matrix를 배포 전 확인하십시오.

2026년 8월 14일 현재 Web search 항목은 정적 feature matrix와 Codex CLI 0.147.0 release·구현이 실제로 다릅니다. 조직 배포 문서에는 검증한 클라이언트 버전, surface와 기능을 함께 기록하십시오.

운영 체크리스트

배포 전 다음 항목을 확인합니다.

• 모델 ID는 Codex 공식 지원 목록에 있고, 선택한 리전은 해당 AWS 모델 카드의 제공 리전이다.
• amazon-bedrock provider를 사용하고 일반 OpenAI SDK 설정을 섞지 않았다.
• API key보다 IAM role, SSO 같은 단기 자격 증명을 우선 검토했다.
• /status에서 provider와 model을 확인하고 짧은 실제 추론을 성공시켰다.
• Cached web search를 쓴다면 InvokeSearch, InvokeFetch 권한, query 비용, citation과 별도 CloudTrail data event를 검토했다.
• 데이터 retention mode, Responses 저장과 abuse-detection 보존을 규정 담당자가 검토했다.
• CloudWatch namespace를 AWS/BedrockMantle로 구성했다.
• 필요한 CloudTrail Mantle data event를 명시적으로 활성화하고 비용을 승인했다.
• Mantle에 Runtime model invocation logging이 적용된다고 가정하지 않았다.
• PrivateLink 서비스가 amazonaws.<region>.bedrock-mantle이며 Private DNS가 활성화됐다.
• 온프레미스 DNS가 Route 53 Resolver inbound endpoint로 조건부 전달된다.
• IAM identity policy와 VPC endpoint policy가 모두 최소 권한으로 평가된다.
• Bedrock hosted cached web search와 별도 egress가 필요한 Git, package registry, MCP·브라우저 도구, credential refresh를 구분해 설계했다.
• 비용은 account/default project/model 기준으로 먼저 검증하고 현재 attribution 공백을 문서화했다.
• AWSome AI Gateway를 사용한다면 문서화된 custom Responses provider, VK 갱신, 정책 집행과 direct-path 복구를 현재 Codex 버전에서 검증했다.

마무리

Amazon Bedrock을 Codex의 모델 backend로 사용하면 로컬 개발 경험을 유지하면서 AWS 네이티브 인증, 사용량 기반 과금, CloudWatch·CloudTrail과 AWS PrivateLink를 결합할 수 있습니다. 성공적인 도입의 핵심은 “Bedrock”이라는 이름만 보고 기존 Runtime 구성을 복사하지 않고, Codex → 내장 Bedrock provider → Bedrock Mantle → /openai/v1/responses라는 실제 경로를 기준으로 모든 통제를 다시 확인하는 것입니다.

먼저 한 리전, 한 모델, 한 팀으로 연결과 비용을 검증하십시오. 그다음 단기 자격 증명, 데이터 보존 정책, Mantle 전용 metric, Private DNS, endpoint policy와 하이브리드 DNS를 단계적으로 추가하면 오류가 발생한 계층을 명확히 분리할 수 있습니다. 마지막으로 현재 문서화되지 않은 Guardrails 직접 적용, prompt content logging과 세밀한 project attribution은 “이미 지원되는 기능”으로 가정하지 말고 제품 업데이트와 실제 시험으로 해소해야 합니다.