Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Información general de la arquitectura
En esta sección, se proporcionan diagramas de arquitectura de implementación de referencia para los componentes implementados con esta solución.
## Diagramas de arquitectura
Para dar soporte a múltiples casos de uso y necesidades empresariales, esta solución ofrece seis CloudFormation plantillas de AWS:
1. **Panel de implementación**: el panel de implementación es una interfaz web que sirve como consola de administración para que los usuarios administradores vean, administren y creen sus casos de uso. Este panel de control permite a los clientes experimentar, iterar y poner en producción diversas AI/ML cargas de trabajo con rapidez, aprovechando el potencial. LLMs
1. Caso de **uso de texto: el caso** de uso de texto permite a los usuarios disfrutar de una interfaz de lenguaje natural mediante la IA generativa. Este caso de uso se puede integrar en aplicaciones nuevas o existentes y se puede implementar a través del panel de implementación o de forma independiente a través de la URL proporcionada.
1. Caso de **uso de Bedrock Agent: el caso** de uso de Bedrock Agent permite utilizar los agentes de Bedrock existentes para completar tareas o automatizar flujos de trabajo repetidos.
1. **Servidor MCP**: el caso de uso del servidor MCP permite el despliegue y la administración de servidores del Model Context Protocol que proporcionan acceso estandarizado a herramientas y recursos a las aplicaciones de IA. Admite tanto los métodos de puerta de enlace para empaquetar las funciones Lambda existentes como los servidores MCP externos APIs, y los métodos de tiempo de ejecución para implementar servidores MCP en contenedores personalizados.
1. **Agent Builder**: Agent Builder permite la creación e implementación de agentes de IA listos para la producción en Amazon Bedrock AgentCore con un control total de la configuración, integración de servidores MCP y capacidades de administración de memoria.
1. **Generador de flujos** de trabajo: el generador de flujos de trabajo permite crear agentes supervisores que orquesten varios agentes de Agent Builder utilizando el patrón de delegación Agents as Tools para flujos de trabajo complejos con varios agentes.
### Panel de despliegue
**Representa la arquitectura del panel de implementación (cuando se implementa con la opción VPC deshabilitada)**
![\[diagrama del panel de implementación\]](http://docs.aws.amazon.com/es_es/solutions/latest/generative-ai-application-builder-on-aws/images/deployment-dashboard-diagram.png)
**Describe la arquitectura del panel de implementación (cuando se implementa con la opción VPC habilitada)**
![\[diagrama de arco de vpc del panel de despliegue\]](http://docs.aws.amazon.com/es_es/solutions/latest/generative-ai-application-builder-on-aws/images/deployment-dashboard-vpc-arch-diagram.png)
**nota**
Los CloudFormation recursos de AWS se crean a partir de componentes del AWS Cloud Development Kit (AWS CDK).
El flujo de proceso de alto nivel para los componentes de la solución implementados con la CloudFormation plantilla de AWS es el siguiente:
1. Los usuarios administradores inician sesión en la interfaz de usuario (UI) del Deployment Dashboard.
1. [Amazon CloudFront](https://aws.amazon.com/cloudfront/) ofrece la interfaz de usuario web, que se aloja en un bucket de [Amazon Simple Storage Service (Amazon S3)](https://aws.amazon.com/s3/).
1. [AWS WAF los protege APIs de](https://aws.amazon.com/waf/) los ataques. Esta solución configura un conjunto de reglas denominado lista de control de acceso a la web (ACL web) que permite, bloquea o cuenta las solicitudes web en función de reglas y condiciones de seguridad web configurables y definidas por el usuario.
1. La interfaz de usuario web utiliza un conjunto de REST APIs que se exponen mediante [Amazon API Gateway](https://aws.amazon.com/api-gateway/).
1. [Amazon Cognito autentica a](https://aws.amazon.com/cognito/) los usuarios y respalda tanto la interfaz de usuario CloudFront web como la API Gateway.
1. [AWS Lambda](https://aws.amazon.com/lambda/) proporciona la lógica empresarial para los puntos de enlace REST. [Esta función Lambda de *respaldo* administra y crea los recursos necesarios para realizar implementaciones de casos de uso mediante AWS. CloudFormation](https://aws.amazon.com/cloudformation/)
1. [Amazon DynamoDB](https://aws.amazon.com/dynamodb) almacena la lista de implementaciones.
1. Cuando el usuario administrador crea un nuevo caso de uso, la función Lambda de *respaldo* inicia un evento de creación de CloudFormation pilas para el caso de uso solicitado.
1. Todas las opciones de configuración de LLM proporcionadas por el usuario administrador en el asistente de implementación se guardan en DynamoDB. La implementación usa esta tabla de DynamoDB para configurar el LLM en tiempo de ejecución.
1. Con [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/), esta solución recopila métricas operativas de varios servicios para generar paneles personalizados que le permiten monitorear el rendimiento y el estado operativo de la solución.
**nota**
Si decide implementar esta solución en una Amazon VPC, los datos se enrutarán dentro de su red privada.
Si bien el panel de implementación se puede lanzar en la mayoría de las regiones de AWS, los casos de uso implementados tienen ciertas restricciones según la disponibilidad del servicio. Consulte [las regiones de AWS compatibles](plan-your-deployment.md#supported-aws-regions) para obtener más información.
### Caso de uso de texto
**Describe la arquitectura de casos de uso de Text (cuando se implementa con la opción VPC deshabilitada)**
![\[diagrama de casos de uso de texto\]](http://docs.aws.amazon.com/es_es/solutions/latest/generative-ai-application-builder-on-aws/images/text-use-case-diagram.png)
**Describe la arquitectura de casos de uso de Text (cuando se implementa con la opción VPC habilitada)**
![\[diagrama de arco de vpc con casos de uso de texto\]](http://docs.aws.amazon.com/es_es/solutions/latest/generative-ai-application-builder-on-aws/images/text-use-case-vpc-arch-diagram.png)
El flujo de proceso de alto nivel para los componentes de la solución implementados con la CloudFormation plantilla de AWS es el siguiente:
1. Los usuarios administradores implementan el caso de uso mediante el panel de implementación. [Los usuarios empresariales](concepts-and-definitions.md) inician sesión en la interfaz de usuario del caso de uso.
1. CloudFront ofrece la interfaz de usuario web que está alojada en un bucket de S3.
1. La interfaz de usuario web aprovecha una WebSocket integración creada mediante API Gateway. La API Gateway está respaldada por una función de [autorización Lambda personalizada, que devuelve la política de [AWS Identity and Access Management](https://aws.amazon.com/iam/) (IAM) correspondiente en función del grupo de Amazon Cognito al que pertenece el usuario autenticador](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html). La política se almacena en DynamoDB.
1. Amazon Cognito autentica a los usuarios y respalda tanto la interfaz de usuario CloudFront web como la API Gateway.
1. *Las solicitudes entrantes del usuario empresarial se transfieren de API Gateway a una [cola de Amazon SQS](https://aws.amazon.com/sqs/) y, después, al Orchestrator. LangChain * El *LangChain Orchestrator* es un conjunto de funciones y capas de Lambda que proporcionan la lógica empresarial necesaria para cumplir con las solicitudes del usuario empresarial. La cola permite el funcionamiento asíncrono de la integración entre API Gateway y Lambda. La cola pasa la información de conexión a las funciones de Lambda, que luego publicarán los resultados directamente en la conexión websocket de API Gateway para admitir llamadas de inferencia de larga duración.
1. *LangChain Orchestrator* utiliza Amazon DynamoDB para obtener las opciones de LLM configuradas y la información de sesión necesaria (como el historial de chats).
1. Si la implementación tiene una base de conocimientos habilitada, *LangChain Orchestrator* utiliza [Amazon Kendra](https://aws.amazon.com/kendra/) [o Knowledge Bases for Amazon Bedrock para](https://aws.amazon.com/bedrock/knowledge-bases/) ejecutar una consulta de búsqueda y recuperar extractos de documentos.
1. [Con el historial de chat, la consulta y el contexto de la base de conocimientos, el *LangChain Orchestrator* crea el mensaje final y lo envía al LLM alojado en Amazon [Bedrock o Amazon AI](https://aws.amazon.com/bedrock/). SageMaker ](https://aws.amazon.com/sagemaker/)
1. Cuando la respuesta proviene del LLM, el *LangChain Orchestrator* transmite la respuesta a través de la API Gateway WebSocket para que la utilice la aplicación cliente.
1. Con Amazon CloudWatch, esta solución recopila métricas operativas de varios servicios para generar paneles personalizados que le permiten monitorear el rendimiento y el estado operativo de la implementación.
1. Si la recopilación de comentarios está habilitada, se pone a disposición un punto final de la API REST, que aprovecha Amazon API Gateway, para recopilar los comentarios de los usuarios.
1. Los comentarios que respaldan a Lambda aumentan los comentarios enviados con metadatos adicionales específicos para cada caso de uso (por ejemplo, el modelo utilizado) y almacenan los datos en Amazon S3 para que los usuarios los DevOps analicen e informen posteriormente.
**nota**
Si decide implementar esta solución en una Amazon VPC, los datos se enrutarán a su red privada.
### Caso de uso de Bedrock Agent
**Describe la arquitectura de casos de uso de Bedrock Agent (cuando se implementa con la opción VPC deshabilitada)**
![\[diagrama de casos de uso del agente\]](http://docs.aws.amazon.com/es_es/solutions/latest/generative-ai-application-builder-on-aws/images/agent-use-case-diagram.png)
**Describe la arquitectura de casos de uso de Bedrock Agent (cuando se implementa con la opción VPC habilitada)**
![\[diagrama de vpc arch/caso de uso del agente\]](http://docs.aws.amazon.com/es_es/solutions/latest/generative-ai-application-builder-on-aws/images/agent-use-case-vpc-arch-diagram.png)
El flujo de proceso de alto nivel para los componentes de la solución implementados con la CloudFormation plantilla de AWS es el siguiente:
1. Los usuarios administradores implementan el caso de uso mediante el panel de implementación. [Los usuarios empresariales](concepts-and-definitions.md) inician sesión en la interfaz de usuario del caso de uso.
1. CloudFront proporciona la interfaz de usuario web que está alojada en un bucket de S3.
1. La interfaz de usuario web aprovecha una WebSocket integración creada mediante API Gateway. La API Gateway está respaldada por una función de autorización Lambda personalizada, que devuelve la política de [AWS Identity and Access Management](https://aws.amazon.com/iam/) (IAM) correspondiente en función del grupo de Amazon Cognito al que pertenece el usuario autenticador. La política se almacena en DynamoDB.
1. Amazon Cognito autentica a los usuarios y respalda tanto la interfaz de usuario CloudFront web como la API Gateway.
1. Las solicitudes entrantes del usuario empresarial se transfieren de API Gateway a una [cola de Amazon SQS](https://aws.amazon.com/sqs/) y, a continuación, a la función AWS Lambda. La cola permite el funcionamiento asíncrono de la integración entre API Gateway y Lambda. La cola pasa la información de conexión a la función Lambda, que luego publicará los resultados directamente en la conexión websocket de API Gateway para admitir llamadas de inferencia de larga duración.
1. La función AWS Lambda usa Amazon DynamoDB para obtener las configuraciones de los casos de uso según sea necesario
1. Con la entrada del usuario y cualquier configuración de caso de uso relevante, la función AWS Lambda crea y envía una carga útil de solicitud al [Amazon Bedrock Agent](https://aws.amazon.com/bedrock/agents/) configurado para cumplir con la intención del usuario.
1. Cuando la respuesta proviene del Amazon Bedrock Agent, la función Lambda transmite la respuesta a través de la API WebSocket Gateway para que la utilice la aplicación cliente.
1. Con Amazon CloudWatch, esta solución recopila métricas operativas de varios servicios para generar paneles personalizados que le permiten monitorear el rendimiento y el estado operativo de la implementación.
1. Si la recopilación de comentarios está habilitada, se pone a disposición un punto final de la API REST, que aprovecha Amazon API Gateway, para recopilar los comentarios de los usuarios.
1. Los comentarios que respaldan a Lambda aumentan los comentarios enviados con metadatos adicionales específicos para cada caso de uso y almacenan los datos en Amazon S3 para que los usuarios los DevOps analicen e informen posteriormente.
**nota**
Si decide implementar esta solución en una Amazon VPC, los datos se enrutarán dentro de su red privada.
### Caso de uso del servidor MCP
**Describe la arquitectura de casos de uso del servidor MCP**
![\[diagrama de casos de uso del servidor mcp\]](http://docs.aws.amazon.com/es_es/solutions/latest/generative-ai-application-builder-on-aws/images/mcp-server-use-case-diagram.png)
El caso de uso del servidor MCP permite la implementación y la administración de servidores del Model Context Protocol en Amazon Bedrock AgentCore. Los servidores MCP proporcionan una interfaz estandarizada para que las aplicaciones de IA accedan a las herramientas, los recursos y las fuentes de datos empresariales.
La solución admite dos métodos de implementación:
+ **Método de puerta** de enlace: agrupa las funciones Lambda, APIs REST o servidores MCP externos existentes como herramientas MCP, gestionando la traducción de protocolos automáticamente
+ **Método de ejecución**: despliega servidores MCP en contenedores personalizados a partir de imágenes de Amazon ECR
El flujo de proceso de alto nivel para la implementación del servidor MCP es el siguiente:
1. Los usuarios administradores implementan el caso de uso del servidor MCP mediante el panel de implementación y seleccionan el método de implementación Gateway o Runtime.
1. Esta acción se autentica con Amazon Cognito.
1. Para la implementación de Gateway, la solución crea un Amazon Bedrock AgentCore Gateway que transforma las funciones APIs Lambda existentes o los servidores MCP externos en herramientas compatibles con MCP. Para la implementación en tiempo de ejecución, la solución implementa servidores MCP en contenedores en Amazon Bedrock AgentCore Runtime mediante las imágenes ECR proporcionadas.
1. Las implementaciones de Gateway recuperan los API/Lambda/Smithy esquemas necesarios de la ubicación en la que se cargaron en Amazon S3 o se conectan directamente a los puntos de enlace URL del servidor MCP.
1. Las implementaciones en tiempo de ejecución recuperan el servidor MCP en contenedores proporcionado por el usuario de Amazon Elastic Container Registry (ECR)
1. El servidor MCP está equipado con un cliente Amazon Bedrock Identity AgentCore OAuth
1. El servidor MCP hace que las herramientas asociadas estén disponibles en el punto final /mcp para que las descubran los agentes.
1. Amazon CloudWatch recopila métricas y registros operativos de las implementaciones de servidores MCP para su supervisión y solución de problemas.
### Caso de uso de Agent Builder
**Describe la arquitectura de Agent Builder**
![\[diagrama de despliegue de Agent Builder\]](http://docs.aws.amazon.com/es_es/solutions/latest/generative-ai-application-builder-on-aws/images/agent-builder-deployment-diagram.png)
El flujo de proceso de alto nivel para los componentes de Agent Builder implementados con la CloudFormation plantilla de AWS es el siguiente:
1. Los usuarios administradores implementan el caso de uso mediante el panel de implementación. [Los usuarios empresariales](concepts-and-definitions.md) inician sesión en la interfaz de usuario del caso de uso.
1. CloudFront proporciona la interfaz de usuario web que está alojada en un bucket de S3.
1. La interfaz de usuario web aprovecha una WebSocket integración creada mediante API Gateway. La API Gateway está respaldada por una función de autorización Lambda personalizada, que devuelve la política de [AWS Identity and Access Management](https://aws.amazon.com/iam/) (IAM) correspondiente en función del grupo de Amazon Cognito al que pertenece el usuario autenticador. La política se almacena en DynamoDB.
1. Amazon Cognito autentica a los usuarios y respalda tanto la interfaz de usuario CloudFront web como la API Gateway.
1. Las solicitudes entrantes del usuario empresarial se transfieren de API Gateway a una [cola de Amazon SQS](https://aws.amazon.com/sqs/) y, a continuación, a la función AWS Lambda. La cola permite el funcionamiento asíncrono de la integración entre API Gateway y Lambda. La cola pasa la información de conexión a la función Lambda, que luego publicará los resultados directamente en la conexión websocket de API Gateway para admitir llamadas de inferencia de larga duración.
1. La función AWS Lambda recupera la configuración del agente de DynamoDB.
1. Con la entrada del usuario y cualquier configuración de caso de uso relevante, la función AWS Lambda crea y envía una carga útil de solicitud al agente, que se ejecuta en [Amazon](https://aws.amazon.com/bedrock/agentcore/) Bedrock Runtime. AgentCore
1. El agente se conecta a los servidores MCP asociados y registra las herramientas en la instancia del agente de Strands. A continuación, el agente selecciona y ejecuta las acciones de forma autónoma en función de las descripciones de las herramientas y los requisitos de las tareas.
1. Cuando la respuesta regresa del entorno de AgentCore ejecución de Amazon Bedrock, la función Lambda transmite la respuesta a través de la API WebSocket Gateway para que la utilice la aplicación cliente.
**nota**
El procesamiento del agente está limitado al tiempo de espera de ejecución de Lambda (15 minutos).
### Caso de uso de Workflow Builder
**Describe la arquitectura de Workflow Builder**
![\[diagrama de despliegue del flujo de trabajo\]](http://docs.aws.amazon.com/es_es/solutions/latest/generative-ai-application-builder-on-aws/images/workflow-deployment-diagram.png)
El flujo de proceso de alto nivel para los componentes de Workflow Builder implementados con la CloudFormation plantilla de AWS es el siguiente:
1. Los usuarios administradores implementan el flujo de trabajo mediante el panel de implementación y seleccionan los agentes de Agent Builder para incluirlos como agentes especializados.
1. CloudFront ofrece la interfaz de usuario web que está alojada en un bucket de S3.
1. La interfaz de usuario web aprovecha una WebSocket integración creada mediante API Gateway. La API Gateway está respaldada por una función de autorización Lambda personalizada, que devuelve la política de [AWS Identity and Access Management](https://aws.amazon.com/iam/) (IAM) correspondiente en función del grupo de Amazon Cognito al que pertenece el usuario autenticador. La política se almacena en DynamoDB.
1. Amazon Cognito autentica a los usuarios y respalda tanto la interfaz de usuario CloudFront web como la API Gateway.
1. Las solicitudes entrantes del usuario empresarial se transfieren de API Gateway a una [cola de Amazon SQS](https://aws.amazon.com/sqs/) y, a continuación, a la función AWS Lambda. La cola permite el funcionamiento asíncrono de la integración entre API Gateway y Lambda.
1. La función AWS Lambda recupera la configuración del flujo de trabajo de DynamoDB, incluida la lista de agentes especializados en Agent Builder.
1. Con las entradas del usuario y la configuración del flujo de trabajo, Lambda envía las solicitudes al [Amazon Bedrock AgentCore Runtime](https://aws.amazon.com/bedrock/agentcore/) que aloja al agente supervisor.
1. El agente supervisor crea instancias locales de todos los agentes especializados de Agent Builder dentro del AgentCore entorno de ejecución. Estos agentes especializados se registran como herramientas mediante el patrón Agentes como herramientas. Luego, el supervisor selecciona y delega el trabajo de forma autónoma en agentes especializados en función de las descripciones de los agentes y los requisitos de la tarea.
1. El agente supervisor agrega los resultados de los agentes especializados y formula la respuesta final y la devuelve a la Lambda para que se transmita a la aplicación cliente a través del API Gateway Websocket.
**nota**
El procesamiento del flujo de trabajo está limitado al tiempo de espera de ejecución de Lambda (15 minutos).
# Consideraciones sobre el diseño de AWS Well-Architected
Esta solución se diseñó con las mejores prácticas del [AWS Well-Architected Framework](https://aws.amazon.com/architecture/well-architected/), que ayuda a los clientes a diseñar y operar cargas de trabajo confiables, seguras, eficientes y rentables en la nube.
En esta sección se describe la aplicación de los principios de diseño y las prácticas recomendadas del Marco de Well-Architected al crear esta solución.
## Excelencia operativa
En esta sección se describe cómo diseñamos esta solución utilizando los principios y las prácticas recomendadas del [pilar de excelencia operativa](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html).
+ Creamos la solución infrastructure-as-code con Amazon CloudFormation.
+ Las funciones de Lambda envían métricas personalizadas CloudWatch y un CloudWatch panel personalizado para supervisar el estado de la solución.
+ Los componentes de la solución están altamente modularizados, lo que proporciona la flexibilidad necesaria para elegir los componentes que se van a implementar.
## Seguridad
En esta sección se describe cómo diseñamos esta solución utilizando los principios y las prácticas recomendadas del [pilar de seguridad](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html).
+ El panel de implementación y todos los casos de uso están autenticados y autorizados con Amazon Cognito.
+ Todas las comunicaciones entre servicios utilizan las funciones de IAM de AWS.
+ Todas las funciones de la solución se basan en el acceso con el mínimo privilegio, es decir, solo se conceden los permisos mínimos necesarios.
+ Todo el almacenamiento de datos, incluidos los buckets S3, DynamoDB y Amazon Kendra, tiene cifrado en reposo.
## Fiabilidad
En esta sección se describe cómo diseñamos esta solución utilizando los principios y las prácticas recomendadas del [pilar de fiabilidad](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html).
+ Arquitectura basada en el paradigma sin servidor.
+ Creamos la arquitectura para ofrecer escalabilidad horizontal bajo demanda y recuperación automática en caso de fallo de la infraestructura subyacente.
+ La arquitectura incluye el almacenamiento en búfer y la limitación de las solicitudes para no sobrecargar los puntos finales subyacentes.
## Eficiencia del rendimiento
En esta sección se describe cómo diseñamos esta solución utilizando los principios y las prácticas recomendadas del [pilar de eficiencia del rendimiento](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/welcome.html).
+ La solución utiliza DynamoDB, una base de datos NoSQL sin servidor totalmente gestionada con escalado bajo demanda.
+ La solución utiliza Amazon S3 para el almacenamiento de objetos y para alojar un sitio web (mediante CloudFront) a fin de ofrecer un bajo coste, escalable y una durabilidad de 11 9 segundos.
## Optimización de costos
En esta sección se describe cómo diseñamos esta solución utilizando los principios y las prácticas recomendadas del [pilar de optimización de costos](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html).
+ Siempre que fue posible, diseñamos la solución para usar una arquitectura sin servidor, de modo que solo paga por lo que usa.
## Sostenibilidad
En esta sección se describe cómo diseñamos esta solución utilizando los principios y las mejores prácticas del [pilar de sostenibilidad](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sustainability-pillar.html).
+ La arquitectura modular y dividida en componentes de la solución ofrece la flexibilidad de personalizar los recursos que se van a aprovisionar para casos de uso individuales.
+ La arquitectura utiliza computación y almacenamiento sin servidor, lo que optimiza la utilización de los recursos.
+ Como solución basada en la nube, esta solución se beneficia de los recursos compartidos, las redes, la alimentación, la refrigeración y las instalaciones físicas.