Managing Amazon Bedrock costs end to end: A playbook for FinOps and platform teams

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon Bedrock 비용 관리는 비용 귀속·요청 관측·예산 집행·플랫폼 기본값 최적화·정기 검토를 연결하는 운영 체계이며, 제공된 본문은 예산 집행의 IAM 태그 기반 방식 설명 도중 끝난다.

📌 핵심 요약

• 에이전트 워크플로의 토큰 소비는 사용자 상호작용 수보다 자율성 수준과 컨텍스트 크기에 좌우되므로, Amazon Bedrock 비용 관리는 애플리케이션 팀과 클라우드 지출 책임 팀이 공동으로 다뤄야 하는 아키텍처·운영 과제다.
• 운영 체계는 비용 귀속, 요청 관측, 예산 집행, 플랫폼 기본값 최적화, 정기 검토의 5단계 순환으로 구성된다. FinOps는 1·5단계, 플랫폼 엔지니어링은 2~4단계를 주도하고 검토는 공동으로 수행한다.
• Amazon Bedrock은 추론 비용을 호출한 IAM 주체에 자동 귀속한다. CUR 2.0과 비용 할당 태그로 팀·애플리케이션별 비용을 구분하고, 공유 게이트웨이에서는 사용자별 역할 세션과 세션 태그로 귀속을 복원한다. bedrock-runtime은 IAM 주체 귀속을 우선 권장하며, bedrock-mantle의 Responses API·Chat Completions API에는 Projects를 사용한다.
• 호출 로그와 공통 요청 메타데이터는 비용을 발생시킨 기능·워크플로·테넌트를 설명한다. CUR 귀속에는 약 24시간의 지연이 있지만 CloudWatch와 OpenTelemetry는 수분 내 지출 가시성을 제공할 수 있으며, 플랫폼 팀은 메타데이터를 중앙에서 주입하고 일관성을 관리해야 한다.
• 예산 집행은 3개 수준을 제시하지만, 제공된 본문에는 차단 없는 AWS Budgets 경고 방식과 IAM 태그 기반 차단 방식의 일부만 담겨 있다. 후자는 AWS Lambda와 Amazon DynamoDB로 사용자별 사용량을 집계하고 임계값 초과 사용자를 bedrock:* 거부 정책에 추가하며, 월별 초기화나 관리자 재정의 전까지 차단하는 방식이다.

🧩 주요 포인트

1. 에이전트의 자율성·컨텍스트가 소비를 결정 → 모델 단가와 프롬프트 길이뿐 아니라 워크플로 설계와 운영 방식까지 비용 관리 대상이 된다.
2. IAM 주체 귀속과 공통 요청 메타데이터의 결합 → 비용 책임자와 비용을 만든 워크플로를 함께 파악해 비용 배분·예산·이상 징후 분석의 근거를 마련한다.
3. CUR의 약 24시간 지연과 AWS Budgets의 비차단 특성 → 지출 속도와 초과 지출 허용 수준에 따라 신속한 관측 및 IAM 기반 집행의 필요성을 판단해야 한다.

🧠 상세 정리

1. 에이전트 비용은 설계와 운영에서 결정된다

생성형 AI 비용 관리는 애플리케이션을 만드는 팀과 클라우드 지출을 책임지는 팀의 공동 책임이며, 모델별 토큰 단가 비교와 프롬프트 단축만으로는 규모 확대에 따른 관리 문제를 해결하기 어렵다. 재무·엔지니어링 책임자가 알아야 하는 것은 어느 팀이 어떤 워크로드에 비용을 썼고 그 지출이 승인된 예산 안에 있었는지다. 일반적인 대화형 도우미는 사용자 발화마다 보통 한 번 모델을 호출하지만, 변경을 계획하고 파일을 읽고 도구를 호출하며 반복하는 에이전트는 작업 하나에 여러 번 호출하고 매번 더 큰 컨텍스트를 전달한다. 따라서 토큰 소비는 사용자 상호작용 수보다 부여한 자율성과 유지하는 컨텍스트 크기에 따라 달라진다. 원문은 공개 평균값을 실제 사용량의 대체재로 삼지 말고, AWS Pricing Calculator와 Amazon Bedrock 가격 페이지로 요금을 모델링한 뒤 자체 워크로드의 실제 소비를 측정하라고 제안한다.

2. 비용 관리의 5단계를 순환 운영한다

원문이 제시하는 해법은 더 저렴한 모델이나 더 짧은 프롬프트에 한정되지 않으며, 비용 책임과 관측·통제를 연결하는 반복 가능한 운영 체계다. 첫 단계는 모든 Amazon Bedrock 비용을 신원·팀·애플리케이션에 귀속하고, 두 번째는 각 요청에 비용 발생 원인을 설명할 수 있는 로그와 메타데이터를 남기는 것이다. 세 번째는 예산 경고와 위험에 따른 강제 차단을 적용하고, 네 번째는 모델 라우팅·캐싱·토큰 한도 같은 플랫폼 기본값에서 낭비를 줄이며, 다섯 번째는 소규모 성과표와 정기 검토로 데이터를 의사결정에 연결한다. FinOps는 비용 귀속과 운영 검토를, 플랫폼 엔지니어링은 관측·집행·최적화를 주도하며 검토 자체는 공동으로 수행한다. 각 단계는 앞 단계에 의존하므로 비용 귀속과 관측 없이 최적화부터 시작하면 추측에 의존하게 된다는 것이 원문의 핵심 주장이다.

3. IAM 주체를 기준으로 비용 귀속을 설정한다

Amazon Bedrock은 모든 모델의 추론 비용을 실제 호출한 IAM 주체에 자동으로 귀속하며, 이를 위해 별도 리소스를 관리할 필요가 없다고 설명한다. 호출자의 ARN은 AWS Cost and Usage Report인 CUR 2.0의 line_item_iam_principal 열에 기록되고, 지원 범위에는 IAM 사용자·역할·연합 신원·API 키가 포함된다. 설정은 CUR 2.0 데이터 내보내기에서 IAM 주체 데이터를 활성화하고, 주체에 팀·애플리케이션·비용 센터 등의 태그를 붙인 뒤, AWS Billing에서 이를 비용 할당 태그로 활성화하는 순서다. 연합 접근에서는 자격 증명 공급자가 OIDC 또는 SAML 클레임으로 세션 이름과 태그를 전달하도록 구성한다. 활성화된 태그는 CUR 2.0에서 iamPrincipal/ 접두사로 제공되고, AWS Cost Explorer에는 활성화 후 24~48시간 안에 IAM 범주로 나타나 팀이나 애플리케이션별 필터링과 집계에 활용된다.

4. 공유 게이트웨이의 귀속 손실을 사용자별 세션으로 해결한다

LLM 게이트웨이가 단일 IAM 역할로 Amazon Bedrock을 호출하면 모든 비용이 그 역할에 귀속되어 사용자별 가시성이 사라지며, 원문은 이를 플랫폼에서 특히 주의해야 할 문제로 지적한다. 제시된 해결책은 게이트웨이가 사용자마다 Amazon Bedrock 호출 역할을 수임하고, 사용자 신원은 역할 세션 이름으로, 사용자 속성은 세션 태그로 전달하는 방식이다. 반환된 자격 증명은 최대 1시간 캐시하므로 AWS STS 호출은 요청마다 발생하는 것이 아니라 사용자당 시간당 한 번 발생한다. 이를 위해 sts:AssumeRole과 sts:TagSession 권한을 가진 게이트웨이 실행 역할과, 그 역할이 수임할 Amazon Bedrock 호출 역할을 구분한다. 그러면 line_item_iam_principal에 assumed-role/BedrockRuntimeRole/gw-alex 같은 사용자별 세션이 기록되고 해당 사용자의 태그도 함께 전달되어, 공유 게이트웨이 뒤에서도 사용자별·테넌트별 비용 귀속을 복원할 수 있다.

5. 엔드포인트와 사용 패턴에 맞는 귀속 수단을 선택한다

IAM 주체 귀속 외에도 Amazon Bedrock은 애플리케이션 추론 프로필과 Projects·workspaces라는 귀속 수단을 제공하며, 원문은 각각 다른 사용 패턴에 적합하다고 구분한다. 애플리케이션 추론 프로필은 bedrock-runtime에서 사용하는 사전 생성 리소스로, 애플리케이션·모델·AWS Region 조합마다 하나를 만들고 호출자가 해당 프로필 ARN을 참조하며 비용 할당 태그를 부여할 수 있다. 이 방식은 애플리케이션과 모델 구성이 작고 안정적이거나, 신원 설계를 바꾸지 않고 소수 사업 단위의 청구 비용을 분리하려는 경우에 적합하다. Projects와 workspaces는 Responses API·Chat Completions API를 제공하는 bedrock-mantle에 대응하며, 프로젝트 하나가 특정 모델에 묶이지 않아 여러 모델을 포괄하고 클라이언트 초기화 시 전달한 프로젝트 ID의 태그가 CUR 2.0과 Cost Explorer로 이어진다. 원문은 bedrock-runtime에는 신원 체계에 따라 확장되고 모든 모델과 API 작업을 포괄하는 세션 태그 기반 IAM 주체 귀속을 우선 권장하며, bedrock-mantle의 OpenAI 호환 워크로드에는 Projects를 사용하도록 안내한다.

6. 호출 로그로 실제 소비와 지연 구간을 관측한다

CUR가 누가 비용을 썼는지 알려준다면, 모델 호출 로그는 어떤 요청과 응답이 그 비용을 만들었는지 설명한다. Amazon Bedrock은 요청 데이터·응답 데이터·메타데이터를 Amazon CloudWatch Logs와 Amazon S3 중 하나 또는 양쪽에 기록할 수 있으며, 원문은 빠른 운영 질의에는 CloudWatch를, 장기적인 비즈니스 분석에는 S3와 Amazon Athena를 제안한다. 로깅은 수동으로 켜는 옵션이 아니라 인프라로 다뤄야 하므로, 로그 그룹이나 버킷을 코드로 생성하고 보존·암호화 정책을 정의하며 환경 구성 과정에서 전달 여부를 검증해야 한다. 개발 환경이나 특정 Region에서만 로그를 수집하면 사용량이 늘어날 때 비용 관리의 관측 범위가 분절된다. 또한 CUR 귀속의 약 24시간 지연을 보완하기 위해 CloudWatch와 OpenTelemetry를 활용하면 수분 안에 개발자별 지출을 보여주는 준실시간 가시성을 확보할 수 있다고 설명한다.

7. 요청 메타데이터로 워크로드별 원인을 설명한다

신원 중심의 원시 로그만으로는 어떤 기능·워크플로·테넌트가 토큰을 발생시켰는지 충분히 설명하기 어려우므로, 원문은 모든 호출에 요청 메타데이터를 추가하도록 제안한다. 예시는 Amazon Bedrock의 미국 교차 리전 추론 프로필을 통해 Anthropic Claude Sonnet 5.5를 호출하면서 requestMetadata에 application·workflow·tenant·agent를 전달하며, 이 값들은 이후 분석을 위해 호출 로그에 기록된다. Amazon Bedrock 자체는 요청 메타데이터를 강제하지 않으므로 애플리케이션마다 구현을 맡기면 스키마가 쉽게 달라질 수 있다는 한계도 명시한다. 따라서 플랫폼 팀은 공통 SDK 래퍼나 게이트웨이에서 필수 메타데이터를 주입하고 키 집합을 표준화하며 메타데이터 적용 범위를 플랫폼 상태 지표로 관리해야 한다. CloudWatch Logs Insights에서는 호출자·모델별 입력과 출력 토큰 합계 및 호출 수를 집계하고, application·workflow 기준으로 바꾸면 워크로드별 소비 순위를 볼 수 있지만, 예시 필드 경로는 모델·API 작업·로깅 설정에 따라 달라질 수 있어 실제 스키마 확인이 필요하다.

8. 예산 경고와 IAM 차단의 차이를 구분한다

비용 귀속과 관측을 마련한 다음에는 지출 속도, 초과 지출 허용 수준, 도구의 Amazon Bedrock 연결 방식에 따라 예산 집행 구조를 선택한다. 원문은 세 가지 수준이 있다고 소개하지만, 제공된 본문에는 첫 번째 수준과 두 번째 수준의 설명 일부만 포함되어 있다. 첫 번째는 자동으로 기록되는 주체별 청구 정보 위에 AWS Budgets 임계값 경고를 적용하고 OpenTelemetry 관측으로 CUR 지연을 보완하는 방식으로, 별도 배포나 추론 호출의 추가 지연 없이 직접 호출 도구에도 적용되지만 지출을 강제로 멈추지는 못한다. 따라서 경고와 사람의 개입으로 충분한 초기 도입 단계에 적합하며, 문제가 발생한 뒤 이를 인지한다는 한계가 있다. 두 번째인 IAM 태그 기반 집행은 집계용 AWS Lambda가 호출 로그에서 사용자별 토큰·금액 카운터를 Amazon DynamoDB에 누적하고, 임계값을 초과한 신원을 bedrock:*를 거부하는 공유 IAM 정책에 추가해 월별 초기화나 관리자 재정의 전까지 차단하는 방식이다. 본문은 이 집행이 IAM에서 수행된다는 설명 도중 끝나므로, 두 번째 수준의 나머지 조건이나 세 번째 수준의 구현 내용은 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 비용 귀속과 요청 관측은 서로 다른 질문에 답한다. IAM 주체는 비용 책임자를 식별하고 요청 메타데이터는 소비를 만든 워크로드를 설명하므로, 두 정보를 함께 갖춰야 비용 배분과 원인 분석을 연결할 수 있다.
• 공유 게이트웨이는 메타데이터를 일관되게 주입할 지점이지만 단일 IAM 역할로 호출하면 사용자별 비용 귀속을 잃는다. 사용자별 세션과 세션 태그가 중앙화된 호출 경로에서도 귀속을 유지하는 핵심 조건이다.
• 예산 가시성과 예산 차단은 구분해야 한다. 준실시간 관측은 청구 데이터의 지연을 보완하지만, AWS Budgets 경고만으로 지출이 중단되지는 않으므로 허용 가능한 초과 지출 수준에 맞춰 집행 방식을 선택해야 한다.

✅ 액션 아이템

• Amazon Bedrock의 에이전트 워크플로별 자율성 수준과 컨텍스트 크기를 실제 토큰 소비와 연결해 검토한다.
• IAM 주체 귀속과 공통 요청 메타데이터를 정비하고, 공유 게이트웨이의 사용자별 역할 세션과 세션 태그 적용을 확인한다.
• CUR의 약 24시간 지연과 AWS Budgets의 비차단 특성을 고려해 지출 속도 및 초과 지출 허용 수준에 맞는 IAM 기반 집행 필요성을 평가한다.

❓ 열린 질문

• Amazon Bedrock의 에이전트 워크플로에서 자율성 수준과 컨텍스트 크기는 실제 토큰 소비에 각각 얼마나 영향을 주는가?
• 공유 게이트웨이의 사용자별 역할 세션과 세션 태그, 공통 요청 메타데이터가 비용 책임자와 워크플로를 충분히 식별하고 있는가?
• CUR의 약 24시간 지연과 AWS Budgets의 비차단 특성을 감안할 때 현재 지출 속도와 초과 지출 허용 수준에 IAM 기반 집행이 필요한가?