47 N3. AWS, Azure y GCP: el mismo supermercado con tres logos
Los tres gigantes venden lo mismo — aprende las equivalencias
AWS, Azure y Google Cloud ofrecen los mismos servicios con distintos nombres: EC2 = Azure VM = Compute Engine. Aprende las ~10 categorías, no el logo — y sabrás moverte en cualquiera de los tres.
47.1 El problema
“Hay que usar AWS” suena a aprender un universo: 200+ servicios, siglas por todas partes, una consola que parece cabina de avión. La verdad liberadora: de esos 200 servicios usas 10, y esos 10 existen idénticos en los tres proveedores. El trabajo no es aprender AWS — es aprender las categorías (compute, storage, base de datos, DNS, identidad, colas…) y luego traducir nombres.
La nube son computadoras de otro que rentas por hora: AWS, Azure, GCP te prestan máquinas, redes y servicios administrados. Pagas por no comprar hardware — y por no administrarlo tú.
Un job es trabajo que se hace sin que el usuario espere: mandar el email, generar el PDF. Va a una cola y un worker lo procesa en segundo plano — la respuesta HTTP sale inmediata.
La terminal (consola, línea de comandos) es la interfaz de texto con el sistema operativo: escribes comandos, lees resultados. Es como hablarle a la computadora por cartas en vez de señalar con el mouse.
Una base de datos es el programa que guarda datos de forma permanente y los responde rápido. Relacional (Postgres): tablas con relaciones. No relacional: documentos, clave-valor, grafos — cada una para una forma de dato distinta.
El DNS es la agenda telefónica de internet: traduce nexus.com → 203.0.113.10. Tu dominio apunta vía DNS a tu load balancer o servidor — por eso “propagación de DNS” toma minutos.
47.2 Cómo lo resuelve un equipo
Nadie memoriza el catálogo. Un equipo real:
- Elige UN proveedor — casi siempre por razones externas: dónde ya está la empresa, créditos gratis, qué sabe el equipo.
- Aprende sus 10 servicios núcleo en ese proveedor.
- Guarda la tabla de equivalencias para cuando toque otro.
El CPU es el cerebro que ejecuta instrucciones; cada núcleo puede ejecutar una cosa a la vez (por eso importan la concurrencia y los procesos paralelos). “CPU-bound” = el límite es el cálculo, no la espera.
El proveedor dominante es AWS (~30% del mercado), luego Azure (~20%, fuerte en empresas con Microsoft), luego GCP (~10%, fuerte en datos/ML). Los PaaS modernos (Render, Vercel, Fly.io) viven encima de estos tres.
IaaS: rentas la máquina, administras todo lo de adentro. PaaS: rentas la plataforma, solo traes tu código. SaaS: usas el software hecho (Gmail, RDS administrado). Menos control, menos trabajo.
47.3 Conceptos nuevos
- Ops Compute: EC2 / Azure VM / Compute Engine — las VMs del cap. N1
- Ops Storage de objetos: S3 / Blob / Cloud Storage — archivos infinitos por HTTP
- D BD administrada: RDS / Azure SQL / Cloud SQL — Postgres sin ser DBA (cap. N4)
- Ops Serverless: Lambda / Azure Functions / Cloud Functions (cap. N5)
- Ops IAM: identidad y permisos — quién puede tocar qué, en los tres
- Ops Regiones y zonas: dónde vive físicamente tu recurso (latencia + leyes)
47.4 La explicación visual
La tabla de equivalencias — la herramienta más útil del capítulo:
| Categoría | AWS | Azure | GCP |
|---|---|---|---|
| Compute (VM) | EC2 | Virtual Machines | Compute Engine |
| Storage objetos | S3 | Blob Storage | Cloud Storage |
| BD relacional | RDS | Azure SQL Database | Cloud SQL |
| BD NoSQL | DynamoDB | Cosmos DB | Firestore |
| Serverless | Lambda | Azure Functions | Cloud Functions |
| Contenedores | ECS/EKS | AKS | GKE/Cloud Run |
| DNS | Route 53 | Azure DNS | Cloud DNS |
| CDN | CloudFront | Azure CDN | Cloud CDN |
| Identidad | IAM | Entra ID (ex-AD) | Cloud IAM |
| Secretos | Secrets Manager | Key Vault | Secret Manager |
| Colas | SQS | Service Bus | Pub/Sub |
| Observabilidad | CloudWatch | Azure Monitor | Cloud Monitoring |
Fíjate el patrón: las categorías son universales porque resuelven problemas universales. Azure renombra más (Entra ID era “Active Directory”), GCP usa nombres descriptivos (“Compute Engine”), AWS usa siglas (“EC2” = Elastic Compute Cloud). Mismo supermercado.
47.5 Implementación
El mismo trabajo — subir el frontend estático de Taskflow (Sección I) a un bucket público — en los tres proveedores. Mira cómo cambian solo los nombres:
# awscli — one profile configured with `aws configure`
aws s3 mb s3://taskflow-web-you # make bucket
aws s3 sync ./dist s3://taskflow-web-you # upload the build
aws s3 website s3://taskflow-web-you --index-document index.html
# + CloudFront distribution in front for HTTPS + caching# az cli — `az login` first
az storage account create -n taskflowwebyou -g my-rg
az storage blob service-properties update \
--account-name taskflowwebyou --static-website --index-document index.html
az storage blob upload-batch -s ./dist -d '$web' --account-name taskflowwebyou# gcloud cli — `gcloud init` first
gsutil mb gs://taskflow-web-you
gsutil -m rsync -r ./dist gs://taskflow-web-you
gsutil web set -m index.html gs://taskflow-web-you
gsutil iam ch allUsers:objectViewer gs://taskflow-web-youTres comandos equivalentes: crear contenedor de objetos → subir build → habilitar como sitio web. La categoría (static hosting en object storage) es la misma; solo cambia el CLI.
Un objeto es una colección de datos con nombre: {name: "Ana", age: 30} — cada dato es una propiedad (clave → valor). Python los llama dict, Go los arma con struct, TS con objetos/interface.
El build (construcción) es el proceso que convierte tu código fuente en algo ejecutable/entregable: compilar TypeScript a JS, empaquetar el frontend, armar la imagen Docker. Lo que se despliega es el resultado del build, no tu código crudo.
Un CLI (Command Line Interface) es un programa que se usa escribiendo comandos en la terminal: git, npm, docker son CLIs. Lo contrario es una GUI (interfaz gráfica con botones).
El tour mental de cualquier consola: todas se organizan igual — región arriba a la derecha (dónde vive el recurso), buscador de servicios (las 10 categorías), IAM (quién eres y qué puedes tocar), Billing (dónde mirar cada semana). Domina esas 4 zonas y cualquier consola deja de intimidar.
Quiero desplegar [mi frontend estático / mi API / ambos] en [AWS /
Azure / GCP] usando el free tier. Dame los comandos CLI exactos en
orden: crear los recursos mínimos, subir el código, exponer la URL, y —
igual de importante — los comandos para DESTRUIR todo al terminar y no
generar costos. Explícame qué hace cada recurso que creamos en
términos de las categorías universales (compute/storage/identidad).47.6 ¿Por qué existen tres?
Lo único que necesitas llevarte: compiten por el mismo pastel, así que convergen a los mismos servicios — la diferencia real no es técnica sino de ecosistema: Azure entra por las empresas que ya pagan Microsoft, GCP por equipos de datos/ML, AWS por ser el primero y tener la comunidad más grande. Para ti, la habilidad transferible es la categoría, no la consola.
| Criterio | Qué significa | Peso real |
|---|---|---|
| El que ya usa tu empresa/cliente | No eliges — vas ahí | El 80% de los casos |
| Créditos/free tier | AWS Activate, Azure for Startups, $300 de GCP | Alto al empezar |
| Ecosistema de tu stack | .NET → Azure natural; ML → GCP Vertex | Medio |
| Multi-cloud “por si acaso” | Usar dos proveedores a la vez | Casi nunca vale el doble de complejidad |
| Proveedores alternos | Cloudflare, DigitalOcean, Hetzner, OVH | Excelentes para cosas específicas y precio |
El mito del multi-cloud: “si AWS cae, tengo Azure” cuesta duplicar todo tu conocimiento e infraestructura. Lo que sí se hace: diseñar sin lock-in innecesario (contenedores portables, Postgres estándar) para que migrar sea posible, no diario.
47.7 Errores comunes
| Error | Por qué pasa | Fix |
|---|---|---|
| La factura sorpresa | Dejaste una VM/bucket/NAT corriendo “por si acaso” | Billing alerts día 1 + destruir lo que no uses |
| Bucket S3 público con datos privados | “Public” suena a “mi sitio web” | Bloqueo de acceso público por defecto; revisa dos veces |
| Trabajar como root/admin | La cuenta raíz puede TODO — incluso vaciar tu cuenta | IAM user con mínimos permisos + MFA |
| Todo en una región lejana | “us-east-1 por defecto” aunque tus usuarios estén en LATAM | Región cerca de usuarios (latencia) y legal del dato |
| Aprender “AWS” en vez de categorías | Memorizas siglas que no transfieren | Esta tabla de equivalencias |
47.8 Buenas prácticas
- Billing alert antes que cualquier recurso. Todos tienen presupuestos con alerta por email — configúrala en tu primera sesión.
- MFA en la cuenta raíz + usuario IAM para el día a día. La cuenta raíz queda guardada como la escritura de la casa.
- Tags en cada recurso (
project:taskflow,env:dev) — en 3 meses no sabrás qué VM era de qué. - Destruye los experimentos. El tutorial terminó = recursos borrados. La nube cobra por existir, no por usar.
47.9 Ejercicio
- Traduce a Azure y GCP: EC2, S3, RDS, Lambda, Route 53.
- Tu app necesita: una VM, una Postgres administrada, storage para imágenes de usuarios, y DNS. Nombra los 4 servicios en AWS.
- ¿Por qué “multi-cloud desde el día 1” casi nunca es buena idea?
Serverless = no piensas en servidores: subes una función y el proveedor la ejecuta por evento, escalando de 0 a 1000 sola. Pagas por ejecución. Lambda (AWS), Cloud Functions (GCP), Azure Functions.
- EC2 → Azure VM / Compute Engine · S3 → Blob Storage / Cloud Storage · RDS → Azure SQL / Cloud SQL · Lambda → Azure Functions / Cloud Functions · Route 53 → Azure DNS / Cloud DNS.
- EC2 (compute), RDS (Postgres administrada), S3 (imágenes como objetos), Route 53 (DNS). Son 4 de las ~10 categorías — ya nombraste medio AWS.
- Porque duplicas el costo de conocimiento y complejidad para cubrir un evento raro (la caída total de un proveedor). Lo correcto: evitar lock-in innecesario (tecnologías portables) y aceptar que migrar es un proyecto, no un interruptor.
47.10 Mini reto
Encuentra los tres problemas en este “deploy a AWS”:
Un deploy es poner tu código a correr en el servidor: copiar la imagen, iniciar el proceso, verificar que responde. El objetivo es que sea aburrido — automático, repetible, con rollback.
aws configure # entered ROOT account keys
aws s3 mb s3://company-user-data
aws s3 sync ./backups s3://company-user-data
aws s3api put-bucket-acl --bucket company-user-data --acl public-read
# done! left the t2.large test instance running "just in case"- Llaves de la cuenta raíz — pueden hacer TODO incluyendo cerrar la cuenta; deben ser credenciales de un usuario IAM con permisos mínimos.
public-readen datos de usuarios — el bucket queda listable y descargable por cualquiera en internet. Es el error que produce las filtraciones masivas de “S3 bucket expuesto” en las noticias.- Instancia corriendo “por si acaso” — una t2.large son ~$70/mes de nada. Regla de la nube: se cobra por existir.
47.11 Vocabulario técnico del capítulo
Un bucle repite una acción por cada elemento o hasta cumplir una condición: for task in tasks hace algo con cada tarea. map y filter son bucles disfrazados de funciones — transforman/filtran colecciones sin for explícito.
Una clase es el molde de un objeto: define qué datos y qué métodos tiene. class Task es el molde; new Task() es una instancia concreta. Go no tiene clases — usa struct + métodos sueltos.
Una CDN (Content Delivery Network) es una red de copias: tu estático se cachea en servidores cercanos al usuario. El de Buenos Aires no viaja a Virginia por una imagen — la recibe del nodo local.
Un caché es una copia rápida de algo costoso de obtener: el resultado de una query pesada, la sesión. Redis es el caché estándar. La regla de oro: cachear es fácil, invalidar (saber cuándo el caché ya no vale) es lo difícil.
Un contenedor es un proceso con mochila propia: corre aislado con su filesystem y sus librerías, pero comparte el kernel de la máquina — por eso arranca en milisegundos donde una VM tarda minutos.
La autenticación responde “¿quién eres?” — login, contraseña, token. Se confunde con autorización (“¿qué puedes hacer?”), que es la pregunta siguiente. Primero te identificas, luego te dejan o no pasar.
La autorización responde “¿qué puedes hacer?”: eres usuario válido (autenticado), pero ¿puedes borrar esta tarea? Se decide por rol o por ownership — y se verifica en cada request, no se recuerda.
HTTPS = HTTP viajando cifrado por TLS: nadie en el camino puede leer ni alterar el tráfico. El certificado es la credencial que prueba que el servidor es quien dice — lo emite una autoridad y hay que renovarlo.