Resumen

  • Una hora de interrupción no se convierte automáticamente en una hora de negocio indemnizada. Con las hipótesis explícitas de un mes de 30 días, 43.200 minutos de disponibilidad programada, 60 minutos de interrupción, un ratio de clientes afectados del 100% y ninguna deducción por parada planificada o fuerza mayor, la fórmula publicada para el SLA Enterprise de Cloudflare produce ((60 × 5) × (1 × 5)) / 43.200 = 0,0347222: aproximadamente un 3,47% de la cuota mensual recurrente correspondiente.

    No es una reclamación real ni una estimación de pérdidas. En un mes de 31 días, manteniendo las demás hipótesis, el resultado sería aproximadamente un 3,36%. (Cloudflare)

  • AWS, Google Cloud, Oracle, IBM y Cloudflare muestran diseños distintos, pero la lección económica es común: el SLA asigna una fracción concreta del riesgo operativo mediante una definición contractual. La arquitectura, el perímetro de medición, la base del crédito, los plazos, los registros y las reglas de no acumulación pueden ser tan importantes como el porcentaje nominal.

Una hora, una fórmula

Cloudflare declara un 100% de disponibilidad para el Servicio Enterprise cubierto. Esa frase, por sí sola, parece absoluta. La mecánica del crédito es bastante más específica. El ratio de clientes afectados se calcula a partir de visitantes únicos afectados frente a visitantes únicos totales, y el ratio de crédito combina minutos de interrupción y ese ratio afectado, aplicando un multiplicador de cinco a cada uno antes de dividir por los minutos de disponibilidad programada. La disponibilidad programada, a su vez, excluye las paradas planificadas por el cliente y los periodos atribuibles a fuerza mayor. (Cloudflare)

Con un mes hipotético de 30 días hay 43.200 minutos. Si se supone una interrupción de 60 minutos, todos los visitantes afectados y ninguna deducción, el cálculo es:

((60 × 5) × (1 × 5)) / 43.200 = 0,0347222

Es decir, alrededor del 3,47%. Pero el porcentaje no se aplica a los ingresos perdidos por el cliente, al coste de recuperar una aplicación, a una penalización sufrida frente a terceros ni necesariamente a toda la factura cloud. Cloudflare limita el cálculo del crédito a las cuotas mensuales recurrentes asociadas al Servicio cubierto. El mismo incidente, sobre un mes de 31 días —44.640 minutos bajo idénticas hipótesis— arrojaría aproximadamente un 3,36%. (Cloudflare)

Este ejercicio es deliberadamente ilustrativo. No reproduce una reclamación de ningún cliente, no determina que un incidente concreto sea válido y no estima el daño económico. Lo importante es otra cosa: la promesa nominal y el remedio monetario operan en unidades diferentes. Una mide disponibilidad bajo una definición contractual; el otro devuelve una parte acotada de una cuota.

Ahí empieza la lectura útil de un SLA.

El porcentaje vive dentro de un perímetro

La primera pregunta no debería ser «¿cuántos nueves?», sino «¿qué exactamente debe fallar para que el contador se mueva?».

En AWS EC2, por ejemplo, el compromiso regional del 99,99% requiere que todas las instancias en ejecución estén desplegadas simultáneamente en al menos dos zonas de disponibilidad dentro de la región, salvo el caso particular de regiones con una sola zona. Una instancia individual tiene, en cambio, un compromiso del 99,5%. La definición de indisponibilidad regional exige que las instancias desplegadas conforme a esa arquitectura pierdan simultáneamente la conectividad externa. No son dos formas de expresar la misma promesa: son dos perímetros contractuales distintos. (Amazon Web Services, Inc.)

Google Compute Engine también diferencia el ámbito. El porcentaje mensual de disponibilidad y el crédito se determinan por proyecto y región o, para una instancia individual, por instancia; además, el objetivo depende del tipo de despliegue y del nivel de red. Su definición de periodo de caída requiere al menos un minuto consecutivo: fracciones de minuto o intermitencias inferiores a un minuto no forman un periodo de caída a efectos del SLA. (Google Cloud)

Esto produce una diferencia material entre la experiencia de una carga y la experiencia que el contrato reconoce. Una aplicación puede degradarse de forma económicamente relevante sin que cada degradación cuente del mismo modo para el SLA. También puede ocurrir que una parte de la arquitectura siga sirviendo tráfico y, precisamente por ello, el incidente no cruce el umbral de una definición regional.

No hay contradicción necesaria. Son fronteras de medición. El error consiste en confundirlas con una garantía de resultado extremo a extremo.

La arquitectura también está en la letra pequeña

La topología no es solo una decisión de ingeniería. Puede ser una condición de acceso a una determinada promesa contractual.

AWS hace explícita esa relación en su SLA regional: el 99,99% presupone el despliegue simultáneo en múltiples zonas. IBM formula la misma cuestión desde otra distinción.

Su documentación separa los SLO —objetivos no contractuales— de los SLA que pueden dar derecho a créditos. En el ejemplo de IBM Cloud VPC, el SLO publicado alcanza el 99,999%, pero IBM explica que, para que una carga aproveche plenamente ese objetivo, debe desplegarse de forma altamente disponible en las tres zonas de una región multizona, con al menos tres servidores virtuales y un balanceador. IBM sitúa la resiliencia de la nube bajo responsabilidad del proveedor y la resiliencia y recuperación de la carga bajo responsabilidad del cliente. (IBM Cloud)

La implicación económica es incómoda pero sencilla: comprar una infraestructura que anuncie una cifra elevada no significa haber comprado automáticamente la arquitectura necesaria para aproximarse a esa cifra en la carga real.

La redundancia cuesta dinero. También cuestan la replicación, el balanceo, las pruebas de recuperación y la disciplina operativa. Por eso el porcentaje nominal debe leerse junto al coste de la configuración que lo hace relevante. Un compromiso aparentemente superior puede exigir una estructura de costes diferente; uno aparentemente inferior puede corresponder a una unidad de medición distinta. Compararlos como una tabla de posiciones produciría más ruido que información.

El crédito sigue a la factura, no al daño

La segunda frontera es monetaria.

AWS utiliza tramos del 10%, 30% y 100%. En el SLA regional, la base es la factura mensual de EC2 en la región afectada; en el SLA de instancia, la factura correspondiente a la instancia afectada. Los pagos únicos, incluidos pagos iniciales de Reserved Instances, quedan fuera de esa base. Los créditos se aplican normalmente contra pagos futuros. (Amazon Web Services, Inc.)

Google utiliza tramos del 10%, 25% y 100% para los ámbitos descritos en su SLA. El máximo agregado de crédito en un mes no supera el importe debido por los servicios cubiertos en las regiones que incumplieron el SLO, y el crédito se aplica al uso futuro del servicio. (Google Cloud)

Oracle lleva esta lógica al recurso no conforme. Su política de PaaS e IaaS de 2026 limita los créditos al servicio concreto que no cumplió el compromiso y calcula la base sobre las cuotas netas pagadas por la cantidad de ese servicio realmente utilizada durante el periodo medido. La forma de utilización y caducidad del crédito varía con el modelo de compra. (甲骨文)

Cloudflare hace algo conceptualmente comparable mediante otra fórmula: el crédito se calcula únicamente contra las cuotas mensuales recurrentes asociadas al Servicio cubierto. (Cloudflare)

Por tanto, «100% de crédito» no significa necesariamente «100% de la factura», y mucho menos «100% de la pérdida económica». Significa el 100% de una base definida por el contrato.

Ese denominador es uno de los datos más importantes de cualquier SLA.

El derecho existe solo si se reclama

La tercera frontera es procedimental. Un incidente técnicamente elegible puede no producir crédito si la reclamación no se presenta a tiempo o carece de evidencia suficiente.

Cloudflare exige que el cliente notifique el incidente al soporte dentro de cinco días laborables. La reclamación debe incluir detalles razonables como duración, traceroutes, URL afectadas y medidas adoptadas. La evidencia suficiente debe presentarse antes de que termine el mes de facturación siguiente al mes del incidente; después, Cloudflare valida la reclamación con la información razonablemente disponible. (Cloudflare)

AWS exige abrir un caso en su Support Center y aportar fechas, horas, región o zona, identificadores de recursos y logs que corroboren la indisponibilidad. La solicitud debe llegar antes del final del segundo ciclo de facturación posterior al incidente. La ausencia de la información requerida descalifica el crédito. (Amazon Web Services, Inc.)

Google exige notificar a soporte dentro de los 60 días desde que el cliente se vuelve elegible para el crédito y acompañar la solicitud con logs que muestren los periodos de caída, con fecha y hora. El incumplimiento de ese procedimiento implica perder el derecho al crédito. (Google Cloud)

Oracle exige, también dentro de 60 días desde el incidente, datos que incluyen el servicio, las circunstancias, duración, región, OCID relevantes, intentos de resolución y documentación o logs que permitan validar el incumplimiento. (甲骨文)

Esto convierte la observabilidad en parte de la economía contractual. Si la organización no conserva la evidencia que el SLA pide, puede haber sufrido una caída sin disponer del activo documental necesario para convertirla en una reclamación.

Medir también es asignar responsabilidad

Cloudflare declara expresamente que no asume la monitorización integral del contenido del cliente. La responsabilidad corresponde al cliente, aunque Cloudflare considera los datos procedentes de sistemas independientes de medición comercialmente razonables y utiliza la información disponible para calcular el ratio de clientes afectados. (Cloudflare)

Ese reparto importa porque la medición es un punto de control. Cuanto más compleja, opaca o específica sea, mayor puede ser la distancia entre «sabemos que la carga falló» y «podemos demostrar que falló exactamente la unidad contractual».

Una disciplina útil es mantener una capa de medición común tan delgada, determinista y reproducible como sea posible: tiempo, recurso, región o zona, síntoma observable, alcance, logs y relación con el tráfico real. No sustituye las métricas internas del proveedor. Sirve para que comprador y proveedor puedan reconstruir el mismo incidente sin convertir cada reclamación en una disputa sobre telemetría.

El principio de Heng Lu de separar etiqueta nominal, dependencia y remedio ofrece aquí una buena estructura. La etiqueta es el 99,99%, 99,999% o 100%. La dependencia es aquello que debe existir o fallar para que el número se aplique: zonas, instancias, proyecto, servicio, tráfico, minuto completo. El remedio es el crédito que queda después de la validación. Mezclar las tres categorías produce expectativas que el contrato nunca formuló.

Exclusiones, topes y no acumulación

Los SLA no solo dicen cuándo se paga. También especifican cuándo no.

Cloudflare excluye, entre otros supuestos, problemas derivados de factores fuera de su control razonable, hardware o software del cliente o de terceros y acciones u omisiones ajenas. Los créditos constituyen el remedio exclusivo del SLA; además, el total concedido durante un periodo anual de facturación no puede superar seis meses de cuotas mensuales acumuladas. (Cloudflare)

AWS establece que una misma instancia no puede generar simultáneamente una reclamación bajo el SLA regional y otra bajo el SLA de instancia. Hay que escoger una vía; los créditos no se apilan para esa instancia. (Amazon Web Services, Inc.)

Google aplica la misma lógica entre una instancia individual y las instancias multizona: para una máquina concreta, el cliente obtiene crédito bajo uno de esos ámbitos, no ambos. (Google Cloud)

Oracle dispone que, si un mismo incidente queda cubierto por varias ofertas de SLA, en general se concede el crédito correspondiente a la disposición que produzca el importe mayor, pero no múltiples créditos por el mismo incidente. Además, define los créditos como remedio exclusivo y responsabilidad total respecto del compromiso correspondiente. (甲骨文)

Las reglas de no acumulación son económicamente importantes porque evitan interpretar una arquitectura compuesta como una cartera de indemnizaciones independientes. Una misma caída puede tocar compute, red, balanceo o gestión desde el punto de vista operativo, pero el contrato puede consolidar la respuesta financiera.

Cinco proveedores no forman una clasificación

Nada de esto demuestra que un proveedor sea más o menos fiable que otro. Los documentos comparados describen cómo se mide y repara contractualmente un incumplimiento, no una serie estadística comparable de fallos reales.

Un compromiso del 100% con una fórmula proporcional, un 99,99% regional condicionado a multizona y un SLO del 99,999% acompañado de una arquitectura recomendada no son observaciones de la misma variable.

También deben separarse las condiciones estándar publicadas de los resultados de cada cliente. El resultado efectivo depende del servicio comprado, el pedido concreto, la configuración, la región, la arquitectura desplegada, la facturación, el incidente observado, sus causas y la evidencia disponible.

El SLA público es el mapa. No es el expediente de una reclamación futura.

La distancia entre disponibilidad y exposición

La carga del cliente existe a través de una cadena: usuarios, conectividad, DNS, red, balanceadores, compute, almacenamiento, software, dependencias externas y procesos humanos. Un SLA suele cubrir solo una parte de esa cadena.

Por eso el crédito de servicio y la exposición extremo a extremo pueden divergir radicalmente.

Si una capa cubierta cuesta una fracción modesta de la operación pero sostiene una actividad de alto valor, el crédito máximo puede ser pequeño respecto de la consecuencia empresarial. Si el diseño multizona exigido no existe, una promesa regional puede no ser el mecanismo aplicable. Si faltan logs o identificadores, un fallo reconocido internamente puede ser difícil de convertir en crédito. Si varias cláusulas describen el mismo incidente, una prohibición de acumulación puede reducir la compensación respecto de la suma intuitiva de componentes.

No es un defecto oculto del concepto de SLA. Es precisamente su función: convertir una parte incierta del riesgo en una obligación calculable y acotada.

El problema empieza cuando el comprador pretende que ese instrumento cubra una exposición que nunca fue transferida.

La brecha restante debe administrarse por otras vías. Arquitectura para reducir frecuencia y radio de impacto. Contratación para renegociar perímetros o remedios cuando la criticidad lo justifique. Seguro para ciertas pérdidas que el crédito de servicio no absorbe. Estrategia de salida para evitar que una dependencia difícil de sustituir transforme una interrupción o un cambio contractual en una posición sin alternativas.

El mejor análisis no pregunta qué SLA «gana». Pregunta dónde empieza y dónde termina cada responsabilidad.

Fuentes