AWS App Runner
Servicio totalmente gestionado que construye, despliega y escala automáticamente aplicaciones web y APIs a partir de imágenes de contenedor o código fuente
Descripción general
AWS App Runner es un servicio totalmente gestionado que permite desplegar y operar aplicaciones web y APIs containerizadas sin conocimientos de infraestructura. Basta con especificar una imagen de contenedor de ECR o código fuente de un repositorio GitHub para que el build, despliegue, terminación TLS, balanceo de carga y autoescalado se configuren automáticamente. Cuando el tráfico es cero, las instancias se reducen al mínimo, y se escalan automáticamente cuando aumentan las solicitudes.
Criterios de selección frente a ECS Fargate y Lambda
App Runner, ECSFargate y Lambda permiten ejecutar contenedores o código de forma serverless, pero difieren en el trade-off entre nivel de abstracción y control. App Runner tiene el mayor nivel de abstracción, sin necesidad de considerar configuración de VPC, configuración de balanceador de carga, definiciones de tareas ni service discovery. Es ideal para desplegar rápidamente aplicaciones web o REST APIs. ECS Fargate ofrece mayor control que App Runner, permitiendo configurar detalladamente CPU/memoria del contenedor, contenedores sidecar, montajes de volúmenes y health checks en la definición de tarea. Cuenta con funcionalidades necesarias para operación en producción como service mesh (App Mesh), service discovery (Cloud Map) y despliegues Blue/Green (integración con CodeDeploy). Se elige Fargate cuando hay arquitectura de microservicios o requisitos de red complejos. Lambda se especializa en ejecución de funciones dirigida por eventos, soportando triggers más allá de solicitudes HTTP (eventos S3, mensajes SQS, programación). Sin embargo, tiene un límite de ejecución de 15 minutos y no es adecuado para WebSocket o respuestas streaming. Como guía de selección: App Runner para aplicaciones web simples, Fargate para microservicios serios, Lambda para procesamiento dirigido por eventos.
Pipeline de despliegue y mecanismo de autoescalado
Las fuentes de despliegue de App Runner son dos: imágenes de contenedor de ECR y repositorios de GitHub. Con la fuente ECR, se puede configurar el despliegue automático disparado por un push de imagen, completando el despliegue simplemente haciendo push de la imagen a ECR desde el pipeline CI/CD. Con la fuente GitHub, App Runner construye y despliega automáticamente el código fuente. Soporta runtimes de Python, Node.js, Java, Go, .NET, Ruby y PHP, definiendo los comandos de build e inicio en apprunner.yaml. El autoescalado funciona basándose en el número de solicitudes concurrentes, escalando cuando se supera el máximo de solicitudes concurrentes por instancia (por defecto 100). Configurar el número mínimo de instancias en 1 mantiene siempre una instancia activa incluso sin tráfico, evitando cold starts. No es posible configurar el mínimo en 0, por lo que si se necesita escalar completamente a cero, se debe considerar Lambda. Durante el despliegue, se realiza automáticamente un rolling update, cambiando el tráfico a la nueva versión una vez que pasa el health check.
Conexión VPC y acceso a recursos privados
App Runner tiene por defecto un endpoint público, pero configurando un VPC connector se puede acceder a recursos privados dentro de la VPC (RDS, ElastiCache, DocumentDB, etc.). El VPC connector establece una conexión de red entre el servicio App Runner y la VPC, alcanzando recursos privados a través de las subnets y security groups especificados. Como punto importante, al configurar un VPC connector, toda la comunicación saliente de App Runner pasa por la VPC, requiriendo un NAT Gateway para acceder a internet. Esto genera costos adicionales, por lo que las aplicaciones que llaman APIs externas necesitan una estimación de costos previa. Para el tráfico entrante, la función de endpoint privado de App Runner permite construir servicios internos accesibles solo desde dentro de la VPC. Es adecuado para paneles de administración internos o comunicación entre microservicios que no se desea exponer a internet. La tarificación se basa en el tiempo de vCPU y memoria de las instancias aprovisionadas, con tarifa normal durante el procesamiento activo de solicitudes y una tarifa de espera más baja durante el tiempo idle.