On a vu chaque brique isolément : le modèle Bedrock, le RAG hybride, le managé vs code-first, les modèles SageMaker. Reste à les assembler en une architecture qui tient en production : disponible, sécurisée, observable, maîtrisée en coût. Voici le plan de référence DEEP-5 sur AWS.
La requête, de bout en bout
Suivons une requête utilisateur à travers la pile.
Couche 1 — Ingress
Le point d’entrée authentifie, limite le débit et route :
- API Gateway (ou ALB) — terminaison TLS, authentification (Cognito, JWT), throttling et quotas par client. Première ligne contre l’abus et le DoS de coût.
- WAF en amont pour les règles de sécurité applicative.
Couche 2 — Compute : où tourne l’agent
Trois options, par ordre de délégation décroissante :
| Option | Quand | Compromis |
|---|---|---|
| AgentCore Runtime | Agents, sessions longues | Managé, isolé, intégré AWS |
| Lambda | Requêtes courtes, pics | Serverless, mais timeout 15 min |
| ECS Fargate / EKS | Contrôle fin, longues exécutions | Vous opérez les conteneurs |
Couche 3 — L’état durable : le checkpointer
Un agent de production doit survivre aux redéploiements et aux pannes, et porter la mémoire conversationnelle (checkpointing). En mémoire, on perd tout ; sur AWS, on persiste dans DynamoDB — serverless, durable, faible latence.
# Checkpointer DynamoDB (paquet langgraph-checkpoint-aws)
from langgraph_checkpoint_aws.saver import BedrockSessionSaver
# ou un checkpointer DynamoDB dédié selon votre version :
# from langgraph_checkpoint_dynamodb import DynamoDBSaver
checkpointer = BedrockSessionSaver(region_name="eu-west-1")
agent = construire_graphe().compile(checkpointer=checkpointer)
# Le thread_id mappe sur l'identité métier (session, ticket, utilisateur)
agent.invoke(entree, {"configurable": {"thread_id": "session-42"}})
La persistance débloque aussi le human-in-the-loop : l’état gelé attend sur DynamoDB qu’un humain valide, puis l’exécution reprend — même après un redéploiement.
Couche 4 — Les services agentiques
L’agent s’appuie sur les services vus dans les deep-dives précédents :
- Bedrock Converse API — le raisonnement et le tool use (Claude, Nova), avec routage de modèles pour le coût.
- Bedrock Guardrails — filtres, PII, ancrage, attachés à l’inférence.
- OpenSearch Serverless / Knowledge Bases — la récupération hybride.
- AgentCore Memory ou un Store sur DynamoDB/OpenSearch — la mémoire long-terme.
- AgentCore Code Interpreter / Browser — l’exécution d’outils isolée (cf. agent de code).
Couche 5 — Observabilité et évaluation
Deux plans complémentaires, déjà rencontrés :
- LangFuse — l’observabilité agentique (traces, coûts, scores). Auto-hébergeable sur AWS (conteneurs ECS/EKS + RDS PostgreSQL + ClickHouse) pour garder les données chez vous, ou en SaaS.
- CloudWatch + Bedrock model invocation logging — métriques d’infra, logs d’invocation pour l’audit et la facturation.
- Bedrock Evaluations + le dataset LangFuse — la non-régression de qualité.
Couche transverse — Sécurité et réseau
La sécurité du deep-dive dédié, déclinée AWS :
- IAM least privilege — chaque composant a un rôle minimal ; l’agent n’a que les permissions de ses outils. L’identité ne transite jamais par le prompt.
- VPC + PrivateLink — les appels à Bedrock et OpenSearch restent sur le réseau privé AWS, sans passer par Internet.
- KMS — chiffrement au repos de l’état (DynamoDB), des index et des logs.
- Secrets Manager — clés et secrets, injectés à l’exécution, jamais en dur.
- Bedrock Guardrails + garde-fous applicatifs — la défense en profondeur.
Maîtrise des coûts
La gestion des coûts sur AWS repose sur :
- Routage de modèles Bedrock (Nova vs Claude) — le levier n°1.
- Bornage :
recursion_limit, timeouts API Gateway/Lambda, quotas par client. - Endpoints SageMaker auto-scalés / serverless pour éviter les instances oisives.
- Suivi dans LangFuse (coût par requête) et Cost Explorer (par service) — avec alertes de budget.
Déploiement et opérations
- Infrastructure as Code (CDK / Terraform) pour reproductibilité et revue.
- CI/CD avec la non-régression d’évaluation en porte : on ne déploie pas si la qualité chute.
- Blue/green ou canary pour les changements de prompt/modèle, avec rollback.
Bonnes pratiques & pièges
- Persistez l'état dans DynamoDB (checkpointer) : durabilité, HITL, reprise sur panne.
- AgentCore Runtime par défaut pour exécuter l'agent ; ECS/EKS pour les besoins spécifiques.
- API Gateway en façade : auth, throttling et quotas par client contre l'abus de coût.
- PrivateLink + IAM least privilege + KMS : les appels restent privés, les rôles minimaux.
- LangFuse (débogage) + CloudWatch (infra/audit) ; non-régression d'éval en CI.
- Infra as Code + canary/rollback pour les changements de prompt et de modèle.
- Garder l'état en mémoire : tout disparaît au redéploiement, pas de HITL durable.
- Exposer l'agent sans throttling : un client peut faire exploser la facture de tokens.
- Appeler Bedrock par l'Internet public au lieu de PivateLink en environnement régulé.
- Des rôles IAM trop larges « pour que ça marche » : surface d'attaque maximale.
- Déployer un changement de prompt sans non-régression : régression invisible en prod.
- Oublier les endpoints SageMaker oisifs et les budgets d'alerte : dérive de coût silencieuse.
Ce qu’il faut retenir
- L’architecture de référence empile : ingress (API Gateway), compute (AgentCore Runtime), agent LangGraph, services (Bedrock, OpenSearch), état durable (DynamoDB), observabilité (LangFuse + CloudWatch).
- L’état dans DynamoDB est ce qui rend l’agent durable, reprenable et HITL-compatible.
- La sécurité est transverse : IAM minimal, VPC/PrivateLink, KMS, Guardrails.
- Le coût se maîtrise par le routage de modèles, le bornage et le suivi.
- IaC + non-régression en CI font de l’agentique une discipline d’ingénierie.
Vous tenez la stack complète : du concept LangGraph au déploiement AWS de production. Mettez-la en pratique sur les cas pratiques — et adaptez ce plan de référence à votre contexte.