En la lección anterior conocimos qué es Azure y a Contoso Airlines. Ahora toca responder a las dos preguntas que condicionan cualquier diseño posterior: ¿cuánta responsabilidad quiero seguir teniendo? y ¿dónde va a vivir físicamente mi plataforma?

La primera pregunta se responde con los modelos de servicio (IaaS, PaaS, SaaS y serverless) y con el modelo de responsabilidad compartida. La segunda, con la jerarquía geográfica de Azure: geografías, regiones, pares de regiones y zonas de disponibilidad. Ambas decisiones son difíciles de deshacer más tarde —cambiar de región un sistema en producción es un proyecto, no un ajuste—, así que merece la pena entenderlas bien antes de crear el primer recurso.

1. Los modelos de servicio y la analogía del control
2. Comparativa: quién gestiona qué
3. Serverless: el caso especial
4. El modelo de responsabilidad compartida
5. Geografías, regiones y pares de regiones
6. Zonas de disponibilidad y conjuntos de disponibilidad
7. Cómo elegir región
8. SLA y su relación con la redundancia
9. La decisión de Contoso Airlines
10. Errores Comunes y Consejos
11. Ejercicios
12. Conclusión

La analogía más útil para entender los modelos de servicio es cómo llegas a tu destino cuando viajas. En todos los casos llegas; lo que cambia es cuánto trabajo haces tú y cuánto control conservas.

Traducido a informática:

Azure te entrega la infraestructura virtualizada: máquinas virtuales, discos, redes. Tú instalas el sistema operativo (o eliges una imagen), lo parcheas, instalas el software, lo configuras y lo mantienes.

• Ejemplos en Azure: Máquinas Virtuales, Discos administrados, Redes virtuales.
• Cuándo usarlo: migraciones rápidas de sistemas existentes, software que exige control del sistema operativo, cargas heredadas.
• En Contoso: el motor de disponibilidad heredado, que depende de una versión concreta de una librería, empezará su vida en Azure como máquina virtual (módulo 2).

Azure te entrega una plataforma lista para ejecutar tu código o tus datos. No ves el sistema operativo ni parcheas nada: subes la aplicación y funciona.

• Ejemplos en Azure: App Service, Azure SQL Database, Azure Database for PostgreSQL, Azure Container Apps.
• Cuándo usarlo: aplicaciones nuevas o modernizables, cuando quieres dedicar el tiempo del equipo al producto y no al mantenimiento.
• En Contoso: la web Contoso Reservas y la API de Disponibilidad acabarán en App Service, y la base de datos de reservas en Azure SQL Database (módulos 2 y 3).

Consumes una aplicación terminada por suscripción. No hay nada que desplegar.

• Ejemplos: Microsoft 365, Dynamics 365, GitHub. Desde el punto de vista del usuario, también Azure DevOps.
• En Contoso: el correo corporativo ya es Microsoft 365; no hay ninguna intención de gestionarlo.

Esta tabla es la referencia para el resto del curso. Marca quién se ocupa de cada capa. C = cliente, M = Microsoft.

Fíjate en las dos primeras filas: los datos y las identidades son siempre responsabilidad del cliente, en todos los modelos. Es la idea más importante de la lección y el motivo por el que el módulo 4 existe.

Serverless ("sin servidor") es un nombre desafortunado: servidores hay, pero tú no los ves, no los dimensionas y no pagas cuando no se usan. Es una evolución del PaaS con dos rasgos propios:

• Escalado automático hasta cero. Si nadie llama a tu función, no hay instancias y no hay coste de cómputo.
• Facturación por ejecución. Se paga por número de invocaciones y por tiempo de ejecución consumido, no por hora de servidor encendido.

• Ejemplos en Azure: Azure Functions, Logic Apps, Event Grid, Azure Container Apps con escalado a cero.
• En Contoso: la generación del PDF de la tarjeta de embarque tras confirmar una reserva es un caso de libro para una función; ocurre a ráfagas y no justifica un servidor encendido las 24 horas. Se construirá en el módulo 6.

Este modelo responde a la pregunta que hace todo responsable de seguridad la primera semana: "si Microsoft está certificado, ¿de qué me tengo que preocupar yo?".

La regla general: Microsoft es responsable de la seguridad de la nube; el cliente es responsable de la seguridad en la nube.

Tres ejemplos concretos aplicados a Contoso, para que no quede en abstracto:

Azure organiza su presencia física en niveles. De mayor a menor:

• Geografía: un área del mundo que agrupa regiones y que respeta los límites de residencia de datos y cumplimiento de ese territorio (por ejemplo, Europa). Los datos de una geografía no salen de ella salvo que tú lo configures explícitamente.
• Región: un conjunto de centros de datos dentro de un perímetro de baja latencia, con un nombre comercial (West Europe, North Europe, Spain Central). Es la unidad que eliges al crear un recurso.
• Par de regiones: cada región está emparejada con otra de la misma geografía, situada normalmente a más de 300 km, con dos propiedades útiles:
  • Algunos servicios replican datos automáticamente a la región pareja (por ejemplo, el almacenamiento con redundancia geográfica, que se ve en el módulo 2).
  • En una interrupción amplia, Microsoft prioriza la recuperación de una región del par y planifica las actualizaciones de plataforma de forma escalonada, no simultánea, para las dos.

Ejemplos de pares en Europa: West Europe (Países Bajos) ↔ North Europe (Irlanda); France Central ↔ France South; Spain Central está emparejada dentro de la misma geografía europea.

Nota importante: Microsoft está introduciendo también regiones no emparejadas apoyadas en zonas de disponibilidad. Comprueba siempre en la documentación oficial el par vigente de la región que uses, porque el mapa evoluciona.

Aquí es donde se decide de qué fallo concreto te proteges. Cada nivel cubre un tipo de desastre distinto y ninguno sustituye a los demás.

Un conjunto de disponibilidad es un concepto de IaaS. Al colocar varias máquinas virtuales en él, Azure las reparte entre:

• Dominios de error: grupos de servidores que comparten alimentación y conmutador de red. Distribuir entre dominios de error evita que un fallo eléctrico se lleve todas tus VM.
• Dominios de actualización: grupos que Azure reinicia por separado durante el mantenimiento planificado. Nunca reinicia dos dominios a la vez.

Una zona de disponibilidad es uno o varios centros de datos físicamente separados dentro de la misma región, con alimentación, refrigeración y red independientes, conectados entre sí por fibra de muy baja latencia. Las regiones habilitadas tienen al menos tres zonas.

Regla práctica: conjunto de disponibilidad para IaaS heredada dentro de un centro de datos; zonas de disponibilidad cuando la región las ofrece y el servicio las soporta; par de regiones para el desastre grande.

No hay una respuesta universal. Se evalúan cinco criterios y se documenta la decisión.

Sobre RGPD y soberanía, tres puntos que a menudo se confunden:

1. Elegir una región europea mantiene los datos en reposo dentro de esa geografía, pero determinados metadatos y servicios globales (como el propio directorio de Microsoft Entra ID) tienen su propio ámbito. Consúltalo si tu sector lo exige.
2. La replicación geográfica puede mover datos a la región pareja: comprueba que esa pareja está también dentro de la geografía admisible (en Europa, lo está).
3. La responsabilidad de clasificar qué datos son personales y aplicar cifrado y retención es siempre del cliente, como vimos en el apartado 4.

El SLA (acuerdo de nivel de servicio) es el compromiso de disponibilidad que Microsoft asume para un servicio, con una compensación económica en forma de crédito si no se cumple. Dos matices que casi nadie explica:

• El crédito no cubre tu pérdida de negocio. Si Contoso deja de vender billetes tres horas, el crédito en la factura no compensa la venta perdida. El SLA es una señal de calidad, no un seguro.
• El SLA depende de cómo despliegues. No es un número fijo del servicio: mejora si añades redundancia.

Valores orientativos para máquinas virtuales (consulta siempre las cifras vigentes en el documento oficial de SLA, porque se actualizan):

Y el punto que más sorprende: cuando compones servicios, las disponibilidades se multiplican. Si la web tiene 99,95 %, la base de datos 99,99 % y el almacenamiento 99,9 %, y la venta necesita los tres a la vez:

Es decir, unos 70 minutos al mes en el peor caso, peor que cualquiera de las piezas por separado. Por eso el diseño de disponibilidad se hace sobre el recorrido completo del usuario, no servicio a servicio.

Marta Ríos documenta así la decisión, que heredaremos durante todo el curso:

• Geografía: Europa. Contoso vende a ciudadanos de la UE y sus datos personales no salen de la geografía europea.
• Región principal: West Europe (Europa Occidental). Motivos: tiene el catálogo de servicios más completo de la geografía, dispone de zonas de disponibilidad, y la latencia desde España es de pocas decenas de milisegundos, aceptable para la venta.
• Región secundaria: North Europe (Europa del Norte), que es su región pareja. Se usará para copias con redundancia geográfica y, más adelante, para la recuperación ante desastres (módulo 7).
• Dentro de West Europe: los componentes críticos (web y API) se repartirán entre al menos dos zonas de disponibilidad.
• Lo que Contoso NO hace: no despliega activo-activo en las dos regiones. Sería el doble de coste y su objetivo de recuperación (unas horas) no lo justifica. Es una decisión consciente, no un olvido.

• Elegir región por costumbre o por cercanía aparente. "Como estamos en España, uso la región más cercana" es un criterio incompleto: puede no tener el servicio que necesitas o tener otro precio. Evalúa los cinco criterios.
• Confundir zonas de disponibilidad con regiones. Las zonas protegen de la caída de un edificio dentro de la misma región; no protegen de un desastre regional. Y los recursos de una zona no son accesibles como si estuvieran en otra región.
• Creer que PaaS elimina toda responsabilidad. En PaaS sigues siendo responsable de los datos, las identidades, la configuración y el código. Solo desaparece el sistema operativo.
• Pensar que el SLA garantiza tu disponibilidad. Solo cubre el servicio de Microsoft, y solo con la configuración que hayas desplegado. Un despliegue de instancia única no tiene el SLA del despliegue redundante.
• Olvidar que la replicación no es una copia de seguridad. Si borras un registro por error, la replicación replica el borrado. Necesitas copias con retención (módulo 7).
• Mezclar regiones sin motivo. Poner la aplicación en una región y la base de datos en otra añade latencia a cada consulta y coste de salida de datos. Mantén juntos los componentes que se hablan mucho.
• Consejo de coste: si estás practicando, todo esto todavía no cuesta nada porque no hemos creado recursos. Pero recuerda que replicar en varias zonas multiplica las instancias, y por tanto la factura. Cada nivel de disponibilidad tiene un precio; elige el que el negocio necesita, no el máximo posible.

Para cada componente de la plataforma de Contoso, indica qué modelo de servicio es el más adecuado (IaaS, PaaS, serverless o SaaS) y justifícalo en una frase:

1. La web pública Contoso Reservas, reescrita como aplicación moderna.
2. El motor de disponibilidad heredado, atado a una versión concreta de una librería del sistema.
3. La generación del PDF de la tarjeta de embarque cuando se confirma una reserva.
4. El correo corporativo del personal.
5. La base de datos de reservas, que necesita copias automáticas y parcheado sin intervención.

Clasifica cada incidente como responsabilidad de Microsoft o de Contoso, y explica por qué en una frase:

1. Un ataque de fuerza bruta consigue entrar con la contraseña débil de una cuenta administrativa sin autenticación multifactor.
2. Un corte de refrigeración deja sin servicio un centro de datos de una zona en West Europe.
3. La máquina virtual del motor de disponibilidad lleva ocho meses sin actualizaciones de seguridad del sistema operativo.
4. Un fallo del almacenamiento subyacente de Azure SQL Database provoca 20 minutos de indisponibilidad.

Contoso quiere que la venta de billetes sobreviva a estos tres escenarios, con el mínimo coste posible en cada caso. Indica qué mecanismo usarías:

1. Microsoft reinicia el host físico donde corre la VM durante el mantenimiento mensual.
2. Un incendio deja sin servicio el edificio donde está una zona de West Europe.
3. Un operador borra por error toda la tabla de reservas del último mes.

Además, calcula la disponibilidad compuesta de un recorrido de compra que atraviesa un balanceador (99,99 %), la web (99,95 %) y la base de datos (99,99 %).

Solución 1:

Solución 2:

1. Contoso. Las identidades y su protección (MFA, políticas de contraseña) son siempre del cliente, en cualquier modelo.
2. Microsoft. Infraestructura física del centro de datos. Ahora bien, si Contoso desplegó en una sola zona, la consecuencia sí es responsabilidad de su diseño.
3. Contoso. Es IaaS: el parcheado del sistema operativo huésped es del cliente.
4. Microsoft. Es PaaS y el fallo está por debajo de la capa que gestiona el cliente; aplica el SLA del servicio.

Solución 3:

1. Conjunto de disponibilidad (o, mejor, zonas si el servicio las admite): reparte las VM en dominios de actualización distintos para que el mantenimiento no las reinicie a la vez. Coste añadido: ninguno más allá de tener más de una instancia.
2. Zonas de disponibilidad: instancias repartidas en al menos dos zonas de West Europe, tras un balanceador con redundancia de zona.
3. Copias de seguridad con retención y restauración a un punto en el tiempo. Ni la replicación de zona ni la geográfica sirven aquí: replicarían el borrado.

Disponibilidad compuesta:

Unos 30 minutos de indisponibilidad al mes, peor que cualquiera de los tres componentes por separado.

Los modelos de servicio describen cuánta responsabilidad cedes: IaaS te deja el sistema operativo, PaaS te lo quita, serverless además te quita la capacidad ociosa y SaaS te entrega la aplicación hecha. Sea cual sea el modelo, el modelo de responsabilidad compartida deja siempre en tu lado los datos, las identidades y la configuración: esa es la frase que hay que recordar de esta lección.

En el plano físico, Azure se organiza en geografías → regiones → zonas de disponibilidad, con pares de regiones para el desastre grande y conjuntos de disponibilidad para el fallo de bastidor. Cada nivel protege de un tipo de fallo distinto, tiene su coste y se refleja en el SLA, que además se multiplica a la baja cuando compones servicios. Contoso Airlines ha decidido West Europe como región principal, North Europe como pareja y reparto en varias zonas para los componentes críticos.

Con el "qué modelo" y el "dónde" resueltos, ya solo falta lo práctico: crear la cuenta. En la siguiente lección, Crear y configurar tu cuenta de Azure, veremos qué necesitas para registrarte, qué incluye la cuenta gratuita, qué tipos de suscripción existen y —muy importante— cómo poner un presupuesto y una alerta de gasto antes de crear tu primer recurso.