AZ-104
Deep Dive
Los servicios de base de datos relacional de Azure. El AZ-104 evalúa los modelos de compra, tiers de servicio, alta disponibilidad, seguridad y las diferencias entre SQL Database y SQL Managed Instance.
Contenido
| Servicio | Tipo | Compatibilidad SQL Server | Gestión | Mejor para |
|---|---|---|---|---|
| Azure SQL Database | PaaS | Alta (últimas features cloud-first) | Fully managed — OS, patches, backups automáticos | Nuevas apps cloud-native, modernización sin dependencias legacy |
| SQL Managed Instance | PaaS | Casi 100% (instancia completa) | Managed — pero con más control que SQL DB | Lift-and-shift de SQL Server on-prem con mínimos cambios |
| SQL Server en VM (IaaS) | IaaS | 100% (tú controlas la versión) | Tú gestionas OS, patches, HA, backups | Máximo control, features no disponibles en PaaS, compliance específico |
Componentes principales
SQL Server (lógico)
Contenedor administrativo que no tiene recursos propios. Agrupa bases de datos, configura logins, firewall y auditoría. Un servidor puede tener hasta 5000 bases de datos.
SQL Database
La base de datos individual. Tiene sus propios recursos (DTUs o vCores), configuración de backup y geo-replication independiente.
Elastic Pool
Pool de recursos compartido por múltiples bases de datos. Ideal cuando las BDs tienen picos de uso en distintos momentos.
Características PaaS incluidas
Limitaciones vs SQL Server completo
Modelo DTU (Database Transaction Unit)
Modelo simplificado: DTU es una medida mezclada de CPU, memoria e I/O. Más fácil de entender, menos flexible.
Basic
5 DTUs
Dev/test, apps pequeñas con pocas transacciones
Standard (S0-S12)
10-3000 DTUs
Producción con carga de trabajo predecible
Premium (P1-P15)
125-4000 DTUs
Apps OLTP con alta densidad de transacciones
Modelo vCore (recomendado para nuevas)
Elige vCores y memoria de forma independiente. Permite usar Azure Hybrid Benefit (licencias SQL Server existentes).
General Purpose
Almacenamiento remoto (Azure Premium Storage). HA: réplica en standby. Ideal para 99% de cargas de producción.
Business Critical
SSD local (NVMe). 3-4 réplicas síncronas (Always On). 1 réplica puede usarse como Read Scale-out o failover. Latencia I/O muy baja.
Hyperscale
Hasta 100 TB+. Arquitectura de páginas distribuida, backups instantáneos, escalado de lectura con réplicas adicionales. Solo SQL Database (no MI).
Serverless (vCore): escala automáticamente el cómputo entre un mínimo y máximo de vCores. Pausa automáticamente y cobra solo por almacenamiento cuando está inactivo. Ideal para BDs con uso intermitente.
Un Elastic Pool es un conjunto de recursos (DTUs o vCores) compartidos entre múltiples bases de datos. Las BDs toman los recursos que necesitan del pool sin superar el máximo del pool.
Cuándo usar Elastic Pools
Cuándo NO usar Elastic Pools
SQL MI es una instancia casi idéntica a SQL Server on-premises pero como servicio PaaS. Diseñada para lift-and-shift de aplicaciones que necesitan compatibilidad al 100% con SQL Server.
| Característica | Azure SQL Database | SQL Managed Instance |
|---|---|---|
| SQL Server Agent | ✗ (Elastic Jobs) | ✓ Nativo |
| Linked Servers | ✗ | ✓ (hacia otros SQL Server) |
| Service Broker | ✗ cross-database | ✓ dentro de la instancia |
| CLR (Common Language Runtime) | Solo safe assemblies | ✓ incluidos unsafe |
| Database Mail | ✗ | ✓ |
| Backup a URL | Gestionado por Azure | ✓ puedes hacer BACKUP TO URL manualmente |
| Instance-level collation | Fijo por BD | ✓ configurable al crear instancia |
| Deployment model | BD individual / Elastic Pool | Instancia completa en VNet (dedicada) |
| Acceso de red | Endpoint público o Private Endpoint | Solo dentro de VNet (diseño por defecto) |
| vCores disponibles | 1-80 vCores | 4-80 vCores (General Purpose) / 4-32 (Business Critical) |
| Número de BDs | Una por recurso | Hasta 100 por instancia |
| Azure Hybrid Benefit | ✓ | ✓ |
SQL MI — importante para el examen
• SQL MI se despliega dentro de una VNet dedicada — requiere subred específica con delegación a Microsoft.Sql/managedInstances
• La subred debe tener un mínimo de /27 de espacio de direcciones
• Instance Pools: múltiples SQL MIs pequeñas comparten un clúster (para reducir costos en dev/test)
• Provisioning de una instancia nueva puede tardar 4-6 horas inicialmente (operación de infraestructura)
Transparent Data Encryption (TDE)
Cifrado en reposo de la BD, backups y transaction logs. Habilitado por defecto en todas las BDs nuevas desde 2017.
Auditoría de Azure SQL
Registra eventos de la BD: consultas, logins, cambios de esquema. Destino: Storage Account, Log Analytics o Event Hub.
Advanced Threat Protection (ATP)
Detecta anomalías de seguridad: SQL injection, acceso desde ubicaciones inusuales, acceso excesivo a datos, privilegios potencialmente comprometidos.
Dynamic Data Masking
Enmascara datos sensibles en el resultado de queries para usuarios sin privilegios. No modifica los datos almacenados.
Autenticación: SQL vs Entra ID
| Modo | Cómo funciona | Pros | Cons |
|---|---|---|---|
| SQL Authentication | Usuario/contraseña gestionado en la BD | Simple, compatible con cualquier cliente SQL | Gestión de credenciales manual, no MFA |
| Entra ID Authentication | Token OAuth desde Entra ID, puede usar MFA/Conditional Access | Centralizado, soporta grupos y MFA, Managed Identity sin contraseña | Requiere soporte en la app/driver |
| Mixed Mode | Ambos disponibles | Compatibilidad con apps legacy | Superficie de ataque mayor |
HA integrada por tier
General Purpose / Standard
Cómputo separado del almacenamiento (Azure Premium Storage). En failover, se crea nuevo cómputo que se conecta al storage remoto. RTO ~25-30 segundos. No hay réplica de cómputo activa.
Business Critical / Premium
Always On Availability Group de 3-4 réplicas con SSD local. Una réplica secundaria disponible para Read Scale-out sin costo extra. Failover <8 segundos. Mínima pérdida de datos.
Hyperscale
Arquitectura única: múltiples réplicas Read-only que acceden al mismo almacenamiento distribuido. Backup instantáneo (no hay copia completa). Restore rápido independiente del tamaño.
Active Geo-Replication
Crea hasta 4 réplicas secundarias legibles en distintas regiones. Replicación asíncrona continua. Las réplicas son bases de datos read-only activas — puedes redirigir queries de lectura para aliviar la primaria.
• Failover manual: promueves una secundaria a primaria cuando lo decides
• Failover forzado: posible con potencial pérdida de datos (RPO ~5 seg)
• Solo disponible en Azure SQL Database (no en SQL MI — usa Auto-failover groups)
Auto-Failover Groups
Agrupa múltiples BDs para failover coordinado. Proporciona un listener endpoint que redirige automáticamente a la primaria o secundaria (read-write y read-only).
• Read-write listener: nombre DNS estático — apuntas tu app aquí, no cambia en failover
• Read-only listener: redirige a secundaria para queries de solo lectura
• Grace period: tiempo antes del failover automático (1h por defecto, configurable)
• Disponible en SQL DB y SQL MI
Public Endpoint + Firewall
El servidor SQL tiene un endpoint público. El firewall permite/bloquea por IP o rangos. "Allow Azure services" abre acceso a todos los servicios Azure (no solo los tuyos — usar con cuidado).
Private Endpoint
IP privada en tu VNet para el SQL Server. El tráfico no sale a internet. Requiere Private DNS Zone (privatelink.database.windows.net). Opción más segura para producción.
VNet Service Endpoint
Extiende identidad de la subred hacia el servicio SQL. Tráfico por backbone de Azure. Configuras en SQL Server Firewall → Virtual Networks. Menos granular que Private Endpoint.
Azure DMS (Database Migration Service)
Servicio gestionado para migrar bases de datos on-premises o de otros clouds a Azure con mínima interrupción. Soporta SQL Server, MySQL, PostgreSQL, Oracle, MongoDB.
Online (mínimo downtime)
Migración continua con replicación de cambios. Cutover manual cuando estés listo. Ideal para prod.
Offline (snapshot)
Backup + restore + migración de esquema. Downtime durante la ventana. Más simple, para BDs no críticas.
Data Migration Assistant (DMA)
Herramienta gratuita que evalúa compatibilidad de SQL Server on-premises con Azure SQL Database o SQL MI. Identifica blocking issues y breaking changes antes de migrar.
Flujo de migración recomendado
1. Evaluar con DMA → identificar incompatibilidades
2. Elegir destino: SQL DB (si compat OK) o SQL MI (si necesitas features completos)
3. Configurar DMS → crear proyecto de migración
4. Migrar esquema → migrar datos
5. Validar en paralelo → cutover en ventana de mantenimiento
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa quiere migrar su aplicación on-premises a Azure. La app usa SQL Server Agent Jobs, Service Broker y CLR assemblies. ¿Qué servicio de Azure SQL deberían elegir?