Letra ChicaDiccionario
La letra chica del multicloud: dónde se rompe la analogía entre Azure, AWS y GCP, con fuentes oficiales y Terraform verificado.
Cola de mensajesasync-event
Desacople productor/consumidor con entrega garantizada y reintentos.
GCP
- Pub/Sub (pull subscription)
Es pub/sub; una suscripción pull se comporta como cola competitiva.
⚠ Dónde se rompe la analogía
Peek-lock (Service Bus), visibility timeout (SQS) y ack deadline (Pub/Sub) son el mismo mecanismo: entrega at-least-once. Ninguno te exime de consumidores idempotentes.
Cola de mensajes fallidos (dead-letter)async-event
Destino de los mensajes que no se pudieron procesar tras N intentos, para inspeccionarlos y reprocesarlos sin bloquear la cola principal.
Azure
- Service Bus dead-letter subqueue ($DeadLetterQueue)
Es una subcola automática de cada cola; no se crea aparte.
AWS
- SQS dead-letter queue (redrive policy)
Es otra cola SQS, vinculada con redrive_policy.
GCP
- Pub/Sub dead-letter topic
Es otro topic, y necesita su propia suscripción para no perder los mensajes.
⚠ Dónde se rompe la analogía
Los tres mueven el mensaje tras N entregas fallidas, pero el 'contenedor' cambia: subcola implícita (Azure), cola separada (AWS) o topic separado que necesita suscripción (GCP). En GCP un dead-letter topic sin suscripción descarta los mensajes.
Orquestación de workflowsasync-event
Coordinación de pasos con estado, reintentos y ramas sin servidor propio.
Ruteo de eventosasync-event
Bus de eventos que filtra y enruta eventos de servicios y aplicaciones hacia destinos.
Cómputo dirigido por eventoscompute-web
Ejecución de código/contenedores disparada por eventos o mensajes, con escala a cero.
AWS
- AWS Lambda
- Amazon ECS on Fargate
Puede bajar a 0 tareas con Application Auto Scaling, pero no es escala-a-cero nativa por evento.
Gestión de APIscompute-web
Gateway de APIs con autenticación, cuotas, transformación y portal de desarrolladores.
⚠ Dónde se rompe la analogía
API Management y Apigee son plataformas completas (portal, monetización, políticas); Amazon API Gateway y Google API Gateway son gateways más livianos. Comparar APIM con API Gateway de AWS solo por precio es comparar productos de categorías distintas.
Kubernetes gestionadocompute-web
Control plane de Kubernetes operado por el proveedor.
⚠ Dónde se rompe la analogía
La identidad de los pods es donde más difieren: AKS usa Microsoft Entra Workload ID (federación OIDC), EKS usa Pod Identity o IRSA, y GKE usa Workload Identity Federation for GKE. El concepto es el mismo (token del service account de Kubernetes → identidad de nube), la configuración no.
Plataforma de contenedores serverlesscompute-web
Correr contenedores HTTP sin administrar nodos ni clusters, con escalado gestionado.
Azure
- Azure Container Apps
Corre dentro de un environment, que es la frontera de red y de logs.
⚠ Dónde se rompe la analogía
ACA y Cloud Run incluyen ingress HTTP y escala a cero. ECS Fargate no: el ingress es un ALB aparte (con costo fijo) y el escalado lo da Application Auto Scaling.
Guardrails de gobernanzagovernance
Políticas a escala de organización que restringen o auditan cómo se configuran los recursos.
Azure
⚠ Dónde se rompe la analogía
Azure Policy evalúa la configuración del recurso y puede auditar, denegar o remediar (modify, deployIfNotExists). Las SCPs de AWS no miran la configuración: limitan qué acciones de API pueden usar los principals, y el cumplimiento de configuración va por AWS Config. Las organization policies de GCP restringen configuraciones con constraints predefinidos o custom, sin remediación automática.
Almacén de secretosidentity
Almacenamiento gestionado de secretos con control de acceso, versionado y auditoría.
⚠ Dónde se rompe la analogía
Key Vault agrupa secretos, claves y certificados. En AWS eso se reparte entre Secrets Manager, KMS y ACM; en GCP entre Secret Manager, Cloud KMS y Certificate Manager.
Control de acceso a recursosidentity
Modelo de permisos sobre recursos de nube: quién puede hacer qué y en qué alcance.
⚠ Dónde se rompe la analogía
Azure y GCP asignan roles en un alcance que se hereda hacia abajo (management group/suscripción/RG en Azure; organización/carpeta/proyecto en GCP). AWS evalúa policies de identidad y de recurso por request, con deny explícito que siempre gana, y la frontera fuerte es la cuenta.
Federación de identidad externa (OIDC)identity
Confianza en tokens de un IdP externo (GitHub Actions, GitLab, Kubernetes, otra nube) para cambiarlos por credenciales de corta duración, sin secretos guardados.
Azure
- Workload identity federation (federated identity credential)
Sobre una user-assigned managed identity o una app registration.
⚠ Dónde se rompe la analogía
Cambia dónde vive la regla de confianza. En Azure, cada federated identity credential es un par issuer + subject que tiene que coincidir exacto (sin comodines, máximo 20 por identidad). En AWS es una trust policy con operadores de condición (StringEquals/StringLike). En GCP es una expresión CEL (attribute_condition) más los bindings IAM sobre atributos mapeados.
Gestión de claves criptográficasidentity
Claves de cifrado gestionadas (CMK) con control de acceso, rotación y auditoría.
⚠ Dónde se rompe la analogía
En AWS el acceso a una clave lo define primero la key policy de KMS (además de IAM); en Azure y GCP alcanza con RBAC/IAM sobre la clave o el contenedor. Copiar permisos de IAM sin la key policy es el error típico al migrar a AWS.
Identidad de workload (sin secretos)identity
Identidad que la plataforma le asigna a un workload para obtener tokens de corta duración, sin claves almacenadas.
⚠ Dónde se rompe la analogía
aws_iam_role no tiene un recurso equivalente 1:1 en Azure. En AWS el rol junta identidad + trust policy + permisos (policies adjuntas). En Azure la identidad (Managed Identity) y el permiso (role assignment sobre un scope) son objetos separados. En GCP la Service Account es la identidad y el permiso es un binding IAM sobre el recurso.
Acceso privado a servicios PaaSnetworking
Consumir un servicio gestionado (storage, colas, bases) desde la red privada sin pasar por internet.
Azure
- Private Endpoint (Private Link)
IP privada en tu VNet por recurso. Pago por hora + GB. Requiere zona DNS privada.
- Service Endpoints
Sin costo; el servicio sigue usando IP pública pero filtra por subnet de origen.
AWS
- Gateway VPC Endpoint (S3, DynamoDB)
Sin costo; entrada en la route table. Solo S3 y DynamoDB.
- Interface VPC Endpoint (PrivateLink)
ENI con IP privada, pago por hora por AZ + GB. Es el equivalente conceptual de Private Endpoint.
GCP
- Private Google Access
Flag por subnet, sin costo. VMs sin IP pública llegan a las APIs de Google.
- Private Service Connect (Google APIs)
⚠ Dónde se rompe la analogía
'Private Endpoint' (Azure), 'Interface Endpoint' (AWS) y 'Private Service Connect' (GCP) son conceptualmente lo mismo. 'Service Endpoint' (Azure), 'Gateway Endpoint' (AWS) y 'Private Google Access' (GCP) se parecen en que son gratis, pero NO hacen lo mismo: ninguno le da al servicio una IP privada en tu red.
CDN y entrada globalnetworking
Cache y terminación TLS en el borde, con WAF y ruteo global hacia orígenes.
⚠ Dónde se rompe la analogía
Cloud CDN no es un servicio independiente: se habilita sobre un Application Load Balancer externo global. Front Door y CloudFront sí son el punto de entrada por sí mismos.
DNS privado e híbridonetworking
Zonas DNS resolubles solo desde redes privadas, y resolución entre la nube y on-premises.
⚠ Dónde se rompe la analogía
La zona privada resuelve dentro de la nube; para que on-premises resuelva nombres de Private Endpoints/interface endpoints (y viceversa) hace falta un componente aparte en las tres: Private Resolver, Resolver endpoints o inbound server policy.
Filtrado de salida por dominio (FQDN)networking
Permite o niega la salida a internet según el nombre de dominio de destino, no solo por IP y puerto.
⚠ Dónde se rompe la analogía
El mecanismo difiere. Las reglas de aplicación de Azure Firewall (HTTP/S y MSSQL) y las listas de dominios de Network Firewall (con TLS_SNI y HTTP_HOST, HTTP y HTTPS) se apoyan en el SNI o el encabezado Host. Los FQDN objects de Cloud NGFW, y los FQDN de las reglas de red de Azure Firewall, se resuelven a IPs por DNS.
Filtrado de tráfico L3/L4networking
Reglas stateful/stateless que permiten o niegan tráfico entre recursos de la red.
⚠ Dónde se rompe la analogía
Los Security Groups de AWS solo tienen reglas allow (stateful) y se asocian a interfaces; para deny explícito están las NACLs (stateless, por subnet). Los NSG de Azure tienen allow y deny con prioridad y se asocian a subnet o NIC. En GCP las reglas son de la VPC y apuntan a instancias por network tags o service accounts.
Firewall gestionado de red (L3-L7)networking
Firewall stateful como servicio para inspeccionar y filtrar tráfico entre redes, hacia internet y desde on-premises, con reglas y política centralizadas.
⚠ Dónde se rompe la analogía
El modelo de despliegue difiere. Azure Firewall es un recurso que vive en una subnet dedicada de la VNet. Network Firewall crea endpoints en subnets de la VPC y el tráfico llega ahí por las route tables. Cloud NGFW intercepta de forma transparente el tráfico que selecciona una regla de la política y manda los paquetes a un firewall endpoint zonal para la inspección de capa 7.
Ingress HTTP internonetworking
Punto de entrada HTTP(S) alcanzable solo desde la red privada (o redes conectadas), sin IP pública.
⚠ Dónde se rompe la analogía
En ACA y en el ALB interno, la red es la frontera de acceso. En Cloud Run, 'internal' restringe el origen de red, pero por default además exige IAM (roles/run.invoker) en cada request: son dos controles, no uno.
NAT de salida a internetnetworking
Traducción de direcciones para que recursos sin IP pública salgan a internet con IPs públicas fijas, sin aceptar conexiones entrantes no solicitadas.
⚠ Dónde se rompe la analogía
En Azure el NAT Gateway se asocia a la subnet y no requiere configuración de rutas en su tabla. En AWS vive en una subnet pública y las subnets privadas necesitan una ruta que apunte a él. En GCP se configura sobre un Cloud Router y, según la doc, no está basado en VMs proxy ni en appliances.
Perímetro de datos (anti-exfiltración)networking
Control que impide que datos de servicios PaaS salgan hacia identidades o redes fuera de la organización, aunque la credencial sea válida.
AWS
Sin equivalente directo
No hay un servicio único. El 'data perimeter' de AWS se arma combinando SCPs/RCPs de Organizations, políticas de VPC endpoint y bucket policies con condiciones (aws:PrincipalOrgID, aws:SourceVpce, aws:ResourceOrgID).
↗ docsGCP
- VPC Service Controls
Se configura a nivel organización (Access Context Manager), no por proyecto.
Red virtualnetworking
Red privada aislada donde viven los recursos, con subnets y ruteo propios.
⚠ Dónde se rompe la analogía
La VPC de GCP es global y sus subnets son regionales; la VNet de Azure y la VPC de AWS son regionales. En AWS cada subnet vive en una sola AZ; en Azure una subnet abarca todas las zonas de la región.
Reenvío DNS híbrido (entrada y salida)networking
Puntos de entrada para que on-premises consulte las zonas privadas de la nube, y reglas para que la nube reenvíe dominios corporativos a los DNS on-premises.
⚠ Dónde se rompe la analogía
En Azure y AWS la entrada y la salida son endpoints con IPs en subnets que pagás por hora aunque no haya consultas. En GCP no hay endpoints: la inbound policy toma una IP de cada subnet de la VPC y la salida es una forwarding zone, que se cobra como cualquier zona más las consultas.
Logs centralizadosobservability
Recolección, consulta y retención de logs de plataforma y aplicaciones.
Almacenamiento de objetosstorage-data
Almacenamiento durable de blobs/objetos accesible por API HTTP, facturado por GB almacenado, operaciones y egress.
Azure
- Azure Blob Storage
Vive dentro de una Storage Account, que es la unidad de red, cifrado y autenticación.
AWS
⚠ Dónde se rompe la analogía
En Azure la configuración de red, cifrado y autenticación vive en la Storage Account (que contiene N contenedores); en S3 y Cloud Storage vive en cada bucket. Un 'bucket' no equivale a un 'container': equivale más bien a Storage Account + container.
Base NoSQL de documentos / clave-valorstorage-data
Base serverless o provisionada para documentos JSON o acceso por clave con latencia baja.
⚠ Dónde se rompe la analogía
El modelo de costo es lo primero que se rompe al traducir: Cosmos DB cobra por Request Units (provisionadas o serverless), DynamoDB por capacidad de lectura/escritura (on-demand o provisionada) y Firestore por operación. Un diseño de particiones que es barato en uno puede ser caro en otro.
Cache en memoria (Redis)storage-data
Redis/Valkey gestionado para cache, sesiones y colas livianas.
Ciclo de vida de objetos (TTL / tiering)storage-data
Reglas declarativas que expiran o cambian de tier objetos según edad, prefijo o tags.
⚠ Dónde se rompe la analogía
Ninguna de las tres es un TTL exacto. Son procesos asincrónicos en background; diseñá asumiendo que el objeto puede seguir existiendo horas o días después de "vencer".
PostgreSQL gestionadostorage-data
PostgreSQL como servicio con backups, HA y parches gestionados.
⚠ Dónde se rompe la analogía
Azure SQL Database NO es el equivalente de RDS PostgreSQL (es SQL Server). Comparar motores distintos invalida cualquier conclusión sobre autenticación o costos.