Amazon Bedrock에서 LLM 게이트웨이의 두 사각지대 메우기: 사라진 호출자와 흐려진 모델 거버넌스

Amazon Bedrock 앞에 LLM 게이트웨이를 두면 호출 편의성이 생기지만 '누가 호출했는지'와 '어느 모델을 썼는지'가 게이트웨이 뒤로 흐려지는 두 사각지대가 생긴다. LiteLLM을 프록시로 두고 X-Amzn-Bedrock-Request-Metadata 헤더와 Application Inference Profile을 조합해 이 두 문제를 동시에 해결하는 방법을 다룬다.

핵심 포인트

사각지대 1: 게이트웨이가 Bedrock에 요청을 대신 보내면 Model Invocation Log에 게이트웨이 자신만 호출자로 기록되어 팀별 추적 불가.
해결 1: X-Amzn-Bedrock-Request-Metadata 헤더에 사용자 ID·팀·litellm_call_id를 주입하면 requestMetadata 필드에 기록돼 Bedrock 로그와 게이트웨이 로그를 call_id로 조인 가능.
사각지대 2: 단일 IAM Role 공유 시 모델별 호출량·토큰·비용을 CloudWatch에서 분리할 수 없음.
해결 2: Application Inference Profile을 모델마다 생성하고 IAM 권한을 프로파일 ARN으로 한정해 CloudWatch에서 모델별 메트릭 수집.
Virtual Key 레벨 예산으로 사용자별 Bedrock 한도 강제, IAM Identity Center 그룹을 팀으로 자동 매핑해 온보딩 자동화.

상세 정리

호출자 식별 문제: LiteLLM이 Bedrock에 직접 요청하면 Invocation Log의 호출자가 LiteLLM 자신으로만 찍혀 팀·사용자 단위 비용 배분이 불가능하다.
메타데이터 헤더 주입: LiteLLM 미들웨어에서 X-Amzn-Bedrock-Request-Metadata에 사용자·팀·litellm_call_id를 주입하고, Bedrock 로그와 게이트웨이 로그를 call_id로 조인해 양쪽을 연결한다.
모델 거버넌스 문제: IAM Role 하나로 여러 모델을 호출하면 CloudWatch에서 모델별 사용량 분리가 안 된다.
Application Inference Profile 도입: 모델마다 Profile을 만들어 IAM 권한을 프로파일 ARN 단위로 한정하고, CloudWatch에서 프로파일 단위 메트릭을 수집한다.
pass-through 로깅 버그: Profile ARN에서 provider를 명시하지 않으면 사용량 로그가 깨지는 버그가 있어, provider를 명시적으로 지정해 해결했다.
IAM Identity Center 자동 매핑: 그룹을 팀으로 자동 매핑해 Virtual Key 발급 온보딩 절차를 자동화했다.
네트워크 격리: VPC Interface Endpoint + 3-tier 서브넷(퍼블릭/프라이빗/격리) + 보안 그룹 체인으로 private 통신을 구성했다.
운영 안정성: SpendLog 테이블 파티셔닝, 주기적 롤링 재시작, Least Outstanding Requests 로드밸런싱으로 편차를 완화했다.
설계 원칙: '게이트웨이는 가볍게 유지하고, Bedrock이 네이티브로 제공하는 것은 Bedrock에 맡긴다.'

왜 읽나Amazon Bedrock + LiteLLM 조합으로 기업 LLM 플랫폼을 운영하는 팀이 호출자 추적·모델별 관측성·비용 거버넌스를 동시에 잡는 구체적인 설정 레시피를 얻을 수 있다.

AWS Korea Tech 블로그

원문은 여기서 이어서 읽을 수 있어요

원문 읽기

읽음 (0)

·takedown 요청

Amazon Bedrock에서 LLM 게이트웨이의 두 사각지대 메우기: 사라진 호출자와 흐려진 모델 거버넌스

이 글과 비슷한

에이전틱 SDLC를 QA 엔지니어링 마인드셋으로 구축하기

보안 업무를 위한 AI 에이전트 플랫폼 「SAGE」 개발기 1편: 판단은 사람에게 남기는 설계

실리콘투의 사내 지식 MCP 게이트웨이 구축기