Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Commencez avec Amazon Bedrock Managed Agents (avec OpenAI) sur Runtime AgentCore
Note
Amazon Bedrock Managed Agents (avec OpenAI) est en version préliminaire. Les fonctionnalités et les API peuvent changer avant leur disponibilité générale.
Amazon Bedrock Managed Agents exécute le harnais OpenAI Codex sur. AWS Le harnais fait la boucle entre le modèle et les outils, maintient la session et compacte le contexte au fur et à mesure que la conversation prend de l'ampleur. Lorsque l'agent doit exécuter une commande ou travailler avec des fichiers, Bedrock Managed Agents envoie le travail vers un environnement. C'est vous qui décidez où s'exécute cet environnement.
Vous pouvez exécuter le serveur exécutif du Codex sur votre propre ordinateur pour le développement local. Pour les autres charges de travail, Bedrock Managed Agents invoque un AgentCore Runtime dans votre compte. Le Runtime donne à chaque session sa propre microVM. La session s'exécute sous un rôle d'exécution que vous contrôlez, et le Runtime peut se connecter à votre VPC afin que l'agent puisse accéder à des ressources privées. Les appels du modèle restent dans Bedrock Managed Agents, de sorte que le conteneur exécute uniquement les commandes envoyées par l'agent.
Dans ce didacticiel, vous allez effectuer les tâches suivantes :
-
Créez et déployez le Runtime avec la AgentCore CLI.
-
Démarrez une session avec le SDK OpenAI. L'agent utilise un exemple de compétence dans votre environnement d'exécution.
-
(Facultatif) Ajoutez vos propres compétences.
Les étapes 1 à 4 prennent environ 15 minutes.
Les AWS ressources que vous créez dans ce didacticiel peuvent entraîner des frais sur votre AWS compte. Ces ressources incluent le Runtime, les builds d' AWS CodeBuild images et les appels du modèle Bedrock Managed Agents. Pour en savoir plus, consultez PricingAgentCore
Conditions préalables
-
Node.js 20 ans ou plus tard. La AgentCore CLI est distribuée sous forme de package npm. Vérifiez auprès de
node --version. -
uv. L'exemple de client utilise uv
pour installer ses dépendances Python. -
Un AWS compte avec des informations d'identification configurées. Pour créer un compte, consultez Commencer à créer un AWS compte. Pour configurer les informations d'identification, consultez la section Configuration de la AWS CLI.
-
Autorisations IAM. Votre identité a besoin d'autorisations pour effectuer des appels d' AgentCore API et pour assumer les rôles de démarrage du CDK utilisés lors du déploiement. Reportez-vous à la section Utiliser la AgentCore CLI. L'exemple de client a également besoin d'autorisations IAM. Consultez Le rôle de session.
-
Accès aux modèles. Votre compte doit accéder au modèle
openai.gpt-5.6-lunaBedrock Managed Agents.
La CLI crée l'image du conteneur AWS CodeBuild dans votre compte.
Étape 1 : Création du projet
Installez la AgentCore CLI et définissez vos informations d'identification et votre région :
npm install -g @aws/agentcore agentcore --version export AWS_PROFILE=your-profile export AWS_REGION=us-east-1
Créez le projet avec le BedrockManagedAgents framework. Vous pouvez également courir agentcore create sans drapeaux. Sélectionnez Agent, puis sélectionnez Bedrock Managed Agents comme framework.
agentcore create --name MyManagedAgent --framework BedrockManagedAgents cd MyManagedAgent
Le projet contient la configuration d'exécution agentcore/agentcore.json et la source du conteneurapp/MyManagedAgent/. Le conteneur s'exécutecodex exec-server, qui se connecte aux agents gérés par Bedrock et exécute les commandes de l'agent.
Le projet configure le Runtime avec les valeurs par défaut suivantes :
-
Un délai d'inactivité de 30 minutes et une durée de vie maximale de 8 heures. Voir Configurer les paramètres du cycle de vie.
-
Un rôle d'exécution dont les autorisations sont entrées dans
policies/bma-acr-policy.json.
MyManagedAgent/ ├── agentcore/ │ ├── agentcore.json │ └── cdk/ └── app/MyManagedAgent/ ├── Dockerfile ├── lifecycle/server.py ├── otel/collector.yaml ├── plugins/acr-report/ ├── policies/ │ ├── bma-acr-policy.json │ ├── bma-session-trust.json │ └── bma-session-policy.json ├── pyproject.toml ├── client.py └── README.md
Fichiers clés :
-
lifecycle/server.py- Le serveur Lifecycle. Bedrock Managed Agents l'appelle pour démarrercodex exec-serverdans votre session Runtime. Ne modifiez pas ce fichier. -
Dockerfile- Installe Codex, l' CloudWatch agent et Python, puis copielifecycle/otel/, etplugins/vers./opt/bma -
otel/collector.yaml- Envoie les spans et les journaux du serveur exécutif à. CloudWatch -
plugins/acr-report/- Un exemple de plugin avec une compétence. La compétence est enregistréeacr-report.txtdans l'espace de travail. -
policies/bma-acr-policy.json- La politique du rôle d'exécution Runtime. Autorisebedrock-mantle:RegisterEnvironmentetbedrock-mantle:ConnectEnvironment. Pour le limiter à un seul projet, passezResourceàarn:aws:bedrock-mantle:<region>:<account-id>:project/<project-id>. -
pyproject.toml- Les dépendances de Python. Ledevgroupe est réservéclient.pyuniquement. -
policies/bma-session-trust.jsonetpolicies/bma-session-policy.json- La politique de confiance et les autorisations associées au rôle de session. Consultez Le rôle de session. -
client.py- Un exemple de client qui démarre une session. Vous l'exécutez à l'étape 3.
Ajoutez les options réseau à agentcore create :
agentcore create --name MyManagedAgent --framework BedrockManagedAgents \ --network-mode VPC --vpc-id <vpc-id> --subnets <subnet-ids> \ --security-groups <security-group-ids>
Le VPC doit avoir une route vers le point de terminaison Bedrock Managed Agents, car le serveur exécutif s'y connecte. La version de l'image télécharge Codex et Python, elle a donc également besoin d'un itinéraire vers Internet. Voir Configuration AgentCore pour VPC.
Le même projet s'exécute sur le type de calcul Instances. Ajoutez un fournisseur de capacité au projet, puis ajoutez l'agent avec le fournisseur de capacité :
agentcore create --name MyManagedAgent --no-agent cd MyManagedAgent agentcore add capacity-provider --name MyCapacityProvider \ --subnets <subnet-ids> --security-groups <security-group-ids> \ --os LINUX_ARM64 --instance-types c7g.large agentcore add agent --name MyManagedAgent --framework BedrockManagedAgents \ --capacity-provider MyCapacityProvider
Continuez ensuite avecÉtape 2 : Déploiement. agentcore deploycrée également le fournisseur de capacité et son rôle d'opérateur.
-
Types d'instance Use
LINUX_ARM64et Graviton, car la construction de l'image crée une image ARM64. -
Le fournisseur de capacité fournit le réseau. Les sous-réseaux doivent avoir une route vers le point de terminaison Bedrock Managed Agents.
Pour associer un fournisseur de capacité qui ne figure pas dans le projet, attribuez son ARN àagentcore create --framework BedrockManagedAgents --capacity-provider <capacity-provider-arn>. Voir Instances d'exécution et fournisseurs de capacité.
Étape 2 : Déploiement
agentcore deploy agentcore status
La CLI crée l'image AWS CodeBuild dans votre compte et déploie le Runtime et son rôle d'exécution. Bedrock Managed Agents invoque le Runtime pour vous.
Enregistrez l'ARN d'exécution à partir de la sortie de agentcore status :
arn:aws:bedrock-agentcore:us-east-1:<account-id>:runtime/<runtime-id>
Étape 3 : Lancer une session
Bedrock Managed Agents utilise un rôle de session pour appeler le modèle et appeler votre Runtime. Le rôle de session n'est pas le rôle d'exécution Runtime. Lorsque vous exécutezclient.py, le rôle de session est créé dans votre compte. agentcore deployne crée pas le rôle de session et agentcore remove ne le supprime pas. Consultez Le rôle de session.
Exécutez le client depuis le répertoire de l'agent :
cd app/MyManagedAgent uv run client.py --runtime <runtime-arn>
Le client crée une session et imprime l'ID de session, chaque commande avec sa sortie et la réponse de l'agent. Par défaut, l'agent utilise la acr-report compétence pour enregistrer des données acr-report.txt dans l'espace de travail.
La section suivante explique comment le client gère le rôle de session et les autorisations IAM dont vous avez besoin pour exécuter le client.
Le rôle de session n'est pas le rôle d'exécution Runtime. agentcore deploycrée le rôle d'exécution avecpolicies/bma-acr-policy.json. Le client donne le rôle de session aux agents gérés de Bedrock role_arn sur le terrain lorsqu'il crée une session.
Lorsque vous démarrez une nouvelle session et que vous ne donnez pas--role-arn, le client effectue les étapes suivantes :
-
Si le rôle
BmaSessionRole-<region>n'existe pas, le client le crée. -
Le client compare la politique de confiance et la politique en ligne
BmaSessiondu rôle avecpolicies/bma-session-trust.jsonetpolicies/bma-session-policy.json. Si une politique n'est pas la même, le client écrit le fichier dans le rôle. Les fichiers sont limités au compte et à la région du Runtime. -
Si le client change de rôle, il attend 15 secondes. IAM a besoin de ce temps avant que les agents gérés de Bedrock puissent utiliser le changement.
Pour modifier le rôle, modifiez les fichiers. Le client ne supprime pas les autres politiques que quelqu'un ajoute au rôle. Il ne vérifie pas le rôle lorsque vous donnez--session-id, et cela ne change pas le rôle avec lequel vous donnez--role-arn.
Pour la production, attribuez au client un rôle pour un Runtime et une passerelle avec--role-arn. Pour créer le rôle, utilisez les deux fichiers danspolicies/. Entrez votre partition, votre région et votre identifiant de compte, puis remplacez-les
par votre identifiant d'exécution et votre identifiant de passerelle. runtime/ gateway/* Ne modifiez pas les fichiers du projet, car tous les projets de la région sont partagésBmaSessionRole-<region>.
L'identité qui gère le client nécessite les autorisations du client Bedrock Managed bedrock-mantle:CallWithBearerToken Agents et iam:PassRole le rôle de session. Pour permettre au client de créer et de réparer le rôle, indiquez égalementiam:GetRole,,iam:CreateRole, iam:UpdateAssumeRolePolicyiam:GetRolePolicy, et ainsi de iam:PutRolePolicy suitearn:aws:iam::<account-id>:role/BmaSessionRole-*. Si vous les donnez--role-arn, le client n'a pas besoin de ces cinq autorisations.
Pour la politique de confiance, les autorisations associées au rôle de session et les autorisations du client, consultez la section Rôles de sécurité et IAM dans le guide de l'utilisateur d'Amazon Bedrock.
Le client utilise les client.beta.agents ressources du openai package. Bedrock Managed Agents exécute la boucle des agents.
Lorsque le client crée la session, il définit les valeurs suivantes dans environment :
-
type-aws_bedrock_agentcore, qui indique aux agents gérés par Bedrock d'utiliser un AgentCore Runtime. -
runtime_arn- Votre temps d'exécution. La session s'exécute dans la région du Runtime. -
workspace_directory- Le répertoire dans lequel l'agent exécute ses commandes. Le client utilise/home/app/workspace. Le serveur de cycle de vie crée le répertoire. -
runtime_qualifier- Le point final du Runtime. Le client utiliseDEFAULT. -
capability_directories- Les annuaires où Bedrock Managed Agents trouve des compétences. Le client utilise/opt/bma/plugins.
Le client définit également role_arn extra_body le rôle de session. Le openai package ne contient aucun paramètre pour ce champ.
L'provide_tokenassistant utilise vos AWS informations d'identification pour obtenir un jeton porteur Amazon Bedrock de courte durée pour chaque demande.
Si vous ajoutez une passerelle au projet, indiquez son ARN à partir de la sortie de agentcore deploy with--gateway. Utilisez le drapeau uniquement pour une nouvelle session. Le client ajoute la passerelle en tant qu'mcpoutil avec l'ARNconnector_id. Bedrock Managed Agents appelle la passerelle avec le rôle de session. La passerelle doit prendre en charge la version 2025-03-26 MCP. Si ce n'est pas le cas, l'agent n'obtient aucun outil de passerelle et Bedrock Managed Agents n'affiche aucune erreur.
"""Send an input to a Bedrock Managed Agents session that uses this project's ACR.""" import argparse import json import time from pathlib import Path from typing import Any import boto3 from aws_bedrock_token_generator import provide_token from botocore.exceptions import ClientError from openai import NotFoundError, OpenAI BMA_MODEL_ID = "openai.gpt-5.6-luna" # The agent runs its commands in this directory. The lifecycle server creates it. WORKSPACE_DIRECTORY = "/home/app/workspace" # Plugins and skills that the agent can use. The image has the acr-report plugin # at this path. Add the path of an S3 Files mount to use the skills in a bucket. CAPABILITY_DIRECTORIES = ["/opt/bma/plugins"] TURN_END = ("completed", "failed", "cancelled") TOOL_CALLS = ("mcp_call", "function_call", "web_search_call") POLICIES = Path(__file__).parent / "policies" SESSION_ROLE = "BmaSessionRole-{region}" SESSION_POLICY = "BmaSession" def show(data: dict[str, Any]) -> None: """Prints the session ID, the commands, the tool calls, and the answer.""" kind = data["type"].removeprefix("agent.session.") item = data.get("item") or {} if kind == "created": print(f"Session {data['session']['id']}") elif kind == "turn.output_text.delta": print(data["delta"], end="", flush=True) elif kind == "turn.item.done" and item.get("type") == "command_execution": print(f"\n$ {item['command']}\n{item.get('output') or ''}".rstrip()) elif kind == "turn.item.done" and item.get("type") in TOOL_CALLS: print(f"\nTool {item.get('name') or item['type']} {item.get('status')}") elif kind == "error" or kind.split(".")[-1] in TURN_END: source = data.get("turn") or data.get("environment") or data.get("session") print(f"\n{kind} {(source or data).get('error') or ''}".rstrip()) def load_policy(name: str, partition: str, region: str, account: str) -> str: """Reads a policy file and puts in the partition, the Region, and the account.""" text = (POLICIES / name).read_text() for key, value in (("Partition", partition), ("Region", region), ("AccountId", account)): text = text.replace("${AWS::" + key + "}", value) return text def session_role(runtime_arn: str) -> str: """Creates or repairs the session role, and returns its ARN. If the trust policy or the policy of the role is not the same as the file in `policies/`, the client writes the file to the role. """ _, partition, _, region, account = runtime_arn.split(":")[:5] name = SESSION_ROLE.format(region=region) trust = load_policy("bma-session-trust.json", partition, region, account) policy = load_policy("bma-session-policy.json", partition, region, account) iam = boto3.client("iam") changed = False try: role = iam.get_role(RoleName=name)["Role"] except iam.exceptions.NoSuchEntityException: role = iam.create_role(RoleName=name, AssumeRolePolicyDocument=trust)["Role"] print(f"Created the session role {name}") changed = True else: if role["AssumeRolePolicyDocument"] != json.loads(trust): iam.update_assume_role_policy(RoleName=name, PolicyDocument=trust) print(f"Updated the trust policy of {name}") changed = True try: current = iam.get_role_policy(RoleName=name, PolicyName=SESSION_POLICY)["PolicyDocument"] except iam.exceptions.NoSuchEntityException: current = None if current != json.loads(policy): iam.put_role_policy(RoleName=name, PolicyName=SESSION_POLICY, PolicyDocument=policy) if not changed: print(f"Updated the policy of {name}") changed = True if changed: # IAM needs some seconds before Bedrock Managed Agents can use a new or changed role. time.sleep(15) return role["Arn"] def main() -> None: parser = argparse.ArgumentParser(description=__doc__) parser.add_argument("--runtime", required=True, help="The ACR ARN.") parser.add_argument( "--session-id", help="The BMA session ID. If it does not exist, the client creates a session.", ) parser.add_argument( "--input", default="Use the acr-report skill to save an ACR report in the workspace.", ) parser.add_argument( "--gateway", help="The Gateway ARN from the output of `agentcore deploy`.", ) parser.add_argument( "--role-arn", help="The session role that BMA assumes. If you do not give it, the client creates a role.", ) parser.add_argument("--delete", action="store_true", help="Delete the session.") parser.add_argument("--raw", action="store_true", help="Print events as JSON.") args = parser.parse_args() # BMA must run in the Region of the ACR. region = args.runtime.split(":")[3] with OpenAI( api_key=lambda: provide_token(region=region), base_url=f"https://bedrock-mantle.{region}.api.aws/openai/v1", ) as client: sessions = client.beta.agents.sessions session_id = args.session_id if session_id: try: session = sessions.retrieve(session_id).model_dump(warnings=False) except NotFoundError: print(f"Session {session_id} does not exist.") session_id = None else: if session["environment"].get("runtime_arn") != args.runtime: raise ValueError(f"Session {session_id} uses another ACR.") if not session_id and not args.role_arn: try: args.role_arn = session_role(args.runtime) except ClientError as error: parser.error( f"The client cannot create or check the session role: {error}. " "Get the IAM permissions in README.md, or give --role-arn." ) print(f"Session role {args.role_arn}") if session_id: # BMA opens the stream only with stream=true, and the SDK does not send it. events = sessions.events.stream(session_id, extra_query={"stream": "true"}) message = { "role": "user", "content": [{"type": "input_text", "text": args.input}], } sessions.events.create( session_id, events=[{"type": "agent.session.input.message", "input": [message]}], ) else: agent: dict[str, Any] = { "model": BMA_MODEL_ID, "instructions": "Use the available tools to complete the task.", } if args.gateway: # Bedrock Managed Agents calls Gateway with the session role from the service side. agent["tools"] = [ {"type": "mcp", "server_label": "team_tools", "connector_id": args.gateway} ] args.input += " Then list the tools that the Gateway gives you." events = sessions.create( agent=agent, environment={ "type": "aws_bedrock_agentcore", "runtime_arn": args.runtime, "runtime_qualifier": "DEFAULT", "workspace_directory": WORKSPACE_DIRECTORY, "capability_directories": CAPABILITY_DIRECTORIES, }, input=args.input, stream=True, # The SDK has no role_arn parameter. BMA assumes this role to call the ACR. extra_body={"role_arn": args.role_arn}, ) with events: for event in events: data = event.model_dump(mode="json", warnings=False) session_id = session_id or (data.get("session") or {}).get("id") if args.raw: print(json.dumps(data), flush=True) else: show(data) if data["type"].removeprefix("agent.session.turn.") in TURN_END: break if args.delete: sessions.delete(session_id) print(f"\nDeleted session {session_id}") if __name__ == "__main__": main()
Étape 4 : Poursuivre la session
Pour envoyer une autre entrée à la même session, ajoutez l'ID de session. Le tour utilise le même espace de travail. Pour conserver l'espace de travail après un arrêt d'inactivité, ajoutez le stockage de session tel qu'il figure dansConserver les fichiers après un arrêt d'inactivité.
uv run client.py --runtime <runtime-arn> --session-id <session-id> \ --input "Run cat acr-report.txt and show the output."
Si la session n'existe pas, le client en crée une nouvelle. Ajoutez --delete pour supprimer la session après le tour ou --raw pour imprimer chaque événement au format JSON.
Sur un environnement d'exécution MicroVM, placez le répertoire personnel du serveur exécutif sur le stockage de session. Ensuite, l'espace de travail, l'état de connexion et le CODEX_HOME séjour après un arrêt d'inactivité.
-
Au lieu de la commande de l'étape 1, créez le projet avec le stockage de session :
agentcore create --name MyManagedAgent --framework BedrockManagedAgents \ --session-storage-mount-path /mnt/home cd MyManagedAgent -
Dans
agentcore/agentcore.json, ajoutez cette variable à l'entrée pour le Runtime :"envVars": [{ "name": "BMA_HOME_DIR", "value": "/mnt/home" }] -
À l'
client.pyintérieur, prêtWORKSPACE_DIRECTORY = "/mnt/home/workspace". -
Déployez et exécutez le client.
Pour plus d'informations sur le stockage de session, consultez la section Configurations du système de fichiers pour AgentCore Runtime.
Étape 5 : (Facultatif) Ajouter des compétences
Pour ajouter une compétence à l'image, ajoutez un plugin en dessous plugins/ et déployez-le. Un plugin possède un .codex-plugin/plugin.json fichier et un skills/ répertoire. Le skills/ répertoire contient un sous-répertoire pour chaque compétence, contenant un SKILL.md fichier. L'image le copie/opt/bma/plugins, que le client donne déjà à Bedrock Managed Agents.
Pour démarrerplugins/acr-report/, copier et renommer le répertoire du plugin, ainsi skills/acr-report/ que le nom de votre plugin et de votre compétence. Dansplugin.json, set nameversion,description, et"skills": "./skills/". Chacun SKILL.md commence par une matière première qui a name etdescription. Après le déploiement, démarrez une nouvelle session avec--input "Use the <skill-name> skill to …".
Montez un point d'accès S3 Files dans le Runtime. Ensuite, les compétences changent lorsque le compartiment change, et l'image reste la même. Pour le système de fichiers S3 Files, le point d'accès et les règles du groupe de sécurité, consultez la section Configurations du système de fichiers pour AgentCore Runtime.
Un montage S3 Files nécessite un environnement d'exécution en mode réseau VPC. Créez le projet avec les options réseau dansDéployer le Runtime dans un VPC.
Dans le compartiment, placez chaque plugin dans son propre répertoire sous le répertoire racine du point d'accès. Utilisez la même mise en page que plugins/acr-report/ : <plugin>/.codex-plugin/plugin.json et<plugin>/skills/<skill>/SKILL.md.
Ajoutez le montage à l'entrée pour le Runtime dans agentcore/agentcore.json :
{ "filesystemConfigurations": [ { "s3FilesAccessPoint": { "accessPointArn": "arn:aws:s3files:us-east-1:111122223333:file-system/fs-0123456789abcdef0/access-point/fsap-0123456789abcdef0", "mountPath": "/mnt/skills" } } ] }
Ensuite, client.py configurez CAPABILITY_DIRECTORIES ["/opt/bma/plugins", "/mnt/skills"] et déployez.
Étape 6 : Afficher les journaux et les traces
agentcore logs --since 15m
Le premier déploiement active la recherche de CloudWatch transactions dans votre compte. Les traces apparaissent au bout de 10 minutes environ. Pour voir les traces, ouvrez la CloudWatch console et choisissez GenAI Observability. Chaque appel des agents gérés de Bedrock au serveur de gestion du cycle de vie a une bma.invocation durée. Pour plus d'informations, consultez Afficher les données d'observabilité de vos agents Amazon Bedrock AgentCore .
Les paramètres de recherche de transactions s'appliquent à l'ensemble du compte
Transaction Search et son indexation de la durée s'appliquent à l'ensemble du compte dans la région, et des frais supplémentaires peuvent s'appliquer. Pour conserver vos paramètres actuels, ajoutez-les ~/.agentcore/config.json avant "disableTransactionSearch": true de procéder au déploiement.
Étape 7 : mise à jour et redéploiement
Modifiez les paramètres d'exécution dans agentcore/agentcore.json ou dans les fichiers de l'image, puis déployez à nouveau. Par exemple, ce paramètre arrête une session inactive au bout de 10 minutes. Les valeurs sont exprimées en secondes.
{ "lifecycleConfiguration": { "idleRuntimeSessionTimeout": 600, "maxLifetime": 28800 } }
agentcore deploy
Les modifications s'appliquent aux nouvelles sessions.
Ajoutez une variable à envVars dans l'entrée pour le Runtime, par exemple{ "name": "DISABLE_ADOT_OBSERVABILITY", "value": "true" }.
| Variable | Par défaut | Description |
|---|---|---|
|
|
Non défini |
Définissez sur |
|
|
|
|
|
|
|
Le répertoire de |
|
|
|
|
|
|
|
Le binaire du Codex. |
|
|
|
Le bail de tour le plus long, en secondes. |
Chaque compilation d'image installe la dernière version du Codex. Le serveur de cycle de vie nécessite Codex 0.154.0 ou version ultérieure. Pour épingler une version, CODEX_RELEASE=<version> ajoutez-la à côté CODEX_NON_INTERACTIVE=1 dans leDockerfile.
Étape 8 : nettoyer
Pour supprimer une session, ajoutez-la --delete à la dernière exécution du client pour cette session. Supprimez ensuite les ressources du projet et déployez-le pour supprimer le Runtime, son rôle d'exécution et la pile.
agentcore remove all agentcore deploy
Le déploiement ne supprime pas les ressources suivantes :
-
Les CloudWatch journaux enregistrent les groupes du Runtime, du CodeBuild projet qui crée l'image et de la fonction Lambda qui lance la génération.
-
La clé AWS KMS du référentiel Amazon ECR. La clé reste dans l'état En attente de suppression pendant 30 jours, puis AWS KMS la supprime.
-
La
CDKToolkitpile, si le premier déploiement a amorcé le compte et la région. D'autres applications AWS CDK peuvent utiliser cette pile. Supprimez-le uniquement si aucune autre application ne l'utilise. -
Les paramètres de recherche de transactions de l'étape 6.
-
Rôle de session
client.pycréé à l'étape 3.
Pour supprimer le rôle de session, exécutez les commandes suivantes :
aws iam delete-role-policy --role-name BmaSessionRole-<region> --policy-name BmaSession aws iam delete-role --role-name BmaSessionRole-<region>
Pour rechercher les groupes de journaux, exécutez ces commandes. Supprimez ensuite chaque groupe de journaux.
aws logs describe-log-groups --log-group-name-prefix /aws/bedrock-agentcore/runtimes/<project-name>_<agent-name>- --query 'logGroups[].logGroupName' aws logs describe-log-groups --log-group-name-prefix /aws/codebuild/AgentCore-<project-name>-<target-name>- --query 'logGroups[].logGroupName' aws logs describe-log-groups --log-group-name-prefix /aws/lambda/AgentCore- --query 'logGroups[].logGroupName' aws logs delete-log-group --log-group-name <log-group-name>
Remplacez les valeurs suivantes :
-
<project-name>- Le nom du projet. À l'étape 1, c'est le casMyManagedAgent. -
<agent-name>- Le nom de l'agent. À l'étape 1, c'est également le casMyManagedAgent. -
<target-name>- Le nom de la cible de déploiement dansagentcore/aws-targets.json. La valeur par défaut estdefault. Dans les CodeBuild noms, chaque trait de soulignement (_) du nom du projet et du nom de la cible est remplacé par un trait d'union ()-.
Le nom du groupe de logs Lambda est raccourci, comme dans cet exemple :
/aws/lambda/AgentCore-MyManagedAgent--ApplicationAgentMyManage-<suffix>
La commande répertorie les groupes de journaux Lambda de tous les projets AgentCore CLI de la région. Supprimez uniquement les groupes de journaux de votre projet.
Si vous avez ajouté d'autres ressources au projet, telles qu'une passerelle ou une mémoire, vérifiez que le déploiement les a supprimées.