AWS a passé son MCP Server en GA cette semaine — un endpoint managé unique qui expose chaque API AWS à travers Model Context Protocol, plutôt que les implémentations par-service que chaque shop cloud bricolait à la main depuis un an. Preview en novembre 2025 ; GA ajoute l'exécution Python sandboxée pour les tâches multi-step plus couverture complète d'API incluant ops long-running et file uploads. Services mentionnés dans le release : Amazon S3 Vectors, Amazon Aurora DSQL, Amazon Bedrock AgentCore — les trois pièces que les builders AI enterprise tapaient à travers du glue SDK manuel. Compatible avec Claude Code, Kiro, Cursor, et Codex out of the box. Pour qui shippe des agents dans des environnements AWS, ça écrase la surface d'intégration de "un wrapper MCP par service" à "un endpoint MCP, plein control plane IAM."
Le bout techniquement intéressant c'est le bridge d'auth. MCP 2.1 a standardisé sur OAuth 2.1 pour l'authentification ; AWS a standardisé sur IAM + SigV4 il y a des décennies. Les deux ne se parlent pas nativement. AWS a sorti un MCP Proxy for AWS open-source à github.com/aws/agent-toolkit-for-aws qui tourne localement à côté de ton agent et traduit l'authentification IAM en requêtes OAuth-compatible — ton agent pense qu'il tape un MCP server standard, le proxy signe l'appel sous-jacent avec SigV4 et forward. C'est le pattern canonique pour faire entrer MCP dans n'importe quel cloud dont l'auth précède OAuth 2.1, et l'implémentation de référence d'AWS est la première majeure dans la wild. La gouvernance s'attache de la manière standard : policies IAM pour ce que l'agent peut appeler, métriques CloudWatch pour ce qu'il fait, CloudTrail pour le full audit log. Pricing : le serveur est gratuit ; tu paies pour les ressources que les agents consomment réellement, facturé normalement.
Lecture écosystème : c'est le second major release d'infra MCP dans la quinzaine après la preview MCP Tunnels d'Anthropic. Le pattern est consistant — les grandes plateformes convergent sur MCP comme la frontière standard agent-vers-outil, et le travail qui se passe en ce moment c'est de remplir les pièces auth/gouvernance/runtime que le protocole lui-même ne dicte pas. AWS faisant ça avec couverture API full-fleet et IAM comme control plane est un vrai signal : on n'est plus dans le monde "un MCP server par intégration", on est dans le monde "un MCP par cloud." Le corollaire c'est que le même MCP qui laisse ton agent appeler s3:PutObject le laisse aussi appeler iam:PassRole si la policy est lâche. C'est exactement le gap qu'un praticien a flag dans le piece InfoQ : "pas de gateways pour restreindre certaines actions ou opérations" au-delà de la couche IAM. La story du blast-radius c'est ta story IAM.
Lundi matin : si tu roules des agents qui touchent AWS, swap tes wrappers MCP par-service pour le serveur unifié et serre le rôle IAM attaché au credential que ton agent assume. La nouvelle exécution Python sandboxée veut dire que les tâches multi-step (read X, transform, write Y) n'ont plus besoin de glue d'orchestration séparée — ça se passe dans le sandbox du MCP server. Le blocker honnête c'est le gap de restriction gateway : IAM est l'unique gate, donc une policy mal configurée c'est le full failure mode. Tant qu'AWS ne shippe pas des gates d'action plus fines, traite le rôle IAM du MCP server comme tu traiterais un rôle production least-privilege : scope-le exactement aux ARNs et actions que l'agent a besoin, log tout via CloudTrail, alerte sur les patterns anormaux. Le proxy de référence et le toolkit vivent à github.com/aws/agent-toolkit-for-aws.