マルチクラウド環境でのLLMコスト管理 - LiteLLM Proxy基盤構築
1. はじめに
弁護士ドットコム SRE 室の櫛部勇気と申します。
当社の SRE 室は、全社横断の組織として Enabling SRE(開発チーム支援)と Platform SRE(基盤提供)の両方の役割を担っています。 Platform SRE 業務の一環として、マルチクラウド環境で生成 AI へのアクセス基盤を社内に提供しています。
生成 AI へのアクセス基盤提供にあたって、社内向けの LLM プロキシ基盤として AWS 上に LiteLLM を構築しました。 ツール選定の背景、構成概要および他ツールとの連携につきましてご紹介します。
2. LLM プロキシとして LiteLLM の選定
当社で LLM プロキシを導入した背景として「各ユーザーが何のモデルに対し、どれだけのトークンを消費し、どのくらいコストがかかっているのか把握したい」という要件がありました。
ユーザーごとに LLM の利用量に偏りがありそうで、ヘビーユーザーには定額課金のプランに乗り換えてもらい、コストの最適化を図りたいと考えていました。 しかし、私たちが調査した範囲では、Amazon Bedrock, Azure OpenAI, Vertex AI のどれも上記の要件を満たす形でコストを計測する機能は確認できませんでした。
当初は Amazon Bedrock のトレースログを S3 に出力し、その内容を分析する運用も検討しました。しかし、Azure OpenAI や Vertex AI についても別途考慮が必要であり、加えてトレースログのクレンジングや集計が想像以上に大変であったため、採用は見送りました。
LLM プロキシの選定にあたっては、最終的にローカルで検証した LiteLLM の動作が良さそうであったため、こちらを AWS へ移植し、社内プロキシとして運用する判断としました。
LiteLLM の機能では「ユーザー × トークン」の粒度でコストを計測できますが「ユーザー × モデル × トークン」の粒度では提供されていません。このため Datadog にログを転送し、Datadog 側のメトリクスフィルターを用いて実現しました。
システム構成図

上記の図は、本システムのアーキテクチャを示しています。 クライアントからのリクエストは ALB 経由で ECS Fargate 上の LiteLLM に到達し、各 LLM プロバイダーへルーティングが行われます。メタデータは Aurora PostgreSQL、ログなどのデータは Datadog で管理します。
公式から提供されている LiteLLM は、docker-compose を確認すると LiteLLM および PostgreSQL の 2 コンテナ構成となっています。当社では安定稼働とデータ保全のため、PostgreSQL はコンテナから Aurora に移行しました。
3. LiteLLM の実装
LiteLLM の稼働にあたって、主要なファイルは次のとおりです。
config.yaml
LiteLLM の中核となる設定ファイルです。LLM モデル定義、認証情報、アラート設定などを管理しています。Datadog や Slack との連携設定も含まれています。
ファイル内容(抜粋)
model_list:
# AWS Bedrock
- model_name: claude-opus-4-20250514
litellm_params:
model: bedrock/us.anthropic.claude-opus-4-20250514-v1:0
aws_region_name: us-west-2
- model_name: claude-opus-4-20250514
litellm_params:
model: bedrock/us.anthropic.claude-opus-4-20250514-v1:0
aws_region_name: us-east-1
- model_name: claude-opus-4-20250514
litellm_params:
model: bedrock/us.anthropic.claude-opus-4-20250514-v1:0
aws_region_name: us-east-2
:
# Azure OpenAI
- model_name: azure-openai-o3
litellm_params:
model: azure/o3
api_base: "https://hoge.openai.azure.com/openai/deployments/o3/"
api_key: os.environ/AZURE_OPENAI_API_KEY
api_version: "2025-01-01-preview"
:
# Google Cloud
- model_name: gemini-2.5-pro
litellm_params:
model: vertex_ai/gemini-2.5-pro
vertex_project: "bengo4-gemini"
vertex_location: "global"
vertex_credentials: "/app/application_credentials.json"
:
general_settings:
master_key: os.environ/LITELLM_MASTER_KEY
store_model_in_db: true
alerting: ["slack"]
:
litellm_settings:
callbacks: ["smtp_email", "datadog"]
:
AWS Bedrock の特定リージョンへのアクセスが集中し、429 too many tokensエラーが頻発していました。この問題を解決するため、アクセス先を 3 つのリージョンに分散させるよう設定しています。こちらによりエラーの発生は大幅に解消されています。
加えて次の内容も設定しています。
general_settings: Web UI 認証と Slack 通知設定litellm_settings: SMTP(ユーザー登録通知)と Datadog(ログ連携)の設定
dockerfile
後述の entrypoint.sh を実行するため、公式の LiteLLM イメージをベースに busybox(/bin/sh)をインストールしています。
ファイル内容
# Dockerfile
FROM ghcr.io/berriai/litellm:main-latest
RUN apk update && apk add --no-cache aws-cli busybox gettext
COPY config.yaml /app/config.yaml
COPY entrypoint.sh /app/entrypoint.sh
RUN chmod +x /app/entrypoint.sh
ENTRYPOINT ["/app/entrypoint.sh"]
CMD ["litellm", "--config", "/app/config_runtime.yaml"]
entrypoint.sh
コンテナ起動時の初期化スクリプトです。Aurora への接続設定と、Google Cloud における認証情報をファイル形式で出力します。 Google Cloud における認証情報のファイルは JSON でやり取りをしますが、パラメータストアでは直接やり取りできないため、コンテナ上のファイルへ出力しています。
ファイル内容
#!/bin/sh
set -e
export DATABASE_URL="postgresql://postgres:${POSTGRES_PASSWORD}@litellm.cluster-ap-northeast-1.rds.amazonaws.com:5432/litellmdb"
# GCP認証情報をファイルとして書き出し
if [ -n "$GCP_VERTEX_AI_CREDENTIALS" ]; then
echo "$GCP_VERTEX_AI_CREDENTIALS" > /app/application_credentials.json
chmod 600 /app/application_credentials.json
fi
# config.yamlテンプレートから実際のconfig.yamlを生成
envsubst < /app/config.yaml > /app/config_runtime.yaml
exec "$@"
litellm-task.json
ECS のタスク定義です。 環境変数として LiteLLM の URL や、SMTP 周りのパラメータを持っています。 またシークレットとしては各種 LLM とやり取りするための認証情報や、Slack/Datadog に接続するためのパラメータを持っています。 それぞれ認証情報はパラメータストアから取得しています。taskRole では Amazon Bedrock 呼び出し権限のみを付与しています。
ファイル内容(抜粋)
{
"containerDefinitions": [
{
"name": "litellm",
"image": "000000000000.dkr.ecr.ap-northeast-1.amazonaws.com/litellm:custom",
"cpu": 0,
"portMappings": [
{
"name": "litellm-8000-tcp",
"containerPort": 8000,
"hostPort": 8000,
"protocol": "tcp"
}
],
"essential": true,
"command": [
"litellm",
"--config",
"/app/config.yaml",
"--port",
"8000",
"--num_workers",
"4"
:
"environment": [
{
"name": "AWS_REGION",
"value": "ap-northeast-1"
},
{
"name": "SMTP_PORT",
"value": "587"
},
{
"name": "PROXY_BASE_URL",
"value": "https://hoge.bengo4.com"
},
{
"name": "SMTP_HOST",
"value": "email-smtp.ap-northeast-1.amazonaws.com"
},
{
"name": "SMTP_SENDER_EMAIL",
"value": "no-reply@hoge.bengo4.com"
},
:
],
"secrets": [
{
"name": "LITELLM_MASTER_KEY",
"valueFrom": "arn:aws:ssm:ap-northeast-1:000000000000:parameter/litellm/litellm/masterkey"
},
{
"name": "AZURE_OPENAI_API_KEY",
"valueFrom": "arn:aws:ssm:ap-northeast-1:000000000000:parameter/litellm/azure/openai_api_key_us_east2"
},
{
"name": "GCP_VERTEX_AI_CREDENTIALS",
"valueFrom": "arn:aws:ssm:ap-northeast-1:000000000000:parameter/litellm/gcp/vertex_ai_credentials"
},
{
"name": "DD_API_KEY",
"valueFrom": "arn:aws:ssm:ap-northeast-1:000000000000:parameter/litellm/datadog/dd_api_key"
},
{
"name": "DD_SITE",
"valueFrom": "arn:aws:ssm:ap-northeast-1:000000000000:parameter/litellm/datadog/dd_site"
},
{
"name": "SLACK_WEBHOOK_URL",
"valueFrom": "arn:aws:ssm:ap-northeast-1:000000000000:parameter/litellm/litellm/slack_webhook_url"
},
{
"name": "POSTGRES_PASSWORD",
"valueFrom": "arn:aws:ssm:ap-northeast-1:000000000000:parameter/litellm/aurora/master_password"
}
],
:
"family": "litellm-task",
"taskRoleArn": "arn:aws:iam::000000000000:role/LitellmApiRole",
"executionRoleArn": "arn:aws:iam::000000000000:role/ecsTaskExecutionRole",
"networkMode": "awsvpc",
:
4. LLM API との連携
LiteLLM はあくまで LLM プロキシであるため、接続先となる各 LLM プロバイダー提供の API についても有効にする設定が必要です。当社では Amazon Bedrock、Azure OpenAI、Vertex AI をそれぞれ設定しています。
Amazon Bedrock とは前述のとおり taskRole 経由でやりとりしています。 Azure OpenAI は、API キーをパラメータストアに格納し、そちらを使ってアクセスします。 Gemini API については、Google Cloud 上で権限を Vertex AI に限定したサービスアカウントを発行し、発行した JSON 鍵をパラメータストアに格納しています。
5. Datadog との連携
LiteLLM の設定ファイル(config.yaml)にて、Datadog と連携するよう設定を入れています。
litellm_settings:
callbacks: ["smtp_email", "datadog"]
turn_off_message_logging: true
また問い合わせの中身自体は Datadog に転送されないよう、LiteLLM でマスクする設定になっています。Datadog に転送されたログは次のような形式となっています。

Datadog に送られるログにはモデル・トークン消費量・ユーザー名などが記録されています。こちらを元に利用状況の分析が可能です。
実際に利用している Datadog ダッシュボードの抜粋をご紹介します。ユーザー × モデル別の項目や、ユーザー別のリスト、利用されるモデルの傾向などが確認できます。

6. Slack Bot 連携による自動ユーザー作成
以前は、各プラットフォームに手動でユーザーを追加していて非常に手間がかかっていました。LiteLLM の導入にあたってこの運用負荷を下げるべく、Slack ワークフローから LiteLLM へ自動でユーザーを作成するようにしました。

利用者は Slack のワークフローからフォーム形式で必要事項を記入し、 Bot 経由で Lambda 関数が実行されます。Lambda は LiteLLM の API を実行することで LiteLLM でユーザーが新規作成されます。利用者には SES 経由で招待メールが送信され、そこからユーザー登録が可能です。
社内利用者が多いため、こちらは自動で処理できるようになってよかったポイントだと感じています。
7. まとめ
本記事では LiteLLM を活用した企業向けマルチクラウド LLM プロキシ基盤の構築について概要をご紹介しました。 AWS 上で LiteLLM を運用し、Amazon Bedrock、Azure OpenAI、Vertex AI を統合しました。 これによって単一のエンドポイントから複数の LLM サービスを利用できる環境を実現しました。
特に、ユーザー・モデル別にコストを計測するという要件に対して Datadog のメトリクスフィルターを活用した監視基盤を構築し、プライバシーを保護しながら運用データを収集する仕組みを確立しました。また IAM ロールとパラメータストアを組み合わせたセキュアな認証基盤により、各クラウドプロバイダーへの安全なアクセスを実現しています。
記事執筆時点でアクティブユーザーは数十名程度で、中にはヘビーユーザーもいらっしゃいますが、その割にはそこそこのスペックでよく動作しているという印象です。今後の LiteLLM の機能追加にも期待しています。
8. おわりに
弁護士ドットコムではさまざまなポジションのエンジニアを募集しています。 ご応募をお待ちしております。