Lo que es igual en cualquier proveedor: responsabilidad compartida, regiones, redes, identidad, cómputo, almacenamiento y costo. Aprenderlo una vez hace que cambiar de nube sea cambiar de nombres.
Armado con los posts publicados al 20 de septiembre de 2026.
Serverless es una decisión operativa, no una forma de escribir funciones. Conviene cuando el escalado y la administración que delegás valen más que el control que entregás.
Idea clave
Cloud es capacidad bajo demanda, elástica y medida. IaaS, PaaS, serverless y SaaS no son una escalera de madurez: son contratos distintos sobre qué administra el proveedor y qué conserva tu equipo. Elegí el contrato que saque trabajo sin quitar el control que la carga necesita.
La nube no te saca responsabilidades: te las cambia de forma. El proveedor absorbe las capas de abajo, donde el trabajo es repetitivo y se puede estandarizar. Te deja las de arriba, donde las decisiones dependen de tu negocio y nadie más las puede tomar. Antes de decir «eso lo maneja la nube», ubicá la fila.
Así te lo toman
En los exámenes de fundamentos de los tres proveedores, el formato es siempre el mismo: te dan una tarea concreta —parchear el sistema operativo invitado, controlar el acceso físico, definir permisos de un bucket, cifrar datos en tránsito— y un modelo de servicio, y hay que decir de quién es. Dos reglas resuelven la mayoría: lo físico es siempre del proveedor, y los datos y sus permisos son siempre del cliente.
Multi-zona por defecto, multi-región por una razón escrita. Las zonas compran independencia de fallas casi gratis; las regiones compran cercanía y supervivencia a cambio de latencia, plata y complejidad. Y antes de sumar la cuarta réplica, contá cuántas piezas tiene que atravesar un pedido: ahí suele estar el nueve que falta.
Así te lo toman
La confusión buscada es entre zona y región. Regla corta: zonas para alta disponibilidad, regiones para latencia geográfica y para recuperación ante desastres, borde para cachear. Y una trampa habitual: replicar en tres zonas no protege de un error de configuración global ni de un borrado de datos, porque eso se replica igual de bien que todo lo demás.
Serverless no es «sin servidores»: es sin capacidad reservada. Conviene cuando la carga es intermitente o impredecible y el trabajo por pedido es corto. Con tráfico alto y constante, la misma carga suele salir más barata en capacidad reservada, y encima sin arranques en frío.
Idea clave
No elegís una tecnología: elegís qué arranca y cuándo lo pagás. Una VM te da el sistema completo y te cobra por tenerlo prendido. Un contenedor te da reproducibilidad y arranques de segundos. Una función te da escalado a cero a cambio de límites y arranques en frío. Escribí la carga en esos términos y la respuesta casi siempre se elige sola.
Así te lo toman
El enunciado describe una carga —«un proceso que corre cinco minutos cada vez que se sube un archivo», «una aplicación heredada que necesita una versión específica del sistema operativo», «una API con tráfico constante»— y pide el servicio más apropiado. La pista está siempre en dos palabras: duración del trabajo y regularidad del tráfico.
El tipo de almacenamiento se elige por el patrón de acceso, no por el tipo de archivo. No es «las fotos van en objetos porque son fotos»: es que se escriben una vez, se leen muchas, no se modifican al medio y varias instancias tienen que alcanzarlas. Cualquier dato con ese patrón va a objetos, sea una foto, un PDF o un respaldo.
Idea clave
Bloques para lo que necesita un disco de verdad; archivos para lo que necesita una ruta compartida; objetos para todo lo demás. Y encima de la elección, dos preguntas que no dependen del tipo: ¿quién puede leerlo? y ¿puedo volver al estado de ayer?
Así te lo toman
Distinguir durabilidad, disponibilidad y respaldo. Durabilidad: no se pierde el dato. Disponibilidad: se puede acceder ahora. Respaldo: se puede volver atrás en el tiempo. Un servicio puede tener durabilidad altísima y aun así perder tu contenido si vos lo borrás y no había versionado.
El prefijo CIDR dice cuántos bits están fijos, y las direcciones son dos a la cantidad de bits libres. Con eso se lee cualquier red. Lo que no se arregla con cuentas es un rango mal elegido: planificá las redes como un recurso de toda la organización, sin superposiciones y con espacio para crecer, antes de crear la primera.
Así te lo toman
Aparece seguido en los exámenes de nivel asociado: ¿cuántas direcciones utilizables tiene una subred /28 en AWS? Son $16 - 5 = 11$. La trampa es contestar 14, que es lo que da la cuenta de redes tradicional, restando sólo la dirección de red y la de broadcast.
Todo lo que no está permitido está prohibido, y una denegación explícita le gana a cualquier permiso. Dale permisos a grupos y roles, no a personas ni a claves fijas; acotá acciones y recursos todo lo posible; y en Google Cloud y Azure acordate de que lo que se da arriba se hereda y se suma.
Así te lo toman
Una pregunta típica de las certificaciones de Azure y de Google Cloud: le diste a alguien un rol de lectura en la suscripción o en la carpeta y ahora querés que no vea un grupo de recursos o un proyecto puntual. Quitarle el rol más abajo no sirve, porque no hay nada que quitar ahí: el permiso viene heredado. Hay que mover la asignación a un ámbito más chico. En Google Cloud, además, se puede agregar una política de denegación; en Azure no, porque las deny assignments no se crean a mano.
Consola, CLI y SDK son clientes de la misma API. Usá la consola para descubrir, la CLI para inspeccionar y repetir, IaC para declarar infraestructura y el SDK para integrar servicios en una aplicación. En todos los casos, verificá contexto y usá identidades temporales con el permiso mínimo.
El costo en la nube es una consecuencia del diseño, no un número que se negocia después. Cuántas horas vive un recurso, cuántos datos salen a internet, cuántas veces se llama a un servicio: eso es lo que se factura. Alertas y etiquetas desde el primer día, apagar lo que no se usa, y comprometer sólo el piso que estás seguro de consumir.
Así te lo toman
Distinguir los modelos de pago y cuándo aplica cada uno: bajo demanda para carga variable o de corta vida, compromiso para carga previsible y constante, interrumpible para trabajo tolerante a fallas, y la capa gratuita con sus límites. Y una pregunta que aparece siempre: quién puede ver y controlar el gasto, que es una cuestión de permisos, no de contabilidad.
Una subred es pública porque su ruta por defecto va a un gateway de internet, no porque lo diga una etiqueta. Las aplicaciones van en subredes privadas y salen por NAT —que vive en la pública, cobra por hora y por gigabyte—, y lo que se pueda alcanzar por un endpoint privado conviene que no pase por ahí.
El balanceador reparte según el chequeo de salud, así que el chequeo es el componente crítico: si depende de la base, una base lenta tira todo abajo. Y el autoescalado tarda minutos en tener capacidad atendiendo: escalá por la métrica que representa el cuello de botella real, con mínimo suficiente para perder una zona y margen para los picos cortos.
El proveedor gestiona la máquina; los datos siguen siendo tuyos, y con ellos el esquema, los índices, las consultas y el plan de crecimiento. Alta disponibilidad y réplicas de lectura no son lo mismo, restaurar crea una instancia nueva y tarda, y el motor estándar deja la puerta de salida abierta.
Una cola reparte cada mensaje a un consumidor; un tema le da una copia a cada interesado; un bus rutea por contenido. Todos entregan al menos una vez, así que el consumidor tiene que ser idempotente, el plazo de visibilidad tiene que superar al peor tiempo de procesamiento, y la cola de mensajes fallidos necesita una alerta y un camino de vuelta.
Serverless cambia tres reglas: se paga por ejecución, escala por invocación y la primera llamada puede pagar un arranque en frío. Encaja en trabajo corto, esporádico y disparado por eventos; se vuelve caro con tráfico alto y parejo, y peligroso cuando escala sin límite contra algo que no escala igual.
Un pedido se resuelve mirando identidad, acción y políticas: una negación explícita gana, y lo que no está permitido está prohibido. Las aplicaciones usan roles con credenciales temporales, las personas y los pipelines entran por federación, y una clave de larga duración es un incidente esperando fecha.
Así te lo toman
Es una pregunta de certificación casi garantizada. El orden importa: una negación explícita gana siempre, por encima de cualquier permiso. Si no hay negación, tiene que existir un permiso explícito; y si no hay nada, el resultado es denegar. Todo lo que no está permitido, está prohibido.
El DNS y la CDN son dos cachés: el de los resolvedores, gobernado por el TTL, y el de los bordes, gobernado por las reglas de caché y la clave de caché. Bajá el TTL antes de migrar, no uses DNS para conmutar rápido, poné hash en los nombres de los archivos y no dejes que nada personalizado entre al borde sin declarar de qué depende.
Así te lo toman
Aparece siempre: ¿por qué no se puede poner un CNAME en ejemplo.com? Porque la norma no permite que un nombre con CNAME tenga otros registros, y la raíz de una zona siempre tiene NS y SOA. Por eso cada proveedor inventó su propio registro de alias —que se resuelve del lado del servidor autoritativo y devuelve direcciones— y por eso el clásico www existía en primer lugar.
El cifrado en reposo es transparente: protege del medio robado, no del permiso de más. Lo que cambia el resultado es administrar la clave uno mismo —permiso separado, cada uso auditado, botón de apagado—, saber qué depende de cada clave antes de tocarla, y tratar un secreto filtrado como comprometido aunque se haya borrado del código.
Así te lo toman
Pregunta habitual: con un balanceador que termina TLS, ¿quién renueva el certificado? Los tres proveedores ofrecen certificados gestionados gratuitos para sus propios balanceadores y CDN, con renovación automática mientras el dominio siga validado. La renovación manual sólo aparece cuando el certificado se termina en una instancia propia, que es justamente el caso que conviene evitar.
La descripción declara el resultado deseado y el estado es lo que permite compararlo con la realidad: remoto, con bloqueo, versionado y tratado como secreto. Leé siempre la columna de destrucción del plan antes de aplicar, usá el mismo código parametrizado para todos los entornos, y aplicá desde un pipeline y no desde una máquina.
Las métricas avisan, las trazas ubican y los logs explican; medí lo que ve el usuario —latencia por percentiles, errores en proporción, tráfico y saturación— y no lo que hace la máquina. Los logs van estructurados, sin secretos y con retención decidida, las métricas con etiquetas de baja cardinalidad, y las alertas sólo donde haya algo concreto que hacer.
Así te lo toman
Es una distinción que se pregunta seguido. El registro de auditoría —CloudTrail, Cloud Audit Logs, Activity Log— guarda quién llamó a qué API del proveedor: quién creó la instancia, quién cambió la política. Los logs de la aplicación guardan lo que hizo el software. Para investigar un incidente de seguridad sirve el primero, y por eso se manda a una cuenta aparte donde nadie de la cuenta original pueda borrarlo.
Los pilares no son una lista para tildar: son preguntas que se contradicen entre sí, y el diseño es elegir qué resignar. Una revisión útil se hace sobre un sistema concreto, con quienes lo operan, anota riesgos con su costo y deja por escrito los que se aceptan.
Multi-zona es barato, resuelve la falla de infraestructura más frecuente y debería ser el piso; multi-región cambia la arquitectura de los datos y hay que justificarlo con el costo de una hora de caída. Y en las dos, la capacidad de sobra y el ejercicio de conmutación son lo que separa el plan de la capacidad real.
Así te lo toman
La pregunta que separa a quien lo pensó de quien lo dibujó: en activo-activo, ¿qué pasa si el mismo registro se modifica en las dos regiones? Hay tres respuestas válidas y ninguna es gratis: repartir por clave para que cada dato tenga una sola región dueña, aceptar consistencia eventual con una regla de resolución de conflictos, o usar una base distribuida globalmente que resuelve el consenso por nosotros y cobra latencia en cada escritura.
RPO es cuántos datos se pueden perder y RTO cuánto puede durar la caída: son decisiones de negocio y de ahí sale la estrategia, no al revés. La replicación no reemplaza a los respaldos —copia el error igual de rápido—, los respaldos van en otra cuenta y con retención inmutable, y el RTO real es el del día que se restauró con cronómetro.
Así te lo toman
RPO se mide hacia atrás desde el incidente y depende de la frecuencia de copia; RTO se mide hacia adelante y depende del procedimiento de recuperación. Un sistema puede tener RPO de cinco minutos —replicación continua— y RTO de ocho horas, si nadie automatizó la promoción de la réplica. Son independientes y se optimizan por separado.
Antes de elegir entre VPN y enlace dedicado hay que resolver los rangos de direcciones, que es lo único que después no se puede cambiar. El peering no es transitivo —a partir de unas pocas redes va un concentrador—, el enlace dedicado necesita su propio respaldo, y si sólo hace falta llegar a un servicio, un punto de acceso privado evita unir las redes.
La cuenta, el proyecto o la suscripción es el límite de aislamiento más fuerte y es gratis: separá primero por entorno y después por sistema. La raíz va vacía, la auditoría se copia a una cuenta donde no se pueda borrar, y las barandas de organización acotan lo que los permisos de adentro pueden lograr.
Así te lo toman
Una pregunta frecuente: alguien es administrador de su cuenta y no puede hacer algo. La explicación es que el permiso efectivo es la intersección entre lo que otorga la política de identidad y lo que permite la baranda de la organización. Si cualquiera de las dos no lo permite, la acción se deniega.
Una landing zone entrega cuentas nuevas con identidad, auditoría, red, presupuesto y barandas ya puestas, en minutos. Prevení lo que nunca tiene excusa, detectá lo que a veces sí, aplicá toda baranda nueva primero en modo reporte, y acordate de que si el camino seguro es lento, los equipos lo esquivan.
El costo se decide al diseñar, así que la práctica consiste en que quien decide vea el precio: etiquetas, paneles por equipo, presupuestos con alertas y estimación en la revisión del cambio. Comprometé la base estable y dejá el pico en bajo demanda, y medí costo unitario en vez de gasto total.
Así te lo toman
La respuesta que se espera no es "todo": es cubrir con compromisos la base estable —el piso de uso que se sostiene todo el mes, mirado sobre varios meses de historia— y dejar el pico en bajo demanda. Comprometer el pico ata a una capacidad que se usa unas horas por día; no comprometer nada paga el precio de lista por lo que igual iba a estar prendido.
La portabilidad es un gradiente con precio: se paga todos los meses y sólo rinde si alguna vez se migra. Mantené portable la lógica de negocio y el cómputo en contenedores, elegí motores estándar para los datos, atate sin culpa en lo periférico, y en vez de construir una abstracción para todo, conocé el costo de salida de las decisiones grandes.
Las cuotas son ajustables y por región; los límites duros son requisitos de diseño. Pedí con anticipación y margen, incluí la región de recuperación, monitoreá el uso contra el tope como cualquier otra saturación, y cuando un límite duro estorba, buscá el patrón que lo evita en vez del formulario.
El SLA no evita la caída: define cuánto crédito se devuelve, hay que reclamarlo y suele exigir haber desplegado con redundancia. Los componentes en serie multiplican sus disponibilidades, así que el número real de un sistema es peor que el de su peor pieza; y lo que sirve el día de la caída —soporte contratado, modo degradado, canal de aviso— tiene que existir desde antes.
Así te lo toman
Aparece en las certificaciones y en las entrevistas: varios servicios en serie multiplican sus disponibilidades. Tres componentes de 99,9 % encadenados dan alrededor de 99,7 %, que son más de dos horas por mes. Por eso el SLA compuesto de un sistema siempre es peor que el del peor de sus componentes, y por eso la redundancia —componentes en paralelo— es la única forma de subirlo.
atlas.matiascaliz.com.ar/materias/fundamentos-de-cloud — si algo de acá no se entiende solo, el post completo lo explica.