El dominio de diseño de cómputo en el examen AZ-305 Solutions Architect Expert está repleto de preguntas que no puedes responder solo memorizando servicios. La respuesta correcta cambia según la combinación de requisitos: "migrar sin cambios de código", "eliminar la carga de gestionar Kubernetes" o "procesar eventos sin servidores". Esta guía destila patrones de 49 preguntas reales del AZ-305 para mapear los criterios de selección de cada servicio y exponer las trampas de respuesta más comunes.
---
VM y Virtual Machine Scale Sets (VMSS)
La señal decisiva para elegir una VM es la dependencia legacy. Cuando aparecen componentes a nivel de runtime del SO de Windows — componentes COM, COM+ o ActiveX — la migración a PaaS no es posible. Cuando los requisitos de alta disponibilidad aparecen junto a esto, se elige entre Availability Sets y Availability Zones.
Availability Sets: Distribuye VMs entre dominios de error (hasta 3) y dominios de actualización (hasta 20) dentro del mismo centro de datos. SLA del 99,95%, sin costo adicional. Availability Zones: Despliega VMs en centros de datos físicamente separados dentro de una región. SLA del 99,99%, protege contra la falla completa de un centro de datos.
La selección de la serie de VM también aparece en el examen. Para entornos de desarrollo y pruebas con picos irregulares, Bsv2 (burstable) — el modelo de acumulación de créditos de CPU mantiene los costos significativamente más bajos. Para cargas de trabajo que necesitan una alta proporción de memoria, como SQL Server, Ev5 (optimizado para memoria) — incluye red acelerada SR-IOV por defecto y también reduce los costos de licencias de SQL Server. Cuando se requiere aislamiento de hardware de nivel de cumplimiento, combina Azure Dedicated Host con VMSS y Availability Zones.
VMSS escala automáticamente VMs idénticas hacia arriba y hacia abajo según métricas como la utilización de CPU, soportando hasta 1.000 instancias en el plan estándar.
---
App Service y cargas de trabajo web
Existen tres señales de selección para App Service: migrar sin cambios de código, delegar la gestión del SO a Azure y necesidad de escalado automático. Cuando los tres términos aparecen juntos, la respuesta casi siempre es App Service. Soporta nativamente runtimes de Java, Python, .NET y Node.js y proporciona almacenamiento temporal local ( en Windows, en Linux), por lo que incluso aplicaciones locales que usan archivos temporales pueden migrarse sin modificaciones de código.
Para implementaciones multirregión, recuerda que un App Service Plan está vinculado a una región específica de Azure. Para desplegar de forma independiente en Europa, Norteamérica y APAC, se necesitan Plans separados por región. Para entornos regulados que necesitan aislamiento completo con una subred de VNet dedicada, considera App Service Environment (ASE v3) — pero ten en cuenta que incluso un entorno vacío incurre en un costo base de más de USD 1.000 por mes.
El swap de Deployment Slots se trata de un cambio instantáneo sin tiempo de inactividad. Después de validar un slot de staging en un entorno idéntico al de producción, el swap lleva las instancias precalentadas a recibir tráfico en segundos. Esta característica está disponible solo en el nivel Standard y superiores. Para despliegues canary progresivos, ajusta el porcentaje de tráfico del slot o usa Traffic Manager.
---
Serverless: Functions y Logic Apps
Elegir un plan de hosting de Azure Functions es un tema recurrente en el AZ-305.
Plan Consumption: Facturación por cantidad de ejecuciones por duración, con 1 millón de ejecuciones gratuitas por mes. Sin costo durante períodos de inactividad. Sin embargo, el tiempo máximo de ejecución es de 10 minutos, ocurren arranques en frío y no se admite la integración con VNet. Plan Premium: Las instancias precalentadas eliminan los arranques en frío. El tiempo de ejecución puede configurarse como ilimitado. Admite integración con VNet. Cuando ves los tres — sin arranques en frío, ejecuciones de más de 10 minutos, integración con VNet — la respuesta es Premium. Plan Dedicated: Se ejecuta sobre un App Service Plan. Existe la sobrecarga de gestión de servidores, pero los recursos del Plan existente pueden compartirse.
Los niveles de autorización del trigger HTTP también se evalúan. permite que cualquiera llame sin una clave, lo que lo hace adecuado para APIs de datos públicos. requiere una clave de función y requiere la clave maestra. El array restringe qué métodos HTTP están permitidos; los métodos no listados reciben automáticamente una respuesta 405.
---
Cargas de trabajo de contenedores: Container Apps y AKS
Container Apps vs AKS
El criterio clave es el nivel de control de Kubernetes necesario. Si el requisito es "ejecutar contenedores sin gestionar Kubernetes y minimizar la sobrecarga operativa", elige Azure Container Apps. Si se requiere control directo de Kubernetes, elige AKS.
Container Apps proporciona escalado automático basado en KEDA e integración con Dapr de forma nativa, con grupos de nodos, kubectl y actualizaciones de clúster completamente abstraídas. AKS se usa para escenarios avanzados que requieren una malla de servicios Istio, políticas de red o runtimes personalizados.
Varios temas avanzados de AKS aparecen con frecuencia en el examen.
KEDA: Una herramienta de escalado automático nativa de Kubernetes que soporta más de 50 escaladores, incluyendo Azure Queue Storage, Event Hubs y Service Bus. La capacidad clave es scale to zero — cuando no hay mensajes en una cola, los pods escalan a cero. HPA solo requiere al menos un pod, pero KEDA permite cero. Virtual Node + ACI: Se usa cuando AKS necesita expandirse instantáneamente sin aprovisionar VMs. Conectar ACI como nodo virtual inicia contenedores en decenas de segundos. Solo admite contenedores Linux. Malla de servicios Istio: La elección correcta cuando necesitas despliegue canary (ponderación de tráfico), enrutamiento basado en cabeceras y cifrado mTLS entre servicios, todo al mismo tiempo. Dapr: La State Management API proporciona una interfaz unificada para Redis, Cosmos DB y Azure Table Storage. La Pub/Sub API abstrae los brokers de mensajes. Cambiar un archivo de configuración YAML te permite cambiar el almacenamiento o el broker sin tocar el código. ACR Geo-replication: Solo compatible con ACR de nivel Premium. Automatiza la replicación de imágenes para clústeres AKS multirregión y garantiza que cada región extraiga imágenes de su réplica más cercana.
!Container Apps vs AKS
Tabla comparativa de servicios
| Servicio | Modelo de costo | Escalado | Complejidad operativa | Señal de selección principal | |---------|----------------|---------|----------------------|------------------------------| | VM | Horas de instancia | Manual o VMSS | Alta | Legacy COM/ActiveX, aislamiento de hardware | | VMSS | Horas de instancia | Automático (métricas) | Media | Escalado automático de VMs idénticas | | App Service | Horas de plan | Automático (cantidad de instancias) | Baja | Lift-and-shift de aplicaciones web sin cambios de código | | Container Apps | Tiempo de ejecución + solicitudes | KEDA automático (incl. 0) | Baja | Ejecutar contenedores sin gestión de K8s | | AKS | Horas de VM de nodo | HPA/KEDA/Cluster Autoscaler | Alta | Control directo de K8s, malla de servicios | | Functions (Consumption) | Ejecuciones x duración | Automático (serverless) | Muy baja | Eventos irregulares, ejecuciones cortas | | Functions (Premium) | Instancias mínimas + uso | Automático (precalentado) | Baja | Sin arranques en frío, integración con VNet |
---
Criterios de selección que confunden en el examen
Procesamiento paralelo a gran escala
Para cargas de trabajo que procesan miles de tareas independientes en paralelo — renderizado 3D, análisis genómico, simulación financiera — Azure Batch es la respuesta. Tiene colas de tareas, programación y escalado automático de grupos de VMs integrados, y vuelve a cero cuando el trabajo termina. Si necesitas integrarte con programadores de trabajos HPC de terceros (PBS Pro, Slurm, LSF), elige Azure CycleCloud. Para los tipos de nodo de Batch, usa Spot VMs para cargas de trabajo de desarrollo tolerantes a interrupciones (hasta un 90% de ahorro) y Dedicated VMs para producción de larga duración.
Herramientas de migración
Azure Migrate: Una plataforma integrada para descubrir, evaluar y migrar cargas de trabajo locales a Azure. Un dispositivo VMware recopila datos de rendimiento de VM sin agentes y calcula el SKU adecuado y el costo estimado. Azure Resource Mover: Se usa para mover recursos existentes entre suscripciones o regiones dentro de Azure. No confundas esto con la migración desde entornos locales. Azure DMS (modo en línea): Sincroniza continuamente SQL Server con Azure SQL Managed Instance mediante CDC, limitando el tiempo de inactividad del corte a minutos. Combinación DMA + DMS: Evalúa previamente la compatibilidad del esquema SQL con DMA, luego realiza la migración real de datos con DMS. Azure Data Factory: Se usa para migraciones entre fuentes de datos heterogéneas, como SQL Server a Cosmos DB (NoSQL). DMS es solo para migraciones de relacional a relacional.
Microservicios híbridos
Cuando el requisito es una plataforma de microservicios que opera simultáneamente en entornos locales y en Azure con ultra-baja latencia, Azure Service Fabric es la respuesta. Puedes desplegar el mismo clúster en centros de datos locales y en la nube de Azure, procesando millones de instancias con latencia de milisegundos.
---
Consejos prácticos de aplicación
Clasificar por patrón de carga de trabajo es el enfoque más rápido. Necesidad de acceso a nivel de SO → VM. Aplicación web PaaS → App Service. Contenedores pero quieres evitar la gestión de K8s → Container Apps. Control completo de K8s → AKS. Eventos cortos e irregulares → Functions.
Recuerda también los patrones de optimización de costos. CPU promedio baja con picos irregul