# Generación de respuestas de error personalizadas
Si un objetos que ofrece a través de CloudFront no está disponible por algún motivo, el servidor web suele devolver un código de estado HTTP a CloudFront. Por ejemplo, si un lector especifica una URL no válida, el servidor web devuelve un código de estado HTTP 404 (no encontrado) a CloudFront y CloudFront se lo devuelve al lector. En lugar de utilizar esta respuesta de error predeterminada, puede crear una respuesta personalizada que CloudFront devuelva al lector.
Si configura 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 lector el código de estado que CloudFront recibió del origen que contiene las páginas de error personalizadas. Por ejemplo, supongamos que el origen personalizado devuelve un código de estado 500 y que haya configurado CloudFront para obtener de un bucket de Amazon S3 una página de error personalizada para un código de estado 500. Sin embargo, alguien ha eliminado accidentalmente la página de error personalizada del bucket de Amazon S3. CloudFront devolverá un código de estado HTTP 404 (no encontrado) al lector que solicitó el objeto.
Cuando CloudFront devuelve una página de error personalizada a un lector, paga los cargos estándar de CloudFront por la página de error personalizada, no paga cargos por el objeto solicitado. Para obtener más información acerca de los cargos de CloudFront, consulte [Precios de Amazon CloudFront](https://aws.amazon.com/cloudfront/pricing/).
**Topics**
+ [Configuración del comportamiento de respuestas de error](custom-error-pages-procedure.md)
+ [Creación de una página de error personalizada para códigos de estado HTTP específicos](creating-custom-error-pages.md)
+ [Almacenamiento de objetos y páginas de error personalizadas en diferentes lugares](custom-error-pages-different-locations.md)
+ [Cambio de códigos de respuesta devueltos por CloudFront](custom-error-pages-response-code.md)
+ [Control de cuánto tiempo CloudFront almacena los errores en caché](custom-error-pages-expiration.md)
# Configuración del comportamiento de respuestas de error
Tiene varias opciones para administrar cómo responde CloudFront cuando hay un error. Para configurar respuestas de errores personalizadas, puede utilizar la consola o la API de CloudFront o CloudFormation. Independientemente de cómo elija actualizar la configuración, tenga en cuenta las siguientes sugerencias y recomendaciones:
+ Guarde las páginas de error personalizadas en una ubicación accesible para 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](custom-error-pages-different-locations.md). Si almacena las páginas de error personalizadas en el mismo origen que su sitio web o aplicación y el origen comienza a devolver errores 5xx, CloudFront no puede 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](custom-error-pages-different-locations.md).
+ Asegúrese de que CloudFront tenga permiso para obtener sus páginas de error personalizadas. Si las páginas de error personalizadas se almacenan en Amazon S3, deben ser accesibles públicamente o debe configurar un [control de acceso de origen (OAC)](private-content-restricting-access-to-s3.md) de CloudFront. 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 utilizar la configuración **TTL mínimo de almacenamiento de errores en caché** para controlar cuánto tiempo CloudFront almacena en caché las páginas de error personalizadas. Para obtener más información, consulte [Control de cuánto tiempo CloudFront almacena los errores en caché](custom-error-pages-expiration.md).
## Configuración de respuestas de error personalizadas
Para configurar respuestas de error personalizadas en la consola de CloudFront, debe tener una distribución de CloudFront. 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 [Introducción a una distribución estándar de CloudFront](GettingStarted.SimpleDistribution.md).
------
#### [ Console ]
**Para configurar respuestas de error personalizadas (consola)**
1. Inicie sesión en la Consola de administración de AWS y abra la página **Distributions (Distribuciones)** en la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home#distributions](https://console.aws.amazon.com/cloudfront/v4/home#distributions).
1. En la lista de distribuciones, elija la distribución que desea actualizar.
1. Elija la pestaña **Error Pages** (Páginas de error) y, a continuación, elija **Create Custom Error Response** (Crear respuesta de error personalizada).
1. Ingrese los valores aplicables. Para obtener más información, consulte [Páginas de error personalizadas y almacenamiento de errores en caché](DownloadDistValuesErrorPages.md).
1. Después de introducir los valores deseados, elija **Create** (Crear).
------
#### [ CloudFront API or CloudFormation ]
Para configurar respuestas de error personalizadas con la API de CloudFront o la CloudFormation, utilice el tipo `CustomErrorResponse` en una distribución. Para obtener más información, consulte los siguientes temas:
+ [AWS::CloudFront::Distribution CustomErrorResponse](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-customerrorresponse.html) en la *Guía del usuario de AWS CloudFormation*
+ [CustomErrorResponse](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CustomErrorResponse.html) en la *Referencia de la API de Amazon CloudFront*
------
# Creación de una página de error personalizada para códigos de estado HTTP específicos
Si prefiere mostrar un mensaje de error personalizado en lugar del mensaje predeterminado (por ejemplo, una página que utiliza el mismo formato que el resto del sitio web), puede hacer que CloudFront devuelva al lector un objeto (por ejemplo, un archivo HTML) que contenga el mensaje de error personalizado.
Para especificar el archivo que desea devolver y los errores por los que se debe devolver este archivo, debe actualizar la distribución de CloudFront y especificar esos valores. Para obtener más información, consulte [Configuración del comportamiento de respuestas de error](custom-error-pages-procedure.md).
Por ejemplo, la siguiente es una página de error personalizada:
![\[Captura de pantalla de un ejemplo de página 404 de AWS personalizada.\]](http://docs.aws.amazon.com/es_es/AmazonCloudFront/latest/DeveloperGuide/images/custom-error-page-aws-404-example.png)
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 que ofrece a través de CloudFront pueden no estar disponibles por diversas razones. 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 de cliente, el origen devuelve a CloudFront un código de estado HTTP en el intervalo de los 4xx.
+ *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 de servidor, el servidor de origen devuelve a CloudFront un código de estado HTTP en el intervalo de los 5xx o CloudFront no obtiene respuesta del servidor de origen durante un periodo determinado y supone un código de estado 504 (tiempo de espera de gateway agotado).
Los códigos de estado HTTP para los que CloudFront puede devolver una página de error personalizada son:
+ 400, 403, 404, 405, 414, 416
+ 500, 501, 502, 503, 504
**Notas**
Si CloudFront detecta que la solicitud puede no ser segura, devuelve un error 400 (Solicitud incorrecta) en lugar de una página de error personalizada.
Puede crear una página de error personalizada para el código de estado HTTP 416 (Intervalo solicitado no puede ser satisfecho) y puede cambiar el código de estado HTTP que CloudFront proporciona a los lectores cuando el origen devuelve un código de estado 416 a CloudFront. Para obtener más información, consulte [Cambio de códigos de respuesta devueltos por CloudFront](custom-error-pages-response-code.md). Sin embargo, CloudFront no almacena en caché las respuestas de los códigos de estado 416, así que, aunque especifique un valor para **Error Caching Minimum TTL** (TTL mínimo de almacenamiento de errores en caché) para el código de estado 416, CloudFront no lo utiliza.
En algunos casos, CloudFront no devuelve una página de error personalizada para el código de estado HTTP 503, incluso si configura CloudFront para hacerlo. Si el código de error de CloudFront es `Capacity Exceeded` o `Limit Exceeded`, CloudFront devuelve un código de estado 503 al lector sin utilizar la página de error personalizada.
Si ha creado una página de error personalizada, CloudFront devolverá `Connection: close` o `Connection: keep-alive` para los siguientes códigos de respuesta:
CloudFront devuelve `Connection: close` para los códigos de estado: 400, 405, 414, 416, 500 y 501
CloudFront devuelve `Connection: keep-alive` para los códigos de estado 403, 404, 502, 503 y 504
Para obtener una explicación detallada acerca de cómo CloudFront gestiona las respuestas de error del origen, consulte [Procesamiento de CloudFront de los códigos de estado HTTP 4xx y 5xx desde el origen](HTTPStatusCodes.md).
# 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é](DownloadDistValuesCacheBehavior.md).
# Cambio de códigos de respuesta devueltos por CloudFront
Puede configurar CloudFront para que devuelva al lector un código de estado HTTP diferente al que CloudFront recibió del origen. Por ejemplo, si el origen devuelve un código de estado 500 a CloudFront, es posible que desee que CloudFront devuelva una página de error personalizada y un código de estado 200 (OK) al lector. Existen diversas razones por las que puede querer que CloudFront devuelva al lector un código de estado diferente del que el origen ha devuelto a 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 le resulta especialmente importante distinguir entre diferentes errores de servidor y de cliente, puede especificar `400` o `500` como el valor que 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 estándar de CloudFront](AccessLogs.md) y configura CloudFront para cambiar el código de estado HTTP en la respuesta, el valor de la columna `sc-status` de los registros contiene el código de estado que se 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 configura CloudFront para devolver un código de estado de `200` al espectador cuando el origen devuelve `404` (No encontrado) a 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 configurar CloudFront para devolver 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
# Control de cuánto tiempo CloudFront almacena los errores en caché
CloudFront almacena en caché las respuestas de error durante una duración predeterminada de 10 segundos. A continuación, CloudFront envía la siguiente solicitud para el objeto al origen para ver si el problema que causó el error se ha resuelto y el objeto solicitado está disponible.
Puede especificar la duración de almacenamiento en caché de errores (**Error Caching Minimum TTL [TTL mínimo de almacenamiento de errores en caché])** para cada código de estado 4xx y 5xx que CloudFront almacena en las caché. (Para obtener más información, consulte ). [Códigos de estado HTTP 4xx y 5xx que CloudFront almacena en caché](HTTPStatusCodes.md#HTTPStatusCodes-cached-errors).) Al especificar una duración, tenga en cuenta lo siguiente:
+ Si se especifica una duración breve de almacenamiento de errores en caché, CloudFront reenvía más solicitudes al origen que si se especifica una mayor duración. En el caso de errores 5xx, esto podría agravar el problema que causó el origen para devolver un error.
+ Cuando el origen devuelve un error por un objeto, CloudFront responde a las solicitudes de dicho objeto con la respuesta de error o con la página de error personalizada hasta que finaliza la duración de almacenamiento de errores en caché. Si especifica una duración de almacenamiento de errores en caché mayor, es posible que CloudFront continúe respondiendo a las solicitudes con una respuesta de error o la página de error 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 (Intervalo solicitado no puede ser satisfecho) y puede cambiar el código de estado HTTP que CloudFront proporciona a los lectores cuando el origen devuelve un código de estado 416 a CloudFront. (Para obtener más información, consulte [Cambio de códigos de respuesta devueltos por CloudFront](custom-error-pages-response-code.md).) Sin embargo, CloudFront no almacena en caché las respuestas de los códigos de estado 416, así que, aunque especifique un valor para **Error Caching Minimum TTL** (TTL mínimo de almacenamiento de errores en caché) para el código de estado 416, CloudFront no lo utiliza.
Si desea controlar el tiempo durante el cual CloudFront almacena errores para objetos individuales en la caché, puede configurar el servidor de origen para añadir el encabezado aplicable a la respuesta de error para dicho objeto.
Si el origen añade una directiva `Cache-Control: max-age` o `Cache-Control: s-maxage`, o un encabezado `Expires`, CloudFront almacena en caché respuestas de error para el valor mayor en el encabezado o el valor de **Error Caching Minimum TTL** (TTL mínimo de almacenamiento de errores 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 agrega una directiva `Cache-Control: no-store`, `Cache-Control: no-cache` o `Cache-Control: private` para los códigos de error 404, 410, 414 o 501, CloudFront no almacena en caché la respuesta de error. Para todos los demás códigos de error, CloudFront ignora las directivas `no-store`, `no-cache` y `private`, y almacena en caché la respuesta de error con el valor del **TTL mínimo de almacenamiento en caché de errores**.
Si el origen añade otras directivas `Cache-Control` o no añade encabezados, CloudFront almacena en caché respuestas de error para el valor de **Error Caching Minimum TTL** (TTL mínimo de almacenamiento de errores en caché).
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 [Invalidación de archivos para eliminar el contenido](Invalidation.md).
Si tiene habilitado el almacenamiento en caché para un origen de bucket de S3 y configura un error que almacena en caché el TTL mínimo de 0 segundos en su distribución de CloudFront, seguirá apareciendo un error al almacenar en caché el TTL mínimo de 1 segundo en los errores de origen de S3. CloudFront lo hace para proteger su origen de los ataques DDoS. Esto no se aplica a otros tipos de orígenes.