Una plataforma practica, con IA integrada y pensada para que mejores desarrollando. Se adapta a tu ritmo, te corrige al instante y te muestra tu progreso real.
Correccion magica
Feedback inteligente
Aprende de cada acierto y fallo con explicaciones claras
¿A quién va dirigida esta formación en Serverless Framework?
Pensado para quienes deben dominar Serverless Framework en su día a día
Desarrolladores backend y full stack
Este curso encaja con desarrolladores que necesitan crear APIs, funciones Lambda, procesos asíncronos, integraciones y servicios event-driven sin gestionar servidores tradicionales. Aprenderán a estructurar proyectos Serverless Framework con código, infraestructura, configuración, entornos, pruebas y despliegues reproducibles, evitando servicios improvisados difíciles de mantener.
Equipos DevOps, CloudOps y plataforma
Los perfiles de DevOps y plataforma podrán estandarizar despliegues serverless, controlar permisos, preparar pipelines, gestionar entornos, revisar logs, automatizar validaciones y gobernar configuraciones. El curso les ayuda a convertir Serverless Framework en una pieza fiable dentro del ciclo de entrega cloud, no en una herramienta usada de forma aislada por cada equipo.
Arquitectos cloud y responsables técnicos
Los arquitectos podrán definir patrones de referencia para APIs, eventos, colas, almacenamiento, seguridad, observabilidad y separación de servicios. La formación aporta criterios para decidir cuándo usar Lambda, API Gateway, SQS, SNS, EventBridge, DynamoDB, Step Functions u otros servicios, y cómo mantener una arquitectura sostenible.
Equipos de integración y automatización
Los equipos que conectan sistemas internos, SaaS, ERPs, CRMs, bases de datos, colas o procesos batch encontrarán un enfoque práctico para crear integraciones serverless seguras. El curso trabaja eventos, reintentos, DLQs, idempotencia, trazabilidad, errores, secretos y operación diaria de flujos distribuidos.
Equipos de seguridad y cumplimiento técnico
Los perfiles de seguridad podrán revisar IAM, secretos, permisos por función, exposición de endpoints, cifrado, logs, auditoría, dependencia de plugins, variables de entorno, acceso a datos y separación de entornos. La formación ayuda a aprobar arquitecturas serverless sin perder control sobre riesgos operativos.
Empresas que migran desde servidores o monolitos
Las organizaciones que quieren modernizar aplicaciones encontrarán una guía para identificar casos adecuados, descomponer responsabilidades, evitar migraciones “lift and shift” mal planteadas y crear servicios event-driven que aporten valor real sin replicar errores del entorno anterior.
Proveedor con 16 años de experiencia en formación empresarial
Sobre
En Imagina Formación llevamos más de 16 años ayudando a profesionales y empresas a mejorar sus habilidades con formación práctica y totalmente adaptada a sus necesidades. Durante este tiempo, hemos formado a más de 480.000 personas y colaborado con más de 3.500 empresas, convirtiéndonos en un referente en el sector.
16
Años de liderazgo
+480.000
Alumnos formados en Imagina
¿Tienes dudas?
Resolvemos todas tus dudas sobre nuestra formación en Serverless Framework
Explora las respuestas a las preguntas que guian a nuestra comunidad. Aqui encontraras claridad sobre como funciona todo, desde el acceso hasta los detalles de los cursos. Si buscas respuestas, este es el lugar para comenzar.
Serverless Framework es una herramienta basada en CLI y configuración YAML que ayuda a desplegar código e infraestructura serverless, especialmente en AWS. Permite definir funciones, eventos, recursos, variables y configuración de despliegue desde un proyecto versionado.
Sí. El curso está planteado sobre Serverless Framework v4, incluyendo cambios actuales como autenticación/licencia, nueva sintaxis recomendada de stages, carga automática de `.env`, soporte nativo de TypeScript con esbuild y control de auto-update mediante `frameworkVersion`.
Según la página oficial de precios, la CLI v4+ es gratuita salvo para organizaciones con ingresos anuales superiores a 2 millones de dólares, que requieren suscripción. En empresa conviene revisar este punto con compras, legal o plataforma antes de desplegarlo de forma generalizada.
No. El laboratorio puede plantearse con Node.js o TypeScript por su integración directa con esbuild en v4, pero los patrones de arquitectura, IAM, eventos, seguridad, observabilidad y CI/CD son aplicables también a Python, Java, Go u otros runtimes soportados por AWS Lambda.
Sí. Lambda y API Gateway son bloques centrales. Se trabajan funciones, handlers, memoria, timeout, eventos HTTP, REST API, HTTP API, CORS, authorizers, respuestas, errores, logs y despliegue mediante Serverless Framework.
Sí. El curso cubre SQS, DLQs, SNS, EventBridge, S3 Events, DynamoDB Streams, Kinesis y tareas programadas. El enfoque es diseñar sistemas desacoplados, idempotentes y observables, no solo añadir triggers a funciones.
Sí. IAM granular, permisos por función, secretos, variables, perfiles AWS, roles de despliegue, logs saneados, cifrado, endpoints y control de datos sensibles forman parte esencial del temario.
Sí. Hay un bloque completo de CI/CD con build, testing, package, deploy por stage, autenticación de v4 en pipelines, aprobaciones, rollback, control de cambios y validación de cuenta, región y entorno.
Sí. El curso incluye un bloque específico de migración desde v3 a v4, revisando breaking changes, plugins antiguos, esbuild nativo, `.env`, stages, login/licencia, pipelines y estrategia de validación sin afectar producción.
Sí. Al tratarse de una formación corporativa avanzada en cloud, desarrollo backend, DevOps, automatización, seguridad y competencias digitales, puede plantearse como formación bonificable hasta el 100% a través de FUNDAE, según el crédito disponible y cumpliendo los requisitos administrativos aplicables.
Serverless Framework es una herramienta basada en CLI y configuración YAML que ayuda a desplegar código e infraestructura serverless, especialmente en AWS. Permite definir funciones, eventos, recursos, variables y configuración de despliegue desde un proyecto versionado.
Sí. El curso está planteado sobre Serverless Framework v4, incluyendo cambios actuales como autenticación/licencia, nueva sintaxis recomendada de stages, carga automática de `.env`, soporte nativo de TypeScript con esbuild y control de auto-update mediante `frameworkVersion`.
Según la página oficial de precios, la CLI v4+ es gratuita salvo para organizaciones con ingresos anuales superiores a 2 millones de dólares, que requieren suscripción. En empresa conviene revisar este punto con compras, legal o plataforma antes de desplegarlo de forma generalizada.
No. El laboratorio puede plantearse con Node.js o TypeScript por su integración directa con esbuild en v4, pero los patrones de arquitectura, IAM, eventos, seguridad, observabilidad y CI/CD son aplicables también a Python, Java, Go u otros runtimes soportados por AWS Lambda.
Sí. Lambda y API Gateway son bloques centrales. Se trabajan funciones, handlers, memoria, timeout, eventos HTTP, REST API, HTTP API, CORS, authorizers, respuestas, errores, logs y despliegue mediante Serverless Framework.
Sí. El curso cubre SQS, DLQs, SNS, EventBridge, S3 Events, DynamoDB Streams, Kinesis y tareas programadas. El enfoque es diseñar sistemas desacoplados, idempotentes y observables, no solo añadir triggers a funciones.
Sí. IAM granular, permisos por función, secretos, variables, perfiles AWS, roles de despliegue, logs saneados, cifrado, endpoints y control de datos sensibles forman parte esencial del temario.
Sí. Hay un bloque completo de CI/CD con build, testing, package, deploy por stage, autenticación de v4 en pipelines, aprobaciones, rollback, control de cambios y validación de cuenta, región y entorno.
Sí. El curso incluye un bloque específico de migración desde v3 a v4, revisando breaking changes, plugins antiguos, esbuild nativo, `.env`, stages, login/licencia, pipelines y estrategia de validación sin afectar producción.
Sí. Al tratarse de una formación corporativa avanzada en cloud, desarrollo backend, DevOps, automatización, seguridad y competencias digitales, puede plantearse como formación bonificable hasta el 100% a través de FUNDAE, según el crédito disponible y cumpliendo los requisitos administrativos aplicables.
Comprensión de Serverless Framework como herramienta para definir y desplegar código e infraestructura serverless mediante configuración YAML y CLI.
Diferenciación entre serverless como modelo operativo, AWS Lambda como servicio de ejecución y Serverless Framework como herramienta de despliegue.
Identificación de casos empresariales adecuados: APIs, integraciones, procesamiento asíncrono, tareas programadas, webhooks, ETL ligero y automatización.
Revisión de escenarios donde serverless no encaja bien, como procesos largos, cargas persistentes, baja tolerancia a cold starts o dependencias locales complejas.
Análisis del valor corporativo: menor operación de servidores, despliegues más rápidos, escalado automático, pago por uso y ciclos de entrega más ágiles.
Evaluación de riesgos: costes inesperados, permisos excesivos, observabilidad incompleta, vendor lock-in, despliegues manuales y fragmentación de servicios.
Creación de una arquitectura conceptual con funciones, eventos, recursos AWS, IAM, CloudFormation, logs, métricas y pipelines.
Separación entre servicio serverless, dominio funcional, microservicio, función Lambda y recurso cloud para evitar diseños confusos.
Definición de criterios de naming, tagging, ownership, criticidad, entorno y documentación desde el primer servicio.
Preparación de una hoja de ruta para pasar de prototipos rápidos a aplicaciones serverless gobernadas y operables.
Comprensión de Serverless Framework como herramienta para definir y desplegar código e infraestructura serverless mediante configuración YAML y CLI.
Diferenciación entre serverless como modelo operativo, AWS Lambda como servicio de ejecución y Serverless Framework como herramienta de despliegue.
Identificación de casos empresariales adecuados: APIs, integraciones, procesamiento asíncrono, tareas programadas, webhooks, ETL ligero y automatización.
Revisión de escenarios donde serverless no encaja bien, como procesos largos, cargas persistentes, baja tolerancia a cold starts o dependencias locales complejas.
Análisis del valor corporativo: menor operación de servidores, despliegues más rápidos, escalado automático, pago por uso y ciclos de entrega más ágiles.
Evaluación de riesgos: costes inesperados, permisos excesivos, observabilidad incompleta, vendor lock-in, despliegues manuales y fragmentación de servicios.
Creación de una arquitectura conceptual con funciones, eventos, recursos AWS, IAM, CloudFormation, logs, métricas y pipelines.
Separación entre servicio serverless, dominio funcional, microservicio, función Lambda y recurso cloud para evitar diseños confusos.
Definición de criterios de naming, tagging, ownership, criticidad, entorno y documentación desde el primer servicio.
Preparación de una hoja de ruta para pasar de prototipos rápidos a aplicaciones serverless gobernadas y operables.
Tema 1: Serverless Framework en la arquitectura cloud moderna
Comprensión de Serverless Framework como herramienta para definir y desplegar código e infraestructura serverless mediante configuración YAML y CLI.
Diferenciación entre serverless como modelo operativo, AWS Lambda como servicio de ejecución y Serverless Framework como herramienta de despliegue.
Identificación de casos empresariales adecuados: APIs, integraciones, procesamiento asíncrono, tareas programadas, webhooks, ETL ligero y automatización.
Revisión de escenarios donde serverless no encaja bien, como procesos largos, cargas persistentes, baja tolerancia a cold starts o dependencias locales complejas.
Análisis del valor corporativo: menor operación de servidores, despliegues más rápidos, escalado automático, pago por uso y ciclos de entrega más ágiles.
Evaluación de riesgos: costes inesperados, permisos excesivos, observabilidad incompleta, vendor lock-in, despliegues manuales y fragmentación de servicios.
Creación de una arquitectura conceptual con funciones, eventos, recursos AWS, IAM, CloudFormation, logs, métricas y pipelines.
Separación entre servicio serverless, dominio funcional, microservicio, función Lambda y recurso cloud para evitar diseños confusos.
Definición de criterios de naming, tagging, ownership, criticidad, entorno y documentación desde el primer servicio.
Preparación de una hoja de ruta para pasar de prototipos rápidos a aplicaciones serverless gobernadas y operables.
Tema 2: Serverless Framework v4: instalación, autenticación, licencia y cambios clave
Instalación de Serverless Framework v4 desde npm, validando versión, PATH, acceso a CLI, proyecto base y comandos principales.
Revisión del nuevo modelo de acceso de v4, donde las license keys autentican el uso del Framework y ayudan a cumplir el modelo de licencia.
Comprensión del modelo de pricing actual, donde la CLI v4+ es gratuita salvo para organizaciones con ingresos superiores a 2 millones de dólares anuales, que requieren suscripción.
Configuración de login, organización, licencia o variables de entorno para entornos locales, CI/CD y equipos que no quieren depender de sesiones personales.
Revisión de cambios de v4: carga automática de `.env`, stages recomendados, esbuild integrado, auto-updating y cambios en plugins heredados.
Fijación de `frameworkVersion` para evitar actualizaciones inesperadas en proyectos corporativos y pipelines críticos.
Evaluación de compatibilidad con proyectos v3, plugins de build, variables antiguas, scripts de despliegue y procesos CI/CD existentes.
Preparación de una política interna sobre versión permitida, instalación, actualización, licencia, autenticación y soporte.
Diagnóstico de errores iniciales: login ausente, licencia no configurada, credenciales AWS inválidas, versión no fijada o permisos CloudFormation insuficientes.
Documentación del setup base para que todo el equipo trabaje con la misma versión, comandos y configuración.
Tema 3: Estructura profesional de un proyecto Serverless Framework
Organización de un repositorio con `serverless.yml`, funciones, handlers, capas, tests, scripts, documentación, configuración y pipeline.
Diseño de una estructura de carpetas por dominio, función, evento, infraestructura auxiliar, librerías compartidas y recursos comunes.
Separación entre código de negocio, adaptadores AWS, validaciones, configuración, schemas, tests y utilidades de despliegue.
Definición de nombres de servicio, stage, región, cuenta, stack y funciones para que los recursos sean identificables en AWS.
Creación de convenciones para tags, owners, costes, entorno, criticidad y aplicación, facilitando gobierno y FinOps.
Uso de `.gitignore`, `.env.example`, README, scripts npm y documentación de comandos para reducir fricción de onboarding.
Preparación de plantillas internas para APIs, workers, jobs programados, integraciones y consumidores de cola.
Revisión de anti-patrones: un único servicio gigante, funciones sin dominio, configuración duplicada o infraestructura mezclada sin orden.
Definición de criterios para dividir servicios cuando el tamaño, el dominio, los permisos o el ciclo de despliegue lo justifican.
Creación de una base de proyecto reutilizable que pueda evolucionar sin convertirse en una plantilla rígida.
Tema 4: `serverless.yml`: provider, functions, resources y configuración base
Lectura completa de `serverless.yml` como contrato operativo del servicio: provider, runtime, región, stage, functions, events, resources y custom.
Configuración del provider AWS con runtime, memoria, timeout, arquitectura, región, logs, variables globales y parámetros comunes.
Definición de funciones dentro de `functions`, entendiendo que en AWS cada función configurada se traduce en una Lambda.
Declaración de eventos por función para vincular HTTP, colas, schedules, streams, S3, SNS, EventBridge u otros disparadores.
Uso de `resources` para declarar infraestructura CloudFormation adicional que el Framework no cubre directamente con eventos.
Organización de valores custom para evitar repetición de nombres, ARNs, configuraciones y convenciones de entorno.
Creación de outputs útiles para compartir endpoints, nombres de recursos, colas, tablas o valores que otros servicios necesitan.
Revisión de errores comunes de indentación YAML, referencias incorrectas, nombres duplicados o dependencias mal definidas.
Aplicación de validaciones previas antes del despliegue para detectar configuración inválida antes de tocar AWS.
Documentación del fichero como pieza crítica de infraestructura, no como un archivo auxiliar que solo entiende una persona.
Tema 5: Stages, variables, parámetros y configuración por entorno
Diseño de stages como `dev`, `test`, `staging`, `pre` y `prod`, separando configuración, recursos, seguridad y datos por entorno.
Uso de la sintaxis recomendada de v4 para stages y parámetros, evitando patrones heredados difíciles de mantener.
Carga controlada de variables desde `.env` y `.env.[stage]`, recordando que en v4 estos archivos se leen automáticamente.
Separación de valores no sensibles, secretos, configuración de despliegue, URLs, nombres de recursos y flags de comportamiento.
Uso de variables de AWS SSM Parameter Store y Secrets Manager mediante sintaxis soportada por el Framework.
Diseño de nombres de recursos por stage para evitar colisiones entre entornos y despliegues de equipos diferentes.
Control de regiones y cuentas AWS por entorno para no desplegar accidentalmente pruebas sobre producción.
Preparación de configuración local segura que no requiera copiar secretos reales en ficheros compartidos.
Validación de variables obligatorias antes de desplegar, evitando errores tardíos durante CloudFormation o ejecución Lambda.
Documentación de parámetros por entorno con valor esperado, responsable, sensibilidad, origen y procedimiento de cambio.
Tema 6: AWS Credentials, perfiles, cuentas y despliegue seguro
Configuración de AWS CLI con perfiles dedicados para laboratorio, desarrollo, staging y producción, evitando credenciales personales mezcladas.
Uso de permisos mínimos para despliegue, diferenciando permisos de CloudFormation, IAM, Lambda, API Gateway, logs y recursos específicos.
Revisión de riesgos de usar claves estáticas, perfiles compartidos, usuarios IAM permanentes o credenciales con privilegios excesivos.
Integración con AWS SSO o mecanismos corporativos cuando el equipo trabaja con cuentas centralizadas y MFA.
Preparación de roles de despliegue para CI/CD con trust policy, permisos limitados y separación por cuenta o entorno.
Control de quién puede desplegar a producción, quién puede borrar stacks y quién puede modificar roles IAM.
Gestión de credenciales en pipelines mediante secretos protegidos, OIDC o mecanismos equivalentes en la plataforma CI.
Revisión de logs de CloudTrail para auditar despliegues, cambios de infraestructura, creación de roles y actualizaciones críticas.
Diagnóstico de errores típicos: perfil no encontrado, token caducado, permisos insuficientes, región errónea o cuenta equivocada.
Creación de un procedimiento de despliegue seguro con validación de cuenta, stage, región, diff, aprobación y rollback.
Tema 7: AWS Lambda con Serverless Framework
Configuración de funciones Lambda con handler, runtime, memoria, timeout, arquitectura, environment, layers y eventos asociados.
Diseño de funciones con responsabilidad clara para evitar lambdas enormes, acoplamiento excesivo o handlers que mezclan todo el proceso.
Ajuste de memoria y timeout según carga, latencia, coste, CPU disponible y comportamiento real observado.
Elección de arquitectura `x86_64` o `arm64` según compatibilidad, coste, rendimiento y dependencias nativas.
Gestión de variables de entorno por función, evitando exponer secretos o duplicar configuración innecesaria.
Uso de reserved concurrency cuando una función no debe consumir toda la capacidad disponible o debe proteger sistemas downstream.
Diseño de respuestas y errores controlados para APIs, workers, jobs programados y consumidores de eventos.
Revisión de cold starts, inicialización de clientes AWS, reutilización de conexiones y tamaño del paquete desplegado.
Preparación de logs estructurados con correlation IDs, request IDs, usuario, evento y resultado operativo.
Documentación de cada función con finalidad, trigger, permisos, input, output, errores esperados y owner técnico.
Tema 8: TypeScript, JavaScript y empaquetado con esbuild nativo
Configuración de proyectos TypeScript con Serverless Framework v4, aprovechando el soporte nativo de esbuild incluido en el Framework.
Eliminación o revisión de plugins de build heredados como `serverless-esbuild`, `serverless-webpack` o `serverless-plugin-typescript` cuando ya no son necesarios.
Organización de `tsconfig`, aliases, módulos compartidos, handlers y tipos para mantener claridad en proyectos con varias funciones.
Control del bundle final para reducir tamaño, dependencias innecesarias, ficheros de desarrollo y archivos que no deben desplegarse.
Gestión de source maps cuando se necesita depurar errores en producción con trazas útiles y mantenibles.
Preparación de builds diferenciados por entorno, evitando que configuración local o mocks entren en paquetes productivos.
Revisión de dependencias nativas, librerías grandes, AWS SDK incluido o externo y efectos sobre tamaño y cold start.
Configuración de empaquetado individual por función cuando el servicio contiene lambdas con dependencias muy distintas.
Validación de código antes de desplegar mediante linting, type-checking, tests y revisión del paquete generado.
Creación de una guía interna de empaquetado para que todos los servicios mantengan tiempos de despliegue y ejecución razonables.
Tema 9: API Gateway, HTTP API y diseño de APIs serverless
Creación de endpoints HTTP mediante eventos de Serverless Framework, conectando rutas, métodos y funciones Lambda.
Diferenciación entre REST API de API Gateway v1 y HTTP API v2 según coste, funcionalidades, autenticación, latencia y necesidades reales.
Uso de integración proxy Lambda como patrón habitual, entendiendo que API Gateway pasa el evento completo a la función por defecto.
Diseño de rutas, recursos, métodos, payloads, headers, códigos de estado y errores de forma coherente para consumidores internos o externos.
Configuración de CORS con criterio, evitando abrir orígenes, headers o métodos innecesarios por comodidad durante desarrollo.
Validación de entrada con schemas, DTOs o librerías específicas antes de ejecutar lógica de negocio.
Gestión de errores y respuestas normalizadas para reducir ambigüedad entre frontend, integraciones y soporte.
Preparación de API keys, authorizers, JWT, Cognito u otros mecanismos cuando la API requiere control de acceso.
Configuración de dominios personalizados y stages de API cuando el servicio necesita URL estable por entorno.
Documentación de endpoints con OpenAPI, ejemplos de payload, códigos de error, límites, autenticación y owner.
Tema 10: IAM granular y permisos por función
Diseño de permisos mínimos por función, evitando roles globales con acceso amplio a todos los recursos del servicio.
Separación de permisos para lectura, escritura, publicación, consumo, administración y acceso a secretos.
Uso de ARNs concretos para tablas, colas, topics, buckets, parámetros o recursos que una función realmente necesita.
Revisión de permisos generados por eventos y recursos para entender qué crea CloudFormation y qué depende de configuración explícita.
Preparación de policies por función mediante configuración o plugins aprobados cuando el proyecto lo requiera.
Auditoría de permisos excesivos como `*`, acciones administrativas innecesarias o acceso a recursos de otros entornos.
Aplicación de condiciones IAM cuando hay que limitar acceso por stage, región, cuenta, tag o contexto.
Control de permisos de despliegue frente a permisos de ejecución, que suelen tener necesidades y riesgos diferentes.
Pruebas de permisos fallidos en laboratorio para validar errores, logs, fallback y mensajes operativos.
Documentación de cada permiso con motivo, función, recurso, riesgo y procedimiento de revisión.
Tema 11: DynamoDB con Serverless Framework
Declaración de tablas DynamoDB dentro de `resources`, definiendo claves, billing mode, índices, streams, TTL y nombres por stage.
Diseño de modelos de acceso antes de crear tablas, evitando trasladar un esquema relacional sin adaptar a DynamoDB.
Uso de partición y sort key para soportar consultas reales con coste y rendimiento adecuados.
Creación de GSIs cuando un caso de consulta lo requiere, documentando coste, proyección, cardinalidad y uso esperado.
Configuración de TTL para datos temporales, sesiones, tokens, cachés, eventos o información que debe expirar automáticamente.
Integración con funciones Lambda para crear APIs CRUD, procesos de consulta o actualizaciones event-driven.
Uso de DynamoDB Streams para reaccionar a cambios cuando el servicio necesita procesamiento posterior.
Gestión de errores de condición, concurrencia, throttling, validación y reintentos con respuestas controladas.
Preparación de seeds, datos de prueba y scripts de limpieza para entornos no productivos.
Documentación de la tabla con ownership, patrones de acceso, claves, índices, retención, backup y métricas.
Tema 12: SQS, DLQs e idempotencia en procesos asíncronos
Diseño de colas SQS para desacoplar procesos, absorber picos, proteger sistemas lentos y mejorar resiliencia.
Configuración de eventos SQS sobre funciones Lambda, teniendo en cuenta que el evento enlaza una cola existente y no crea una nueva automáticamente.
Creación de colas estándar o FIFO según orden, deduplicación, throughput, coste y necesidad de consistencia.
Configuración de batch size, visibility timeout, redrive policy, DLQ y límites de reintento para evitar pérdidas o bucles.
Diseño de consumers idempotentes que puedan procesar mensajes duplicados sin crear efectos secundarios incorrectos.
Gestión de poison messages mediante DLQ, análisis posterior, reprocesado controlado y alertas operativas.
Inclusión de correlation IDs para seguir el flujo desde API, evento, cola, worker y recurso final.
Preparación de métricas de cola: mensajes visibles, invisibles, edad del mensaje, errores, DLQ y throughput.
Revisión de errores habituales: visibility timeout menor que timeout Lambda, batch sin manejo parcial o DLQ sin monitorización.
Documentación de contratos de mensaje con schema, versión, origen, destino, reintentos, idempotency key y owner.
Tema 13: SNS, fan-out y comunicación entre servicios
Uso de SNS para publicar eventos a múltiples suscriptores cuando varios procesos necesitan reaccionar a una misma notificación.
Diseño de topics por dominio funcional, evitando topics genéricos que mezclan eventos incompatibles.
Creación de suscripciones a Lambda, SQS, HTTP/S u otros destinos según patrón de integración.
Configuración de DLQ o redrive policy para gestionar entregas fallidas cuando un suscriptor no puede procesar eventos.
Definición de contratos de evento claros, con versión, tipo, origen, timestamp, payload y campos obligatorios.
Aplicación de filtros de suscripción cuando los consumidores solo necesitan una parte de los eventos publicados.
Control de permisos para publicar en topics y recibir eventos desde suscripciones autorizadas.
Diseño de fan-out hacia SQS para desacoplar consumidores y evitar que un fallo bloquee a otros procesos.
Revisión de riesgos de duplicidad, falta de orden, payloads grandes o consumidores no idempotentes.
Documentación de topics, suscriptores, eventos, owners y criterios de evolución del contrato.
Tema 14: EventBridge y arquitecturas event-driven
Uso de EventBridge para conectar eventos de aplicaciones propias, servicios AWS o SaaS con funciones Lambda y otros destinos.
Diseño de event buses por dominio, entorno o frontera organizativa cuando el sistema crece en complejidad.
Creación de reglas con event patterns para enrutar eventos según detalle, fuente, tipo, cuenta, región o atributos del payload.
Definición de eventos de negocio, diferenciándolos de eventos técnicos o logs internos.
Preparación de schemas y versiones para evitar romper consumidores cuando evoluciona el payload.
Uso de scheduled events para tareas recurrentes, jobs de mantenimiento, sincronizaciones, limpieza o reporting programado.
Integración de EventBridge con SQS cuando se necesita durabilidad, desacoplamiento o reintentos controlados.
Control de loops event-driven y eventos recursivos que pueden provocar consumo inesperado o efectos no deseados.
Monitorización de reglas, invocaciones, fallos, targets y dead-letter queues asociadas.
Documentación del mapa de eventos del sistema para que arquitectura y soporte entiendan dependencias reales.
Tema 15: S3 Events, procesamiento de archivos y pipelines ligeros
Configuración de eventos S3 para disparar funciones ante creación, modificación o eliminación de objetos en buckets.
Diseño de flujos de procesamiento de archivos: subida, validación, transformación, extracción, persistencia, notificación y archivo.
Uso de prefijos y sufijos para limitar qué objetos generan eventos, evitando invocaciones innecesarias o bucles.
Control de permisos de bucket, acceso a objetos, cifrado, versionado, lifecycle policies y retención.
Validación de tamaño, extensión, tipo MIME, metadatos, origen y seguridad antes de procesar un archivo.
Preparación de colas intermedias cuando el procesamiento puede ser lento, pesado o sensible a picos de carga.
Gestión de errores y reprocesado cuando un archivo falla, queda incompleto o no cumple el formato esperado.
Creación de logs por archivo con estado, fecha, hash, resultado, error, usuario o proceso origen.
Diseño de políticas para mover archivos entre `incoming`, `processing`, `processed`, `failed` y `archive`.
Documentación del pipeline de ficheros con buckets, eventos, funciones, permisos, retención y alertas.
Tema 16: Streams con DynamoDB y Kinesis
Configuración de eventos de streams para procesar cambios en DynamoDB o registros de Kinesis desde funciones Lambda.
Ajuste de batch size, starting position, batch window, retry attempts, record age y destinos on-failure según comportamiento esperado.
Diseño de procesamiento incremental basado en eventos insert, modify, remove o registros de streaming.
Uso de `ReportBatchItemFailures` cuando se necesita manejar fallos parciales sin reintentar registros ya procesados.
Implementación de idempotencia para evitar duplicidades ante reintentos, fallos parciales o procesamiento fuera de orden.
Gestión de ordering y shard behavior cuando el orden de eventos afecta a consistencia del proceso.
Diseño de DLQ o destinos de fallo para análisis posterior de registros problemáticos.
Monitorización de iterator age, errores, throttling, batches fallidos y latencia de procesamiento.
Revisión de cuándo usar DynamoDB Streams, Kinesis, SQS o EventBridge según tipo de evento y necesidad de control.
Documentación de contrato de stream con origen, consumidor, posición inicial, batch, reintentos, orden y procedimiento de recuperación.
Tema 17: Step Functions, workflows y orquestación serverless
Identificación de procesos que no conviene modelar como una única Lambda: pasos largos, aprobaciones, reintentos, compensaciones o integraciones múltiples.
Diseño de workflows con AWS Step Functions para coordinar tareas, estados, decisiones, paralelismo y errores.
Integración con Serverless Framework mediante recursos CloudFormation o plugins mantenidos, revisando compatibilidad antes de producción.
Separación entre orquestación con Step Functions y coreografía basada en eventos, eligiendo según visibilidad, control y acoplamiento.
Creación de flujos de negocio con estados claros: recibido, validado, enriquecido, procesado, notificado, fallido o compensado.
Gestión de errores por estado con retries, catches, timeouts y rutas de recuperación.
Invocación de Lambdas, servicios AWS o tareas externas desde una máquina de estados.
Monitorización de ejecuciones, estados fallidos, tiempos, payloads y causas raíz.
Control de costes y tamaño de payload cuando el workflow crece en número de pasos o volumen.
Documentación de workflows con diagrama, contrato, responsables, estados, errores, SLAs y criterios de reejecución.
Tema 18: Plugins, extensiones y ecosistema Serverless Framework
Evaluación del ecosistema de plugins de Serverless Framework, recordando que el framework es extensible y cuenta con numerosos plugins comunitarios.
Definición de criterios para aprobar plugins: mantenimiento, compatibilidad v4, comunidad, seguridad, permisos, licencia y alternativa nativa.
Revisión de plugins históricos que pueden dejar de ser necesarios por capacidades nativas de v4, como build TypeScript mediante esbuild.
Instalación controlada de plugins, fijando versiones y documentando por qué se incorporan al proyecto.
Auditoría de dependencias de plugins para detectar vulnerabilidades, paquetes abandonados o permisos excesivos.
Separación entre plugins de desarrollo local, build, despliegue, seguridad, observabilidad, domains, pruning y Step Functions.
Preparación de fallback si un plugin crítico deja de mantenerse o rompe compatibilidad con una nueva versión.
Creación de extensiones propias solo cuando el beneficio justifica mantenimiento interno.
Validación de plugins en CI antes de actualizar versiones o framework.
Documentación del catálogo de plugins aprobados por la empresa con owner, uso permitido y alternativas.
Tema 19: Desarrollo local, testing y feedback rápido
Uso de `serverless dev` en v4 para desarrollo más rápido mediante proxy de eventos desde Lambdas en AWS hacia código local, según el nuevo modo documentado.
Preparación de pruebas unitarias para handlers, servicios de dominio, validadores y adaptadores AWS.
Creación de mocks de eventos API Gateway, SQS, SNS, EventBridge, S3 y DynamoDB Streams para pruebas reproducibles.
Uso de pruebas de integración contra recursos reales en cuentas sandbox cuando el comportamiento AWS no debe simularse.
Diseño de fixtures y payloads versionados para evitar depender de eventos copiados sin contexto.
Validación de errores, timeouts, permisos fallidos, payloads inválidos y datos incompletos.
Pruebas de contrato para APIs y eventos publicados, evitando romper consumidores downstream.
Separación entre tests rápidos de desarrollo, tests de integración, pruebas end-to-end y validaciones previas a producción.
Automatización de pruebas en pipeline antes de ejecutar `serverless deploy`.
Creación de una estrategia de test que equilibre velocidad, realismo, coste y confianza.
Tema 20: CI/CD, despliegues controlados y rollback
Diseño de pipelines para instalar dependencias, validar YAML, ejecutar tests, empaquetar, revisar seguridad y desplegar por stage.
Uso de entornos separados con aprobaciones para producción, evitando que cualquier commit despliegue cambios críticos.
Configuración de licencia, login o license key en CI/CD sin exponer secretos en logs ni depender de sesiones interactivas.
Generación de artefactos versionados para saber qué código y configuración se desplegó en cada release.
Uso de `serverless package` y despliegue posterior cuando se quiere separar build, revisión y aplicación de cambios.
Validación de cuenta, región y stage antes de desplegar para evitar errores de entorno.
Preparación de rollback mediante versiones Lambda, redeploy de commit anterior, CloudFormation rollback y procedimientos documentados.
Control de cambios en infraestructura con revisión de `serverless.yml`, recursos CloudFormation, IAM y variables sensibles.
Creación de changelogs técnicos con funciones afectadas, eventos, recursos, permisos, migraciones y riesgos.
Integración de notificaciones de despliegue con Slack, Teams, email, Jira o herramientas internas de ITSM.
Tema 21: Observabilidad: logs, métricas, traces y Serverless Dashboard
Configuración de logs estructurados en Lambda para facilitar búsqueda, filtrado, correlación e investigación de incidencias.
Uso de CloudWatch Logs, métricas Lambda, API Gateway metrics, SQS metrics, DynamoDB metrics y alarmas por servicio.
Activación de tracing cuando el sistema necesita visibilidad entre funciones, API Gateway, SDKs, servicios AWS y dependencias externas.
Revisión de Serverless Framework Dashboard como opción para seguimiento de despliegues, outputs, secrets, métricas, traces y logs cuando se configura `app`.
Instrumentación con SDK cuando se quiere enviar spans, eventos y errores al Dashboard, siguiendo el modelo documentado.
Creación de correlation IDs desde entrada API o evento para reconstruir flujos distribuidos.
Definición de métricas de negocio además de métricas técnicas: pedido procesado, archivo validado, lead creado o integración completada.
Configuración de alarmas para errores, duración, throttling, DLQ, edad de mensajes, latencia API y costes anómalos.
Preparación de dashboards operativos por servicio, entorno, función, cola, API y dependencia externa.
Documentación de runbooks asociados a alertas para que soporte sepa qué revisar y cuándo escalar.
Tema 22: Seguridad de secretos, variables y datos sensibles
Separación estricta entre configuración no sensible, secretos, credenciales, tokens, claves API y datos operativos.
Uso de AWS SSM Parameter Store y Secrets Manager para valores sensibles referenciables desde Serverless Framework.
Evitación de secretos en `serverless.yml`, `.env` versionado, logs, outputs de CloudFormation o mensajes de error.
Cifrado de datos en reposo y tránsito en S3, DynamoDB, SQS, SNS y otros servicios cuando el caso lo requiere.
Saneamiento de logs para no registrar tokens, emails, teléfonos, documentos, identificadores sensibles o payloads completos.
Rotación de secretos y credenciales con procedimientos de despliegue compatibles con cambios sin caída.
Control de acceso a parámetros por función, rol, stage y entorno, evitando secretos compartidos por todo el servicio.
Revisión de permisos de lectura de secrets en pipelines, cuentas AWS, roles Lambda y usuarios administrativos.
Gestión de datos personales en eventos, colas, logs y DLQs, con criterios de minimización y retención.
Preparación de una checklist de seguridad antes de publicar cualquier endpoint o workflow serverless.
Tema 23: Costes, rendimiento, cold starts y límites
Análisis de coste por invocaciones Lambda, duración, memoria, API Gateway, logs, colas, DynamoDB, transferencias y servicios asociados.
Ajuste de memoria y timeout con mediciones reales, buscando equilibrio entre coste, latencia, CPU y fiabilidad.
Control de cold starts mediante tamaño de bundle, dependencias, inicialización, runtime, arquitectura y conexiones externas.
Configuración de concurrencia reservada o provisionada cuando el negocio exige latencia estable o protección de recursos downstream.
Revisión de límites de payload, timeout, tamaño de paquete, logs, cuotas regionales y límites de servicios integrados.
Prevención de bucles infinitos en arquitecturas event-driven, un anti-patrón reconocido en serverless por su impacto en escalado y coste.
Uso de SQS como buffer cuando un proceso downstream es más lento que el upstream, tal como recomienda AWS para desacoplar cargas.
Optimización de DynamoDB, colas y APIs para evitar costes por consultas ineficientes o reintentos mal diseñados.
Creación de alertas de coste, presupuestos, tags y reporting por servicio, entorno, equipo y producto.
Documentación de supuestos de tráfico, límites aceptables, políticas de escalado y estrategia de contención de consumo.
Tema 24: Multi-servicio, dependencias y Serverless Compose
Evaluación de cuándo dividir una aplicación en varios servicios Serverless Framework por dominio, equipo, permisos o ciclo de despliegue.
Gestión de dependencias entre stacks mediante outputs, imports, parámetros, naming estable o composición controlada.
Uso de Serverless Compose cuando se necesita coordinar varios servicios dentro de una misma aplicación sin mezclar todo en un stack gigante.
Separación entre servicios core, APIs, workers, recursos compartidos, integraciones, jobs y componentes de infraestructura.
Control de despliegue por orden cuando un servicio depende de colas, topics, tablas, authorizers o recursos publicados por otro.
Revisión de riesgos de acoplamiento entre servicios mediante ARNs compartidos, nombres hardcodeados o imports difíciles de migrar.
Creación de contratos entre servicios basados en eventos, APIs, schemas y documentación.
Preparación de entornos preview o temporales sin romper nombres de recursos compartidos.
Documentación de topología multi-servicio para que soporte y arquitectura entiendan dependencias reales.
Definición de criterios para extraer un servicio, fusionarlo, versionarlo o retirarlo.
Tema 25: Migración de Serverless Framework v3 a v4
Inventario de proyectos v3 con versión de Framework, plugins, runtimes, stages, variables, pipelines y dependencias de build.
Evaluación de cambios de v4 que pueden afectar al proyecto: licencia, login, esbuild nativo, `.env` automático, stages y auto-update.
Revisión de plugins de TypeScript, webpack, git variables u otros componentes que pueden requerir retirada, sustitución o configuración explícita.
Fijación de `frameworkVersion` antes de migrar para evitar cambios no controlados durante el proceso.
Preparación de rama de migración, entorno sandbox y pipeline paralelo para validar despliegue sin afectar producción.
Comparación de paquetes generados antes y después de migrar para detectar diferencias de build, dependencias o comportamiento.
Validación de funciones críticas, eventos, IAM, variables, outputs, resources y permisos tras el primer despliegue v4.
Ajuste de CI/CD para autenticar Framework v4 mediante login, organización o license key en entornos no interactivos.
Creación de plan de rollback a v3 cuando todavía sea posible y se detecten incompatibilidades críticas.
Documentación de la migración con cambios aplicados, plugins retirados, decisiones, riesgos y pruebas superadas.
Tema 26: Operación, soporte y troubleshooting en producción
Creación de runbooks para incidencias frecuentes: función con errores, API lenta, cola acumulada, DLQ con mensajes, despliegue fallido o permisos denegados.
Diagnóstico de errores Lambda mediante logs, request ID, stack trace, payload saneado, variables, timeout y consumo de memoria.
Resolución de despliegues fallidos revisando CloudFormation events, recursos en rollback, permisos IAM y nombres de recursos ya existentes.
Análisis de problemas API Gateway: CORS, authorizers, integration errors, mapping, throttling, latencia y respuestas mal formadas.
Investigación de mensajes atascados en SQS o DLQ, determinando si el fallo está en payload, consumidor, permisos o sistema externo.
Revisión de eventos EventBridge no entregados por pattern incorrecto, target deshabilitado, permisos o payload no esperado.
Gestión de errores de secretos, parámetros, región, stage o cuenta AWS durante ejecución y despliegue.
Preparación de herramientas internas de diagnóstico para listar endpoints, colas, funciones, logs, DLQs, métricas y recursos.
Documentación de postmortems con causa raíz, impacto, detección, mitigación, corrección y medidas preventivas.
Creación de una cultura de operación donde cada incidente mejora configuración, tests, alarmas o documentación.
Tema 27: Gobierno, estándares internos y adopción corporativa
Creación de un estándar corporativo para servicios Serverless Framework: estructura, naming, tags, stages, IAM, logs, tests, CI/CD y documentación.
Definición de plantillas aprobadas para APIs, consumers SQS, publishers SNS, jobs programados, pipelines S3 y flujos EventBridge.
Revisión de seguridad previa al despliegue mediante checklist de IAM, secretos, endpoints, logs, datos sensibles y recursos públicos.
Incorporación de FinOps con presupuestos, alertas, tags obligatorios, coste por servicio y revisión periódica de consumo.
Gestión de ownership por servicio, función, cola, tabla, topic, API, pipeline y alerta.
Definición de lifecycle de servicios: experimental, piloto, productivo, crítico, en mantenimiento, deprecado y retirado.
Creación de documentación mínima obligatoria para cada servicio: propósito, arquitectura, comandos, variables, eventos, errores y runbook.
Formación de equipos para evitar shadow serverless, despliegues manuales, cuentas personales y stacks sin propietario.
Establecimiento de revisiones periódicas de versiones del Framework, plugins, runtimes, dependencias y políticas AWS.
Construcción de un catálogo interno de patrones serverless reutilizables y mantenidos por plataforma.
Tema 28: Proyecto final integrador: aplicación serverless empresarial con Serverless Framework
Diseño de una aplicación serverless completa con API pública o interna, cola SQS, tabla DynamoDB, eventos EventBridge y procesamiento asíncrono.
Creación del proyecto con Serverless Framework v4, TypeScript, esbuild nativo, stages, variables, parámetros y estructura profesional.
Implementación de endpoints API Gateway con validación, respuestas normalizadas, errores controlados, CORS y documentación de contrato.
Configuración de IAM granular por función para acceder solo a tabla, cola, topic, parámetro o recurso necesario.
Desarrollo de un flujo asíncrono con SQS, DLQ, idempotencia, reintentos, correlation IDs y logs estructurados.
Incorporación de un evento programado o EventBridge para tareas de mantenimiento, sincronización o procesamiento periódico.
Configuración de secretos mediante SSM Parameter Store o Secrets Manager, evitando credenciales en código o YAML versionado.
Preparación de pipeline CI/CD con tests, build, package, deploy por stage, aprobación para producción y rollback documentado.
Implementación de observabilidad con métricas, logs, alarmas, dashboard, trazabilidad y runbook de incidencias.
Presentación final con arquitectura, decisiones, costes estimados, riesgos, seguridad, documentación, pruebas y plan de evolución.
Una plataforma practica, con IA integrada y pensada para que mejores desarrollando. Se adapta a tu ritmo, te corrige al instante y te muestra tu progreso real.
Correccion magica
Feedback inteligente
Aprende de cada acierto y fallo con explicaciones claras
Comprensión de Serverless Framework como herramienta para definir y desplegar código e infraestructura serverless mediante configuración YAML y CLI.
Diferenciación entre serverless como modelo operativo, AWS Lambda como servicio de ejecución y Serverless Framework como herramienta de despliegue.
Identificación de casos empresariales adecuados: APIs, integraciones, procesamiento asíncrono, tareas programadas, webhooks, ETL ligero y automatización.
Revisión de escenarios donde serverless no encaja bien, como procesos largos, cargas persistentes, baja tolerancia a cold starts o dependencias locales complejas.
Análisis del valor corporativo: menor operación de servidores, despliegues más rápidos, escalado automático, pago por uso y ciclos de entrega más ágiles.
Evaluación de riesgos: costes inesperados, permisos excesivos, observabilidad incompleta, vendor lock-in, despliegues manuales y fragmentación de servicios.
Creación de una arquitectura conceptual con funciones, eventos, recursos AWS, IAM, CloudFormation, logs, métricas y pipelines.
Separación entre servicio serverless, dominio funcional, microservicio, función Lambda y recurso cloud para evitar diseños confusos.
Definición de criterios de naming, tagging, ownership, criticidad, entorno y documentación desde el primer servicio.
Preparación de una hoja de ruta para pasar de prototipos rápidos a aplicaciones serverless gobernadas y operables.
Comprensión de Serverless Framework como herramienta para definir y desplegar código e infraestructura serverless mediante configuración YAML y CLI.
Diferenciación entre serverless como modelo operativo, AWS Lambda como servicio de ejecución y Serverless Framework como herramienta de despliegue.
Identificación de casos empresariales adecuados: APIs, integraciones, procesamiento asíncrono, tareas programadas, webhooks, ETL ligero y automatización.
Revisión de escenarios donde serverless no encaja bien, como procesos largos, cargas persistentes, baja tolerancia a cold starts o dependencias locales complejas.
Análisis del valor corporativo: menor operación de servidores, despliegues más rápidos, escalado automático, pago por uso y ciclos de entrega más ágiles.
Evaluación de riesgos: costes inesperados, permisos excesivos, observabilidad incompleta, vendor lock-in, despliegues manuales y fragmentación de servicios.
Creación de una arquitectura conceptual con funciones, eventos, recursos AWS, IAM, CloudFormation, logs, métricas y pipelines.
Separación entre servicio serverless, dominio funcional, microservicio, función Lambda y recurso cloud para evitar diseños confusos.
Definición de criterios de naming, tagging, ownership, criticidad, entorno y documentación desde el primer servicio.
Preparación de una hoja de ruta para pasar de prototipos rápidos a aplicaciones serverless gobernadas y operables.
Tema 1: Serverless Framework en la arquitectura cloud moderna
Comprensión de Serverless Framework como herramienta para definir y desplegar código e infraestructura serverless mediante configuración YAML y CLI.
Diferenciación entre serverless como modelo operativo, AWS Lambda como servicio de ejecución y Serverless Framework como herramienta de despliegue.
Identificación de casos empresariales adecuados: APIs, integraciones, procesamiento asíncrono, tareas programadas, webhooks, ETL ligero y automatización.
Revisión de escenarios donde serverless no encaja bien, como procesos largos, cargas persistentes, baja tolerancia a cold starts o dependencias locales complejas.
Análisis del valor corporativo: menor operación de servidores, despliegues más rápidos, escalado automático, pago por uso y ciclos de entrega más ágiles.
Evaluación de riesgos: costes inesperados, permisos excesivos, observabilidad incompleta, vendor lock-in, despliegues manuales y fragmentación de servicios.
Creación de una arquitectura conceptual con funciones, eventos, recursos AWS, IAM, CloudFormation, logs, métricas y pipelines.
Separación entre servicio serverless, dominio funcional, microservicio, función Lambda y recurso cloud para evitar diseños confusos.
Definición de criterios de naming, tagging, ownership, criticidad, entorno y documentación desde el primer servicio.
Preparación de una hoja de ruta para pasar de prototipos rápidos a aplicaciones serverless gobernadas y operables.
Tema 2: Serverless Framework v4: instalación, autenticación, licencia y cambios clave
Instalación de Serverless Framework v4 desde npm, validando versión, PATH, acceso a CLI, proyecto base y comandos principales.
Revisión del nuevo modelo de acceso de v4, donde las license keys autentican el uso del Framework y ayudan a cumplir el modelo de licencia.
Comprensión del modelo de pricing actual, donde la CLI v4+ es gratuita salvo para organizaciones con ingresos superiores a 2 millones de dólares anuales, que requieren suscripción.
Configuración de login, organización, licencia o variables de entorno para entornos locales, CI/CD y equipos que no quieren depender de sesiones personales.
Revisión de cambios de v4: carga automática de `.env`, stages recomendados, esbuild integrado, auto-updating y cambios en plugins heredados.
Fijación de `frameworkVersion` para evitar actualizaciones inesperadas en proyectos corporativos y pipelines críticos.
Evaluación de compatibilidad con proyectos v3, plugins de build, variables antiguas, scripts de despliegue y procesos CI/CD existentes.
Preparación de una política interna sobre versión permitida, instalación, actualización, licencia, autenticación y soporte.
Diagnóstico de errores iniciales: login ausente, licencia no configurada, credenciales AWS inválidas, versión no fijada o permisos CloudFormation insuficientes.
Documentación del setup base para que todo el equipo trabaje con la misma versión, comandos y configuración.
Tema 3: Estructura profesional de un proyecto Serverless Framework
Organización de un repositorio con `serverless.yml`, funciones, handlers, capas, tests, scripts, documentación, configuración y pipeline.
Diseño de una estructura de carpetas por dominio, función, evento, infraestructura auxiliar, librerías compartidas y recursos comunes.
Separación entre código de negocio, adaptadores AWS, validaciones, configuración, schemas, tests y utilidades de despliegue.
Definición de nombres de servicio, stage, región, cuenta, stack y funciones para que los recursos sean identificables en AWS.
Creación de convenciones para tags, owners, costes, entorno, criticidad y aplicación, facilitando gobierno y FinOps.
Uso de `.gitignore`, `.env.example`, README, scripts npm y documentación de comandos para reducir fricción de onboarding.
Preparación de plantillas internas para APIs, workers, jobs programados, integraciones y consumidores de cola.
Revisión de anti-patrones: un único servicio gigante, funciones sin dominio, configuración duplicada o infraestructura mezclada sin orden.
Definición de criterios para dividir servicios cuando el tamaño, el dominio, los permisos o el ciclo de despliegue lo justifican.
Creación de una base de proyecto reutilizable que pueda evolucionar sin convertirse en una plantilla rígida.
Tema 4: `serverless.yml`: provider, functions, resources y configuración base
Lectura completa de `serverless.yml` como contrato operativo del servicio: provider, runtime, región, stage, functions, events, resources y custom.
Configuración del provider AWS con runtime, memoria, timeout, arquitectura, región, logs, variables globales y parámetros comunes.
Definición de funciones dentro de `functions`, entendiendo que en AWS cada función configurada se traduce en una Lambda.
Declaración de eventos por función para vincular HTTP, colas, schedules, streams, S3, SNS, EventBridge u otros disparadores.
Uso de `resources` para declarar infraestructura CloudFormation adicional que el Framework no cubre directamente con eventos.
Organización de valores custom para evitar repetición de nombres, ARNs, configuraciones y convenciones de entorno.
Creación de outputs útiles para compartir endpoints, nombres de recursos, colas, tablas o valores que otros servicios necesitan.
Revisión de errores comunes de indentación YAML, referencias incorrectas, nombres duplicados o dependencias mal definidas.
Aplicación de validaciones previas antes del despliegue para detectar configuración inválida antes de tocar AWS.
Documentación del fichero como pieza crítica de infraestructura, no como un archivo auxiliar que solo entiende una persona.
Tema 5: Stages, variables, parámetros y configuración por entorno
Diseño de stages como `dev`, `test`, `staging`, `pre` y `prod`, separando configuración, recursos, seguridad y datos por entorno.
Uso de la sintaxis recomendada de v4 para stages y parámetros, evitando patrones heredados difíciles de mantener.
Carga controlada de variables desde `.env` y `.env.[stage]`, recordando que en v4 estos archivos se leen automáticamente.
Separación de valores no sensibles, secretos, configuración de despliegue, URLs, nombres de recursos y flags de comportamiento.
Uso de variables de AWS SSM Parameter Store y Secrets Manager mediante sintaxis soportada por el Framework.
Diseño de nombres de recursos por stage para evitar colisiones entre entornos y despliegues de equipos diferentes.
Control de regiones y cuentas AWS por entorno para no desplegar accidentalmente pruebas sobre producción.
Preparación de configuración local segura que no requiera copiar secretos reales en ficheros compartidos.
Validación de variables obligatorias antes de desplegar, evitando errores tardíos durante CloudFormation o ejecución Lambda.
Documentación de parámetros por entorno con valor esperado, responsable, sensibilidad, origen y procedimiento de cambio.
Tema 6: AWS Credentials, perfiles, cuentas y despliegue seguro
Configuración de AWS CLI con perfiles dedicados para laboratorio, desarrollo, staging y producción, evitando credenciales personales mezcladas.
Uso de permisos mínimos para despliegue, diferenciando permisos de CloudFormation, IAM, Lambda, API Gateway, logs y recursos específicos.
Revisión de riesgos de usar claves estáticas, perfiles compartidos, usuarios IAM permanentes o credenciales con privilegios excesivos.
Integración con AWS SSO o mecanismos corporativos cuando el equipo trabaja con cuentas centralizadas y MFA.
Preparación de roles de despliegue para CI/CD con trust policy, permisos limitados y separación por cuenta o entorno.
Control de quién puede desplegar a producción, quién puede borrar stacks y quién puede modificar roles IAM.
Gestión de credenciales en pipelines mediante secretos protegidos, OIDC o mecanismos equivalentes en la plataforma CI.
Revisión de logs de CloudTrail para auditar despliegues, cambios de infraestructura, creación de roles y actualizaciones críticas.
Diagnóstico de errores típicos: perfil no encontrado, token caducado, permisos insuficientes, región errónea o cuenta equivocada.
Creación de un procedimiento de despliegue seguro con validación de cuenta, stage, región, diff, aprobación y rollback.
Tema 7: AWS Lambda con Serverless Framework
Configuración de funciones Lambda con handler, runtime, memoria, timeout, arquitectura, environment, layers y eventos asociados.
Diseño de funciones con responsabilidad clara para evitar lambdas enormes, acoplamiento excesivo o handlers que mezclan todo el proceso.
Ajuste de memoria y timeout según carga, latencia, coste, CPU disponible y comportamiento real observado.
Elección de arquitectura `x86_64` o `arm64` según compatibilidad, coste, rendimiento y dependencias nativas.
Gestión de variables de entorno por función, evitando exponer secretos o duplicar configuración innecesaria.
Uso de reserved concurrency cuando una función no debe consumir toda la capacidad disponible o debe proteger sistemas downstream.
Diseño de respuestas y errores controlados para APIs, workers, jobs programados y consumidores de eventos.
Revisión de cold starts, inicialización de clientes AWS, reutilización de conexiones y tamaño del paquete desplegado.
Preparación de logs estructurados con correlation IDs, request IDs, usuario, evento y resultado operativo.
Documentación de cada función con finalidad, trigger, permisos, input, output, errores esperados y owner técnico.
Tema 8: TypeScript, JavaScript y empaquetado con esbuild nativo
Configuración de proyectos TypeScript con Serverless Framework v4, aprovechando el soporte nativo de esbuild incluido en el Framework.
Eliminación o revisión de plugins de build heredados como `serverless-esbuild`, `serverless-webpack` o `serverless-plugin-typescript` cuando ya no son necesarios.
Organización de `tsconfig`, aliases, módulos compartidos, handlers y tipos para mantener claridad en proyectos con varias funciones.
Control del bundle final para reducir tamaño, dependencias innecesarias, ficheros de desarrollo y archivos que no deben desplegarse.
Gestión de source maps cuando se necesita depurar errores en producción con trazas útiles y mantenibles.
Preparación de builds diferenciados por entorno, evitando que configuración local o mocks entren en paquetes productivos.
Revisión de dependencias nativas, librerías grandes, AWS SDK incluido o externo y efectos sobre tamaño y cold start.
Configuración de empaquetado individual por función cuando el servicio contiene lambdas con dependencias muy distintas.
Validación de código antes de desplegar mediante linting, type-checking, tests y revisión del paquete generado.
Creación de una guía interna de empaquetado para que todos los servicios mantengan tiempos de despliegue y ejecución razonables.
Tema 9: API Gateway, HTTP API y diseño de APIs serverless
Creación de endpoints HTTP mediante eventos de Serverless Framework, conectando rutas, métodos y funciones Lambda.
Diferenciación entre REST API de API Gateway v1 y HTTP API v2 según coste, funcionalidades, autenticación, latencia y necesidades reales.
Uso de integración proxy Lambda como patrón habitual, entendiendo que API Gateway pasa el evento completo a la función por defecto.
Diseño de rutas, recursos, métodos, payloads, headers, códigos de estado y errores de forma coherente para consumidores internos o externos.
Configuración de CORS con criterio, evitando abrir orígenes, headers o métodos innecesarios por comodidad durante desarrollo.
Validación de entrada con schemas, DTOs o librerías específicas antes de ejecutar lógica de negocio.
Gestión de errores y respuestas normalizadas para reducir ambigüedad entre frontend, integraciones y soporte.
Preparación de API keys, authorizers, JWT, Cognito u otros mecanismos cuando la API requiere control de acceso.
Configuración de dominios personalizados y stages de API cuando el servicio necesita URL estable por entorno.
Documentación de endpoints con OpenAPI, ejemplos de payload, códigos de error, límites, autenticación y owner.
Tema 10: IAM granular y permisos por función
Diseño de permisos mínimos por función, evitando roles globales con acceso amplio a todos los recursos del servicio.
Separación de permisos para lectura, escritura, publicación, consumo, administración y acceso a secretos.
Uso de ARNs concretos para tablas, colas, topics, buckets, parámetros o recursos que una función realmente necesita.
Revisión de permisos generados por eventos y recursos para entender qué crea CloudFormation y qué depende de configuración explícita.
Preparación de policies por función mediante configuración o plugins aprobados cuando el proyecto lo requiera.
Auditoría de permisos excesivos como `*`, acciones administrativas innecesarias o acceso a recursos de otros entornos.
Aplicación de condiciones IAM cuando hay que limitar acceso por stage, región, cuenta, tag o contexto.
Control de permisos de despliegue frente a permisos de ejecución, que suelen tener necesidades y riesgos diferentes.
Pruebas de permisos fallidos en laboratorio para validar errores, logs, fallback y mensajes operativos.
Documentación de cada permiso con motivo, función, recurso, riesgo y procedimiento de revisión.
Tema 11: DynamoDB con Serverless Framework
Declaración de tablas DynamoDB dentro de `resources`, definiendo claves, billing mode, índices, streams, TTL y nombres por stage.
Diseño de modelos de acceso antes de crear tablas, evitando trasladar un esquema relacional sin adaptar a DynamoDB.
Uso de partición y sort key para soportar consultas reales con coste y rendimiento adecuados.
Creación de GSIs cuando un caso de consulta lo requiere, documentando coste, proyección, cardinalidad y uso esperado.
Configuración de TTL para datos temporales, sesiones, tokens, cachés, eventos o información que debe expirar automáticamente.
Integración con funciones Lambda para crear APIs CRUD, procesos de consulta o actualizaciones event-driven.
Uso de DynamoDB Streams para reaccionar a cambios cuando el servicio necesita procesamiento posterior.
Gestión de errores de condición, concurrencia, throttling, validación y reintentos con respuestas controladas.
Preparación de seeds, datos de prueba y scripts de limpieza para entornos no productivos.
Documentación de la tabla con ownership, patrones de acceso, claves, índices, retención, backup y métricas.
Tema 12: SQS, DLQs e idempotencia en procesos asíncronos
Diseño de colas SQS para desacoplar procesos, absorber picos, proteger sistemas lentos y mejorar resiliencia.
Configuración de eventos SQS sobre funciones Lambda, teniendo en cuenta que el evento enlaza una cola existente y no crea una nueva automáticamente.
Creación de colas estándar o FIFO según orden, deduplicación, throughput, coste y necesidad de consistencia.
Configuración de batch size, visibility timeout, redrive policy, DLQ y límites de reintento para evitar pérdidas o bucles.
Diseño de consumers idempotentes que puedan procesar mensajes duplicados sin crear efectos secundarios incorrectos.
Gestión de poison messages mediante DLQ, análisis posterior, reprocesado controlado y alertas operativas.
Inclusión de correlation IDs para seguir el flujo desde API, evento, cola, worker y recurso final.
Preparación de métricas de cola: mensajes visibles, invisibles, edad del mensaje, errores, DLQ y throughput.
Revisión de errores habituales: visibility timeout menor que timeout Lambda, batch sin manejo parcial o DLQ sin monitorización.
Documentación de contratos de mensaje con schema, versión, origen, destino, reintentos, idempotency key y owner.
Tema 13: SNS, fan-out y comunicación entre servicios
Uso de SNS para publicar eventos a múltiples suscriptores cuando varios procesos necesitan reaccionar a una misma notificación.
Diseño de topics por dominio funcional, evitando topics genéricos que mezclan eventos incompatibles.
Creación de suscripciones a Lambda, SQS, HTTP/S u otros destinos según patrón de integración.
Configuración de DLQ o redrive policy para gestionar entregas fallidas cuando un suscriptor no puede procesar eventos.
Definición de contratos de evento claros, con versión, tipo, origen, timestamp, payload y campos obligatorios.
Aplicación de filtros de suscripción cuando los consumidores solo necesitan una parte de los eventos publicados.
Control de permisos para publicar en topics y recibir eventos desde suscripciones autorizadas.
Diseño de fan-out hacia SQS para desacoplar consumidores y evitar que un fallo bloquee a otros procesos.
Revisión de riesgos de duplicidad, falta de orden, payloads grandes o consumidores no idempotentes.
Documentación de topics, suscriptores, eventos, owners y criterios de evolución del contrato.
Tema 14: EventBridge y arquitecturas event-driven
Uso de EventBridge para conectar eventos de aplicaciones propias, servicios AWS o SaaS con funciones Lambda y otros destinos.
Diseño de event buses por dominio, entorno o frontera organizativa cuando el sistema crece en complejidad.
Creación de reglas con event patterns para enrutar eventos según detalle, fuente, tipo, cuenta, región o atributos del payload.
Definición de eventos de negocio, diferenciándolos de eventos técnicos o logs internos.
Preparación de schemas y versiones para evitar romper consumidores cuando evoluciona el payload.
Uso de scheduled events para tareas recurrentes, jobs de mantenimiento, sincronizaciones, limpieza o reporting programado.
Integración de EventBridge con SQS cuando se necesita durabilidad, desacoplamiento o reintentos controlados.
Control de loops event-driven y eventos recursivos que pueden provocar consumo inesperado o efectos no deseados.
Monitorización de reglas, invocaciones, fallos, targets y dead-letter queues asociadas.
Documentación del mapa de eventos del sistema para que arquitectura y soporte entiendan dependencias reales.
Tema 15: S3 Events, procesamiento de archivos y pipelines ligeros
Configuración de eventos S3 para disparar funciones ante creación, modificación o eliminación de objetos en buckets.
Diseño de flujos de procesamiento de archivos: subida, validación, transformación, extracción, persistencia, notificación y archivo.
Uso de prefijos y sufijos para limitar qué objetos generan eventos, evitando invocaciones innecesarias o bucles.
Control de permisos de bucket, acceso a objetos, cifrado, versionado, lifecycle policies y retención.
Validación de tamaño, extensión, tipo MIME, metadatos, origen y seguridad antes de procesar un archivo.
Preparación de colas intermedias cuando el procesamiento puede ser lento, pesado o sensible a picos de carga.
Gestión de errores y reprocesado cuando un archivo falla, queda incompleto o no cumple el formato esperado.
Creación de logs por archivo con estado, fecha, hash, resultado, error, usuario o proceso origen.
Diseño de políticas para mover archivos entre `incoming`, `processing`, `processed`, `failed` y `archive`.
Documentación del pipeline de ficheros con buckets, eventos, funciones, permisos, retención y alertas.
Tema 16: Streams con DynamoDB y Kinesis
Configuración de eventos de streams para procesar cambios en DynamoDB o registros de Kinesis desde funciones Lambda.
Ajuste de batch size, starting position, batch window, retry attempts, record age y destinos on-failure según comportamiento esperado.
Diseño de procesamiento incremental basado en eventos insert, modify, remove o registros de streaming.
Uso de `ReportBatchItemFailures` cuando se necesita manejar fallos parciales sin reintentar registros ya procesados.
Implementación de idempotencia para evitar duplicidades ante reintentos, fallos parciales o procesamiento fuera de orden.
Gestión de ordering y shard behavior cuando el orden de eventos afecta a consistencia del proceso.
Diseño de DLQ o destinos de fallo para análisis posterior de registros problemáticos.
Monitorización de iterator age, errores, throttling, batches fallidos y latencia de procesamiento.
Revisión de cuándo usar DynamoDB Streams, Kinesis, SQS o EventBridge según tipo de evento y necesidad de control.
Documentación de contrato de stream con origen, consumidor, posición inicial, batch, reintentos, orden y procedimiento de recuperación.
Tema 17: Step Functions, workflows y orquestación serverless
Identificación de procesos que no conviene modelar como una única Lambda: pasos largos, aprobaciones, reintentos, compensaciones o integraciones múltiples.
Diseño de workflows con AWS Step Functions para coordinar tareas, estados, decisiones, paralelismo y errores.
Integración con Serverless Framework mediante recursos CloudFormation o plugins mantenidos, revisando compatibilidad antes de producción.
Separación entre orquestación con Step Functions y coreografía basada en eventos, eligiendo según visibilidad, control y acoplamiento.
Creación de flujos de negocio con estados claros: recibido, validado, enriquecido, procesado, notificado, fallido o compensado.
Gestión de errores por estado con retries, catches, timeouts y rutas de recuperación.
Invocación de Lambdas, servicios AWS o tareas externas desde una máquina de estados.
Monitorización de ejecuciones, estados fallidos, tiempos, payloads y causas raíz.
Control de costes y tamaño de payload cuando el workflow crece en número de pasos o volumen.
Documentación de workflows con diagrama, contrato, responsables, estados, errores, SLAs y criterios de reejecución.
Tema 18: Plugins, extensiones y ecosistema Serverless Framework
Evaluación del ecosistema de plugins de Serverless Framework, recordando que el framework es extensible y cuenta con numerosos plugins comunitarios.
Definición de criterios para aprobar plugins: mantenimiento, compatibilidad v4, comunidad, seguridad, permisos, licencia y alternativa nativa.
Revisión de plugins históricos que pueden dejar de ser necesarios por capacidades nativas de v4, como build TypeScript mediante esbuild.
Instalación controlada de plugins, fijando versiones y documentando por qué se incorporan al proyecto.
Auditoría de dependencias de plugins para detectar vulnerabilidades, paquetes abandonados o permisos excesivos.
Separación entre plugins de desarrollo local, build, despliegue, seguridad, observabilidad, domains, pruning y Step Functions.
Preparación de fallback si un plugin crítico deja de mantenerse o rompe compatibilidad con una nueva versión.
Creación de extensiones propias solo cuando el beneficio justifica mantenimiento interno.
Validación de plugins en CI antes de actualizar versiones o framework.
Documentación del catálogo de plugins aprobados por la empresa con owner, uso permitido y alternativas.
Tema 19: Desarrollo local, testing y feedback rápido
Uso de `serverless dev` en v4 para desarrollo más rápido mediante proxy de eventos desde Lambdas en AWS hacia código local, según el nuevo modo documentado.
Preparación de pruebas unitarias para handlers, servicios de dominio, validadores y adaptadores AWS.
Creación de mocks de eventos API Gateway, SQS, SNS, EventBridge, S3 y DynamoDB Streams para pruebas reproducibles.
Uso de pruebas de integración contra recursos reales en cuentas sandbox cuando el comportamiento AWS no debe simularse.
Diseño de fixtures y payloads versionados para evitar depender de eventos copiados sin contexto.
Validación de errores, timeouts, permisos fallidos, payloads inválidos y datos incompletos.
Pruebas de contrato para APIs y eventos publicados, evitando romper consumidores downstream.
Separación entre tests rápidos de desarrollo, tests de integración, pruebas end-to-end y validaciones previas a producción.
Automatización de pruebas en pipeline antes de ejecutar `serverless deploy`.
Creación de una estrategia de test que equilibre velocidad, realismo, coste y confianza.
Tema 20: CI/CD, despliegues controlados y rollback
Diseño de pipelines para instalar dependencias, validar YAML, ejecutar tests, empaquetar, revisar seguridad y desplegar por stage.
Uso de entornos separados con aprobaciones para producción, evitando que cualquier commit despliegue cambios críticos.
Configuración de licencia, login o license key en CI/CD sin exponer secretos en logs ni depender de sesiones interactivas.
Generación de artefactos versionados para saber qué código y configuración se desplegó en cada release.
Uso de `serverless package` y despliegue posterior cuando se quiere separar build, revisión y aplicación de cambios.
Validación de cuenta, región y stage antes de desplegar para evitar errores de entorno.
Preparación de rollback mediante versiones Lambda, redeploy de commit anterior, CloudFormation rollback y procedimientos documentados.
Control de cambios en infraestructura con revisión de `serverless.yml`, recursos CloudFormation, IAM y variables sensibles.
Creación de changelogs técnicos con funciones afectadas, eventos, recursos, permisos, migraciones y riesgos.
Integración de notificaciones de despliegue con Slack, Teams, email, Jira o herramientas internas de ITSM.
Tema 21: Observabilidad: logs, métricas, traces y Serverless Dashboard
Configuración de logs estructurados en Lambda para facilitar búsqueda, filtrado, correlación e investigación de incidencias.
Uso de CloudWatch Logs, métricas Lambda, API Gateway metrics, SQS metrics, DynamoDB metrics y alarmas por servicio.
Activación de tracing cuando el sistema necesita visibilidad entre funciones, API Gateway, SDKs, servicios AWS y dependencias externas.
Revisión de Serverless Framework Dashboard como opción para seguimiento de despliegues, outputs, secrets, métricas, traces y logs cuando se configura `app`.
Instrumentación con SDK cuando se quiere enviar spans, eventos y errores al Dashboard, siguiendo el modelo documentado.
Creación de correlation IDs desde entrada API o evento para reconstruir flujos distribuidos.
Definición de métricas de negocio además de métricas técnicas: pedido procesado, archivo validado, lead creado o integración completada.
Configuración de alarmas para errores, duración, throttling, DLQ, edad de mensajes, latencia API y costes anómalos.
Preparación de dashboards operativos por servicio, entorno, función, cola, API y dependencia externa.
Documentación de runbooks asociados a alertas para que soporte sepa qué revisar y cuándo escalar.
Tema 22: Seguridad de secretos, variables y datos sensibles
Separación estricta entre configuración no sensible, secretos, credenciales, tokens, claves API y datos operativos.
Uso de AWS SSM Parameter Store y Secrets Manager para valores sensibles referenciables desde Serverless Framework.
Evitación de secretos en `serverless.yml`, `.env` versionado, logs, outputs de CloudFormation o mensajes de error.
Cifrado de datos en reposo y tránsito en S3, DynamoDB, SQS, SNS y otros servicios cuando el caso lo requiere.
Saneamiento de logs para no registrar tokens, emails, teléfonos, documentos, identificadores sensibles o payloads completos.
Rotación de secretos y credenciales con procedimientos de despliegue compatibles con cambios sin caída.
Control de acceso a parámetros por función, rol, stage y entorno, evitando secretos compartidos por todo el servicio.
Revisión de permisos de lectura de secrets en pipelines, cuentas AWS, roles Lambda y usuarios administrativos.
Gestión de datos personales en eventos, colas, logs y DLQs, con criterios de minimización y retención.
Preparación de una checklist de seguridad antes de publicar cualquier endpoint o workflow serverless.
Tema 23: Costes, rendimiento, cold starts y límites
Análisis de coste por invocaciones Lambda, duración, memoria, API Gateway, logs, colas, DynamoDB, transferencias y servicios asociados.
Ajuste de memoria y timeout con mediciones reales, buscando equilibrio entre coste, latencia, CPU y fiabilidad.
Control de cold starts mediante tamaño de bundle, dependencias, inicialización, runtime, arquitectura y conexiones externas.
Configuración de concurrencia reservada o provisionada cuando el negocio exige latencia estable o protección de recursos downstream.
Revisión de límites de payload, timeout, tamaño de paquete, logs, cuotas regionales y límites de servicios integrados.
Prevención de bucles infinitos en arquitecturas event-driven, un anti-patrón reconocido en serverless por su impacto en escalado y coste.
Uso de SQS como buffer cuando un proceso downstream es más lento que el upstream, tal como recomienda AWS para desacoplar cargas.
Optimización de DynamoDB, colas y APIs para evitar costes por consultas ineficientes o reintentos mal diseñados.
Creación de alertas de coste, presupuestos, tags y reporting por servicio, entorno, equipo y producto.
Documentación de supuestos de tráfico, límites aceptables, políticas de escalado y estrategia de contención de consumo.
Tema 24: Multi-servicio, dependencias y Serverless Compose
Evaluación de cuándo dividir una aplicación en varios servicios Serverless Framework por dominio, equipo, permisos o ciclo de despliegue.
Gestión de dependencias entre stacks mediante outputs, imports, parámetros, naming estable o composición controlada.
Uso de Serverless Compose cuando se necesita coordinar varios servicios dentro de una misma aplicación sin mezclar todo en un stack gigante.
Separación entre servicios core, APIs, workers, recursos compartidos, integraciones, jobs y componentes de infraestructura.
Control de despliegue por orden cuando un servicio depende de colas, topics, tablas, authorizers o recursos publicados por otro.
Revisión de riesgos de acoplamiento entre servicios mediante ARNs compartidos, nombres hardcodeados o imports difíciles de migrar.
Creación de contratos entre servicios basados en eventos, APIs, schemas y documentación.
Preparación de entornos preview o temporales sin romper nombres de recursos compartidos.
Documentación de topología multi-servicio para que soporte y arquitectura entiendan dependencias reales.
Definición de criterios para extraer un servicio, fusionarlo, versionarlo o retirarlo.
Tema 25: Migración de Serverless Framework v3 a v4
Inventario de proyectos v3 con versión de Framework, plugins, runtimes, stages, variables, pipelines y dependencias de build.
Evaluación de cambios de v4 que pueden afectar al proyecto: licencia, login, esbuild nativo, `.env` automático, stages y auto-update.
Revisión de plugins de TypeScript, webpack, git variables u otros componentes que pueden requerir retirada, sustitución o configuración explícita.
Fijación de `frameworkVersion` antes de migrar para evitar cambios no controlados durante el proceso.
Preparación de rama de migración, entorno sandbox y pipeline paralelo para validar despliegue sin afectar producción.
Comparación de paquetes generados antes y después de migrar para detectar diferencias de build, dependencias o comportamiento.
Validación de funciones críticas, eventos, IAM, variables, outputs, resources y permisos tras el primer despliegue v4.
Ajuste de CI/CD para autenticar Framework v4 mediante login, organización o license key en entornos no interactivos.
Creación de plan de rollback a v3 cuando todavía sea posible y se detecten incompatibilidades críticas.
Documentación de la migración con cambios aplicados, plugins retirados, decisiones, riesgos y pruebas superadas.
Tema 26: Operación, soporte y troubleshooting en producción
Creación de runbooks para incidencias frecuentes: función con errores, API lenta, cola acumulada, DLQ con mensajes, despliegue fallido o permisos denegados.
Diagnóstico de errores Lambda mediante logs, request ID, stack trace, payload saneado, variables, timeout y consumo de memoria.
Resolución de despliegues fallidos revisando CloudFormation events, recursos en rollback, permisos IAM y nombres de recursos ya existentes.
Análisis de problemas API Gateway: CORS, authorizers, integration errors, mapping, throttling, latencia y respuestas mal formadas.
Investigación de mensajes atascados en SQS o DLQ, determinando si el fallo está en payload, consumidor, permisos o sistema externo.
Revisión de eventos EventBridge no entregados por pattern incorrecto, target deshabilitado, permisos o payload no esperado.
Gestión de errores de secretos, parámetros, región, stage o cuenta AWS durante ejecución y despliegue.
Preparación de herramientas internas de diagnóstico para listar endpoints, colas, funciones, logs, DLQs, métricas y recursos.
Documentación de postmortems con causa raíz, impacto, detección, mitigación, corrección y medidas preventivas.
Creación de una cultura de operación donde cada incidente mejora configuración, tests, alarmas o documentación.
Tema 27: Gobierno, estándares internos y adopción corporativa
Creación de un estándar corporativo para servicios Serverless Framework: estructura, naming, tags, stages, IAM, logs, tests, CI/CD y documentación.
Definición de plantillas aprobadas para APIs, consumers SQS, publishers SNS, jobs programados, pipelines S3 y flujos EventBridge.
Revisión de seguridad previa al despliegue mediante checklist de IAM, secretos, endpoints, logs, datos sensibles y recursos públicos.
Incorporación de FinOps con presupuestos, alertas, tags obligatorios, coste por servicio y revisión periódica de consumo.
Gestión de ownership por servicio, función, cola, tabla, topic, API, pipeline y alerta.
Definición de lifecycle de servicios: experimental, piloto, productivo, crítico, en mantenimiento, deprecado y retirado.
Creación de documentación mínima obligatoria para cada servicio: propósito, arquitectura, comandos, variables, eventos, errores y runbook.
Formación de equipos para evitar shadow serverless, despliegues manuales, cuentas personales y stacks sin propietario.
Establecimiento de revisiones periódicas de versiones del Framework, plugins, runtimes, dependencias y políticas AWS.
Construcción de un catálogo interno de patrones serverless reutilizables y mantenidos por plataforma.
Tema 28: Proyecto final integrador: aplicación serverless empresarial con Serverless Framework
Diseño de una aplicación serverless completa con API pública o interna, cola SQS, tabla DynamoDB, eventos EventBridge y procesamiento asíncrono.
Creación del proyecto con Serverless Framework v4, TypeScript, esbuild nativo, stages, variables, parámetros y estructura profesional.
Implementación de endpoints API Gateway con validación, respuestas normalizadas, errores controlados, CORS y documentación de contrato.
Configuración de IAM granular por función para acceder solo a tabla, cola, topic, parámetro o recurso necesario.
Desarrollo de un flujo asíncrono con SQS, DLQ, idempotencia, reintentos, correlation IDs y logs estructurados.
Incorporación de un evento programado o EventBridge para tareas de mantenimiento, sincronización o procesamiento periódico.
Configuración de secretos mediante SSM Parameter Store o Secrets Manager, evitando credenciales en código o YAML versionado.
Preparación de pipeline CI/CD con tests, build, package, deploy por stage, aprobación para producción y rollback documentado.
Implementación de observabilidad con métricas, logs, alarmas, dashboard, trazabilidad y runbook de incidencias.
Presentación final con arquitectura, decisiones, costes estimados, riesgos, seguridad, documentación, pruebas y plan de evolución.
Aulas Virtuales Personalizadas
¿Te imaginas tener un Temario 100% Personalizado para tu Empresa?
¿A quién va dirigida esta formación en Serverless Framework?
Pensado para quienes deben dominar Serverless Framework en su día a día
Desarrolladores backend y full stack
Este curso encaja con desarrolladores que necesitan crear APIs, funciones Lambda, procesos asíncronos, integraciones y servicios event-driven sin gestionar servidores tradicionales. Aprenderán a estructurar proyectos Serverless Framework con código, infraestructura, configuración, entornos, pruebas y despliegues reproducibles, evitando servicios improvisados difíciles de mantener.
Equipos DevOps, CloudOps y plataforma
Los perfiles de DevOps y plataforma podrán estandarizar despliegues serverless, controlar permisos, preparar pipelines, gestionar entornos, revisar logs, automatizar validaciones y gobernar configuraciones. El curso les ayuda a convertir Serverless Framework en una pieza fiable dentro del ciclo de entrega cloud, no en una herramienta usada de forma aislada por cada equipo.
Arquitectos cloud y responsables técnicos
Los arquitectos podrán definir patrones de referencia para APIs, eventos, colas, almacenamiento, seguridad, observabilidad y separación de servicios. La formación aporta criterios para decidir cuándo usar Lambda, API Gateway, SQS, SNS, EventBridge, DynamoDB, Step Functions u otros servicios, y cómo mantener una arquitectura sostenible.
Equipos de integración y automatización
Los equipos que conectan sistemas internos, SaaS, ERPs, CRMs, bases de datos, colas o procesos batch encontrarán un enfoque práctico para crear integraciones serverless seguras. El curso trabaja eventos, reintentos, DLQs, idempotencia, trazabilidad, errores, secretos y operación diaria de flujos distribuidos.
Equipos de seguridad y cumplimiento técnico
Los perfiles de seguridad podrán revisar IAM, secretos, permisos por función, exposición de endpoints, cifrado, logs, auditoría, dependencia de plugins, variables de entorno, acceso a datos y separación de entornos. La formación ayuda a aprobar arquitecturas serverless sin perder control sobre riesgos operativos.
Empresas que migran desde servidores o monolitos
Las organizaciones que quieren modernizar aplicaciones encontrarán una guía para identificar casos adecuados, descomponer responsabilidades, evitar migraciones “lift and shift” mal planteadas y crear servicios event-driven que aporten valor real sin replicar errores del entorno anterior.
Proveedor con 16 años de experiencia en formación empresarial
Sobre
En Imagina Formación llevamos más de 16 años ayudando a profesionales y empresas a mejorar sus habilidades con formación práctica y totalmente adaptada a sus necesidades. Durante este tiempo, hemos formado a más de 480.000 personas y colaborado con más de 3.500 empresas, convirtiéndonos en un referente en el sector.
16
Años de liderazgo
+480.000
Alumnos formados en Imagina
¿Tienes dudas?
Resolvemos todas tus dudas sobre nuestra formación en Serverless Framework
Explora las respuestas a las preguntas que guian a nuestra comunidad. Aqui encontraras claridad sobre como funciona todo, desde el acceso hasta los detalles de los cursos. Si buscas respuestas, este es el lugar para comenzar.
Serverless Framework es una herramienta basada en CLI y configuración YAML que ayuda a desplegar código e infraestructura serverless, especialmente en AWS. Permite definir funciones, eventos, recursos, variables y configuración de despliegue desde un proyecto versionado.
Sí. El curso está planteado sobre Serverless Framework v4, incluyendo cambios actuales como autenticación/licencia, nueva sintaxis recomendada de stages, carga automática de `.env`, soporte nativo de TypeScript con esbuild y control de auto-update mediante `frameworkVersion`.
Según la página oficial de precios, la CLI v4+ es gratuita salvo para organizaciones con ingresos anuales superiores a 2 millones de dólares, que requieren suscripción. En empresa conviene revisar este punto con compras, legal o plataforma antes de desplegarlo de forma generalizada.
No. El laboratorio puede plantearse con Node.js o TypeScript por su integración directa con esbuild en v4, pero los patrones de arquitectura, IAM, eventos, seguridad, observabilidad y CI/CD son aplicables también a Python, Java, Go u otros runtimes soportados por AWS Lambda.
Sí. Lambda y API Gateway son bloques centrales. Se trabajan funciones, handlers, memoria, timeout, eventos HTTP, REST API, HTTP API, CORS, authorizers, respuestas, errores, logs y despliegue mediante Serverless Framework.
Sí. El curso cubre SQS, DLQs, SNS, EventBridge, S3 Events, DynamoDB Streams, Kinesis y tareas programadas. El enfoque es diseñar sistemas desacoplados, idempotentes y observables, no solo añadir triggers a funciones.
Sí. IAM granular, permisos por función, secretos, variables, perfiles AWS, roles de despliegue, logs saneados, cifrado, endpoints y control de datos sensibles forman parte esencial del temario.
Sí. Hay un bloque completo de CI/CD con build, testing, package, deploy por stage, autenticación de v4 en pipelines, aprobaciones, rollback, control de cambios y validación de cuenta, región y entorno.
Sí. El curso incluye un bloque específico de migración desde v3 a v4, revisando breaking changes, plugins antiguos, esbuild nativo, `.env`, stages, login/licencia, pipelines y estrategia de validación sin afectar producción.
Sí. Al tratarse de una formación corporativa avanzada en cloud, desarrollo backend, DevOps, automatización, seguridad y competencias digitales, puede plantearse como formación bonificable hasta el 100% a través de FUNDAE, según el crédito disponible y cumpliendo los requisitos administrativos aplicables.
Serverless Framework es una herramienta basada en CLI y configuración YAML que ayuda a desplegar código e infraestructura serverless, especialmente en AWS. Permite definir funciones, eventos, recursos, variables y configuración de despliegue desde un proyecto versionado.
Sí. El curso está planteado sobre Serverless Framework v4, incluyendo cambios actuales como autenticación/licencia, nueva sintaxis recomendada de stages, carga automática de `.env`, soporte nativo de TypeScript con esbuild y control de auto-update mediante `frameworkVersion`.
Según la página oficial de precios, la CLI v4+ es gratuita salvo para organizaciones con ingresos anuales superiores a 2 millones de dólares, que requieren suscripción. En empresa conviene revisar este punto con compras, legal o plataforma antes de desplegarlo de forma generalizada.
No. El laboratorio puede plantearse con Node.js o TypeScript por su integración directa con esbuild en v4, pero los patrones de arquitectura, IAM, eventos, seguridad, observabilidad y CI/CD son aplicables también a Python, Java, Go u otros runtimes soportados por AWS Lambda.
Sí. Lambda y API Gateway son bloques centrales. Se trabajan funciones, handlers, memoria, timeout, eventos HTTP, REST API, HTTP API, CORS, authorizers, respuestas, errores, logs y despliegue mediante Serverless Framework.
Sí. El curso cubre SQS, DLQs, SNS, EventBridge, S3 Events, DynamoDB Streams, Kinesis y tareas programadas. El enfoque es diseñar sistemas desacoplados, idempotentes y observables, no solo añadir triggers a funciones.
Sí. IAM granular, permisos por función, secretos, variables, perfiles AWS, roles de despliegue, logs saneados, cifrado, endpoints y control de datos sensibles forman parte esencial del temario.
Sí. Hay un bloque completo de CI/CD con build, testing, package, deploy por stage, autenticación de v4 en pipelines, aprobaciones, rollback, control de cambios y validación de cuenta, región y entorno.
Sí. El curso incluye un bloque específico de migración desde v3 a v4, revisando breaking changes, plugins antiguos, esbuild nativo, `.env`, stages, login/licencia, pipelines y estrategia de validación sin afectar producción.
Sí. Al tratarse de una formación corporativa avanzada en cloud, desarrollo backend, DevOps, automatización, seguridad y competencias digitales, puede plantearse como formación bonificable hasta el 100% a través de FUNDAE, según el crédito disponible y cumpliendo los requisitos administrativos aplicables.