Elegir un AWS servicio sin servidor

Step Functions admite variables para asignar datos en un estado y usarlos en estados posteriores, así como transformaciones de JSonata para la manipulación avanzada de datos, incluido el formateo de fechas y las operaciones matemáticas. Estas funciones simplifican el intercambio de datos entre los estados y reducen la necesidad de pasos de procesamiento intermedios. Para el procesamiento por lotes a gran escala, Distributed Map ejecuta el mismo proceso en millones de elementos de conjuntos de datos de Amazon S3, Athena o JSON en paralelo sin aprovisionar la infraestructura informática.

Comprender el patrón operativo de su aplicación es el factor más importante a la hora de seleccionar los servicios sin servidor. Los diferentes patrones de carga de trabajo exigen diferentes combinaciones de servicios. El procesamiento de datos sin servidor se ajusta en gran medida a los siguientes patrones:

Cada patrón utiliza una combinación diferente de servicios sin servidor. Para ver ejemplos detallados y combinaciones de servicios recomendadas para cada patrón, consulte la sección Elegir.

Los servicios de computación sin servidor difieren significativamente en cuanto al tiempo que permiten que se ejecute una sola ejecución y a la forma en que gestionan la simultaneidad. A diferencia de los servidores tradicionales, las funciones de eventos de Lambda no se ejecutan constantemente. Cuando un evento desencadena una función, esto se denomina invocación. Las funciones de eventos de Lambda tienen una duración limitada de 15 minutos, pero, de media, en todos los AWS clientes, la mayoría de las invocaciones duran menos de un segundo.

Short-lived, las invocaciones basadas en eventos son las que mejor funcionan con Lambda, que admite ejecuciones de hasta 15 minutos y escala automáticamente por solicitud hasta miles de invocaciones simultáneas. El servicio Lambda ejecuta instancias de su función solo cuando es necesario y escala automáticamente de cero solicitudes por día a miles por segundo. Solo pagas por el tiempo de procesamiento que realmente se utilice, por lo que no se te cobrará nada cuando el código no se esté ejecutando. La facturación por milisegundo de Lambda puede reducir el costo de las cargas de trabajo de corta duración.

Hay muchos tipos de eventos de invocación que pueden activar funciones de corta duración. Algunos ejemplos incluyen una solicitud HTTP de API Gateway, una programación gestionada mediante una EventBridge regla, un mensaje de un dispositivo de IoT o una notificación de que se ha subido un archivo a un bucket de Amazon S3.

Las sesiones interactivas y llenas de estado, como los entornos limitados de codificación con IA, los cuadernos interactivos y los entornos de CI con varios usuarios, necesitan entornos aislados que mantengan el estado en todas las interacciones de los usuarios. Las micromáquinas virtuales de Lambda tienen un formato informático diferente al de Event Functions: utilizan un modelo de Dockerfile-based programación, asignan un entorno por sesión (no por solicitud) y facturan según un modelo de línea base más ráfaga en lugar de por milisegundo. Las micromáquinas virtuales proporcionan VM-level aislamiento con todas las capacidades del sistema operativo, un inicio rápido basado en instantáneas, una vida útil de hasta 8 horas y reducen los costos de inactividad. suspend/resume

Long-running o los procesos en estado estacionario, como los trabajos por lotes, WebSocket las conexiones persistentes o los servicios que requieren más de 15 minutos de procesamiento continuo, se benefician mejor con Fargate, que puede ejecutarse indefinidamente. Para obtener más información sobre cómo Fargate y Lambda escalan de forma diferente, consulta la pestaña Modelo de escalado y latencia. Fargate proporciona una asignación uniforme de recursos para las cargas de trabajo que superan los límites de tiempo de espera o procesamiento de Lambda. Además, las funciones duraderas de Lambda permiten ejecuciones prolongadas y de varios pasos que mantienen el estado en varias invocaciones. Cada invocación individual sigue respetando el límite de 15 minutos. Las funciones duraderas comprueban automáticamente el progreso y se reanudan donde lo dejaron, por lo que la duración total de los flujos de trabajo puede superar con creces los 15 minutos sin necesidad de Fargate ni de una organización externa.

Tenga en cuenta el tiempo medio y máximo de ejecución de sus cargas de trabajo. Una función de Lambda que, en ocasiones, supera los 15 minutos falla de forma impredecible y requiere un rediseño arquitectónico. La arquitectura y las necesidades de su aplicación determinan cómo invocar una función. Por ejemplo, los patrones de procesamiento por lotes tienen requisitos diferentes a los del procesamiento de datos bajo demanda. Fargate se adapta a un microservicio que gestiona principalmente el procesamiento de datos por lotes. Lambda es más fácil de implementar y mantener para el procesamiento bajo demanda.

Una de las principales ventajas del desarrollo sin servidor es que solo paga por los recursos que consume. Las tecnologías sin servidor se pagan por uso, lo que significa que puede ampliarlas y reducirlas a medida que cambien las necesidades de sus aplicaciones sin tener que pagar por la capacidad inactiva. Sin embargo, los distintos servicios AWS sin servidor utilizan distintos modelos de precios que favorecen distintos patrones de uso.

Pay-per-use los precios (Lambda, Step Functions Express EventBridge) se cobran en función de las invocaciones reales y la duración, sin coste alguno cuando están inactivos. En el caso de Lambda, se cobra en función del número de solicitudes de las funciones y del tiempo que tarda el código en ejecutarse. No se aplican cargos cuando su código no se está ejecutando. Este modelo se adapta a cargas de trabajo impredecibles o con picos de tráfico que pueden reducirse a cero, y a aplicaciones en fase inicial en las que la demanda es incierta.

Capacity-based los precios (Fargate, Amazon Aurora Serverless, modo aprovisionado de DynamoDB) cobran por la capacidad de procesamiento o rendimiento reservada. Si bien esto puede generar costos durante los períodos de poco tráfico, resulta más rentable a una escala sostenida y predecible, en la que los precios por solicitud superarían la capacidad reservada equivalente. Por ejemplo, el modo aprovisionado de DynamoDB le permite ajustar la capacidad de rendimiento de las tablas según sea necesario, lo que puede resultar más económico para cargas de trabajo con patrones de tráfico uniformes.

Los precios híbridos (DynamoDB bajo demanda, API Gateway) ofrecen precios por solicitud que se escalan de forma lineal sin compromiso inicial. Esto permite predecir los costos sin necesidad de pronosticar la capacidad, pero puede resultar caro si se trata de un rendimiento muy alto en comparación con las alternativas aprovisionadas.

Los precios de referencia más ráfagas (Lambda microVMS) cobran por los recursos básicos configurados mientras la microVM está en funcionamiento, con la capacidad de multiplicar por cuatro el valor inicial durante los picos de actividad. Las micromáquinas virtuales suspendidas reducen los costos y, al mismo tiempo, preservan el estado. Este modelo se adapta a las cargas de trabajo interactivas con períodos de inactividad y actividad variables.

Modele sus patrones de tráfico esperados en ciclos diarios, semanales y estacionales. Las cargas de trabajo con índices altos entre picos y promedio favorecen los precios por uso. Steady-state las cargas de trabajo pueden beneficiarse de los precios basados en la capacidad. También puede usar una combinación: por ejemplo, Lambda con pago por uso para el procesamiento variable y el modo aprovisionado de DynamoDB para lograr patrones de acceso a los datos predecibles.

Los marcos de aplicaciones web tradicionales agrupan el enrutamiento, el acceso a los datos, los grupos de conexiones y las integraciones en una única base de código que se implementa y mantiene como una sola unidad. La instalación, la configuración y el mantenimiento de los marcos, los entornos de ejecución y la infraestructura ralentizan la entrega de funciones y correcciones de errores. A medida que las aplicaciones crecen y dependen de más sistemas externos, esta complejidad aumenta el tiempo de preparación para los nuevos desarrolladores, hace que sea más difícil localizar el origen de los errores y retrasa la entrega de nuevas funciones.

Los servicios sin servidor se basan en un espectro de responsabilidades operativas que reducen o eliminan esta sobrecarga. En lugar de administrar todo en un solo paquete, se crean servicios poco conectados en los que cada uno hace bien una cosa con la menor cantidad de dependencias posible.

Administración mínima: Lambda, API Gateway, DynamoDB, Amazon SQS, Amazon SNS y Step Functions no requieren el aprovisionamiento EventBridge, la aplicación de parches ni la planificación de la capacidad de los servidores. No es necesario configurar grupos de conexiones, configurar entornos de ejecución ni administrar la infraestructura de escalado. Puede centrarse por completo en escribir o generar código que resuelva los problemas empresariales.

Administración de contenedores: Fargate requiere crear y mantener imágenes de contenedores, configurar las definiciones de tareas y administrar los procesos de implementación. No administras la infraestructura subyacente, pero eres el propietario del ciclo de vida de los contenedores. Este modelo se adapta a los equipos que necesitan tiempos de ejecución personalizados o que ya tienen cargas de trabajo en contenedores que desean ejecutar sin administrar clústeres.

La infraestructura como complejidad del código: AWS Serverless Application Model minimiza la complejidad de IaC para arquitecturas que solo funcionan sin servidor con sintaxis abreviada y pruebas locales. Kit de desarrollo de la nube de AWS (AWS CDK) y Terraform proporcionan más potencia para aplicaciones complejas a costa de curvas de aprendizaje más pronunciadas y más código que mantener.

Tenga en cuenta las habilidades actuales de su equipo, la cantidad de servicios que debe administrar y los estándares operativos de su organización. Si sus equipos dedican más tiempo al mantenimiento de la infraestructura que a la creación de funciones, optar por una gestión mínima puede liberar recursos para realizar trabajos de mayor valor.

La forma en que un servicio se amplía afecta directamente a la capacidad de respuesta de su aplicación bajo carga. En las arquitecturas sin servidor, el escalado se realiza automáticamente, pero los distintos servicios utilizan distintos mecanismos que afectan a la latencia y al rendimiento.

Per-request el escalado (Lambda) crea un nuevo entorno de ejecución para cada solicitud simultánea. Lambda invoca la función en un entorno de ejecución, que proporciona un entorno de ejecución seguro y aislado que administra los procesos y los recursos necesarios para ejecutar la función. Esto proporciona una respuesta casi instantánea a los picos de tráfico, lo que permite pasar de cero a miles de ejecuciones simultáneas en cuestión de segundos.

Sin embargo, el escalado por solicitud introduce arranques en frío, que son retrasos en la inicialización que se producen cuando Lambda crea un nuevo entorno de ejecución. El factor que más contribuye al tiempo de arranque en frío es el tiempo que Lambda dedica a inicializar la función, lo que incluye cargar el código de la función, iniciar el tiempo de ejecución e inicializar el código de la función. En el caso de las cargas de trabajo de Java, Python y.NET, Lambda SnapStart puede mejorar el rendimiento de inicio hasta 10 veces sin coste adicional al tomar una instantánea del entorno de ejecución inicializado y almacenarla en caché para un acceso de baja latencia. Para otros tiempos de ejecución, puede mitigar los arranques en frío con la simultaneidad aprovisionada, a un costo adicional.

Task-level scaling (Fargate) agrega o elimina instancias de contenedores en función de métricas como el uso de la CPU, el uso de la memoria o el recuento de solicitudes. El escalado añade nuevas tareas en cuestión de segundos a minutos y evita que las solicitudes gestionadas por las tareas existentes se inicien en frío. Una vez que una tarea está en ejecución, permanece activa durante toda su vida útil, lo que proporciona una latencia constante para todas las solicitudes que gestiona.

Throughput-based el escalado (DynamoDB, Kinesis) ajusta la read/write capacidad o el recuento de fragmentos en función de la demanda. El modo bajo demanda de DynamoDB se amplía al instante para adaptarse a los patrones de tráfico de su carga de trabajo. El modo aprovisionado requiere una configuración de escalado automático, pero proporciona un rendimiento predecible con unos costes por solicitud más bajos. Con la arquitectura sin servidor y DynamoDB, los grupos de conexiones no son necesarios para conectar y escalar rápidamente la base de datos. En su lugar, puede ajustar la capacidad de rendimiento de las tablas según sea necesario.

Si tiene requisitos de latencia estrictos (menos de 100 ms, P99), evalúe cuidadosamente el comportamiento de arranque en frío. Lambda con simultaneidad aprovisionada o Fargate con tareas predefinidas proporcionan una SnapStart latencia predecible para las cargas de trabajo de las API. Para las cargas de trabajo de procesamiento de datos en las que la latencia es menos crítica, el escalado estándar de Lambda suele ser suficiente.

Las arquitecturas sin servidor se componen de varios servicios que se comunican a través de eventos. Un evento representa un cambio de estado o una actualización. Por ejemplo, un artículo colocado en un carrito de compras, un archivo subido a un sistema de almacenamiento o un pedido que está a punto de enviarse. La profundidad de la integración nativa entre los servicios afecta a la rapidez con la que puedes crear y a la cantidad de código personalizado que necesitas escribir.

Integración nativa profunda: Lambda se integra con más de 200 AWS servicios como fuentes de eventos. Algunos servicios pueden activar funciones de Lambda directamente. Por ejemplo, cuando se agrega una imagen a un bucket de Amazon S3, se puede activar Lambda para cambiar su tamaño. Algunos servicios no pueden invocar Lambda directamente, pero puede usar una asignación de fuentes de eventos, que es un mecanismo de sondeo que lee una fuente de eventos e invoca una función de Lambda. Puede usar las asignaciones de fuentes de eventos para procesar elementos de una transmisión o cola en: DynamoDB Streams, Amazon Kinesis, Amazon MQ, Amazon MSK, Self-managed y Amazon SQS. Apache Kafka

Flexibilidad en el enrutamiento de eventos: EventBridge proporciona un enrutamiento basado en el contenido con reglas de filtrado, lo que permite que un único bus de eventos dirija los eventos a diferentes destinos en función del contenido del evento. Amazon SNS ofrece una distribución por temas para enviar mensajes a varios suscriptores de forma simultánea. Amazon SQS ofrece un almacenamiento intermedio punto a punto en el que los consumidores sondean activamente los mensajes de la cola. Entre las combinaciones más habituales se incluyen EventBridge enviar los eventos de Amazon SNS a una cola de Amazon SQS como búfer para los consumidores intermedios, extraer los eventos de una transmisión o cola con Pipes y enviar los eventos a Kinesis para su análisis. EventBridge

Patrones de integración de API: API Gateway ofrece dos enfoques de integración. Las integraciones de proxy transfieren directamente toda la información de las solicitudes a una función de Lambda para su procesamiento, que es más sencilla de configurar. Non-proxy Las integraciones (personalizadas) pueden transformar los datos antes de que lleguen a su función y antes de que los datos se devuelvan a los clientes, lo que resulta útil para la migración del código heredado o para mantener el código de las funciones centrado en la lógica empresarial. La API REST proporciona el conjunto de funciones más amplio, que incluye el almacenamiento en caché, la validación de solicitudes y el WAF. La API HTTP proporciona la latencia y el costo más bajos. AWS AppSync ofrece suscripciones en tiempo real y GraphQL. Las URL de las funciones de Lambda proporcionan el punto final HTTPS de función única más sencillo sin necesidad de API Gateway. Para la comunicación bidireccional en la que el servidor necesita enviar datos a los clientes, las API de WebSocket API Gateway proporcionan conexiones persistentes adecuadas para el chat, los paneles de control en tiempo real y los juegos multijugador.

Debido al débil acoplamiento entre los componentes de un sistema basado en eventos, tus funciones informáticas no están al tanto de otras actividades de la arquitectura. Puede escalar los componentes de forma independiente, un servicio puede fallar sin afectar a otros servicios y los eventos se pueden enrutar, almacenar en búfer y proporcionar un registro para la auditoría de manera flexible.

La elección de los servicios sin servidor afecta a la portabilidad de la arquitectura en todos los entornos. Las aplicaciones sin servidor suelen estar compuestas por varios AWS servicios, integrados con código personalizado que se ejecuta en las funciones de Lambda. Si bien Lambda se puede integrar con la mayoría de los AWS servicios, debe considerar el equilibrio entre una integración profunda de la plataforma y la capacidad de ejecutar cargas de trabajo en otros entornos.

AWS Los servicios nativos (Lambda, Step Functions y DynamoDB) proporcionan la integración más profunda y la menor sobrecarga operativa. EventBridge Puede usar cualquiera de estos servicios a través del AWS SDK sin necesidad de instalar aplicaciones o configurar servidores. Dominar el uso de estos servicios mediante código en las funciones de Lambda es un paso importante para producir aplicaciones sin servidor bien diseñadas. Sin embargo, estos servicios se adaptan a API y formatos de eventos AWS específicos, lo que significa que la migración a otra nube requiere una refactorización importante.

Standards-based los servicios (Fargate con Docker contenedores, Amazon MQ conAMQP, Amazon MSK conApache Kafka) se ejecutan en protocolos abiertos o tecnologías de código abierto. Si necesita un tiempo de ejecución personalizado que no proporcione AWS, puede crear e implementar una imagen de contenedor personalizada en Fargate. Amazon MSK proporciona Apache Kafka compatibilidad para equipos que ya tienen experiencia en Kafka. Estas opciones hacen que la portabilidad de las cargas de trabajo sea más factible a costa de una mayor complejidad operativa y una integración menos estrecha con otros servicios. AWS

Marcos de implementación: AWS Serverless Application Model Kit de desarrollo de la nube de AWS (AWS CDK) generan CloudFormation plantillas y son únicamente AWS. AWS Serverless Application Model incluye CloudFormation una sintaxis abreviada que se centra en acelerar el desarrollo sin servidores y ofrece definiciones optimizadas para los recursos de API Gateway, Lambda y Step Functions, además de realizar pruebas Lambda locales mediante la CLI de SAM. Terraformproporciona una definición de infraestructura multinube mediante un único flujo de trabajo para todos los proveedores, pero con menos herramientas específicas para sistemas sin servidor y con capacidades limitadas de pruebas Lambda locales.

Los contenedores y la mensajería basada en estándares pueden mejorar la portabilidad para los requisitos de múltiples nubes. Los servicios nativos sin servidor ofrecen una estrecha integración con otros AWS servicios, lo que puede simplificar el desarrollo cuando la carga de trabajo se basa principalmente en ella. AWS

Debes gestionar las solicitudes HTTP de los clientes web o móviles, procesarlas y devolver las respuestas con una latencia baja.

En el caso de las API web y los backends móviles, API Gateway dirige las solicitudes HTTP a las funciones de Lambda. DynamoDB gestiona el acceso a los datos de baja latencia. La API HTTP proporciona un enrutamiento sencillo a un costo menor, mientras que la API REST añade almacenamiento en caché, validación de solicitudes e integración con WAF. Puede gestionar la autenticación con Amazon Cognito y AWS Serverless Application Model definir estos recursos con una sintaxis abreviada.

Para implementar el procesamiento sincrónico, utilice AWS Lambda para el procesamiento y Amazon API Gateway Gateway para enrutar las solicitudes. Úselo AWS Step Functions para organizar los flujos de trabajo de microservicios. Almacene datos y archivos con DynamoDB y Amazon S3, y autentique a los usuarios con Amazon Amazon Cognito.

Por ejemplo, supongamos que desea crear una aplicación de microservicios que busque datos meteorológicos por código postal. El cliente resuelve el nombre de host a través de Amazon Route 53. La solicitud HTTP GET se dirige a API Gateway, que verifica un token de acceso a través de Amazon Cognito y, a continuación, envía la solicitud a una función de Lambda. La función consulta DynamoDB, personaliza los datos, envía un evento a Amazon SQS para su análisis y otro a Amazon SNS para recibir alertas. Cuando el tráfico se ralentiza, Lambda interrumpe el entorno de ejecución. Solo paga por el uso real de las funciones.

Debe gestionar los eventos que no requieren una respuesta inmediata, con una entrega fiable y la capacidad de absorber los picos de tráfico.

En el caso de las cargas de trabajo que procesan eventos sin una respuesta inmediata, Amazon SQS gestiona el almacenamiento en búfer y la nivelación de carga. Amazon SNS puede distribuir un solo evento para varios suscriptores en paralelo. EventBridge filtra los eventos por contenido y se integra con las aplicaciones SaaS. Step Functions coordina el procesamiento de varios pasos con DynamoDB o Amazon S3 para almacenar los resultados.

Para implementar el procesamiento asincrónico, AWS Lambda utilícelo para el procesamiento y la orquestación. AWS Step Functions Distribuya los mensajes con Amazon Simple Notification Service para distribuirlos en forma horizontal y Amazon Simple Queue Service para obtener una cola duradera. Almacene los resultados en DynamoDB y Amazon S3.

Por ejemplo, cuando un usuario sube una foto a Amazon S3, Amazon S3 publica un evento que invoca una función de Lambda para generar una miniatura. Si también necesita clasificar la imagen y notificárselo al usuario, utilice Amazon SNS para distribuir ese único evento de subida a varias funciones de Lambda que lo procesan en paralelo.

Debe coordinar una secuencia de tareas con la lógica de bifurcación, la gestión de errores, los reintentos y los pasos de aprobación humana.

Los flujos de trabajo estándar gestionan procesos que duran hasta 1 año con una ejecución exacta y un historial de auditoría completo. Para el procesamiento de grandes volúmenes y de corta duración (hasta 5 minutos), los flujos de trabajo rápidos funcionan a un costo por ejecución más bajo.

Step Functions es útil cuando tiene flujos de trabajo con más de un estado, necesita ramificarse o ejecutar tareas en paralelo. El servicio Step Functions actúa como modelo de estado para su aplicación. Los flujos de trabajo estándar se ejecutan exactamente una vez con un historial de ejecución completo y auditable, lo que los hace ideales para el procesamiento de pedidos, los flujos de trabajo de aprobación humana y los procesos de ETL. Los flujos de trabajo rápidos permiten una ejecución al menos una vez a un mayor volumen y menor costo, lo que los hace ideales para la ingestión de datos de IoT, las transformaciones de streaming y el procesamiento de eventos a alta velocidad.

Necesita ingerir, procesar y analizar datos continuos de alta velocidad casi en tiempo real. Lambda y Amazon Kinesis pueden procesar datos de streaming en tiempo real. Los casos de uso incluyen el seguimiento de la actividad, el análisis del flujo de clics, el filtrado de registros, la telemetría del IoT y la medición.

Para la AWS integración nativa, Kinesis Data Streams gestiona la ingesta de transmisiones. Amazon MSK puede ingerir transmisiones de forma compatible. Apache Kafka Lambda o Fargate procesan los datos de las transmisiones, con DynamoDB o Amazon S3 para almacenar los resultados.

Para implementar la transmisión sin servidor, utilice Amazon Kinesis AWS Lambda para recopilar y analizar datos en tiempo real para la computación. Almacene los resultados con DynamoDB y Amazon S3.

Por ejemplo, cuando se escriben elementos en una tabla de DynamoDB, DynamoDB Streams publica eventos que invocan una función de Lambda para generar análisis en tiempo real. Para ingerir un mayor volumen de datos, como la telemetría de IoT desde millones de dispositivos, utilice Kinesis Data Streams para recopilar y almacenar en búfer los datos antes de procesarlos.

Necesita un procesamiento que supere el límite de 15 minutos de Lambda, que requiera conexiones persistentes o que se beneficie de tiempos de ejecución de contenedores personalizados.

Para los flujos de trabajo que superan los 15 minutos pero constan de pasos discretos, las funciones duraderas de Lambda comprueban el progreso y la reanudación en todas las invocaciones. El mapa distribuido de Step Functions puede procesar millones de elementos de Amazon S3, Athena o JSON en paralelo sin aprovisionar el procesamiento. Fargate admite el procesamiento continuo, las conexiones persistentes y un control detallado. CPU/memory

Por ejemplo, una canalización de datos nocturna que procesa 10 millones de objetos de Amazon S3 utiliza el mapa distribuido de Step Functions para paralelizar el trabajo. Un servicio de transcodificación de vídeo que procesa archivos durante más de 30 minutos utiliza Fargate. Un flujo de trabajo de aprobación de préstamos de varios pasos que dura varios días utiliza las funciones duraderas de Lambda para mantener el estado entre las etapas de revisión humana.

Debe ejecutar AI-generated código suministrado por el usuario o en entornos aislados con una fuerte separación de inquilinos y preservación del estado.

Las micromáquinas virtuales de Lambda proporcionan VM-level aislamiento con tecnología Firecracker, con todas las capacidades del sistema operativo, un inicio rápido basado en instantáneas y una vida útil de hasta 8 horas. Cada microVM cuenta con una URL HTTPS dedicada compatible con gRPC y protocolos. HTTP/2 WebSocket Las micromáquinas virtuales se pueden suspender cuando están inactivas para reducir los costos y preservar el estado de la memoria y el disco. A diferencia de Event Functions, las micromáquinas virtuales utilizan un modelo de Dockerfile-based programación, asignan un entorno por sesión y facturan según un modelo básico más un modelo de ráfaga (hasta 4 veces más alto durante los picos de actividad). Cada microVM admite redes de salida configurables para el acceso a la VPC y la conectividad pública a Internet, sin necesidad de balanceadores de carga ni infraestructura de entrada.

Por ejemplo, un asistente de codificación de IA proporciona a cada sesión de usuario su propia microVM para ejecutar el código generado de forma segura. Una plataforma de cuadernos interactivos ejecuta el código de cada alumno en una micromáquina virtual aislada que permanece en estado continuo entre interacciones.

AWS Lambda

AWS Fargate

MicroVM Lambda

API REST de Amazon API Gateway

API HTTP de Amazon API Gateway

AWS AppSync

URL de funciones de Lambda

Amazon Simple Queue Service

Amazon Simple Notification Service

Amazon EventBridge

AWS Step Functions

Amazon DynamoDB

Amazon Simple Storage Service

Amazon Aurora Serverless

AWS Serverless Application Model

Kit de desarrollo de la nube de AWS (AWS CDK)

Terraform

Amazon CloudWatch

AWS X-Ray