AWS MCP : connecter vos outils IA à AWS sans exposer vos accès

AWS MCP en 30 secondes

AWS MCP est intéressant pour une équipe DevOps parce qu’il rapproche l’agent IA du plan de contrôle AWS. L’agent ne répond plus seulement depuis sa mémoire : il peut consulter des références fraîches et proposer des appels cohérents.

Le risque est évident : si un agent peut appeler AWS, il peut aussi faire des dégâts. La question utile n’est donc pas « peut-on brancher MCP ? », mais « avec quel périmètre, quelle traçabilité et quelle procédure de validation ? ».

Ce qu’est AWS MCP, concrètement

Le Model Context Protocol est un standard client-serveur. Un client compatible, comme Cursor, Claude Code, Codex, Kiro ou un agent interne, se connecte à un serveur MCP qui expose des outils.

Côté AWS, il existe plusieurs familles. AWS Knowledge MCP donne accès à la documentation, aux API references, aux régions et aux bonnes pratiques. AWS API MCP Server permet d’interagir avec les services AWS via des commandes ou appels structurés.

AWS a aussi introduit un AWS MCP Server managé dans Agent Toolkit for AWS. Celui-ci regroupe documentation, API tools, skills, métriques CloudWatch et contrôles IAM dans une approche plus intégrée.

Pour une équipe infra, la bonne lecture est simple. AWS MCP n’est pas un nouveau mode magique d’administration cloud. C’est une interface d’orchestration pour agents, posée au-dessus d’API AWS déjà gouvernées.

AWS MCP et API AWS : qui fait vraiment quoi ?

L’API AWS reste le plan de contrôle. Quand une ressource est listée, créée ou modifiée, l’action finit par passer par une opération AWS signée et autorisée.

AWS MCP aide surtout l’agent à choisir la bonne opération, formater les paramètres, lire la documentation et interpréter les erreurs. Il réduit la friction, mais il ne remplace ni l’architecture ni la revue humaine.

Couche	Rôle	Point de contrôle
Agent IA	Interprète la demande et choisit un outil.	Prompt, règles projet, validation humaine.
Serveur MCP	Expose documentation, tools et exécution encadrée.	Configuration, transport, auth, allowlist.
API AWS	Applique les actions sur les ressources.	IAM, SCP, quotas, CloudTrail.

Cette séparation est importante en incident. Si un agent crée une ressource trop large ou supprime un composant, l’analyse doit retrouver l’utilisateur, le rôle IAM, l’appel API et le contexte MCP.

Pour un exemple AWS plus classique côté infrastructure, tu peux aussi lire le guide sur Route 53, DNS hybride et Terraform. Il complète bien la logique API/IaC.

Les limites d’AWS MCP à intégrer dès le départ

La première limite est celle des permissions. Un agent ne doit jamais utiliser un profil administrateur permanent. Même si l’outil semble pratique, le blast radius doit rester volontairement faible.

La deuxième limite est celle des quotas AWS. MCP ne supprime pas le throttling, les limites régionales, les quotas par service ou les erreurs de concurrence. Il peut même les atteindre plus vite si un agent boucle.

La troisième limite concerne les clients MCP. Tous ne supportent pas les mêmes transports, surtout pour les serveurs distants en HTTP streamable. Certains workflows nécessitent encore un proxy ou une configuration spécifique.

La quatrième limite est fonctionnelle. Un agent peut générer un appel syntaxiquement correct mais stratégiquement mauvais. Créer un bucket public, ouvrir un security group ou choisir un service inadapté restent des risques métiers.

Installer AWS API MCP Server dans Claude Code, Codex et OpenCode

Le serveur AWS API MCP open source se lance généralement en local via uvx. Le profil AWS doit être explicite, temporaire si possible, et limité au périmètre du test.

Avant de le brancher à un agent, prépare un profil AWS dédié. Évite le profil personnel et commence avec une politique read-only ou un compte sandbox.

Claude Code

Claude Code fournit une commande claude mcp add. Pour un serveur local stdio, les options Claude précèdent le séparateur --, puis vient la commande qui démarre le serveur.

claude mcp add --transport stdio aws-api   --env AWS_REGION=eu-west-3   --env AWS_API_MCP_PROFILE_NAME=sandbox-readonly   -- uvx awslabs.aws-api-mcp-server@latest

# Vérification dans Claude Code
/mcp

Le point important côté Claude Code est la validation. Garde les actions sensibles hors auto-approval et utilise /mcp pour vérifier l’état du serveur avant une opération AWS.

Codex CLI / IDE

Codex partage la configuration MCP entre CLI et extension IDE via ~/.codex/config.toml, ou .codex/config.toml dans un projet de confiance.

[mcp_servers.aws_api]
command = "uvx"
args = ["awslabs.aws-api-mcp-server@latest"]
startup_timeout_sec = 20
tool_timeout_sec = 60
default_tools_approval_mode = "prompt"
enabled = true

[mcp_servers.aws_api.env]
AWS_REGION = "eu-west-3"
AWS_API_MCP_PROFILE_NAME = "sandbox-readonly"
READ_OPERATIONS_ONLY = "true"

Pour un ajout rapide en CLI, Codex accepte aussi codex mcp add. Le format est pratique en local, mais le fichier TOML reste meilleur pour versionner une procédure d’équipe.

codex mcp add aws-api   --env AWS_REGION=eu-west-3   --env AWS_API_MCP_PROFILE_NAME=sandbox-readonly   --env READ_OPERATIONS_ONLY=true   -- uvx awslabs.aws-api-mcp-server@latest

# Dans la TUI Codex
/mcp

OpenCode

OpenCode déclare les serveurs MCP dans opencode.json ou opencode.jsonc, sous la clé mcp. Le type local lance une commande locale.

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "aws_api": {
      "type": "local",
      "command": ["uvx", "awslabs.aws-api-mcp-server@latest"],
      "enabled": true,
      "timeout": 20000,
      "environment": {
        "AWS_REGION": "eu-west-3",
        "AWS_API_MCP_PROFILE_NAME": "sandbox-readonly",
        "READ_OPERATIONS_ONLY": "true"
      }
    }
  }
}

OpenCode charge ensuite les outils MCP à côté de ses outils internes. Si plusieurs MCP sont actifs, limite-les par agent ou désactive les outils inutiles pour éviter de gonfler le contexte.

Mode HTTP local : à réserver aux cas maîtrisés

Le serveur AWS API MCP supporte aussi un transport HTTP streamable. En local, limite l’écoute à 127.0.0.1 et active OAuth si l’outil le permet.

AWS_API_MCP_TRANSPORT=streamable-http AUTH_TYPE=oauth AWS_API_MCP_HOST=127.0.0.1 AWS_API_MCP_PORT=8000 uvx awslabs.aws-api-mcp-server@latest

Ne transforme pas ce mode en service partagé improvisé. La documentation AWS précise que le mode HTTP self-host est pensé pour un usage single-customer.

IAM, CloudTrail et garde-fous indispensables

Le modèle propre consiste à créer un rôle dédié à l’agent. Ce rôle doit avoir une durée courte, des permissions minimales et des conditions explicites sur les services ou environnements autorisés.

Avec l’AWS MCP Server managé, AWS indique que des clés de contexte globales permettent de différencier les actions initiées via le service MCP. C’est précieux pour écrire des politiques et filtrer l’audit.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadOnlyDiscovery",
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "rds:Describe*",
        "cloudwatch:GetMetricData",
        "cloudwatch:DescribeAlarms",
        "logs:DescribeLogGroups"
      ],
      "Resource": "*"
    }
  ]
}

Ce type de politique ne suffit pas à tout, mais il donne une base saine pour découvrir l’environnement. Les actions comme Delete*, PutBucketPolicy ou AuthorizeSecurityGroupIngress doivent passer par une étape séparée.

CloudTrail doit être activé et exploitable. L’objectif n’est pas seulement d’avoir des logs, mais de pouvoir répondre vite : quel agent, quel rôle, quelle API, quelle ressource, quel résultat ?

Mini-lab AWS MCP en 20 minutes, sans risque

Pour tester AWS MCP sans exposer un compte de production, pars d’un périmètre volontairement limité : un profil AWS dédié, une région précise et des droits en lecture seule. L’objectif du premier test n’est pas d’automatiser AWS, mais de vérifier que l’agent comprend l’environnement, propose des actions cohérentes et laisse des traces exploitables.

Policy IAM minimale pour démarrer

Cette policy sert de point de départ pour un test d’inventaire. Elle autorise uniquement la lecture sur quelques services courants. Elle ne permet pas de créer, modifier ou supprimer des ressources.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadOnlyInventoryForMcpLab",
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "s3:ListAllMyBuckets",
        "s3:GetBucketLocation",
        "s3:GetBucketEncryption",
        "s3:GetBucketPublicAccessBlock",
        "iam:GetAccountSummary",
        "iam:ListRoles",
        "iam:ListPolicies",
        "cloudtrail:DescribeTrails",
        "cloudtrail:GetTrailStatus",
        "cloudwatch:DescribeAlarms",
        "tag:GetResources"
      ],
      "Resource": "*"
    }
  ]
}

Checklist de test

1. Créer le rôle ou l’utilisateur IAM dédié avec la policy read-only ci-dessus.
2. Configurer le profil local : aws configure --profile sandbox-readonly.
3. Vérifier manuellement : aws ec2 describe-instances --profile sandbox-readonly --region eu-west-3.
4. Lancer le serveur AWS MCP avec ce profil uniquement.
5. Demander à l’agent de faire un inventaire, sans action corrective.
6. Contrôler CloudTrail pour confirmer quels appels API ont été effectués.

Prompts prêts à copier

Vérifier les traces CloudTrail

Après le test, regarde les événements CloudTrail associés au rôle ou à l’utilisateur de lab. Tu dois retrouver les appels Describe*, List* ou Get* attendus, sans action d’écriture.

aws cloudtrail lookup-events   --lookup-attributes AttributeKey=Username,AttributeValue=sandbox-readonly   --region eu-west-3   --profile sandbox-readonly

Rollback propre du test

• désactiver ou supprimer les clés du profil de test ;
• retirer la policy IAM temporaire ;
• désactiver le serveur MCP dans Claude Code, Codex ou OpenCode ;
• relire CloudTrail une dernière fois pour confirmer l’absence d’action d’écriture.

Checklist production avant d’autoriser AWS MCP

Une fois le lab validé, le passage en production doit rester progressif. L’idée n’est pas de donner “AWS” à un agent, mais de publier un nombre limité d’outils, sur un périmètre connu, avec une procédure de validation.

Dans une PME ou une équipe SaaS, je recommande de commencer avec trois scénarios : inventaire, diagnostic et génération de plan. Les changements automatisés viennent ensuite, quand l’audit et les rollback sont solides.

Cas d’usage raisonnables pour une équipe DevOps

Le meilleur premier cas est l’inventaire. L’agent peut lister des ressources, repérer des écarts évidents et préparer une synthèse lisible pour l’équipe.

Le deuxième cas est le diagnostic guidé. Sur un incident applicatif, il peut consulter métriques CloudWatch, statuts de stacks et logs récents, puis proposer une hypothèse vérifiable.

Le troisième cas est la préparation d’IaC. L’agent peut rechercher la documentation récente, proposer un module CDK, Terraform ou CloudFormation, puis laisser la CI valider le résultat.

Je déconseille de commencer par la remédiation automatique. Fermer un port, modifier une policy ou supprimer une ressource doit rester une action explicite, revue et traçable.

Erreurs courantes avec AWS MCP

Sources officielles utiles

FAQ AWS MCP

Déploiement progressif recommandé

Sur un compte AWS existant, je conseille une approche par paliers. Le premier palier donne seulement accès à la documentation et aux inventaires read-only.

Le deuxième palier autorise des diagnostics limités, avec lecture de métriques, logs et statuts de déploiement. L’agent prépare alors un plan, sans modifier les ressources.

Le troisième palier concerne les changements faibles risques, par exemple ajouter un tag ou générer une pull request IaC. Les modifications directes restent désactivées.

Le dernier palier peut autoriser certaines actions de remédiation. Il nécessite validation explicite, fenêtre de maintenance, rollback connu et alerte CloudTrail exploitable.

Conclusion : AWS MCP est puissant si tu gardes la main

AWS MCP est une avancée utile pour les équipes qui veulent accélérer diagnostic, documentation et opérations cloud avec des agents IA. Le gain réel vient de la combinaison : documentation fraîche, appels API structurés et procédures guidées.

Mais ce gain ne vaut rien sans gouvernance. Les limites AWS, IAM, CloudTrail, quotas et validations humaines restent les fondations. MCP doit rendre l’agent plus fiable, pas plus libre.