# Capacidad de rendimiento de DynamoDB
<a name="capacity-mode"></a>

En esta sección se ofrece una descripción general de los dos modos de rendimiento que hay disponibles para la tabla de DynamoDB y se explica cómo seleccionar el modo de capacidad adecuado para la aplicación. El modo de rendimiento de una tabla determina cómo se administra la capacidad de ella. El modo de rendimiento también determina cómo se le cobran las operaciones de lectura y escritura en las tablas. En Amazon DynamoDB, puede elegir entre el modo **bajo demanda** y el modo **aprovisionado** para sus tablas con el fin de adaptarse a los diferentes requisitos de carga de trabajo.

**Topics**
+ [Modo bajo demanda](#capacity-mode-on-demand)
+ [Modo aprovisionado](#capacity-mode-provisioned)
+ [Modo de capacidad bajo demanda de DynamoDB](on-demand-capacity-mode.md)
+ [Modo de capacidad aprovisionada de DynamoDB](provisioned-capacity-mode.md)
+ [Descripción del rendimiento en caliente de DynamoDB](warm-throughput.md)
+ [Capacidad de ampliación y de adaptación de DynamoDB](burst-adaptive-capacity.md)
+ [Aspectos a tener en cuenta al cambiar los modos de capacidad en DynamoDB](bp-switching-capacity-modes.md)

## Modo bajo demanda
<a name="capacity-mode-on-demand"></a>

El modo bajo demanda de Amazon DynamoDB es una opción de rendimiento sin servidor que simplifica la administración de bases de datos y se escala automáticamente para respaldar las aplicaciones más exigentes de los clientes. DynamoDB bajo demanda le permite crear una tabla sin preocuparse de la planificación de capacidad, supervisar el uso ni configurar políticas de escalado. DynamoDB bajo demanda ofrece precios de pago por solicitud para las solicitudes de lectura y escritura. De este modo, únicamente tendrá que pagar por aquello que utilice. Para tablas en modo en diferido, no necesita especificar el rendimiento de lectura y escritura que espera de su aplicación. 

El modo bajo demanda es la opción de rendimiento predeterminada y recomendada para la mayoría de las cargas de trabajo de DynamoDB. DynamoDB se encarga de todos los aspectos de la administración del rendimiento y el escalado para admitir cargas de trabajo que pueden empezar siendo pequeñas y escalar hasta millones de solicitudes por segundo. Puede leer y escribir en las tablas de DynamoDB según sea necesario sin administrar la capacidad de rendimiento de la tabla. Para obtener más información, consulte [Modo de capacidad bajo demanda de DynamoDB](on-demand-capacity-mode.md).

## Modo aprovisionado
<a name="capacity-mode-provisioned"></a>

En el modo aprovisionado, debe especificar el número de lecturas y escrituras por segundo que necesita para la aplicación. Se le cobrará en función de la capacidad de lectura y escritura por hora que haya aprovisionado, no de la cantidad de esa capacidad aprovisionada que haya consumido realmente. Esto le ayuda a controlar el uso de DynamoDB para que se mantenga igual o menor que la velocidad de solicitudes definida y, de esta forma, poder predecir los costos.

Puede elegir utilizar capacidad aprovisionada si tiene cargas de trabajo estables con un crecimiento predecible y si puede prever con fiabilidad las necesidades de capacidad de la aplicación. Para obtener más información, consulte [Modo de capacidad aprovisionada de DynamoDB](provisioned-capacity-mode.md).

# Modo de capacidad bajo demanda de DynamoDB
<a name="on-demand-capacity-mode"></a>

Amazon DynamoDB bajo demanda ofrece una verdadera experiencia de base de datos sin servidor que se escala de forma automática para adaptarse a las cargas de trabajo más exigentes sin necesidad de planificación de capacidad. Bajo demanda simplifica el proceso de configuración, elimina la administración y supervisión de la capacidad y proporciona un escalado rápido y automático. Con los precios de pago por solicitud, no tiene que preocuparse por la capacidad inactiva porque solo paga por el rendimiento que realmente utiliza. Se le factura por solicitud de lectura o escritura, por lo que los costos reflejan directamente el uso real. 

Al elegir el modo en diferido, DynamoDB se adapta de forma instantánea a sus cargas de trabajo a medida que aumentan o disminuyen a cualquier nivel de tráfico alcanzado previamente. Si el nivel de tráfico de una carga de trabajo alcanza un nuevo pico, DynamoDB se escala automáticamente para adaptarse al aumento de los requisitos de rendimiento. El modo bajo demanda es la opción de rendimiento predeterminada y recomendada porque simplifica la creación de aplicaciones modernas y sin servidor que pueden empezar siendo pequeñas y escalar hasta millones de solicitudes por segundo. Una vez escalada horizontalmente la tabla bajo demanda, podrá volver a alcanzar al instante el mismo rendimiento en el futuro sin limitaciones. Si no dirige tráfico alguno a la tabla, con el sistema bajo demanda no se le cobrará ningún rendimiento. Para obtener más información sobre las propiedades de escalado del modo bajo demanda, consulte [Rendimiento inicial y propiedades de escalado](#on-demand-capacity-mode-initial). 

Las tablas que utilizan el modo bajo demanda ofrecen la misma latencia de un milisegundo, acuerdo de nivel de servicio (SLA) y seguridad que el modo aprovisionado de DynamoDB.

**nota**  
De forma predeterminada, DynamoDB lo protege del uso incontrolado e imprevisto. Para escalar más allá de los límites de rendimiento de lectura y escritura en el nivel de tabla de 40 000 para todas las tablas de la cuenta, puede solicitar un aumento de esta cuota. Las solicitudes de rendimiento que superan la cuota de rendimiento predeterminada de la tabla están limitadas. Para obtener más información, consulte [Cuotas de rendimiento predeterminadas](ServiceQuotas.md#default-limits-throughput).

Si lo desea, también puede configurar el rendimiento máximo de lectura o escritura (o ambos) por segundo para tablas bajo demanda individuales e índices secundarios globales. Al configurar el rendimiento, puede limitar el uso y los costos de las tablas, protegerse contra un aumento no intencionado de los recursos consumidos y evitar el uso excesivo para que la administración de los costos sea predecible. Las solicitudes de rendimiento que superan el rendimiento máximo de la tabla tienen aplicada una limitación. Puede modificar el rendimiento máximo específico de la tabla en cualquier momento en función de los requisitos de su aplicación. Para obtener más información, consulte [Rendimiento máximo de DynamoDB para las tablas bajo demanda](on-demand-capacity-mode-max-throughput.md).

Para empezar, cree o actualice una tabla para utilizar el modo bajo demanda. Para obtener más información, consulte [Operaciones básicas en tablas de DynamoDB](WorkingWithTables.Basics.md).

Puede cambiar las tablas del modo de capacidad aprovisionada al modo bajo demanda hasta cuatro veces en un periodo continuo de 24 horas. Las tablas pueden cambiar del modo bajo demanda al modo de capacidad aprovisionada en cualquier momento. 

Para obtener más información sobre el cambio entre los modos de capacidad de lectura y escritura, consulte [Aspectos a tener en cuenta al cambiar los modos de capacidad en DynamoDB](bp-switching-capacity-modes.md). Para ver las cuotas de las tablas bajo demanda, consulte [Rendimiento de lectura o escritura](ServiceQuotas.md#default-limits-throughput-capacity-modes).

**Topics**
+ [Unidades de solicitud de lectura y de escritura](#read-write-request-units)
+ [Rendimiento inicial y propiedades de escalado](#on-demand-capacity-mode-initial)
+ [Rendimiento máximo de DynamoDB para las tablas bajo demanda](on-demand-capacity-mode-max-throughput.md)

## Unidades de solicitud de lectura y de escritura
<a name="read-write-request-units"></a>

DynamoDB le cobra por las lecturas y escrituras que realiza su aplicación en sus tablas por *unidades de solicitud de lectura* y *unidades de solicitud de escritura*.

Una *unidad de solicitud de lectura* representa una lectura altamente coherente por segundo, o dos lecturas coherentes posteriores por segundo, para elementos con un tamaño máximo de 4 KB. Para obtener más información sobre los modelos de consistencia de lectura de DynamoDB, consulte [Coherencia de lectura de DynamoDB](HowItWorks.ReadConsistency.md).

Una *unidad de solicitud de escritura* representa una operación de escritura por segundo para un elemento con un tamaño máximo de 1 KB.

Para obtener más información sobre cómo se consumen las unidades de lectura y escritura, consulte[Operaciones de lectura y escritura de DynamoDB](read-write-operations.md).

## Rendimiento inicial y propiedades de escalado
<a name="on-demand-capacity-mode-initial"></a>

Las tablas de DynamoDB que utilizan el modo de capacidad bajo demanda se adaptan automáticamente al volumen de tráfico de la aplicación. Las nuevas tablas bajo demanda podrán soportar hasta 4000 escrituras por segundo y 12 000 lecturas por segundo. El modo de capacidad bajo demanda acomoda al instante hasta el doble del tráfico máximo alcanzado previamente en una tabla. Por ejemplo, supongamos que el patrón de tráfico de su aplicación oscila entre 25 000 y 50 000 lecturas altamente coherentes por segundo. El pico de tráfico anterior es de 50 000 lecturas por segundo. El modo de capacidad bajo demanda se adapta instantáneamente a un tráfico sostenido de hasta 100 000 lecturas por segundo. Si su aplicación soporta un tráfico de 100 000 lecturas por segundo, ese pico se convierte en su nuevo pico anterior. Este pico anterior permite que el tráfico posterior alcance hasta 200 000 lecturas por segundo.

Si su carga de trabajo genera más del doble que su pico anterior en una tabla, DynamoDB asigna automáticamente más capacidad a medida que aumenta su volumen de tráfico. Esta asignación de capacidad ayuda a garantizar que no se aplique una limitación en su carga de trabajo. Sin embargo, esta limitación controlada podría producirse si supera el doble del pico anterior en el plazo de 30 minutos. Por ejemplo, supongamos que el patrón de tráfico de su aplicación oscila entre 25 000 y 50 000 lecturas altamente coherentes por segundo. El pico de tráfico alcanzado anteriormente es de 50 000 lecturas por segundo. Le recomendamos que precaliente la tabla o espacie el crecimiento de su tráfico durante al menos 30 minutos antes de producir más de 100 000 lecturas por segundo. Para obtener más información acerca del precalentamiento, consulte [Descripción del rendimiento en caliente de DynamoDB](warm-throughput.md).

DynamoDB no establece la restricción de limitación de 30 minutos si el pico de tráfico de la carga de trabajo se mantiene dentro del doble del pico anterior. Si el pico de tráfico supera el doble de ese pico, asegúrese de que este aumento se produce 30 minutos después de la última vez que alcanzó el pico.

# Rendimiento máximo de DynamoDB para las tablas bajo demanda
<a name="on-demand-capacity-mode-max-throughput"></a>

En el caso de las tablas bajo demanda, si lo desea, puede especificar el rendimiento máximo de lectura o escritura (o ambos) por segundo en tablas individuales y en los índices secundarios globales (GSI) asociados. Especificar un rendimiento máximo bajo demanda ayuda a limitar el uso y los costos de las tablas. De forma predeterminada, no se aplica la configuración de rendimiento máximo y la tasa de rendimiento bajo demanda está limitada por la [cuota de servicio de AWS](ServiceQuotas.md#default-limits-throughput) de rendimiento de lectura y escritura en el nivel de tabla de 40 000 para todas las tablas de la cuenta. Si es necesario, también puede solicitar un aumento de la cuota de servicio.

Al configurar el rendimiento máximo para una tabla bajo demanda, se aplicará una limitación a las solicitudes de rendimiento que superen la cantidad máxima especificada. Puede modificar la configuración del rendimiento de las tablas en cualquier momento en función de los requisitos de su aplicación.

Estos son algunos casos de uso comunes que pueden beneficiarse del uso de un rendimiento máximo para las tablas bajo demanda:
+ **Optimización de los costos de rendimiento**: el uso del rendimiento máximo para las tablas bajo demanda permite disponer de un nivel adicional de previsibilidad de los costos y facilidad de administración. Además, ofrece una mayor flexibilidad para usar el modo bajo demanda para soportar cargas de trabajo con diferentes patrones de tráfico y presupuestos.
+ **Protección contra el uso excesivo**: al establecer el rendimiento máximo, puede evitar un aumento accidental del consumo de lecturas o escrituras, que podría deberse a un código no optimizado o a procesos fraudulentos en una tabla bajo demanda. Esta configuración de tabla puede evitar que las organizaciones consuman recursos excesivos en un período de tiempo determinado.
+ **Protección de los servicios posteriores**: la aplicación de un cliente puede incluir tecnologías sin servidor y con servidor. La parte sin servidor de la arquitectura sin puede escalarse rápidamente para adaptarse a la demanda. Sin embargo, los componentes posteriores con capacidades fijas podrían saturarse. La implementación de una configuración de rendimiento máximo para las tablas bajo demanda puede evitar que un gran volumen de eventos se propague a varios componentes posteriores y se produzcan efectos secundarios inesperados.

Puede configurar el rendimiento máximo del modo bajo demanda en tablas nuevas y existentes de una sola región, así como en tablas globales y GSI. También puede configurar el rendimiento máximo durante la restauración de tablas y la importación de datos desde los flujos de trabajo de Amazon S3.

Puede especificar la configuración de rendimiento máximo de una tabla bajo demanda mediante la [consola de DynamoDB](https://console.aws.amazon.com/dynamodb/), la [AWS CLI](AccessingDynamoDB.md#Tools.CLI), [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-dynamodb-table.html) o la [API de DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/Welcome.html).

**nota**  
El rendimiento máximo de una tabla bajo demanda se aplica en la medida de lo posible y debe considerarse como un objetivo en lugar de un límite de solicitudes garantizado. Es posible que su carga de trabajo supere temporalmente el rendimiento máximo especificado debido a la [*capacidad de ampliación*](burst-adaptive-capacity.md#burst-capacity). En algunos casos, DynamoDB utiliza la *capacidad de ampliación* para atender las lecturas o escrituras que superan la configuración de rendimiento máxima de la tabla. Con la capacidad de ráfaga, pueden realizarse correctamente solicitudes de lectura o escritura inesperadas que, de otro modo, habrían sido objeto de una limitación controlada.

**Topics**
+ [Consideraciones al utilizar el rendimiento máximo en el modo bajo demanda](#consideration-use-max-throughput-ondemand)
+ [Limitación de solicitudes y métricas de CloudWatch](#max-throughput-ondemand-request-throttle)

## Consideraciones al utilizar el rendimiento máximo en el modo bajo demanda
<a name="consideration-use-max-throughput-ondemand"></a>

Cuando se utiliza el rendimiento máximo para las tablas en el modo bajo demanda, hay que tener en cuenta lo siguiente:
+ Puede establecer de forma independiente el rendimiento máximo de lectura y escritura para cualquier tabla bajo demanda o para un índice secundario global individual dentro de esa tabla para ajustar su enfoque a los requisitos específicos.
+ Puede utilizar Amazon CloudWatch para monitorear y conocer las métricas de uso de tabla de DynamoDB y para determinar la configuración de rendimiento máximo adecuada para el modo bajo demanda. Para obtener más información, consulte [Dimensiones y métricas de DynamoDB](metrics-dimensions.md).
+ Al especificar la configuración de rendimiento máximo de lectura o escritura (o ambas) en una sola réplica de tabla global, esa misma configuración se aplica automáticamente a todas las tablas de réplicas. Es importante que las tablas de réplicas y los índices secundarios de la tabla global tengan una configuración de rendimiento de escritura idéntica para garantizar la replicación adecuada de los datos. Para obtener más información, consulte [Prácticas recomendadas para tablas globales](globaltables-bestpractices.md).
+ El rendimiento máximo de lectura o escritura más bajo que puede especificar es una unidad de solicitud por segundo.
+ El rendimiento máximo que especifique debe ser inferior a la cuota de rendimiento predeterminada que está disponible para cualquier tabla bajo demanda o índice secundario global individual dentro de esa tabla.

## Limitación de solicitudes y métricas de CloudWatch
<a name="max-throughput-ondemand-request-throttle"></a>

Si la aplicación supera el rendimiento máximo de lectura o escritura que ha establecido en la tabla bajo demanda, DynamoDB comienza a aplicar límites a esas solicitudes. Cuando DynamoDB aplica una limitación controlada a una lectura o escritura, devuelve una `ThrottlingException` a la persona que llama. A continuación, puede tomar las medidas adecuadas, si es necesario. Por ejemplo, puede aumentar o deshabilitar la configuración de rendimiento máximo de la tabla o esperar un poco antes de volver a intentar la solicitud.

Para simplificar el monitoreo del rendimiento máximo configurado para una tabla o un índice secundario global, CloudWatch proporciona las siguientes métricas: [OnDemandMaxReadRequestUnits](metrics-dimensions.md#OnDemandMaxReadRequestUnits) y [OnDemandMaxWriteRequestUnits](metrics-dimensions.md#OnDemandMaxWriteRequestUnits).

# Modo de capacidad aprovisionada de DynamoDB
<a name="provisioned-capacity-mode"></a>

Al crear una nueva tabla aprovisionada en DynamoDB, debe especificar su *capacidad de rendimiento aprovisionada*. Esta es la cantidad de rendimiento de lectura y escritura que puede soportar la tabla. Se le cobrará en función de la capacidad de lectura y escritura por hora que haya aprovisionado, no de la cantidad de esa capacidad aprovisionada que haya consumido realmente.

A medida que cambian los requisitos de datos y acceso de la aplicación, puede que tenga que ajustar la configuración de rendimiento de la tabla. Puede utilizar el escalado automático para ajustar automáticamente la capacidad aprovisionada de la tabla en respuesta a los patrones de tráfico. El escalado automático de DynamoDB utiliza una [política de escalado](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html) en [Escalado automático de aplicaciones](https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html). Para configurar el escalado automático en DynamoDB, debe establecer los niveles mínimo y máximo de capacidad de lectura y escritura, además del porcentaje de utilización objetivo. Auto Scaling de aplicaciones crea y administra las alarmas de CloudWatch que desencadenan eventos de escalado cuando la métrica se desvía del destino. El escalado automático supervisa la actividad de la tabla y aumenta o reduce la configuración de capacidad en función de los umbrales preconfigurados. El escalado automático se activa cuando la capacidad consumida supera el objetivo de utilización configurado durante dos minutos consecutivos. Es posible que las alarmas de CloudWatch tarden unos minutos antes de desencadenar el escalado automático. Para obtener más información, consulte [Administración automática de la capacidad de rendimiento con la función Auto Scaling de DynamoDB](AutoScaling.md).

Si utiliza la función Auto Scaling de DynamoDB, la configuración de rendimiento se modificarán automáticamente en respuesta a las cargas de trabajo reales. También puede usar la operación [UpdateTable](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateTable.html) para ajustar manualmente la capacidad de rendimiento de la tabla. Por ejemplo, es posible que prefiera hacerlo de ese modo para cargar datos masivamente de un almacén de datos en la nueva tabla de DynamoDB. Podría crear la tabla con un ajuste de desempeño de escritura mayor y, a continuación, reducir este ajuste una vez finalizada la carga masiva de datos.

**nota**  
De forma predeterminada, DynamoDB lo protege del uso incontrolado e imprevisto. Para escalar más allá de los límites de rendimiento de lectura y escritura en el nivel de tabla de 40 000 para todas las tablas de la cuenta, puede solicitar un aumento de esta cuota. Las solicitudes de rendimiento que superan la cuota de rendimiento predeterminada de la tabla están limitadas. Para obtener más información, consulte [Cuotas de rendimiento predeterminadas](ServiceQuotas.md#default-limits-throughput).

Puede cambiar las tablas del modo de capacidad aprovisionada al modo bajo demanda hasta cuatro veces en un periodo continuo de 24 horas. Las tablas pueden cambiar del modo bajo demanda al modo de capacidad aprovisionada en cualquier momento. 

Para obtener más información sobre el cambio entre los modos de capacidad de lectura y escritura, consulte [Aspectos a tener en cuenta al cambiar los modos de capacidad en DynamoDB](bp-switching-capacity-modes.md).

**Topics**
+ [Unidades de capacidad de lectura y de escritura](#read-write-capacity-units)
+ [Elección de los ajustes de rendimiento iniciales](#choosing-initial-throughput)
+ [Escalado automático de DynamoDB](#ddb-autoscaling)
+ [Administración automática de la capacidad de rendimiento con la función Auto Scaling de DynamoDB](AutoScaling.md)
+ [Capacidad reservada de DynamoDB](reserved-capacity.md)

## Unidades de capacidad de lectura y de escritura
<a name="read-write-capacity-units"></a>

Para las tablas en el modo aprovisionado, especifique los requisitos de rendimiento en *unidades de capacidad*. Estas unidades representan la cantidad de datos que la aplicación necesita para leer o escribir por segundo. Puede cambiar esta configuración más adelante, si es necesario, o habilitar la función Auto Scaling de DynamoDB para que se modifiquen automáticamente.

Para un elemento de hasta 4 KB, una *unidad de capacidad de lectura* (RCU) representa una operación de lectura altamente coherente por segundo o dos operaciones de lectura coherente posterior por segundo. Para obtener más información sobre los modelos de consistencia de lectura de DynamoDB, consulte [Coherencia de lectura de DynamoDB](HowItWorks.ReadConsistency.md).

Una *unidad de capacidad de escritura* (WCU) equivale a una escritura por segundo para un elemento con un tamaño máximo de 1 KB. Para obtener más información sobre las diferentes operaciones de lectura y escritura, consulte [Operaciones de lectura y escritura de DynamoDB](read-write-operations.md).

## Elección de los ajustes de rendimiento iniciales
<a name="choosing-initial-throughput"></a>

Cada aplicación tiene requisitos diferentes de lectura y escritura en una base de datos. Al determinar la configuración de rendimiento inicial de una tabla de DynamoDB, debe tener en cuenta lo siguiente:
+ **Velocidades esperadas de solicitudes de lectura y escritura**: debe calcular la cantidad de lecturas y escrituras que debe realizar por segundo.
+ **Tamaños de los elementos**: algunos elementos son lo bastante pequeños para leerlos o escribirlos con una sola unidad de capacidad. Los elementos mayores requieren varias unidades de capacidad. Si calcula el tamaño medio de los elementos que contendrá la tabla, podrá especificar una configuración precisa del rendimiento aprovisionado de la tabla.
+ **Requisitos de consistencia de lectura**: las unidades de capacidad de lectura se basan en operaciones de lectura altamente coherente, que consumen el doble de recursos de la base de datos que las lecturas coherentes posteriores. Es importante determinar si la aplicación necesita las lecturas de consistencia alta o si es posible adoptar un enfoque más flexible que realice en su lugar lecturas consistentes finales. Las operaciones de lectura en DynamoDB son coherentes posteriores de manera predeterminada. Si es preciso, puede solicitar lecturas altamente coherentes para estas operaciones.

Por ejemplo, supongamos que desea leer 80 elementos por segundo de una tabla. Los elementos tienen un tamaño de 3 KB y desea realizar lecturas altamente coherentes. En este caso, cada lectura requiere una unidad de capacidad de lectura aprovisionada. Para determinar esta cifra, hay que dividir el tamaño de elemento de la operación por 4 KB. A continuación, se redondea al número entero más próximo, como se muestra en el siguiente ejemplo:
+ 3 KB / 4 KB = 0,75 o **1** unidad de capacidad de lectura

Por lo tanto, para leer 80 elementos por segundo de una tabla, establezca el rendimiento de lectura aprovisionado de la tabla en 80 unidades de capacidad de lectura, como se muestra en el siguiente ejemplo:
+ 1 unidad de capacidad de lectura por elemento × 80 lecturas por segundo = **80** unidades de capacidad de lectura

Ahora, suponga que desea escribir 100 elementos por segundo en la tabla y que los elementos tienen un tamaño de 512 bytes. En este caso, cada escritura requiere una unidad de capacidad de escritura aprovisionada. Para determinar esta cifra, hay que dividir el tamaño de elemento de la operación por 1 KB. A continuación, se redondea al número entero más próximo, como se muestra en el siguiente ejemplo:
+ 512 bytes /1 KB = 0,5 o **1** unidad de capacidad de escritura

Para escribir 100 elementos por segundo en la tabla, establezca el rendimiento de escritura aprovisionado para la tabla en 100 unidades de capacidad de escritura:
+ 1 unidad de capacidad de escritura por elemento × 100 escrituras por segundo = **100** unidades de capacidad de escritura

## Escalado automático de DynamoDB
<a name="ddb-autoscaling"></a>

El escalado automático de DynamoDB administra activamente la capacidad de rendimiento aprovisionada de las tablas y los índices secundarios globales. Con Auto Scaling, se define un rango (los límites superior e inferior) de unidades de capacidad de lectura y escritura. También se definir un porcentaje de objetivo de utilización comprendido en ese rango. La función Auto Scaling de DynamoDB intenta mantener el objetivo de utilización aunque la carga de trabajo de la aplicación aumente o disminuya.

Con el escalado automático de DynamoDB, una tabla o un índice secundario global pueden aumentar su capacidad de lectura y escritura aprovisionada para hacer frente a los aumentos repentinos de tráfico, sin que se aplique la limitación controlada a las solicitudes. Cuando la carga de trabajo disminuye, el escalado automático de DynamoDB puede reducir el rendimiento para evitar que tenga que pagar por una capacidad aprovisionada que no se utiliza.

**nota**  
Si usa la Consola de administración de AWS para crear una tabla o un índice secundario global, la función Auto Scaling de DynamoDB se habilita de forma predeterminada.  
Puede administrar la configuración de escalado automático en cualquier momento mediante la consola, la AWS CLI o uno de los AWS. Para obtener más información, consulte [Administración automática de la capacidad de rendimiento con la función Auto Scaling de DynamoDB](AutoScaling.md).

### Tasa de utilización
<a name="ddb-autoscaling-utilization-rate"></a>

La tasa de utilización puede ayudarle a determinar si su capacidad de aprovisionamiento es excesiva, en cuyo caso debería reducir la capacidad de las tablas para ahorrar costos. Por el contrario, también puede ayudarle a determinar si su capacidad de aprovisionamiento es insuficiente. En este caso, debería aumentar la capacidad de las tablas para evitar que se apliquen limitaciones en las solicitudes en casos inesperados de tráfico intenso. Para obtener más información, consulte [Amazon DynamoDB auto scaling: Performance and cost optimization at any scale](https://aws.amazon.com/blogs/database/amazon-dynamodb-auto-scaling-performance-and-cost-optimization-at-any-scale/).

Si utiliza el escalado automático de DynamoDB, también tendrá que establecer un porcentaje de utilización objetivo. El escalado automático utilizará este porcentaje como objetivo para ajustar la capacidad arriba o abajo. Recomendamos establecer el objetivo de utilización en un 70 %. Para obtener más información, consulte [Administración automática de la capacidad de rendimiento con la función Auto Scaling de DynamoDB](AutoScaling.md).

# Administración automática de la capacidad de rendimiento con la función Auto Scaling de DynamoDB
<a name="AutoScaling"></a>

Muchas cargas de trabajo de base de datos son de naturaleza cíclica, mientras que otras son difíciles de predecir con antelación. Por ejemplo, tomemos una aplicación de redes sociales en la que la mayoría de los usuarios están activos en el horario diurno. La base de datos debe satisfacer los requisitos de la actividad diurna, pero no se requieren los mismos niveles de rendimiento por la noche. Otro ejemplo: tomemos una nueva aplicación de juegos para móviles cuya adopción está siendo inesperadamente rápida. Si el juego adquiere demasiada popularidad, podría superar los recursos disponibles en la base de datos, lo que daría lugar a un rendimiento lento y a clientes descontentos. Estos tipos de cargas de trabajo suelen requerir intervención manual para escalar los recursos de la base de datos en sentido ascendente o descendente en respuesta a las variaciones en los niveles de uso.

El escalado automático de Amazon DynamoDB usa el servicio Auto Scaling de aplicaciones de AWS para ajustar de manera dinámica y automática la capacidad de rendimiento aprovisionada en respuesta a los patrones de tráfico reales. Esto permite a una tabla o índice secundario global (GSI) incrementar su capacidad de lectura y escritura aprovisionada para abastecer incrementos repentinos del tráfico sin limitaciones. Cuando la carga de trabajo disminuye, el Auto Scaling de aplicaciones puede reducir el rendimiento para evitar que tenga que pagar por una capacidad aprovisionada que no se utiliza.

**nota**  
Si usa la Consola de administración de AWS para crear una tabla o un índice secundario global, la función Auto Scaling de DynamoDB se habilita de forma predeterminada. Puede modificar los ajustes de Auto Scaling en cualquier momento. Para obtener más información, consulte [Uso de la Consola de administración de AWS con la función Auto Scaling de DynamoDB](AutoScaling.Console.md).  
Cuando elimina una tabla o una réplica de tabla global, los destinos escalables, las políticas de escalado o las alarmas de CloudWatch asociadas no se eliminan automáticamente con ella.

Con Auto Scaling de aplicaciones, puede crear una *política de escalado* para una tabla o un índice secundario global. La política de escalado especifica si desea escalar la capacidad de lectura o de escritura (o ambas), así como los ajustes de unidades de capacidad provisionada mínimas y máximas para la tabla o el índice.

La política de escalado contiene además un valor de *objetivo de utilización*, es decir, el porcentaje de rendimiento aprovisionado consumido en un momento dado. Auto Scaling de aplicaciones utiliza un algoritmo de *seguimiento de destino* para ajustar el rendimiento aprovisionado de la tabla (o el índice) al alza o a la baja en respuesta a las cargas de trabajo reales, de tal forma que la utilización de la capacidad real se mantenga en valores iguales o parecidos al objetivo de utilización.

Las salidas de DynamoDB consumieron el rendimiento aprovisionado durante periodos de un minuto. El escalado automático se activa cuando la capacidad consumida supera el objetivo de utilización configurado durante dos minutos consecutivos. Es posible que las alarmas de CloudWatch tarden unos minutos antes de desencadenar el escalado automático. Este retraso garantiza una evaluación precisa de las métricas de CloudWatch. Si los picos de rendimiento consumidos están separados por más de un minuto, es posible que no se desencadene el escalado automático. Del mismo modo, se puede producir un evento de reducción vertical cuando 15 puntos de datos consecutivos sean inferiores a la utilización objetivo. En cualquier caso, tras desencadenar el escalado automático, se invoca la API [UpdateTable](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateTable.html). La actualización de la capacidad aprovisionada para la tabla o el índice puede tardar unos minutos. Durante este periodo, cualquier solicitud que supere la capacidad aprovisionada previamente de las tablas se limita.

**importante**  
No se puede ajustar el número de puntos de datos que se van a violar para desencadenar la alarma subyacente (aunque el número actual podría cambiar en el futuro).

 Puede establecer los valores de objetivo de utilización de escalado automático entre un 20 y un 90 por ciento de la capacidad de lectura y escritura. 

**nota**  
Además de con las tablas, el escalado automático de DynamoDB es compatible con los índices secundarios globales. Cada índice secundario global tiene su propia capacidad de rendimiento aprovisionada que es independiente de la de su tabla base. Al crear una política de escalado para un índice secundario global, Auto Scaling de aplicaciones ajusta los ajustes de rendimiento aprovisionado del índice para asegurarse de que el uso real se mantenga en valores iguales o parecidos al porcentaje de utilización deseado.

## Funcionamiento de la función Auto Scaling de DynamoDB
<a name="AutoScaling.HowItWorks"></a>

**nota**  
Para comenzar rápidamente a usar la función Auto Scaling de DynamoDB, consulte [Uso de la Consola de administración de AWS con la función Auto Scaling de DynamoDB](AutoScaling.Console.md).

En el siguiente diagrama se ofrece información general sobre cómo el escalado automático de DynamoDB administra la capacidad de rendimiento de una tabla.

![\[El escalado automático de DynamoDB ajusta la capacidad de rendimiento de una tabla para satisfacer la demanda.\]](http://docs.aws.amazon.com/es_es/amazondynamodb/latest/developerguide/images/auto-scaling.png)


En los pasos siguientes se resume el proceso de Auto Scaling mostrado en el diagrama anterior:

1. Cree una política de Auto Scaling de aplicaciones para la tabla de DynamoDB.

1. DynamoDB publica métricas de capacidad consumida en Amazon CloudWatch. 

1. Si la capacidad consumida de la tabla supera el objetivo de utilización (o no lo alcanza) durante un periodo de tiempo específico, Amazon CloudWatch activa una alarma. Puede ver la alarma en la consola y recibir notificaciones mediante Amazon Simple Notification Service (Amazon SNS).

1. La alarma de CloudWatch invoca a Auto Scaling de aplicaciones para evaluar la política de escalado.

1. Auto Scaling de aplicaciones emite una solicitud `UpdateTable` para ajustar el rendimiento aprovisionado de la tabla.

1. DynamoDB procesa la solicitud `UpdateTable` y aumenta (o reduce) dinámicamente la capacidad de rendimiento aprovisionada de la tabla para que sea parecida al objetivo de utilización.

Para comprender cómo funciona el escalado automático de DynamoDB, supongamos que tenemos una tabla denominada `ProductCatalog`. Es infrecuente que se realicen cargas masivas de datos en la tabla, de modo que presenta poca actividad de escritura. Sin embargo, sí experimenta una intensa actividad de lectura, que varía en cada momento. Gracias a las métricas de Amazon CloudWatch de `ProductCatalog` que se monitorean, ha determinado que la tabla requiere 1 200 unidades de capacidad de lectura (para evitar que DynamoDB aplique una limitación controlada a las solicitudes de lectura durante los picos de actividad). También ha determinado que `ProductCatalog` requiere como mínimo 150 unidades de capacidad de lectura, cuando el tráfico de lectura se encuentra en el punto más bajo. Para obtener más información sobre cómo prevenir la limitación, consulte [Solución de problemas de limitación en Amazon DynamoDB](TroubleshootingThrottling.md).

Dentro del rango de 150 a 1200 unidades de capacidad de lectura, decide que un objetivo de utilización del 70 por ciento sería apropiado para la tabla `ProductCatalog`. El *objetivo de utilización* es la proporción de unidades de capacidad consumidas respecto de las unidades de capacidad provisionadas y se expresa como un porcentaje. Auto Scaling de aplicaciones utiliza el algoritmo de seguimiento de destino para asegurarse de que la capacidad de lectura provisionada de `ProductCatalog` se ajuste de acuerdo con las necesidades, de tal forma que la utilización permanezca próxima al 70 %.

**nota**  
La función de escalado automático de DynamoDB modifica la configuración de rendimiento aprovisionado solo cuando la carga de trabajo real se mantiene elevada o reducida durante un periodo sostenido de varios minutos. El algoritmo de seguimiento de destino de Auto Scaling de aplicaciones intenta mantener el objetivo de utilización en el valor elegido o en valores próximos a él a largo plazo.  
Los picos de actividad repentinos y breves se atienden gracias a la capacidad de ampliación incorporada de la tabla. Para obtener más información, consulte [Capacidad de ampliación](burst-adaptive-capacity.md#burst-capacity).

Para habilitar el escalado automático de DynamoDB para la tabla `ProductCatalog`, debe crear una política de escalado. La política especifica los elementos siguientes:
+ La tabla o el índice secundario global que desea administrar
+ Qué tipo de capacidad va a administrar (capacidad de lectura o capacidad de escritura)
+ Los límites superior e inferior de los ajustes de desempeño provisionado
+ Su objetivo de utilización

Al crear una política de escalado, Auto Scaling de aplicaciones crea automáticamente un par de alarmas de Amazon CloudWatch. Cada par representa los límites superior e inferior de la configuración de rendimiento provisionado. Estas alarmas de CloudWatch se activan cuando la utilización real de la tabla se desvía del objetivo de utilización durante un periodo de tiempo prolongado.

Cuando se activa una de las alarmas de CloudWatch, Amazon SNS envía una notificación (si se ha habilitado). A continuación, la alarma de CloudWatch invoca a Auto Scaling de aplicaciones que, a su vez, notifica a DynamoDB para que ajuste la capacidad aprovisionada de la tabla `ProductCatalog` al alza o a la baja, según corresponda.

Durante un evento de escalado, la AWS Config se cobra por cada elemento de configuración registrado. Cuando se produce un evento de escalado, se crean cuatro alarmas de CloudWatch para cada evento de escalado automático de lectura y escritura: alarmas ProvisionedCapacity: ProvisionedCapacityLow, ProvisionedCapacityHigh y alarmas ConsumedCapacity: AlarmHigh, AlarmLow. Esto da como resultado un total de ocho alarmas. Por lo tanto, AWS Config registra ocho elementos de configuración para cada evento de escalado.

**nota**  
También puede programar el escalado de DynamoDB para que se realice en determinados momentos. Descubra los pasos básicos [aquí](https://docs.aws.amazon.com/autoscaling/application/userguide/get-started-exercise.html).

## Notas de uso
<a name="AutoScaling.UsageNotes"></a>

Antes de comenzar a usar la función Auto Scaling de DynamoDB, debe tener en cuenta lo siguiente:
+ La función Auto Scaling de DynamoDB puede aumentar la capacidad de lectura o escritura tan a menudo como sea preciso, de acuerdo con la política de Auto Scaling. Todas las cuotas de DynamoDB siguen vigentes, tal como se describe en [Cuotas en Amazon DynamoDB](ServiceQuotas.md).
+ La función Auto Scaling de DynamoDB no le impide modificar manualmente la configuración de rendimiento aprovisionado. Estos ajustes manuales no afectan a las alarmas de CloudWatch vigentes relacionadas con la función Auto Scaling de DynamoDB.
+ Si habilita la función Auto Scaling de DynamoDB en una tabla que tiene uno o varios índices secundarios globales, recomendamos encarecidamente aplicar también Auto Scaling de manera uniforme a esos índices. Esto contribuirá a garantizar un mejor rendimiento en las escrituras y lecturas de las tablas, y a evitar la limitación. Puede activar el escalado automático si selecciona **Apply same settings to global secondary indexes** (Aplicar la misma configuración a los índices secundarios globales) en la Consola de administración de AWS. Para obtener más información, consulte [Habilitación de la función Auto Scaling de DynamoDB en tablas existentes](AutoScaling.Console.md#AutoScaling.Console.ExistingTable).
+ Cuando elimina una tabla o una réplica de tabla global, los destinos escalables, las políticas de escalado o las alarmas de CloudWatch asociadas no se eliminan automáticamente con ella.
+ Al crear un GSI para una tabla existente, la función Auto Scaling no está habilitada para el GSI. Tendrá que administrar manualmente la capacidad mientras se construye el GSI. Una vez que se complete el relleno del GSI y este alcance el estado activo, la función de escalado automático funcionará con normalidad.

# Uso de la Consola de administración de AWS con la función Auto Scaling de DynamoDB
<a name="AutoScaling.Console"></a>

Si usa la Consola de administración de AWS para crear una tabla nueva, la función Auto Scaling de Amazon DynamoDB se habilita para esa tabla de forma predeterminada. También puede utilizar la consola para habilitar Auto Scaling en las tablas existentes, modificar la configuración de esta función o deshabilitarla.

**nota**  
 Para obtener carácterísticas más avanzadas como la configuración de tiempos de recuperación de escalado y reducción horizontal, utilice la AWS Command Line Interface (AWS CLI) para administrar el Auto Scaling de DynamoDB. Para obtener más información, consulte [Uso de la AWS CLI para administrar la función Auto Scaling de DynamoDB](AutoScaling.CLI.md).

**Topics**
+ [Antes de comenzar: concesión de permisos a los usuarios para la función Auto Scaling de DynamoDB](#AutoScaling.Permissions)
+ [Creación de una nueva tabla con la función Auto Scaling habilitada](#AutoScaling.Console.NewTable)
+ [Habilitación de la función Auto Scaling de DynamoDB en tablas existentes](#AutoScaling.Console.ExistingTable)
+ [Visualización de las actividades de Auto Scaling en la consola](#AutoScaling.Console.ViewingActivities)
+ [Modificación o deshabilitación de la configuración de Auto Scaling de DynamoDB](#AutoScaling.Console.Modifying)

## Antes de comenzar: concesión de permisos a los usuarios para la función Auto Scaling de DynamoDB
<a name="AutoScaling.Permissions"></a>

En AWS Identity and Access Management (IAM), la política `DynamoDBFullAccess` administrada por AWS proporciona los permisos necesarios para utilizar la consola de DynamoDB. No obstante, para el escalamiento automático de DynamoDB, los usuarios necesitan permisos adicionales. 

**importante**  
 Para eliminar una tabla habilitada para el escalado automático se necesitan permisos `application-autoscaling:*`. La política `DynamoDBFullAccess` administrada por AWS incluye estos permisos.

Para configurar un usuario para el acceso a la consola de DynamoDB y el escalamiento automático de DynamoDB, cree un rol y agregue la política **AmazonDynamoDBFullAccess** a dicho rol. A continuación, asigne el rol a un usuario.

## Creación de una nueva tabla con la función Auto Scaling habilitada
<a name="AutoScaling.Console.NewTable"></a>

**nota**  
El escalamiento automático de DynamoDB requiere la presencia de un rol vinculado al servicio (`AWSServiceRoleForApplicationAutoScaling_DynamoDBTable`) que realice acciones de escalamiento automático en su nombre. Este rol se crea automáticamente. Para obtener más información, consulte [Roles vinculados a servicios de Auto Scaling de aplicaciones](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html) en la *Guía del usuario de Auto Scaling de aplicaciones*.

**Para crear una nueva tabla con la función Auto Scaling habilitada**

1. Abra la consola de DynamoDB en [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/).

1. Seleccione **Create table**.

1. En la página **Crear tabla**, ingrese los detalles de **Nombre de tabla** y clave principal.

1. Si elige **Configuración predeterminada**, el escalado automático se habilita en la nueva tabla.

   De lo contrario, elija **Personalizar la configuración** y haga lo siguiente para especificar la configuración personalizada de la tabla: 

   1. Para **Clase de tabla**, mantenga la selección predeterminada de **DynamoDB Standard**.

   1. Para la **Configuración de la capacidad de lectura o escritura**, mantenga la selección predeterminada de **Aprovisionada** y, a continuación, haga lo siguiente:

      1. Para la **Capacidad de lectura**, asegúrese de que el **Escalado automático** esté configurado en **Activado**.

      1. Para la **Capacidad de escritura**, asegúrese de que el **Escalado automático** esté configurado en **Activado**.

      1. Para **Capacidad de lectura** y **Capacidad de escritura**, establezca la política de escalado que desee para la tabla y, opcionalmente, para todos los índices secundarios globales de la tabla.
         + **Unidades de capacidad mínimas**: introduzca el límite inferior del intervalo de escalamiento automático.
         + **Unidades de capacidad máxima**: introduzca el límite superior del intervalo de escalamiento automático.
         + **Objetivo de utilización**: introduzca su porcentaje de utilización objetivo para la tabla.
**nota**  
Si crea un índice secundario global para la nueva tabla, la capacidad del índice en el momento de la creación será la misma que la capacidad de la tabla base. Puede cambiar la capacidad del índice en la configuración de la tabla después de crearla.

1. Seleccione **Create table (Creación de tabla)**. Esto crea la tabla con los parámetros de escalado automático especificados.

## Habilitación de la función Auto Scaling de DynamoDB en tablas existentes
<a name="AutoScaling.Console.ExistingTable"></a>

**nota**  
El escalamiento automático de DynamoDB requiere la presencia de un rol vinculado al servicio (`AWSServiceRoleForApplicationAutoScaling_DynamoDBTable`) que realice acciones de escalamiento automático en su nombre. Este rol se crea automáticamente. Para obtener más información, consulte [Roles vinculados a servicios para Aplication Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html).

**Para habilitar la función Auto Scaling de DynamoDB en una tabla existente**

1. Abra la consola de DynamoDB en [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/).

1. En el panel de navegación del lado izquierdo de la consola, elija **Tablas**.

1. Elija la tabla en la que desee habilitar el escalado automático y, a continuación, haga lo siguiente:

   1. Elija la pestaña **Configuración adicional**.

   1. En la sección **Capacidad de lectura/escritura**, elija **Editar**.

   1. En la sección **Modo de capacidad**, elija **Aprovisionado**.

   1. En la sección **Capacidad de tabla**, establezca **Escalado automático** en **Activado** para **Capacidad de lectura**, **Capacidad de escritura** o ambas. Para cada uno de ellos, establezca la política de escalado que desee para la tabla y, opcionalmente, para todos los índices secundarios globales de la tabla.
      + **Unidades de capacidad mínimas**: introduzca el límite inferior del intervalo de escalamiento automático.
      + **Unidades de capacidad máxima**: introduzca el límite superior del intervalo de escalamiento automático.
      + **Objetivo de utilización**: introduzca su porcentaje de utilización objetivo para la tabla.
      + **Usar la misma configuración de capacidad de lectura/escritura para todos los índices secundarios globales**: elija si los índices secundarios globales deben utilizar la misma política de escalamiento automático que la tabla base.
**nota**  
Para obtener el máximo rendimiento, le recomendamos que habilite la opción **Use the same read/write capacity settings for all global secondary indexes** (Utilizar la misma configuración de capacidad de lectura/escritura para todos los índices secundarios globales). Esta opción permite que la función Auto Scaling de DynamoDB pueda escalar uniformemente todos los índices secundarios globales de la tabla base. Esto incluye los índices secundarios globales existentes y cualquier otro que se creen en esta tabla en el futuro.  
Con esta opción habilitada, no se puede establecer una política de escalado para un índice secundario global individual.

1. Cuando la configuración sea la que desea, elija **Save (Guardar)**.

## Visualización de las actividades de Auto Scaling en la consola
<a name="AutoScaling.Console.ViewingActivities"></a>

A medida que la aplicación envía tráfico de lectura y escritura a la tabla, la función Auto Scaling de DynamoDB modifica de forma dinámica la configuración de rendimiento de esa tabla. Amazon CloudWatch realiza un seguimiento de la capacidad aprovisionada y consumida, los eventos limitados, la latencia y otras métricas de todas las tablas de DynamoDB e índices secundarios.

Para ver estas métricas en la consola de DynamoDB, elija la tabla con la que desee trabajar y seleccione la pestaña **Monitorear**. Para crear una vista personalizable de las métricas de tabla, seleccione **View all in CloudWatch** (Ver todo en CloudWatch).

## Modificación o deshabilitación de la configuración de Auto Scaling de DynamoDB
<a name="AutoScaling.Console.Modifying"></a>

Puede utilizar la Consola de administración de AWS para modificar la configuración de Auto Scaling de DynamoDB. Para ello, vaya a la pestaña **Configuración adicional** de la tabla y elija **Editar** en la sección **Capacidad de lectura/escritura**. Para obtener más información sobre estas opciones, consulte [Habilitación de la función Auto Scaling de DynamoDB en tablas existentes](#AutoScaling.Console.ExistingTable).

# Uso de la AWS CLI para administrar la función Auto Scaling de DynamoDB
<a name="AutoScaling.CLI"></a>

En lugar de utilizar la Consola de administración de AWS, puede utilizar la AWS Command Line Interface (AWS CLI) para administrar la función Auto Scaling de Amazon DynamoDB. En el tutorial de esta sección se muestra cómo instalar y configurar la AWS CLI para administrar la función Auto Scaling de DynamoDB. En este tutorial, aprenderá a hacer lo siguiente:
+ Creación de una tabla de DynamoDB llamada `TestTable`. Los ajustes de desempeño iniciales son 5 unidades de capacidad de lectura y 5 unidades de capacidad de escritura.
+ Cree una política Auto Scaling de aplicaciones para `TestTable`. La política está dirigida a mantener una proporción objetivo del 50 % entre la capacidad de escritura consumida y la capacidad de escritura provisionada. El rango de esta métrica está comprendido entre 5 y 10 unidades de capacidad de escritura. (Auto Scaling de aplicaciones no puede ajustar el rendimiento fuera de este rango).
+ Ejecute un programa en Python para dirigir tráfico de escritura a `TestTable`. Cuando la proporción objetivo supere el 50 % durante un periodo prolongado, el Auto Scaling de aplicaciones se lo notificará a DynamoDB para que ajuste el rendimiento de `TestTable` al alza y, de este modo, mantener el 50 % de utilización de destinos.
+ Compruebe que DynamoDB haya ajustado correctamente la capacidad de escritura aprovisionada para `TestTable`.

**nota**  
También puede programar el escalado de DynamoDB para que se realice en determinados momentos. Descubra los pasos básicos [aquí](https://docs.aws.amazon.com/autoscaling/application/userguide/get-started-exercise.html).

**Topics**
+ [Antes de empezar](#AutoScaling.CLI.BeforeYouBegin)
+ [Paso 1: crear una tabla de DynamoDB](#AutoScaling.CLI.CreateTable)
+ [Paso 2: registrar un objetivo escalable](#AutoScaling.CLI.RegisterScalableTarget)
+ [Paso 3: crear una política de escalado](#AutoScaling.CLI.CreateScalingPolicy)
+ [Paso 4: dirigir tráfico de escritura a TestTable](#AutoScaling.CLI.DriveTraffic)
+ [Paso 5: consultar las acciones de Auto Scaling de aplicaciones](#AutoScaling.CLI.ViewCWAlarms)
+ [(Opcional) Paso 6: limpiar](#AutoScaling.CLI.CleanUp)

## Antes de empezar
<a name="AutoScaling.CLI.BeforeYouBegin"></a>

Complete las siguientes tareas antes de comenzar el tutorial.

### Instala la AWS CLI
<a name="AutoScaling.CLI.BeforeYouBegin.InstallCLI"></a>

Si aún no lo ha hecho, debe instalar y configurar la AWS CLI. Para ello, siga las siguientes instrucciones en la *Guía del usuario de AWS Command Line Interface*:
+ [Instalación del AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/installing.html)
+ [Configuración de la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)

### Instalación de Python
<a name="AutoScaling.CLI.BeforeYouBegin.InstallPython"></a>

Una parte de este tutorial requiere que se ejecute un programa en Python (consulte [Paso 4: dirigir tráfico de escritura a TestTable](#AutoScaling.CLI.DriveTraffic)). Si aún no lo tiene instalado, puede [descargar Python](https://www.python.org/downloads). 

## Paso 1: crear una tabla de DynamoDB
<a name="AutoScaling.CLI.CreateTable"></a>

En este paso, utilice la AWS CLI para crear una `TestTable`. La clave principal consta de `pk` (clave de partición) y `sk` (clave de ordenación). Ambos atributos son de tipo `Number`. Los ajustes de desempeño iniciales son 5 unidades de capacidad de lectura y 5 unidades de capacidad de escritura.

1. Utilice el siguiente comando de la AWS CLI para crear la tabla.

   ```
   aws dynamodb create-table \
       --table-name TestTable \
       --attribute-definitions \
           AttributeName=pk,AttributeType=N \
           AttributeName=sk,AttributeType=N \
       --key-schema \
           AttributeName=pk,KeyType=HASH \
           AttributeName=sk,KeyType=RANGE \
       --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5
   ```

1. Para comprobar el estado de la tabla, use el comando siguiente.

   ```
   aws dynamodb describe-table \
       --table-name TestTable \
       --query "Table.[TableName,TableStatus,ProvisionedThroughput]"
   ```

   La tabla está lista para usarla cuando su estado es `ACTIVE`.

## Paso 2: registrar un objetivo escalable
<a name="AutoScaling.CLI.RegisterScalableTarget"></a>

Ahora, vamos a registrar la capacidad de escritura de la tabla como objetivo escalable con Auto Scaling de aplicaciones. Esto permite que Auto Scaling de aplicaciones ajuste la capacidad de escritura aprovisionada para *TestTable*, pero solo dentro del rango de entre 5 y 10 unidades de capacidad.

**nota**  
La función Auto Scaling de DynamoDB requiere la presencia de un rol (`AWSServiceRoleForApplicationAutoScaling_DynamoDBTable`) que lleve a cabo las acciones de escalado automático en su nombre. Este rol se crea automáticamente para usted. Para obtener más información, consulte [Roles vinculados a servicios de Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html) en la *Guía del usuario de Application Auto Scaling*. 

1. Ingrese el siguiente comando para registrar el objetivo escalable. 

   ```
   aws application-autoscaling register-scalable-target \
       --service-namespace dynamodb \
       --resource-id "table/TestTable" \
       --scalable-dimension "dynamodb:table:WriteCapacityUnits" \
       --min-capacity 5 \
       --max-capacity 10
   ```

1. Para comprobar el registro, utilice el siguiente comando.

   ```
   aws application-autoscaling describe-scalable-targets \
       --service-namespace dynamodb \
       --resource-id "table/TestTable"
   ```
**nota**  
 También puede registrar un destino escalable en un índice secundario global. Por ejemplo, para un índice secundario global (“test-index”), el ID de recurso y los argumentos de dimensión escalable se actualizan adecuadamente.   

   ```
   aws application-autoscaling register-scalable-target \
       --service-namespace dynamodb \
       --resource-id "table/TestTable/index/test-index" \
       --scalable-dimension "dynamodb:index:WriteCapacityUnits" \
       --min-capacity 5 \
       --max-capacity 10
   ```

## Paso 3: crear una política de escalado
<a name="AutoScaling.CLI.CreateScalingPolicy"></a>

En este paso, se crea una política de escalado para `TestTable`. La política define los detalles según los cuales Auto Scaling de aplicaciones puede ajustar el rendimiento aprovisionado de la tabla y las acciones llevará a cabo para ello. Puede asociar esta política al objetivo escalable definido en el paso anterior (unidades de capacidad de escritura para la tabla `TestTable`).

La política contiene los componentes siguientes:
+ `PredefinedMetricSpecification`: métrica que puede ajustar Auto Scaling de aplicaciones. Para DynamoDB, los siguientes valores son válidos para `PredefinedMetricType`:
  + `DynamoDBReadCapacityUtilization`
  + `DynamoDBWriteCapacityUtilization`
+ `ScaleOutCooldown`: cantidad mínima de tiempo (en segundos) entre cada evento de Auto Scaling de aplicaciones que aumenta el rendimiento aprovisionado. Este parámetro permite que Auto Scaling de aplicaciones aumente de forma continua, pero no drástica, el rendimiento en respuesta a las cargas de trabajo reales. El ajuste predeterminado de `ScaleOutCooldown` es 0.
+ `ScaleInCooldown`: cantidad mínima de tiempo (en segundos) entre cada evento de Auto Scaling de aplicaciones que reduce el rendimiento aprovisionado. Este parámetro permite que Auto Scaling de aplicaciones disminuya el rendimiento de manera gradual y predecible. El ajuste predeterminado de `ScaleInCooldown` es 0.
+ `TargetValue`: Auto Scaling de aplicaciones se asegura de que la proporción entre capacidad consumida y capacidad aprovisionada se mantenga en este valor o en un valor próximo. `TargetValue` se define como un porcentaje.

**nota**  
Para entender cómo funciona `TargetValue`, imagine que tiene una tabla con una configuración de rendimiento aprovisionado de 200 unidades de capacidad de escritura. Decide crear una política de escalado para esta tabla, con un valor de `TargetValue` del 70 %.  
Ahora, supongamos que comienza a dirigir el tráfico de escritura a la tabla, de tal forma que el rendimiento de escritura real es de 150 unidades de capacidad. La proporción entre capacidad consumida y aprovisionada es ahora de (150/200), es decir, del 75 %. Esta proporción supera su objetivo, de modo que Auto Scaling de aplicaciones aumenta la capacidad de escritura aprovisionada a 215 para que la proporción sea de (150/215), es decir, del 69,77 %; de esta forma se mantiene lo más próxima posible al valor de `TargetValue`, pero sin superarlo.

Para `TestTable`, configure `TargetValue` hasta el 50 %. Auto Scaling de aplicaciones ajusta el rendimiento aprovisionado de la tabla dentro del rango comprendido entre 5 y 10 unidades de capacidad (consulte [Paso 2: registrar un objetivo escalable](#AutoScaling.CLI.RegisterScalableTarget)), de tal forma que la proporción entre capacidad consumida y provisionada se mantiene en el 50 % o en un valor próximo a este. Los valores de `ScaleOutCooldown` y `ScaleInCooldown` se establecen en 60 segundos.

1. Cree un archivo denominado `scaling-policy.json` con el siguiente contenido.

   ```
   {
       "PredefinedMetricSpecification": {
           "PredefinedMetricType": "DynamoDBWriteCapacityUtilization"
       },
       "ScaleOutCooldown": 60,
       "ScaleInCooldown": 60,
       "TargetValue": 50.0
   }
   ```

1. Utilice el siguiente comando de la AWS CLI para crear la política.

   ```
   aws application-autoscaling put-scaling-policy \
       --service-namespace dynamodb \
       --resource-id "table/TestTable" \
       --scalable-dimension "dynamodb:table:WriteCapacityUnits" \
       --policy-name "MyScalingPolicy" \
       --policy-type "TargetTrackingScaling" \
       --target-tracking-scaling-policy-configuration file://scaling-policy.json
   ```

1. En el resultado, observe que Auto Scaling de aplicaciones ha creado dos alarmas de Amazon CloudWatch, una para cada límite (superior e inferior) del rango de escalado objetivo.

1. Utilice el comando de AWS CLI siguiente para ver más detalles sobre la política de escalado.

   ```
   aws application-autoscaling describe-scaling-policies \
       --service-namespace dynamodb \
       --resource-id "table/TestTable" \
       --policy-name "MyScalingPolicy"
   ```

1. En el resultado, compruebe que los ajustes de la política coincidan con las especificaciones de [Paso 2: registrar un objetivo escalable](#AutoScaling.CLI.RegisterScalableTarget) y [Paso 3: crear una política de escalado](#AutoScaling.CLI.CreateScalingPolicy).

## Paso 4: dirigir tráfico de escritura a TestTable
<a name="AutoScaling.CLI.DriveTraffic"></a>

Ahora puede probar la política de escalado escribiendo datos en . `TestTable`. Para ello, deberá ejecutar un programa en Python.

1. Cree un archivo denominado `bulk-load-test-table.py` con el siguiente contenido.

   ```
   import boto3
   dynamodb = boto3.resource('dynamodb')
   
   table = dynamodb.Table("TestTable")
   
   filler = "x" * 100000
   
   i = 0
   while (i < 10):
       j = 0
       while (j < 10):
           print (i, j)
           
           table.put_item(
               Item={
                   'pk':i,
                   'sk':j,
                   'filler':{"S":filler}
               }
           )
           j += 1
       i += 1
   ```

1. Para ejecutar el programa, introduzca el siguiente comando.

   `python bulk-load-test-table.py`

   La capacidad de escritura provisionada de `TestTable` es muy baja (5 unidades de capacidad de escritura), por lo que el programa se ahoga en ocasiones a causa de la limitación controlada de escritura. Este es el comportamiento esperado.

   Permita que el programa continúe ejecutándose mientras avanza al paso siguiente.

## Paso 5: consultar las acciones de Auto Scaling de aplicaciones
<a name="AutoScaling.CLI.ViewCWAlarms"></a>

 En este paso, consultaremos las acciones de Auto Scaling de aplicaciones que se han iniciado en su nombre. Además, comprobaremos que Auto Scaling de aplicaciones ha actualizado la capacidad de escritura provisionada para `TestTable`.

1. Ingrese el siguiente comando para ver las acciones de Auto Scaling de aplicaciones.

   ```
   aws application-autoscaling describe-scaling-activities \
       --service-namespace dynamodb
   ```

   Vuelva a ejecutar este comando cada cierto tiempo mientras el programa en Python siga en ejecución. (Se tardarán varios minutos hasta que se invoque la política de escalado). En algún momento, debería aparecer el resultado siguiente.

   ```
   ...
   {
       "ScalableDimension": "dynamodb:table:WriteCapacityUnits", 
       "Description": "Setting write capacity units to 10.", 
       "ResourceId": "table/TestTable", 
       "ActivityId": "0cc6fb03-2a7c-4b51-b67f-217224c6b656", 
       "StartTime": 1489088210.175, 
       "ServiceNamespace": "dynamodb", 
       "EndTime": 1489088246.85, 
       "Cause": "monitor alarm AutoScaling-table/TestTable-AlarmHigh-1bb3c8db-1b97-4353-baf1-4def76f4e1b9 in state ALARM triggered policy MyScalingPolicy", 
       "StatusMessage": "Successfully set write capacity units to 10. Change successfully fulfilled by dynamodb.", 
       "StatusCode": "Successful"
   }, 
   ...
   ```

   Esto indica que el Auto Scaling de aplicaciones ha emitido una solicitud `UpdateTable` a DynamoDB.

1. Ingrese el siguiente comando para comprobar que DynamoDB ha aumentado la capacidad de escritura de la tabla.

   ```
   aws dynamodb describe-table \
       --table-name TestTable \
       --query "Table.[TableName,TableStatus,ProvisionedThroughput]"
   ```

   `WriteCapacityUnits` debería haberse escalado de `5` a `10`.

## (Opcional) Paso 6: limpiar
<a name="AutoScaling.CLI.CleanUp"></a>

En este tutorial, ha creado varios recursos. Puede eliminar estos recursos cuando ya los necesite.

1. Elimine la política de escalado para `TestTable`.

   ```
   aws application-autoscaling delete-scaling-policy \
       --service-namespace dynamodb \
       --resource-id "table/TestTable" \
       --scalable-dimension "dynamodb:table:WriteCapacityUnits" \
       --policy-name "MyScalingPolicy"
   ```

1. Anule el registro del objetivo escalable.

   ```
   aws application-autoscaling deregister-scalable-target \
       --service-namespace dynamodb \
       --resource-id "table/TestTable" \
       --scalable-dimension "dynamodb:table:WriteCapacityUnits"
   ```

1. Elimine la tabla `TestTable`.

   ```
   aws dynamodb delete-table --table-name TestTable
   ```

# Uso del AWS SDK para configurar escalado automático en tablas de Amazon DynamoDB
<a name="AutoScaling.HowTo.SDK"></a>

Además de utilizar la Consola de administración de AWS y la AWS Command Line Interface (AWS CLI), puede escribir aplicaciones que interaccionen con el escalado automático de Amazon DynamoDB. Esta sección contiene dos programas de Java que puede utilizar para probar esta funcionalidad:
+ `EnableDynamoDBAutoscaling.java`
+ `DisableDynamoDBAutoscaling.java`

## Habilitación de Auto Scaling de aplicaciones para una tabla
<a name="AutoScaling.HowTo.SDK-enable"></a>

En el siguiente programa se muestra un ejemplo de cómo configurar una política de escalado automático para una tabla de DynamoDB (`TestTable`). Funciona de la siguiente manera:
+ El programa registra las unidades de capacidad de escritura como objetivo escalable de `TestTable`. El rango de esta métrica está comprendido entre 5 y 10 unidades de capacidad de escritura.
+ Después de crear el objetivo escalable, el programa crea una configuración de seguimiento del objetivo. La política está dirigida a mantener una proporción objetivo del 50 % entre la capacidad de escritura consumida y la capacidad de escritura provisionada.
+ Después, el programa crea la política de escalado basada en la configuración de seguimiento del objetivo.

**nota**  
Cuando se elimina manualmente una tabla o réplica de tabla global, no se eliminan automáticamente los destinos escalables asociados, las políticas de escalado o las alarmas de CloudWatch.

------
#### [ Java v2 ]

```
import software.amazon.awssdk.regions.Region;
import software.amazon.awssdk.services.applicationautoscaling.ApplicationAutoScalingClient;
import software.amazon.awssdk.services.applicationautoscaling.model.ApplicationAutoScalingException;
import software.amazon.awssdk.services.applicationautoscaling.model.DescribeScalableTargetsRequest;
import software.amazon.awssdk.services.applicationautoscaling.model.DescribeScalableTargetsResponse;
import software.amazon.awssdk.services.applicationautoscaling.model.DescribeScalingPoliciesRequest;
import software.amazon.awssdk.services.applicationautoscaling.model.DescribeScalingPoliciesResponse;
import software.amazon.awssdk.services.applicationautoscaling.model.PolicyType;
import software.amazon.awssdk.services.applicationautoscaling.model.PredefinedMetricSpecification;
import software.amazon.awssdk.services.applicationautoscaling.model.PutScalingPolicyRequest;
import software.amazon.awssdk.services.applicationautoscaling.model.RegisterScalableTargetRequest;
import software.amazon.awssdk.services.applicationautoscaling.model.ScalingPolicy;
import software.amazon.awssdk.services.applicationautoscaling.model.ServiceNamespace;
import software.amazon.awssdk.services.applicationautoscaling.model.ScalableDimension;
import software.amazon.awssdk.services.applicationautoscaling.model.MetricType;
import software.amazon.awssdk.services.applicationautoscaling.model.TargetTrackingScalingPolicyConfiguration;
import java.util.List;

/**
 * Before running this Java V2 code example, set up your development environment, including your credentials.
 *
 * For more information, see the following documentation topic:
 *
 * https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/get-started.html
 */
public class EnableDynamoDBAutoscaling {
    public static void main(String[] args) {
        final String usage = """

            Usage:
               <tableId> <roleARN> <policyName>\s

            Where:
               tableId - The table Id value (for example, table/Music).
               roleARN - The ARN of the role that has ApplicationAutoScaling permissions.
               policyName - The name of the policy to create.
               
            """;

        if (args.length != 3) {
            System.out.println(usage);
            System.exit(1);
        }

        System.out.println("This example registers an Amazon DynamoDB table, which is the resource to scale.");
        String tableId = args[0];
        String roleARN = args[1];
        String policyName = args[2];
        ServiceNamespace ns = ServiceNamespace.DYNAMODB;
        ScalableDimension tableWCUs = ScalableDimension.DYNAMODB_TABLE_WRITE_CAPACITY_UNITS;
        ApplicationAutoScalingClient appAutoScalingClient = ApplicationAutoScalingClient.builder()
            .region(Region.US_EAST_1)
            .build();

        registerScalableTarget(appAutoScalingClient, tableId, roleARN, ns, tableWCUs);
        verifyTarget(appAutoScalingClient, tableId, ns, tableWCUs);
        configureScalingPolicy(appAutoScalingClient, tableId, ns, tableWCUs, policyName);
    }

    public static void registerScalableTarget(ApplicationAutoScalingClient appAutoScalingClient, String tableId, String roleARN, ServiceNamespace ns, ScalableDimension tableWCUs) {
        try {
            RegisterScalableTargetRequest targetRequest = RegisterScalableTargetRequest.builder()
                .serviceNamespace(ns)
                .scalableDimension(tableWCUs)
                .resourceId(tableId)
                .roleARN(roleARN)
                .minCapacity(5)
                .maxCapacity(10)
                .build();

            appAutoScalingClient.registerScalableTarget(targetRequest);
            System.out.println("You have registered " + tableId);

        } catch (ApplicationAutoScalingException e) {
            System.err.println(e.awsErrorDetails().errorMessage());
        }
    }

    // Verify that the target was created.
    public static void verifyTarget(ApplicationAutoScalingClient appAutoScalingClient, String tableId, ServiceNamespace ns, ScalableDimension tableWCUs) {
        DescribeScalableTargetsRequest dscRequest = DescribeScalableTargetsRequest.builder()
            .scalableDimension(tableWCUs)
            .serviceNamespace(ns)
            .resourceIds(tableId)
            .build();

        DescribeScalableTargetsResponse response = appAutoScalingClient.describeScalableTargets(dscRequest);
        System.out.println("DescribeScalableTargets result: ");
        System.out.println(response);
    }

    // Configure a scaling policy.
    public static void configureScalingPolicy(ApplicationAutoScalingClient appAutoScalingClient, String tableId, ServiceNamespace ns, ScalableDimension tableWCUs, String policyName) {
        // Check if the policy exists before creating a new one.
        DescribeScalingPoliciesResponse describeScalingPoliciesResponse = appAutoScalingClient.describeScalingPolicies(DescribeScalingPoliciesRequest.builder()
            .serviceNamespace(ns)
            .resourceId(tableId)
            .scalableDimension(tableWCUs)
            .build());

        if (!describeScalingPoliciesResponse.scalingPolicies().isEmpty()) {
            // If policies exist, consider updating an existing policy instead of creating a new one.
            System.out.println("Policy already exists. Consider updating it instead.");
            List<ScalingPolicy> polList = describeScalingPoliciesResponse.scalingPolicies();
            for (ScalingPolicy pol : polList) {
                System.out.println("Policy name:" +pol.policyName());
            }
        } else {
            // If no policies exist, proceed with creating a new policy.
            PredefinedMetricSpecification specification = PredefinedMetricSpecification.builder()
                .predefinedMetricType(MetricType.DYNAMO_DB_WRITE_CAPACITY_UTILIZATION)
                .build();

            TargetTrackingScalingPolicyConfiguration policyConfiguration = TargetTrackingScalingPolicyConfiguration.builder()
                .predefinedMetricSpecification(specification)
                .targetValue(50.0)
                .scaleInCooldown(60)
                .scaleOutCooldown(60)
                .build();

            PutScalingPolicyRequest putScalingPolicyRequest = PutScalingPolicyRequest.builder()
                .targetTrackingScalingPolicyConfiguration(policyConfiguration)
                .serviceNamespace(ns)
                .scalableDimension(tableWCUs)
                .resourceId(tableId)
                .policyName(policyName)
                .policyType(PolicyType.TARGET_TRACKING_SCALING)
                .build();

            try {
                appAutoScalingClient.putScalingPolicy(putScalingPolicyRequest);
                System.out.println("You have successfully created a scaling policy for an Application Auto Scaling scalable target");
            } catch (ApplicationAutoScalingException e) {
                System.err.println("Error: " + e.awsErrorDetails().errorMessage());
            }
        }
    }
}
```

------
#### [ Java v1 ]

El programa requiere que se suministre el nombre de recurso de Amazon (ARN) de un rol vinculado a un servicio de Auto Scaling de aplicaciones válido. (Por ejemplo: `arn:aws:iam::122517410325:role/AWSServiceRoleForApplicationAutoScaling_DynamoDBTable`.) En el siguiente programa, sustituya `SERVICE_ROLE_ARN_GOES_HERE` por el ARN real. 

```
package com.amazonaws.codesamples.autoscaling;

import com.amazonaws.services.applicationautoscaling.AWSApplicationAutoScalingClient;
import com.amazonaws.services.applicationautoscaling.AWSApplicationAutoScalingClientBuilder;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalableTargetsRequest;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalableTargetsResult;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalingPoliciesRequest;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalingPoliciesResult;
import com.amazonaws.services.applicationautoscaling.model.MetricType;
import com.amazonaws.services.applicationautoscaling.model.PolicyType;
import com.amazonaws.services.applicationautoscaling.model.PredefinedMetricSpecification;
import com.amazonaws.services.applicationautoscaling.model.PutScalingPolicyRequest;
import com.amazonaws.services.applicationautoscaling.model.RegisterScalableTargetRequest;
import com.amazonaws.services.applicationautoscaling.model.ScalableDimension;
import com.amazonaws.services.applicationautoscaling.model.ServiceNamespace;
import com.amazonaws.services.applicationautoscaling.model.TargetTrackingScalingPolicyConfiguration;

public class EnableDynamoDBAutoscaling {

	static AWSApplicationAutoScalingClient aaClient = (AWSApplicationAutoScalingClient) AWSApplicationAutoScalingClientBuilder
			.standard().build();

	public static void main(String args[]) {

		ServiceNamespace ns = ServiceNamespace.Dynamodb;
		ScalableDimension tableWCUs = ScalableDimension.DynamodbTableWriteCapacityUnits;
		String resourceID = "table/TestTable";

		// Define the scalable target
		RegisterScalableTargetRequest rstRequest = new RegisterScalableTargetRequest()
				.withServiceNamespace(ns)
				.withResourceId(resourceID)
				.withScalableDimension(tableWCUs)
				.withMinCapacity(5)
				.withMaxCapacity(10)
				.withRoleARN("SERVICE_ROLE_ARN_GOES_HERE");

		try {
			aaClient.registerScalableTarget(rstRequest);
		} catch (Exception e) {
			System.err.println("Unable to register scalable target: ");
			System.err.println(e.getMessage());
		}

		// Verify that the target was created
		DescribeScalableTargetsRequest dscRequest = new DescribeScalableTargetsRequest()
				.withServiceNamespace(ns)
				.withScalableDimension(tableWCUs)
				.withResourceIds(resourceID);
		try {
			DescribeScalableTargetsResult dsaResult = aaClient.describeScalableTargets(dscRequest);
			System.out.println("DescribeScalableTargets result: ");
			System.out.println(dsaResult);
			System.out.println();
		} catch (Exception e) {
			System.err.println("Unable to describe scalable target: ");
			System.err.println(e.getMessage());
		}

		System.out.println();

		// Configure a scaling policy
		TargetTrackingScalingPolicyConfiguration targetTrackingScalingPolicyConfiguration = new TargetTrackingScalingPolicyConfiguration()
				.withPredefinedMetricSpecification(
						new PredefinedMetricSpecification()
								.withPredefinedMetricType(MetricType.DynamoDBWriteCapacityUtilization))
				.withTargetValue(50.0)
				.withScaleInCooldown(60)
				.withScaleOutCooldown(60);

		// Create the scaling policy, based on your configuration
		PutScalingPolicyRequest pspRequest = new PutScalingPolicyRequest()
				.withServiceNamespace(ns)
				.withScalableDimension(tableWCUs)
				.withResourceId(resourceID)
				.withPolicyName("MyScalingPolicy")
				.withPolicyType(PolicyType.TargetTrackingScaling)
				.withTargetTrackingScalingPolicyConfiguration(targetTrackingScalingPolicyConfiguration);

		try {
			aaClient.putScalingPolicy(pspRequest);
		} catch (Exception e) {
			System.err.println("Unable to put scaling policy: ");
			System.err.println(e.getMessage());
		}

		// Verify that the scaling policy was created
		DescribeScalingPoliciesRequest dspRequest = new DescribeScalingPoliciesRequest()
				.withServiceNamespace(ns)
				.withScalableDimension(tableWCUs)
				.withResourceId(resourceID);

		try {
			DescribeScalingPoliciesResult dspResult = aaClient.describeScalingPolicies(dspRequest);
			System.out.println("DescribeScalingPolicies result: ");
			System.out.println(dspResult);
		} catch (Exception e) {
			e.printStackTrace();
			System.err.println("Unable to describe scaling policy: ");
			System.err.println(e.getMessage());
		}

	}

}
```

------

## Desactivación de Auto Scaling de aplicaciones para una tabla
<a name="AutoScaling.HowTo.SDK-disable"></a>

En el siguiente programa se invierte el proceso anterior. Se elimina la política de escalado automático y, a continuación, se anula el registro del objetivo escalable.

------
#### [ Java v2 ]

```
import software.amazon.awssdk.regions.Region;
import software.amazon.awssdk.services.applicationautoscaling.ApplicationAutoScalingClient;
import software.amazon.awssdk.services.applicationautoscaling.model.ApplicationAutoScalingException;
import software.amazon.awssdk.services.applicationautoscaling.model.DeleteScalingPolicyRequest;
import software.amazon.awssdk.services.applicationautoscaling.model.DeregisterScalableTargetRequest;
import software.amazon.awssdk.services.applicationautoscaling.model.DescribeScalableTargetsRequest;
import software.amazon.awssdk.services.applicationautoscaling.model.DescribeScalableTargetsResponse;
import software.amazon.awssdk.services.applicationautoscaling.model.DescribeScalingPoliciesRequest;
import software.amazon.awssdk.services.applicationautoscaling.model.DescribeScalingPoliciesResponse;
import software.amazon.awssdk.services.applicationautoscaling.model.ScalableDimension;
import software.amazon.awssdk.services.applicationautoscaling.model.ServiceNamespace;

/**
 * Before running this Java V2 code example, set up your development environment, including your credentials.
 *
 * For more information, see the following documentation topic:
 *
 * https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/get-started.html
 */

public class DisableDynamoDBAutoscaling {
    public static void main(String[] args) {
        final String usage = """

            Usage:
               <tableId> <policyName>\s

            Where:
               tableId - The table Id value (for example, table/Music).\s
               policyName - The name of the policy (for example, $Music5-scaling-policy). 
        
            """;
        if (args.length != 2) {
            System.out.println(usage);
            System.exit(1);
        }

        ApplicationAutoScalingClient appAutoScalingClient = ApplicationAutoScalingClient.builder()
            .region(Region.US_EAST_1)
            .build();

        ServiceNamespace ns = ServiceNamespace.DYNAMODB;
        ScalableDimension tableWCUs = ScalableDimension.DYNAMODB_TABLE_WRITE_CAPACITY_UNITS;
        String tableId = args[0];
        String policyName = args[1];

        deletePolicy(appAutoScalingClient, policyName, tableWCUs, ns, tableId);
        verifyScalingPolicies(appAutoScalingClient, tableId, ns, tableWCUs);
        deregisterScalableTarget(appAutoScalingClient, tableId, ns, tableWCUs);
        verifyTarget(appAutoScalingClient, tableId, ns, tableWCUs);
    }

    public static void deletePolicy(ApplicationAutoScalingClient appAutoScalingClient, String policyName, ScalableDimension tableWCUs, ServiceNamespace ns, String tableId) {
        try {
            DeleteScalingPolicyRequest delSPRequest = DeleteScalingPolicyRequest.builder()
                .policyName(policyName)
                .scalableDimension(tableWCUs)
                .serviceNamespace(ns)
                .resourceId(tableId)
                .build();

            appAutoScalingClient.deleteScalingPolicy(delSPRequest);
            System.out.println(policyName +" was deleted successfully.");

        } catch (ApplicationAutoScalingException e) {
            System.err.println(e.awsErrorDetails().errorMessage());
        }
    }

    // Verify that the scaling policy was deleted
    public static void verifyScalingPolicies(ApplicationAutoScalingClient appAutoScalingClient, String tableId, ServiceNamespace ns, ScalableDimension tableWCUs) {
        DescribeScalingPoliciesRequest dscRequest = DescribeScalingPoliciesRequest.builder()
            .scalableDimension(tableWCUs)
            .serviceNamespace(ns)
            .resourceId(tableId)
            .build();

        DescribeScalingPoliciesResponse response = appAutoScalingClient.describeScalingPolicies(dscRequest);
        System.out.println("DescribeScalableTargets result: ");
        System.out.println(response);
    }

    public static void deregisterScalableTarget(ApplicationAutoScalingClient appAutoScalingClient, String tableId, ServiceNamespace ns, ScalableDimension tableWCUs) {
        try {
            DeregisterScalableTargetRequest targetRequest = DeregisterScalableTargetRequest.builder()
                .scalableDimension(tableWCUs)
                .serviceNamespace(ns)
                .resourceId(tableId)
                .build();

            appAutoScalingClient.deregisterScalableTarget(targetRequest);
            System.out.println("The scalable target was deregistered.");

        } catch (ApplicationAutoScalingException e) {
            System.err.println(e.awsErrorDetails().errorMessage());
        }
    }

    public static void verifyTarget(ApplicationAutoScalingClient appAutoScalingClient, String tableId, ServiceNamespace ns, ScalableDimension tableWCUs) {
        DescribeScalableTargetsRequest dscRequest = DescribeScalableTargetsRequest.builder()
            .scalableDimension(tableWCUs)
            .serviceNamespace(ns)
            .resourceIds(tableId)
            .build();

        DescribeScalableTargetsResponse response = appAutoScalingClient.describeScalableTargets(dscRequest);
        System.out.println("DescribeScalableTargets result: ");
        System.out.println(response);
    }
}
```

------
#### [ Java v1 ]

```
package com.amazonaws.codesamples.autoscaling;

import com.amazonaws.services.applicationautoscaling.AWSApplicationAutoScalingClient;
import com.amazonaws.services.applicationautoscaling.model.DeleteScalingPolicyRequest;
import com.amazonaws.services.applicationautoscaling.model.DeregisterScalableTargetRequest;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalableTargetsRequest;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalableTargetsResult;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalingPoliciesRequest;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalingPoliciesResult;
import com.amazonaws.services.applicationautoscaling.model.ScalableDimension;
import com.amazonaws.services.applicationautoscaling.model.ServiceNamespace;

public class DisableDynamoDBAutoscaling {

	static AWSApplicationAutoScalingClient aaClient = new AWSApplicationAutoScalingClient();

	public static void main(String args[]) {

		ServiceNamespace ns = ServiceNamespace.Dynamodb;
		ScalableDimension tableWCUs = ScalableDimension.DynamodbTableWriteCapacityUnits;
		String resourceID = "table/TestTable";

		// Delete the scaling policy
		DeleteScalingPolicyRequest delSPRequest = new DeleteScalingPolicyRequest()
				.withServiceNamespace(ns)
				.withScalableDimension(tableWCUs)
				.withResourceId(resourceID)
				.withPolicyName("MyScalingPolicy");

		try {
			aaClient.deleteScalingPolicy(delSPRequest);
		} catch (Exception e) {
			System.err.println("Unable to delete scaling policy: ");
			System.err.println(e.getMessage());
		}

		// Verify that the scaling policy was deleted
		DescribeScalingPoliciesRequest descSPRequest = new DescribeScalingPoliciesRequest()
				.withServiceNamespace(ns)
				.withScalableDimension(tableWCUs)
				.withResourceId(resourceID);

		try {
			DescribeScalingPoliciesResult dspResult = aaClient.describeScalingPolicies(descSPRequest);
			System.out.println("DescribeScalingPolicies result: ");
			System.out.println(dspResult);
		} catch (Exception e) {
			e.printStackTrace();
			System.err.println("Unable to describe scaling policy: ");
			System.err.println(e.getMessage());
		}

		System.out.println();

		// Remove the scalable target
		DeregisterScalableTargetRequest delSTRequest = new DeregisterScalableTargetRequest()
				.withServiceNamespace(ns)
				.withScalableDimension(tableWCUs)
				.withResourceId(resourceID);

		try {
			aaClient.deregisterScalableTarget(delSTRequest);
		} catch (Exception e) {
			System.err.println("Unable to deregister scalable target: ");
			System.err.println(e.getMessage());
		}

		// Verify that the scalable target was removed
		DescribeScalableTargetsRequest dscRequest = new DescribeScalableTargetsRequest()
				.withServiceNamespace(ns)
				.withScalableDimension(tableWCUs)
				.withResourceIds(resourceID);

		try {
			DescribeScalableTargetsResult dsaResult = aaClient.describeScalableTargets(dscRequest);
			System.out.println("DescribeScalableTargets result: ");
			System.out.println(dsaResult);
			System.out.println();
		} catch (Exception e) {
			System.err.println("Unable to describe scalable target: ");
			System.err.println(e.getMessage());
		}

	}

}
```

------

# Capacidad reservada de DynamoDB
<a name="reserved-capacity"></a>

En el caso de las tablas de capacidad aprovisionada que utilizan la [clase de tabla](HowItWorks.TableClasses.md) estándar, DynamoDB ofrece la posibilidad de comprar capacidad reservada para la capacidad de lectura y escritura. La compra de capacidad reservada es un acuerdo por el que se paga una cantidad mínima de capacidad de rendimiento aprovisionada durante el período de vigencia del acuerdo, a cambio de descuentos en los precios.

**nota**  
No puede adquirir capacidad reservada para las unidades de capacidad de escritura replicadas (rWCU). La capacidad reservada solo se aplica a la región en la que se compró. La capacidad reservada tampoco está disponible para tablas que utilizan la clase de tabla DynamoDB Standard - IA o el modo de capacidad bajo demanda.

La capacidad reservada se adquiere en asignaciones de 100 WCU o 100 RCU. La oferta de capacidad reservada más pequeña es de 100 unidades de capacidad (lectura o escritura). La capacidad reservada de DynamoDB se ofrece con un compromiso de un año o, en determinadas regiones, de tres años. Puede disfrutar de un ahorro de hasta el 54 % sobre las tarifas estándar con el compromiso de un año y de un 77 % sobre las tarifas estándar en el de tres años. Para obtener más información sobre cómo y cuándo debería adquirirlos, consulte [Amazon DynamoDB Reserved Capacity](https://aws.amazon.com/dynamodb/reserved-capacity/).

**nota**  
A través de la consola de administración de AWS, puede adquirir hasta un total de 1 000 000 de unidades de capacidad reservada, entre unidades de capacidad de escritura (WCU) y unidades de capacidad de lectura (RCU). Si desea adquirir más de 1 000 000 de unidades de capacidad aprovisionada en una sola compra, o si ya dispone de capacidad reservada activa y desea adquirir capacidad reservada adicional que suponga superar las 1 000 000 de unidades de capacidad aprovisionada activas, siga el procedimiento descrito en la sección “Cómo adquirir capacidad reservada” de [Capacidad reservada de Amazon DynamoDB](https://aws.amazon.com/dynamodb/reserved-capacity/).

Cuando se adquiere capacidad reservada de DynamoDB, realiza un único pago parcial por adelantado y recibe una tarifa por hora con descuento por el uso aprovisionado comprometido. Se paga por todo el uso aprovisionado comprometido, independientemente del uso real, por lo que el ahorro de costos depende enormemente del uso. Cualquier capacidad que aprovisione que supere la capacidad reservada adquirida se cobrará a la tarifa de capacidad aprovisionada estándar. Al reservar las unidades de capacidad de lectura y escritura por adelantado, logrará un ahorro importante en los costos de capacidad aprovisionada.

No puede vender, cancelar ni transferir la capacidad reservada a otra región o cuenta.

# Descripción del rendimiento en caliente de DynamoDB
<a name="warm-throughput"></a>

El *rendimiento en caliente* se refiere al número de operaciones de lectura y escritura que la tabla de DynamoDB puede admitir de modo instantáneo. Estos valores están disponibles de manera predeterminada para todas las tablas y los índices secundarios globales (GSI) y representan cuánto han escalado en función del uso histórico. Si utiliza el modo bajo demanda, o si actualiza el rendimiento aprovisionado a estos valores, la aplicación podrá emitir solicitudes hasta esos valores de forma instantánea.

DynamoDB ajustará automáticamente los valores de rendimiento en caliente a medida que aumente el uso. También puede aumentar estos valores de forma proactiva cuando sea necesario, lo que resulta especialmente útil en los picos de eventos próximos, como lanzamientos de productos o ventas. En el caso de eventos de pico planificados, en los que las tasas de solicitudes para la tabla de DynamoDB podrían aumentar 10 veces, 100 veces o más, ahora puede evaluar si el rendimiento en caliente actual es suficiente para gestionar el tráfico previsto. Si no es así, puede aumentar el valor de rendimiento en caliente sin cambiar la configuración de rendimiento ni el [modo de facturación](capacity-mode.md). Este proceso se denomina *precalentamiento* de una tabla, lo que le permite establecer una línea de base que las tablas pueden admitir al instante. Esto garantiza que las aplicaciones puedan manejar tasas de solicitudes más elevadas desde el momento en que se produzcan. Una vez aumentados, los valores de rendimiento en caliente no se pueden reducir.

Puede aumentar el valor de rendimiento en caliente en el caso de las operaciones de lectura, escritura o ambas. Puede aumentar este valor para las tablas de una sola región, las tablas globales y los GSI nuevos y existentes. En el caso de las tablas globales, esta característica está disponible para la [versión 2019.11.21 (actual)](GlobalTables.md) y la configuración de rendimiento en caliente que establezca se aplicará de forma automática a todas las tablas de réplica de la tabla global. No hay límite en el número de tablas de DynamoDB a las que puede aplicar el precalentamiento en cualquier momento. El tiempo necesario para completar el precalentamiento depende de los valores que establezca y del tamaño de la tabla o el índice. Puede presentar solicitudes de precalentamiento simultáneas y no interferirán en ninguna operación de tabla. Puede precalentar la tabla hasta el límite de cuota de tabla o índice de la cuenta en esa región. Utilice la [consola de Service Quotas](https://console.aws.amazon.com/servicequotas) para comprobar los límites actuales y aumentarlos si es necesario. 

Los valores de rendimiento en caliente están disponibles de forma predeterminada para todas las tablas y los índices secundarios sin costo alguno. No obstante, si aumenta de forma proactiva estos valores de rendimiento en caliente predeterminados para precalentar las tablas, se le cobrarán esas solicitudes. Para obtener más información, consulte los precios de [Amazon DynamoDB](https://aws.amazon.com/dynamodb/pricing/).

Para obtener más información sobre el rendimiento en caliente, consulte los temas siguientes:

**Topics**
+ [Comprobación del rendimiento en caliente actual de la tabla de DynamoDB](check-warm-throughput.md)
+ [Aumento del rendimiento en caliente de la tabla de DynamoDB existente](update-warm-throughput.md)
+ [Creación de una tabla de DynamoDB nueva con rendimiento en caliente más alto](create-table-warm-throughput.md)
+ [Descripción del rendimiento en caliente de DynamoDB en diferentes escenarios](warm-throughput-scenarios.md)

# Comprobación del rendimiento en caliente actual de la tabla de DynamoDB
<a name="check-warm-throughput"></a>

Utilice las siguientes instrucciones de la AWS CLI y de la consola de AWS para comprobar el valor actual de rendimiento en caliente de la tabla o el índice.

## Consola de administración de AWS
<a name="warm-throughput-check-console"></a>

Para comprobar el rendimiento en caliente de la tabla de DynamoDB con la consola de DynamoDB:

1. Inicie sesión en la Consola de administración de AWS y abra la consola de DynamoDB en [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/).

1. En el panel de navegación izquierdo, elija Tables (Tablas).

1. En la página **Tablas**, elija la tabla que desee.

1. Seleccione **Configuración** para ver el valor de rendimiento en caliente actual. Este valor se muestra como unidades de lectura por segundo y unidades de escritura por segundo.

## AWS CLI
<a name="warm-throughput-check-CLI"></a>

En el siguiente ejemplo de la AWS CLI se muestra cómo comprobar el rendimiento en caliente de la tabla de DynamoDB.

1. Ejecute la operación `describe-table` en la tabla de DynamoDB.

   ```
   aws dynamodb describe-table --table-name GameScores
   ```

1. Verá una respuesta similar a la siguiente. La configuración de `WarmThroughput` se mostrará como `ReadUnitsPerSecond` y `WriteUnitsPerSecond`. El `Status` será `UPDATING` cuando se actualice el valor de rendimiento en caliente y `ACTIVE` cuando se establezca el nuevo valor de rendimiento en caliente.

   ```
   {
       "Table": {
           "AttributeDefinitions": [
               {
                   "AttributeName": "GameTitle",
                   "AttributeType": "S"
               },
               {
                   "AttributeName": "TopScore",
                   "AttributeType": "N"
               },
               {
                   "AttributeName": "UserId",
                   "AttributeType": "S"
               }
           ],
           "TableName": "GameScores",
           "KeySchema": [
               {
                   "AttributeName": "UserId",
                   "KeyType": "HASH"
               },
               {
                   "AttributeName": "GameTitle",
                   "KeyType": "RANGE"
               }
           ],
           "TableStatus": "ACTIVE",
           "CreationDateTime": 1726128388.729,
           "ProvisionedThroughput": {
               "NumberOfDecreasesToday": 0,
               "ReadCapacityUnits": 0,
               "WriteCapacityUnits": 0
           },
           "TableSizeBytes": 0,
           "ItemCount": 0,
           "TableArn": "arn:aws:dynamodb:us-east-1:XXXXXXXXXXXX:table/GameScores",
           "TableId": "XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
           "BillingModeSummary": {
               "BillingMode": "PAY_PER_REQUEST",
               "LastUpdateToPayPerRequestDateTime": 1726128388.729
           },
           "GlobalSecondaryIndexes": [
               {
                   "IndexName": "GameTitleIndex",
                   "KeySchema": [
                       {
                           "AttributeName": "GameTitle",
                           "KeyType": "HASH"
                       },
                       {
                           "AttributeName": "TopScore",
                           "KeyType": "RANGE"
                       }
                   ],
                   "Projection": {
                       "ProjectionType": "INCLUDE",
                       "NonKeyAttributes": [
                           "UserId"
                       ]
                   },
                   "IndexStatus": "ACTIVE",
                   "ProvisionedThroughput": {
                       "NumberOfDecreasesToday": 0,
                       "ReadCapacityUnits": 0,
                       "WriteCapacityUnits": 0
                   },
                   "IndexSizeBytes": 0,
                   "ItemCount": 0,
                   "IndexArn": "arn:aws:dynamodb:us-east-1:XXXXXXXXXXXX:table/GameScores/index/GameTitleIndex",
                   "WarmThroughput": {
                       "ReadUnitsPerSecond": 12000,
                       "WriteUnitsPerSecond": 4000,
                       "Status": "ACTIVE"
                   }
               }
           ],
           "DeletionProtectionEnabled": false,
           "WarmThroughput": {
               "ReadUnitsPerSecond": 12000,
               "WriteUnitsPerSecond": 4000,
               "Status": "ACTIVE"
           }
       }
   }
   ```

# Aumento del rendimiento en caliente de la tabla de DynamoDB existente
<a name="update-warm-throughput"></a>

Una vez que haya comprobado el valor actual de rendimiento en caliente de la tabla de DynamoDB, puede actualizarlo con los siguientes pasos:

## Consola de administración de AWS
<a name="warm-throughput-update-console"></a>

Para comprobar el valor de rendimiento en caliente de la tabla de DynamoDB mediante la consola de DynamoDB:

1. Inicie sesión en la Consola de administración de AWS y abra la consola de DynamoDB en [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/).

1. En el panel de navegación izquierdo, elija Tables (Tablas).

1. En la página **Tablas**, elija la tabla que desee.

1. En el campo **Rendimiento en caliente**, seleccione **Editar**.

1. En la página **Editar rendimiento en caliente**, seleccione **Aumentar el rendimiento en caliente**.

1. Ajuste las **unidades de lectura por segundo** y las **unidades de escritura por segundo**. Estas dos configuraciones definen el rendimiento que la tabla puede gestionar al instante.

1. Seleccione **Guardar**.

1. Las **unidades de lectura por segundo** y las **unidades de escritura por segundo** se actualizarán en el campo **Rendimiento en caliente** cuando la solicitud termine de procesarse.
**nota**  
La actualización del valor de rendimiento en caliente es una tarea asíncrona. El `Status` cambiará de `UPDATING` a `ACTIVE` cuando se complete la actualización.

## AWS CLI
<a name="warm-throughput-update-CLI"></a>

En el siguiente ejemplo de la AWS CLI se muestra cómo actualizar el valor de rendimiento en caliente de la tabla de DynamoDB.

1. Ejecute la operación `update-table` en la tabla de DynamoDB.

   ```
   aws dynamodb update-table \
       --table-name GameScores \
       --warm-throughput ReadUnitsPerSecond=12345,WriteUnitsPerSecond=4567 \
       --global-secondary-index-updates \
           "[
               {
                   \"Update\": {
                       \"IndexName\": \"GameTitleIndex\",
                       \"WarmThroughput\": {
                           \"ReadUnitsPerSecond\": 88,
                           \"WriteUnitsPerSecond\": 77
                       }
                   }
               }
           ]" \
       --region us-east-1
   ```

1. Verá una respuesta similar a la siguiente. La configuración de `WarmThroughput` se mostrará como `ReadUnitsPerSecond` y `WriteUnitsPerSecond`. El `Status` será `UPDATING` cuando se actualice el valor de rendimiento en caliente y `ACTIVE` cuando se establezca el nuevo valor de rendimiento en caliente.

   ```
   {
       "TableDescription": {
           "AttributeDefinitions": [
               {
                   "AttributeName": "GameTitle",
                   "AttributeType": "S"
               },
               {
                   "AttributeName": "TopScore",
                   "AttributeType": "N"
               },
               {
                   "AttributeName": "UserId",
                   "AttributeType": "S"
               }
           ],
           "TableName": "GameScores",
           "KeySchema": [
               {
                   "AttributeName": "UserId",
                   "KeyType": "HASH"
               },
               {
                   "AttributeName": "GameTitle",
                   "KeyType": "RANGE"
               }
           ],
           "TableStatus": "ACTIVE",
           "CreationDateTime": 1730242189.965,
           "ProvisionedThroughput": {
               "NumberOfDecreasesToday": 0,
               "ReadCapacityUnits": 20,
               "WriteCapacityUnits": 10
           },
           "TableSizeBytes": 0,
           "ItemCount": 0,
           "TableArn": "arn:aws:dynamodb:us-east-1:XXXXXXXXXXXX:table/GameScores",
           "TableId": "XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
           "GlobalSecondaryIndexes": [
               {
                   "IndexName": "GameTitleIndex",
                   "KeySchema": [
                       {
                           "AttributeName": "GameTitle",
                           "KeyType": "HASH"
                       },
                       {
                           "AttributeName": "TopScore",
                           "KeyType": "RANGE"
                       }
                   ],
                   "Projection": {
                       "ProjectionType": "INCLUDE",
                       "NonKeyAttributes": [
                           "UserId"
                       ]
                   },
                   "IndexStatus": "ACTIVE",
                   "ProvisionedThroughput": {
                       "NumberOfDecreasesToday": 0,
                       "ReadCapacityUnits": 50,
                       "WriteCapacityUnits": 25
                   },
                   "IndexSizeBytes": 0,
                   "ItemCount": 0,
                   "IndexArn": "arn:aws:dynamodb:us-east-1:XXXXXXXXXXXX:table/GameScores/index/GameTitleIndex",
                   "WarmThroughput": {
                       "ReadUnitsPerSecond": 50,
                       "WriteUnitsPerSecond": 25,
                       "Status": "UPDATING"
                   }
               }
           ],
           "DeletionProtectionEnabled": false,
           "WarmThroughput": {
               "ReadUnitsPerSecond": 12300,
               "WriteUnitsPerSecond": 4500,
               "Status": "UPDATING"
           }
       }
   }
   ```

## AWS SDK
<a name="warm-throughput-update-SDK"></a>

En los siguientes ejemplos del SDK se muestra cómo actualizar el valor de rendimiento en caliente de la tabla de DynamoDB.

------
#### [ Java ]

```
import software.amazon.awssdk.services.dynamodb.DynamoDbClient;
import software.amazon.awssdk.services.dynamodb.model.DynamoDbException;
import software.amazon.awssdk.services.dynamodb.model.GlobalSecondaryIndexUpdate;
import software.amazon.awssdk.services.dynamodb.model.UpdateGlobalSecondaryIndexAction;
import software.amazon.awssdk.services.dynamodb.model.UpdateTableRequest;
import software.amazon.awssdk.services.dynamodb.model.WarmThroughput;

...
public static WarmThroughput buildWarmThroughput(final Long readUnitsPerSecond,
                                                 final Long writeUnitsPerSecond) {
    return WarmThroughput.builder()
            .readUnitsPerSecond(readUnitsPerSecond)
            .writeUnitsPerSecond(writeUnitsPerSecond)
            .build();
}

public static void updateDynamoDBTable(DynamoDbClient ddb,
                                       String tableName,
                                       Long tableReadUnitsPerSecond,
                                       Long tableWriteUnitsPerSecond,
                                       String globalSecondaryIndexName,
                                       Long globalSecondaryIndexReadUnitsPerSecond,
                                       Long globalSecondaryIndexWriteUnitsPerSecond) {

    final WarmThroughput tableWarmThroughput = buildWarmThroughput(tableReadUnitsPerSecond, tableWriteUnitsPerSecond);
    final WarmThroughput gsiWarmThroughput = buildWarmThroughput(globalSecondaryIndexReadUnitsPerSecond, globalSecondaryIndexWriteUnitsPerSecond);

    final GlobalSecondaryIndexUpdate globalSecondaryIndexUpdate = GlobalSecondaryIndexUpdate.builder()
            .update(UpdateGlobalSecondaryIndexAction.builder()
                    .indexName(globalSecondaryIndexName)
                    .warmThroughput(gsiWarmThroughput)
                    .build()
            ).build();

    final UpdateTableRequest request = UpdateTableRequest.builder()
            .tableName(tableName)
            .globalSecondaryIndexUpdates(globalSecondaryIndexUpdate)
            .warmThroughput(tableWarmThroughput)
            .build();

    try {
        ddb.updateTable(request);
    } catch (DynamoDbException e) {
        System.err.println(e.getMessage());
        System.exit(1);
    }

    System.out.println("Done!");
}
```

------
#### [ Python ]

```
from boto3 import resource
from botocore.exceptions import ClientError

def update_dynamodb_table_warm_throughput(table_name, table_read_units, table_write_units, gsi_name, gsi_read_units, gsi_write_units, region_name="us-east-1"):
    """
    Updates the warm throughput of a DynamoDB table and a global secondary index.

    :param table_name: The name of the table to update.
    :param table_read_units: The new read units per second for the table's warm throughput.
    :param table_write_units: The new write units per second for the table's warm throughput.
    :param gsi_name: The name of the global secondary index to update.
    :param gsi_read_units: The new read units per second for the GSI's warm throughput.
    :param gsi_write_units: The new write units per second for the GSI's warm throughput.
    :param region_name: The AWS Region name to target. defaults to us-east-1
    """
    try:
        ddb = resource('dynamodb', region_name)
        
        # Update the table's warm throughput
        table_warm_throughput = {
            "ReadUnitsPerSecond": table_read_units,
            "WriteUnitsPerSecond": table_write_units
        }

        # Update the global secondary index's warm throughput
        gsi_warm_throughput = {
            "ReadUnitsPerSecond": gsi_read_units,
            "WriteUnitsPerSecond": gsi_write_units
        }

        # Construct the global secondary index update
        global_secondary_index_update = [
            {
                "Update": {
                    "IndexName": gsi_name,
                    "WarmThroughput": gsi_warm_throughput
                }
            }
        ]

        # Construct the update table request
        update_table_request = {
            "TableName": table_name,
            "GlobalSecondaryIndexUpdates": global_secondary_index_update,
            "WarmThroughput": table_warm_throughput
        }

        # Update the table
        ddb.update_table(**update_table_request)
        print("Table updated successfully!")
    except ClientError as e:
        print(f"Error updating table: {e}")
        raise e
```

------
#### [ Javascript ]

```
import { DynamoDBClient, UpdateTableCommand } from "@aws-sdk/client-dynamodb";

async function updateDynamoDBTableWarmThroughput(
  tableName,
  tableReadUnits,
  tableWriteUnits,
  gsiName,
  gsiReadUnits,
  gsiWriteUnits,
  region = "us-east-1"
) {
  try {
    const ddbClient = new DynamoDBClient({ region: region });

    // Construct the update table request
    const updateTableRequest = {
      TableName: tableName,
      GlobalSecondaryIndexUpdates: [
        {
            Update: {
                IndexName: gsiName,
                WarmThroughput: {
                    ReadUnitsPerSecond: gsiReadUnits,
                    WriteUnitsPerSecond: gsiWriteUnits,
                },
            },
        },
      ],
      WarmThroughput: {
          ReadUnitsPerSecond: tableReadUnits,
          WriteUnitsPerSecond: tableWriteUnits,
      },
    };

    const command = new UpdateTableCommand(updateTableRequest);
    const response = await ddbClient.send(command);
    console.log(`Table updated successfully! Response: ${response}`);
  } catch (error) {
    console.error(`Error updating table: ${error}`);
    throw error;
  }
}
```

------

# Creación de una tabla de DynamoDB nueva con rendimiento en caliente más alto
<a name="create-table-warm-throughput"></a>

Puede ajustar los valores de rendimiento en caliente cuando cree la tabla de DynamoDB según los pasos que se indican a continuación. Estos pasos también se aplican al crear una [tabla global](GlobalTables.md) o un [índice secundario](SecondaryIndexes.md).

## Consola de administración de AWS
<a name="warm-throughput-create-console"></a>

Para crear una tabla de DynamoDB y ajustar los valores de rendimiento en caliente a través de la consola:

1. Inicie sesión en la Consola de administración de AWS y abra la consola de DynamoDB en [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/).

1. Seleccione **Crear tabla**.

1. Elija un **nombre de tabla**, una **clave de partición** y una **clave de clasificación (opcional)**.

1. En **Configuración de la tabla**, elija **Personalizar configuración**.

1. En el campo **Rendimiento en caliente**, seleccione **Aumentar el rendimiento en caliente**.

1. Ajuste las **unidades de lectura por segundo** y las **unidades de escritura por segundo**. Estas dos configuraciones definen el rendimiento máximo que la tabla puede gestionar al instante.

1. Continúe agregando los detalles de tabla restantes y, a continuación, seleccione **Crear tabla**.

## AWS CLI
<a name="warm-throughput-create-CLI"></a>

En el siguiente ejemplo de la AWS CLI se muestra cómo crear una tabla de DynamoDB con valores de rendimiento en caliente personalizados.

1. Ejecute la operación `create-table` para crear la siguiente tabla de DynamoDB.

   ```
   aws dynamodb create-table \
       --table-name GameScores \
       --attribute-definitions AttributeName=UserId,AttributeType=S \
                               AttributeName=GameTitle,AttributeType=S \
                               AttributeName=TopScore,AttributeType=N  \
       --key-schema AttributeName=UserId,KeyType=HASH \
                    AttributeName=GameTitle,KeyType=RANGE \
       --provisioned-throughput ReadCapacityUnits=20,WriteCapacityUnits=10 \
       --global-secondary-indexes \
           "[
               {
                   \"IndexName\": \"GameTitleIndex\",
                   \"KeySchema\": [{\"AttributeName\":\"GameTitle\",\"KeyType\":\"HASH\"},
                                   {\"AttributeName\":\"TopScore\",\"KeyType\":\"RANGE\"}],
                   \"Projection\":{
                       \"ProjectionType\":\"INCLUDE\",
                       \"NonKeyAttributes\":[\"UserId\"]
                   },
                   \"ProvisionedThroughput\": {
                       \"ReadCapacityUnits\": 50,
                       \"WriteCapacityUnits\": 25
                   },\"WarmThroughput\": {
                       \"ReadUnitsPerSecond\": 1987,
                       \"WriteUnitsPerSecond\": 543
                   }
               }
           ]" \
       --warm-throughput ReadUnitsPerSecond=12345,WriteUnitsPerSecond=4567 \
       --region us-east-1
   ```

1. Verá una respuesta similar a la siguiente. La configuración de `WarmThroughput` se mostrará como `ReadUnitsPerSecond` y `WriteUnitsPerSecond`. El `Status` será `UPDATING` cuando se actualice el valor de rendimiento en caliente y `ACTIVE` cuando se establezca el nuevo valor de rendimiento en caliente.

   ```
   {
       "TableDescription": {
           "AttributeDefinitions": [
               {
                   "AttributeName": "GameTitle",
                   "AttributeType": "S"
               },
               {
                   "AttributeName": "TopScore",
                   "AttributeType": "N"
               },
               {
                   "AttributeName": "UserId",
                   "AttributeType": "S"
               }
           ],
           "TableName": "GameScores",
           "KeySchema": [
               {
                   "AttributeName": "UserId",
                   "KeyType": "HASH"
               },
               {
                   "AttributeName": "GameTitle",
                   "KeyType": "RANGE"
               }
           ],
           "TableStatus": "CREATING",
           "CreationDateTime": 1730241788.779,
           "ProvisionedThroughput": {
               "NumberOfDecreasesToday": 0,
               "ReadCapacityUnits": 20,
               "WriteCapacityUnits": 10
           },
           "TableSizeBytes": 0,
           "ItemCount": 0,
           "TableArn": "arn:aws:dynamodb:us-east-1:XXXXXXXXXXXX:table/GameScores",
           "TableId": "XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
           "GlobalSecondaryIndexes": [
               {
                   "IndexName": "GameTitleIndex",
                   "KeySchema": [
                       {
                           "AttributeName": "GameTitle",
                           "KeyType": "HASH"
                       },
                       {
                           "AttributeName": "TopScore",
                           "KeyType": "RANGE"
                       }
                   ],
                   "Projection": {
                       "ProjectionType": "INCLUDE",
                       "NonKeyAttributes": [
                           "UserId"
                       ]
                   },
                   "IndexStatus": "CREATING",
                   "ProvisionedThroughput": {
                       "NumberOfDecreasesToday": 0,
                       "ReadCapacityUnits": 50,
                       "WriteCapacityUnits": 25
                   },
                   "IndexSizeBytes": 0,
                   "ItemCount": 0,
                   "IndexArn": "arn:aws:dynamodb:us-east-1:XXXXXXXXXXXX:table/GameScores/index/GameTitleIndex",
                   "WarmThroughput": {
                       "ReadUnitsPerSecond": 1987,
                       "WriteUnitsPerSecond": 543,
                       "Status": "UPDATING"
                   }
               }
           ],
           "DeletionProtectionEnabled": false,
           "WarmThroughput": {
               "ReadUnitsPerSecond": 12345,
               "WriteUnitsPerSecond": 4567,
               "Status": "UPDATING"
           }
       }
   }
   ```

## AWS SDK
<a name="warm-throughput-create-SDK"></a>

En los siguientes ejemplos del SDK se muestra cómo crear una tabla de DynamoDB con valores de rendimiento en caliente personalizados.

------
#### [ Java ]

```
import software.amazon.awscdk.services.dynamodb.ProjectionType;
import software.amazon.awssdk.services.dynamodb.DynamoDbClient;
import software.amazon.awssdk.services.dynamodb.model.CreateTableResponse;
import software.amazon.awssdk.services.dynamodb.model.CreateTableRequest;
import software.amazon.awssdk.services.dynamodb.model.KeySchemaElement;
import software.amazon.awssdk.services.dynamodb.model.KeyType;
import software.amazon.awssdk.services.dynamodb.model.ProvisionedThroughput;
import software.amazon.awssdk.services.dynamodb.model.Projection;
import software.amazon.awssdk.services.dynamodb.model.GlobalSecondaryIndex;
import software.amazon.awssdk.services.dynamodb.model.AttributeDefinition;
import software.amazon.awssdk.services.dynamodb.model.ScalarAttributeType;
import software.amazon.awssdk.services.dynamodb.model.WarmThroughput;
...

public static WarmThroughput buildWarmThroughput(final Long readUnitsPerSecond,
                                                 final Long writeUnitsPerSecond) {
    return WarmThroughput.builder()
            .readUnitsPerSecond(readUnitsPerSecond)
            .writeUnitsPerSecond(writeUnitsPerSecond)
            .build();
}
private static AttributeDefinition buildAttributeDefinition(final String attributeName, 
                                                            final ScalarAttributeType scalarAttributeType) {
    return AttributeDefinition.builder()
            .attributeName(attributeName)
            .attributeType(scalarAttributeType)
            .build();
}
private static KeySchemaElement buildKeySchemaElement(final String attributeName, 
                                                      final KeyType keyType) {
    return KeySchemaElement.builder()
            .attributeName(attributeName)
            .keyType(keyType)
            .build();
}
public static void createDynamoDBTable(DynamoDbClient ddb,
                                       String tableName,
                                       String partitionKey,
                                       String sortKey,
                                       String miscellaneousKeyAttribute,
                                       String nonKeyAttribute,
                                       Long tableReadCapacityUnits,
                                       Long tableWriteCapacityUnits,
                                       Long tableWarmReadUnitsPerSecond,
                                       Long tableWarmWriteUnitsPerSecond,
                                       String globalSecondaryIndexName,
                                       Long globalSecondaryIndexReadCapacityUnits,
                                       Long globalSecondaryIndexWriteCapacityUnits,
                                       Long globalSecondaryIndexWarmReadUnitsPerSecond,
                                       Long globalSecondaryIndexWarmWriteUnitsPerSecond) {

    // Define the table attributes
    final AttributeDefinition partitionKeyAttribute = buildAttributeDefinition(partitionKey, ScalarAttributeType.S);
    final AttributeDefinition sortKeyAttribute = buildAttributeDefinition(sortKey, ScalarAttributeType.S);
    final AttributeDefinition miscellaneousKeyAttributeDefinition = buildAttributeDefinition(miscellaneousKeyAttribute, ScalarAttributeType.N);
    final AttributeDefinition[] attributeDefinitions = {partitionKeyAttribute, sortKeyAttribute, miscellaneousKeyAttributeDefinition};

    // Define the table key schema
    final KeySchemaElement partitionKeyElement = buildKeySchemaElement(partitionKey, KeyType.HASH);
    final KeySchemaElement sortKeyElement = buildKeySchemaElement(sortKey, KeyType.RANGE);
    final KeySchemaElement[] keySchema = {partitionKeyElement, sortKeyElement};

    // Define the provisioned throughput for the table
    final ProvisionedThroughput provisionedThroughput = ProvisionedThroughput.builder()
            .readCapacityUnits(tableReadCapacityUnits)
            .writeCapacityUnits(tableWriteCapacityUnits)
            .build();

    // Define the Global Secondary Index (GSI)
    final KeySchemaElement globalSecondaryIndexPartitionKeyElement = buildKeySchemaElement(sortKey, KeyType.HASH);
    final KeySchemaElement globalSecondaryIndexSortKeyElement = buildKeySchemaElement(miscellaneousKeyAttribute, KeyType.RANGE);
    final KeySchemaElement[] gsiKeySchema = {globalSecondaryIndexPartitionKeyElement, globalSecondaryIndexSortKeyElement};

    final Projection gsiProjection = Projection.builder()
            .projectionType(String.valueOf(ProjectionType.INCLUDE))
            .nonKeyAttributes(nonKeyAttribute)
            .build();
    final ProvisionedThroughput gsiProvisionedThroughput = ProvisionedThroughput.builder()
            .readCapacityUnits(globalSecondaryIndexReadCapacityUnits)
            .writeCapacityUnits(globalSecondaryIndexWriteCapacityUnits)
            .build();
    // Define the warm throughput for the Global Secondary Index (GSI)
    final WarmThroughput gsiWarmThroughput = buildWarmThroughput(globalSecondaryIndexWarmReadUnitsPerSecond, globalSecondaryIndexWarmWriteUnitsPerSecond);
    final GlobalSecondaryIndex globalSecondaryIndex = GlobalSecondaryIndex.builder()
            .indexName(globalSecondaryIndexName)
            .keySchema(gsiKeySchema)
            .projection(gsiProjection)
            .provisionedThroughput(gsiProvisionedThroughput)
            .warmThroughput(gsiWarmThroughput)
            .build();

    // Define the warm throughput for the table
    final WarmThroughput tableWarmThroughput = buildWarmThroughput(tableWarmReadUnitsPerSecond, tableWarmWriteUnitsPerSecond);

    final CreateTableRequest request = CreateTableRequest.builder()
            .tableName(tableName)
            .attributeDefinitions(attributeDefinitions)
            .keySchema(keySchema)
            .provisionedThroughput(provisionedThroughput)
            .globalSecondaryIndexes(globalSecondaryIndex)
            .warmThroughput(tableWarmThroughput)
            .build();

    CreateTableResponse response = ddb.createTable(request);
    System.out.println(response);
}
```

------
#### [ Python ]

```
from boto3 import resource
from botocore.exceptions import ClientError

def create_dynamodb_table_warm_throughput(table_name, partition_key, sort_key, misc_key_attr, non_key_attr, table_provisioned_read_units, table_provisioned_write_units, table_warm_reads, table_warm_writes, gsi_name, gsi_provisioned_read_units, gsi_provisioned_write_units, gsi_warm_reads, gsi_warm_writes, region_name="us-east-1"):
    """
    Creates a DynamoDB table with a warm throughput setting configured.

    :param table_name: The name of the table to be created.
    :param partition_key: The partition key for the table being created.
    :param sort_key: The sort key for the table being created.
    :param misc_key_attr: A miscellaneous key attribute for the table being created.
    :param non_key_attr: A non-key attribute for the table being created.
    :param table_provisioned_read_units: The newly created table's provisioned read capacity units.
    :param table_provisioned_write_units: The newly created table's provisioned write capacity units.
    :param table_warm_reads: The read units per second setting for the table's warm throughput.
    :param table_warm_writes: The write units per second setting for the table's warm throughput.
    :param gsi_name: The name of the Global Secondary Index (GSI) to be created on the table.
    :param gsi_provisioned_read_units: The configured Global Secondary Index (GSI) provisioned read capacity units.
    :param gsi_provisioned_write_units: The configured Global Secondary Index (GSI) provisioned write capacity units.
    :param gsi_warm_reads: The read units per second setting for the Global Secondary Index (GSI)'s warm throughput.
    :param gsi_warm_writes: The write units per second setting for the Global Secondary Index (GSI)'s warm throughput.
    :param region_name: The AWS Region name to target. defaults to us-east-1
    """
    try:
        ddb = resource('dynamodb', region_name)
        
        # Define the table attributes
        attribute_definitions = [
            { "AttributeName": partition_key, "AttributeType": "S" },
            { "AttributeName": sort_key, "AttributeType": "S" },
            { "AttributeName": misc_key_attr, "AttributeType": "N" }
        ]
        
        # Define the table key schema
        key_schema = [
            { "AttributeName": partition_key, "KeyType": "HASH" },
            { "AttributeName": sort_key, "KeyType": "RANGE" }
        ]
        
        # Define the provisioned throughput for the table
        provisioned_throughput = {
            "ReadCapacityUnits": table_provisioned_read_units,
            "WriteCapacityUnits": table_provisioned_write_units
        }
        
        # Define the global secondary index
        gsi_key_schema = [
            { "AttributeName": sort_key, "KeyType": "HASH" },
            { "AttributeName": misc_key_attr, "KeyType": "RANGE" }
        ]
        gsi_projection = {
            "ProjectionType": "INCLUDE",
            "NonKeyAttributes": [non_key_attr]
        }
        gsi_provisioned_throughput = {
            "ReadCapacityUnits": gsi_provisioned_read_units,
            "WriteCapacityUnits": gsi_provisioned_write_units
        }
        gsi_warm_throughput = {
            "ReadUnitsPerSecond": gsi_warm_reads,
            "WriteUnitsPerSecond": gsi_warm_writes
        }
        global_secondary_indexes = [
            {
                "IndexName": gsi_name,
                "KeySchema": gsi_key_schema,
                "Projection": gsi_projection,
                "ProvisionedThroughput": gsi_provisioned_throughput,
                "WarmThroughput": gsi_warm_throughput
            }
        ]
        
        # Define the warm throughput for the table
        warm_throughput = {
            "ReadUnitsPerSecond": table_warm_reads,
            "WriteUnitsPerSecond": table_warm_writes
        }
        
        # Create the DynamoDB client and create the table
        response = ddb.create_table(
            TableName=table_name,
            AttributeDefinitions=attribute_definitions,
            KeySchema=key_schema,
            ProvisionedThroughput=provisioned_throughput,
            GlobalSecondaryIndexes=global_secondary_indexes,
            WarmThroughput=warm_throughput
        )
        
        print(response)
    except ClientError as e:
        print(f"Error creating table: {e}")
        raise e
```

------
#### [ Javascript ]

```
import { DynamoDBClient, CreateTableCommand } from "@aws-sdk/client-dynamodb";

async function createDynamoDBTableWithWarmThroughput(
  tableName,
  partitionKey,
  sortKey,
  miscKeyAttr,
  nonKeyAttr,
  tableProvisionedReadUnits,
  tableProvisionedWriteUnits,
  tableWarmReads,
  tableWarmWrites,
  indexName,
  indexProvisionedReadUnits,
  indexProvisionedWriteUnits,
  indexWarmReads,
  indexWarmWrites,
  region = "us-east-1"
) {
  try {
    const ddbClient = new DynamoDBClient({ region: region });
    const command = new CreateTableCommand({
      TableName: tableName,
      AttributeDefinitions: [
          { AttributeName: partitionKey, AttributeType: "S" },
          { AttributeName: sortKey, AttributeType: "S" },
          { AttributeName: miscKeyAttr, AttributeType: "N" },
      ],
      KeySchema: [
          { AttributeName: partitionKey, KeyType: "HASH" },
          { AttributeName: sortKey, KeyType: "RANGE" },
      ],
      ProvisionedThroughput: {
          ReadCapacityUnits: tableProvisionedReadUnits,
          WriteCapacityUnits: tableProvisionedWriteUnits,
      },
      WarmThroughput: {
          ReadUnitsPerSecond: tableWarmReads,
          WriteUnitsPerSecond: tableWarmWrites,
      },
      GlobalSecondaryIndexes: [
          {
            IndexName: indexName,
            KeySchema: [
                { AttributeName: sortKey, KeyType: "HASH" },
                { AttributeName: miscKeyAttr, KeyType: "RANGE" },
            ],
            Projection: {
                ProjectionType: "INCLUDE",
                NonKeyAttributes: [nonKeyAttr],
            },
            ProvisionedThroughput: {
                ReadCapacityUnits: indexProvisionedReadUnits,
                WriteCapacityUnits: indexProvisionedWriteUnits,
            },
            WarmThroughput: {
                ReadUnitsPerSecond: indexWarmReads,
                WriteUnitsPerSecond: indexWarmWrites,
            },
          },
      ],
    });
    const response = await ddbClient.send(command);
    console.log(response);
  } catch (error) {
    console.error(`Error creating table: ${error}`);
    throw error;
  }
}
```

------

# Descripción del rendimiento en caliente de DynamoDB en diferentes escenarios
<a name="warm-throughput-scenarios"></a>

A continuación se presentan algunos escenarios diferentes que puede encontrar al trabajar con rendimiento en caliente de DynamoDB.

**Topics**
+ [Rendimiento en caliente y patrones de acceso desiguales](#warm-throughput-scenarios-uneven)
+ [Rendimiento en caliente para una tabla aprovisionada](#warm-throughput-scenarios-provisioned)
+ [Rendimiento en caliente de una tabla bajo demanda](#warm-throughput-scenarios-ondemand)
+ [Rendimiento en caliente para una tabla bajo demanda con el máximo rendimiento configurado](#warm-throughput-scenarios-max)

## Rendimiento en caliente y patrones de acceso desiguales
<a name="warm-throughput-scenarios-uneven"></a>

Una tabla puede tener un rendimiento en caliente de 30 000 unidades de lectura por segundo y de 10 000 unidades de escritura por segundo, pero aún así podría experimentar una limitación en las lecturas o escrituras antes de llegar a esos valores. Se debe probablemente a una partición activa. Aunque DynamoDB puede seguir escalando para soportar un rendimiento prácticamente ilimitado, cada partición individual está limitada a 1000 unidades de escritura por segundo y 3000 unidades de lectura por segundo. Si la aplicación dirige demasiado tráfico a una pequeña parte de las particiones de la tabla, puede producirse una limitación incluso antes de alcanzar los valores de rendimiento en caliente de la tabla. Recomendamos seguir las [prácticas recomendadas de DynamoDB](bp-partition-key-design.md) para garantizar una escalabilidad fluida y evitar las particiones en caliente.

## Rendimiento en caliente para una tabla aprovisionada
<a name="warm-throughput-scenarios-provisioned"></a>

Considere una tabla aprovisionada que tiene un rendimiento en caliente de 30 000 unidades de lectura por segundo y 10 000 unidades de escritura por segundo, pero que actualmente tiene un rendimiento aprovisionado de 4000 RCU y 8000 WCU. Puede escalar instantáneamente el rendimiento aprovisionado de la tabla hasta 30 000 RCU o 10 000 WCU actualizando la configuración de rendimiento aprovisionada. A medida que aumente el rendimiento en caliente aprovisionado por encima de estos valores, el rendimiento en caliente se ajustará automáticamente a los nuevos valores superiores, porque habrá establecido un nuevo rendimiento pico. Por ejemplo, si establece el rendimiento en caliente aprovisionado en 50 000 RCU, el rendimiento en caliente aumentará a 50 000 unidades de lectura por segundo.

```
"ProvisionedThroughput": 
    {
        "ReadCapacityUnits": 4000,
        "WriteCapacityUnits": 8000 
    }
"WarmThroughput": 
    { 
        "ReadUnitsPerSecond": 30000,
        "WriteUnitsPerSecond": 10000
    }
```

## Rendimiento en caliente de una tabla bajo demanda
<a name="warm-throughput-scenarios-ondemand"></a>

Una nueva tabla bajo demanda comienza con un rendimiento en caliente de 12 000 unidades de lectura por segundo y 4000 unidades de escritura por segundo. La tabla puede acomodar de forma instantánea un tráfico sostenido hasta estos niveles. Cuando las solicitudes superen las 12 000 unidades de lectura por segundo o las 4000 unidades de escritura por segundo, el rendimiento en caliente se ajustará automáticamente a valores superiores.

```
"WarmThroughput": 
    { 
        "ReadUnitsPerSecond": 12000,
        "WriteUnitsPerSecond": 4000
    }
```

## Rendimiento en caliente para una tabla bajo demanda con el máximo rendimiento configurado
<a name="warm-throughput-scenarios-max"></a>

Considere una tabla bajo demanda con un rendimiento en caliente de 30 000 unidades de lectura por segundo, pero con un [rendimiento máximo](on-demand-capacity-mode-max-throughput.md) configurado en 5000 unidades de solicitud de lectura (RRU). En este caso, el rendimiento de la tabla se limitará al máximo de las 5000 RRU que ha establecido. Cualquier solicitud de rendimiento que supere este máximo se limitará. No obstante, puede modificar en cualquier momento el rendimiento máximo específico de la tabla en función de las necesidades de la aplicación.

```
"OnDemandThroughput": 
    {
        "MaxReadRequestUnits": 5000,
        "MaxWriteRequestUnits": 4000
    }
"WarmThroughput": 
    { 
        "ReadUnitsPerSecond": 30000,
        "WriteUnitsPerSecond": 10000
    }
```

# Capacidad de ampliación y de adaptación de DynamoDB
<a name="burst-adaptive-capacity"></a>

Para minimizar las limitaciones debidas a las excepciones de rendimiento, DynamoDB utiliza la *capacidad de ampliación* para gestionar los picos de uso. DynamoDB utiliza la *capacidad de adaptación* para adaptarse a patrones de acceso irregulares.

## Capacidad de ampliación
<a name="burst-capacity"></a>

DynamoDB proporciona cierta flexibilidad para su aprovisionamiento de rendimiento con *capacidad de ampliación*. Cuando no se utiliza todo el rendimiento disponible, DynamoDB reserva una parte de esa capacidad no utilizada para realizar posteriormente *ampliaciones* de rendimiento durante los picos de uso. Con la capacidad de ráfaga, pueden realizarse correctamente solicitudes de lectura o escritura inesperadas que, de otro modo, habrían sido objeto de una limitación controlada.

En este momento, DynamoDB retiene hasta cinco minutos (300 segundos) de capacidad de lectura y escritura sin usar. Durante una ampliación de actividad de lectura o escritura ocasional, estas unidades de capacidad adicionales pueden consumirse muy rápidamente, incluso a más velocidad que la capacidad de rendimiento aprovisionada por segundo que se ha definido para la tabla.

DynamoDB también puede consumir capacidad de ampliación para el mantenimiento en segundo plano y otras tareas sin previo aviso.

Tenga en cuenta que estos detalles sobre la capacidad de ampliación podrían cambiar en el futuro.

## Capacidad de adaptación
<a name="adaptive-capacity"></a>

DynamoDB distribuye automáticamente sus datos en [particiones](HowItWorks.Partitions.md), que se almacenan en varios servidores en la Nube de AWS. No siempre es posible distribuir uniformemente la actividad de lectura y escritura. Si el acceso a los datos está desequilibrado, una partición "caliente" podría recibir un volumen mayor de tráfico de lectura y escritura que otras particiones. Dado que las operaciones de lectura y escritura en una partición se administran de forma independiente, se aplicará una limitación si una sola partición recibe más de 3000 operaciones de lectura o más de 1000 operaciones de escritura. De forma automática, la capacidad de adaptación hace que la capacidad de rendimiento aumente en las particiones que reciben más tráfico.

 Para acomodar mejor los patrones de acceso desiguales, la capacidad de adaptación de DynamoDB permite que una aplicación pueda seguir leyendo particiones calientes y escribiendo en ellas sin que se produzca una limitación controlada, siempre que el tráfico no supere la capacidad total aprovisionada para la tabla o la capacidad máxima de la partición. De forma automática e instantánea, la capacidad de adaptación hace que la capacidad de rendimiento aumente en las particiones que reciben más tráfico.

El siguiente diagrama ilustra el funcionamiento de la capacidad de adaptación. La tabla de ejemplo está aprovisionada con 400 WCU distribuidas de manera uniforme entre cuatro particiones, lo que permite que cada una de ellas admita un máximo de 100 WCU por segundo. Cada una de las particiones 1, 2 y 3 recibe tráfico de escritura de 50 WCU/seg. La partición 4 recibe 150 WCU/seg. Esta partición caliente puede aceptar tráfico de escritura mientras haya capacidad de ampliación disponible, pero eventualmente limitará el tráfico que supere las 100 WCU/s.

La capacidad de adaptación de DynamoDB responde aumentando la capacidad de la partición 4 para que pueda soportar la mayor carga de trabajo de 150 WCU/s sin que se aplique una limitación.

![\[La capacidad de adaptación aumenta automáticamente el rendimiento de la partición 4 con un tráfico mayor para evitar la limitación.\]](http://docs.aws.amazon.com/es_es/amazondynamodb/latest/developerguide/images/adaptive-capacity.png)


La capacidad de adaptación está habilitada de forma automática para todas las tablas de DynamoDB sin coste adicional. No es necesario habilitarla o deshabilitarla de forma explícita.

### Aislamiento de elementos de acceso frecuente
<a name="isolate-frequent-access-items"></a>

Si su aplicación dirige un tráfico alto hacia uno o dos elementos de forma desproporcionada, la capacidad de adaptación volverá a equilibrar sus particiones de manera que los elementos con acceso frecuente no residan en la misma partición. Este aislamiento de los elementos de acceso frecuente reduce la probabilidad de que se solicite la limitación controlada debida a que la carga de trabajo supere la cuota de rendimiento de una única partición. También puede dividir una colección de elementos en segmentos por clave de clasificación, siempre y cuando la colección de elementos no sea objeto de un seguimiento por aumento o disminución monótona de la clave de clasificación.

Si la aplicación genera habitualmente gran intensidad de tráfico dirigido a un solo elemento, la capacidad de adaptación puede reequilibrar los datos, de tal forma que una partición solo contenga ese elemento al que se accede con frecuencia. En este caso, DynamoDB puede proporcionar rendimiento hasta el máximo de la partición de 3000 RCU y 1000 WCU a la clave principal de ese elemento único. La capacidad de adaptación no dividirá las colecciones de elementos en varias particiones de la tabla cuando haya un [índice secundario local](LSI.md) en la tabla.

# Aspectos a tener en cuenta al cambiar los modos de capacidad en DynamoDB
<a name="bp-switching-capacity-modes"></a>

Cuando cree una tabla de DynamoDB, debe seleccionar el modo de capacidad bajo demanda o aprovisionada.

Puede cambiar las tablas del modo de capacidad aprovisionada al modo bajo demanda hasta cuatro veces en un periodo continuo de 24 horas. Las tablas pueden cambiar del modo bajo demanda al modo de capacidad aprovisionada en cualquier momento. 

**Topics**
+ [Cambio del modo de capacidad aprovisionada al modo de capacidad bajo demanda](#switch-provisioned-to-ondemand)
+ [Cambio del modo de capacidad bajo demanda al modo de capacidad aprovisionada](#switch-ondemand-to-provisioned)

## Cambio del modo de capacidad aprovisionada al modo de capacidad bajo demanda
<a name="switch-provisioned-to-ondemand"></a>

En el modo aprovisionado, se establece la capacidad de lectura y escritura en función de las necesidades esperadas de la aplicación. Al actualizar una tabla en modo aprovisionado al modo bajo demanda, no necesita especificar el rendimiento de lectura y escritura que espera de su aplicación. DynamoDB bajo demanda ofrece precios de pago por solicitud para las solicitudes de lectura y escritura. De este modo, únicamente paga por aquello que utiliza, por lo que es fácil equilibrar los costos y el rendimiento. Si lo desea, también puede configurar el rendimiento máximo de lectura o escritura (o ambos) para tablas individuales bajo demanda e índices secundarios globales para ayudar a mantener limitados los costos y el uso. Para obtener más información sobre cómo configurar el rendimiento máximo para una tabla o índice específicos, consulte [Rendimiento máximo de DynamoDB para las tablas bajo demanda](on-demand-capacity-mode-max-throughput.md).

Cuando se cambia del modo de capacidad aprovisionada al modo de capacidad bajo demanda, DynamoDB efectúa varios cambios en la estructura y las particiones de la tabla. Este proceso puede tardar varios minutos. Durante el periodo de cambio, la tabla proporciona el rendimiento acorde con las unidades de capacidad de lectura y de escritura aprovisionadas previamente.

### Rendimiento inicial del modo de capacidad bajo demanda
<a name="initial-throughput-ondemand-mode"></a>

Si recientemente ha cambiado una tabla existente al modo de capacidad bajo demanda por primera vez, la tabla tendrá la configuración del pico máximo anterior, aunque no haya atendido ningún tráfico en este modo.

A continuación, se muestran ejemplos de posibles escenarios:
+ **Cualquier tabla aprovisionada configurada por debajo de 4000 WCU y 12 000 RCU, que nunca se haya aprovisionado anteriormente para más cantidad.** Cuando cambie esta tabla a la versión bajo demanda por primera vez, DynamoDB se asegurará de que se escale horizontalmente para soportar al instante al menos 4000 unidades de escritura por segundo y 12 000 unidades de lectura por segundo.
+ **Una tabla aprovisionada configurada como 8000 WCU y 24 000 RCU.** Cuando esta tabla se cambie a la versión bajo demanda, seguirá siendo capaz de soportar al menos 8000 unidades de escritura por segundo y 24 000 unidades de lectura por segundo en cualquier momento.
+ **Una tabla aprovisionada configurada con 8000 WCU y 24 000 RCU, que consumió 6000 unidades de escritura por segundo y 18 000 unidades de lectura por segundo durante un periodo prolongado.** Cuando esta tabla se cambie a la versión bajo demanda, seguirá siendo capaz de soportar al menos 8000 unidades de escritura por segundo y 24 000 unidades de lectura por segundo. El tráfico anterior puede permitir además que la tabla mantenga niveles de tráfico mucho más altos sin limitaciones.
+ **Una tabla que anteriormente se aprovisionaba con 10 000 WCU y 10 000 RCU, pero que actualmente se aprovisiona con 10 RCU y 10 WCU.** Cuando esta tabla se cambie a la versión bajo demanda, será capaz de soportar al menos 10 000 unidades de escritura por segundo y 10 000 unidades de lectura por segundo.

### Configuración de escalado automático
<a name="autoscaling-settings"></a>

Al actualizar una tabla del modo aprovisionado al modo bajo demanda:
+ Si utiliza la consola, se eliminarán todos los ajustes de escalado automático (si los hay).
+ Si utiliza la AWS CLI o el SDK de AWS, se conservarán todos los ajustes de escalado automático. Estos ajustes se pueden aplicar al actualizar la tabla de nuevo al modo aprovisionado de facturación.

### Modo de capacidad de edición masiva en la [consola de DynamoDB](https://console.aws.amazon.com/dynamodb)
<a name="bulk-edit-capacity-mode"></a>

Puede editar varias tablas de forma masiva para cambiar del modo de capacidad aprovisionada al modo de capacidad bajo demanda mediante la [consola de DynamoDB](https://console.aws.amazon.com/dynamodb). Para editar de forma masiva el modo de capacidad:

1. En la consola de DynamoDB, vaya a la página **Tablas**.

1. Seleccione las casillas de verificación de las tablas que desee actualizar al modo de capacidad bajo demanda.

1. Elija **Acciones** y, a continuación, seleccione **Actualizar al modo de capacidad bajo demanda**.

Esta operación masiva le permite cambiar de manera eficiente varias tablas al modo de capacidad bajo demanda sin tener que actualizar cada tabla de forma individual.

## Cambio del modo de capacidad bajo demanda al modo de capacidad aprovisionada
<a name="switch-ondemand-to-provisioned"></a>

Al cambiar del modo de capacidad bajo demanda al modo de capacidad aprovisionada, la tabla proporciona el rendimiento acorde con el tráfico máximo alcanzado anteriormente mientras la tabla estaba en el modo de capacidad bajo demanda.

### Administración de la capacidad
<a name="switch-ondemand-capacity"></a>

Tenga en cuenta lo siguiente al actualizar una tabla del modo bajo demanda al modo aprovisionado:
+  Si usa la AWS CLI o el SDK de AWS, elija la configuración de capacidad aprovisionada correctos de la tabla y de los índices secundarios globales tras haber consultado en Amazon CloudWatch el consumo histórico (métricas `ConsumedWriteCapacityUnits` y `ConsumedReadCapacityUnits`) para determinar los nuevos ajustes de rendimiento.
**nota**  
Si va a cambiar una tabla global al modo aprovisionado, fíjese en el consumo máximo en todas las réplicas regionales de las tablas base y en los índices secundarios globales para determinar los nuevos ajustes de rendimiento. 
+ Si va a cambiar del modo bajo demanda al modo aprovisionado, asegúrese de establecer unas unidades aprovisionadas iniciales lo suficientemente altas como para gestionar la capacidad de su tabla o índice durante la transición.

### Administración de Auto Scaling
<a name="switch-ondemand-autoscaling"></a>

Al actualizar una tabla del modo bajo demanda al modo aprovisionado:
+ Si utiliza la consola, le recomendamos habilitar el escalado automático con los valores predeterminados siguientes:
  + Objetivo de utilización: 70 %
  + Capacidad aprovisionada mínima: 5 unidades
  + Capacidad aprovisionada máxima: el máximo de la región
+  Si utiliza la AWS CLI o el SDK, se conservan los ajustes anteriores de escalado automático (si los hay).