AZ-104
Deep Dive
PaaS de Microsoft para hospedar web apps, APIs REST y backends móviles. El AZ-104 evalúa App Service Plans, deployment slots, escalado y networking.
Contenido
Azure App Service es una plataforma PaaS HTTP totalmente gestionada. Hospeda web apps, APIs REST, WebJobs y aplicaciones móviles sin gestionar servidores ni OS. Soporta .NET, Node.js, Python, Java, PHP, Ruby y contenedores Docker.
App Service gestiona automáticamente: parches del OS, escalado de infraestructura, balanceo de carga, certificados TLS y alta disponibilidad básica.
Web App
Aplicaciones web HTTP/HTTPS. Deploys de código o contenedor. Múltiples runtimes. Ideal para sitios web, portales, aplicaciones empresariales.
API App
APIs REST. Swagger/OpenAPI integrado. CORS configurado. Igual que Web App técnicamente pero con herramientas de API integradas.
WebJob
Tareas en background que corren en el mismo plan que una Web App. Pueden ser continuas o programadas (cron). Alternativa ligera a Azure Functions.
El App Service Plan define los recursos de cómputo subyacentes (región, vCPUs, RAM, número de instancias). Las apps dentro de un plan comparten los mismos recursos. Múltiples apps en un plan = economía de escala.
Plan vs App — la relación clave
App Service Plan
La "granja de servidores" — define región, SO (Windows/Linux), tier y número de instancias. Se factura por el plan, no por las apps.
App Service (la app)
La aplicación que vive dentro del plan. Un plan puede tener múltiples apps. Todas comparten los mismos recursos de cómputo del plan.
Importante: si el plan tiene 2 instancias y hay 3 apps, cada instancia ejecuta las 3 apps. No es que cada app tenga 2 instancias propias.
Restricciones de combinación
Windows vs Linux
Un plan es Windows O Linux — no puedes mezclar apps de ambos OS en el mismo plan.
Free/Shared vs Paid
En tiers Free y Shared las apps comparten recursos con apps de OTROS clientes (multitenancy). En Basic y superior: VMs dedicadas solo para ti.
Isolated (ASE)
App Service Environment: infraestructura dedicada dentro de tu VNet. Máximo aislamiento, mayor costo. Para compliance y apps que requieren VNet privada.
| Tier | SKUs | Instancias | Features clave | SLA |
|---|---|---|---|---|
| Free | F1 | 1 (compartida) | No custom domain, no SSL, 60 min CPU/día | Sin SLA |
| Shared | D1 | 1 (compartida) | Custom domain, no SSL | Sin SLA |
| Basic | B1, B2, B3 | Hasta 3 dedicadas | Custom domain + SSL, manual scale, no autoscale, no slots | 99.95% |
| Standard | S1, S2, S3 | Hasta 10 dedicadas | Autoscale, 5 deployment slots, custom domains + SSL ilimitados, backups | 99.95% |
| Premium v2/v3 | P1v3, P2v3, P3v3 | Hasta 30 dedicadas | Todo Standard + más RAM/CPU, 20 slots, VNet integration, Private Endpoints | 99.95% |
| Isolated v2 (ASE) | I1v2, I2v2, I3v2 | Hasta 100 | Todo Premium + VNet dedicada, inbound/outbound en VNet, sin IP pública obligatoria | 99.95% |
Para el examen
→ Deployment Slots: Basic no tiene. Standard = 5. Premium = 20.
→ Autoscale: solo desde Standard y superior.
→ VNet Integration: disponible en Standard y superior (salida a VNet). Inbound requiere Isolated o Private Endpoint.
→ Custom domains + SSL: desde Basic.
GitHub Actions / Azure DevOps
CI/CD automatizado. Cada push/PR puede disparar build + deploy a App Service. Azure provee workflows de GitHub Actions pre-configurados.
Recomendado para producción. Deployment slots + swap para zero-downtime.
ZIP Deploy / War Deploy
Subir un archivo ZIP o WAR directamente via REST API o az webapp deploy. Simple, sin configurar pipeline CI/CD.
Útil para demos, POCs o despliegues rápidos desde scripts.
Container (Docker)
Deploy de imagen Docker desde Docker Hub, Azure Container Registry o GitHub Container Registry. La app corre dentro del contenedor.
Para apps con dependencias específicas del OS o stack poco convencional.
FTP / FTPS
Subir archivos directamente via FTP/FTPS. Credenciales de deployment en Portal → Deployment Center. No recomendado para producción.
Legacy. Solo usar si no hay otra opción.
Un Deployment Slot es una instancia viva adicional de la app con su propia URL (app-staging.azurewebsites.net). El swap intercambia el tráfico de producción al slot (y viceversa) de forma atómica — zero downtime.
Flujo de deployment con slots
Configuración Sticky vs No-Sticky
Cada slot tiene su propia configuración (app settings, connection strings). Al hacer swap, la configuración se intercambia con el código — a menos que se marque como "Slot Setting" (sticky).
• Sticky (slot setting): queda en el slot aunque hagas swap. Ej: string de conexión de staging a la BD de staging.
• No-sticky: se intercambia con el código. Ej: feature flags, variables de configuración.
Traffic Routing — canary deployment
Puedes dirigir un % del tráfico de producción a un slot. Ej: 10% al slot "v2" para probar con usuarios reales antes del swap completo. Se configura en Portal → Deployment Slots → Traffic %.
Scale Up (vertical) vs Scale Out (horizontal)
Scale Up (vertical)
Cambiar a un plan más grande (más vCPUs/RAM). Ej: S1 → S3. Implica mover la app a una VM más grande — puede haber breve interrupción.
Scale Out (horizontal)
Añadir más instancias del mismo tamaño. La carga se distribuye entre instancias via el load balancer integrado. No hay interrupción.
Autoscale (Standard+)
Escala automáticamente el número de instancias según reglas métricas o programación horaria.
Metric-based
Scale out cuando CPU media > 70% por 10 min. Scale in cuando CPU < 30% por 15 min. Métricas: CPU, memoria, peticiones, latencia, cola de mensajes.
Schedule-based
Aumentar instancias los lunes a las 8:00 AM, reducir los viernes a las 7:00 PM. Para cargas predecibles (horario laboral).
Combinado
Reglas base de programación + ajuste por métricas sobre la base programada.
Mínimo y máximo de instancias siempre configurables. El autoscale nunca supera el máximo definido.
| Feature | Dirección del tráfico | Tier mínimo | Para qué sirve |
|---|---|---|---|
| VNet Integration | Salida (outbound) desde la app | Standard / Basic (regional) | Que la app acceda a recursos en VNet: DBs privadas, VMs, servicios internos |
| Private Endpoint | Entrada (inbound) a la app | Standard+ | Que la app solo sea accesible desde dentro de la VNet (sin IP pública) |
| App Service Environment (ASE) | Entrada y salida en VNet | Isolated v2 | Aislamiento total: la app vive dentro de la VNet. Sin IP pública obligatoria. |
| Access Restrictions | Entrada (inbound) | Todos | Whitelist de IPs o rangos CIDR. Bloquear todo excepto IPs de confianza o Application Gateway. |
| Hybrid Connections | Salida (outbound) | Basic+ | Acceder a recursos on-premises sin VPN ni ExpressRoute (relay via Service Bus) |
App Settings (variables de entorno)
Las app settings se inyectan como variables de entorno en el proceso de la app. Sobrescriben cualquier configuración en el archivo de config de la app (web.config, appsettings.json).
• Portal → App Service → Configuration → Application settings
• Por defecto visibles en texto plano para quienes tienen acceso al portal
• Key Vault Reference: en lugar del valor, poner @Microsoft.KeyVault(SecretUri=...) — la app lee el secreto desde Key Vault en tiempo de ejecución
• Marcar como "Deployment slot setting" para que sean sticky al slot (no se intercambien al hacer swap)
Connection Strings
Similar a App Settings pero tipadas por motor de BD (SQL Server, PostgreSQL, MySQL, Custom). En .NET, se inyectan automáticamente como connection strings sobreescribiendo las del web.config/appsettings.
• Se pueden marcar como sticky igual que las app settings
• Soportan Key Vault References para no exponer strings de conexión en el portal
• Para otros lenguajes (Python, Node): se inyectan como variables de entorno con prefijo SQLCONNSTR_, MYSQLCONNSTR_, etc.
Best practice: usar Key Vault References en lugar de hardcodear credenciales en App Settings. La Managed Identity de la app lee el secreto de KV automáticamente.
Azure Functions es la plataforma serverless de Azure. Ejecuta código en respuesta a eventos (triggers) sin gestionar servidores. Escala a cero automáticamente.
Consumption Plan
Escala a cero. Pagas por ejecución y tiempo de CPU. Máx 5 min de timeout por defecto (10 min max). Sin instancias siempre activas.
Mejor para
APIs de bajo tráfico, event processing, automatizaciones.
Flex Consumption (nuevo)
Consumption con VNet Integration nativa, instancias pre-provisioned opcionales, más control de concurrencia. El futuro de Functions.
Mejor para
Apps que necesitan VNet access y el modelo serverless.
Premium Plan
Instancias pre-calentadas (sin cold start). VNet Integration. Sin timeout máximo. Escala horizontal ilimitada. Más costoso.
Mejor para
APIs con SLA de latencia, acceso a recursos en VNet, ejecuciones largas.
Triggers comunes de Azure Functions
| Trigger | Evento que dispara | Caso típico |
|---|---|---|
| HTTP | Request HTTP/HTTPS | API REST, webhook, backend de SPA |
| Timer | Cron expression (ej: "0 0 * * * *") | Jobs programados, cleanup nocturno, reportes periódicos |
| Blob Storage | Archivo nuevo/modificado en container | Procesar imagen subida, generar thumbnail |
| Queue Storage | Mensaje en cola | Procesamiento asíncrono, desacoplamiento de servicios |
| Service Bus | Mensaje en topic/queue de Service Bus | Mensajería empresarial, patrones pub/sub |
| Cosmos DB | Change feed de Cosmos DB | Sincronización de datos, proyecciones de read model |
| Event Grid | Evento de cualquier fuente Azure | Reaccionar a eventos de Azure Monitor, Storage, etc. |
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Un equipo desplegó una nueva versión de su app en el deployment slot 'staging'. Al hacer swap con producción, la app falló porque intentó conectarse a la base de datos de producción usando la connection string del slot staging. ¿Cómo deberían haber configurado los slots para evitar esto?