Este documento técnico es únicamente de referencia histórica. Es posible que parte del contenido esté desactualizado y que algunos enlaces no estén disponibles.
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.
# Ejemplos de patrones de arquitectura
Puede implementar patrones de arquitectura populares mediante API Gateway y AWS Lambda como nivel lógico. Este documento técnico incluye los patrones de arquitectura más populares que aprovechan los niveles lógicos AWS Lambda basados en datos:
+ **Backend móvil:** una aplicación móvil se comunica con API Gateway y Lambda para acceder a los datos de la aplicación. Este patrón se puede extender a los clientes HTTPS genéricos que no utilizan los recursos de AWS sin servidor para alojar los recursos del nivel de presentación (como los clientes de escritorio, el servidor web que se ejecuta EC2, etc.).
+ **Aplicación de una sola página**: una aplicación de una sola página alojada en Amazon S3 y que CloudFront se comunica con API Gateway y accede AWS Lambda a los datos de la aplicación.
+ **Aplicación web**: la aplicación web es un back-end de aplicaciones web de uso general y basado en eventos que utiliza API AWS Lambda Gateway para su lógica empresarial. También usa DynamoDB como base de datos y Amazon Cognito para la administración de usuarios. Todo el contenido estático se aloja mediante Amplify.
Además de estos dos patrones, en este documento técnico se analiza la aplicabilidad de Lambda y API Gateway a una arquitectura general de microservicios. La arquitectura de microservicios es un patrón popular que, si bien no es una arquitectura estándar de tres niveles, implica desvincular los componentes de la aplicación y desplegarlos como unidades de funcionalidad individuales y sin estado que se comunican entre sí.
# Backend móvil
![\[Patrón arquitectónico para el backend móvil sin servidor\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/arch-pattern-serverless-mobile-backend.png)
*Patrón arquitectónico para el backend móvil sin servidor*
*Tabla 1: Componentes del nivel de backend móvil*
| Nivel | Componentes |
| --- | --- |
| Presentación | Aplicación móvil que se ejecuta en un dispositivo de usuario. |
| Logic (Lógica) | Amazon API Gateway con AWS Lambda. Esta arquitectura muestra tres servicios expuestos (`/tickets``/shows`, y`/info`). Los puntos de enlace de API Gateway están protegidos por grupos de [usuarios de Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html). Con este método, los usuarios inician sesión en los grupos de usuarios de Amazon Cognito (utilizando un tercero federado si es necesario) y reciben tokens de acceso e ID que se utilizan para autorizar las llamadas a API Gateway. A cada función de Lambda se le asigna su propia función de Identity and Access Management (IAM) (Identity and Access Management, IAM) para proporcionar acceso a la fuente de datos adecuada. |
| Datos | DynamoDB se utiliza para `/tickets` los servicios y. `/shows` Para el `/info` servicio se utiliza Amazon RDS. Esta función Lambda recupera las credenciales de Amazon RDS de Secrets AWS Manager y utiliza una interfaz de red elástica para acceder a la subred privada. |
# Aplicación de una sola página
![\[AWS architecture diagram showing interactions between services like CloudFront, S3, Lambda, and DynamoDB.\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/single-page-application.png)
*Patrón arquitectónico para aplicaciones de una sola página sin servidor*
*Tabla 2: Componentes de la aplicación de una sola página*
| Nivel | Componentes |
| --- | --- |
| Presentación | Contenido de sitios web estáticos alojado en Amazon S3, distribuido por CloudFront. AWS Certificate Manager permite utilizar un certificado SSL/TLS personalizado. |
| Logic (Lógica) | API Gateway con AWS Lambda. Esta arquitectura muestra tres servicios expuestos (`/tickets``/shows`, y`/info`). Los puntos finales de API Gateway están protegidos por un autorizador Lambda. Con este método, los usuarios inician sesión a través de un proveedor de identidad externo y obtienen tokens de acceso e identificación. Estos tokens se incluyen en las llamadas a API Gateway, y el autorizador de Lambda los valida y genera una política de IAM que contiene los permisos de inicio de la API. A cada función de Lambda se le asigna su propia función de IAM para proporcionar acceso a la fuente de datos adecuada. |
| Datos | Amazon DynamoDB se utiliza para `/tickets` los servicios y. `/shows` El `/shows` servicio ElastiCache utiliza Amazon para mejorar el rendimiento de la base de datos. Los errores de caché se envían a DynamoDB. Amazon S3 se utiliza para alojar contenido estático utilizado por`/info service`. |
# Aplicación web
![\[Nube de AWS architecture diagram showing client interaction with various Servicios de AWS.\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/web-application.png)
*Patrón arquitectónico para la aplicación web*
*Tabla 3: Componentes de la aplicación web*
| Nivel | Componentes |
| --- | --- |
| Presentación | La aplicación front-end es todo contenido estático (HTML, CSS JavaScript e imágenes) generado por utilidades como create-react-app React. Amazon CloudFront aloja todos estos objetos. La aplicación web, cuando se usa, descarga todos los recursos al navegador y comienza a ejecutarse desde allí. La aplicación web se conecta al backend llamando al APIs. |
| Logic (Lógica) | La capa lógica se crea con funciones de Lambda dirigidas por API Gateway REST. APIs Esta arquitectura muestra varios servicios expuestos. Hay varias funciones Lambda diferentes, cada una de las cuales gestiona un aspecto diferente de la aplicación. Las funciones de Lambda están detrás de API Gateway y se puede acceder a ellas mediante rutas URL de API. La autenticación de los usuarios se gestiona mediante grupos de usuarios de Amazon Cognito o proveedores de usuarios federados. API Gateway utiliza una integración inmediata con Amazon Cognito. Solo después de que el usuario se haya autenticado, el cliente recibirá un token JSON Web Token (JWT) que deberá usar al realizar las llamadas a la API. A cada función de Lambda se le asigna su propia función de IAM para proporcionar acceso a la fuente de datos adecuada. |
| Datos | En este ejemplo concreto, DynamoDB se usa para el almacenamiento de datos, pero se pueden usar otras bases de datos o servicios de almacenamiento de Amazon diseñados específicamente, según el caso de uso y el escenario de uso. |
# Microservicios con Lambda
![\[Nube de AWS architecture with API Gateways and Lambda functions across two accounts.\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/microservices-with-lambda.png)
*Patrón arquitectónico para microservicios con Lambda*
El patrón de arquitectura de microservicios no está limitado a la arquitectura típica de tres niveles; sin embargo, este patrón popular puede reportar beneficios significativos al usar recursos sin servidor.
En esta arquitectura, cada uno de los componentes de la aplicación está desacoplado y se implementa y opera de forma independiente. Todo lo que necesita para crear un microservicio es una API creada con Amazon API Gateway y funciones lanzadas AWS Lambda posteriormente por él. Su equipo puede usar estos servicios para desacoplar y fragmentar su entorno con el nivel de granularidad deseado.
En general, un entorno de microservicios puede presentar las siguientes dificultades: sobrecarga constante al crear cada nuevo microservicio, problemas con la optimización de la densidad y la utilización de los servidores, complejidad al ejecutar varias versiones de varios microservicios simultáneamente y la proliferación de requisitos de código del lado del cliente para la integración con muchos servicios distintos.
Cuando se crean microservicios con recursos sin servidor, estos problemas se vuelven menos difíciles de resolver y, en algunos casos, simplemente desaparecen. El patrón de microservicios sin servidor reduce la barrera para la creación de cada microservicio posterior (API Gateway incluso permite la clonación de funciones Lambda existentes APIs y el uso de las mismas en otras cuentas). La optimización de la utilización de los servidores ya no es relevante con este patrón. Por último, Amazon API Gateway proporciona un cliente generado mediante programación SDKs en varios lenguajes populares para reducir la sobrecarga de integración.