Azure App Service vs AKS para FastAPI: cuál elegir
¿Azure App Service o AKS para tu FastAPI? Si tenés una app monolítica con tráfico chico o mediano y ningún DevOps dedicado, App Service te resuelve el deploy en minutos desde una imagen Docker. Si manejás microservicios, picos de 100K+ requests por día y querés control fino, AKS es el camino (aunque pagás con complejidad y plata).
Azure App Service vs AKS es la decisión de arquitectura que más se traba en los equipos que mueven FastAPI a producción en Azure. App Service es un PaaS gestionado por Microsoft que corre tu contenedor sin que toques infraestructura. AKS (Azure Kubernetes Service) es Kubernetes orquestado: vos manejás pods, nodos y networking. Misma imagen, dos filosofías de operación.
En 30 segundos
- App Service es PaaS: deploy de un contenedor con tres comandos de Azure CLI, sin tocar Kubernetes.
- AKS es Kubernetes gestionado: pods, deployments y HPA para escalar microservicios horizontalmente.
- Costo de entrada: App Service arranca en un plan B1 (~USD 13-15/mes); un cluster AKS útil cuesta bastante más.
- La misma imagen Docker sirve para los dos. Lo que cambia es la configuración: health checks, logs y variables de entorno.
- Regla rápida: menos de 100K requests/día y sin equipo de plataforma, App Service. Microservicios y alta disponibilidad multi-zona, AKS.
¿Cuál es la diferencia fundamental entre Azure App Service y AKS?
La diferencia es quién carga con la operación.
En App Service, Microsoft te gestiona el sistema operativo, el runtime, los parches y el balanceador. Vos subís una imagen Docker, configurás unas variables y listo: la app queda en una URL tipo fastapi-appsvc.azurewebsites.net. Es el modelo PaaS clásico, donde la responsabilidad operativa tuya termina más o menos en el Dockerfile.
En AKS la cosa cambia. Tenés un cluster con nodos, y dentro corren pods que agrupan tus contenedores. Vos definís deployments en YAML, services para exponer tráfico, probes de liveness y readiness, y políticas de escalado. Control total, sí, pero también todo el peso encima: si un pod se cae a las 3 de la mañana, el que diseñó el self-healing fuiste vos. Más contexto en cómo se comparan Microsoft y GitHub.
El artículo original de la guía en dev.to lo resume bien: la misma app FastAPI dockerizada puede ir a cualquiera de los dos, pero el “cuánto te metés con la infra” es lo que decide.
¿Cuándo elegir Azure App Service para FastAPI?
App Service brilla cuando tu app es relativamente simple y no querés convertirte en SRE para publicar un endpoint.
Casos donde es la opción obvia:
- Apps monolíticas o de pocos servicios: una API FastAPI que hace su laburo sin necesidad de orquestar diez contenedores.
- Escala chica a media: hasta unos 100K requests por día se manejan tranquilos con autoscaling por métrica.
- Equipos sin DevOps dedicado: si nadie quiere mantener un cluster, esto te ahorra el dolor.
- MVPs y validaciones: ponés algo en producción hoy y lo iterás mañana.
Sobre precios, los planes Linux arrancan accesibles. El B1 ronda los USD 13-15 por mes, y por encima están los SKUs B2 y B3 del tier Basic para más recursos. El autoscaling reacciona a CPU, memoria o cola de HTTP, así que en un pico la plataforma suma instancias sola. ¿Lo mejor? No tenés que pensar en nodos.
¿Cuándo elegir AKS para FastAPI?
AKS es para cuando App Service te queda chico de verdad.
Ponele que tu plataforma creció, partiste el monolito en seis servicios, cada uno escala distinto, y necesitás que un equipo entero despliegue sin pisarse. Ahí Kubernetes deja de ser sobre-ingeniería y empieza a tener sentido.
- Microservicios: cada servicio con su deployment, su ciclo de vida y su escalado independiente.
- Escala muy alta: 100K+ requests/día con escalado horizontal vía HPA (Horizontal Pod Autoscaler).
- Alta disponibilidad multi-zona: nodos repartidos en zonas para sobrevivir a una caída regional.
- Networking granular: service mesh tipo Istio, políticas de red, control fino de tráfico interno.
El costo es el peaje. Un cluster mínimamente serio cuesta bastante más solo en compute, y eso sin contar el laburo humano de mantenerlo. Si no tenés a alguien que sepa de Kubernetes, ese número se multiplica en horas perdidas. Cubrimos ese tema en detalle en riesgos de seguridad en el ecosistema.
¿Cómo crear y desplegar FastAPI en App Service paso a paso?
Son cuatro pasos con Azure CLI. Acá los concretos, basados en los comandos de la guía:
- Crear el resource group:
az group create --name fastapi-rg --location eastus. Te devuelve unprovisioningState: Succeeded. - Crear el App Service plan Linux:
az appservice plan create --name fastapi-plan --resource-group fastapi-rg --sku B1 --is-linux true. Acá elegís el SKU (B1 para empezar). - Crear la webapp con tu imagen:
az webapp create --resource-group fastapi-rg --plan fastapi-plan --name fastapi-appsvc --deployment-container-image-name myregistry.azurecr.io/fastapi:latest. Queda en estadoRunningcon hostnamefastapi-appsvc.azurewebsites.net. - Configurar credenciales del Container Registry: con
az webapp config container setapuntando a tu registry privado (URL, usuario y password).
Y ya está sirviendo. Si tu Dockerfile instala dependencias del sistema, acordate de limpiar el cache de apt en la misma capa (rm -rf /var/lib/apt/lists/*) para no inflar la imagen.
¿Cómo deployar FastAPI en AKS?
Acá entran los conceptos de Kubernetes, y son varios.
El flujo, a grandes rasgos: creás el cluster AKS, configurás kubectl para hablar con él, escribís un YAML de deployment que describe tu pod de FastAPI, lo aplicás con kubectl apply -f deployment.yaml, y exponés el tráfico con un service de tipo LoadBalancer que Azure te asigna como IP pública. Después sumás un HPA para que escale por CPU, y probes de readiness y liveness para que Kubernetes sepa cuándo tu app está viva y lista.
Comparado con los cuatro comandos de App Service, esto es otra liga. Más control sobre cada detalle, sí, pero también una curva de aprendizaje que no se aprende en una tarde. ¿Vale la pena? Depende de si tu escala lo justifica. Complementá con orquestación del pipeline de CI/CD.
¿Cómo comparar costos reales entre App Service y AKS?
Los dos modelos cobran distinto. App Service factura el plan de compute más almacenamiento y egress. AKS suma horas de VM de cada nodo, managed disks, el load balancer y el egress. Acá la tabla con un escenario típico:
| Aspecto | Azure App Service | AKS |
|---|---|---|
| Modelo | PaaS gestionado | Kubernetes orquestado |
| Costo de entrada | ~USD 13-15/mes (B1) | Mayor (cluster con varios nodos) |
| Ejemplo con escala | B1 escalado a varias instancias | Cluster con varios nodos |
| Escalado | Autoscale por CPU/memoria/cola HTTP | HPA por métricas, granular |
| Operación | Mínima, la maneja Azure | Compleja, la manejás vos |
| Caso ideal | Monolito, <100K req/día | Microservicios, 100K+ req/día |
| Curva de aprendizaje | Baja | Alta |

Si recién arrancás y manejás tu propio hosting o infraestructura web para otros proyectos, una opción local como donweb.com te cubre dominios y servidores en Argentina sin pelearte con la facturación en dólares.
¿Puedo usar la misma imagen Docker en App Service y AKS?
Sí. La imagen Docker es agnóstica y corre igual en los dos.
Lo que cambia es la periferia. En App Service los logs salen por stdout y los levantás desde el portal o Application Insights; en AKS tenés probes de readiness y liveness que App Service no te pide. Las variables de entorno se configuran distinto, los puertos hay que alinearlos con lo que cada plataforma espera, y el shutdown graceful importa más en Kubernetes, donde los pods se reciclan seguido.
Buenas prácticas que aplican a los dos: usá los lifespan events de FastAPI para abrir y cerrar conexiones limpio, definí timeouts razonables, y exponé un endpoint de health para que la plataforma sepa si tu app respira.
Errores comunes al deployar FastAPI en Azure
Estos son los que más se repiten y cómo evitarlos:
- No configurar las credenciales del Container Registry: la webapp se crea pero no puede bajar la imagen privada. Corré
az webapp config container setcon URL, usuario y password del registry. - Puertos que no coinciden: tu Dockerfile expone uno y la plataforma espera otro. Alineá el puerto del contenedor con lo que App Service o el service de AKS escuchan.
- Health checks con timeout muy corto: si tu app tarda en arrancar y el timeout es bajo, la plataforma la mata. Dale margen suficiente en la configuración de startup.
- Olvidar el DNS personalizado: en AKS el LoadBalancer te da una IP, y sin un registro DNS apuntando a esa IP tu dominio no resuelve.
- Variables de entorno faltantes en producción: funciona en local con tu
.envy explota en Azure. Cargá las settings en la configuración de la app. - Cero monitoreo: sin Application Insights ni logs centralizados, debuggear un 500 en producción es a ciegas.
Preguntas Frecuentes
¿Cuál es la diferencia entre Azure App Service y AKS?
App Service es un PaaS que corre tu contenedor sin que gestiones infraestructura, ideal para apps simples. AKS es Kubernetes gestionado, donde manejás pods, nodos y networking, pensado para microservicios y escala alta. La diferencia central es cuánta operación cargás vos. En entre estas dos herramientas de CI profundizamos sobre esto.
¿Cuándo debo usar App Service vs AKS para FastAPI?
Usá App Service si tenés una app monolítica, menos de 100K requests por día y ningún equipo de plataforma. Pasate a AKS cuando manejás microservicios, picos de 100K+ requests diarios o necesitás alta disponibilidad multi-zona con control granular.
¿Cuánto cuesta deployar en App Service vs AKS?
App Service arranca en un plan B1 de ~USD 13-15/mes y sube según las instancias que sumes con autoscale. Un cluster AKS cuesta bastante más, porque pagás los nodos del cluster, el load balancer y los discos, sin contar la operación.
¿Necesito Kubernetes para mi aplicación FastAPI?
No, en la mayoría de los casos no. Una app FastAPI monolítica o de pocos servicios corre perfecto en App Service sin tocar Kubernetes. Kubernetes recién se justifica cuando tenés varios microservicios, escala muy alta o requisitos finos de networking y disponibilidad.
¿Cómo escalar FastAPI horizontalmente en Azure?
En App Service activás el autoscaling por métrica (CPU, memoria o cola HTTP) y la plataforma suma instancias sola. En AKS usás el Horizontal Pod Autoscaler (HPA), que crea más pods según las métricas que definas en el deployment.
Conclusión
La decisión Azure App Service vs AKS no es sobre cuál es “mejor”, es sobre qué tan grande es tu problema. Para la mayoría de los proyectos FastAPI (un monolito, tráfico razonable, un equipo que prefiere construir features antes que mantener clusters), App Service gana por goleada: deploy en minutos, costo de entrada bajo, cero Kubernetes.
AKS entra cuando tu arquitectura ya empujó a microservicios, la escala pasó los 100K requests diarios y tenés a alguien que sabe operar Kubernetes. Si dudás, arrancá en App Service. Migrar después es relativamente barato porque la imagen Docker es la misma, y te ahorrás meses peleando con YAML antes de necesitarlo. Probá el camino simple primero y complejizá solo cuando los números te lo pidan.


![Kelsey Hightower: Kubernetes and retiring at the top [video] - ilustracion](https://donweb.news/wp-content/uploads/2026/06/kelsey-hightower-retiro-google-kubernetes-hero-768x429.jpg)



![Open System Firmware: Experiences deploying LinuxBoot, coreboot at Google (2021) [video] - ilustracion](https://donweb.news/wp-content/uploads/2026/06/linuxboot-coreboot-firmware-abierto-google-hero-768x432.jpg)