¿Está caído Amazon Web Services?

Cómo funciona la disponibilidad de AWS

Amazon Web Services es un conjunto de servicios cloud que operan en cuentas, regiones y zonas de disponibilidad, no una única aplicación con un estado de disponibilidad universal. Un incidente que afecte a un servicio o región concretos puede dejar otras cargas de trabajo de AWS funcionando con normalidad.

Empieza por la página oficial de estado de AWS Health. Compara cualquier evento con el servicio, la región, el recurso, la cuenta o el entorno afectados, así como con la hora aproximada del fallo. Si no hay ningún evento relacionado, investiga las causas específicas de la cuenta, la carga de trabajo, la configuración y la conectividad antes de considerar que se trata de una interrupción generalizada de AWS.

Una página de estado pública sin incidencias no demuestra que todos los recursos funcionen correctamente. Las credenciales, los permisos, el DNS, el enrutamiento, los controles de seguridad, la selección del endpoint, los cambios de despliegue y el código de la aplicación pueden afectar a un servicio respaldado por AWS.

Diagnóstico de fallos de AWS

1. Comprueba si hay un incidente de servicio o región

Abre la página oficial de estado de AWS Health y busca un evento que coincida con el servicio, la región y la hora aproximada de inicio afectados. Un evento coincidente hace más probable que se trate de un problema del proveedor. Evita cambiar repetidamente la configuración de producción o volver a desplegar recursos mientras se investiga un incidente.

Si no aparece ningún evento coincidente, el problema puede limitarse a una cuenta, carga de trabajo, región, recurso o ruta de red.

2. Identifica la capa que falla

Define la operación exacta que falla: abrir la consola de AWS, desplegar código, resolver un hostname, llamar a un endpoint de AWS, leer desde el almacenamiento o conectarse a una base de datos. Comprueba si otros recursos o servicios no relacionados de la misma región siguen funcionando.

Compara el fallo con un despliegue o cambio de configuración reciente. Revisa los logs para obtener el error exacto de AWS, la hora de la solicitud, la región, el identificador del recurso y la operación. Una respuesta HTTP 5xx no demuestra por sí sola que AWS esté caído; puede haberla generado la aplicación, el proxy, el load balancer o el gateway.

3. Comprueba las causas relacionadas con la cuenta, los permisos y la configuración

Si el fallo se limita a una cuenta, entorno o recurso, verifica la región seleccionada, el estado del recurso, las credenciales, los permisos, el endpoint, las cuotas y los cambios recientes de infraestructura. Confirma que la aplicación utiliza la cuenta y la región previstas. Si una identidad o un despliegue falla mientras una ruta conocida como válida funciona, investiga el acceso y la configuración antes de considerar que el problema afecta a toda la plataforma.

4. Comprueba los problemas específicos del navegador y la consola

Si la consola de AWS o una aplicación alojada falla únicamente en un navegador o dispositivo, prueba una ventana privada, otro navegador compatible u otro dispositivo. Registra el error visible antes de borrar los datos del sitio. Un problema exclusivo de la consola puede ser independiente del estado de los recursos de AWS subyacentes.

5. Comprueba la red, el DNS y la conectividad

Cuando sea posible, realiza la prueba desde una segunda red. Compara la resolución DNS, la negociación TLS y el comportamiento de la conexión para el hostname afectado. Los fallos de DNS, los rechazos de conexión, los errores de certificado y los timeouts pueden deberse al DNS local, la configuración de la VPN o el proxy, las reglas del firewall, el enrutamiento, los security groups, las network ACL, los listeners del load balancer o la aplicación de destino.

Si la solicitud funciona desde otra red o región, investiga la ruta entre el cliente y AWS en lugar de asumir que existe una interrupción global.

6. Comprueba los fallos del SDK, la CLI, los webhooks y las automatizaciones

Captura la categoría completa del error y la operación. Distingue los errores de autenticación o autorización de los de throttling, validación, endpoint, timeout y los errores del lado del servidor. Confirma la región y el endpoint configurados y vuelve a intentarlo únicamente cuando sea seguro repetir la operación. En los cambios de producción, conserva los IDs de solicitud y las marcas de tiempo para el diagnóstico o la escalación al soporte.