Présentation du kit d’outils d’agent pour Amazon Web Services
Qu’est-ce que Agent Toolkit pour AWS ?
est un projet open source développé par AWS qui aide les agents de codage d’IA à travailler avec AWS de manière plus fiable. Avec l’ajout récent du serveur MCP récemment publié dans le Toolkit, les agents de codage utilisant le Toolkit peuvent désormais accéder au contexte, aux flux de travail, aux garde-fous et aux outils spécifiques à AWS dont ils ont besoin pour créer, déployer, déboguer et exploiter des systèmes cloud sans s’appuyer uniquement sur des connaissances générales sur les modèles, qui sont souvent obsolètes.
Au lieu de demander à un agent de codage d’improviser de mémoire, la boîte à outils lui donne des instructions organisées et spécifiques à une tâche. Ceux-ci sont regroupés sous forme de compétences, de plugins, de règles et d’une configuration de serveur MCP.
Les compétences sont des packs d’instructions ciblés. Ils guident l’agent dans des tâches AWS spécifiques, telles que la création d’une table Lakehouse S3 Tables, le déploiement d’une application sans serveur, le débogage des délais d’attente Lambda, la connexion d’AWS Glue à une base de données ou l’ajout de mémoire à un agent AgentCore.
Les plugins regroupent les compétences associées. Par exemple, aws-core couvre le développement général d’AWS, aws-agents couvre les flux de travail Bedrock AgentCore et aws-data-analytics couvre les tables S3, Glue, Athena, la découverte de données et le stockage vectoriel.
Les fichiers de règles définissent le comportement AWS par défaut de l’agent. Ils peuvent demander à l’agent de préférer l’infrastructure en tant que code, consulter la documentation AWS en cas de doute et utiliser les outils AWS MCP lorsqu’ils sont disponibles.
L’intégration du serveur AWS MCP fournit aux agents un accès à la documentation AWS en direct, aux API AWS, à l’exécution de scripts en bac à sable et à l’audit via des contrôles natifs AWS.
Le résultat devrait être de meilleurs systèmes, avec plus de résilience.
Pourquoi c’est important
Les agents de codage modernes peuvent écrire des commandes AWS CLI plausibles, Terraform, CDK, des gestionnaires Lambda, des tâches Glue ou des politiques IAM. Souvent, ceux-ci seront corrects et utilisables immédiatement, mais il existe un problème potentiel, et c’est le même problème avec lequel TOUS les agents de codage sont confrontés. Coupure des connaissances.
Lorsque les agents sont formés, ils sont exposés aux dernières informations disponibles à ce moment-là, mais lorsque les modèles sont publiés, ces informations sont généralement obsolètes depuis plusieurs mois. Par exemple, le dernier modèle d’OpenAI au moment de la rédaction est GPT 5.5. Il a été publié vers la fin avril 2026, mais sa date limite de connaissance était le 1er décembre 2025. Et pendant la période intermédiaire, de nouveaux services sont introduits et les systèmes existants, les appels API, la documentation, etc., sont mis à jour.
Le développement du cloud regorge de détails qui peuvent sembler minimes mais qui peuvent briser les systèmes réels. Par exemple, lors de la création d’une table d’analyse avec des tables Amazon S3, un agent générique peut générer une instruction DDL Athena avec une clause LOCATION car ce modèle est courant pour les tables externes. Mais avec S3 Tables, c’est faux : le service gère le stockage des tables. Le modèle correct consiste à garder le SQL propre et à transmettre le catalogue de tables S3 via le contexte d’exécution de requête d’Athena.
L’Agent Toolkit for AWS permet d’éviter ce genre d’erreur. Ses compétences guident l’agent pour :
- Vérifiez ce qui existe déjà avant de créer de nouvelles ressources
- Utilisez les bonnes API AWS
- Évitez les modèles qu’AWS ne prend pas en charge
- Vérifier les hypothèses par rapport à la documentation AWS actuelle
- Produire des politiques IAM plus strictes
- Exécuter des vérifications après avoir apporté des modifications
- Suivez le bon chemin de dépannage lorsque quelque chose se brise
C’est ce qui compte le plus dans le travail AWS, où le plus difficile n’est pas d’écrire du code. Il s’agit d’écrire du code qui correspond au service AWS, au modèle d’autorisations et à l’environnement d’exploitation spécifiques.
Installation de Agent Toolkit dans votre agent de codage
La boîte à outils d’agent est disponible pour la plupart des agents de codage modernes, tels que Claude Code, Cursor, Kiro et VS Code. Des exemples d’instructions d’installation pour chaque agent se trouvent dans le référentiel AWS Toolkit, auquel je ferai un lien à la fin de l’article.
Mon agent de codage préféré à utiliser actuellement est Codex, c’est donc ce que je vais utiliser dans mon exemple. Installez-le d’abord si vous souhaitez suivre.
Pour installer le Toolkit for Codex, tapez ce qui suit dans une fenêtre de terminal,
$ codex plugin marketplace add aws/agent-toolkit-for-awsEnsuite, ouvrez l’application Codex et tapez ce qui suit.
/pluginsEn fonction de ce que vous avez installé précédemment, vous devriez voir quelque chose comme ceci.
AI Agents on AWS
AWS Core
AWS Data Analytics
Browser
Documents
Presentations
SpreadsheetsCela signifie que tous les plug-ins liés à AWS requis sont disponibles pour que votre agent puisse les utiliser. N’oubliez pas que si vous rencontrez des problèmes, demandez simplement à votre agent de codage de les résoudre.
Utilisation de la boîte à outils avec votre agent de codage
C’est la partie la plus facile, car il vous suffit d’indiquer au Codex en anglais ce que vous souhaitez réaliser.
Pour mon exemple, je voulais :
- Créer une table de commandes Iceberg à l’aide des tables Amazon S3
- Ingérer les données de commande à partir d’une source JDBC avec AWS Glue
- Validez et interrogez la table iceberg avec Athena.
Cela peut sembler une demande assez simple, mais lorsque vous la décomposez, elle est beaucoup plus complexe que vous ne le pensez. Pour commencer, je n’ai pas de source de données JDBC existante, j’ai donc également dû demander au Codex de créer d’abord une base de données RDS et de la remplir avec des données factices. Cela seul engendre un tas d’autres exigences, puisque ma table de base de données RDS est privée, j’avais besoin d’un VPC, de groupes de sécurité, d’autorisations IAM, etc.
Vous comprenez, et ce sera un problème bien connu de tous ceux qui liront ceci et utiliseront AWS avec colère. Même un système AWS assez simple nécessite généralement une configuration complexe, car vous devez tenir compte de la sécurité, des autorisations et des permissions.
Mais comme vous le verrez, AWS Toolkit fait tout le gros du travail à notre place.
Remarque : Agent Toolkit for AWS s’exécute dans votre environnement d’agent de codage. Lorsqu’il doit inspecter, créer ou modifier des ressources AWS, il utilise les informations d’identification AWS configurées dans cet environnement. Pour le développement local, cela signifie généralement les informations d’identification AWS CLI, SSO ou variables d’environnement, assurez-vous donc que l’une ou l’autre de ces méthodes est configurée avant de commencer
Pour commencer, j’ai lancé mon application Codex et tapé ce qui suit :
Create an Iceberg orders table using Amazon S3 Tables, ingest order data
from a JDBC source with AWS Glue, and validate the table with Athena.
The first thing to do is set up a private JDBC source for the above with all
required VPC, networking and security infrastructure. Populate the JDBC source
with sample data,then everything elseAprès cela, l’agent… s’y met en quelque sorte. Voici quelques-uns des résultats qu’il a produits pour moi. Je ne les inclurai pas tous, car la liste était assez longue
Worked for 32m 49s
I'll use the AWS Data Analytics skills for the JDBC source, S3 Tables/Iceberg
table creation, ingestion, and Athena validation. I'm first checking the
workspace shape so the implementation matches what's already here.
The existing workspace already has an aws-data-lake directory, so I'm
inspecting it before deciding whether to extend it or create a separate
deployment package. I also need to verify local AWS tooling and credentials
before any real AWS resources can be created.
...
...
...
Implemented files:
orders-private-jdbc-source.yaml: VPC, private Aurora PostgreSQL source,
NAT/S3 endpoint, security groups, Glue connection/job, IAM roles, seed data
custom resource.
glue_orders_jdbc_to_s3tables.py: Glue 5.1 JDBC-to-S3-Tables ingestion script.
deploy-orders-end-to-end.ps1: deploys stack, uploads Glue script, grants
Lake Formation permissions, runs Glue, validates Athena.
README.md: updated runbook and validation results.
Validation completed:
CloudFormation stack: orders-private-jdbc-source
Glue job: orders-lake-jdbc-to-s3tables-orders
Successful Glue run: jr_a5c6e33544a452a107429f0f7613d5522d8f145062fbb40ad77507529a26263c
Target table: s3tablescatalog/mytablebucket.retail.orders
Athena row count: 6
Athena date range: 2026-04-01 to 2026-05-03
Athena sample rows returned ord-1001 through ord-1005
...
...L’ensemble du processus était très complet et a duré un peu plus de 30 minutes du début à la fin.
Mais est-ce que ça a marché ?
Oui, et en voici la preuve.
Formation de nuages
Il s’agit du service qu’AWS utilise pour automatiser la création de toutes les ressources nécessaires à la création d’un système particulier. C’est une source unique de vérité sur ce qui a été réellement fait. Nous pouvons utiliser l’AWS CLI pour vérifier ce que CloudFormation a fait.
aws cloudformation describe-stacks --stack-name orders-private-jdbc-source --region us-east-2 --query "Stacks[0].StackStatus" --output text
# Output
UPDATE_COMPLETENous pouvons également obtenir une liste complète de tous les services et ressources que CloudFormation a créés en notre nom. J’ai montré la commande ci-dessous, mais veuillez noter que j’ai embelli sa sortie pour la rendre plus lisible.
aws cloudformation list-stack-resources --stack-name orders-private-jdbc-source --region us-east-2 --output table
# Modified Output
+------------------------------------------------------+-------------------------------+-----------------+
| Service Deployed | ResourceType | ResourceStatus |
+------------------------------------------------------+-------------------------------+-----------------+
| S3 bucket (artifact/scripts bucket) | AWS::S3::Bucket | CREATE_COMPLETE |
| Security group rule (ingress) | AWS::EC2::SecurityGroupIngress | CREATE_COMPLETE |
| Secrets Manager secret (DB credentials) | AWS::SecretsManager::Secret | CREATE_COMPLETE |
| Security group (database SG) | AWS::EC2::SecurityGroup | CREATE_COMPLETE |
| RDS DB subnet group (Aurora subnets) | AWS::RDS::DBSubnetGroup | CREATE_COMPLETE |
| IAM role (Glue job execution role) | AWS::IAM::Role | UPDATE_COMPLETE |
| Security group (Glue/Spark SG) | AWS::EC2::SecurityGroup | CREATE_COMPLETE |
| Security group rule (egress) | AWS::EC2::SecurityGroupEgress | CREATE_COMPLETE |
| Security group rule (ingress) | AWS::EC2::SecurityGroupIngress | CREATE_COMPLETE |
| Security group rule (egress) | AWS::EC2::SecurityGroupEgress | CREATE_COMPLETE |
| Internet Gateway (VPC IGW) | AWS::EC2::InternetGateway | CREATE_COMPLETE |
| IAM role (Lake Formation / S3 Tables access role) | AWS::IAM::Role | CREATE_COMPLETE |
| Elastic IP (for NAT Gateway) | AWS::EC2::EIP | CREATE_COMPLETE |
| NAT Gateway | AWS::EC2::NatGateway | CREATE_COMPLETE |
| Aurora DB cluster (PostgreSQL) | AWS::RDS::DBCluster | CREATE_COMPLETE |
| Aurora DB instance (writer/instance) | AWS::RDS::DBInstance | CREATE_COMPLETE |
| Glue job (JDBC -> S3 Tables ingestion) | AWS::Glue::Job | CREATE_COMPLETE |
| Glue JDBC connection (to Aurora/Postgres) | AWS::Glue::Connection | CREATE_COMPLETE |
| Route (private default route, typically to NAT) | AWS::EC2::Route | CREATE_COMPLETE |
| Route table (private) | AWS::EC2::RouteTable | CREATE_COMPLETE |
| Subnet (private subnet 1) | AWS::EC2::Subnet | CREATE_COMPLETE |
| Route table association (private subnet 1) | AWS::EC2::SubnetRouteTableAssoc| CREATE_COMPLETE |
| Subnet (private subnet 2) | AWS::EC2::Subnet | CREATE_COMPLETE |
| Route table association (private subnet 2) | AWS::EC2::SubnetRouteTableAssoc| CREATE_COMPLETE |
| Route (public default route, typically to IGW) | AWS::EC2::Route | CREATE_COMPLETE |
| Route table (public) | AWS::EC2::RouteTable | CREATE_COMPLETE |
| Subnet (public subnet 1) | AWS::EC2::Subnet | CREATE_COMPLETE |
| Route table association (public subnet 1) | AWS::EC2::SubnetRouteTableAssoc| CREATE_COMPLETE |
| VPC endpoint (S3 Gateway Endpoint) | AWS::EC2::VPCEndpoint | CREATE_COMPLETE |
| Custom resource (seed orders data step) | Custom::SeedOrdersData | CREATE_COMPLETE |
| Lambda function (seeds sample orders into DB) | AWS::Lambda::Function | CREATE_COMPLETE |
| IAM role (Lambda execution role for seeding) | AWS::IAM::Role | CREATE_COMPLETE |
| VPC | AWS::EC2::VPC | CREATE_COMPLETE |
| VPC gateway attachment (attach IGW to VPC) | AWS::EC2::VPCGatewayAttachment | CREATE_COMPLETE |
+------------------------------------------------------+-------------------------------+-----------------+
Je ne passerai pas en revue TOUS les services qui ont été créés, mais voici une liste des plus importants avec vérification.
VPC et mise en réseau
Un VPC, c’est comme avoir votre propre mini-réseau au sein de l’écosystème AWS. Autour de cela se trouvent des services tels que les adresses CIDR, les tables de routage, les sous-réseaux et les groupes de sécurité, qui contrôlent quelles ressources ont accès au VPC. Voyons ce qui a été créé.
aws ec2 describe-vpcs --region us-east-2 --query "Vpcs[?Tags[?Key=='aws:cloudformation:stack-name' && Value=='orders-private-jdbc-source']].[VpcId,CidrBlock]" --output table
-------------------------------------------
| DescribeVpcs |
+------------------------+----------------+
| vpc-0165f765ce1af50c0 | 10.40.0.0/16 |
+------------------------+----------------+
aws ec2 describe-subnets --region us-east-2 --query "Subnets[?Tags[?Key=='aws:cloudformation:stack-name' && Value=='orders-private-jdbc-source']].[SubnetId,VpcId,CidrBlock,AvailabilityZone,MapPublicIpOnLaunch]" --output table
-----------------------------------------------------------------------------------------------
| DescribeSubnets |
+---------------------------+-------------------------+----------------+-------------+--------+
| subnet-0a9e1bbeeb1e7f53d | vpc-0165f765ce1af50c0 | 10.40.11.0/24 | us-east-2b | False |
| subnet-07dc3d0e99f09cdc4 | vpc-0165f765ce1af50c0 | 10.40.0.0/24 | us-east-2a | True |
| subnet-0c640ae5d30fe00e9 | vpc-0165f765ce1af50c0 | 10.40.10.0/24 | us-east-2a | False |
+---------------------------+-------------------------+----------------+-------------+--------+
aws ec2 describe-security-groups --region us-east-2 --query "SecurityGroups[?Tags[?Key=='aws:cloudformation:stack-name' && Value=='orders-private-jdbc-source']].[GroupId,GroupName,VpcId]" --output table
--------------------------------------------------------------------------------------------------------------------
| DescribeSecurityGroups |
+----------------------+-----------------------------------------------------------------+-------------------------+
| sg-0c56c3639a47dcbdb| orders-private-jdbc-source-DatabaseSecurityGroup-ZS9C0AJXzASB | vpc-0165f765ce1af50c0 |
| sg-0f1c55c20ebbf7acf| orders-private-jdbc-source-GlueSecurityGroup-XvKHWvTsRuap | vpc-0165f765ce1af50c0 |
+----------------------+-----------------------------------------------------------------+-------------------------+
Rôles IAM
La gestion des identités et des accès (IAM) est un élément crucial de la sécurité AWS. Il contrôle qui et quoi a accès à quels services dans AWS.
aws cloudformation list-stack-resources --stack-name orders-private-jdbc-source --region us-east-2 --query "StackResourceSummaries[?ResourceType=='AWS::IAM::Role' || ResourceType=='AWS::IAM::Policy'].[LogicalResourceId,ResourceType,PhysicalResourceId,ResourceStatus]" --output table
# Output
----------------------------------------------------------------------------------------------------------------------------------------
| ListStackResources |
+---------------------------+-----------------+--------------------------------------------------------------------+-------------------+
| GlueJobRole | AWS::IAM::Role | orders-private-jdbc-source-GlueJobRole-7cOVpk9zf1nf | UPDATE_COMPLETE |
| LakeFormationS3TablesRole| AWS::IAM::Role | orders-private-jdbc-sourc-LakeFormationS3TablesRole-4NKeHFJ0VwBh | CREATE_COMPLETE |
| SeedOrdersFunctionRole | AWS::IAM::Role | orders-private-jdbc-source-SeedOrdersFunctionRole-LPniYBvOU4jt | CREATE_COMPLETE |
+---------------------------+-----------------+--------------------------------------------------------------------+-------------------+
Nous pouvons voir que les rôles appropriés ont été créés pour nous permettre de créer une table S3, de remplir notre base de données RDS avec des données à l’aide d’une fonction Lambda et de remplir notre table S3 à partir de la base de données RDS à l’aide d’une tâche Glue.
Base de données RDS
Ceci a été créé comme source de données initiale pour notre table iceberg sur S3. Après la création, la table de base de données a été ensemencée avec des données factices à l’aide d’une fonction Lambda.
La fonction Lambda
Cela a été utilisé pour « amorcer » la base de données RDS avec des données factices pour la propagation vers la table S3. Je ne montrerai pas le code, mais la fonction elle-même comptait environ 70 lignes de Python.
aws cloudformation list-stack-resources --stack-name orders-private-jdbc-source --region us-east-2 --query "StackResourceSummaries[?ResourceType=='AWS::Lambda::Function'].[LogicalResourceId,PhysicalResourceId,ResourceStatus]" --output table
# Output
---------------------------------------------------------------------------------------------------------
| ListStackResources |
+--------------------+--------------------------------------------------------------+-------------------+
| SeedOrdersFunction| orders-private-jdbc-source-SeedOrdersFunction-aDuplePymvWQ | CREATE_COMPLETE |
+--------------------+--------------------------------------------------------------+-------------------+Une table Iceberg sur S3
Notre objectif ultime était de produire une table iceberg sur S3 que nous pourrions utiliser pour stocker, manipuler et analyser des données. La capture d’écran ci-dessous montre les données du tableau, qui reflètent exactement les données sources de la base de données RDS.
Athéna
Il ne sert à rien d’avoir une table S3 avec des données à moins que nous puissions interroger, mettre à jour ou supprimer ces données. C’est exactement ce que le service Athena d’AWS vous permet de faire. Malheureusement, j’ai rencontré un problème en essayant d’utiliser Athena au départ. Lorsque j’ai vérifié la console Athena, je n’ai pas pu voir la nouvelle table S3 dans la liste des bases de données et des tables, je n’ai donc pas pu l’interroger. Cependant, après quelques allers-retours avec le Codex, il a finalement trouvé ceci :
The key mismatch is now clear: database/table permissions are present, but
catalog-level Lake Formation permissions are empty. AWS's Athena S3 Tables
docs say the Athena principal also needs permissions on the S3 Tables catalog
itself. I'm going to grant ALL on xxxxxxxxxxxx:s3tablescatalog/mytablebucket
to the root user, then verify it.Après cela, l’accès s’est bien passé.
aws athena list-data-catalogs --region us-east-2 --output table
# Output
---------------------------------------------------------
| ListDataCatalogs |
+-------------------------------------------------------+
|| DataCatalogsSummary ||
|+-------------------------+-------------------+-------+|
|| CatalogName | Status | Type ||
|+-------------------------+-------------------+-------+|
|| AwsDataCatalog | CREATE_COMPLETE | GLUE ||
|| mytablebucket_s3tables | CREATE_COMPLETE | GLUE ||
|+-------------------------+-------------------+-------+|
Et j’ai pu interroger la table dans la console Athena.
Colle et étincelle
Glue est l’outil ETL d’AWS et a deux objectifs principaux. Il peut cataloguer les sources de données et les rendre disponibles pour d’autres services AWS tels qu’Athena. Glue peut également utiliser Spark ou Pandas pour lire des sources de données (telles que des bases de données RDS) et utiliser toutes les données trouvées pour créer et alimenter des magasins de données sur d’autres services, tels que des tables et des objets S3.
aws glue get-connection --name orders-lake-orders-aurora-postgres --region us-east-2 --output json
# Output
{
"Connection": {
"Name": "orders-lake-orders-aurora-postgres",
"Description": "Private Aurora PostgreSQL orders source for S3 Tables ingestion.",
"ConnectionType": "JDBC",
"ConnectionProperties": {
"JDBC_ENFORCE_SSL": "false",
"JDBC_CONNECTION_URL": "jdbc:postgresql://orders-private-jdbc-source-ordersdbcluster-wxxm5ygu3dig.cluster-chfygkamm03d.us-east-2.rds.amazonaws.com:5432/ordersdb",
"SECRET_ID": "arn:aws:secretsmanager:us-east-2:XXXXXXXXXXXX:secret:DatabaseSecret-AYWd1SzbgdsG-3K7a0X"
},
"PhysicalConnectionRequirements": {
"SubnetId": "subnet-0c640ae5d30fe00e9",
"SecurityGroupIdList": [
"sg-0f1c55c20ebbf7acf"
],
"AvailabilityZone": "us-east-2a"
},
"CreationTime": "2026-05-08T21:27:26.593000+01:00",
"LastUpdatedTime": "2026-05-08T21:27:26.593000+01:00",
"LastUpdatedBy": "user/administrator",
"ConnectionSchemaVersion": 1
}
}Codex a également généré le code Spark dans Glue pour charger les données de la base de données RDS dans Iceberg. Je ne montrerai pas l’intégralité du code, car il fait presque 100 lignes, mais en voici un extrait.
import sys
from datetime import datetime, timezone
import boto3
from awsglue.context import GlueContext
from awsglue.job import Job
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
from pyspark.sql.functions import col, lit, to_date
args = getResolvedOptions(
sys.argv,
[
"JOB_NAME",
"connection_name",
"source_table",
"target_table",
"watermark_bucket",
"watermark_key",
],
)
sc = SparkContext()
...
...
...
row_count = changed_df.count()
print(f"Found {row_count} changed rows")
if row_count > 0:
orders_df = changed_df.select(
col("order_id").cast("string").alias("order_id"),
col("customer_id").cast("string").alias("customer_id"),
to_date(col("order_date")).alias("order_date"),
col("status").cast("string").alias("status"),
col("amount").cast("double").alias("amount"),
col("updated_at").cast("timestamp").alias("updated_at"),
lit(datetime.now(timezone.utc)).cast("timestamp").alias("load_timestamp"),
)
orders_df.writeTo(args["target_table"]).append()
new_watermark = changed_df.agg({"updated_at": "max"}).collect()[0][0]
s3.put_object(
Bucket=args["watermark_bucket"],
Key=args["watermark_key"],
Body=str(new_watermark),
)
print(f"Updated watermark to {new_watermark}")
else:
print("No new rows to ingest")
job.commit()Autres considérations lors de l’utilisation de la boîte à outils AWS
1/ Limiter l’accès de l’agent à certains services AWS.
Le serveur AWS MCP de la boîte à outils utilise vos autorisations IAM par défaut pour créer et accéder aux services AWS. Si vous souhaitez restreindre l’accès à certains services AWS, vous avez plusieurs choix.
a) Deux clés contextuelles de condition globale sont automatiquement ajoutées à toutes les demandes effectuées via le serveur AWS MCP :
- aws : via le service AWSMCP – Défini sur true pour toute demande transitant par un serveur MCP géré par AWS.
- aws:AppeléViaAWSMCP – Contient le principal de service du serveur MCP géré par AWS spécifique (par exemple, aws-mcp.amazonaws.com).
Vous pouvez utiliser ces clés contextuelles dans vos stratégies IAM pour autoriser ou refuser les actions initiées via n’importe quel serveur MCP géré par AWS. Par exemple, disons que vous vouliez refuser au serveur MCP la possibilité de supprimer des compartiments ou des objets S3. Vous pouvez utiliser cette politique,
{
"Effect": "Deny",
"Action": ["s3:DeleteBucket", "s3:DeleteObject"],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:CalledViaAWSMCP": "aws-mcp.amazonaws.com"
}
}
}b) Une autre option consiste à créer un rôle dédié pour la boîte à outils AWS. Attachez les stratégies restreintes que vous souhaitez à ce rôle, puis créez un profil AWS CLI nommé pour celui-ci à l’aide du AWS configurer commande.
Ensuite, avant de démarrer votre agent de codage (par exemple, Codex), définissez le AWS_PROFILE variable d’environnement à votre nouveau nom de profil Codex uniquement.
2/ Observabilité
La surveillance d’AWS Agent Toolkit s’effectue principalement via le serveur AWS MCP, car c’est le composant géré qui reçoit les appels d’outils et exécute les actions AWS. En tant que tels, les deux principaux services AWS utilisés pour la surveillance sont les mêmes que ceux utilisés pour la plupart des autres services AWS : CloudWatch et CloudTrail.
Le serveur AWS MCP publie automatiquement les métriques sur CloudWatch dans l’espace de noms AWS-MCP. Vous pouvez voir :
- Invocation : combien de fois un outil a été appelé
- Succès : appels d’outils réussis
- UserError : erreurs côté client, souvent des actions refusées par IAM ou des paramètres incorrects
- SystemError : échecs côté serveur
- Throttle : requêtes limitées
CloudTrail enregistre les appels d’API AWS réels effectués dans votre compte. C’est ici que vous pouvez vérifier :
- Qui a passé l’appel
- Comment s’appelait l’API ?
- Quand c’est arrivé
- L’adresse IP source
- Le rôle assumé ou le principal IAM
- Si l’action a réussi ou échoué
Conclusion
Si vous êtes un ingénieur de données, un architecte de données ou un spécialiste DevOps, utiliser AWS Toolkit est une véritable aubaine. Grâce aux plug-ins et aux outils qu’il fournit, vous pouvez accéder à tous les services AWS et à plus de 15 000 appels API.
En bref, lorsqu’elle est utilisée avec un agent de codage, la boîte à outils AWS peut :
- Créez des ressources AWS, écrivez du code et déployez des applications. La boîte à outils l’aide à choisir les bons services et à suivre les meilleures pratiques AWS.
- Accédez aux documents AWS, aux API et aux détails du service les plus à jour.
- Pour les tâches complexes telles que les politiques IAM, les pipelines de données ou les applications sans serveur, l’agent suit les flux de travail AWS testés et documentés plutôt que de deviner.
- Votre agent peut vous aider à enquêter sur les échecs de déploiement, les erreurs ou les hausses de coûts à l’aide des journaux AWS, des métriques, de l’état de la pile et des conseils de dépannage.
- Vous pouvez surveiller l’activité des agents, contrôler l’accès avec IAM et définir des garde-fous tels que l’accès en lecture seule ou le blocage d’actions AWS spécifiques.
- Travaillez avec de nombreux agents de codage différents compatibles MCP, notamment Claude Code, Cursor, Codex, Kiro, Windsurf, etc.
Cependant, comme le montre le problème auquel j’ai été confronté avec ma configuration Athena, la boîte à outils, bien que permettant un gain de temps considérable, n’est pas infaillible. Par conséquent, comme pour toutes les sorties agents, vérifiez votre travail avant de mettre quoi que ce soit en production.
Pour plus d’informations sur Agent Toolkit for AWS, consultez le dépôt officiel GitHub.
You may also like
Comment décoder le paramètre de température dans les LLM
