Generación de respuestas de error personalizadas - Amazon CloudFront

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Generación de respuestas de error personalizadas

Si un objeto a través del cual estás publicando no CloudFront está disponible por algún motivo, tu servidor web normalmente devuelve un código de estado HTTP relevante CloudFront para indicarlo. Por ejemplo, si un usuario solicita una URL no válida, el servidor web devuelve un código de estado HTTP 404 (no encontrado) al CloudFront usuario y lo CloudFront devuelve al espectador.

Si lo desea, puede CloudFront configurarlo para que devuelva una respuesta de error personalizada al espectador. También tienes varias opciones para gestionar la forma en que CloudFront responde cuando se produce un error. Para especificar opciones para los mensajes de error personalizados, actualiza la CloudFront distribución para especificar esos valores. Para obtener más información, consulte Configurar el comportamiento de respuestas de error.

Si configuras CloudFront para devolver una página de error personalizada para un código de estado HTTP, pero la página de error personalizada no está disponible, CloudFront devuelve al espectador el código de estado que CloudFront recibió del origen y que contiene las páginas de error personalizadas. Por ejemplo, supongamos que su origen personalizado devuelve un código de estado 500 y que lo ha configurado CloudFront para obtener una página de error personalizada para un código de estado 500 de un bucket de Amazon S3. Sin embargo, alguien borró accidentalmente la página de error personalizada de tu bucket. CloudFront devuelve un código de estado HTTP 404 (No encontrado) al espectador que solicitó el objeto.

Cuando CloudFront devuelve una página de error personalizada a un espectador, usted paga los CloudFront cargos estándar de la página de error personalizada, no los cargos del objeto solicitado. Para obtener más información sobre CloudFront los cargos, consulta los CloudFrontprecios de Amazon.

Configurar el comportamiento de respuestas de error

Para configurar las respuestas de error personalizadas, puedes usar la CloudFront consola, la CloudFront API oAWS CloudFormation. Independientemente de cómo elija actualizar la configuración, tenga en cuenta las siguientes sugerencias y recomendaciones:

  • Guarda tus páginas de error personalizadas en una ubicación a la que puedas acceder CloudFront. Le recomendamos que las almacene en un bucket de Amazon S3 y que no las almacene en el mismo lugar que el resto del contenido de su sitio web o aplicación. Si guardas las páginas de error personalizadas en el mismo origen que tu sitio web o aplicación y el origen empieza a arrojar cinco veces más errores, no CloudFront podrás obtener las páginas de error personalizadas porque el servidor de origen no está disponible. Para obtener más información, consulte Almacenamiento de objetos y páginas de error personalizadas en diferentes lugares.

  • Asegúrate de que CloudFront tiene permiso para obtener tus páginas de error personalizadas. Si las páginas de error personalizadas están almacenadas en Amazon S3, deben ser de acceso público o debe configurar un control de acceso de CloudFront origen (OAC). Si las páginas de error personalizadas se almacenan en un origen personalizado, deben ser accesibles públicamente.

  • (Opcional) Configure su origen para agregar un encabezado Cache-Control o Expires junto con las páginas de error personalizadas, si lo desea. También puede usar la configuración TTL mínima de almacenamiento en caché de errores para controlar cuánto tiempo se almacenan en CloudFront caché las páginas de error personalizadas. Para obtener más información, consulte Controlar cuánto tiempo se almacenan en CloudFront caché los errores.

Configure las respuestas de error personalizadas (consola) CloudFront

Para configurar las respuestas de error personalizadas en la CloudFront consola, debe tener una CloudFront distribución. En la consola, la configuración de las respuestas de error personalizadas solo está disponible para distribuciones existentes. Para obtener información sobre cómo crear una distribución, consulte Cómo empezar con una distribución sencilla CloudFront .

Para configurar respuestas de error personalizadas (consola)
  1. Inicie sesión en la página de distribuciones de la CloudFront consola AWS Management Console y ábrala enhttps://console.aws.amazon.com/cloudfront/v4/home#distributions.

  2. En la lista de distribuciones, elija la distribución que desea actualizar.

  3. Elija la pestaña Error Pages (Páginas de error) y, a continuación, elija Create Custom Error Response (Crear respuesta de error personalizada).

  4. Ingrese los valores aplicables. Para obtener más información, consulte Páginas de error personalizadas y almacenamiento de errores en caché.

  5. Después de introducir los valores deseados, elija Create (Crear).

Configure las respuestas de error personalizadas (CloudFrontAPI oAWS CloudFormation)

Para configurar las respuestas de error personalizadas con la CloudFront API o AWS CloudFormation utilice el CustomErrorResponse tipo en una distribución. Para más información, consulte los siguientes temas:

Creación de una página de error personalizada para códigos de estado HTTP específicos

Si prefieres mostrar un mensaje de error personalizado en lugar del mensaje predeterminado (por ejemplo, una página que utilice el mismo formato que el resto de tu sitio web), puedes hacer que se CloudFront devuelva al espectador un objeto (como un archivo HTML) que contenga tu mensaje de error personalizado.

Para especificar el archivo que quieres devolver y los errores por los que se debe devolver el archivo, actualiza la CloudFront distribución para especificar esos valores. Para obtener más información, consulte Configurar el comportamiento de respuestas de error.

Por ejemplo, la siguiente es una página de error personalizada:


				AWS página 404

Puede especificar un objeto diferente por código de estado HTTP admitido o el mismo objeto para todos los códigos de estado admitidos. Puede elegir especificar páginas de error personalizadas para algunos códigos de estado y no para otros.

Los objetos con los que está sirviendo CloudFront pueden no estar disponibles por diversos motivos. Estas se dividen en dos amplias categorías:

  • Errores de cliente, que indican un problema con la solicitud. Por ejemplo, un objeto con el nombre especificado no está disponible o el usuario no tiene los permisos necesarios para obtener un objeto en el bucket de Amazon S3. Cuando se produce un error en el cliente, el origen devuelve un código de estado HTTP en el rango de 4xx aCloudFront.

  • Errores de servidor, que indican un problema con el servidor de origen. Por ejemplo, el servidor HTTP está ocupado o no disponible. Cuando se produce un error en el servidor, el servidor de origen devuelve un código de estado HTTP del orden de 5 xx o CloudFront no recibe respuesta del servidor de origen durante un período de tiempo determinado y asume un código de estado 504 (tiempo de espera de la puerta de enlace). CloudFront

Los códigos de estado HTTP para los que se CloudFront puede devolver una página de error personalizada son los siguientes:

  • 400, 403, 404, 405, 414, 416

    nota

    Puede crear una página de error personalizada para el código de estado HTTP 416 (Rango solicitado no puede ser satisfecho); también puede cambiar el código de estado HTTP que CloudFront proporciona a los espectadores cuando el origen devuelve un código de estado 416 a CloudFront. (Para obtener más información, consulte Cambiar los códigos de respuesta devueltos por CloudFront). Sin embargo, CloudFront no almacena en caché las respuestas del código de estado 416, por lo que, aunque especifiques un valor para el TTL mínimo de almacenamiento en caché para el código de estado 416, CloudFront no lo utiliza.

  • 500, 501, 502, 503, 504

    nota

    En algunos casos, CloudFront no devuelve una página de error personalizada para el código de estado HTTP 503, incluso si lo has configurado CloudFront para hacerlo. Si el código de CloudFront error es Capacity Exceeded oLimit Exceeded, CloudFront devuelve un código de estado 503 al espectador sin utilizar la página de error personalizada.

Para obtener una explicación detallada de cómo CloudFront gestiona las respuestas de error de tu origen, consulta¿Cómo CloudFront procesa y almacena en caché los códigos de estado HTTP 4xx y 5xx de tu origen?.

Almacenamiento de objetos y páginas de error personalizadas en diferentes lugares

Si desea almacenar los objetos y las páginas de error personalizadas en diferentes ubicaciones, la distribución debe incluir un comportamiento de la caché que cumpla con las siguientes condiciones:

  • El valor de Path Pattern (Patrón de ruta) debe coincidir con la ruta de los mensajes de error personalizados. Por ejemplo, supongamos que ha guardado páginas para errores 4xx personalizadas en un bucket de Amazon S3 en un directorio llamado /4xx-errors. La distribución debe incluir un comportamiento de la caché cuyo patrón de ruta dirija las solicitudes de las páginas de error personalizadas a esa ubicación, por ejemplo, /4xx-errors/*.

  • El valor de Origin (Origen) especifica el valor de Origin ID (ID de origen) del origen que contiene las páginas de error personalizadas.

Para obtener más información, consulte Configuración del comportamiento de la caché.

Cambiar los códigos de respuesta devueltos por CloudFront

Puede configurarlo CloudFront para que devuelva al espectador un código de estado HTTP diferente al que CloudFront recibió del origen. Por ejemplo, si tu origen devuelve un código de estado 500 CloudFront, es posible que desees CloudFront devolver una página de error personalizada y un código de estado 200 (OK) al visor. Existen varios motivos por los que podrías CloudFront querer devolver al espectador un código de estado diferente al que devolvió tu origen CloudFront:

  • Algunos dispositivos de Internet (algunos firewalls y proxis corporativos, por ejemplo) interceptan los códigos de estado HTTP 4xx y 5xx y evitan que la respuesta se devuelva al lector. En este escenario, si sustituye 200, la respuesta no se intercepta.

  • Si no te importa distinguir entre los distintos errores del cliente o del servidor, puedes especificar 400 o 500 como el valor que se CloudFront devuelve para todos los códigos de estado 4xx o 5xx.

  • Quizá desee devolver un código de estado 200 (OK) y un sitio web estático para que sus clientes no sepan que su sitio web está caído.

Si habilita los registros CloudFront estándar y los configura CloudFront para cambiar el código de estado HTTP en la respuesta, el valor de la sc-status columna de los registros contiene el código de estado que especifique. Sin embargo, el valor de la columna x-edge-result-type no se ve afectado. Contiene el tipo de resultado de la respuesta del origen. Por ejemplo, supongamos que se configura CloudFront para devolver un código de estado 200 al espectador cuando el origen retorne a 404 (No encontrado) CloudFront. Cuando el origen responda a una solicitud con un código de estado 404, el valor de la columna sc-status en el registro será 200, pero el valor de la columna x-edge-result-type será Error.

Puede configurarlo CloudFront para que devuelva cualquiera de los siguientes códigos de estado HTTP junto con una página de error personalizada:

  • 200

  • 400, 403, 404, 405, 414, 416

  • 500, 501, 502, 503, 504

Controlar cuánto tiempo se almacenan en CloudFront caché los errores

CloudFront guarda en caché las respuestas de error durante un tiempo predeterminado de 10 segundos. CloudFront a continuación, envía la siguiente solicitud del objeto a su origen para comprobar si se ha resuelto el problema que provocó el error y si el objeto solicitado está disponible.

Puede especificar la duración del almacenamiento en caché de errores (el TTL mínimo de almacenamiento en caché de errores) para cada código de estado 4xx y 5xx que se almacene en caché. CloudFront (Para obtener más información, consulte Códigos de estado HTTP 4xx y 5xx que se almacenan en caché CloudFront). Al especificar una duración, tenga en cuenta lo siguiente:

  • Si especificas una duración de almacenamiento en caché de errores corta, reenvía más solicitudes a tu origen que si especificas una duración más larga CloudFront . En el caso de errores 5xx, esto podría agravar el problema que causó el origen para devolver un error.

  • Cuando tu origen devuelve un error para un objeto, CloudFront responde a las solicitudes del objeto con la respuesta de error o con tu página de error personalizada hasta que transcurra el tiempo de almacenamiento en caché de errores. Si especificas una duración de almacenamiento en caché de errores prolongada, es CloudFront posible que sigas respondiendo a las solicitudes con una respuesta de error o con tu página de errores personalizada durante mucho tiempo después de que el objeto vuelva a estar disponible.

nota

Puede crear una página de error personalizada para el código de estado HTTP 416 (Rango solicitado no puede ser satisfecho); también puede cambiar el código de estado HTTP que CloudFront proporciona a los espectadores cuando el origen devuelve un código de estado 416 a CloudFront. (Para obtener más información, consulte Cambiar los códigos de respuesta devueltos por CloudFront). Sin embargo, CloudFront no almacena en caché las respuestas del código de estado 416, por lo que, aunque especifiques un valor para el TTL mínimo de almacenamiento en caché de errores para el código de estado 416, CloudFront no lo utiliza.

Si quieres controlar durante cuánto tiempo se almacenan en CloudFront caché los errores de los objetos individuales, puedes configurar tu servidor de origen para que añada el encabezado correspondiente a la respuesta de error de ese objeto.

Si el origen añade una Cache-Control: s-maxage directiva Cache-Control: max-age o un Expires encabezado, guarda en CloudFront caché las respuestas de error si es mayor el valor del encabezado o el TTL mínimo de error de almacenamiento en caché.

nota

Los valores Cache-Control: max-age y Cache-Control: s-maxage no pueden ser mayores que el valor de Maximum TTL (TTL máximo) definido para el comportamiento de la caché para el que se está obteniendo la página de error.

Si el origen añade otras Cache-Control directivas o no añade ningún encabezado, guarda en CloudFront caché las respuestas de error con el valor de Error Caching Minimum TTL.

Si la fecha de vencimiento de un código de estado 4xx o 5xx de un objeto es más lejana de lo que desea y el objeto está disponible nuevamente, puede invalidar el código de error almacenado en caché utilizando la URL del objeto solicitado. Si el origen devuelve una respuesta de error para varios objetos, es necesario invalidar cada uno de los objetos por separado. Para obtener más información acerca de las invalidaciones de objetos, consulte Invalidar archivos.