# Prácticas recomendadas para patrones de diseño: optimizar el rendimiento de Amazon S3
Sus aplicaciones pueden lograr fácilmente miles de transacciones por segundo en el rendimiento de la solicitud al cargar y recuperar almacenamiento desde Amazon S3. Amazon S3 se escala automáticamente a velocidades de solicitudes altas. Por ejemplo, la aplicación puede realizar al menos 3500 solicitudes PUT/COPY/POST/DELETE o 5500 solicitudes GET/HEAD por segundo y prefijo de Amazon S3 dividido. No existe ningún límite en cuanto al número de prefijos dentro de un bucket. Para aumentar el rendimiento de lectura o escritura, ejecute en paralelo las operaciones de lectura. Por ejemplo, si crea 10 prefijos en un bucket de Amazon S3 para ejecutar en paralelo las operaciones de lectura, podría escalar el rendimiento de lectura a 55 000 solicitudes de lectura por segundo. Del mismo modo, puede escalar las operaciones de escritura escribiendo en varios prefijos. La escalación, en el caso de las operaciones de lectura y escritura, se produce gradualmente y no es instantánea, y el rendimiento real variará en función de las características específicas de la carga de trabajo, los patrones de uso y la configuración del sistema. A medida que Amazon S3 escala según la nueva tasa de solicitudes más elevada, es posible que aparezcan algunos errores 503 (ralentización). Estos errores desaparecerán cuando se complete la escalación. Para obtener más información acerca de cómo crear y utilizar prefijos, consulte [Organizar objetos con prefijos](using-prefixes.md).
Por ejemplo, algunas aplicaciones de lago de datos de Amazon S3 analizan millones o miles de millones de objetos para consultas que ejecutan petabytes de datos. Estas aplicaciones de lagos de datos logran velocidades de transferencia de una sola instancia que maximizan el uso de la interfaz de red para su instancia [Amazon EC2](https://docs.aws.amazon.com/ec2/index.html), que puede alcanzar hasta 100 GB/s en una sola instancia. A continuación, estas aplicaciones agregan rendimiento en varias instancias para obtener varios terabits por segundo.
Otras aplicaciones son sensibles a la latencia, como las aplicaciones de mensajería de las redes sociales. Estas aplicaciones pueden lograr latencias para objetos pequeños coherentes (y latencias de “first-byte-out” para objetos más grandes) de unos 100-200 milisegundos aproximadamente.
Otros servicios de AWS también pueden ayudar a acelerar el rendimiento para diferentes arquitecturas de aplicaciones. Por ejemplo, si desea velocidades de transferencia mayores a través de una conexión HTTP única o latencias de milisegundos de un solo dígito, use [Amazon CloudFront](https://docs.aws.amazon.com/cloudfront/index.html) o [Amazon ElastiCache](https://docs.aws.amazon.com/elasticache/index.html) para el almacenamiento en caché con Amazon S3.
De forma adicional, si desea transportar rápidamente los datos a largas distancias entre un cliente y un bucket de S3, use [Configuración de transferencias de archivos rápidas y seguras con Aceleración de transferencias de Amazon S3](transfer-acceleration.md). Aceleración de transferencias usa las ubicaciones de borde distribuidas globalmente en CloudFront para acelerar el transporte de los datos a través de grandes distancias geográficas. Si la carga de trabajo de Amazon S3 utiliza el cifrado del lado del servidor con AWS KMS, consulte [Límites de AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/limits.html) en la Guía para desarrolladores de AWS Key Management Service para obtener información acerca de las tasas de solicitud admitidas para su caso de uso.
En los siguientes temas se describen las directrices y patrones de diseño recomendados a fin de optimizar el rendimiento para las aplicaciones que usan Amazon S3. Consulte [Directrices de rendimiento para Amazon S3](optimizing-performance-guidelines.md) y [Patrones de diseño de rendimiento para Amazon S3](optimizing-performance-design-patterns.md) para obtener la información más reciente sobre la optimización del rendimiento de Amazon S3.
**nota**
Para obtener más información sobre el uso de la clase de almacenamiento Amazon S3 Express One Zone con buckets de directorio, consulte [S3 Express One Zone](directory-bucket-high-performance.md#s3-express-one-zone) y [Trabajar con buckets de de directorio](directory-buckets-overview.md).
**Topics**
+ [Directrices de rendimiento para Amazon S3](optimizing-performance-guidelines.md)
+ [Patrones de diseño de rendimiento para Amazon S3](optimizing-performance-design-patterns.md)
# Directrices de rendimiento para Amazon S3
Al crear aplicaciones que cargan y recuperan objetos de Amazon S3, siga las directrices de nuestras prácticas recomendadas para optimizar el rendimiento. También ofrecemos con más detall [Patrones de diseño de rendimiento para Amazon S3 ](optimizing-performance-design-patterns.md).
Para obtener el mejor rendimiento para su aplicación en Amazon S3, recomendamos las siguientes directrices.
**Topics**
+ [
## Mida el rendimiento
](#optimizing-performance-guidelines-measure)
+ [
## Escalado horizontal de las conexiones de almacenamiento
](#optimizing-performance-guidelines-scale)
+ [
## Uso de recuperaciones de rango de byte
](#optimizing-performance-guidelines-get-range)
+ [
## Reintento de solicitudes de aplicaciones sensibles a la latencia
](#optimizing-performance-guidelines-retry)
+ [
## Combinación de Amazon S3 (almacenamiento) y Amazon EC2 (cómputo) en la misma Región de AWS
](#optimizing-performance-guidelines-combine)
+ [
## Uso de Aceleración de transferencias de Amazon S3 para minimizar la latencia generada por la distancia
](#optimizing-performance-guidelines-acceleration)
+ [
## Uso de la versión más reciente de los AWS SDK
](#optimizing-performance-guidelines-sdk)
## Mida el rendimiento
Al optimizar el rendimiento, fíjese en los requisitos de rendimiento de red, CPU y DRAM. Dependiendo de la combinación de demandas de estos otros recursos, es posible que merezca la pena evaluar otros tipos de instancias [Amazon EC2](https://docs.aws.amazon.com/ec2/index.html). Para obtener más información acerca de los tipos de instancias, consulte [Instance types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) en la *Guía del usuario de Amazon EC2*.
También es útil fijarse en el tiempo de búsqueda de DNS, la latencia y la velocidad de transferencia de datos mediante herramientas de análisis HTTP al medir el rendimiento.
Para comprender los requisitos de rendimiento y optimizar el rendimiento de la aplicación, también puede supervisar las respuestas de error 503 que recibe. La monitorización de ciertas métricas de rendimiento puede generar gastos adicionales. Para obtener más información, consulte [Precios de Amazon S3](https://aws.amazon.com/s3/pricing/).
### Monitorizar el número de respuestas de error de estado 503 (ralentización)
Para monitorizar el número de respuestas de error de estado 503 que recibe, puede utilizar una de las siguientes opciones:
+ Use las métricas de solicitud de Amazon CloudWatch para Amazon S3. Las métricas de solicitud de CloudWatch incluyen una métrica para las respuestas de estado 5xx. Para obtener más información acerca de las métricas de solicitud de CloudWatch, consulte [Monitorización de métricas con Amazon CloudWatch](cloudwatch-monitoring.md).
+ Utilice el recuento de errores 503 (servicio no disponible) disponible en la sección de métricas avanzadas de Lente de almacenamiento de Amazon S3. Para obtener más información, consulte [Uso de métricas de Lente de almacenamiento de S3 para mejorar el rendimiento](storage-lens-detailed-status-code.md).
+ Use el registro de acceso al servidor de Amazon S3. Con el registro de acceso al servidor, puede filtrar y revisar todas las solicitudes que reciben respuestas 503 (error interno). También puede usar Amazon Athena para analizar los registros. Para obtener más información sobre el registro de acceso del servidor, consulte [Registro de solicitudes con registro de acceso al servidor](ServerLogs.md).
Al monitorizar la cantidad de códigos de error de estado HTTP 503, puede obtener información valiosa sobre qué prefijos, claves o buckets reciben la mayor cantidad de solicitudes de limitación.
## Escalado horizontal de las conexiones de almacenamiento
La distribución de las solicitudes entre muchas conexiones es un patrón de diseño habitual para escalar horizontalmente el rendimiento. Al crear aplicaciones de alto rendimiento, piense en Amazon S3 como un sistema distribuido muy grande, no como un punto de enlace de una sola red como un servidor de almacenamiento tradicional. Puede lograr el mejor rendimiento emitiendo varias solicitudes simultáneas a Amazon S3. Distribuya estas solicitudes a través de conexiones separadas para maximizar el ancho de banda accesible desde Amazon S3. Amazon S3 no tiene límites en cuanto al número de conexiones que se realizan en su bucket.
## Uso de recuperaciones de rango de byte
Al usar el encabezado HTTP `Range` en una solicitud [GET Object](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectGET.html), puede recuperar un rango de byte de un objeto, transfiriendo solo la parte especificada. Puede usar conexiones simultáneas a Amazon S3 para recuperar otros rangos de byte desde dentro del mismo objeto. Esto le ayuda a lograr un rendimiento total mayor frente a una sola solicitud de todo el objeto. La recuperación de rangos más pequeños de un objeto grande también permite que su aplicación mejore los tiempos de reintento al interrumpirse las solicitudes. Para obtener más información, consulte [Descarga de objetos](download-objects.md).
Si los objetos aplican PUT mediante una carga multiparte, aplicarles GET en los mismos tamaños de parte (o al menos alinearlos con los límites de parte) es una buena práctica para lograr el mejor rendimiento. Las solicitudes GET pueden ocuparse directamente de partes individuales; por ejemplo, `GET ?partNumber=N.`
## Reintento de solicitudes de aplicaciones sensibles a la latencia
Los reintentos y tiempos de espera agresivos contribuyen a potenciar una latencia coherente. Teniendo en cuenta la gran escala de Amazon S3, si la primera solicitud es lenta, es probable que una solicitud que se ha intentado de nuevo tome otra ruta y se realice correctamente. Los SDK de AWS cuentan con un tiempo de espera configurable y valores de reintento que puede ajustar a las tolerancias de su aplicación específica.
## Combinación de Amazon S3 (almacenamiento) y Amazon EC2 (cómputo) en la misma Región de AWS
Aunque los nombres del bucket de S3 son únicos a nivel global, cada uno de ellos se almacena en una región que se selecciona al crearlos. Para obtener más información sobre las pautas de nomenclatura de los buckets, consulte [Descripción general de los buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucket.html) y [Reglas de nomenclatura de buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html). Para optimizar el rendimiento, recomendamos que acceda al bucket desde las instancias de Amazon EC2 en la misma Región de AWS cuando sea posible. Esto ayuda a reducir los costos de la transferencia de datos y la latencia de red.
Para obtener más información acerca de los costes de las transferencias de datos, consulte [Precios de Amazon S3](https://aws.amazon.com/s3/pricing/).
## Uso de Aceleración de transferencias de Amazon S3 para minimizar la latencia generada por la distancia
[Configuración de transferencias de archivos rápidas y seguras con Aceleración de transferencias de Amazon S3](transfer-acceleration.md) administra transferencias de archivos rápidas, fáciles y seguras a través de grandes distancias geográficas entre el cliente y un bucket de S3. Aceleración de transferencias aprovecha las ubicaciones de borde distribuidas globalmente en [Amazon CloudFront](https://docs.aws.amazon.com/cloudfront/index.html). A medida que los datos llegan a una ubicación de borde, se redirigen a Amazon S3 a través de una ruta de red optimizada. Aceleración de transferencias es ideal para transferir desde gigabytes hasta terabytes de datos con frecuencia entre continentes. También resulta útil para los clientes que cargan en un bucket centralizado desde todo el mundo.
Puede utilizar la [herramienta de comparación de velocidad de Aceleración de transferencias de Amazon S3](https://s3-accelerate-speedtest.s3-accelerate.amazonaws.com/en/accelerate-speed-comparsion.html) para comparar velocidades de subida aceleradas y no aceleradas en las regiones de Amazon S3. La herramienta de comparación de velocidad utiliza cargas multipartes para transferir un archivo desde su navegador hacia diversas regiones de Amazon S3 con y sin Aceleración de transferencias de Amazon S3.
## Uso de la versión más reciente de los AWS SDK
Los SDK de AWS ofrecen compatibilidad integrada con muchas de las directrices recomendadas para optimizar el rendimiento de Amazon S3. Asimismo, proporcionan una API más sencilla para aprovechar Amazon S3 desde dentro de una aplicación y se actualizan con frecuencia para seguir las prácticas recomendadas más recientes. Por ejemplo, los SDK incluyen lógica para reintentar solicitudes automáticamente en errores HTTP 503 e invierten en código para responder a las conexiones lentas y adaptarse a ellas.
Los SDK también ofrecen un [gestor de transferencias](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/examples-s3-transfermanager.html), que automatiza el escalado horizontal de conexiones para lograr miles de solicitudes por segundo, empleando solicitudes de rango de byte si procede. Es importante usar la versión más reciente de los SDK de AWS para obtener las características de optimización de rendimiento más recientes.
También puede optimizar el rendimiento al usar solicitudes de la API de REST de HTTP. Al usar la API de REST, debe seguir las mismas prácticas recomendadas que forman parte de los SDK. Permita los tiempos de espera y los reintentos en las solicitudes lentas y varias conexiones para que la recuperación de datos de objeto en paralelo sea posible. Para obtener información sobre el uso de la API de REST, consulte la [referencia de la API de Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/API/).
# Patrones de diseño de rendimiento para Amazon S3
Al diseñar aplicaciones para cargar y recuperar objetos de Amazon S3, use los patrones de diseño de nuestras prácticas recomendadas para lograr el mejor rendimiento para su aplicación. También ofrecemos [Directrices de rendimiento para Amazon S3 ](optimizing-performance-guidelines.md) para que las tenga en cuenta al planificar la arquitectura de aplicaciones.
Para optimizar el rendimiento, puede usar los siguientes patrones de diseño.
**Topics**
+ [
## Uso del almacenamiento en caché para el contenido de acceso frecuente
](#optimizing-performance-caching)
+ [
## Tiempos de espera y reintentos de aplicaciones sensibles a la latencia
](#optimizing-performance-timeouts-retries)
+ [
## Escalado horizontal y uso en paralelo de solicitudes para lograr un alto rendimiento
](#optimizing-performance-parallelization)
+ [
## Uso de Aceleración de transferencias de Amazon S3 para acelerar las transferencias de datos en lugares geográficos dispares
](#optimizing-performance-acceleration)
+ [
## Optimización para cargas de trabajo con altas tasas de solicitudes
](#optimizing-performance-high-request-rate)
## Uso del almacenamiento en caché para el contenido de acceso frecuente
Muchas aplicaciones que almacenan datos en Amazon S3 ofrecen un “conjunto de trabajo” que los usuarios solicitan continuamente. Si una carga de trabajo envía solicitudes GET repetidas para un conjunto común de objetos, puede utilizar una caché como [Amazon CloudFront](https://docs.aws.amazon.com/cloudfront/index.html), [Amazon ElastiCache](https://docs.aws.amazon.com/elasticache/index.html) o [AWS Elemental MediaStore](https://docs.aws.amazon.com/mediastore/index.html) para optimizar el rendimiento. La adopción correcta de la caché puede dar lugar a una baja latencia y a velocidades de transferencias de datos altas. Las aplicaciones que usan el almacenamiento en caché también envían menos solicitudes directas a Amazon S3, lo que puede contribuir a reducir los costes de las solicitudes.
Amazon CloudFront es una red de entrega de contenido (CDN) rápida que almacena datos en caché de forma transparente desde Amazon S3 en un gran conjunto de puntos de presencia (PoP) distribuidos geográficamente. Cuando se puede tener acceso a los objetos desde multirregiones o a través de Internet, CloudFront permite que los datos se almacenen en caché cerca de los usuarios con acceso a los objetos. Esto puede dar como resultado la entrega de alto rendimiento de contenido popular de Amazon S3. Para obtener más información sobre CloudFront, consulte la [guía para desarrolladores de Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/).
Amazon ElastiCache es una caché en memoria administrada. Con ElastiCache, puede aprovisionar instancias Amazon EC2 que almacenan en caché objetos en memoria. Este almacenamiento en caché se traduce en pedidos de reducción de la magnitud en la latencia GET y aumentos sustanciales en el rendimiento de descarga. Para usar ElastiCache, debe modificar la lógica de la aplicación tanto para rellenar la caché con objetos activos como para comprobar la caché en busca de estos objetos antes de solicitarlos en Amazon S3. Para ver ejemplos de uso de ElastiCache para mejorar el rendimiento de GET de Amazon S3, consulte la publicación del blog [Turbocharge Amazon S3 with Amazon ElastiCache for Redis](https://aws.amazon.com/blogs/storage/turbocharge-amazon-s3-with-amazon-elasticache-for-redis/).
AWS Elemental MediaStore es un sistema de almacenamiento en caché y distribución de contenido creado específicamente para flujos de trabajo de vídeo y entrega de medios desde Amazon S3. MediaStore proporciona API de almacenamiento integrales específicamente para vídeo, y está recomendado para cargas de trabajo de vídeo sensibles al rendimiento. Para obtener información sobre MediaStore, consulte la [Guía del usuario de AWS Elemental MediaStore](https://docs.aws.amazon.com/mediastore/latest/ug/).
## Tiempos de espera y reintentos de aplicaciones sensibles a la latencia
Hay ciertas situaciones en las que una aplicación recibe una respuesta de Amazon S3 que indica que es necesario volver a intentarlo. Amazon S3 asigna nombres de bucket y objeto a los datos de objeto asociados a ellos. Si una aplicación genera velocidades de solicitudes altas (normalmente velocidades sostenidas de más de 5000 solicitudes por segundo a un pequeño número de objetos), podría recibir respuestas de *ralentización* HTTP 503. Si se producen estos errores, cada SDK de AWS implementa la lógica de reintentos automática mediante el retroceso exponencial. Si no está usando un SDK de AWS, debe implementar la lógica de reintentos al recibir el error HTTP 503. Para obtener más información, consulte [Retry behavior](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html) en la *AWS SDKs and Tools Reference Guide*.
Amazon S3 se escala automáticamente en respuesta a las nuevas velocidades de solicitudes sostenidas, optimizando el rendimiento de forma dinámica. Aunque Amazon S3 se está optimizando internamente para una nueva velocidad de solicitudes, recibirá respuestas a las solicitudes HTTP 503 de forma temporal hasta que se complete la optimización. Una vez que Amazon S3 optimice internamente el rendimiento para la nueva velocidad de las solicitudes, todas las solicitudes se atienden de forma general sin reintentos.
En las aplicaciones sensibles a la latencia, Amazon S3 aconseja un seguimiento y realizar un reintento agresivo de operaciones más lentas. Siempre que reintente una solicitud, recomendamos que se use una nueva conexión a Amazon S3 y que se vuelva a realizar una búsqueda de DNS.
Si realiza solicitudes de tamaño grande y variable (por ejemplo: más de 128 MB), aconsejamos que se realice un seguimiento del rendimiento logrado y que se reintente el 5 % más lento de las solicitudes. Al realizar solicitudes más pequeñas (por ejemplo: menos de 512 KB), donde las latencias medias suelen situarse en el rango de las decenas de milisegundos, una buena directriz es reintentar una operación GET o PUT transcurridos 2 segundos. Si son necesarios reintentos adicionales, la práctica recomendada es el retardo. Por ejemplo, recomendamos que se emita un reintento transcurridos 2 segundos y un segundo reintento después de 4 segundos adicionales.
Si su aplicación realiza solicitudes de tamaño fijo a Amazon S3, debe esperar unos tiempos de respuesta más uniformes para cada una de estas solicitudes. En este caso, una estrategia sencilla consiste en identificar el 1 % más lento de las solicitudes y reintentarlas. Incluso un único reintento suele ser eficaz reduciendo la latencia.
Si está utilizando AWS Key Management Service (AWS KMS) para el cifrado del servidor, consulte [Cuotas](https://docs.aws.amazon.com/kms/latest/developerguide/limits.html) en la *Guía para desarrolladores de AWS Key Management Service* con el fin de obtener información acerca de las tasas de solicitudes admitidas para su caso de uso.
## Escalado horizontal y uso en paralelo de solicitudes para lograr un alto rendimiento
Amazon S3 es un sistema distribuido muy grande. Para ayudarle a aprovechar su escala, le animamos a escalar horizontalmente solicitudes paralelas a los puntos de enlace de servicio de Amazon S3. Además de distribuir las solicitudes en Amazon S3, este tipo de enfoque de escalado ayuda a distribuir la carga mediante varias rutas a través de la red.
Para las transferencias de alto rendimiento, Amazon S3 aconseja que se usen aplicaciones que a su vez usen varias conexiones a los datos de GET o PUT en paralelo. Por ejemplo, esto cuenta con el respaldo del [gestor de transferencias de Amazon S3](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/transfer-manager.html) en el SDK de AWS para Java. Además, la mayoría de los otros SDK de AWS proporcionan construcciones similares. Para algunas aplicaciones, puede lograr conexiones paralelas lanzando varias solicitudes simultáneamente en diferentes subprocesos de aplicación, o bien en diferentes instancias de aplicación. El mejor enfoque que adoptar depende de su aplicación y la estructura de los objetos a los que tiene acceso.
Puede utilizar los SDK de AWS para emitir las solicitudes GET y PUT directamente en lugar de emplear la administración de las transferencias en el SDK de AWS. Este enfoque le permite ajustar su carga de trabajo de forma más directa, mientras sigue beneficiándose de la compatibilidad del SDK con los reintentos y su control de cualquier respuesta HTTP 503 que pueda surgir. Como regla general, al descargar objetos grandes desde Amazon S3, recomendamos que se realicen solicitudes simultáneas para maximizar el rendimiento de la red y optimizar el rendimiento de descarga. Para ello, puede solicitar rangos de bytes específicos del objeto o descargar partes individuales de un objeto multiparte de forma simultánea. Este enfoque de descarga paralela ayuda a utilizar al máximo la capacidad de la tarjeta de interfaz de red (NIC). Para los objetos que se cargaron mediante la carga multiparte, recomendamos descargarlos con los mismos tamaños de pieza o alinear las solicitudes con los límites de las partes originales para obtener el mejor rendimiento. Este método de descarga simultánea proporciona un mayor rendimiento agregado en comparación con las solicitudes de un solo objeto completo.
Medir el rendimiento es importante cuando ajusta el número de solicitudes que se van a emitir simultáneamente. Recomendamos comenzar con una sola solicitud cada vez. Mida el ancho de banda de red logrado y el uso de otros recursos utilizados por su aplicación durante el procesamiento de los datos. A partir de ese momento, podrá identificar el recurso de cuello de botella (es decir, el recurso más usado) y, por tanto, el número de solicitudes con probabilidades de resultar de utilidad. Por ejemplo, si el procesamiento de una solicitud cada vez se traduce a un uso del 25 % de la CPU, sugiere que se pueden atender hasta cuatro solicitudes simultáneas. La medición es fundamental y merece la pena confirmar el uso de recursos a medida que aumenta la velocidad de solicitudes.
Si su aplicación emite solicitudes directamente a Amazon S3 mediante la API de REST, recomendamos usar un grupo de conexiones HTTP y volver a utilizar cada conexión para una serie de solicitudes. Al evitarse la configuración de la conexión por solicitud, desaparece la necesidad de llevar a cabo protocolos de enlace de Capa de conexión segura (SSL) y TCP de inicio lento. Para obtener información sobre el uso de la API de REST, consulte la [referencia de la API de Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/API/).
Por último, merece la pena prestar atención a DNS y volver a comprobar si las solicitudes se distribuyen mediante un amplio grupo de direcciones IP de Amazon S3. Consultas de DNS para el ciclo de Amazon S3 a través de una gran lista de puntos de enlace de IP. Sin embargo, el almacenamiento en caché de los solucionadores o el código de aplicación que vuelve a usar una sola dirección IP no se beneficia de la diversidad de direcciones y el balanceo de carga que se produce a continuación. Las herramientas de utilidades de red, como, por ejemplo, la herramienta de línea de comandos `netstat`, pueden mostrar las direcciones IP que se están utilizando para la comunicación con Amazon S3. Además, proporcionamos directrices acerca de las configuraciones de DNS que se deben emplear. Para obtener más información sobre estas directrices, consulte [Making requests](https://docs.aws.amazon.com/AmazonS3/latest/API/MakingRequests.html) en la *Amazon S3 API Reference*.
## Uso de Aceleración de transferencias de Amazon S3 para acelerar las transferencias de datos en lugares geográficos dispares
[Configuración de transferencias de archivos rápidas y seguras con Aceleración de transferencias de Amazon S3](transfer-acceleration.md) resulta eficaz a la hora de minimizar o eliminar la latencia generada por la distancia geográfica existente entre clientes repartidos por todo el mundo y una aplicación regional mediante Amazon S3. Aceleración de transferencias usa las ubicaciones de borde distribuidas globalmente en CloudFront para el transporte de los datos. La red de borde de AWS tiene puntos de presencia en más de 50 ubicaciones. Actualmente, se usa para distribuir el contenido a través de CloudFront y proporcionar respuestas rápidas a las consultas DNS realizadas a [Amazon Route 53](https://docs.aws.amazon.com/route53/index.html).
La red de borde también ayuda a acelerar las transferencias de datos tanto dentro como fuera de Amazon S3. Resulta ideal para las aplicaciones que transfieren datos en o entre continentes, tienen una conexión a Internet rápida, usan objetos grandes o tienen mucho contenido que cargar. A medida que los datos llegan a una ubicación de borde, se redirigen a Amazon S3 a través de una ruta de red optimizada. En general, cuanto más lejos esté de una región de Amazon S3, mayor será la mejora de la velocidad que puede esperar del uso de Aceleración de transferencias.
Puede configurar Aceleración de transferencias en buckets nuevos o ya existentes. Puede usar un punto de enlace independiente de Aceleración de transferencias de Amazon S3 para utilizar las ubicaciones de borde de AWS. La mejor forma de probar si Aceleración de transferencias contribuye al rendimiento de las solicitudes de los clientes es usar la [herramienta de comparación de velocidad de Aceleración de transferencias de Amazon S3](https://s3-accelerate-speedtest.s3-accelerate.amazonaws.com/en/accelerate-speed-comparsion.html). Las condiciones y configuraciones de red varían de cuando en cuando y de ubicación a ubicación. Así pues, solo se le cobrarán las transferencias en las que Aceleración de transferencias de Amazon S3 pueda mejorar de forma potencial su rendimiento de carga. Para obtener información acerca del uso de Aceleración de transferencias con diferentes SDK de AWS, consulte [Habilitación y uso de Aceleración de transferencias de S3](transfer-acceleration-examples.md).
## Optimización para cargas de trabajo con altas tasas de solicitudes
Las aplicaciones que generan altas tasas de solicitudes a Amazon S3 requieren patrones de diseño específicos para lograr un rendimiento óptimo. Cuando la aplicación genera de forma coherente más de 3500 solicitudes PUT/COPY/POST/DELETE o 5500 solicitudes GET/HEAD por segundo y prefijo, debe implementar estrategias para distribuir las solicitudes y gestionar el comportamiento de escalado.
Amazon S3 escala automáticamente para admitir tasas de solicitudes más elevadas, pero esta escala se produce de forma gradual. Durante el proceso de escalado, es posible que reciba respuestas HTTP 503 (Slow Down). Estas respuestas son temporales e indican que Amazon S3 está optimizando sus sistemas internos para el nuevo patrón de solicitudes. Una vez que se complete el escalado, las solicitudes se atenderán sin limitaciones.
Para optimizar el rendimiento de las cargas de trabajo de tasas de solicitudes altas, tenga en cuenta las siguientes estrategias:
+ **Distribuya las solicitudes entre varios prefijos**: utilice un patrón de prefijos asignado al azar o secuencial para distribuir las solicitudes entre varias particiones. Por ejemplo, en lugar de usar nombres de objetos secuenciales como `log-2024-01-01.txt`, use prefijos asignados al azar como `a1b2/log-2024-01-01.txt`. Esto ayuda a Amazon S3 a distribuir la carga de forma más eficaz.
+ **Implemente un retroceso exponencial para los errores 503**: cuando reciba respuestas HTTP 503, implemente una lógica de reintento con un retroceso exponencial. Comience con un breve retraso y aumente gradualmente el tiempo de espera entre los reintentos. Los AWS SDK incluyen una lógica de reintento integrada que lo gestiona automáticamente.
+ **Supervise los patrones de solicitudes**: utilice las métricas de Amazon CloudWatch para supervisar las tasas de solicitudes y las tasas de error. Preste especial atención a las métricas de errores 5xx, que pueden indicar si la aplicación se acerca o supera los límites de escalado actuales.
+ **Aumente gradualmente las tasas de solicitudes**: al lanzar nuevas aplicaciones o aumentar significativamente las tasas de solicitudes, aumente gradualmente el tráfico a lo largo del tiempo en lugar de saltar inmediatamente a las tasas máximas. Esto permite que Amazon S3 escale de forma proactiva y reduce la probabilidad de que se produzcan limitaciones.
+ **Utilice varias conexiones**: distribuya las solicitudes entre varias conexiones HTTP para maximizar el rendimiento y reducir el impacto de cualquier problema de conexión individual.
Para las aplicaciones que requieren un alto rendimiento coherente, tenga en cuenta la posibilidad de utilizar Amazon S3 Express One Zone, que está diseñado para aplicaciones que requieren latencias de milisegundos de un solo dígito y que puede admitir cientos de miles de solicitudes por segundo. Para obtener más información, consulte [S3 Express One Zone](directory-bucket-high-performance.md#s3-express-one-zone).