Azure Cosmos DB for MongoDB vCore es MongoDB real en Azure, con arquitectura vCore (CPU + RAM) que escala vertical y horizontalmente sin downtime. Soporte nativo para vector search (DiskANN), sharding automático y 99.99% SLA con HA activado. Ideal para lift & shift de aplicaciones MongoDB existentes o nuevas apps que necesiten queries complejas, aggregations y transacciones distribuidas.
Azure Virtual Desktop ahora soporta Ephemeral OS Disks (Public Preview desde octubre 2025), una característica que mejora significativamente el rendimiento y velocidad de aprovisionamiento en entornos de escritorios virtuales. Los discos efímeros almacenan el sistema operativo en el almacenamiento local de la VM en lugar de en Azure Storage remoto, proporcionando latencias más bajas y tiempos de reimagen más rápidos, ideales para cargas de trabajo stateless.
Los Ephemeral OS Disks son discos de sistema operativo creados en el almacenamiento local de la máquina virtual (SSD local, cache o disco temporal) en lugar de almacenarse en Azure Storage remoto. Esta arquitectura ofrece ventajas clave para entornos AVD donde la persistencia del sistema operativo no es crítica.
Características principales:
Beneficios concretos:
flowchart LR
A[Session Host VM] -->|OS Disk| B[Local SSD/Cache]
A -->|User Profiles| C[FSLogix Container]
C -->|Storage| D[Azure Files/NetApp]
style B fill:#2ecc71
style D fill:#3498db
Diferencia clave con discos persistentes:
| Aspecto | Ephemeral OS Disk | Managed OS Disk |
|---|---|---|
| Ubicación | Almacenamiento local VM | Azure Storage remoto |
| Latencia I/O | Muy baja | Mayor (red) |
| Persistencia | No persistente | Persistente |
| Operaciones | Restart/Reimage/Delete | Start/Stop/Deallocate/Snapshot |
| Coste | Incluido en VM | Coste adicional storage |
Placement options:
No soporta:
Configuración de autoscaling:
# Configuración requerida en Azure Portal
Host Pool Type: Pooled
Management Type: Automated
Session Host Configuration: Enabled
# En la pestaña Virtual Machines:
Image: Windows 11 Enterprise multi-session
Virtual Machine Size: Standard_D8s_v3 (temp disk 200 GiB)
OS Disk Type: Standard SSD (auto-selected)
Ephemeral OS Disk: Enabled
Placement: Temp Disk
# Variables del entorno
$resourceGroup = "avd-rg"
$hostPoolName = "avd-ephemeral-pool"
$location = "westeurope"
$vmPrefix = "avd-eph"
$vmSize = "Standard_D8s_v3"
$subnetId = "/subscriptions/<SUB_ID>/resourceGroups/<RG>/providers/Microsoft.Network/virtualNetworks/<VNET>/subnets/<SUBNET>"
# Crear session host configuration con ephemeral disk
$parameters = @{
FriendlyName = "Ephemeral Session Hosts"
HostPoolName = $hostPoolName
ResourceGroupName = $resourceGroup
VMNamePrefix = $vmPrefix
VMLocation = $location
ImageInfoType = "Marketplace"
MarketplaceInfoPublisher = "MicrosoftWindowsDesktop"
MarketplaceInfoOffer = "Windows-11"
MarketplaceInfoSku = "win11-22h2-avd"
MarketplaceInfoExactVersion = "latest"
VMSizeId = $vmSize
DiskInfoType = "Standard_LRS" # Standard SSD requerido en preview
NetworkInfoSubnetId = $subnetId
DomainInfoJoinType = "AzureActiveDirectory"
VMAdminCredentialsUsernameKeyVaultSecretUri = "https://<VAULT>.vault.azure.net/secrets/<SECRET>/..."
VMAdminCredentialsPasswordKeyVaultSecretUri = "https://<VAULT>.vault.azure.net/secrets/<SECRET>/..."
}
New-AzWvdSessionHostConfiguration @parameters
# Listar VM sizes con soporte ephemeral disk
$location = "westeurope"
$vmSizes = Get-AzComputeResourceSku -Location $location |
Where-Object {$_.ResourceType -eq 'virtualMachines'}
foreach ($vmSize in $vmSizes) {
foreach ($capability in $vmSize.Capabilities) {
if ($capability.Name -eq "EphemeralOSDiskSupported" -and $capability.Value -eq "True") {
[PSCustomObject]@{
VMSize = $vmSize.Name
EphemeralSupported = $capability.Value
CacheSize = ($vmSize.Capabilities | Where-Object {$_.Name -eq "CachedDiskBytes"}).Value
TempDiskSize = ($vmSize.Capabilities | Where-Object {$_.Name -eq "MaxResourceVolumeMB"}).Value
}
}
}
}
# Crear scaling plan con configuración específica para ephemeral
$scalingParams = @{
HostPoolName = $hostPoolName
ResourceGroupName = $resourceGroup
ScheduledDateTimeZone = "W. Europe Standard Time"
UpdateLogOffDelayMinute = 15
UpdateMaxVmsRemoved = 10
UpdateDeleteOriginalVM = $true # Importante: eliminar VMs en lugar de deallocate
UpdateLogOffMessage = "El sistema se reiniciará para mantenimiento en 15 minutos"
}
New-AzWvdSessionHostManagement @scalingParams
Para migrar un host pool con managed disks a ephemeral:
# 1. Actualizar session host configuration
$updateParams = @{
HostPoolName = $hostPoolName
ResourceGroupName = $resourceGroup
VMSizeId = "Standard_D8s_v3" # VM size con temp disk suficiente
DiskInfoType = "Standard_LRS"
}
Update-AzWvdSessionHostConfiguration @updateParams
# 2. Programar update para aplicar cambios (reemplaza session hosts)
# Nota: Esto recreará los session hosts con ephemeral disks
# 3. Monitorizar progreso
$progress = Get-AzWvdSessionHostManagementsUpdateStatus @updateParams |
Format-List PercentComplete, ProgressSessionHostsCompleted, EndTime
$progress
Persistencia de datos:
Gestión de ciclo de vida:
Sizing correcto:
Monitorización:
Error: "Insufficient local storage"
# Causa: VM size sin suficiente cache/temp disk
# Solución: Cambiar a VM size mayor o con temp disk adecuado
# Verificar tamaño requerido
$imageSize = 127 # GiB para Windows 11 multi-session
Get-AzComputeResourceSku -Location $location |
Where-Object {$_.Name -eq "Standard_D8s_v3"} |
Select-Object Name, @{N="TempDiskGB";E={[math]::Round(($_.Capabilities |
Where-Object {$_.Name -eq "MaxResourceVolumeMB"}).Value / 1024)}}
Error: "NVMe placement not supported"
Causa: Selección de NVMe como placement durante preview
Solución: Usar Temp Disk o Cache placement en Azure Portal
Pérdida de datos tras deallocate:
Causa: Operación stop/deallocate borra OS state en ephemeral disks
Solución: Configurar autoscaling con UpdateDeleteOriginalVM = $true
Usar restart en lugar de deallocate para operaciones manuales
Añadir usuarios (internos y externos) uno a uno en canales compartidos de Teams es tedioso. Este post muestra cómo automatizar el proceso usando PowerShell, Microsoft Graph y un archivo CSV como origen de datos para añadir múltiples usuarios de forma eficiente.
En este post explico qué son los VNet flow logs (logs de flujo de red de Azure), cómo habilitarlos y cómo analizarlos con un pequeño script PowerShell que desarrollé para facilitar la detección de anomalías y la generación de reportes.
Documentación oficial (Microsoft):
https://learn.microsoft.com/azure/network-watcher/vnet-flow-logs-overview
records con campos que describen cada flujo y sus métricas (bytes, paquetes, acción,
puertos, etc.).He incluido un script llamado Analyze-VNETFlowLogs.ps1 que procesa archivos JSON con VNet flow logs
y genera un análisis en consola. Además puede exportar dos ficheros CSV con el detalle y el resumen del
análisis.
Si tus logs están aún en la cuenta de almacenamiento, puedes usar el script de apoyo
Download-FlowLogs.ps1 para:
insights-logs-flowlogflowevent).-AutoShorten).YYYY-MM-DD/HH/FlowLog_<timestamp>_*.json.Parámetros clave:
- -StorageAccount (obligatorio): Nombre de la storage account.
- -ContainerName: Contenedor (default: insights-logs-flowlogflowevent).
- -DownloadPath: Carpeta destino local (default: ./FlowLogs).
- -AutoShorten: Acorta automáticamente rutas demasiado largas mediante hashing.
- -Force: Omite confirmaciones interactivas.
Variables de entorno soportadas:
- AZ_STORAGE_KEY: Si está definida se usa esa clave directamente.
- AZ_RESOURCE_GROUP: Permite intentar descubrir la key si no se pasó manualmente.
Si no hay clave disponible o el intento de descubrimiento falla, se intentará usar automáticamente --auth-mode login para la autenticación.
Ejemplo de uso completo (descarga + análisis):
# 1. Descargar y organizar
pwsh -File ./Download-FlowLogs.ps1 -StorageAccount mystorageacct -DownloadPath ./FlowLogs -AutoShorten -Force
# 2. Analizar todos los logs resultantes
pwsh -File ./Analyze-VNETFlowLogs.ps1 -LogFiles "./FlowLogs/**/*.json" -ExportCSV -OutputPath ./reports -ShowGraphs
Si ya tienes los JSON en local (por AzCopy u otro método), puedes saltarte el paso 1.
pwsh -File "./Analyze-VNETFlowLogs.ps1" -LogFiles "./samples/*.json" -ExportCSV -OutputPath "./reports" -ShowGraphs
-LogFiles: rutas a los JSON (acepta wildcards).-ExportCSV: exporta VNetFlowAnalysis_Details_<timestamp>.csv y VNetFlowAnalysis_Summary_<timestamp>.csv.-OutputPath: directorio para los CSV.-SpecificIPs: array de IPs para análisis centrado en hosts concretos.-ShowGraphs: muestra gráficas de barras simples en la consola.samples/sample-flowlog.json con varios flujos que cubren casos típicos (permitidos, denegados,
varios BEGIN para simular reintentos/posible escaneo).reports/ y se muestra
un resumen en consola.Parse-FlowTuple del script espera un orden concreto de campos, que puedes
adaptar si es necesario.Analyze-VNETFlowLogs.ps1 — script principal.Download-FlowLogs.ps1 — utilidad para descargar y normalizar logs desde la cuenta de almacenamiento.README.md — instrucciones y referencia a la doc oficial.samples/sample-flowlog.json — ejemplo para pruebas.Espero que esto te ayude a analizar flujos en tus VNets.
Azure Monitor Alerts detecta problemas antes de que los usuarios los reporten. Con Action Groups automatizas la respuesta (email, SMS, webhook, runbook, Logic App). En este post verás cómo configurar alertas de métricas y logs, action groups, y KQL queries para monitoring efectivo.
Azure Firewall Premium añade inspección TLS, Threat Intelligence y reglas personalizadas para proteger redes cloud y híbridas. Este post va directo: cómo activar TLS inspection, usar Threat Intelligence, crear reglas avanzadas y monitorizar tráfico. Para admins y arquitectos que quieren seguridad real en producción.
flowchart LR
Internet --> FW[Azure Firewall Premium]
FW --> VNet1[Prod VNet]
FW --> VNet2[Dev VNet]
FW --> OnPrem[On-Premises]
FW -.-> LogAnalytics[Log Analytics]
FW -.-> Sentinel[Azure Sentinel]
# Application rule: solo permite https://github.com
az network firewall policy rule-collection-group application-rule-collection create \
--policy-name fw-policy-premium \
--resource-group $RESOURCE_GROUP \
--name app-allow-github \
--priority 100 \
--action Allow \
--rules '[{"name":"AllowGithub","sourceAddresses":["*"],"protocols":[{"protocolType":"Https","port":443}],"targetFqdns":["github.com"]}]'
# Network rule: solo permite TCP 443 a IP específica
az network firewall policy rule-collection-group network-rule-collection create \
--policy-name fw-policy-premium \
--resource-group $RESOURCE_GROUP \
--name net-allow-prod \
--priority 200 \
--action Allow \
--rules '[{"name":"AllowProd443","sourceAddresses":["10.0.0.0/24"],"destinationAddresses":["20.30.40.50"],"destinationPorts":["443"],"protocols":["TCP"]}]'
az monitor diagnostic-settings create \
--resource /subscriptions/$SUB_ID/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.Network/azureFirewalls/$FW_NAME \
--workspace $LOG_ANALYTICS_ID \
--name fw-logs \
--logs '[{"category":"AzureFirewallApplicationRule","enabled":true},{"category":"AzureFirewallNetworkRule","enabled":true},{"category":"AzureFirewallDnsProxy","enabled":true}]'
// Top 10 destinos bloqueados
AzureDiagnostics
| where Category == "AzureFirewallNetworkRule"
| where action_s == "Deny"
| summarize Count = count() by destination_ip_s
| top 10 by Count desc
// Detección de ataques IDPS
AzureDiagnostics
| where Category == "AzureFirewallIdpsSignature"
| summarize Count = count() by signature_name_s
| top 10 by Count desc
Black Friday y Cyber Monday generan picos de tráfico 10-50x normales. Azure Front Door te da CDN global, WAF, load balancing inteligente y failover automático para manejar esos picos sin caídas. En este post verás cómo configurar Front Door para alta disponibilidad y performance.
Bicep permite IaC declarativo en Azure, pero en producción necesitas testing, linting y despliegue seguro por entorno. Este post va al grano: cómo testear plantillas, usar linting, parametrizar para dev/prod y evitar errores comunes.
flowchart LR
Dev[Dev] --> CI[CI Pipeline]
CI --> Lint[Lint]
CI --> Test[Test]
CI --> Deploy[Deploy]
Deploy --> Azure[Azure]
Azure --> RG1[Resource Group Dev]
Azure --> RG2[Resource Group Prod]
.bicepconfig.json:
trigger:
- main
pool:
vmImage: 'ubuntu-latest'
steps:
- script: bicep build main.bicep
displayName: 'Build Bicep'
- script: bicep linter main.bicep
displayName: 'Lint Bicep'
- script: pwsh -c "Invoke-PSRule -Path ./main.bicep"
displayName: 'Test Bicep'
- script: az deployment group create --resource-group rg-dev --template-file main.bicep --parameters @dev.parameters.json
displayName: 'Deploy Dev'
Pipelines as Code con YAML en Azure DevOps te permite versionar CI/CD, reutilizar templates y aplicar DRY principle. En este post verás cómo crear pipelines YAML modulares, templates parametrizados y estrategias multi-stage para deploy seguro.
Azure Policy es el pilar de governance en Azure que permite definir estándares organizacionales (tags obligatorios, regiones permitidas, SKUs aprobados) y evaluar compliance automáticamente en todos los recursos. Cuando detecta recursos no conformes, puede auditar, denegar nuevos despliegues, o remediar recursos existentes con deployIfNotExists/modify effects. En este post veremos cómo crear policies, asignarlas con initiative sets, configurar remediation tasks para traer recursos a conformidad, y usar Azure Policy para implementar governance escalable en entornos multi-subscripción.