# Almacenamiento en caché y disponibilidad Puede utilizar CloudFront para reducir la cantidad de solicitudes a las que debe responder directamente el servidor de origen. Con el almacenamiento en caché de CloudFront, se atienden más objetos desde ubicaciones periférica de CloudFront, que están más cerca de los usuarios. Esto reduce la carga en su servidor de origen y reduce la latencia. Cuantas más solicitudes pueda atender CloudFront desde cachés de borde, menos solicitudes de lector debe reenviar CloudFront al origen para obtener la versión más reciente o una versión única de un objeto. Para optimizar CloudFront y realizar el menor número posible de solicitudes al origen, considere la posibilidad de utilizar CloudFront Origin Shield. Para obtener más información, consulte [Uso de Amazon CloudFront Origin Shield](origin-shield.md). La proporción de solicitudes que se atienden directamente desde la caché de CloudFront en comparación con todas las solicitudes se denomina *tasa de aciertos de caché*. Puede consultar el porcentaje de aciertos, fallos y errores de solicitudes de lectores en la consola de CloudFront. Para obtener más información, consulte [Visualización de informes estadísticos de la caché de CloudFront](cache-statistics.md). Hay una serie de factores que afectan a la tasa de aciertos de caché. Puede ajustar la configuración de distribución de CloudFront para mejorar la tasa de aciertos de caché siguiendo las instrucciones de [Incremento de la proporción de solicitudes que se atienden directamente desde las cachés de CloudFront (tasa de aciertos de caché)](cache-hit-ratio.md). Para obtener información sobre cómo agregar y eliminar el contenido que desea que CloudFront distribuya, consulte [Agregación, eliminación o sustitución de contenido que distribuye CloudFront](AddRemoveReplaceObjects.md). **Topics** + [ # Incremento de la proporción de solicitudes que se atienden directamente desde las cachés de CloudFront (tasa de aciertos de caché) ](cache-hit-ratio.md) + [ # Uso de Amazon CloudFront Origin Shield ](origin-shield.md) + [ # Optimización de alta disponibilidad con conmutación por error de origen de CloudFront ](high_availability_origin_failover.md) + [ # Administración de cuánto tiempo se mantiene el contenido en una caché (vencimiento) ](Expiration.md) + [ # Almacenamiento en caché de contenido en función de parámetros de cadenas de consulta ](QueryStringParameters.md) + [ # Almacenamiento en caché de contenido en función de cookies ](Cookies.md) + [ # Almacenamiento en caché de contenido en función de encabezados de solicitud ](header-caching.md) # Incremento de la proporción de solicitudes que se atienden directamente desde las cachés de CloudFront (tasa de aciertos de caché) Puede mejorar el rendimiento aumentando la proporción de las solicitudes de lector que se atienden directamente desde la caché de CloudFront en lugar de acceder a los servidores de origen para obtener contenido. Esto se conoce como mejora de la tasa de aciertos de caché. En las secciones siguientes se explica cómo mejorar la tasa de aciertos de la caché. **Topics** + [ ## Especificación de cuánto tiempo CloudFront almacena en caché los objetos ](#cache-hit-ratio-duration) + [ ## Uso del escudo de origen ](#cache-hit-ratio-use-origin-shield) + [ ## Almacenamiento en caché en función de parámetros de cadenas de consulta ](#cache-hit-ratio-query-string-parameters) + [ ## Almacenamiento en caché en función de valores de cookies ](#cache-hit-ratio-cookies) + [ ## Almacenamiento en caché en función de encabezados de solicitud ](#cache-hit-ratio-request-headers) + [ ## Eliminación del encabezado `Accept-Encoding` cuando no sea necesario comprimir ](#cache-hit-ratio-remove-accept-encoding) + [ ## Distribución de contenido multimedia a través de HTTP ](#cache-hit-ratio-http-streaming) ## Especificación de cuánto tiempo CloudFront almacena en caché los objetos Para incrementar la tasa de aciertos de caché, puede configurar su origen para agregar una directiva [Cache-Control max-age](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control) a sus objetos y especificar el mayor valor práctico de `max-age`. Cuanto más corta sea la duración de la caché, más frecuentemente reenvía CloudFront las solicitudes al origen para determinar si un objeto ha cambiado y para obtener la versión más reciente. Puede complementar `max-age` con las directivas `stale-while-revalidate` y `stale-if-error` para mejorar aún más la proporción de aciertos de la caché en determinadas condiciones. Para obtener más información, consulte [Administración de cuánto tiempo se mantiene el contenido en una caché (vencimiento)](Expiration.md). ## Uso del escudo de origen CloudFront Origin Shield puede contribuir a mejorar la tasa de aciertos de caché de la distribución de CloudFront, porque proporciona una capa adicional de almacenamiento en caché frente al origen. Cuando utiliza Origin Shield, todas las solicitudes de todas las capas de almacenamiento en caché de CloudFront en el origen provienen de una sola ubicación. CloudFront puede recuperar cada objeto mediante una sola solicitud de origen de Origin Shield y todas las demás capas de la caché de CloudFront (ubicaciones periférica y [cachés regionales de borde](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches)) pueden recuperar el objeto desde Origin Shield. Para obtener más información, consulte [Uso de Amazon CloudFront Origin Shield](origin-shield.md). ## Almacenamiento en caché en función de parámetros de cadenas de consulta Si configura CloudFront para almacenar en caché en función de los parámetros de cadenas de consulta, puede mejorar el almacenamiento en la caché si hace lo siguiente: + Configure CloudFront para reenviar solo los parámetros de cadenas de consulta para los que el origen devolverá objetos únicos. + Utilice el mismo tipo de letra (mayúscula o minúscula) para todas las instancias del mismo parámetro. Por ejemplo, si una solicitud contiene `parameter1=A` y otra contiene `parameter1=a`, CloudFront reenvía solicitudes independientes al origen cuando una solicitud contiene `parameter1=A` y otra contiene `parameter1=a`. A continuación, CloudFront almacena en caché de forma independiente los objetos correspondientes devueltos por el origen por separado incluso si los objetos son idénticos. Si utiliza solo `A` o `a`, CloudFront reenvía menos solicitudes al origen. + Enumere los parámetros en el mismo orden. Al igual que con las diferencias de mayúsculas y minúsculas, si una solicitud de un objeto contiene la cadena de consulta `parameter1=a¶meter2=b` y otra solicitud del mismo objeto contiene `parameter2=b¶meter1=a`, CloudFront reenvía ambas solicitudes al origen y almacena en caché los objetos correspondientes de forma independiente aunque sean idénticos. Si ordena los parámetros siempre de la misma manera, CloudFront reenvía menos solicitudes al origen. Para obtener más información, consulte [Almacenamiento en caché de contenido en función de parámetros de cadenas de consulta](QueryStringParameters.md). Si desea revisar las cadenas de consulta que CloudFront reenvía al origen, consulte los valores en la columna `cs-uri-query` de los archivos de registro de CloudFront. Para obtener más información, consulte [Registros de acceso (registros estándar)](AccessLogs.md). ## Almacenamiento en caché en función de valores de cookies Si configura CloudFront para almacenar en caché en función de los valores de las cookies, puede mejorar el almacenamiento en la caché si hace lo siguiente: + Configure CloudFront para reenviar solo las cookies especificadas en lugar de todas. Para las cookies que configura que CloudFront reenvíe al origen, CloudFront reenvía cada combinación de nombre y valor de las cookies. A continuación, almacena en caché por separado los objetos que devuelve su origen, incluso si todos son idénticos. Supongamos que los espectadores incluyen dos cookies en cada solicitud, que cada cookie tiene tres valores posibles y que todas las combinaciones de valores de cookie son posibles. CloudFront reenvía hasta nueve solicitudes diferentes al origen para cada uno de los objetos. Si el origen devuelve distintas versiones de un objeto en función de solo una de las cookies, CloudFront reenvía más solicitudes al origen de lo necesario y almacena en caché varias versiones idénticas del objeto innecesariamente. + Cree diferentes comportamientos de la caché para contenido estático y dinámico y configure CloudFront para reenviar las cookies al origen solo para contenido dinámico. Por ejemplo, supongamos que tiene un comportamiento de la caché para la distribución y que utiliza la distribución para contenido dinámico, como archivos `.js` y para archivos `.css` que raramente cambian. CloudFront almacena en caché versiones independientes de los archivos `.css` en función de los valores de cookies, de modo que cada ubicación periférica de CloudFront reenvía una solicitud al origen por cada nuevo valor de cookie o por cada combinación de valores de cookies. Si crea un comportamiento de la caché cuyo patrón de ruta es `*.css` y para el que CloudFront no almacena en caché en función de los valores de las cookies, CloudFront reenviará las solicitudes de archivos `.css` al origen solo para la primera solicitud que reciba desde una ubicación periférica de un archivo `.css` determinado y para la primera solicitud después de que un archivo `.css` venza. + Si es posible, cree diferentes comportamientos de la caché para contenido dinámico cuyos valores de cookie sean exclusivos para cada usuario (como un ID de usuario) y para contenido dinámico que varíe en función de una cantidad más reducida de valores únicos. Para obtener más información, consulte [Almacenamiento en caché de contenido en función de cookies](Cookies.md). Si desea revisar las cookies que CloudFront reenvía al origen, consulte los valores en la columna `cs(Cookie)` de los archivos de registro de CloudFront. Para obtener más información, consulte [Registros de acceso (registros estándar)](AccessLogs.md). ## Almacenamiento en caché en función de encabezados de solicitud Si configura CloudFront para almacenar en caché en función de encabezados de solicitud, puede mejorar el almacenamiento en la caché si hace lo siguiente: + Configure CloudFront para reenviar y almacenar en caché solo en función de encabezados especificados en lugar de reenviar y almacenar en caché en función de todos los encabezados. Para los encabezados que especifique, CloudFront reenvía todas las combinaciones de nombre y valor de encabezado. A continuación, almacena en caché por separado los objetos que devuelve su origen, incluso si todos son idénticos. **nota** CloudFront siempre reenvía al origen los encabezados especificados en los siguientes temas: Cómo CloudFront procesa y reenvía solicitudes al servidor de origen de Amazon S3 > [Encabezados de solicitud HTTP que CloudFront elimina o actualiza](RequestAndResponseBehaviorS3Origin.md#request-s3-removed-headers) Cómo CloudFront procesa y reenvía solicitudes al servidor de origen personalizado > [Encabezados de solicitudes HTTP y comportamiento de CloudFront (personalizado y orígenes de Amazon S3)](RequestAndResponseBehaviorCustomOrigin.md#request-custom-headers-behavior) Cuando configura CloudFront para almacenar en caché en función de encabezados de solicitud, no cambia los encabezados que reenvía CloudFront, solo si CloudFront almacena en caché objetos en función de los valores de encabezado. + Intente evitar el almacenamiento en caché en función de encabezados de solicitud con un gran número de valores únicos. Por ejemplo, si desea enviar diferentes tamaños de una imagen en función del dispositivo del usuario, no configura CloudFront para almacenar en caché en función del encabezado `User-Agent`, que tiene gran cantidad de valores posibles. En su lugar, configure CloudFront para almacenar en caché en función de los encabezados de tipo de dispositivo de CloudFront `CloudFront-Is-Desktop-Viewer`, `CloudFront-Is-Mobile-Viewer`, `CloudFront-Is-SmartTV-Viewer` y `CloudFront-Is-Tablet-Viewer`. Además, si va a devolver la misma versión de la imagen para tablets y equipos de escritorio, reenvíe solo el encabezado `CloudFront-Is-Tablet-Viewer`, no el `CloudFront-Is-Desktop-Viewer`. Para obtener más información, consulte [Almacenamiento en caché de contenido en función de encabezados de solicitud](header-caching.md). ## Eliminación del encabezado `Accept-Encoding` cuando no sea necesario comprimir Si la compresión no está habilitada, porque el origen no la admite, CloudFront no la admite o el contenido no es compresible, puede aumentar la tasa de aciertos de caché asociando un comportamiento de caché en la distribución con un origen que establezca Custom Origin Header como se muestra a continuación: + **Nombre del encabezado**: `Accept-Encoding` + **Valor de encabezado**: (mantener en blanco) Cuando utiliza esta configuración, CloudFront elimina el encabezado `Accept-Encoding` de la clave de caché y no incluye el encabezado en las solicitudes de origen. Esta configuración se aplica a todo el contenido que CloudFront sirve con la distribución desde ese origen. ## Distribución de contenido multimedia a través de HTTP Para obtener más información acerca de cómo optimizar el contenido de vídeo bajo demanda (VOD) y en streaming, consulte [Video bajo demanda y streaming de video en directo con CloudFront](on-demand-streaming-video.md). # Uso de Amazon CloudFront Origin Shield CloudFront Origin Shield es una capa adicional en la infraestructura de almacenamiento en caché de CloudFront que contribuye a minimizar la carga en el origen, mejorar su disponibilidad y reducir los costos de explotación. Con CloudFront Origin Shield, obtendrá los siguientes beneficios: **Mejor tasa de aciertos de caché** Origin Shield puede contribuir a mejorar la tasa de aciertos de caché de su distribución de CloudFront, ya que proporciona una capa adicional de almacenamiento en caché delante del origen. Cuando utiliza Origin Shield, todas las solicitudes de todas las capas de almacenamiento en caché de CloudFront a su origen pasan por Origin Shield, lo que aumenta la probabilidad de que se produzca un acierto de caché. CloudFront puede recuperar cada objeto con una sola solicitud de origen desde Origin Shield al origen, y todas las demás capas de la caché de CloudFront (ubicaciones de borde y [cachés de borde regionales](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches)) pueden recuperar el objeto desde Origin Shield. **Carga de origen reducida** El escudo de origen puede reducir aún más el número de [solicitudes simultáneas](RequestAndResponseBehaviorCustomOrigin.md#request-custom-traffic-spikes) que se envían a su origen para el mismo objeto. Las solicitudes de contenido que no están en la caché del escudo de origen se consolidan con otras solicitudes para el mismo objeto, por lo que solo una solicitud va a su origen. La gestión de menos solicitudes en su origen puede preservar la disponibilidad del origen durante las cargas máximas o picos de tráfico inesperados y puede reducir los costos de cosas como el empaquetado justo a tiempo, las transformaciones de imágenes y la transferencia de datos (DTO). **Mejor rendimiento de red** Cuando se habilita el escudo de origen en la región de AWS [que tiene la latencia más baja a su origen](#choose-origin-shield-region), puede obtener un mejor rendimiento de red. Para los orígenes de una región de AWS, el tráfico de red de CloudFront permanece en la red de alto rendimiento de CloudFront hasta el origen. Para los orígenes fuera de AWS, el tráfico de red de CloudFront permanece en la red de CloudFront hasta el escudo de origen, que tiene una conexión de baja latencia con su origen. Se incurre en cargos adicionales por usar el escudo de origen. Para obtener más información, consulte los [precios de CloudFront](https://aws.amazon.com/cloudfront/pricing/). **nota** Origin Shield no es compatible con las solicitudes de gRPC. Si una distribución compatible con gRPC tiene Origin Shield activado, las solicitudes de gRPC seguirán funcionando. Sin embargo, las solicitudes se distribuirán directamente al origen de gRPC sin pasar por Origin Shield. Para obtener más información, consulte [Uso de gRPC con distribuciones de CloudFront](distribution-using-grpc.md). **Topics** + [ ## Casos de uso para el escudo de origen ](#origin-shield-use-cases) + [ ## Elección de la región de AWS para Origin Shield ](#choose-origin-shield-region) + [ ## Habilitar Origin Shield ](#enable-origin-shield) + [ ## Estimación de los costos de Origin Shield ](#origin-shield-costs) + [ ## Alta disponibilidad del escudo de origen ](#origin-shield-high-availability) + [ ## Cómo interactúa Origin Shield con otras características de CloudFront ](#origin-shield-and-other-features) ## Casos de uso para el escudo de origen CloudFront Origin Shield puede ser beneficioso en muchos casos de uso, incluidos los siguientes: + Los lectores que se distribuyen en diferentes regiones geográficas + Orígenes que proporcionan empaquetado justo a tiempo para streaming o procesamiento de imágenes sobre la marcha + Orígenes en las instalaciones con limitaciones de capacidad o de ancho de banda + Cargas de trabajo que utilizan varias redes de entrega de contenido (CDN) El escudo de origen puede no ser adecuado en otros casos, como el contenido dinámico que se remite al origen, el contenido con poca capacidad de caché o el contenido que se solicita con poca frecuencia. En las siguientes secciones se explican los beneficios del escudo de origen para los siguientes casos de uso. **Topics** + [ ### Lectores en distintas regiones geográficas ](#os-use-cases-global-viewers) + [ ### Varias CDN ](#os-use-cases-multi-cdn) ### Lectores en distintas regiones geográficas Con Amazon CloudFront, obtiene de forma inherente una carga reducida en su origen porque las solicitudes que CloudFront puede atender desde la caché no van a su origen. Además de la [red global de ubicaciones de borde](https://aws.amazon.com/cloudfront/features/#Amazon_CloudFront_Infrastructure) de CloudFront, las [cachés regionales de borde](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches) sirven como capa de almacenamiento en caché de nivel intermedio para proporcionar aciertos de caché y consolidar solicitudes de origen para los lectores de regiones geográficas cercanas. Las solicitudes de lector se dirigen primero a una ubicación de borde de CloudFront cercana y, si el objeto no está almacenado en caché en esa ubicación, la solicitud se envía a una caché de borde regional. Cuando los lectores se encuentran en distintas regiones geográficas, las solicitudes se pueden dirigir a través de distintas cachés de borde regionales, cada una de las cuales puede enviar una solicitud a su origen para el mismo contenido. Pero con el escudo de origen, obtiene una capa adicional de almacenamiento en caché entre las cachés de borde regionales y su origen. Todas las solicitudes de todas las cachés de borde regionales pasan por el escudo de origen, lo que reduce aún más la carga en su origen. Los siguientes diagramas lo ilustran. En los siguientes diagramas, el origen es AWS Elemental MediaPackage. **Sin escudo de origen** Sin escudo de origen, es posible que su origen reciba solicitudes duplicadas para el mismo contenido, como se muestra en el siguiente diagrama. ![\[Sin CloudFront Origin Shield, el origen podría recibir solicitudes duplicadas.\]](http://docs.aws.amazon.com/es_es/AmazonCloudFront/latest/DeveloperGuide/images/origin-shield-without.png) **Con escudo de origen** El uso del escudo de origen puede contribuir a reducir la carga sobre el origen, como se muestra en el siguiente diagrama. ![\[Con CloudFront Origin Shield, el origen puede recibir menos solicitudes duplicadas.\]](http://docs.aws.amazon.com/es_es/AmazonCloudFront/latest/DeveloperGuide/images/origin-shield-with.png) ### Varias CDN Para ofrecer eventos de vídeo en directo o contenido popular bajo demanda, puede utilizar varias redes de entrega de contenido (CDN). El uso de varias CDN puede ofrecer ciertos beneficios, pero también significa que su origen puede recibir muchas solicitudes duplicadas para el mismo contenido, cada una proveniente de CDN diferentes o diferentes ubicaciones dentro de la misma CDN. Estas solicitudes redundantes podrían afectar negativamente a la disponibilidad de su origen o conllevar costos operativos adicionales para procesos como el empaquetado justo a tiempo o la transferencia de datos (DTO) a Internet. Al combinar Origin Shield con el uso de su distribución de CloudFront como origen para otras CDN, puede obtener los siguientes beneficios: + Menos solicitudes redundantes recibidas en su origen, lo que ayuda a reducir los efectos negativos del uso de varias CDN. + Una [clave de caché](controlling-the-cache-key.md) común en las CDN y administración centralizada para características orientadas al origen. + Mejora del rendimiento de la red. El tráfico de red de otras CDN finaliza en una ubicación de borde de CloudFront cercana, lo que podría proporcionar un acierto de la caché local. Si el objeto solicitado no está en la caché de ubicación de borde, la solicitud al origen permanece en la red de CloudFront hasta Origin Shield, lo que proporciona un alto rendimiento y una baja latencia en el origen. Si el objeto solicitado está en la caché del escudo de origen, la solicitud a su origen se evita por completo. **importante** Si le interesa utilizar el escudo de origen en una arquitectura de CDN múltiples y tiene precios reducidos, [contacte con nosotros](https://aws.amazon.com/contact-us/) o con su representante de ventas de AWS para obtener más información. Podrían aplicarse cargos adicionales. Los siguientes diagramas muestran cómo puede ayudar esta configuración a minimizar la carga en su origen cuando se ofrecen eventos de vídeo en vivo populares con varias CDN. En los siguientes diagramas, el origen es AWS Elemental MediaPackage. **Sin escudo de origen (varias CDN)** Sin el escudo de origen, es posible que su origen reciba muchas solicitudes duplicadas para el mismo contenido, cada una proveniente de una CDN diferente, como se muestra en el siguiente diagrama. ![\[Gráfico que muestra cómo un origen puede recibir solicitudes duplicadas, cada una procedente de una CDN distinta.\]](http://docs.aws.amazon.com/es_es/AmazonCloudFront/latest/DeveloperGuide/images/origin-shield-without-multi-cdn.png) **Con escudo de origen (varias CDN)** Usar Origin Shield con CloudFront como origen para las demás CDN puede ayudar a reducir la carga en su origen, como se muestra en el siguiente diagrama. ![\[Gráfico que muestra CloudFront Origin Shield recibiendo menos solicitudes duplicadas.\]](http://docs.aws.amazon.com/es_es/AmazonCloudFront/latest/DeveloperGuide/images/origin-shield-with-multi-cdn.png) ## Elección de la región de AWS para Origin Shield Amazon CloudFront ofrece el escudo de origen en las regiones de AWS en las que CloudFront tiene una [caché de borde regional](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches). Al activar el escudo de origen, elija la región de AWS para el Escudo de origen. Debe elegir la región de AWS que tenga la latencia más baja a su origen. Puede utilizar el escudo de origen con orígenes que se encuentren en una región de AWS y con orígenes que no estén en AWS. ### Para los orígenes de una región de AWS Si su origen se encuentra en una región de AWS, determine primero si este se encuentra en una región en la que CloudFront ofrece el escudo de origen. CloudFront ofrece el escudo de origen en las siguientes regiones de AWS. + EE. UU. Este (Ohio) – `us-east-2` + EE.UU. Este (Norte de Virginia) – `us-east-1` + EE.UU. Oeste (Oregón) – `us-west-2` + Asia-Pacífico (Bombay) – `ap-south-1` + Asia-Pacífico (Seúl) – (`ap-northeast-2`) + Asia Pacífico (Singapur) – `ap-southeast-1` + Asia-Pacífico (Sídney) – `ap-southeast-2` + Asia-Pacífico (Tokio) – `ap-northeast-1` + Europa (Fráncfort) – `eu-central-1` + Europa (Irlanda) – `eu-west-1` + Europa (Londres) – `eu-west-2` + América del Sur (São Paulo) – `sa-east-1` + Medio Oriente (EAU) – `me-central-1` **Si su origen se encuentra en una región de AWS en la que CloudFront ofrece el escudo de origen** Si el origen se encuentra en una región de AWS en la que CloudFront ofrece el escudo de origen (véase la lista anterior), habilite el escudo de origen en la misma región que el origen. **Si el origen no se encuentra en una región de AWS en la que CloudFront ofrece el escudo de origen** Si el origen no se encuentra en una región de AWS en la que CloudFront ofrece el escudo de origen, consulte la siguiente tabla para determinar en qué región debe habilitarlo. | **Si su origen está en ...** | **Habilite el escudo de origen en ...** | | --- | --- | | EE.UU. Oeste (Norte de California) – `us-west-1` | EE.UU. Oeste (Oregón) – `us-west-2` | | África (Ciudad del Cab) – `af-south-1` | Europa (Irlanda) – `eu-west-1` | | Asia-Pacífico (Hong Kon) – `ap-east-1` | Asia Pacífico (Singapur) – `ap-southeast-1` | | Canadá (Centra) – `ca-central-1` | EE.UU. Este (Norte de Virginia) – `us-east-1` | | Europa (Milá) – `eu-south-1` | UE (Fráncfort) – `eu-central-1` | | Europa (Parí) – `eu-west-3` | UE (Londres) – `eu-west-2` | | Europa (Estocolm) – `eu-north-1` | UE (Londres) – `eu-west-2` | | Medio Oriente (Baréi) – `me-south-1` | Asia-Pacífico (Mumbai) – `ap-south-1` | ### Para orígenes fuera de AWS Puede utilizar el escudo de origen con un origen en las instalaciones o que no esté en una región de AWS. En este caso, habilite el escudo de origen en la región de AWS que tenga la latencia más baja para su origen. Si no está seguro de qué región de AWS tiene la latencia más baja para su origen, puede utilizar las siguientes sugerencias para ayudarle a tomar una decisión. + Puede consultar la tabla anterior para obtener una aproximación de la región de AWS que podría tener la menor latencia para su origen, en función de la ubicación geográfica de su origen. + Puede lanzar instancias Amazon EC2 en diferentes regiones de AWS que estén geográficamente próximas a su origen y ejecutar algunas pruebas utilizando `ping` para medir las latencias de red típicas entre esas regiones y el origen. ## Habilitar Origin Shield Puede habilitar el escudo de origen para mejorar su tasa de aciertos de caché, reducir la carga en el origen y ayudar a mejorar el rendimiento. Para habilitar Origin Shield, cambie la configuración de origen de una distribución de CloudFront. El escudo de origen es una propiedad del origen. Para cada origen de sus distribuciones de CloudFront, puede habilitar el escudo de origen por separado en cualquier región de AWS que ofrezca el mejor rendimiento para dicho origen. Puede habilitar Origin Shield en la consola de CloudFront, con CloudFormation, o con la API de CloudFront. ------ #### [ Console ] **Para habilitar el escudo de origen para un origen existente (consola)** 1. Inicie sesión en Consola de administración de AWS y abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home). 1. Elija la distribución que tiene el origen que desea actualizar. 1. Elija la pestaña **Orígenes**. 1. Elija el origen que desea actualizar y, a continuación, seleccione **Edit (Editar)**. 1. En **Enable Origin Shield (Activar escudo de origen)**, elija **Yes (Sí)**. 1. En **Origin Shield Region (Región de escudo de origen)**, elija la región de AWS donde desea activar el escudo de origen. Para obtener ayuda para elegir una región, consulte [Elección de la región de AWS para Origin Shield](#choose-origin-shield-region). 1. Seleccione **Save changes (Guardar cambios)**. Cuando el estado de distribución esté **Deployed (Implementado)**, el escudo de origen estará listo. Esto lleva unos minutos. **Para habilitar el escudo de origen para un nuevo origen (consola)** 1. Inicie sesión en Consola de administración de AWS y abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home). 1. Para crear el nuevo origen en una distribución existente, haga lo siguiente: 1. Elija la distribución en la que desea crear el origen. 1. Elija **Create Origin (Crear origen)**, y, a continuación, continúe con el paso 3. Para crear el nuevo origen en una nueva distribución estándar, haga lo siguiente: 1. Siga estos pasos para crear una distribución estándar en la consola. Para obtener más información, consulte [Creación de una distribución de CloudFront en la consola](distribution-web-creating-console.md#create-console-distribution). 1. En la sección **Configuración**, elija **Personalizar configuración de origen**. Continúe con el paso 3. 1. En **Enable Origin Shield (Activar escudo de origen)**, elija **Yes (Sí)**. 1. En **Origin Shield Region (Región de escudo de origen)**, elija la región de AWS donde desea activar el escudo de origen. Para obtener ayuda para elegir una región, consulte [Elección de la región de AWS para Origin Shield](#choose-origin-shield-region). 1. Siga los pasos de la consola para terminar de crear el origen o la distribución. Cuando el estado de distribución esté **Deployed (Implementado)**, el escudo de origen estará listo. Esto lleva unos minutos. ------ #### [ CloudFormation ] Para habilitar el escudo de origen con CloudFormation, utilice la propiedad `OriginShield` en el tipo de propiedad `Origin` en un recurso `AWS::CloudFront::Distribution`. Puede agregar la propiedad `OriginShield` a un `Origin` existente o incluirla al crear un nuevo `Origin`. En el siguiente ejemplo se muestra la sintaxis, en formato YAML, para habilitar `OriginShield` en la región EE. UU. Oeste (Oregón) (`us-west-2`). Para obtener ayuda para elegir una región, consulte [Elección de la región de AWS para Origin Shield](#choose-origin-shield-region). En este ejemplo se muestra solo el tipo de propiedad `Origin`, no todo el recurso `AWS::CloudFront::Distribution`. ``` Origins: - DomainName: 3ae97e9482b0d011.mediapackage.us-west-2.amazonaws.com Id: Example-EMP-3ae97e9482b0d011 OriginShield: Enabled: true OriginShieldRegion: us-west-2 CustomOriginConfig: OriginProtocolPolicy: match-viewer OriginSSLProtocols: TLSv1 ``` Para obtener más información, consulte [AWS::CloudFront::Distribution Origin](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-origin.html)‬ en la sección de referencia de recursos y propiedades de la *Guía del usuario de AWS CloudFormation*. ------ #### [ API ] Para habilitar el escudo de origen con la API de CloudFront mediante los SDK de AWS o la AWS Command Line Interface (AWS CLI), utilice el tipo `OriginShield`. Se especifica `OriginShield` en un `Origin`, en una `DistributionConfig`. Para obtener información sobre el tipo `OriginShield`, consulte la siguiente información en la *Referencia de la API de Amazon CloudFront*. + [OriginShield](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_OriginShield.html) (tipo) + [Origin](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_Origin.html) (tipo) + [DistributionConfig](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_DistributionConfig.html) (tipo) + [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) (operación) + [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html) (operación) La sintaxis específica para usar estos tipos y operaciones varía en función del SDK, de la CLI o cliente de API. Para obtener más información, consulte la documentación de referencia de su SDK, CLI o cliente. ------ ## Estimación de los costos de Origin Shield Se acumulan cargos por escudo de origen en función del número de solicitudes que van al escudo de origen como capa incremental. Para las solicitudes dinámicas (no almacenables en caché) que se envían como proxy al origen, el escudo de origen es siempre una capa incremental. Las solicitudes dinámicas utilizan los métodos HTTP `PUT`, `POST`, `PATCH` y `DELETE`. Las solicitudes `GET` y `HEAD` que tienen una configuración de tiempo de vida (TTL) inferior a 3600 segundos se consideran solicitudes dinámicas. Además, las solicitudes `GET` y `HEAD` que deshabilitan el almacenamiento en caché también se consideran solicitudes dinámicas. Para calcular los cargos del escudo de origen para solicitudes dinámicas, utilice la siguiente fórmula: Número total de solicitudes dinámicas **x** cargo de escudo de origen por 10 000 solicitudes **/** 10 000 Para las solicitudes no dinámicas con los métodos HTTP `GET`, `HEAD` y `OPTIONS`, Origin Shield es a veces una capa incremental. Al activar Origin Shield, elija la región de Región de AWS para esa función. Para las solicitudes que van naturalmente a la [memoria caché periférica regional](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches) en la misma región que Origin Shield, no se trata de una capa incremental. No acumula cargos de Origin Shield por estas solicitudes. En el caso de las solicitudes que van a una memoria caché periférica regional en una región diferente de Origin Shield y, a continuación, van a Origin Shield, sí es una capa incremental. Se acumulan cargos del escudo de origen por estas solicitudes. Para calcular los cargos del escudo de origen para solicitudes que se pueden almacenar en caché, utilice la siguiente fórmula: Número total de solicitudes que se pueden almacenar en caché **x** (1: tasa de aciertos de caché) **x** porcentaje de solicitudes que van a Origin Shield desde una caché de borde regional en una región diferente **x** cargo de Origin Shield por 10 000 solicitudes **/** 10 000 Para obtener más información sobre el cargo por cada 10 000 solicitudes de Origin Shield, consulte [Precios de CloudFront](https://aws.amazon.com/cloudfront/pricing/). ## Alta disponibilidad del escudo de origen Origin Shield utiliza la característica de [memorias cachés periféricas regionales](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches) de CloudFront. Cada una de estas cachés de borde se crea en una región de AWS usando al menos tres [zonas de disponibilidad](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) con flotas de instancias Amazon EC2 de escalado automático. Las conexiones originadas en las ubicaciones de CloudFront hacia Origin Shield también usan el seguimiento activo de errores en cada solicitud para direccionar automáticamente la solicitud a una ubicación de Origin Shield secundaria si la principal no está disponible. ## Cómo interactúa Origin Shield con otras características de CloudFront En las secciones siguientes se explica cómo interactúa Origin Shield con otras características de CloudFront. ### Registro de Origin Shield y CloudFront Para ver cuándo ha gestionado una solicitud el escudo de origen, debe habilitar una de las siguientes opciones: + [Registros estándar de CloudFront (registros de acceso)](AccessLogs.md). Los registros estándar se proporcionan de forma gratuita. + [Registros de acceso en tiempo real de CloudFront](real-time-logs.md). Se incurre en cargos adicionales por el uso de registros de acceso en tiempo real. Consulte [Precios de Amazon CloudFront](https://aws.amazon.com/cloudfront/pricing/). Los aciertos de caché de Origin Shield se muestran como `OriginShieldHit` en el campo `x-edge-detailed-result-type` de los registros de CloudFront. Origin Shield utiliza las [cachés regionales de borde](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches) de Amazon CloudFront. Si una solicitud se dirige desde una ubicación de borde de CloudFront a la caché de borde regional que actúa como Origin Shield, se notifica como un `Hit` en los registros, no como un `OriginShieldHit`. ### Escudo de origen y grupos de origen Origin Shield es compatible con los [grupos de orígenes de CloudFront](high_availability_origin_failover.md). Dado que el escudo de origen es una propiedad del origen, las solicitudes siempre viajan a través del escudo de origen para cada origen, incluso cuando el origen forma parte de un grupo de origen. Para una solicitud determinada, CloudFront dirige la solicitud al origen principal en el grupo de origen a través de la instancia de Origin Shield del origen principal. Si esa solicitud devuelve un error (según los criterios de conmutación por error del grupo de orígenes), CloudFront dirige la solicitud al origen secundario a través de la instancia de Origin Shield del origen secundario. ### Escudo de origen y Lambda@Edge El escudo de origen no afecta a la funcionalidad de las funciones de [Lambda @Edge](lambda-at-the-edge.md) pero puede afectar a la región de AWS donde se ejecutan esas funciones. Cuando utiliza el escudo de origen con Lambda @Edge, los [desencadenadores orientados al origen](lambda-cloudfront-trigger-events.md) (solicitud de origen y respuesta de origen) se ejecutan en la región de AWS donde está habilitado el escudo de origen. Si la ubicación de Origin Shield principal no está disponible y CloudFront enruta las solicitudes a una ubicación de Origin Shield secundaria, los desencadenadores orientados al origen de Lambda@Edge también cambiarán para utilizar la ubicación de Origin Shield secundaria. Los desencadenadores orientados al lector no se ven afectados. # Optimización de alta disponibilidad con conmutación por error de origen de CloudFront Puede configurar CloudFront con conmutación por error de origen en los casos en los que se requiera alta disponibilidad. Para empezar, cree un *grupo de origen* con dos orígenes: uno primario y otro secundario. Si el origen principal no está disponible o devuelve códigos de estado de respuesta HTTP específicos que indican un error, CloudFront cambia automáticamente al origen secundario. Para configurar la conmutación por error de origen, debe tener una distribución con al menos dos orígenes. A continuación, cree un grupo de origen para su distribución que incluya dos orígenes, configurando uno como principal. Por último, cree o actualice un comportamiento de caché para utilizar el grupo de origen. Para consultar los pasos para configurar grupos de origen y configurar opciones de conmutación por error de origen específicas, consulte [Creación de un grupo de origen](#concept_origin_groups.creating). Después de configurar la conmutación por error de origen para un comportamiento de la caché, CloudFront hace lo siguiente para las solicitudes del lector: + Cuando hay un acierto de caché, CloudFront devuelve el objeto solicitado. + Cuando hay un error de caché, CloudFront dirige la solicitud al origen principal en el grupo de origen. + Cuando el origen principal devuelve un código de estado que no está configurado para conmutación por error, como un código de estado HTTP 2xx o 3xx, CloudFront envía el objeto solicitado al lector. + Cuando se produce cualquiera de las siguientes situaciones: + El origen principal devuelve un código de estado HTTP que ha configurado para la conmutación por error + CloudFront no se conecta al origen principal (cuando se establece 503 como código de conmutación por error) + La respuesta del origen principal tarda demasiado (se agota el tiempo de espera) (cuando se establece 504 como código de conmutación por error) A continuación, CloudFront dirige la solicitud al origen secundario del grupo de origen. **nota** En algunos casos de uso, como el streaming de contenido de vídeo, es posible que CloudFront conmute por error rápidamente al origen secundario. Para ajustar la rapidez con la que CloudFront conmuta por error al origen secundario, consulte [Control de tiempos de espera e intentos de origen](#controlling-attempts-and-timeouts). CloudFront dirige todas las solicitudes entrantes al origen principal, incluso cuando una solicitud anterior ha conmutado por error al origen secundario. CloudFront solo envía solicitudes al origen secundario después de que se produzca un error en una solicitud al origen principal. CloudFront conmuta por error al origen secundario solo cuando el método HTTP de la solicitud del lector es `GET`, `HEAD` u `OPTIONS`. CloudFront no realiza una conmutación por error cuando el lector envía un método HTTP diferente (por ejemplo `POST`, `PUT`, etc.). **nota** CloudFront no realizará la conmutación por error si `OPTIONS` no se establece como [Métodos HTTP almacenados en caché](DownloadDistValuesCacheBehavior.md#DownloadDistValuesCachedHTTPMethods) en el comportamiento de la caché. El siguiente diagrama ilustra el funcionamiento de la conmutación por error de origen. ![\[Cómo funciona la conmutación por error de origen\]](http://docs.aws.amazon.com/es_es/AmazonCloudFront/latest/DeveloperGuide/images/origingroups-overview.png) **Topics** + [ ## Creación de un grupo de origen ](#concept_origin_groups.creating) + [ ## Control de tiempos de espera e intentos de origen ](#controlling-attempts-and-timeouts) + [ ## Utilizar la conmutación por error de origen con funciones de Lambda@Edge ](#concept_origin_groups.lambda) + [ ## Utilizar páginas de error personalizadas con conmutación por error de origen ](#concept_origin_groups.custom-error) ## Creación de un grupo de origen **Para crear un grupo de origen** 1. Inicie sesión en la Consola de administración de AWS y abra la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home). 1. Elija la distribución para la que desea crear el grupo de origen. 1. Elija la pestaña **Orígenes**. 1. Asegúrese de que la distribución tenga más de un origen. Si no lo tiene, agregue un segundo origen. 1. En la pestaña **Origins** (Orígenes), en el panel **Origin Groups** (Grupos de origen), elija **Create origin group** (Crear grupo de origen). 1. Elija los orígenes del grupo de origen. Después de agregar orígenes, utilice las flechas para establecer la prioridad, es decir, qué origen es primario y cuál secundario. 1. Ingrese un nombre para el grupo de origen. 1. Elija los códigos de estado HTTP que desea utilizar como criterios de conmutación por error. Puede elegir cualquier combinación de los siguientes códigos de estado: 400, 403, 404, 416, 500, 502, 503 o 504. Cuando CloudFront recibe una respuesta con uno de los códigos de estado especificados, conmuta por error al origen secundario. **nota** CloudFront conmuta por error al origen secundario solo cuando el método HTTP de la solicitud del lector es `GET`, `HEAD` u `OPTIONS`. CloudFront no realiza una conmutación por error cuando el lector envía un método HTTP diferente (por ejemplo `POST`, `PUT`, etc.). 1. En **Criterios de selección de origen**, especifique cómo se seleccionan sus orígenes cuando lo solicite el espectador de rutas de distribución. Puede elegir las opciones siguientes. **Predeterminado** CloudFront utilizará la prioridad de origen predeterminada que especifique en la página **Configuración**. **Puntuación de calidad multimedia** CloudFront rastrea y usa esta puntuación para determinar el primer origen al que reenviar la solicitud. Esto también autoriza a CloudFront a realizar solicitudes `HEAD` asincrónicas al origen alternativo del grupo de origen para determinar su nivel de calidad multimedia. Solo puede elegir esta opción para los orígenes v2 de AWS Elemental MediaPackage. Para obtener más información, consulte [Resiliencia basada en la calidad multimedia](media-quality-score.md). 1. Elija **Create origin group** (Crear grupo de origen). Asegúrese de asignar su grupo de origen como el origen del comportamiento de caché de la distribución. Para obtener más información, consulte [Nombre](DownloadDistValuesOrigin.md#DownloadDistValuesId). ## Control de tiempos de espera e intentos de origen De forma predeterminada, CloudFront intenta conectarse al origen primario de un grupo de orígenes durante 30 segundos (3 intentos de conexión de 10 segundos cada uno) antes de conmutar por error al origen secundario. En algunos casos de uso, como el streaming de contenido de vídeo, es posible que desee que CloudFront conmute por error más rápidamente al origen secundario. Puede ajustar la siguiente configuración para que afecte a la rapidez con la que CloudFront conmuta por error al origen secundario. Si el origen es un origen secundario o un origen que no forma parte de un grupo de orígenes, esta configuración afecta a la rapidez con la que CloudFront devuelve una respuesta HTTP 504 al lector. Para conmutar por error más rápidamente, especifique un tiempo de espera de conexión más breve, menos intentos de conexión o ambas opciones. Para orígenes personalizados (incluidos los orígenes de bucket de Amazon S3 *configurados* con alojamiento de sitio web estático), también puede ajustar el tiempo de espera de respuesta de origen. **Tiempo de espera de conexión de origen** La configuración de tiempo de espera de conexión de origen afecta al tiempo que CloudFront espera al intentar establecer una conexión con el origen. De forma predeterminada, CloudFront espera 10 segundos para establecer una conexión, pero puede especificar de 1 a 10 segundos (inclusive). Para obtener más información, consulte [Tiempo de espera de conexión](DownloadDistValuesOrigin.md#origin-connection-timeout). **Intentos de conexión de origen** La configuración de intentos de conexión de origen afecta al número de veces que CloudFront intenta conectarse al origen. De forma predeterminada, CloudFront intenta conectarse 3 veces, pero puede especificar de 1 a 3 (inclusive). Para obtener más información, consulte [Intentos de conexión](DownloadDistValuesOrigin.md#origin-connection-attempts). Para un origen personalizado (incluido un bucket de Amazon S3 configurado con alojamiento de sitios web estático), esta configuración también afecta al número de veces que CloudFront intenta obtener una respuesta del origen en el caso de un tiempo de espera de respuesta del origen. **Tiempo de espera de respuesta de origen** El tiempo de espera de respuesta del origen, también conocido como tiempo de espera de lectura del origen, afecta al tiempo que CloudFront espera para recibir una respuesta (o para recibir la respuesta completa) del origen. De forma predeterminada, CloudFront espera 30 segundos, pero puede especificar de 1 a 120 segundos (ambos inclusive). Para obtener más información, consulte [Tiempo de espera de respuesta](DownloadDistValuesOrigin.md#DownloadDistValuesOriginResponseTimeout). ### Cómo cambiar esta configuración **Para cambiar esta configuración en la [consola de CloudFront](https://console.aws.amazon.com/cloudfront/v4/home)** + Para un nuevo origen o una nueva distribución, especifique estos valores al crear el recurso. + En el caso de un origen existente en una distribución existente, debe especificar estos valores al editar el origen. Para obtener más información, consulte [Referencia de toda la configuración de distribución](distribution-web-values-specify.md). ## Utilizar la conmutación por error de origen con funciones de Lambda@Edge Puede utilizar las funciones Lambda@Edge con distribuciones de CloudFront que haya configurado con grupos de origen. Para utilizar una función Lambda, especifíquela en una [solicitud de origen o un desencadenador de respuesta de origen](lambda-cloudfront-trigger-events.md) para un grupo de origen al crear el comportamiento de la caché. Cuando se utiliza una función Lambda@Edge con un grupo de origen, la función se puede activar dos veces para una sola solicitud de visor. Por ejemplo, considere esta situación: 1. Se crea una función Lambda@Edge con un desencadenador de solicitud de origen. 1. La función Lambda se desencadena una vez cuando CloudFront envía una solicitud al origen principal (en un error de caché). 1. El origen principal responde con un código de estado HTTP configurado para la conmutación por error. 1. La función Lambda se desencadena de nuevo cuando CloudFront envía la misma solicitud al origen secundario. El siguiente diagrama ilustra cómo funciona la conmutación por error de origen cuando se incluye una función de Lambda@Edge en una solicitud de origen o desencadenador de respuesta. ![\[Cómo utilizar la conmutación por error de origen con funciones de Lambda@Edge\]](http://docs.aws.amazon.com/es_es/AmazonCloudFront/latest/DeveloperGuide/images/origingroups-with-lambda-edge.png) Para obtener más información sobre el uso de desencadenadores de Lambda@Edge, consulte [Adición de desencadenadores para una función de Lambda@Edge](lambda-edge-add-triggers.md). Para obtener más información sobre la administración de la conmutación por error de DNS, consulte [Configuring DNS failover](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html) en la *Guía para desarrolladores de Amazon Route 53*. ## Utilizar páginas de error personalizadas con conmutación por error de origen Puede utilizar páginas de error personalizadas con grupos de origen de forma similar a cómo utilizarlos con orígenes que no están configuradas para la conmutación por error de origen. Cuando se utiliza la conmutación por error de origen, puede configurar CloudFront para que devuelva una página de error personalizada para el origen principal o secundario (o ambos): + **Devolver una página de error personalizada para el origen principal**: si el origen principal devuelve un código de estado HTTP que no está configurado para la conmutación por error, CloudFront devuelve la página de error personalizada a los lectores. + **Devolver una página de error personalizada para el origen secundario**: si CloudFront recibe un código de estado de error del origen secundario, CloudFront devuelve la página de error personalizada. Para obtener más información acerca del uso de páginas de error personalizadas con CloudFront, consulte [Generación de respuestas de error personalizadas](GeneratingCustomErrorResponses.md). # Administración de cuánto tiempo se mantiene el contenido en una caché (vencimiento) Puede controlar cuánto tiempo se mantienen los archivos en una caché de CloudFront antes de que CloudFront reenvíe otra solicitud al origen. Reducir la duración le permite ofrecer contenido dinámico. Aumentar la duración implica que sus usuarios podrán disfrutar de un mejor rendimiento ya que es más probable que sus archivos se ofrezcan directamente desde la caché perimetral. Una mayor duración también reduce la carga en el origen. Normalmente, CloudFront ofrece un archivo desde una ubicación periférica durante el tiempo de almacenamiento en caché especificado por usted, es decir, hasta que el archivo venza. Después de que venza, la próxima vez que la ubicación periférica reciba una solicitud de un archivo, CloudFront reenviará la solicitud al servidor de origen para comprobar que la caché contiene la versión más reciente del archivo. La respuesta del origen depende de si el archivo ha cambiado: + Si la caché de CloudFront ya tiene la versión más reciente, el origen devuelve un código de estado `304 Not Modified`. + Si la caché de CloudFront no tiene la versión más reciente, el origen devuelve un código de estado `200 OK` y la versión más reciente del archivo. Si un archivo de una ubicación periférica no se solicita con frecuencia, es posible que CloudFront lo desaloje (lo elimine antes de su fecha de vencimiento) con el fin de dejar espacio para otros archivos que se hayan solicitado más recientemente. Le recomendamos que actualice la política de caché de su distribución para administrar la duración de la caché. Si opta por no utilizar una política de caché, el TTL (período de vida) predeterminado es de 24 horas, pero puede actualizar la siguiente configuración para anular el predeterminado: + Para cambiar la duración del almacenamiento en caché de todos los archivos que coinciden con el mismo patrón de ruta, puede cambiar la configuración de CloudFront para **Minimum TTL (TTL mínimo)**, **Maximum TTL (TTL máximo)** y **Default TTL (TTL predeterminado)** de un comportamiento de la caché. Para obtener información sobre las opciones de configuración individuales, consulte [Tiempo de vida mínimo](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMinTTL), [Tiempo de vida máximo](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL) y [Tiempo de vida (TTL) predeterminado](DownloadDistValuesCacheBehavior.md#DownloadDistValuesDefaultTTL). + Para cambiar la duración del almacenamiento en caché de un archivo individual, puede configurar el origen para agregar un encabezado `Cache-Control` con la política `max-age` o `s-maxage`, o un campo de encabezado `Expires` en el archivo. Para obtener más información, consulte [Uso de encabezados para controlar la duración del almacenamiento en caché de objetos individuales](#expiration-individual-objects). Para obtener más información acerca de cómo **Minimum TTL (TTL mínimo)**, **Default TTL (TTL predeterminado)** y **Maximum TTL (TTL máximo)** interactúan con las políticas `max-age` y `s-maxage` y con el campo de encabezado `Expires`, consulte [Especificación de cuánto tiempo CloudFront almacena objetos en caché](#ExpirationDownloadDist). También puede controlar durante cuánto tiempo los errores (como `404 Not Found`) permanecen en una caché de CloudFront antes de que CloudFront intente obtener de nuevo el objeto solicitado reenviando otra solicitud al origen. Para obtener más información, consulte [Procesamiento de CloudFront de los códigos de estado HTTP 4xx y 5xx desde el origen](HTTPStatusCodes.md). **Topics** + [ ## Uso de encabezados para controlar la duración del almacenamiento en caché de objetos individuales ](#expiration-individual-objects) + [ ## Distribución de contenido obsoleto (caducado) ](#stale-content) + [ ## Especificación de cuánto tiempo CloudFront almacena objetos en caché ](#ExpirationDownloadDist) + [ ## Agregación de encabezados a los objetos con la consola de Amazon S3 ](#ExpirationAddingHeadersInS3) ## Uso de encabezados para controlar la duración del almacenamiento en caché de objetos individuales Puede utilizar los encabezados `Cache-Control` y `Expires` para controlar durante cuánto tiempo permanecen los objetos en la caché. La configuración de **Minimum TTL (Tiempo de vida mínimo)**, **Default TTL (Tiempo de vida predeterminado)** y **Maximum TTL (Tiempo de vida máximo)** también afecta la duración del almacenamiento en caché, pero a continuación encontrará información general acerca de cómo los encabezados pueden influir en la duración de la caché: + La política `Cache-Control max-age` le permite especificar durante cuánto tiempo (en segundos) desea que un objeto permanezca en la caché antes de que CloudFront obtenga el objeto de nuevo del servidor de origen. El tiempo mínimo de caducidad compatible con CloudFront es de 0 segundos. El valor máximo es 100 años. Especifique el valor en el siguiente formato: `Cache-Control: max-age=`*segundos* Por ejemplo, la siguiente política indica a CloudFront que debe mantener el objeto asociado en la caché durante 3600 segundos (una hora): `Cache-Control: max-age=3600` Si desea que los objetos permanezcan en las cachés de borde de CloudFront por un tiempo distinto del que permanecen en las cachés de navegadores, puede utilizar las políticas `Cache-Control max-age` y `Cache-Control s-maxage` de forma conjunta. Para obtener más información, consulte [Especificación de cuánto tiempo CloudFront almacena objetos en caché](#ExpirationDownloadDist). + El campo del encabezado `Expires` le permite especificar una fecha y hora de vencimiento con el formato indicado en [RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1 Section 3.3.1, Full Date](https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3.1), por ejemplo: `Sat, 27 Jun 2015 23:59:59 GMT` Le recomendamos que utilice la directiva `Cache-Control max-age` en lugar del campo de encabezado `Expires` para controlar el almacenamiento de objetos en caché. Si especifica valores para `Cache-Control max-age` y para `Expires`, CloudFront utiliza solo el valor de `Cache-Control max-age`. Para obtener más información, consulte [Especificación de cuánto tiempo CloudFront almacena objetos en caché](#ExpirationDownloadDist). No puede utilizar los campos de encabezado HTTP `Cache-Control` ni `Pragma` en una solicitud `GET` de un lector para obligar a CloudFront a volver al servidor de origen para obtener el objeto. CloudFront ignora los campos de encabezado de las solicitudes de los lectores. Para obtener más información acerca de los campos de encabezado `Cache-Control` y `Expires`, visite las siguientes secciones de *RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1*: + [Section 14.9 Cache Control](https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9) + [Section 14.21 Expires](https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.21) ## Distribución de contenido obsoleto (caducado) CloudFront admite las directivas de control de la caché `Stale-While-Revalidate` y `Stale-If-Error`. Puede usar estas directivas para especificar durante cuánto tiempo estará disponible el contenido obsoleto para los lectores. **Topics** + [ ### `Stale-While-Revalidate` ](#stale-while-revalidate) + [ ### `Stale-If-Error` ](#stale-if-error-only) + [ ### Uso de ambas directivas ](#use-both-stale-directives) ### `Stale-While-Revalidate` Esta directiva permite a CloudFront distribuir contenido obsoleto desde la caché mientras CloudFront obtiene de forma asíncrona una versión nueva del origen. Esto mejora la latencia, ya que los lectores reciben respuestas inmediatamente desde las ubicaciones periféricas sin tener que esperar a la recuperación en segundo plano. El contenido nuevo se carga en segundo plano para futuras solicitudes. **Example Ejemplo:: `Stale-While-Revalidate`** CloudFront hace lo siguiente al configurar el encabezado `Cache-Control` para que utilice estas directivas. ``` Cache-Control: max-age=3600, stale-while-revalidate=600 ``` 1. CloudFront almacenará en caché una respuesta durante una hora (`max-age=3600`). 1. Si se realiza una solicitud después de este tiempo, CloudFront distribuye el contenido obsoleto y, al mismo tiempo, envía una solicitud al origen para revalidar y actualizar el contenido almacenado en caché. 1. Mientras el contenido se vuelve a validar, CloudFront distribuye el contenido obsoleto durante un máximo de 10 minutos (`stale-while-revalidate=600`). **nota** CloudFront distribuirá el contenido obsoleto hasta el valor de la directiva `stale-while-revalidate` o el valor del [TTL máximo](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL) de CloudFront, el valor que sea menor. Una vez transcurrida la duración máxima de TTL, el objeto obsoleto no estará disponible en la caché perimetral, independientemente del valor `stale-while-revalidate`. ### `Stale-If-Error` Esta directiva permite a CloudFront distribuir contenido obsoleto desde la memoria caché si no se puede acceder al origen o devuelve el código de error que está entre 500 y 600. Esto garantiza que los espectadores puedan acceder al contenido incluso durante una interrupción del origen. **Example Ejemplo:: `Stale-If-Error`** CloudFront hace lo siguiente al configurar el encabezado `Cache-Control` para que utilice estas directivas. ``` Cache-Control: max-age=3600, stale-if-error=86400 ``` 1. CloudFront almacena en caché la respuesta durante una hora (`max-age=3600`). 1. Si el origen no funciona o devuelve un error después de este tiempo, CloudFront seguirá distribuyendo el contenido obsoleto durante un máximo de 24 horas (`stale-if-error=86400`) 1. Si configuró respuestas de error personalizadas, CloudFront intentará distribuir el contenido obsoleto si se encuentra un error dentro de la duración de `stale-if-error` especificada. Si el contenido obsoleto no está disponible, CloudFront distribuirá las respuestas de error personalizadas configuradas para el código de estado del error correspondiente. Para obtener más información, consulte [Generación de respuestas de error personalizadas](GeneratingCustomErrorResponses.md). **Notas** CloudFront distribuirá el contenido obsoleto hasta el valor de la directiva `stale-if-error` o el valor del [TTL máximo](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL) de CloudFront, el valor que sea menor. Una vez transcurrida la duración máxima de TTL, el objeto obsoleto no estará disponible en la caché perimetral, independientemente del valor `stale-if-error`. Si no configura `stale-if-error` ni respuestas de error personalizadas, CloudFront devolverá el objeto obsoleto o reenviará la respuesta de error al lector, en función de si el objeto solicitado está en la caché perimetral o no. Para obtener más información, consulte [Cómo CloudFront procesa los errores si no ha configurado las páginas de error personalizadas](HTTPStatusCodes.md#HTTPStatusCodes-no-custom-error-pages). ### Uso de ambas directivas `stale-while-revalidate` y `stale-if-error` son directivas de control de caché independientes que se pueden usar juntas para reducir la latencia y agregar un búfer para que el origen responda o se recupere. **Example Ejemplo: Uso de ambas directivas** CloudFront hace lo siguiente al configurar el encabezado `Cache-Control` para que utilice las siguientes directivas. ``` Cache-Control: max-age=3600, stale-while-revalidate=600, stale-if-error=86400 ``` 1. CloudFront almacena en caché la respuesta durante una hora (`max-age=3600`). 1. Si se realiza una solicitud después de este tiempo, CloudFront distribuye el contenido obsoleto durante un máximo de 10 minutos (`stale-while-revalidate=600`) mientras se vuelve a validar el contenido. 1. Si el servidor de origen devuelve un error mientras CloudFront intenta revalidar el contenido, CloudFront seguirá distribuyendo el contenido obsoleto durante un máximo de 24 horas (`stale-if-error=86400`). El almacenamiento en caché es un equilibrio entre rendimiento y actualización. El uso de directivas como `stale-while-revalidate` y `stale-if-error` puede mejorar el rendimiento y la experiencia del usuario, pero asegúrese de que las configuraciones se ajusten a la actualización que desea que tenga el contenido. Las directivas de contenido obsoletas son las más adecuadas para casos de uso en los que es necesario actualizar el contenido, pero no es esencial tener la versión más reciente. Además, si el contenido no cambia o cambia con poca frecuencia, `stale-while-revalidate` podría agregar solicitudes de red innecesarias. En su lugar, considere establecer una duración de caché larga. ## Especificación de cuánto tiempo CloudFront almacena objetos en caché Para controlar la cantidad de tiempo que CloudFront mantiene un objeto en la caché antes de enviar otra solicitud al origen, puede: + Establecer los valores TTL mínimo, máximo y predeterminado en el comportamiento de la caché de una distribución de CloudFront. Puede establecer estos valores en una [política de caché](controlling-the-cache-key.md) adjunta al comportamiento de caché (recomendado) o en la configuración de caché heredada. + Incluya el encabezado `Cache-Control` o `Expires` en las respuestas del origen. Estos encabezados también ayudan a determinar cuánto tiempo un explorador mantiene un objeto en la caché del explorador antes de enviar otra solicitud a CloudFront. En la tabla siguiente se explica cómo los encabezados `Cache-Control` y `Expires` enviados desde el origen funcionan junto con la configuración TTL en un comportamiento de caché para afectar al almacenamiento en caché. **** | Encabezados de origen | Tiempo de vida mínimo = 0 | Tiempo de vida mínimo > 0 | | --- | --- | --- | | **El origen agrega una directiva de `Cache-Control: max-age` al objeto** | **Almacenamiento en caché de CloudFront** CloudFront almacena en caché el objeto para el menor valor de la directiva `Cache-Control: max-age` o el valor de TTL máximo de CloudFront. **Almacenamiento en caché de navegadores** Los navegadores almacenan en caché el objeto para el valor de la directiva `Cache-Control: max-age`. | **Almacenamiento en caché de CloudFront** El almacenamiento en caché de CloudFront depende de los valores del TTL mínimo y TTL máximo de CloudFront y de la directiva `Cache-Control max-age`: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonCloudFront/latest/DeveloperGuide/Expiration.html) **Almacenamiento en caché de navegadores** Los navegadores almacenan en caché el objeto para el valor de la directiva `Cache-Control: max-age`. | | **El origen no agrega una directiva `Cache-Control: max-age` al objeto** | **Almacenamiento en caché de CloudFront** CloudFront almacena en caché el objeto para el valor del TTL predeterminado de CloudFront. **Almacenamiento en caché de navegadores** Depende del navegador. | **Almacenamiento en caché de CloudFront** CloudFront almacena en caché el objeto para el mayor valor del TTL mínimo de CloudFront o TTL predeterminado. **Almacenamiento en caché de navegadores** Depende del navegador. | | **El origen agrega directivas `Cache-Control: max-age` y `Cache-Control: s-maxage` al objeto** | **Almacenamiento en caché de CloudFront** CloudFront almacena en caché el objeto para el menor valor de la directiva `Cache-Control: s-maxage` o el valor de TTL máximo de CloudFront. **Almacenamiento en caché de navegadores** Los navegadores almacenan en caché el objeto para el valor de la directiva `Cache-Control max-age`. | **Almacenamiento en caché de CloudFront** El almacenamiento en caché de CloudFront depende de los valores del TTL mínimo y TTL máximo de CloudFront y de la directiva `Cache-Control: s-maxage`: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonCloudFront/latest/DeveloperGuide/Expiration.html) **Almacenamiento en caché de navegadores** Los navegadores almacenan en caché el objeto para el valor de la directiva `Cache-Control: max-age`. | | **El origen añade un encabezado `Expires` al objeto** | **Almacenamiento en caché de CloudFront** CloudFront almacena en caché el objeto hasta la fecha del encabezado `Expires` o el valor del TTL máximo de CloudFront, lo que suceda antes. **Almacenamiento en caché de navegadores** Los navegadores almacenan el objeto en la caché hasta la fecha del encabezado `Expires`. | **Almacenamiento en caché de CloudFront** El almacenamiento en caché de CloudFront depende de los valores de los TTL mínimo y máximo de CloudFront y del encabezado `Expires`: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonCloudFront/latest/DeveloperGuide/Expiration.html) **Almacenamiento en caché de navegadores** Los navegadores almacenan el objeto en la caché hasta la fecha y hora del encabezado `Expires`. | | **El origen agrega directivas `Cache-Control: no-cache`, `no-store` o `private` al objeto** | CloudFront y los navegadores respetan los encabezados. | **Almacenamiento en caché de CloudFront** CloudFront almacena en caché el objeto para el valor del TTL mínimo de CloudFront. [Consulte la advertencia debajo de esta tabla](#stale-if-error). **Almacenamiento en caché de navegadores** Los navegadores respetan los encabezados. | **aviso** Si el TTL mínimo es superior a 0, CloudFront utiliza el TTL mínimo de la política de caché, aunque las directivas `Cache-Control: no-cache`, `no-store` o `private` estén presentes en los encabezados de origen. Si se puede acceder al origen, CloudFront obtiene el objeto del origen y lo devuelve al lector. Si no se puede acceder al origen *o* el TTL máximo es mayor que 0, CloudFront servirá el objeto que obtuvo del origen anteriormente. Para evitar este comportamiento, incluya la directiva `Cache-Control: stale-if-error=0` con el objeto devuelto desde el origen. Esto hace que CloudFront devuelva un error en respuesta a solicitudes futuras si el origen es inalcanzable, en lugar de devolver el objeto que obtuvo del origen anteriormente. CloudFront no almacena en caché el código de estado HTTP 501 (no implementado) de un origen de S3 cuando los encabezados de origen incluyen las directivas `Cache-Control: no-cache`, `no-store` o `private`. Este es el comportamiento predeterminado de un origen de S3, incluso si la configuración de [TTL mínima](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMinTTL) es superior a 0. Para obtener información acerca de cómo cambiar la configuración de distribuciones mediante la consola de CloudFront, consulte [Actualizar una distribución](HowToUpdateDistribution.md). Para obtener información sobre cómo cambiar la configuración de las distribuciones con la API de Cloudfront; consulte [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html). ## Agregación de encabezados a los objetos con la consola de Amazon S3 Puede agregar el campo de encabezado `Cache-Control` o `Expires` a los objetos de Amazon S3. Para ello, debe modificar los campos de metadatos del objeto. **Agregación de un campo de encabezado `Cache-Control` o `Expires` a objetos de Amazon S3** 1. Siga el procedimiento de la sección **Sustitución de metadatos definidos por el sistema** en el tema [Edición de metadatos de objetos en la consola de Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-object-metadata.html) de la *Guía del usuario de Amazon S3*. 1. Para **Key (Clave)**, elija el nombre del encabezado que agregará (**Cache-Control** o **Expires**). 1. En **Value (Valor)**, introduzca un valor de encabezado. Por ejemplo, para un encabezado `Cache-Control`, introduzca `max-age=86400`. Para `Expires`, introduzca una fecha y hora de caducidad tal como `Wed, 30 Jun 2021 09:28:00 GMT`. 1. Siga el resto del procedimiento para guardar los cambios en los metadatos. # Almacenamiento en caché de contenido en función de parámetros de cadenas de consulta Algunas aplicaciones web utilizan cadenas de consulta para enviar información al origen. Una cadena de consulta es la parte de una solicitud web que aparece después de un carácter `?` y puede contener uno o varios parámetros, separados por caracteres `&`. En el siguiente ejemplo, la cadena de consulta incluye dos parámetros, *color=red* y *size=large*: `https://d111111abcdef8.cloudfront.net/images/image.jpg?color=red&size=large` Para distribuciones, puede elegir si desea que CloudFront reenvíe cadenas de consultas al origen y si desea almacenar en caché el contenido en función de todos los parámetros o de los parámetros seleccionados. ¿Por qué podría resultar útil? Considere el siguiente ejemplo. Supongamos que su sitio web está disponible en cinco idiomas. La estructura de directorios y los nombres de archivo de las cinco versiones del sitio web son idénticos. Cuando un usuario consulta el sitio web, las solicitudes que se reenvían a CloudFront incluyen un parámetro de cadena de consulta de idioma en función del idioma elegido por el usuario. Puede configurar CloudFront para reenviar cadenas de consulta al origen y almacenar en caché en función del parámetro de idioma. Si configura el servidor web para devolver la versión de una página determinada que se corresponda con el idioma seleccionado, CloudFront almacena en la caché cada versión del idioma por separado, en función del valor del parámetro de cadena de consulta del idioma. En este ejemplo, si la página principal para el sitio web es `main.html`, las siguientes cinco solicitudes hacen que CloudFront almacene cinco veces en la caché `main.html`, una vez por cada valor de parámetro de cadena de consulta de idioma: + `https://d111111abcdef8.cloudfront.net/main.html?language=de` + `https://d111111abcdef8.cloudfront.net/main.html?language=en` + `https://d111111abcdef8.cloudfront.net/main.html?language=es` + `https://d111111abcdef8.cloudfront.net/main.html?language=fr` + `https://d111111abcdef8.cloudfront.net/main.html?language=jp` Tenga en cuenta lo siguiente: + Algunos servidores HTTP no procesan parámetros de cadenas de consulta y, por lo tanto, no devuelven distintas versiones de un objeto en función de los valores de los parámetros. Para estos orígenes, si configura CloudFront para reenviar los parámetros de cadenas de consulta al origen, CloudFront sigue almacenando en caché en función de los valores de los parámetros a pesar de que el origen devuelva versiones idénticas del objeto a CloudFront para cada valor del parámetro. + Para que los parámetros de cadenas de consulta funcionen tal y como se describe en el ejemplo anterior con los idiomas, debe utilizar el carácter `&` como delimitador entre parámetros de cadenas de consulta. Si utiliza un delimitador diferente, es posible que obtenga resultados imprevistos, en función de los parámetros que especifique para que CloudFront utilice como base para el almacenamiento en caché y del orden en el que aparecen los parámetros en la cadena de consulta. Los siguientes ejemplos muestran lo que ocurre si utiliza un delimitador diferente y configura CloudFront para almacenar en caché solo en función del parámetro `color`: + En la siguiente solicitud, CloudFront almacena en caché el contenido en función del valor del parámetro `color`, pero CloudFront interpreta el valor como *red;size=large*: `https://d111111abcdef8.cloudfront.net/images/image.jpg?color=red;size=large` + En la siguiente solicitud, CloudFront almacena en caché el contenido pero no en función de los parámetros de cadenas de consulta. Esto se debe a que ha configurado CloudFront para almacenar en caché en función del parámetro `color`, pero CloudFront interpreta la siguiente cadena como que contiene solo un parámetro `size` con el valor *large;color=red*: `https://d111111abcdef8.cloudfront.net/images/image.jpg?size=large;color=red` Puede configurar CloudFront para que realice una de las siguientes acciones: + No enviar cadenas de consultas al origen. Si no reenvía cadenas de consultas, CloudFront no almacena en caché en función de parámetros de cadenas de consulta. + Reenviar cadenas de consulta al origen y almacenar en caché en función de todos los parámetros de la cadena de consulta. + Reenviar cadenas de consulta al origen y almacenar en caché en función de parámetros especificados en la cadena de consulta. Para obtener más información, consulte [Optimización del almacenamiento en caché](#query-string-parameters-optimizing-caching). **Topics** + [ ## Configuración de la consola y de la API para el reenvío de cadenas de consulta y almacenamiento en caché ](#query-string-parameters-console) + [ ## Optimización del almacenamiento en caché ](#query-string-parameters-optimizing-caching) + [ ## Parámetros de cadena de consulta y registros estándar de CloudFront (registros de acceso) ](#query-string-parameters-access-logs) ## Configuración de la consola y de la API para el reenvío de cadenas de consulta y almacenamiento en caché Al crear una distribución en la consola de CloudFront, CloudFront configura el reenvío y el almacenamiento en caché de cadenas de consulta en función del tipo de origen. Si lo desea, puede editar manualmente esta configuración. Para obtener más información, consulte la siguiente configuración en la [Referencia de toda la configuración de distribución](distribution-web-values-specify.md): + [Reenvío de cadenas de consulta y almacenamiento en caché](DownloadDistValuesCacheBehavior.md#DownloadDistValuesQueryString) + [Lista de permitidos de cadenas de consulta](DownloadDistValuesCacheBehavior.md#DownloadDistValuesQueryStringAllowlist) Para configurar el reenvío y el almacenamiento en caché de cadenas de consulta con la API de CloudFront, consulte [CachePolicy](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CachePolicy.html) y [OriginRequestPolicy](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_OriginRequestPolicy.html) en la *referencia de la API de Amazon CloudFront*. ## Optimización del almacenamiento en caché Cuando se configura CloudFront para almacenar en caché en función de parámetros de cadenas de consulta, puede realizar los siguientes pasos para reducir el número de solicitudes que CloudFront reenvía al origen. Cuando las ubicaciones periférica de CloudFront sirven objetos, se reduce la carga en el servidor de origen y se reduce la latencia porque los objetos se sirven desde ubicaciones más cercanas a los usuarios. **Almacene en caché solo en función de parámetros por los que su origen devuelve diferentes versiones de un objeto** Por cada parámetro de cadena de consulta que la aplicación web reenvía a CloudFront, CloudFront reenvía solicitudes al origen por cada valor del parámetro y almacena en caché una versión independiente del objeto por cada valor del parámetro. Esto ocurre incluso si el origen siempre devuelve el mismo objeto independientemente del valor del parámetro. Para varios parámetros, el número de solicitudes y el número de objetos se multiplican. Le recomendamos configurar CloudFront para almacenar en caché solo los parámetros de cadenas de consulta para los que el origen devuelve distintas versiones y que piense detenidamente en las ventajas de almacenar en caché en función de cada parámetro. Supongamos que tiene un sitio web de venta al por menor. Dispone de imágenes de una chaqueta en seis colores diferentes y la chaqueta está disponible en diez tallas distintas. Sus imágenes de la chaqueta muestran los distintos colores, pero no las distintas tallas. Para optimizar el almacenamiento en caché, debe configurar CloudFront para almacenar en caché solo en función del parámetro de color, no el de tamaño. Esto aumenta la probabilidad de que CloudFront pueda atender una solicitud de la caché, lo que mejora el rendimiento y reduce la carga en el origen. **Organice los parámetros siempre en el mismo orden** El orden de los parámetros de cadenas de consulta es importante. En el siguiente ejemplo, las cadenas de consulta son idénticas, salvo que los parámetros están en órdenes diferentes. Esto hace que CloudFront reenvíe dos solicitudes de image.jpg independientes al origen y que almacene en caché dos versiones independientes del objeto: + `https://d111111abcdef8.cloudfront.net/images/image.jpg?color=red&size=large` + `https://d111111abcdef8.cloudfront.net/images/image.jpg?size=large&color=red` Le recomendamos enumerar los nombres de los parámetros siempre en el mismo orden, por ejemplo, por orden alfabético. **Utilice siempre el mismo tipo de letra (mayúsculas o minúsculas) para los nombres y valores de parámetros** CloudFront diferencia mayúsculas de minúsculas en los valores y nombres de los parámetros al almacenar en caché en función de los parámetros de cadenas de consulta. En el siguiente ejemplo, las cadenas de consulta son idénticas, salvo por las mayúsculas y minúsculas de los nombres y valores del parámetro. Esto hace que CloudFront reenvíe cuatro solicitudes de image.jpg independientes al origen y que almacene en caché cuatro versiones independientes del objeto: + `https://d111111abcdef8.cloudfront.net/images/image.jpg?color=red` + `https://d111111abcdef8.cloudfront.net/images/image.jpg?color=Red` + `https://d111111abcdef8.cloudfront.net/images/image.jpg?Color=red` + `https://d111111abcdef8.cloudfront.net/images/image.jpg?Color=Red` Recomendamos utilizar mayúsculas o minúsculas de forma consistente en los valores y nombres de parámetros, como todo en minúsculas. **No utilice nombres de parámetros que entren en conflicto con URL firmadas** Si utiliza URL firmadas para restringir el acceso al contenido (si ha agregado signatarios de confianza a la distribución), CloudFront elimina los siguientes parámetros de cadenas de consulta antes de reenviar el resto de la URL al origen: + `Expires` + `Key-Pair-Id` + `Policy` + `Signature` Si utiliza URL firmadas y desea configurar CloudFront para reenviar cadenas de consulta al origen, sus propios parámetros de cadenas de consulta no pueden denominarse `Expires`, `Key-Pair-Id`, `Policy` ni `Signature`. ## Parámetros de cadena de consulta y registros estándar de CloudFront (registros de acceso) Si habilita el registro, CloudFront registra la URL completa, incluidos los parámetros de cadenas de consulta. Esto ocurre independientemente de si ha configurado CloudFront para reenviar cadenas de consulta al origen. Para obtener más información acerca del registro de CloudFront, consulte [Registros de acceso (registros estándar)](AccessLogs.md). # Almacenamiento en caché de contenido en función de cookies De forma predeterminada, CloudFront no tiene en cuenta las cookies al procesar solicitudes y respuestas, ni al almacenar en caché los objetos en ubicaciones periférica. Si CloudFront recibe dos solicitudes que sean idénticas excepto por lo que está en el encabezado de `Cookie`, de forma predeterminada, CloudFront trata las solicitudes como idénticas y devuelve el mismo objeto para ambas solicitudes. Puede configurar CloudFront para reenviar al origen algunas o todas las cookies de las solicitudes de los lectores y para almacenar en caché diferentes versiones de los objetos en función de los valores de las cookies de las solicitudes que reenvía. Al hacerlo, CloudFront utiliza algunas o todas las cookies de las solicitudes de lectores (las que esté configurado para reenviar) para identificar de forma única un objeto en la caché. Supongamos que las solicitudes de `locations.html` contienen una cookie `country` con un valor de `uk` o `fr`. Al configurar CloudFront para almacenar los objetos en la caché en función del valor de la cookie `country`, CloudFront reenvía al origen las solicitudes de `locations.html` e incluye la cookie `country` y su valor. El origen devuelve `locations.html` y CloudFront almacena el objeto una vez en la caché para las solicitudes cuyo valor de la cookie `country` sea `uk` y otra vez para las solicitudes cuyo valor de la cookie sea `fr`. **importante** Amazon S3 y algunos servidores HTTP no procesan cookies. No configure CloudFront para reenviar cookies a un origen que no procese cookies o que no varíe su respuesta en función de las cookies. Esto puede hacer que CloudFront reenvíe más solicitudes al origen para el mismo objeto, lo que ralentiza el rendimiento y aumenta la carga en el origen. Si, teniendo en cuenta el ejemplo anterior, su origen no procesa la cookie `country` o siempre devuelve la misma versión de `locations.html` a CloudFront independientemente del valor de la cookie `country`, no configure CloudFront para que reenvíe esa cookie. Por el contrario, si el origen personalizado depende de una cookie en particular o envía diferentes respuestas en función de una cookie, asegúrese de configurar CloudFront para que reenvíe esa cookie al origen. De lo contrario, CloudFront elimina la cookie antes de reenviar la solicitud al origen. Para configurar el reenvío de cookies, actualice el comportamiento de la caché de su distribución. Para obtener más información acerca de los comportamientos de caché, consulte [Configuración del comportamiento de la caché](DownloadDistValuesCacheBehavior.md) y, en particular, las secciones [Reenvío de cookies](DownloadDistValuesCacheBehavior.md#DownloadDistValuesForwardCookies) y [Cookies de lista de permitidos](DownloadDistValuesCacheBehavior.md#DownloadDistValuesAllowlistCookies). Puede configurar cada comportamiento de la caché para realizar una de las siguientes acciones: + **Reenviar todas las cookies al origen**: CloudFront incluye todas las cookies enviadas por el lector cuando reenvía las solicitudes al origen. Cuando el origen devuelve una respuesta, CloudFront almacena en caché la respuesta utilizando los nombres y valores de las cookies en la solicitud del lector. Si la respuesta de origen incluye encabezados `Set-Cookie`, CloudFront los devuelve al lector con el objeto solicitado. CloudFront también almacena en caché los encabezados `Set-Cookie` con el objeto devuelto desde el origen y envía esos encabezados `Set-Cookie` a los lectores en todos los aciertos de caché. + **Reenviar un conjunto de cookies que especifique**: CloudFront elimina las cookies que el lector envía y que no están en la lista blanca antes de que reenvíe una solicitud al origen. CloudFront almacena en caché la respuesta mediante el uso de los nombres y los valores de las cookies enumerados en la solicitud del lector. Si la respuesta de origen incluye encabezados `Set-Cookie`, CloudFront los devuelve al lector con el objeto solicitado. CloudFront también almacena en caché los encabezados `Set-Cookie` con el objeto devuelto desde el origen y envía esos encabezados `Set-Cookie` a los lectores en todos los aciertos de caché. Para obtener información acerca de la especificación de comodines en nombres de cookies, consulte [Cookies de lista de permitidos](DownloadDistValuesCacheBehavior.md#DownloadDistValuesAllowlistCookies). Para consultar la cuota actual de la cantidad de nombres de cookies que puede reenviar para cada comportamiento de la caché o para solicitar una ampliación de la cuota, consulte [Cuotas en cadenas de consulta (configuración de caché heredada)](cloudfront-limits.md#limits-allowlisted-query-strings). + **No reenviar las cookies al origen**: CloudFront no almacena los objetos en caché según las cookies enviadas por el lector. Además, CloudFront elimina las cookies antes de reenviar las solicitudes al origen y elimina los encabezados `Set-Cookie` de las respuestas antes de devolver las respuestas a los lectores. Como esta no es la forma óptima de utilizar los recursos de origen, al seleccionar este comportamiento de caché, debe asegurarse de que el origen no incluya cookies en las respuestas de origen de forma predeterminada. Tenga en cuenta lo siguiente acerca de especificar las cookies que desea reenviar: **Logs de acceso** Si configura CloudFront para registrar solicitudes y registrar cookies, CloudFront registra todas las cookies y todos los atributos de cookies, incluso si configura CloudFront para no reenviar cookies al origen o si configura CloudFront para reenviar solo cookies específicas. Para obtener más información acerca del registro de CloudFront, consulte [Registros de acceso (registros estándar)](AccessLogs.md). **Sensibilidad de mayúsculas y minúsculas** Los nombres y valores de las cookies distinguen entre mayúsculas y minúsculas. Por ejemplo, si se configura CloudFront para reenviar todas las cookies y dos solicitudes de lector para el mismo objeto tienen cookies que son idénticas excepto por el caso, CloudFront almacena el objeto dos veces en la caché. **CloudFront ordena las cookies** Si se configura CloudFront para reenviar las cookies (todas o un subconjunto), CloudFront ordena las cookies en orden natural por nombre de cookie antes de reenviar la solicitud al origen. No se admiten nombres de cookies que empiecen por el carácter `$`. CloudFront eliminará la cookie antes de reenviar la solicitud al origen. Puede eliminar el carácter `$` o especificar otro distinto al principio del nombre de la cookie. **`If-Modified-Since` y `If-None-Match`** Las solicitudes condicionales `If-Modified-Since` y `If-None-Match` no son compatibles cuando CloudFront se configura para reenviar cookies (todas o un subconjunto). **Formato necesario de pares de nombre-valor estándar** CloudFront reenvía un encabezado de cookie solo si el valor se ajusta al [formato estándar de pares de nombre-valor](https://tools.ietf.org/html/rfc6265#section-4.1.1), por ejemplo: `"Cookie: cookie1=value1; cookie2=value2"` **Deshabilitar el almacenamiento en caché de los encabezados `Set-Cookie`** Si se configura CloudFront para reenviar cookies al origen (ya sean todas o cookies específicas), también almacena en caché los encabezados `Set-Cookie` recibidos en la respuesta de origen. CloudFront incluye estos encabezados `Set-Cookie` en la respuesta al lector original y también los incluye en las respuestas posteriores que se sirven desde la caché de CloudFront. Si desea recibir cookies en el origen pero no desea que CloudFront almacene en caché los encabezados `Set-Cookie` en las respuestas del origen, configure el origen para agregar un encabezado `Cache-Control` con una política de `no-cache` que especifique `Set-Cookie` como nombre de campo. Por ejemplo: `Cache-Control: no-cache="Set-Cookie"`. Para obtener más información, consulte [Directivas de respuesta de control de caché](https://tools.ietf.org/html/rfc7234#section-5.2.2) en el *protocolo de transferencia de hipertexto (HTTP/1.1): almacenamiento en caché* estándar. **Longitud máxima de los nombres de las cookies** Si configura CloudFront para reenviar cookies específicas al origen, la cantidad total de bytes en todos los nombres de cookies que configure para que CloudFront los reenvíe no puede superar los 512 menos la cantidad de cookies que reenvía. Por ejemplo, si configura CloudFront para reenviar 10 cookies al origen, la longitud combinada de los nombres de las 10 cookies no puede superar los 502 bytes (512-10). Si configura CloudFront para reenviar todas las cookies al origen, la longitud de los nombres de las cookies no importa. Para obtener más información acerca del uso de la consola de CloudFront para actualizar una distribución de modo que CloudFront reenvíe las cookies al origen, consulte [Actualizar una distribución](HowToUpdateDistribution.md). Para obtener información sobre el uso de la API de CloudFront para actualizar una distribución, consulte [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) en la *Referencia de la API de Amazon CloudFront*. # Almacenamiento en caché de contenido en función de encabezados de solicitud CloudFront le permite elegir si desea que CloudFront reenvíe los encabezados al origen y almacene en caché diferentes versiones de un objeto especificado en función de los valores de encabezado de las solicitudes de los lectores. Esto le permite ofrecer distintas versiones del contenido en función del dispositivo del usuario, la ubicación del espectador, su idioma y otros criterios. **Topics** + [ ## Encabezados y distribuciones: información general ](#header-caching-web) + [ ## Selección de los encabezados para basar el almacenamiento en caché ](#header-caching-web-selecting) + [ ## Configuración de CloudFront para que respete la configuración de CORS ](#header-caching-web-cors) + [ ## Configuración del almacenamiento en caché en función del tipo de dispositivo ](#header-caching-web-device) + [ ## Configuración del almacenamiento en caché en función del idioma del lector ](#header-caching-web-language) + [ ## Configuración del almacenamiento en caché en función de la ubicación del lector ](#header-caching-web-location) + [ ## Configuración del almacenamiento en caché en función del protocolo de la solicitud ](#header-caching-web-protocol) + [ ## Configuración del almacenamiento en caché para archivos comprimidos ](#header-caching-web-compressed) + [ ## Cómo afecta al rendimiento el almacenamiento en caché en función de los encabezados ](#header-caching-web-performance) + [ ## Cómo afectan al almacenamiento en caché las mayúsculas o minúsculas de los encabezados y sus valores ](#header-caching-web-case) + [ ## Encabezados que CloudFront devuelve al lector ](#header-caching-web-response) ## Encabezados y distribuciones: información general De forma predeterminada, CloudFront no tiene en cuenta los encabezados al almacenar los objetos en la caché en ubicaciones periférica. Si el origen devuelve dos objetos que se diferencian solo por los valores de los encabezados de solicitud, CloudFront almacena solo una versión del objeto en la caché. Puede configurar CloudFront para reenviar los encabezados al origen, lo que hace que CloudFront almacene en caché varias versiones de un objeto en función de los valores en uno o varios encabezados de solicitud. Para configurar CloudFront para almacenar en caché los objetos en función de los valores de encabezados específicos, se especifica la configuración del comportamiento de la caché para la distribución. Para obtener más información, consulte [Caché en función de encabezados de solicitud seleccionados](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesForwardHeaders). Supongamos que las solicitudes de espectadores de `logo.jpg` contienen un encabezado personalizado `Product` con un valor de `Acme` o `Apex`. Al configurar CloudFront para que almacene en caché los objetos en función del valor del encabezado `Product`, CloudFront reenvía solicitudes de `logo.jpg` al origen e incluye el encabezado `Product` y los valores del encabezado. CloudFront almacena en caché `logo.jpg` una vez por cada solicitud cuyo valor del encabezado `Product` es `Acme` y otra vez por cada solicitud cuyo valor es `Apex`. Puede configurar cada comportamiento de la caché en una distribución para realizar una de las siguientes acciones: + Reenviar todos los encabezados al origen **nota** **Para configuraciones de caché heredadas**: si configura CloudFront para reenviar todos los encabezados al origen, CloudFront no almacena en caché los objetos asociados con este comportamiento de la caché. En su lugar, envía todas las solicitudes al origen. + Reenvíe una lista de encabezados que especifique. CloudFront almacena en caché los objetos en función de los valores de todos los encabezados especificados. CloudFront también reenvía los encabezados que reenvía de forma predeterminada, pero almacena en caché los objetos solo según los encabezados que especifique. + Reenviar solo los encabezados predeterminados. En esta configuración, CloudFront no almacena los objetos en caché en función de los valores de los encabezados de solicitudes. Para consultar la cuota actual de la cantidad de encabezados que puede reenviar para cada comportamiento de la caché o para solicitar una ampliación de la cuota, consulte [Cuotas en encabezados](cloudfront-limits.md#limits-custom-headers). Para obtener información acerca del uso de la consola de CloudFront para actualizar una distribución de modo que CloudFront reenvíe encabezados al origen, consulte [Actualizar una distribución](HowToUpdateDistribution.md). Para obtener información sobre el uso de la API de CloudFront para actualizar una distribución existente, consulte [Actualizar distribución](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) en la *Referencia de la API de Amazon CloudFront*. ## Selección de los encabezados para basar el almacenamiento en caché Los encabezados que puede reenviar al origen y en los que CloudFront basa el almacenamiento en caché dependen de si el origen es un bucket de Amazon S3 o un origen personalizado. + **Amazon S3**: puede configurar CloudFront para reenviar y almacenar en caché los objetos en función de un número de encabezados específicos (consulte la lista de excepciones que se muestra a continuación). Sin embargo, le recomendamos que evite reenviar encabezados con un origen de Amazon S3, excepto que necesite implementar el uso compartido de recursos entre orígenes (CORS) o desee personalizar contenido mediante Lambda@Edge en eventos producidos en el origen. + Para configurar CORS, debe reenviar encabezados que permitan a CloudFront distribuir contenido para sitios web que están habilitados para el uso compartido de recursos entre orígenes (CORS). Para obtener más información, consulte [Configuración de CloudFront para que respete la configuración de CORS](#header-caching-web-cors). + Para personalizar el contenido mediante el uso de encabezados que reenvía al origen de Amazon S3, debe escribir y agregar funciones Lambda@Edge y asociarlas a la distribución de CloudFront para desencadenarlas mediante un evento producido en el origen. Para obtener más información acerca del uso de encabezados para personalizar contenido, consulte [Personalización de contenido por encabezados de tipo de dispositivo o país: ejemplos](lambda-examples.md#lambda-examples-redirecting-examples). Le recomendamos que evite reenviar encabezados que no esté utilizando para la personalización de contenido, ya que el reenvío de encabezados adicionales puede reducir la tasa de aciertos de caché. Es decir, CloudFront; no puede atender tantas solicitudes de cachés perimetrales, como una proporción de todas las solicitudes. + **Origen personalizado**: puede configurar CloudFront para almacenar en caché en función del valor de cualquier encabezado de solicitud, excepto los siguientes: + `Connection` + `Cookie`: si desea reenviar y almacenar en caché en función de las cookies, utilice otra configuración diferente en la distribución. Para obtener más información, consulte [Almacenamiento en caché de contenido en función de cookies](Cookies.md). + `Host (for Amazon S3 origins)` + `Proxy-Authorization` + `TE` + `Upgrade` Puede configurar CloudFront para almacenar en caché los objetos en función de los valores de los encabezados `Date` y `User-Agent`, pero no lo recomendamos. Estos encabezados tienen muchos valores posibles y el almacenamiento en caché en función de los valores podría hacer que CloudFront reenvíe una cantidad de solicitudes significativamente mayor al origen. Para obtener una lista completa de encabezados de solicitudes HTTP y cómo los procesa CloudFront, consulte [Encabezados de solicitudes HTTP y comportamiento de CloudFront (personalizado y orígenes de Amazon S3)](RequestAndResponseBehaviorCustomOrigin.md#request-custom-headers-behavior). ## Configuración de CloudFront para que respete la configuración de CORS Si ha habilitado el uso compartido de recursos entre orígenes (CORS) en un bucket de Amazon S3 o en un origen personalizado, debe elegir encabezados específicos para reenviar, para respetar la configuración CORS. Los encabezados que debe reenviar difieren en función del origen (Amazon S3 o personalizado) y si desea almacenar las respuestas de `OPTIONS` en caché. **Amazon S3** + Si desea que las respuestas `OPTIONS` se almacenen en caché, haga lo siguiente: + Elija las opciones para la configuración de comportamiento de la caché predeterminado que habilitan el almacenamiento en caché para respuestas de `OPTIONS`. + Configure CloudFront para reenviar los siguientes encabezados: `Origin`, `Access-Control-Request-Headers`, y `Access-Control-Request-Method`. + Si no desea que las respuestas de `OPTIONS` se almacenen en caché, configure CloudFront para reenviar el encabezado `Origin`, junto con los demás encabezados requeridos por el origen (por ejemplo `Access-Control-Request-Headers`, `Access-Control-Request-Method` u otros). **Orígenes personalizados**: reenvíe el encabezado `Origin` junto con los demás encabezados exigidos por el origen. Para configurar CloudFront con el fin de que almacene en caché en caché en función de CORS, debe configurar CloudFront para reenviar los encabezados mediante una política de caché. Para obtener más información, consulte [Control de la clave de caché con una política](controlling-the-cache-key.md). Para obtener más información sobre CORS y Amazon S3, consulte [Uso compartido de recursos entre orígenes (CORS)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/cors.html) en la *Guía del usuario de Amazon Simple Storage Service*. ## Configuración del almacenamiento en caché en función del tipo de dispositivo Si desea que CloudFront almacene en caché diferentes versiones de los objetos en función del dispositivo que el usuario utilice para consultar el contenido, configure CloudFront para reenviar los encabezados aplicables al origen personalizado: + `CloudFront-Is-Desktop-Viewer` + `CloudFront-Is-Mobile-Viewer` + `CloudFront-Is-SmartTV-Viewer` + `CloudFront-Is-Tablet-Viewer` En función del valor del encabezado `User-Agent`, CloudFront establece el valor de estos encabezados en `true` o `false` antes de reenviar la solicitud al origen. Si un dispositivo entra en más de una categoría, más de un valor podría ser `true`. Por ejemplo, en el caso de algunas tabletas, CloudFront podría establecer tanto `CloudFront-Is-Mobile-Viewer` como `CloudFront-Is-Tablet-Viewer` en `true`. ## Configuración del almacenamiento en caché en función del idioma del lector Si desea que CloudFront almacene en caché distintas versiones de los objetos en función del idioma especificado en la solicitud, configure CloudFront para reenviar el encabezado `Accept-Language` al origen. ## Configuración del almacenamiento en caché en función de la ubicación del lector Si desea que CloudFront almacene en caché distintas versiones de los objetos en función del país del que provino la solicitud, configure CloudFront para reenviar el encabezado `CloudFront-Viewer-Country` al origen. CloudFront convierte automáticamente la dirección IP de la que provino la solicitud en un código de país de dos letras. Para obtener una lista sencilla de códigos de país, organizable por código y por nombre de país, consulte la entrada de Wikipedia [ISO 3166-1 alpha-2](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2). ## Configuración del almacenamiento en caché en función del protocolo de la solicitud Si desea que CloudFront almacene en caché distintas versiones de los objetos en función del protocolo de la solicitud (HTTP o HTTPS), configure CloudFront para reenviar el encabezado `CloudFront-Forwarded-Proto` al origen. ## Configuración del almacenamiento en caché para archivos comprimidos Si el origen admite compresión Brotli, puede almacenar en caché en función del encabezado `Accept-Encoding`. Configure el almacenamiento en caché en función de `Accept-Encoding` solo si el origen ofrece contenido en función del encabezado. ## Cómo afecta al rendimiento el almacenamiento en caché en función de los encabezados Si configura CloudFront para almacenar en caché en función de uno o varios encabezados y los encabezados tienen más de un valor posible, CloudFront reenvía más solicitudes al servidor de origen para el mismo objeto. Esto afecta negativamente el desempeño y aumenta la carga en su servidor de origen. Si el servidor de origen devuelve el mismo objeto independientemente del valor de un encabezado determinado, le recomendamos que no configure CloudFront para almacenar en caché en función de ese encabezado. Si configura CloudFront para reenviar más de un encabezado, el orden de los encabezados de las solicitudes de los lectores no afecta al almacenamiento en caché siempre y cuando los valores sean los mismos. Por ejemplo, si una solicitud contiene los encabezados A:1,B:2 y otra solicitud contiene B:2,A:1, CloudFront almacena en caché solo una copia del objeto. ## Cómo afectan al almacenamiento en caché las mayúsculas o minúsculas de los encabezados y sus valores Cuando CloudFront almacena en caché en función de los valores del encabezado, pasa por alto el uso de mayúsculas y minúsculas en los nombres de encabezado, pero lo tiene en cuenta en el caso del valor de encabezado: + Si las solicitudes de lector incluyen `Product:Acme` y `product:Acme`, CloudFront almacena en caché un objeto solo una vez. La única diferencia entre ellos es el uso de mayúsculas y minúsculas en el nombre del encabezado, lo que no afecta el almacenamiento en caché. + Si las solicitudes de lector incluyen `Product:Acme` y `Product:acme`, CloudFront almacena en caché un objeto dos veces, porque el valor es `Acme` en algunas solicitudes y `acme` en otras. ## Encabezados que CloudFront devuelve al lector La configuración de CloudFront para reenviar y almacenar en caché los encabezados no afecta a los encabezados que CloudFront devuelve al lector. CloudFront devuelve todos los encabezados que obtiene del origen con algunas excepciones. Para obtener más información, consulte el tema correspondiente: + **Orígenes de Amazon S3**: consulte [Encabezados de respuesta HTTP que CloudFront elimina o actualiza](RequestAndResponseBehaviorS3Origin.md#response-s3-removed-headers). + **Orígenes personalizados**: consulte [Encabezados de respuesta HTTP que CloudFront elimina o reemplaza](RequestAndResponseBehaviorCustomOrigin.md#ResponseCustomRemovedHeaders).