¿Cómo crea una página de mantenimiento para AWS cuando sus instancias están detrás de un ELB?

Route53 no es una buena solución para este problema. Toma una cantidad significativa de tiempo para que las entradas DNS caduquen antes de que aparezca la página de mantenimiento (y luego toma la misma cantidad de tiempo antes de que se actualicen después de que se complete el mantenimiento). Me doy cuenta de que los disparadores Lambda y CodeDeploy no existían en el momento en que se hizo esta pregunta, pero quería que otros supieran que Lambda se puede usar para crear una solución relativamente limpia para esto, que he detallado en un blog post: http://blog.ajhodges.com/2016/04/aws-lambda-setting-temporary.html

La estrategia de la solución es suscribir una función Lambda a los eventos CodeDeploy, que reemplaza su ASG con una micro instancia que sirve una página estática en su balanceador de carga durante las implementaciones.

Se le ocurrió otra solución que está funcionando muy bien para nosotros. Estos son los pasos:

1. Replique su entorno EB para crear otro, llámelo algo como app-environment-maintenance, por ejemplo.
2. Cambie la configuración para el escalado automático y establezca los servidores min y max en cero. Esto no le costará ningún servidor EC2 y el entorno se volverá gris y quedará en su lista.
3. Esto es un requisito, pero usamos Cloudfront, como muchas personas lo harán para HTTPS, etc. Cloudfront tiene páginas de error.
4. Cree un nuevo cubo de alojamiento web S3 con sus páginas de error. Considere la posibilidad de crear archivos separados para los códigos de respuesta, 503, etc. Vea #6 para requisitos de directorio y rutas.
5. Agregue el bucket S3 a su distribución de Cloudfront.
6. Agregue un nuevo comportamiento a su distribución de Cloudfront para una ruta como /error/*.
7. Configure una página de error en Cloudfront para manejar códigos de respuesta 503 y apuntarla a su ruta de bucket S3, como /error/503-error.html

8. Finalmente, puedes use la CLI de AWS para ahora intercambiar el CNAME del entorno para llevar su entorno principal al modo de mantenimiento. Por ejemplo:

   aws elasticbeanstalk swap-environment-cnames \ --profile "$awsProfile" \ --region "$awsRegion" \ --output text \ --source-environment-name api-prod \ --destination-environment-name api-prod-maintenance

Esto cambiaría su entorno app-prod al modo de mantenimiento. Causaría que el ELB lanzara un 503 ya que no hay ninguna instancia EC2 en ejecución y luego Cloudfront atrapará el 503 y devolverá su respectiva página de error 503.

Y eso es todo. Sé que hay bastantes pasos y probé muchas de las opciones sugeridas allí incluyendo Route53, etc. Pero todos estos tienen problemas con la forma en que funcionan con Elbs y Cloudfront, etc.

Tenga en cuenta que después de intercambiar los nombres de host por los entornos, se tarda aproximadamente un minuto más o menos en propagarse.

Nuestro proceso de implementación primero ejecuta una cloudformation para hacer girar una micro instancia ec2 (instancia de mantenimiento) que copia la página estática predefinida de s3 en la ec2. Cloudformation se suministra con elb a la que se adjunta la instancia micro ec2. A continuación, se ejecuta un script (powershell o cli) para eliminar las instancias web (ec2) de la instancia de mantenimiento que sale de elb.

De esta manera cambiamos a la instancia de mantenimiento durante el proceso de implementación.

En nuestro caso, tenemos dos elb, uno para externo y el otro interno. Nuestros elb internos no se actualizarán durante este proceso y es así como se realiza la prueba de humo postprod deployment. Una vez que se realiza la prueba, ejecutamos otro script para adjuntar instancias web a las de elb y eliminar la pila de Mantenimiento.