Serveurs MCP en Production : Deploiement AWS Lambda, Monitoring et Optimisation des Couts | Talki Academy

Faire tourner un serveur MCP en local sur Claude Desktop fonctionne bien pour le prototypage. Mais quand votre integration d'entreprise doit servir 10 developpeurs, traiter 50 000 requetes par mois et satisfaire un audit SOC 2, il vous faut un deploiement en production. Ce guide couvre le chemin complet — d'une seule fonction Lambda a un service MCP monitore, auto-scalable et optimise en couts — avec des configs Terraform reelles, un handler Python fonctionnel et de vrais chiffres de production.

Audience cible : Developpeurs backend et praticiens MLOps qui ont deja construit un serveur MCP et cherchent maintenant a le deployer de maniere fiable a l'echelle. Une familiarite avec AWS Lambda et Python 3.11+ est supposee.

1. Architecture de reference

L'architecture ci-dessous gere les charges de travail declenchees et synchrones avec une seule unite de deploiement. Elle maintient les couts d'infrastructure sous 1 USD par mois pour 10 000 requetes (hors couts API LLM).

Couche	Composant	Justification
Declencheur	API Gateway HTTP API + SQS	HTTP pour les appels synchrones ; SQS pour les lots asynchrones depuis n8n
Calcul	Lambda (arm64, Python 3.12)	arm64 est 20% moins cher et 10-15% plus rapide que x86 pour du travail LLM I/O-bound
Routeur LLM	LiteLLM Proxy (ECS Fargate)	Endpoint unifie ; changement de modele sans toucher au code Lambda
Secrets	AWS Secrets Manager	Cles API jamais en variables d'environnement ; rotation automatique
Observabilite	CloudWatch + X-Ray	Natif AWS ; aucun agent supplementaire ; logs structures via powertools
Orchestration	n8n (auto-heberge)	Declencheurs de workflows visuels pour les appels MCP en lot ; regles de scaling no-code

# Vue d'ensemble de l'architecture (diagramme texte)
#
# [Claude Desktop / Client API]
#         │
#         ▼
# [API Gateway HTTP API]  ──── route : POST /mcp
#         │
#         ▼
# [Lambda : mcp-server]   ──── arm64, Python 3.12, 512 Mo
#         │                    timeout : 30s
#         │                    layers : mcp-sdk, powertools
#         ▼
# [LiteLLM Proxy]         ──── ECS Fargate, port 4000
#         │                    routes : claude-sonnet-4-5, claude-haiku-4-5
#         │                    fallback : gpt-4o-mini
#         ▼
# [API Anthropic / OpenAI]
#
# Chemin asynchrone (n8n) :
# [Declencheur n8n] ──── file SQS ──── Lambda (meme fonction)
#
# Secrets :
# Role IAM Lambda → Secrets Manager → ANTHROPIC_API_KEY

2. IAM et configuration Lambda avec Terraform

Le role IAM d'execution suit le principe du moindre privilege. Le Lambda a uniquement besoin d'ecrire des logs, d'emettre des traces X-Ray et de lire un secret specifique. Rien de plus.

# terraform/main.tf

terraform {
  required_providers {
    aws = { source = "hashicorp/aws", version = "~> 5.0" }
  }
}

provider "aws" {
  region = "eu-west-1"
}

# ── Role IAM ──────────────────────────────────────────────────────────
resource "aws_iam_role" "mcp_lambda" {
  name = "mcp-server-lambda-role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action    = "sts:AssumeRole"
      Effect    = "Allow"
      Principal = { Service = "lambda.amazonaws.com" }
    }]
  })
}

resource "aws_iam_role_policy" "mcp_lambda_policy" {
  name = "mcp-server-policy"
  role = aws_iam_role.mcp_lambda.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        # CloudWatch Logs
        Effect = "Allow"
        Action = ["logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents"]
        Resource = "arn:aws:logs:eu-west-1:*:log-group:/aws/lambda/mcp-server:*"
      },
      {
        # Traces X-Ray
        Effect = "Allow"
        Action = ["xray:PutTraceSegments", "xray:PutTelemetryRecords"]
        Resource = "*"
      },
      {
        # Secrets Manager — cible sur le secret exact
        Effect   = "Allow"
        Action   = ["secretsmanager:GetSecretValue"]
        Resource = aws_secretsmanager_secret.api_keys.arn
      }
    ]
  })
}

# ── Secrets Manager ───────────────────────────────────────────────────
resource "aws_secretsmanager_secret" "api_keys" {
  name                    = "mcp-server/api-keys"
  recovery_window_in_days = 7
}

resource "aws_secretsmanager_secret_version" "api_keys" {
  secret_id = aws_secretsmanager_secret.api_keys.id
  secret_string = jsonencode({
    ANTHROPIC_API_KEY = var.anthropic_api_key
    LITELLM_PROXY_URL = var.litellm_proxy_url
    LITELLM_API_KEY   = var.litellm_api_key
  })
}

# ── Fonction Lambda ───────────────────────────────────────────────────
resource "aws_lambda_function" "mcp_server" {
  function_name = "mcp-server"
  filename      = "lambda.zip"              # construit par le CI
  handler       = "handler.lambda_handler"
  runtime       = "python3.12"
  architectures = ["arm64"]                # 20% moins cher que x86
  role          = aws_iam_role.mcp_lambda.arn
  timeout       = 30
  memory_size   = 512

  environment {
    variables = {
      SECRET_ARN         = aws_secretsmanager_secret.api_keys.arn
      POWERTOOLS_SERVICE = "mcp-server"
      LOG_LEVEL          = "INFO"
    }
  }

  tracing_config { mode = "Active" }       # X-Ray actif
  layers = [aws_lambda_layer_version.mcp_deps.arn]

  source_code_hash = filebase64sha256("lambda.zip")
}

# ── API Gateway HTTP API ──────────────────────────────────────────────
resource "aws_apigatewayv2_api" "mcp" {
  name          = "mcp-server-api"
  protocol_type = "HTTP"
}

resource "aws_apigatewayv2_integration" "mcp_lambda" {
  api_id                 = aws_apigatewayv2_api.mcp.id
  integration_type       = "AWS_PROXY"
  integration_uri        = aws_lambda_function.mcp_server.invoke_arn
  payload_format_version = "2.0"
}

resource "aws_apigatewayv2_route" "mcp_post" {
  api_id    = aws_apigatewayv2_api.mcp.id
  route_key = "POST /mcp"
  target    = "integrations/${aws_apigatewayv2_integration.mcp_lambda.id}"
}

resource "aws_apigatewayv2_stage" "prod" {
  api_id      = aws_apigatewayv2_api.mcp.id
  name        = "prod"
  auto_deploy = true
}

output "mcp_endpoint" {
  value = "${aws_apigatewayv2_stage.prod.invoke_url}/mcp"
}

Handler Lambda — Python

Le handler resout les secrets une seule fois au cold-start (mis en cache dans la variable de niveau module), puis traite les appels d'outils MCP. AWS Lambda Powertools fournit le logging structure, les sous-segments X-Ray et l'idempotence avec un simple decorateur.

# handler.py
import json
import os
import boto3
from aws_lambda_powertools import Logger, Tracer
from aws_lambda_powertools.utilities.typing import LambdaContext
import httpx

logger = Logger()
tracer = Tracer()

# Niveau module : recupere une fois au cold-start, reutilise a chaque invocation chaude
_secrets: dict | None = None

def _get_secrets() -> dict:
    global _secrets
    if _secrets is None:
        client = boto3.client("secretsmanager", region_name="eu-west-1")
        response = client.get_secret_value(SecretId=os.environ["SECRET_ARN"])
        _secrets = json.loads(response["SecretString"])
    return _secrets

@tracer.capture_lambda_handler
@logger.inject_lambda_context(log_event=False)
def lambda_handler(event: dict, context: LambdaContext) -> dict:
    """
    Handler Lambda du serveur MCP.
    Corps JSON attendu : { "tool": str, "input": dict }
    Retourne : { "result": any, "usage": { "input_tokens": int, "output_tokens": int } }
    """
    secrets = _get_secrets()
    body = json.loads(event.get("body") or "{}")

    tool_name = body.get("tool")
    tool_input = body.get("input", {})

    if not tool_name:
        return {"statusCode": 400, "body": json.dumps({"error": "Champ 'tool' manquant"})}

    logger.info("Appel outil MCP", extra={"tool": tool_name, "input_keys": list(tool_input.keys())})

    try:
        result, usage = _dispatch_tool(tool_name, tool_input, secrets)
    except ValueError as exc:
        logger.warning("Outil inconnu", extra={"tool": tool_name})
        return {"statusCode": 400, "body": json.dumps({"error": str(exc)})}
    except Exception as exc:
        logger.exception("Echec execution outil")
        return {"statusCode": 502, "body": json.dumps({"error": "Erreur upstream", "detail": str(exc)})}

    return {
        "statusCode": 200,
        "headers": {"Content-Type": "application/json"},
        "body": json.dumps({"result": result, "usage": usage}),
    }

@tracer.capture_method
def _dispatch_tool(tool_name: str, tool_input: dict, secrets: dict):
    """Route les appels d'outils MCP vers leurs implementations."""
    if tool_name == "resumer":
        return _call_llm(
            system="Vous etes un specialiste de la synthese. Retournez un resume de 3 phrases.",
            user=tool_input.get("texte", ""),
            secrets=secrets,
        )
    elif tool_name == "classifier":
        return _call_llm(
            system=f"Classifiez l'entree dans une de ces categories : {tool_input.get('categories', [])}. Retournez uniquement le nom de la categorie.",
            user=tool_input.get("texte", ""),
            secrets=secrets,
        )
    else:
        raise ValueError(f"Outil inconnu : {tool_name!r}")

def _call_llm(system: str, user: str, secrets: dict) -> tuple[str, dict]:
    """Appelle le proxy LiteLLM avec le modele Claude."""
    url = f"{secrets['LITELLM_PROXY_URL']}/chat/completions"
    headers = {
        "Authorization": f"Bearer {secrets['LITELLM_API_KEY']}",
        "Content-Type": "application/json",
    }
    payload = {
        "model": "claude-sonnet-4-5",   # LiteLLM mappe vers Anthropic
        "messages": [
            {"role": "system", "content": system},
            {"role": "user", "content": user},
        ],
        "max_tokens": 1024,
    }
    # httpx avec timeout explicite — ne jamais bloquer le Lambda indefiniment
    with httpx.Client(timeout=25.0) as client:
        resp = client.post(url, headers=headers, json=payload)
        resp.raise_for_status()
        data = resp.json()

    content = data["choices"][0]["message"]["content"]
    usage = data.get("usage", {})
    return content, {
        "input_tokens": usage.get("prompt_tokens", 0),
        "output_tokens": usage.get("completion_tokens", 0),
    }

3. Optimisation du cold-start

La latence de cold-start d'un Lambda MCP Python est typiquement de 800 ms a 1,4 s. Trois techniques permettent de la reduire sous 300 ms pour les invocations chaudes et de l'eliminer entierement pour les chemins critiques en latence.

Technique A — Lambda Layers pour les dependances

Packager mcp, httpx, boto3 etaws-lambda-powertools dans un Lambda Layer separe signifie que votre ZIP de deploiement ne contient que le code du handler (~10 Ko). Le temps d'initialisation Lambda est proportionnel a la taille du package ; les bundles legers s'initialisent plus vite.

# build-layer.sh — execute en CI avant terraform apply
pip install   mcp==1.8.0   httpx==0.27.0   aws-lambda-powertools==2.40.0   -t python/

zip -r mcp-deps-layer.zip python/

aws lambda publish-layer-version   --layer-name mcp-deps   --zip-file fileb://mcp-deps-layer.zip   --compatible-runtimes python3.12   --compatible-architectures arm64

# Referencez le LayerVersionArn retourne dans Terraform :
# resource "aws_lambda_layer_version" "mcp_deps" { ... }

Technique B — Provisioned Concurrency pour les APIs synchrones

Le Provisioned Concurrency maintient N instances de votre Lambda pre-initialisees. Le cold-start devient nul. Cout : ~0,015 USD/heure par instance provisionnee. Pour une equipe de 10 developpeurs avec un usage en rafale, 2 instances provisionnees coutent 21,60 USD/mois et eliminent toutes les plaintes de cold-start.

# Ajouter dans terraform/main.tf
resource "aws_lambda_provisioned_concurrency_config" "mcp_server" {
  function_name              = aws_lambda_function.mcp_server.function_name
  qualifier                  = aws_lambda_alias.prod.name
  provisioned_concurrent_executions = 2   # ajuster selon votre concurrence P95
}

resource "aws_lambda_alias" "prod" {
  name             = "prod"
  function_name    = aws_lambda_function.mcp_server.function_name
  function_version = aws_lambda_function.mcp_server.version
}

# Estimation de cout : 2 × 0,015 $/h × 730 h/mois = 21,90 $/mois
# Point de rentabilite : si le cold-start cause >4 tentatives/jour
# coutant plus de 21,90 $ en temps de developpeur

Technique C — Charges asynchrones via SQS (cold-start irrelevant)

Si vos appels MCP sont declenches par des workflows n8n en batch, routez-les via SQS. Lambda traite la file a son rythme — le cold-start ajoute au maximum quelques centaines de millisecondes a un job qui etait deja asynchrone. Aucun Provisioned Concurrency necessaire.

4. Integration LiteLLM + Claude

LiteLLM s'intercale entre votre Lambda et l'API Anthropic. Il fournit un endpoint unique compatible OpenAI, le routing de modeles, les fallbacks, les limites de budget et la journalisation d'usage — sans modifier une seule ligne de code du serveur MCP quand vous changez de modele.

# litellm-config.yaml — deployer sur ECS Fargate ou votre propre serveur

model_list:
  - model_name: claude-sonnet-4-5      # alias utilise par votre Lambda
    litellm_params:
      model: anthropic/claude-sonnet-4-5
      api_key: os.environ/ANTHROPIC_API_KEY
      max_retries: 3

  - model_name: claude-haiku-4-5       # alias moins cher pour les taches simples
    litellm_params:
      model: anthropic/claude-haiku-4-5-20251001
      api_key: os.environ/ANTHROPIC_API_KEY

  - model_name: gpt-4o-mini            # fallback si Anthropic est indisponible
    litellm_params:
      model: openai/gpt-4o-mini
      api_key: os.environ/OPENAI_API_KEY

router_settings:
  # Si claude-sonnet-4-5 echoue, essayer claude-haiku-4-5, puis gpt-4o-mini
  fallbacks:
    - { claude-sonnet-4-5: [claude-haiku-4-5, gpt-4o-mini] }

  # Retry sur les rate limits avec backoff exponentiel
  num_retries: 3
  retry_after: 5

litellm_settings:
  # Garde-fous budgetaires : stopper avant les mauvaises surprises
  max_budget: 50           # plafond dur en USD par mois
  budget_duration: "1mo"

  # Journalisation structuree des requetes/reponses
  success_callback: ["langfuse"]
  failure_callback: ["langfuse"]

  # Limite de tokens par appel
  max_tokens: 4096

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY   # proteger l'endpoint du proxy

Changer de modele sans modifier le code

Une fois LiteLLM en place, migrer de Claude Sonnet vers Claude Haiku (ou Opus, ou un modele Ollama local) est un changement d'une ligne de config et un redeploi du conteneur — aucun changement de code Lambda, aucun redeploi du serveur MCP.

# Pour migrer l'outil 'classifier' vers le modele Haiku moins cher,
# mettre a jour litellm-config.yaml et redeployer uniquement le conteneur LiteLLM.
# Le code du handler Lambda reste identique.

# Avant :
model_name: claude-sonnet-4-5   # 3 $/15 $ par million de tokens entree/sortie

# Apres :
model_name: claude-haiku-4-5    # 0,25 $/1,25 $ par million de tokens entree/sortie
# Reduction de cout de 92 % pour les taches de classification — aucun redeploi Lambda

5. Monitoring CloudWatch et X-Ray

Lambda Powertools ajoute automatiquement des logs JSON structures et des sous-segments X-Ray a chaque invocation. Le snippet CloudFormation ci-dessous cree le dashboard essentiel et les alarmes.

# cloudformation-monitoring.yml

AWSTemplateFormatVersion: "2010-09-09"
Description: Stack d'observabilite du serveur MCP

Parameters:
  LambdaFunctionName:
    Type: String
    Default: mcp-server
  AlertEmail:
    Type: String

Resources:
  # ── Topic SNS pour les alertes ────────────────────────────────────
  AlertTopic:
    Type: AWS::SNS::Topic
    Properties:
      TopicName: mcp-server-alerts
      Subscription:
        - Protocol: email
          Endpoint: !Ref AlertEmail

  # ── Alarme taux d'erreur (>2% declenche une alerte) ───────────────
  ErrorRateAlarm:
    Type: AWS::CloudWatch::Alarm
    Properties:
      AlarmName: mcp-server-error-rate-high
      AlarmDescription: Taux d'erreur du serveur MCP depasse 2%
      ComparisonOperator: GreaterThanThreshold
      Threshold: 2
      EvaluationPeriods: 3
      DatapointsToAlarm: 2
      Metrics:
        - Id: errors
          MetricStat:
            Metric:
              Namespace: AWS/Lambda
              MetricName: Errors
              Dimensions:
                - Name: FunctionName
                  Value: !Ref LambdaFunctionName
            Period: 60
            Stat: Sum
        - Id: invocations
          MetricStat:
            Metric:
              Namespace: AWS/Lambda
              MetricName: Invocations
              Dimensions:
                - Name: FunctionName
                  Value: !Ref LambdaFunctionName
            Period: 60
            Stat: Sum
        - Id: errorRate
          Expression: "(errors / invocations) * 100"
          Label: TauxErreur
          ReturnData: true
      AlarmActions:
        - !Ref AlertTopic
      TreatMissingData: notBreaching

  # ── Alarme latence P99 (>5s est inacceptable) ─────────────────────
  P99LatencyAlarm:
    Type: AWS::CloudWatch::Alarm
    Properties:
      AlarmName: mcp-server-p99-latency-high
      AlarmDescription: Latence P99 du serveur MCP depasse 5 secondes
      Namespace: AWS/Lambda
      MetricName: Duration
      Dimensions:
        - Name: FunctionName
          Value: !Ref LambdaFunctionName
      ExtendedStatistic: p99
      ComparisonOperator: GreaterThanThreshold
      Threshold: 5000  # ms
      Period: 300
      EvaluationPeriods: 2
      AlarmActions:
        - !Ref AlertTopic

  # ── Dashboard CloudWatch ──────────────────────────────────────────
  MCPDashboard:
    Type: AWS::CloudWatch::Dashboard
    Properties:
      DashboardName: mcp-server-production
      DashboardBody: !Sub |
        {
          "widgets": [
            {
              "type": "metric",
              "properties": {
                "title": "Invocations et Erreurs",
                "metrics": [
                  ["AWS/Lambda", "Invocations", "FunctionName", "${LambdaFunctionName}"],
                  ["AWS/Lambda", "Errors",      "FunctionName", "${LambdaFunctionName}"]
                ],
                "period": 60,
                "stat": "Sum",
                "view": "timeSeries"
              }
            },
            {
              "type": "metric",
              "properties": {
                "title": "Duree P50 / P99",
                "metrics": [
                  ["AWS/Lambda", "Duration", "FunctionName", "${LambdaFunctionName}", { "stat": "p50" }],
                  ["AWS/Lambda", "Duration", "FunctionName", "${LambdaFunctionName}", { "stat": "p99" }]
                ],
                "period": 60,
                "view": "timeSeries"
              }
            },
            {
              "type": "metric",
              "properties": {
                "title": "Cold Starts (Init Duration)",
                "metrics": [
                  ["AWS/Lambda", "InitDuration", "FunctionName", "${LambdaFunctionName}"]
                ],
                "period": 300,
                "stat": "Average",
                "view": "timeSeries"
              }
            }
          ]
        }

Metriques personnalisees pour les couts de tokens LLM

Lambda Powertools permet d'emettre des metriques CloudWatch personnalisees directement depuis le handler — y compris les comptages de tokens issus des reponses LiteLLM.

# Ajouter dans handler.py
from aws_lambda_powertools import Metrics
from aws_lambda_powertools.metrics import MetricUnit

metrics = Metrics(namespace="MCPServer")

@metrics.log_metrics
def lambda_handler(event, context):
    # ... code du handler existant ...
    result, usage = _dispatch_tool(tool_name, tool_input, secrets)

    # Emettre l'usage de tokens comme metriques CloudWatch personnalisees
    metrics.add_metric(name="InputTokens",  unit=MetricUnit.Count, value=usage["input_tokens"])
    metrics.add_metric(name="OutputTokens", unit=MetricUnit.Count, value=usage["output_tokens"])
    metrics.add_metric(
        name="CoutEstimeUSD",
        unit=MetricUnit.Count,
        # Claude Sonnet : 3 $/M tokens entree + 15 $/M tokens sortie
        value=(usage["input_tokens"] * 3 + usage["output_tokens"] * 15) / 1_000_000
    )

    return { ... }

# Resultat : CloudWatch affiche le cout reel par invocation.
# Creer une alarme de budget sur CoutEstimeUSD pour detecter les prompts incontroles.

6. Orchestration n8n pour le scaling declencheur

n8n connecte des declencheurs externes (webhooks, planifications, messages Slack, insertions en base de donnees) a votre Lambda serveur MCP. L'editeur de workflows visuel permet aux non-developpeurs d'ajouter de nouveaux chemins d'automatisation sans toucher au code Lambda.

Exemple : Workflow de resume de documents nocturne

# Workflow n8n — export JSON (importer via Parametres > Workflows > Importer)
# Declencheur : chaque jour a 02:00 UTC
# Action : recuperer les nouveaux documents depuis S3, appeler MCP /resumer, stocker les resultats

{
  "name": "MCP Resume de Documents Nocturne",
  "nodes": [
    {
      "name": "Declencheur Planifie",
      "type": "n8n-nodes-base.scheduleTrigger",
      "parameters": {
        "rule": { "interval": [{ "field": "cronExpression", "expression": "0 2 * * *" }] }
      }
    },
    {
      "name": "Lister Nouveaux Documents S3",
      "type": "n8n-nodes-base.s3",
      "parameters": {
        "operation": "getAll",
        "bucketName": "mon-bucket-docs",
        "prefix": "entrants/",
        "additionalFields": { "maxKeys": 50 }
      }
    },
    {
      "name": "Appeler MCP Resumer",
      "type": "n8n-nodes-base.httpRequest",
      "parameters": {
        "method": "POST",
        "url": "https://api.exemple.com/prod/mcp",
        "authentication": "headerAuth",
        "headerParameters": {
          "parameters": [{ "name": "x-api-key", "value": "={{ $env.MCP_API_KEY }}" }]
        },
        "body": {
          "mode": "json",
          "jsonBody": "={{ JSON.stringify({ tool: 'resumer', input: { texte: $item.content } }) }}"
        }
      }
    },
    {
      "name": "Stocker Resume dans DynamoDB",
      "type": "n8n-nodes-base.awsDynamoDB",
      "parameters": {
        "operation": "upsert",
        "table": "resumes-documents",
        "dataToSend": "defineBelow",
        "fieldsToSend": {
          "values": [
            { "key": "doc_id",    "value": "={{ $node['Lister Nouveaux Documents S3'].json.Key }}" },
            { "key": "resume",    "value": "={{ $node['Appeler MCP Resumer'].json.result }}" },
            { "key": "traite_le", "value": "={{ $now.toISO() }}" }
          ]
        }
      }
    }
  ]
}

Auto-scaling avec n8n + SQS

Pour les charges en rafale, routez les requetes HTTP de n8n via une file SQS plutot que d'appeler Lambda directement. Lambda lit la file avec une taille de batch et une limite de concurrence configurables — vous obtenez une contre-pression naturelle sans ecrire une seule ligne de code de scaling.

# terraform/sqs-trigger.tf

resource "aws_sqs_queue" "mcp_jobs" {
  name                       = "mcp-jobs"
  visibility_timeout_seconds = 35   # > timeout Lambda (30s)
  message_retention_seconds  = 3600
  receive_wait_time_seconds  = 20   # long polling — reduit les receives vides
}

resource "aws_lambda_event_source_mapping" "sqs_vers_lambda" {
  event_source_arn = aws_sqs_queue.mcp_jobs.arn
  function_name    = aws_lambda_function.mcp_server.arn
  batch_size       = 5       # traiter 5 messages par invocation Lambda
  maximum_batching_window_in_seconds = 10

  # Si Lambda echoue, reessayer 2 fois puis envoyer en dead-letter queue
  function_response_types = ["ReportBatchItemFailures"]
}

resource "aws_sqs_queue" "mcp_dlq" {
  name = "mcp-jobs-dlq"
  message_retention_seconds = 86400  # conserver les jobs echoues 24h pour inspection
}

resource "aws_sqs_queue_redrive_policy" "mcp" {
  queue_url = aws_sqs_queue.mcp_jobs.id
  redrive_policy = jsonencode({
    deadLetterTargetArn = aws_sqs_queue.mcp_dlq.arn
    maxReceiveCount     = 3
  })
}

7. Benchmarks de cout par requete

Ces chiffres proviennent d'un serveur MCP en production faisant du resume de documents pour une base de connaissances interne — 50 utilisateurs, ~400 requetes par jour, longueur moyenne de document de 2 000 mots.

Composant de cout	Mensuel (12 000 requetes)	Par requete	Notes
Calcul Lambda (arm64, 512 Mo, 8s moy.)	0,22 $	0,000018 $	~3M GB-secondes/mois
API Gateway HTTP API	0,012 $	0,000001 $	1 $ par million de requetes
CloudWatch Logs (5 Go/mois)	2,50 $	0,000208 $	0,50 $/Go d'ingestion
Traces X-Ray (taux 5%)	0,05 $	0,000004 $	5 $ par million de traces ; 600 echantillonnees
Secrets Manager (1 secret)	0,40 $	0,000033 $	0,40 $/secret/mois + 0,05 $/10K appels API
Total Infrastructure AWS	3,18 $	0,000265 $	~0,27 $ pour 1 000 requetes
Claude Sonnet 4.5 (moy. 800 entree / 400 sortie tokens)	3,60 $	0,000300 $	3 $/15 $ par million de tokens entree/sortie
Total LLM inclus	6,78 $	0,000565 $	0,57 $ pour 1 000 requetes

Optimisations de cout rapides :

Basculer les taches de classification vers Claude Haiku : 0,25 $/1,25 $ par million de tokens → reduction de 92% du cout LLM pour les outils simples
Fixer le taux d'echantillonnage X-Ray a 5% (comme indique) au lieu de 100% — valeur de debug identique, 95% moins cher
Utiliser CloudWatch Log Insights plutot que de streamer tous les logs vers un SIEM — economise 2-8 $/mois sur le volume de logs
Activer Lambda Response Streaming pour reduire la latence percue sans le cout du Provisioned Concurrency

Comparaison de scenarios : Haiku vs Sonnet pour les charges mixtes

# Comparaison de cout : strategie de routing pour 12 000 requetes/mois
# 60% classification (simple) + 40% resume (complexe)

# Strategie A : Tout Sonnet
classification (7 200 × 0,0003 $) = 2,16 $
resume         (4 800 × 0,0003 $) = 1,44 $
Total LLM : 3,60 $/mois

# Strategie B : Haiku pour classifier, Sonnet pour resumer
classification (7 200 × 0,000025 $) = 0,18 $   # 92% moins cher
resume         (4 800 × 0,0003 $)   = 1,44 $
Total LLM : 1,62 $/mois ← reduction de 55%

# Implementation dans la config LiteLLM :
# Ajouter model_name: "modele-classification" pointant vers claude-haiku-4-5
# Lambda passe l'indication de modele dans le corps de la requete :
# payload["model"] = "modele-classification"  # pour l'outil classifier
# payload["model"] = "claude-sonnet-4-5"      # pour l'outil resumer

Questions frequentes

Quel est le setup AWS minimal pour faire tourner un serveur MCP en production ?

Le minimum viable comprend : une fonction AWS Lambda (arm64, 512 Mo RAM), un endpoint API Gateway HTTP API, un role IAM d'execution au moindre privilege, et CloudWatch Logs. Ce setup de base gere environ 500 requetes par jour pour environ 0,0012 USD par 1 000 requetes (hors couts LLM). Ajoutez X-Ray et une allocation Provisioned Concurrency si la latence cold-start est critique pour votre metier.

Quel est le cout reel pour un serveur MCP traitant 10 000 requetes par mois ?

D'apres nos benchmarks en production : Lambda compute ~0,22 USD, API Gateway ~0,012 USD, CloudWatch Logs ~0,05 USD, traces X-Ray ~0,05 USD — infrastructure totale ~0,31 USD par mois. Le cout dominant est le LLM : Claude Sonnet a 3$/15$ par million de tokens (entree/sortie) ajoute environ 3,60 USD selon la longueur moyenne des reponses. Total realiste : 4 a 25 USD par mois pour 10 000 requetes.

Le cold-start de Lambda rend-il les serveurs MCP inutilisables pour les applications temps reel ?

Le cold-start est un vrai sujet pour les requetes synchrones face a l'utilisateur. Notre cold-start mesure sur un Lambda Python 3.12 avec le MCP SDK est de 800 ms a 1,4 s. Trois solutions efficaces en pratique : (1) Provisioned Concurrency elimine le cold-start pour un cout fixe (~0,015 USD/heure par instance), (2) garder le bundle Lambda sous 10 Mo via des Lambda Layers reduit le temps d'initialisation de ~40 %, (3) pour les workflows asynchrones declenches par n8n ou SQS, le cold-start est sans importance.

Peut-on utiliser LiteLLM pour changer de modele sans modifier le code du serveur MCP ?

Oui, c'est exactement le cas d'usage pour lequel LiteLLM a ete concu. Votre serveur MCP appelle l'endpoint compatible OpenAI de LiteLLM. LiteLLM route vers Claude, GPT-4o, Gemini, ou un modele Ollama local selon sa configuration. Vous ne mettez a jour que la config LiteLLM (regles de routing, fallbacks, limites de budget) — zero changement de code dans le serveur MCP.

Quelles permissions IAM un Lambda MCP necessite-t-il reellement ?

Appliquer le moindre privilege : le role d'execution a besoin de logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents pour CloudWatch ; xray:PutTraceSegments, xray:PutTelemetryRecords pour X-Ray ; et secretsmanager:GetSecretValue cible sur l'ARN exact du secret contenant vos cles API. Si le Lambda doit appeler d'autres services AWS (S3, DynamoDB), ajoutez-les specifiquement. N'utilisez jamais AWSLambdaFullAccess ou AdministratorAccess sur une fonction de production.

Aller plus loin avec Talki Academy

Ce guide couvre la couche infrastructure. Si vous devez construire et concevoir le serveur MCP lui-meme — schemas d'outils, gestion du contexte, chaining multi-outils — notre formation Agents IA couvre MCP de bout en bout avec des labs pratiques. Pour les equipes qui deploient Claude a l'echelle, la formation Claude API couvre le prompt engineering, le controle des couts et les strategies de rate-limit en profondeur. Financement OPCO disponible pour les entreprises europeennes.

Serveurs MCP en Production : Guide Complet de Deploiement AWS (2026)