Página de AWS ELB "lo siento, el sitio no funciona"

Tengo un sitio ELB v2 básico. No hay agrupación ni nada todavía. Soy bastante inexperto con AWS.

Mi pila es nginx / uwsgi / django + algunos otros servicios.

Me preguntaba si alguien pensó en hacer un "lo siento, el sitio web está actualmente inactivo ..." - página de estilo (¡el texto personalizado puedo actualizar el tiempo de inactividad planificado es una ventaja!) Siempre que haya tiempo de inactividad por cualquier motivo, y la salud de La instancia es roja. No parece que Amazon ofrezca esta capacidad, ¿me estoy perdiendo algo? ¿Hay alguna manera de crear una instancia súper pequeña separada que SOLO se sirve si la principal es roja o algo así?

¡Gracias!

La solución simple y genial aquí es poner su ELB detrás de CloudFront.

Si el servidor de origen (el ELB en este caso) arroja un error 5XX (o 4XX si lo desea), CloudFront puede devolver una página de error personalizada , que puede configurar CloudFront para buscar desde un depósito S3 creando un segundo origen apuntando al bucket y creando un enrutamiento de comportamiento de caché (por ejemplo) /errors/static/*al bucket.

Esto funciona mejor que la conmutación por error de la ruta 53 por una razón importante ... un defecto fatal, si lo desea ... los navegadores son terribles sobre el almacenamiento en caché de las búsquedas de DNS durante mucho más tiempo de lo esperado. El DNS TTL no es relevante.

Esencialmente, una vez que un navegador tiene una entrada DNS en la mano, simplemente sigue intentando usarla ... típicamente, hasta que se cierran todas las ventanas del navegador.

Entonces, si su sitio deja de funcionar para un visitante que ya estaba en el sitio, es poco probable que vea el sitio alternativo.

Peor aún, si un visitante visita su sitio por primera vez mientras está inactivo, se "pegará" en la página de mantenimiento hasta que cierre todas las ventanas del navegador.

Si usa DNS de conmutación por error, eso es realmente bueno si el objetivo de conmutación por error sigue siendo su aplicación, tal vez un poco más lejos.

Puede desactivar el almacenamiento en caché de CloudFront si no lo necesita.

También puede configurar el error de almacenamiento en caché TTL de CloudFront a un valor distinto de cero si desea que deje de dañar su sitio mientras está inactivo y tratando de recuperarse. Para una página determinada que arroja un error, seguirá mostrando la página de error y no molestará a su servidor con más solicitudes para esa página hasta que caduque el Error CachingTTL.

Utilice Route53 DNS y enrutamiento de conmutación por error . Debería poder obtener un bucket S3 que aloje un sitio web estático de una sola página. No creo que puedas hacerlo solo con ELB.

Amazon tiene una publicación de blog que te dice cómo hacerlo aquí .

Actualización: como dice Michael, hay un inconveniente en el almacenamiento en caché de DNS del navegador, consulte su respuesta para obtener más información. La ruta 53 es probablemente una opción más simple que CloudFront, pero CF tiene otras ventajas, rendimiento y en algunos casos de uso puede reducir los costos.

Ya se han mencionado varias soluciones, incluidas CloudFront y Route53. CloudFront es una solución excelente y, en mi experiencia, no ha ralentizado las cosas en absoluto, pero tiene un costo adicional. Y Route53 tiene los problemas de almacenamiento en caché de DNS ya mencionados.

Hasta que ALB admita páginas de error personalizadas listas para usar (lo que puede suceder o no), existe potencialmente una nueva solución después del reciente anuncio de respuestas fijas de ALB , pero no es apuntar y hacer clic: podría configurar una función Lambda que agregue temporalmente una regla para su equilibrador de carga, proporcionando una respuesta fija con el contenido de su 'página de error'.

Además de escribir el Lambda, necesitará encontrar una forma de activarlo y desactivarlo, lo que podría ser a través de una comprobación de estado de Route53 o una comprobación de estado del grupo objetivo del equilibrador de carga (probablemente a través de la alarma CloudWatch -> SNS - > Lambda).

No es exactamente simple, ¡pero probablemente funcionaría bien una vez configurado!

Según lo escrito por @Tim y @Micheal, tiene la opción de usar el DNS de Route53 y el enrutamiento de conmutación por error , o CloudFront con páginas de error personalizadas . Ambos métodos tienen sus pros y sus contras.

Si aún no está utilizando Cloudfront, creo que Route53 es una solución más simple. Consulte la publicación de blog actualizada de AWS (que ahora incluye un método más simple para la integración de ELB).

CloudFront es mucho más complicado de configurar, y tomará aproximadamente 15 minutos para cada actualización. Cloudfront también almacena en caché (como era de esperar), por lo que no está claro si eso será más lento para responder, que los problemas de caché de DNS con Route 53.

Tenga en cuenta que si su sitio web de ELB solo responde a SSL, entonces no puede usar la solución S3 simple como se describe en el blog 3 de AWS . En ese caso, tendrá que agregar Cloudfront frente al bucket S3 para agregar SSL, lo que hace que la solución de enrutamiento de falla de DNS sea más complicada.