Problema

En entornos multi‑cloud es frecuente que una aplicación deje de comunicarse o que un recurso no se despliegue, aunque los servicios de AWS, Azure o GCP estén operativos. El síntoma típico es una cadena de fallos que parece “aleatoria”: una API que responde con 403, una base de datos que no acepta conexiones o un pipeline CI que se queda colgado en la fase de despliegue. Lo que une a esos casos es que el origen suele estar en una configuración mínima – una regla de firewall, un cambio de IAM, una ruta de red o un certificado caducado – y no en una interrupción del propio proveedor.

El objetivo de esta guía es ofrecer un método reutilizable que permita a cualquier sysadmin, ya sea que trabaje exclusivamente en una nube o en una arquitectura híbrida, aislar rápidamente la causa y aplicar una solución sin tocar código de aplicación.

Causa

Los fallos de cloud se agrupan en cuatro áreas que aparecen con mayor frecuencia:

  1. Cambios de infraestructura no sincronizados

    • Modificaciones en grupos de seguridad (Security Groups, NSG, firewall rules) que bloquean puertos críticos.
    • Actualizaciones de VPC/VNet que eliminan rutas o cambian CIDR sin actualizar los peers.

  2. Permisos insuficientes

    • Políticas IAM o RBAC que revocan acceso a servicios dependientes (por ejemplo, una función Lambda que pierde permiso para leer un bucket S3).
    • Service accounts en GCP que pierden scopes necesarios para acceder a Cloud SQL.

  3. Problemas de DNS y certificados

    • Registros CNAME/A que apuntan a una IP antigua después de un migration.
    • Certificados TLS expirados o no renovados en Application Gateway o Cloud Load Balancer.

  4. Fallas de observabilidad

    • Logs desactivados o mal configurados, lo que impide ver el error real.
    • Métricas de latencia que no se recogen, ocultando cuellos de botella de red.

En producción, la combinación de dos o más de estos factores es la norma, no la excepción. Por eso el proceso de diagnóstico debe ser sistemático y no lineal.

Solución

1. Definir el síntoma con precisión

Antes de abrir tickets, escribe brevemente qué está fallando, qué funciona y cuál es el alcance. Por ejemplo: “EC2 en us‑east‑1 no puede resolver el hostname de la base de datos RDS; las demás instancias sí”. Esa frase guía la búsqueda de la raíz.

2. Revisar cambios recientes

Consulta el historial de cambios de la infraestructura (IaC, CloudTrail, Activity Log, audit logs). Busca:

  • Commits que modificaron security groups, firewall rules o VNet peering.
  • Pull requests que alteraron políticas IAM/RBAC.
  • Renovaciones de certificados o actualizaciones de DNS.

Si encuentras algo, revierte temporalmente o compara con la versión anterior.

3. Verificar conectividad de red

Utiliza herramientas nativas para probar la ruta entre los recursos involucrados:

  • AWS: aws ec2 describe-network-interfaces, aws ec2 ping (via SSM).
  • Azure: az network watcher test-connectivity.
  • GCP: gcloud compute ssh + nc -zv.

Ejemplo rápido con Azure CLI:

az network watcher test-connectivity \
  --source-resource <VM_ID> \
  --dest-address <IP_o_FQDN> \
  --dest-port 5432

El comando devuelve latencia, éxito o detalle del bloqueo (NSG, UDR, etc.). Repite la prueba desde varias subredes para descartar problemas de ruta asimétrica.

4. Auditar permisos

Ejecuta una consulta de permisos efectivos:

  • AWS: aws iam simulate-principal-policy --policy-source-arn <arn> --action-names <action>
  • Azure: az role assignment list --assignee <objectId> y compara con la documentación del recurso.
  • GCP: gcloud iam service-accounts get-iam-policy <SA_EMAIL>.

Si el permiso requerido falta, agrégalo de forma mínima (principio de menor privilegio) y vuelve a probar.

5. Comprobar DNS y certificados

  • Usa dig o nslookup para validar que el nombre resuelve a la IP esperada.
  • Verifica la cadena de confianza del certificado con openssl s_client -connect <host>:443 -servername <host> y revisa la fecha de expiración.

6. Revisar logs y métricas

Activa temporalmente los logs de VPC Flow, NSG Flow o Cloud Logging si estaban deshabilitados. Busca códigos de error (403, 502, timeout) y correlaciónalos con la hora del fallo.

7. Aplicar la mínima corrección

Una vez identificado el punto de ruptura, implementa la solución más pequeña posible:

  • Añade la regla de puerto faltante.
  • Restablece el permiso eliminado.
  • Actualiza el registro DNS o renueva el certificado.

Evita cambios masivos que puedan introducir nuevos problemas.

8. Documentar la causa raíz

Registra en el ticket interno o en el repositorio de runbooks: síntoma, causa, acción tomada y referencia al cambio de IaC. Esa práctica evita que el mismo error reaparezca cuando otro equipo realice despliegues.

Cuándo aplicar esta solución

  • Síntomas de conectividad inter‑servicio (p.ej., microservicios que no se comunican, pipelines que fallan en stage de despliegue).
  • Errores de autorización inesperados (403, AccessDenied) después de un despliegue.
  • Fallos intermitentes que coinciden con cambios de infraestructura recientes.

No es adecuada cuando el problema es una limitación de cuota del proveedor o una interrupción anunciada en la página de status; en esos casos la solución pasa por esperar o solicitar aumento de cuota.

Código

# Azure: prueba de conectividad desde una VM a un endpoint SQL
az network watcher test-connectivity \
  --source-resource $(az vm show -g MyRG -n MyVM --query id -o tsv) \
  --dest-address sqlserver.database.windows.net \
  --dest-port 1433

# AWS: simulación de política IAM para un rol que accede a S3
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:role/MyAppRole \
  --action-names s3:GetObject \
  --resource-arns arn:aws:s3:::my-bucket/*

# GCP: inspección de flujo de red entre dos instancias
gcloud compute firewall-rules list --filter="name=my-allow-ssh"

Verificación

  1. Re‑ejecuta la operación original (p.ej., curl https://api.myservice.com/health).
  2. Confirma ausencia de errores en los logs de aplicación y en los logs de red.
  3. Mide latencia con az network watcher test-connectivity o su equivalente para asegurar que la ruta es estable.
  4. Revisa la expiración del certificado con openssl para evitar recaídas futuras.

Si todos los pasos pasan, el problema está resuelto.

Notas adicionales

  • Mantén un pipeline de CI/CD que incluya pruebas de conectividad y de permisos después de cada despliegue; así detectas roturas antes de que lleguen a producción.
  • Usa etiquetas (tags) en recursos de nube para agrupar por entorno (dev, prod) y aplicar políticas de auditoría automáticas.
  • Cuando trabajes con varios proveedores, considera una herramienta de observabilidad unificada (por ejemplo, Datadog o Prometheus con exporters) para evitar cambiar de consola cada vez.
  • En caso de que la causa sea un cambio de infraestructura, automatiza la reversión mediante Terraform taint o Azure az deployment what-if antes de aplicar.

Con este enfoque estructurado, la mayoría de los incidentes de configuración, red o permisos en AWS, Azure y GCP pueden diagnosticarse y solucionarse en menos de una hora, reduciendo el tiempo de inactividad y evitando que el mismo error vuelva a aparecer.