Modulo 01. Conceptos cloud y propuesta de Azure

Objetivo del modulo

Entender que propone Azure como plataforma cloud y como encaja en escenarios empresariales habituales, especialmente en organizaciones con ecosistema Microsoft.

Resultados esperados

• Explicar beneficios cloud desde la perspectiva de Azure.
• Relacionar suscripciones, regiones y recursos con organizacion basica.
• Traducir un caso simple de negocio a una opcion inicial en Azure.
• Comprender el modelo de responsabilidad compartida en Azure.

Desarrollo teorico

Azure combina servicios de infraestructura, plataforma, datos, identidad, integracion y gestion en una oferta muy alineada con entornos corporativos hibridos. Para muchas organizaciones, su valor aparece no solo por la elasticidad o el pago por uso, sino por la integracion nativa con Microsoft 365, Entra ID (antes Azure AD), Windows Server, SQL Server, herramientas de desarrollo (.NET, Visual Studio, GitHub) y modelos hibridos con Azure Arc o ExpressRoute. Eso hace que Azure se use a menudo como extension natural de entornos ya muy "Microsoft", aunque tambien soporta Linux, contenedores, open source y muchos escenarios multiplataforma.

Caracteristicas fundamentales del cloud computing. Antes de profundizar en Azure conviene consolidar los principios cloud que aplican a cualquier proveedor y que el examen AZ-900 evalua directamente. La elasticidad permite escalar recursos automaticamente segun la demanda, tanto hacia arriba como hacia abajo. La alta disponibilidad garantiza que los servicios mantienen un SLA definido mediante redundancia de componentes. La escalabilidad puede ser vertical (mas CPU o RAM en una VM) u horizontal (mas instancias detras de un balanceador). La agilidad reduce el tiempo necesario para aprovisionar infraestructura de semanas a minutos. La tolerancia a fallos asegura que la caida de un componente no interrumpe el servicio global. El pago por uso (pay-as-you-go) convierte gasto de capital (CapEx) en gasto operativo (OpEx), facilitando la planificacion financiera. Azure implementa todos estos principios a traves de su infraestructura global de centros de datos distribuidos en mas de 60 regiones.

Organizacion de recursos en Azure. En la base de Azure conviene entender cuatro piezas organizativas que determinan como se gobiernan los recursos:

1. Management Group: Contenedor de suscripciones para aplicar politicas y control de acceso a escala. Util en grandes organizaciones con multiples departamentos. Pueden anidarse hasta seis niveles de profundidad.
2. Suscripcion (Subscription): Actua como contenedor de facturacion, limites de servicio y ambito de control. Una empresa puede tener suscripciones separadas por entorno (desarrollo, produccion), por departamento o por proyecto. Cada suscripcion tiene limites (quotas) de recursos que se pueden solicitar ampliar.
3. Resource Group: Agrupa recursos relacionados por ciclo de vida o logica de gestion. Todos los recursos de una aplicacion (VM, base de datos, storage account, red virtual) suelen vivir en el mismo Resource Group. Eliminar un Resource Group elimina todos los recursos que contiene. Un recurso solo puede pertenecer a un Resource Group, pero los Resource Groups pueden contener recursos de distintas regiones.
4. Region: Indica donde se despliega el servicio fisicamente. Azure opera en mas de 60 regiones globales. Cada region tiene Availability Zones (zonas de disponibilidad fisicamente separadas dentro de la misma region) para alta disponibilidad. Existen tambien Region Pairs, parejas de regiones en la misma geografia que proporcionan replicacion y failover para servicios criticos.

Esta jerarquia (Management Group > Subscription > Resource Group > Resource) es fundamental para gobernanza, facturacion y control de acceso.

Servicios core de Azure. Azure ofrece centenares de servicios, pero los fundamentales para empezar son:

• Computo: Azure Virtual Machines (IaaS), Azure App Service (PaaS para apps web), Azure Functions (serverless event-driven), Azure Kubernetes Service (AKS para orquestacion de contenedores), Azure Container Instances (contenedores sin cluster).
• Almacenamiento: Blob Storage (objetos, con tiers Hot, Cool y Archive), Azure Files (compartidos SMB/NFS), Azure Disks (discos gestionados para VMs), Azure Queue Storage (colas de mensajes). Blob Storage es comparable a Amazon S3 y permite almacenar desde backups hasta contenido estatico de aplicaciones web.
• Red: Virtual Network (VNet, equivalente a AWS VPC), Network Security Groups (NSG, filtrado de trafico por reglas), Azure Load Balancer (capa 4), Application Gateway (capa 7 con WAF), ExpressRoute (conexion privada dedicada), Azure DNS, VPN Gateway.
• Bases de datos: Azure SQL Database (relacional gestionada), Cosmos DB (NoSQL multimodelo y distribuido globalmente), Azure Database for PostgreSQL/MySQL.
• Identidad: Entra ID (antes Azure AD: autenticacion, SSO, MFA, Conditional Access, RBAC). Entra ID es el servicio de identidad central de Azure y diferencia clave frente a otros proveedores por su integracion con el ecosistema Microsoft.
• Gestion: Azure Monitor (metricas y alertas), Azure Policy (cumplimiento de normas a escala), Azure Cost Management (control de gasto), Azure Advisor (recomendaciones de seguridad, rendimiento y coste).

Modelo de responsabilidad compartida. Al igual que en AWS, Azure opera un modelo de responsabilidad compartida. Azure gestiona la seguridad "de" la infraestructura (centros de datos, red fisica, hypervisor). El cliente gestiona lo que despliega "en" Azure: configuracion de red virtual, sistema operativo (en IaaS), datos, identidades, acceso. En servicios PaaS y SaaS, la frontera se desplaza y Azure asume mas responsabilidades, pero el cliente siempre es responsable de sus datos, identidades y configuracion de acceso. Este modelo es un tema recurrente en el examen AZ-900 y en la operacion real: un error comun es asumir que Azure "se encarga de todo" cuando en IaaS la responsabilidad de parchear el sistema operativo, configurar firewalls y proteger datos recae completamente en el cliente.

Por que Azure encaja en entornos hibridos. Muchas organizaciones no migran todo a cloud de una vez. Azure facilita escenarios hibridos con:

• Azure Arc: Gestionar servidores on-premises y multi-cloud desde Azure, aplicando politicas y monitorizacion unificada.
• ExpressRoute: Conexion privada dedicada entre CPD y Azure (no pasa por internet publico), con anchos de banda de hasta 100 Gbps.
• Azure Stack HCI: Infraestructura hiperconvergente on-premises gestionada con herramientas Azure.
• Entra ID Connect: Sincronizacion de identidades entre Active Directory on-premises y Entra ID en Azure, habilitando SSO hibrido.
• VPN Gateway: Conexion cifrada site-to-site o point-to-site para conectividad hibrida sobre internet.

Esto permite una transicion gradual donde los servicios mas adecuados para cloud migran primero y el resto se integra mediante herramientas de gestion unificada.

Modelos de servicio y tipos de nube. Azure soporta nube publica, privada e hibrida. Los modelos de servicio (IaaS, PaaS, SaaS) determinan el nivel de control y responsabilidad del cliente. IaaS da maximo control pero tambien maxima responsabilidad operativa (ejemplo: Azure VMs). SaaS minimiza operacion pero limita personalizacion (ejemplo: Microsoft 365). PaaS ofrece un equilibrio intermedio popular para aplicaciones web y APIs (ejemplo: Azure App Service, Azure SQL Database). La eleccion entre modelos depende de las necesidades de control, coste y velocidad de entrega de cada organizacion.

Contenido ampliado

Puntos clave

• Azure tiene especial fuerza en escenarios hibridos y en organizaciones con ecosistema Microsoft.
• La jerarquia Management Group > Subscription > Resource Group > Resource es la base de gobernanza.
• El modelo de responsabilidad compartida define que gestiona Azure y que gestiona el cliente.
• El valor cloud no es solo tecnico; tambien es operativo, financiero y de agilidad.
• Los escenarios hibridos (Arc, ExpressRoute, Entra ID Connect) facilitan transiciones graduales.
• Elegir region impacta latencia, cumplimiento normativo y disponibilidad de servicios.

Checklist operativa

• Identificar que problema de negocio o TI resuelve Azure en el caso estudiado.
• Disenar la jerarquia de suscripciones y Resource Groups antes de crear recursos.
• Elegir region con criterios de latencia, cumplimiento y operacion.
• Entender que responsabilidades de seguridad recaen en el cliente.
• Evaluar si el escenario requiere conectividad hibrida (ExpressRoute, VPN, Arc).

Errores frecuentes

• Pensar que Azure se reduce a VMs en la nube.
• Mezclar recursos sin logica de organizacion en Resource Groups.
• Elegir region sin considerar usuarios, regulacion o resiliencia.
• Asumir que Azure gestiona toda la seguridad por defecto.
• No planificar la estructura de suscripciones antes de empezar a crear recursos.
• Ignorar las capacidades hibridas cuando la organizacion no puede migrar todo a cloud.

Practica sugerida

Describe como organizarias una aplicacion web corporativa en Azure: elige suscripcion, Resource Group, region, servicios de computo, almacenamiento, base de datos e identidad. Justifica cada decision. Bonus: indica que servicios hibridos usarias si parte de la infraestructura permanece on-premises.

Preguntas de autoevaluacion

• Que diferencia hay entre suscripcion y Resource Group y como se relacionan.
• Por que Azure encaja especialmente bien en entornos hibridos con ecosistema Microsoft.
• Que decision tecnica y de negocio depende de la region elegida.
• Que significa el modelo de responsabilidad compartida en Azure.
• Cuando tiene sentido usar Azure Arc frente a migrar completamente a cloud.

Cierre

Azure se entiende mucho mejor cuando dejas de verlo como lista de servicios y empiezas a verlo como plataforma organizada para operar, gobernar y escalar recursos empresariales con una integracion natural con el ecosistema Microsoft y capacidades hibridas que facilitan la transicion.

Modulo 02. Servicios core: compute, network y storage

Objetivo del modulo

Reconocer los servicios fundamentales de cómputo, red y almacenamiento de Azure y diferenciar sus casos de uso básicos.

Resultados esperados

• Distinguir VMs, App Services, Functions y otros patrones básicos.
• Explicar qué papel tienen VNet, subredes y balanceadores.
• Diferenciar discos, Blob Storage y opciones de almacenamiento gestionado.

Desarrollo teorico

Azure ofrece un abanico amplio de servicios de cómputo, red y almacenamiento que cubren desde el control total de infraestructura hasta modelos completamente gestionados. Entender cuándo usar cada uno es una de las habilidades más importantes para cualquier profesional que trabaje con Azure, tanto para certificación como para proyectos reales.

Azure Virtual Machines: IaaS con control completo. Las Azure VMs proporcionan máquinas virtuales donde el cliente controla el sistema operativo, el software instalado, los parches y la configuración completa. Azure ofrece cientos de tamaños de VM organizados en familias: serie B para cargas económicas con créditos de CPU (similar a las t3 de AWS), serie D para propósito general equilibrado, serie F optimizada para cómputo intensivo, serie E para cargas con mucha memoria, serie N con GPUs para machine learning o renderizado, y serie L optimizada para almacenamiento con alta IOPS. Crear una VM desde la CLI de Azure se hace con az vm create --resource-group mi-rg --name mi-vm --image Ubuntu2204 --size Standard_B2s --admin-username azureuser --generate-ssh-keys --location westeurope. Este comando crea la VM, el disco del SO, una interfaz de red, una IP pública y un NSG básico automáticamente. Para producción, es habitual separar estos componentes y configurarlos independientemente para mayor control.

Las VMs en Azure soportan Availability Sets (distribución entre fault domains y update domains dentro de un datacenter), Availability Zones (distribución entre centros de datos físicamente separados dentro de una región) y Virtual Machine Scale Sets (VMSS) que permiten crear y gestionar grupos de VMs idénticas con autoescalado. Un VMSS se configura con az vmss create --resource-group mi-rg --name mi-vmss --image Ubuntu2204 --instance-count 3 --vm-sku Standard_B2s --lb mi-lb --upgrade-policy-mode automatic. El autoescalado se basa en métricas como CPU, memoria o métricas personalizadas, añadiendo o eliminando instancias automáticamente según la demanda.

Azure App Service: PaaS para aplicaciones web y APIs. App Service abstrae la infraestructura subyacente y permite desplegar aplicaciones web, APIs REST, backends móviles y funciones sin gestionar el sistema operativo ni el servidor web. Soporta múltiples runtimes (.NET, Java, Node.js, Python, PHP, Ruby) y permite despliegues desde Git, GitHub Actions, Azure DevOps, contenedores Docker o archivos ZIP. El despliegue es tan directo como az webapp create --resource-group mi-rg --plan mi-plan --name mi-webapp --runtime "PYTHON:3.11" seguido de az webapp deploy --resource-group mi-rg --name mi-webapp --src-path app.zip --type zip. App Service gestiona parches del SO, certificados TLS (con dominios personalizados), autoescalado, slots de despliegue para blue-green deployments, y monitorización integrada con Application Insights. Los App Service Plans definen el nivel de recursos (CPU, memoria, características) y el precio, con niveles desde Free y Shared para desarrollo hasta Premium y Isolated para cargas de producción con requisitos de aislamiento y rendimiento.

Azure Functions: serverless orientado a eventos. Azure Functions ejecuta código en respuesta a eventos sin que el desarrollador gestione infraestructura. Los triggers incluyen HTTP requests, mensajes en Service Bus o Storage Queues, eventos de Event Grid, cambios en Blob Storage, timers programados y muchos más. La facturación en el plan de consumo es por número de ejecuciones y tiempo de cómputo en GB-segundo, con un nivel gratuito de un millón de ejecuciones y 400.000 GB-segundo por mes. Crear una Function App se hace con az functionapp create --resource-group mi-rg --consumption-plan-location westeurope --runtime python --runtime-version 3.11 --functions-version 4 --name mi-function --storage-account mistorage. Functions es ideal para procesamiento de eventos, automatización de tareas, webhooks, transformación de datos y microservicios ligeros. Para cargas que necesitan ejecución continua o más control, existe el plan Premium con instancias pre-calentadas y conectividad VNet.

Azure Container Instances y AKS. Para cargas basadas en contenedores, Azure ofrece Azure Container Instances (ACI) para ejecutar contenedores individuales rápidamente sin gestionar clústeres ni orquestación (útil para tareas batch, CI/CD runners o microservicios simples), y Azure Kubernetes Service (AKS) para desplegar clústeres de Kubernetes gestionados donde Azure se encarga del plano de control y el cliente gestiona los nodos worker y los workloads. AKS se integra nativamente con Azure Container Registry (ACR) para almacenar imágenes Docker, con Entra ID para autenticación, con Azure Monitor para observabilidad y con Azure Policy para governance de los clústeres.

Azure Virtual Network: la base de red. Azure Virtual Network (VNet) es la red lógica aislada donde viven los recursos de Azure. Cada VNet se define con un espacio de direcciones CIDR (por ejemplo, 10.0.0.0/16) y se subdivide en subredes. Las subredes pueden ser públicas (con recursos que tienen IP pública y acceso directo a internet) o privadas (sin acceso directo desde internet). Crear una VNet con subredes se hace con az network vnet create --resource-group mi-rg --name mi-vnet --address-prefix 10.0.0.0/16 --subnet-name frontend --subnet-prefix 10.0.1.0/24 --location westeurope seguido de az network vnet subnet create --resource-group mi-rg --vnet-name mi-vnet --name backend --address-prefix 10.0.2.0/24.

Network Security Groups (NSG). Los NSGs funcionan como firewall a nivel de subred o interfaz de red. Contienen reglas de entrada y salida que permiten o deniegan tráfico basándose en IP origen/destino, puerto y protocolo. A diferencia de los Security Groups de AWS, los NSGs son stateful pero permiten tanto reglas de permiso como de denegación explícita, con prioridad numérica. Una regla típica para permitir HTTPS sería az network nsg rule create --resource-group mi-rg --nsg-name mi-nsg --name AllowHTTPS --priority 100 --direction Inbound --access Allow --protocol Tcp --destination-port-ranges 443. Los NSGs incluyen reglas por defecto que permiten tráfico dentro de la VNet y desde el balanceador de Azure, y deniegan todo el tráfico de entrada desde internet.

Balanceadores y puertas de enlace. Azure ofrece varios servicios de balanceo: Azure Load Balancer opera en capa 4 (TCP/UDP) para distribución de tráfico de alto rendimiento dentro de una región. Application Gateway opera en capa 7 (HTTP/HTTPS) con funcionalidades de WAF, routing basado en URL, afinidad de sesión y terminación SSL. Azure Front Door combina CDN global, balanceo de carga multi-región y WAF para aplicaciones con presencia global. Para conectividad híbrida, VPN Gateway establece túneles IPsec entre la red on-premises y Azure, mientras que ExpressRoute proporciona conectividad privada dedicada sin pasar por internet público, con anchos de banda de 50 Mbps a 100 Gbps.

VNet Peering y conectividad avanzada. VNet Peering conecta dos VNets de forma privada con tráfico que fluye por la red backbone de Microsoft, sin pasar por internet. El peering puede ser dentro de la misma región (VNet Peering) o entre regiones (Global VNet Peering). Para organizaciones con muchas VNets, Azure Virtual WAN simplifica la topología de red hub-and-spoke con conectividad automatizada entre VNets, sucursales y conexiones VPN o ExpressRoute.

Azure Blob Storage: almacenamiento de objetos. Blob Storage es el equivalente de Azure a Amazon S3. Almacena datos no estructurados como ficheros, imágenes, vídeos, backups, logs y cualquier tipo de blob (Binary Large Object). Se organiza en Storage Accounts (cuentas de almacenamiento) que contienen contenedores, y cada contenedor almacena blobs. Los niveles de acceso (Hot, Cool, Cold, Archive) permiten optimizar coste según la frecuencia de acceso. Hot es para datos accedidos frecuentemente, Cool para datos almacenados al menos 30 días, Cold para 90 días y Archive para datos que raramente se acceden y pueden tolerar horas de rehidratación. Crear una Storage Account y subir un archivo: az storage account create --name mistorage --resource-group mi-rg --location westeurope --sku Standard_LRS seguido de az storage blob upload --account-name mistorage --container-name datos --file archivo.zip --name backups/archivo.zip.

Azure Managed Disks: almacenamiento en bloque. Los Managed Disks proporcionan almacenamiento en bloque para VMs, equivalente a EBS en AWS. Los tipos incluyen Ultra Disk (latencia sub-milisegundo para cargas de bases de datos exigentes), Premium SSD v2 (rendimiento configurable), Premium SSD (alto rendimiento para producción), Standard SSD (equilibrio coste-rendimiento) y Standard HDD (bajo coste para cargas no críticas). A diferencia de Blob Storage, los discos se adjuntan a una VM y se formatean con un sistema de ficheros.

Azure Files: sistema de ficheros compartido. Azure Files ofrece recursos compartidos SMB y NFS totalmente gestionados, accesibles desde VMs en Azure, desde on-premises mediante VPN o ExpressRoute, o desde cualquier sistema que soporte SMB 3.0. Es ideal para compartir ficheros entre aplicaciones, migrar aplicaciones legacy que dependen de file shares, y escenarios híbridos donde se necesita un recurso compartido accesible tanto desde cloud como desde on-premises. Azure File Sync permite sincronizar Azure Files con servidores Windows on-premises, manteniendo una caché local de los ficheros más accedidos.

Contenido ampliado

Puntos clave

• VM, App Service y Functions resuelven necesidades distintas.
• VNet y subredes son la base de conectividad y segmentación.
• No todo almacenamiento en Azure funciona igual.

Checklist operativa

• Elegir el servicio de cómputo según el nivel de control necesario.
• Identificar qué recursos requieren red privada o exposición pública.
• Distinguir si el caso necesita objeto, bloque o base de datos gestionada.

Errores frecuentes

• Usar VMs por costumbre donde App Service sería más simple.
• Exponer recursos sin entender VNet y NSG.
• Confundir Blob Storage con disco adjunto a VM.

Practica sugerida

Compara una pequeña web desplegada en VM frente a App Service y explica ventajas e inconvenientes fundacionales de cada enfoque.

Preguntas de autoevaluacion

• ¿Cuándo usarías App Service en vez de una VM?
• ¿Qué función cumple una VNet?
• ¿Qué diferencia hay entre Blob Storage y Managed Disks?

Cierre

Conocer los servicios core permite interpretar bien casi cualquier diagrama básico de Azure y justificar por qué una solución usa un patrón u otro.