Teoría — fundamentos para decidir

Antes de abrir una calculadora necesitas un modelo mental. En este bloque aprenderás a pasar de una necesidad —por ejemplo, «el catálogo deja de responder en Navidad»— a una decisión que indique alternativa, responsabilidades, supuestos de coste y condiciones de revisión.

1. Qué es la computación en la nube

La computación en la nube consiste en obtener recursos informáticos como servicios configurables: cómputo, almacenamiento, bases de datos, redes o aplicaciones. La organización puede solicitar capacidad cuando la necesita, ajustar parte de esa capacidad y medir su uso sin comprar previamente todo el hardware físico.

La nube no es simplemente «el ordenador de otra persona». El proveedor opera centros de datos y ofrece servicios estandarizados; el cliente sigue tomando decisiones sobre sus datos, configuración, accesos, arquitectura, uso y gasto.

Infraestructura local	Nube pública
La organización compra o contrata equipos, red y almacenamiento.	El proveedor ofrece recursos compartidos con separación lógica entre clientes.
La capacidad suele decidirse antes de conocer la demanda real.	La capacidad puede ajustarse, si el servicio y el diseño lo permiten.
La organización mantiene el hardware y las capas de software que utilice.	El proveedor mantiene la infraestructura física; el cliente conserva responsabilidades.
Predomina la inversión inicial, aunque también hay gastos periódicos.	Predomina el gasto variable, aunque puede haber compromisos y costes mínimos.

CapEx es inversión en bienes que se utilizan durante varios años, como comprar un servidor. OpEx es gasto operativo recurrente, como pagar mensualmente por capacidad utilizada. No toda compra local es CapEx ni todo coste cloud es puramente variable, pero la distinción ayuda a comparar cuándo se paga y qué riesgo económico se asume.

2. Seis ventajas que debes saber explicar

AWS suele presentar seis ventajas económicas y operativas de la nube. Son posibilidades, no promesas automáticas.

Ventaja	Qué significa	Condición o límite
Cambiar gasto fijo por gasto variable	Evitar parte de la compra inicial y pagar según configuración o consumo.	Un recurso mal dimensionado o abandonado también cuesta.
Beneficiarse de economías de escala	El proveedor compra y opera infraestructura para muchos clientes.	El precio público no garantiza que cualquier arquitectura sea más barata.
Dejar de adivinar capacidad	Aumentar o reducir recursos cuando cambia la demanda.	Hace falta medir, diseñar el escalado y comprobar cuotas.
Ganar rapidez y agilidad	Aprovisionar servicios en minutos en lugar de esperar una compra física.	La rapidez técnica no sustituye pruebas, seguridad ni aprobación.
Reducir el mantenimiento de centros de datos	El proveedor mantiene edificio, energía, refrigeración y hardware físico.	El cliente sigue manteniendo las capas que le correspondan.
Alcanzar otras ubicaciones con más facilidad	Elegir infraestructura próxima a usuarios o requisitos.	Hay que comprobar región, latencia, normativa, disponibilidad y coste.

Una explicación correcta relaciona la ventaja con el caso: «la tienda podría aumentar capacidad durante la campaña» es mejor que «la nube escala».

3. Dos clasificaciones que no debes mezclar

3.1 Modelos de despliegue

Indican dónde y para quién se ofrece la infraestructura.

Nube pública: recursos de un proveedor disponibles para diferentes clientes con separación lógica.
Nube privada: entorno cloud dedicado a una organización, propio o gestionado.
Nube híbrida: integra recursos privados o locales con nube pública.

P01 se centra en nube pública. Nombrar nube privada o híbrida sirve para comprender que migrar no obliga a moverlo todo.

3.2 Modelos de servicio

Indican qué capas administra cada parte. Las siglas proceden del inglés: IaaS, Infrastructure as a Service (infraestructura como servicio); PaaS, Platform as a Service (plataforma como servicio); y SaaS, Software as a Service (software como servicio).

Imagina que La Cesta Verde quiere conservar su aplicación. Con IaaS alquilaría una máquina virtual: el proveedor mantiene el hardware, pero la tienda instala y actualiza el sistema operativo y su aplicación. Con PaaS publicaría su código sobre una plataforma que opera el proveedor, siempre que sea compatible. Con SaaS contrataría una aplicación terminada y tendría que comprobar si sus funciones y la exportación de datos cubren sus necesidades. Cambia el reparto de trabajo y también la libertad para modificar el servicio.

La clasificación de despliegue responde a otra pregunta: una máquina IaaS puede formar parte de una nube pública o privada. Por eso «pública» e «IaaS» no son alternativas excluyentes.

Modelo	El proveedor mantiene principalmente	La organización mantiene principalmente	Ejemplo de uso
IaaS	Centro de datos, hardware, red física y virtualización	Sistema operativo, aplicación, configuración, identidades y datos	Alquilar una máquina virtual para la web
PaaS	Infraestructura, sistema operativo y plataforma de ejecución	Código, datos, usuarios y configuración de la aplicación	Publicar código en una plataforma gestionada
SaaS	Aplicación y capas subyacentes	Usuarios, configuración de uso, información introducida y cumplimiento	Contratar una aplicación de reservas terminada

4. Responsabilidad compartida

El proveedor es responsable de la seguridad de la nube: instalaciones, hardware y las capas que gestiona. El cliente es responsable de la seguridad en la nube: aquello que configura, instala, permite o almacena.

Cuanto más gestionado es el servicio, más capas opera el proveedor, pero nunca desaparecen todas las responsabilidades del cliente.

En IaaS, si la tienda no actualiza el sistema operativo, esa omisión sigue siendo su responsabilidad.
En PaaS, el proveedor actualiza la plataforma, pero la tienda debe proteger su código, datos y accesos.
En SaaS, el proveedor mantiene la aplicación, pero la academia debe retirar cuentas antiguas y configurar permisos adecuados.

5. Una aplicación necesita varias categorías

Una tienda online o una academia no es «una web» sin más. Puede necesitar:

cómputo, donde se ejecuta la lógica;
almacenamiento, donde se conservan imágenes o documentos;
base de datos, donde se registran productos, reservas o pedidos;
red y entrega, para comunicar componentes y atender a usuarios;
seguridad e identidad, para decidir quién puede hacer qué;
operaciones, para observar, actualizar y recuperar el servicio.

AWS organiza sus servicios en estas y otras categorías. En la estimación guiada usarás Amazon EC2 como ejemplo de cómputo, Amazon S3 como almacenamiento de objetos y Amazon RDS como base de datos relacional gestionada. Son piezas de un modelo didáctico, no una arquitectura definitiva.

Sigue un pedido simulado: una persona solicita el catálogo; la aplicación que se ejecuta en EC2 consulta los productos registrados en RDS y devuelve una página que referencia fotografías guardadas en S3. La red permite las peticiones entre esos componentes y el navegador. Cada parte tiene una función y una medida de uso distinta: horas de cómputo, datos almacenados y solicitudes, por ejemplo. En P01 solo estimarás algunas de esas partidas; todavía no configurarás sus conexiones.

Una Región es un área geográfica donde AWS agrupa infraestructura. Una Zona de Disponibilidad es una ubicación aislada dentro de una Región. En P01 seleccionarás US East (N. Virginia), código us-east-1, porque es una de las regiones autorizadas del curso. La infraestructura global se desarrollará más adelante.

6. Adoptar, migrar y decidir por fases

Adoptar nube puede significar crear una carga nueva. Migrar significa mover o transformar una carga existente. Copiar una aplicación sin entender sus dependencias puede trasladar también sus problemas.

Un proceso inicial razonable es:

Inventariar: aplicación, datos, usuarios, dependencias y responsables.
Evaluar: problema que se quiere resolver, riesgos, coste y restricciones.
Planificar: alternativa, piloto, criterio de éxito y vuelta atrás.
Probar: validar con un alcance pequeño y datos ficticios o controlados.
Comprobar: rendimiento, seguridad, coste y recuperación.
Revisar: ampliar, corregir, mantener un modelo híbrido o detener la migración.

AWS Cloud Adoption Framework (AWS CAF) ayuda a no olvidar decisiones organizativas. Sus seis perspectivas pueden convertirse en preguntas.

Perspectiva	Pregunta útil
Negocio	¿Qué resultado necesita la organización y cómo medirá la mejora?
Personas	¿Quién sabe operar el servicio y quién actuará ante una incidencia?
Gobernanza	¿Qué límites, responsables y reglas controlarán decisiones y gasto?
Plataforma	¿Qué aplicaciones, datos y dependencias forman la carga?
Seguridad	¿Qué información se trata y quién debe acceder?
Operaciones	¿Cómo se observará, mantendrá, recuperará y revisará el servicio?

No memorices el marco como una lista aislada. Úsalo para descubrir preguntas pendientes.

7. Del precio a la factura

Estos conceptos están relacionados, pero no son equivalentes:

Concepto	Qué representa	Qué no hace
Precio	Tarifa de una unidad: hora, GB-mes, solicitud u otra medida.	No describe por sí solo el uso total.
Estimación	Proyección previa que combina precios con supuestos de uso.	No limita el gasto ni garantiza el importe final.
Presupuesto	Importe objetivo con el que se compara el coste real o previsto.	No es una factura ni bloquea necesariamente el consumo.
Consumo	Uso real registrado de los recursos.	No incluye por sí solo impuestos o acuerdos comerciales.
Factura	Cargos reales del periodo, con los ajustes aplicables.	No sustituye la planificación previa.

La tienda empieza con una previsión: elige cantidades y aplica tarifas para obtener una estimación. Después compara esa previsión con el presupuesto autorizado. Si finalmente desplegara el servicio, mediría consumo real y revisaría los cargos facturados. Una desviación puede deberse a un supuesto de uso incorrecto o a una partida olvidada; reducir una cifra en la calculadora no reduce por sí solo un recurso real.

8. Qué hace variar el coste

El coste puede depender de:

Región y modelo de pago;
cantidad y horas de cómputo;
capacidad almacenada en GB o GiB y clase de almacenamiento;
número de solicitudes u operaciones;
transferencia de datos, especialmente la salida a Internet;
copias, instantáneas, registros y monitorización;
direcciones IPv4 públicas y componentes de red;
soporte, descuentos, compromisos e impuestos.

En la práctica partirás de 730 horas al mes, un supuesto normalizado para representar un recurso disponible continuamente durante un mes medio. No significa que todos los meses tengan exactamente 730 horas ni que las horas de atención de una tienda sean 24/7.

Unidades y opciones que encontrarás

En la notación estándar, un GB representa 1.000.000.000 bytes y un GiB, 1.073.741.824 bytes. Sin embargo, AWS S3 etiqueta como «GB» cantidades binarias equivalentes a GiB. Conserva el valor y la unidad del campo y consulta su definición; no conviertas automáticamente una etiqueta GB de S3 a decimal. Un GB-mes expresa almacenamiento durante un periodo: mantener 10 GB medios durante un mes representa 10 GB-mes. Es distinto de transferir 10 GB al mes o de añadir 10 GB nuevos cada mes. Registra también la unidad de las solicitudes: 1.000 operaciones equivalen a 1 cuando el campo pide miles.

En EC2, On-Demand indica pago por uso sin un compromiso prolongado; Shared indica que el hardware físico puede compartirse con otros clientes, con aislamiento entre instancias. El nombre t3.micro identifica una clase de máquina, no un precio ni una garantía de capacidad suficiente para la tienda.

En RDS, Single-AZ sitúa la instancia en una sola Zona de Disponibilidad; no incluye el despliegue redundante Multi-AZ. gp3 identifica un tipo de almacenamiento SSD de uso general. Las IOPS miden operaciones de entrada/salida por segundo: en este ejercicio no añadirás rendimiento aprovisionado adicional. Proxy gestiona conexiones a la base de datos, Database Insights permite observar su funcionamiento y Extended Support cubre versiones antiguas más allá del soporte estándar. Solo necesitas reconocer esas opciones para registrar las exclusiones del modelo.

9. Estimar y controlar

AWS Pricing Calculator permite preparar una previsión de coste sin crear recursos. En P01 no necesitas cuenta AWS, credenciales ni Start Lab.

Un flujo profesional sencillo es:

describir la necesidad;
separar hechos de supuestos;
elegir región y unidades;
configurar servicios;
revisar opciones activadas por defecto;
declarar qué falta;
exportar el resultado;
modificar un parámetro y comparar;
fijar una regla de revisión.

El control simulado debe indicar umbral, responsable, frecuencia y acción. No usarás Billing, Budgets ni Cost Explorer; esas herramientas no son necesarias para demostrar el método de P01.

Ejemplo resuelto: calcular antes de decidir

Las siguientes tarifas son ficticias y no corresponden a precios AWS. Una asociación estudia un modelo mensual simplificado:

Partida	Cantidad	Tarifa ficticia	Coste mensual
Cómputo	100 h	0,04 USD/h	4,00 USD
Almacenamiento	20 GB-mes	0,10 USD/GB-mes	2,00 USD
Solicitudes	2 miles	0,50 USD/mil	1,00 USD
Subtotal C0			7,00 USD

Cada partida se calcula como cantidad × tarifa; después se suman los costes del mismo periodo y moneda. Si el almacenamiento aumenta a 30 GB-mes, cuesta 3,00 USD y el subtotal C1 pasa a 8,00 USD. La variación absoluta es 8 − 7 = 1 USD; la porcentual, 1 ÷ 7 × 100 ≈ 14,29 %. El denominador es el coste inicial.

Si el presupuesto fuera 10 USD, quedarían 2 USD de margen en las partidas calculadas. Todavía faltarían red, copias y otras exclusiones: estar por debajo del límite no demuestra que el servicio completo quepa en él. Una regla aplicable sería que la persona responsable revise la previsión semanalmente y solicite autorización si aumenta más del 10 %. En este ejemplo se activa esa revisión aunque el subtotal siga por debajo de 10 USD.

10. Soporte como decisión operativa

Los planes de soporte determinan canales y tiempos de ayuda, y pueden añadir coste. A fecha de comprobación documental 21/10/2026, AWS enumera Basic, Business Support+, Enterprise Support y Unified Operations. No contratarás ni modificarás soporte: solo decidirás si el caso requiere comparar un plan de pago.

El catálogo es variable y debe revisarse antes de impartir el bloque.

Ejemplo resuelto: de la necesidad a la decisión

Necesidad: la web de una biblioteca escolar se queda sin servicio cuando falla su único ordenador.

Alternativa: estudiar una plataforma gestionada antes que administrar una máquina virtual.

Responsabilidad: la biblioteca seguirá gestionando cuentas, datos publicados y permisos.

Supuesto de coste: 12 meses de servicio, 5 GB de documentos y pocas operaciones diarias.

Condición de revisión: descartar o renegociar la alternativa si supera el presupuesto o no permite exportar los datos.

La conclusión no es «la nube es mejor». Es una hipótesis comprobable que conecta problema, alternativa, responsabilidad, coste y condición de revisión.

Comprobación antes de practicar

Sin mirar las tablas, intenta explicar:

la diferencia entre nube pública e IaaS;
una ventaja de cloud y la condición necesaria para que sea real;
una responsabilidad que conserva el cliente en SaaS;
la diferencia entre estimación, presupuesto y factura;
por qué una Región forma parte de los supuestos.

Si alguna respuesta no está clara, vuelve al apartado correspondiente. Después comienza P01-A01.