Simplificación del despliegue de contenedores - Despliegue sin configuración con AWS App Runner

Posicionamiento de App Runner y desafíos del despliegue de contenedores

Al desplegar aplicaciones web en contenedores en AWS, tradicionalmente se utilizaban ECS (Elastic Container Service) o EKS (Elastic Kubernetes Service). Sin embargo, estos servicios requieren configurar numerosos recursos como gestión de clústeres, definiciones de tareas, definiciones de servicios, balanceadores de carga, grupos de destino y grupos de seguridad, demandando conocimientos de infraestructura. AWS App Runner, lanzado en 2021, es un servicio de aplicaciones de contenedores completamente gestionado que abstrae completamente esta complejidad. Con solo especificar un repositorio de código fuente (GitHub) o una imagen de contenedor (ECR), App Runner procesa automáticamente la compilación, el despliegue, el escalado, el balanceo de carga y la terminación TLS. Los desarrolladores pueden concentrarse en el código de la aplicación y desplegar en producción sin conocimientos de infraestructura, siempre que tengan un Dockerfile. Cabe señalar que App Runner ha dejado de aceptar nuevos clientes y solo los clientes existentes pueden seguir utilizándolo (a fecha de agosto de 2026); para los nuevos despliegues de contenedores, alternativas como ECS (Express Mode) toman el relevo.

Métodos de despliegue y configuración de origen

App Runner soporta 2 tipos de origen. El primero es el origen de imagen de contenedor, donde se especifica una imagen de ECR (público o privado). También es posible configurar el despliegue automático al detectar un push de imagen a ECR. El segundo es el repositorio de código fuente, donde se conecta un repositorio GitHub y App Runner ejecuta de forma consistente desde la compilación hasta el despliegue. Si se selecciona un runtime gestionado, funciona con solo especificar los comandos de compilación e inicio sin necesidad de buildspec.yml (los runtimes compatibles se tratan en la siguiente sección).

# Definición de servicio App Runner en CloudFormation
Resources:
 AppRunnerService:
 Type: AWS::AppRunner::Service
 Properties:
 ServiceName: my-web-app
 SourceConfiguration:
 AuthenticationConfiguration:
 AccessRoleArn: !GetAtt AppRunnerAccessRole.Arn
 AutoDeploymentsEnabled: true
 ImageRepository:
 ImageIdentifier: !Sub '${AWS::AccountId}.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest'
 ImageRepositoryType: ECR
 ImageConfiguration:
 Port: '8080'
 RuntimeEnvironmentVariables:
 - Name: NODE_ENV
 Value: production
 InstanceConfiguration:
 Cpu: '1024'
 Memory: '2048'

En la configuración de instancia se selecciona una combinación de vCPU (0.25 / 0.5 / 1 / 2 / 4) y memoria (0.5 a 12 GB). A diferencia de ECS Fargate, donde es necesario configurar individualmente la definición de tarea, definición de servicio, ALB, listener y grupo de destino, con una sola definición de recurso se completa el despliegue.

Integracion con GitHub y despliegue desde codigo fuente en la practica

Con el despliegue basado en codigo fuente, se conecta un repositorio GitHub y App Runner construye automaticamente una imagen de contenedor a partir del codigo y la despliega. Hay varios runtimes gestionados disponibles, entre ellos Python, Node.js, Java (Corretto), Go, .NET, PHP y Ruby; al seleccionar uno de ellos, el despliegue se completa sin necesidad de escribir un Dockerfile. Las versiones de runtime se añaden y dejan de recibir soporte periódicamente, por lo que conviene confirmar el estado de compatibilidad actual en la documentación oficial al comenzar. Colocando un archivo apprunner.yaml en la raiz del repositorio, se pueden definir declarativamente los comandos de compilacion, comandos de inicio, versiones de runtime y variables de entorno, permitiendo gestionar la configuracion de infraestructura junto con el codigo bajo control de versiones. La integracion con GitHub ofrece la opcion de despliegue automatico o manual. Con el despliegue automatico habilitado, los push a la rama especificada activan automaticamente compilaciones y despliegues, eliminando la necesidad de construir un pipeline CI/CD separado. Con el despliegue manual, se activan los despliegues explicitamente desde la consola o la API. El costo de compilación automática es de 0.005 USD por minuto, por lo que los repositorios con push frecuentes deben considerar la acumulación de cargos de compilación. Además, se aplica una tarifa fija de 1 USD al mes por cada aplicación con el despliegue automático habilitado (a fecha de agosto de 2026, región de Tokio).

Dominios personalizados y observabilidad

La configuracion de dominios personalizados se completa ingresando el nombre de dominio en la consola y agregando un registro CNAME en el proveedor DNS (Route 53 o un servicio DNS externo). Un certificado ACM (AWS Certificate Manager) se emite y renueva automaticamente, habilitando el acceso HTTPS en el dominio personalizado. Al utilizar conectores VPC se crean ENIs (Elastic Network Interfaces), por lo que las subredes especificadas deben tener suficiente espacio de direcciones IP disponible. En cuanto a observabilidad, habilitar el rastreo con X-Ray permite visualizar trazas distribuidas de latencia y errores de las solicitudes. Los registros de acceso y de aplicacion se envian automaticamente a CloudWatch, con metricas que registran conteos HTTP 2xx/4xx/5xx y tiempos de respuesta. Los health checks se pueden configurar con ruta HTTP o TCP, y las instancias con problemas se reemplazan automaticamente.

Auto-escalado y estructura de costos

App Runner proporciona auto-escalado basado en el número de solicitudes como estándar. En la Auto Scaling Configuration se puede configurar el umbral de solicitudes concurrentes (predeterminado 100), el número mínimo de instancias (1 a 25) y el número máximo de instancias (máximo 25). Cuando el tráfico disminuye, las instancias se reducen automáticamente hasta el número mínimo. Con la función de pausa (Pause), la capacidad de cómputo se reduce a cero y no se genera facturación mientras el servicio está detenido. A continuación se ordena la estructura de precios (a fecha de agosto de 2026, región de Tokio; los importes mensuales se calculan sobre 730 horas). Los precios unitarios son de 0.0809 USD/hora por vCPU y 0.00885 USD/hora por GB de memoria. Las instancias activas se facturan por vCPU y memoria, mientras que las instancias aprovisionadas (en espera) solo se facturan por memoria. Este cargo de memoria en espera constituye el costo mínimo de una configuración que mantiene el número mínimo de instancias en 1 o más para evitar arranques en frío. Por ejemplo, una configuración de 1 vCPU / 2 GB de memoria en funcionamiento continuo cuesta aproximadamente 72.0 USD/mes. La configuración equivalente de ECS Fargate (1 vCPU / 2 GB) en funcionamiento continuo en la misma región de Tokio cuesta aproximadamente 45.0 USD/mes, a lo que se suma el costo del ALB. El ALB tiene una tarifa fija de 0.0243 USD/hora (aproximadamente 17.7 USD/mes) más 0.008 USD/hora por LCU (unidad de capacidad del balanceador de carga), por lo que, suponiendo una carga pequeña que consume 1 LCU de forma constante, el total es de aproximadamente 23.6 USD/mes. Es decir, a plena carga continua el total es de aproximadamente 68.6 USD/mes para Fargate + ALB frente a aproximadamente 72.0 USD/mes para App Runner, de modo que App Runner no resulta más barato si solo se miran los precios unitarios. La ventaja de costo de App Runner aparece cuando el tráfico tiene picos y valles. En un servicio casi sin accesos por la noche o los fines de semana, durante la espera solo se paga la memoria (aproximadamente 12.9 USD/mes para 2 GB) y, en los periodos sin uso, la pausa permite detener por completo la facturación. En cambio, el ALB sigue generando su tarifa fija con independencia del volumen de tráfico. Tome la decisión en función del patrón de uso previsto y no de la comparación de tablas de precios.

Integración con VPC y seguridad

App Runner proporciona un endpoint público por defecto, pero usando un conector VPC se puede acceder a recursos dentro de subredes privadas (RDS, ElastiCache, endpoints VPC de DynamoDB, etc.). El conector VPC se crea especificando subredes y grupos de seguridad, y se asocia al servicio App Runner. Solo el tráfico de salida pasa por la VPC, mientras que el tráfico de entrada sigue siendo recibido por el endpoint gestionado de App Runner. Con la integración de WAF (Web Application Firewall), se puede asociar una WebACL de WAF al endpoint de App Runner para aplicar reglas de seguridad como restricciones de IP y límites de tasa. La integración con Secrets Manager y Systems Manager Parameter Store permite gestionar de forma segura credenciales de bases de datos y claves API, inyectándolas como variables de entorno. También se proporcionan como estándar el control de acceso con IAM, la monitorización de métricas con CloudWatch (número de solicitudes, latencia, códigos de estado HTTP) y la salida de registros de aplicación a CloudWatch Logs.

Diferenciación con ECS/Fargate

App Runner y ECS/Fargate ejecutan cargas de trabajo de contenedores, pero los casos de uso objetivo difieren. App Runner está especializado en aplicaciones web y API basadas en HTTP/HTTPS, con escalado basado en solicitudes como estándar. Por otro lado, ECS/Fargate soporta una amplia gama de cargas de trabajo como procesamiento por lotes, procesos worker, gRPC, WebSocket y patrones sidecar. Los criterios de selección son los siguientes. Se debe elegir App Runner cuando se desea desplegar rápidamente aplicaciones web o API HTTP/HTTPS, cuando se quiere minimizar la gestión de infraestructura, o cuando el equipo tiene poca experiencia en orquestación de contenedores. Se debe elegir ECS/Fargate cuando se necesitan contenedores sidecar o service mesh, cuando se usan protocolos TCP/UDP, cuando se necesita control fino de estrategias de colocación de tareas o proveedores de capacidad, o para cargas de trabajo no HTTP como procesamiento por lotes o workers de cola. EKS se elige cuando se necesita compatibilidad con el ecosistema Kubernetes o cuando se prioriza la portabilidad de cargas de trabajo en una estrategia multi-nube. App Runner tiene un nivel de abstracción más alto que ECS/Fargate: reduce los elementos configurables a cambio de ahorrar el esfuerzo de configuración. Verlo como un trade-off entre flexibilidad de control y simplicidad facilita la elección. Elastic Beanstalk también ofrece despliegue simplificado, pero los recursos subyacentes de EC2 y ALB son visibles y gestionables, ofreciendo mayor personalización a costa de más recursos operativos. Cuando se desea prescindir de Dockerfiles, configuración CI/CD y configuración de VPC/ALB, App Runner es la opción óptima.

Resumen - Directrices de uso de App Runner

AWS App Runner es un servicio para desplegar y operar aplicaciones web en contenedores con configuración mínima. Con solo especificar código fuente o imagen de contenedor, se configuran automáticamente la compilación, el despliegue, TLS, el balanceo de carga y el Auto Scaling. También cuenta con funciones necesarias para operación en producción como acceso a recursos privados mediante conector VPC, refuerzo de seguridad con integración WAF y gestión de credenciales con Secrets Manager. Comparado con ECS/Fargate tiene menor flexibilidad de control, pero como no requiere configuración de ALB ni grupos de destino, reduce considerablemente la carga operativa para aplicaciones web de pequeña a mediana escala. En cuanto al costo, depende del patrón de uso: a plena carga continua se sitúa aproximadamente al mismo nivel que Fargate + ALB, y cuanto más fluctúa el tráfico, más ventajoso resulta App Runner. Como primer paso en el despliegue de contenedores o como medio para publicar prototipos rápidamente, App Runner es una opción sólida.