

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

# Optimización de costos de las tablas de Amazon Keyspaces
<a name="bp-cost-optimization"></a>

En esta sección se describen las prácticas recomendadas para optimizar los costos de sus tablas de Amazon Keyspaces existentes. Debería examinar las siguientes estrategias para ver qué estrategia de optimización de costos se adapta mejor a sus necesidades y abordarlas de forma iterativa. Cada estrategia proporciona información general sobre lo que puede estar afectando a sus costos, cómo buscar oportunidades para optimizar costos y orientación prescriptiva sobre cómo implementar estas prácticas recomendadas para ayudarle a ahorrar.

**Topics**
+ [Evaluación de los costos en el nivel de tabla](CostOptimization_TableLevelCostAnalysis.md)
+ [Evaluación del modo de capacidad de una tabla](CostOptimization_TableCapacityMode.md)
+ [Evaluación de los ajustes de Application Auto Scaling de su tabla](CostOptimization_AutoScalingSettings.md)
+ [Identificación de recursos no utilizados optimizar los costos en Amazon Keyspaces](CostOptimization_UnusedResources.md)
+ [Evaluación de los patrones de uso de las tablas para optimizar el rendimiento y los costos](CostOptimization_TableUsagePatterns.md)
+ [Evaluación de la capacidad aprovisionada para lograr un aprovisionamiento del tamaño adecuado](CostOptimization_RightSizedProvisioning.md)

# Evaluación de los costos en el nivel de tabla
<a name="CostOptimization_TableLevelCostAnalysis"></a>

La herramienta Cost Explorer que se encuentra en el Consola de administración de AWS le permite ver los costos desglosados por tipo, por ejemplo, los cargos de lectura, escritura, almacenamiento y respaldo. También puede ver estos costos resumidos por periodo, por ejemplo, por mes o por día.

Uno de los problemas comunes del Explorador de costos es que no permite revisar fácilmente los costos de una sola tabla en particular, ya que el Explorador de costos no le permite filtrar o agrupar por costos de una tabla específica. Puede ver la métrica **Tamaño de tabla facturable (bytes)** de cada tabla en la consola de Amazon Keyspaces, en la pestaña **Supervisar** la tabla. Si necesita más información relacionada con los costos por tabla, en esta sección se muestra cómo utilizar el [etiquetado](tagging-keyspaces.md) para realizar un análisis de costos de tablas individuales en el Explorador de costos.

**Topics**
+ [Visualización de costos de una única tabla de Amazon Keyspaces](#CostOptimization_TableLevelCostAnalysis_ViewInfo)
+ [Vista predeterminada del Explorador de costos](#CostOptimization_TableLevelCostAnalysis_CostExplorer)
+ [Cómo utilizar y aplicar las etiquetas de tabla en el Explorador de costos](#CostOptimization_TableLevelCostAnalysis_Tagging)

## Visualización de costos de una única tabla de Amazon Keyspaces
<a name="CostOptimization_TableLevelCostAnalysis_ViewInfo"></a>

Puede ver información básica sobre una tabla de Amazon Keyspaces en la consola, incluido el esquema de la clave principal, el tamaño de tabla facturable y las métricas relacionadas con la capacidad. El tamaño de la tabla se puede utilizar para calcular el costo mensual de almacenamiento de la tabla. Por ejemplo, 0,25\$1 por GB en el este de EE. UU. (Virginia del Norte). Región de AWS

Si la tabla utiliza el modo de capacidad aprovisionada, también se devuelven los ajustes actuales de la unidad de capacidad de lectura (RCU) y de la unidad de capacidad de escritura (WCU). Puede utilizar esta información para calcular los costos actuales de lectura y escritura de la tabla. Tenga en cuenta que estos costos podrían cambiar, especialmente si ha configurado la tabla con el escalado automático de Amazon Keyspaces.

## Vista predeterminada del Explorador de costos
<a name="CostOptimization_TableLevelCostAnalysis_CostExplorer"></a>

La vista predeterminada del Explorador de costos ofrece gráficos que muestran el costo de los recursos consumidos, por ejemplo, de rendimiento y almacenamiento. Puede optar por agrupar estos costos por periodos, como totales por mes o por día. Además, los costos de almacenamiento, lecturas, escrituras y otras categorías se pueden desglosar y comparar.

![\[Imagen que muestra el costo de los recursos consumidos en la vista del Explorador de costos.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/CostOptimization/CostExplorerView.png)


## Cómo utilizar y aplicar las etiquetas de tabla en el Explorador de costos
<a name="CostOptimization_TableLevelCostAnalysis_Tagging"></a>

De forma predeterminada, el Explorador de costos no proporciona un resumen de costos de ninguna tabla específica, porque combina los costos de múltiples tablas en un total. No obstante, puede utilizar el [etiquetado de recursos de AWS](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) para identificar cada tabla con una etiqueta de metadatos. Las etiquetas son pares clave-valor que puede utilizar para diversos fines, por ejemplo, para identificar todos los recursos pertenecientes a un proyecto o departamento. Para obtener más información, consulte [Trabajo con etiquetas para los recursos de Amazon Keyspaces](tagging-keyspaces.md).

Para este ejemplo, utilizamos una tabla con el nombre **MyTable**.

1. Establece una etiqueta con la clave **table\$1name** y el valor de. **MyTable**

1. [Active la etiqueta en el Explorador de costos](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html) y, a continuación, filtre el valor de la etiqueta para obtener una mayor visibilidad de los costos de cada tabla.

**nota**  
La etiqueta puede tardar uno o dos días en comenzar a aparecer en el Explorador de costos

Puede configurar las etiquetas de metadatos usted mismo en la consola o mediante programación con CQL, el o el AWS CLI SDK. AWS Considere la posibilidad de exigir que se establezca una etiqueta **table\$1name** como parte del proceso de creación de una nueva tabla en su organización. Para obtener más información, consulte [Creación de informes de asignación de costos con etiquetas para Amazon Keyspaces](CostAllocationReports.md).

# Evaluación del modo de capacidad de una tabla
<a name="CostOptimization_TableCapacityMode"></a>

En esta sección se ofrece información general sobre cómo seleccionar el modo de capacidad apropiado para su tabla de Amazon Keyspaces. Cada modo está ajustado para satisfacer las necesidades de una carga de trabajo diferente en cuanto a la capacidad de respuesta a los cambios en el rendimiento, así como a la forma de facturar ese uso. Debe sopesar estos factores al tomar su decisión.

**Topics**
+ [Qué modos de capacidad de tabla hay disponibles](#CostOptimization_TableCapacityMode_Overview)
+ [Cuándo seleccionar el modo de capacidad bajo demanda](#CostOptimization_TableCapacityMode_OnDemand)
+ [Cuándo seleccionar el modo de capacidad aprovisionada](#CostOptimization_TableCapacityMode_Provisioned)
+ [Factores adicionales que se deben tener en cuenta al elegir un modo de capacidad de tabla](#CostOptimization_TableCapacityMode_AdditionalFactors)

## Qué modos de capacidad de tabla hay disponibles
<a name="CostOptimization_TableCapacityMode_Overview"></a>

Al crear una tabla de Amazon Keyspaces, debe seleccionar el modo de capacidad bajo demanda o aprovisionada. Para obtener más información, consulte [Configurar los modos de read/write capacidad en Amazon Keyspaces](ReadWriteCapacityMode.md).

**Modo de capacidad bajo demanda**  
El modo de capacidad bajo demanda está diseñado para eliminar la necesidad de planificar o aprovisionar la capacidad de su tabla de Amazon Keyspaces. En este modo, su tabla se adapta instantáneamente a las solicitudes sin necesidad de ampliar o reducir ningún recurso (hasta el doble del rendimiento máximo anterior de la tabla). 

Las tablas bajo demanda se facturan contando el número de solicitudes reales que recibe la tabla, por lo que solo paga por lo que utiliza y no por lo que ha sido aprovisionada.

**Modo de capacidad aprovisionada**  
El modo de capacidad aprovisionada es un modelo más tradicional en el que puede definir cuánta capacidad tiene disponible la tabla para solicitudes, ya sea de forma directa o con la ayuda de Application Auto Scaling. Dado que se aprovisiona una capacidad específica para la tabla en un momento dado, la facturación se basa en la capacidad aprovisionada y no en el número de solicitudes. Superar la capacidad asignada también puede hacer que la tabla rechace solicitudes y reducir la experiencia de los usuarios de su aplicación.

El modo de capacidad aprovisionada requiere un equilibrio entre no sobreaprovisionar ni subaprovisionar la tabla a fin de lograr tanto una baja incidencia de errores de capacidad de rendimiento insuficiente como costos optimizados.

## Cuándo seleccionar el modo de capacidad bajo demanda
<a name="CostOptimization_TableCapacityMode_OnDemand"></a>

A la hora de optimizar costos, el modo bajo demanda es su mejor opción cuando tiene una carga de trabajo impredecible similar a la que se muestra en el siguiente gráfico.

Estos factores contribuyen a este tipo de carga de trabajo:
+ Tiempo de solicitud imprevisible (lo que provoca picos de tráfico)
+ Volumen variable de solicitudes (resultante de las cargas de trabajo por lotes)
+ Cae a cero o por debajo del 18 % del pico para una hora determinada (que resulta de entornos de desarrollo o prueba)

![\[Imagen que muestra una carga de trabajo puntiaguda con picos de tráfico aleatorios.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/CostOptimization/TableCapacityModeOnDemand.png)


En el caso de cargas de trabajo con las características anteriores, el uso de Application Auto Scaling para mantener una capacidad suficiente para que la tabla responda a los picos de tráfico podría dar lugar a resultados no deseados. O bien la tabla podría sobreaprovisionarse y costar más de lo necesario, o subaprovisionarse y las solicitudes darían lugar a errores innecesarios de baja capacidad de rendimiento. En casos como este, las tablas bajo demanda son la mejor opción.

Dado que las tablas bajo demanda se facturan por solicitud, no necesita hacer nada más a nivel de tabla para optimizar costos. Debe evaluar periódicamente sus tablas bajo demanda para comprobar que la carga de trabajo siga teniendo las características mencionadas. Si la carga de trabajo se ha estabilizado, considere la posibilidad de cambiar al modo aprovisionado para mantener la optimización de costos.

## Cuándo seleccionar el modo de capacidad aprovisionada
<a name="CostOptimization_TableCapacityMode_Provisioned"></a>

Una carga de trabajo ideal para el modo de capacidad aprovisionada es aquella con un patrón de uso más predecible como el que se muestra en el gráfico siguiente.

Los siguientes factores contribuyen a una carga de trabajo predecible:
+ Tráfico predecible o cíclico para una hora o un día determinado
+ Ampliaciones limitadas de corta duración

![\[Imagen que muestra una carga de trabajo bastante predecible con picos de tráfico limitados.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/CostOptimization/TableCapacityModeProvisioned.png)


Dado que los volúmenes de tráfico en un momento o día determinados son más estables, puede fijar la capacidad aprovisionada relativamente cerca de la capacidad consumida real de la tabla. Optimizar los costos de una tabla de capacidad aprovisionada es, en última instancia, el ejercicio de conseguir que la capacidad aprovisionada (línea azul) se acerque tanto como sea posible a la capacidad consumida (línea naranja) sin aumentar los eventos `ThrottledRequests` de la tabla. El espacio entre las dos líneas es tanto capacidad desaprovechada como un seguro contra una mala experiencia del usuario debida a errores de capacidad de rendimiento insuficiente.

Amazon Keyspaces proporciona Application Auto Scaling para las tablas de capacidad aprovisionada, que equilibra de forma automática esta situación en su nombre. Puede hacer un seguimiento de la capacidad consumida a lo largo del día y configurar la capacidad aprovisionada de la tabla basándose en un puñado de variables.

**Unidades de capacidad mínima**  
Puede fijar la capacidad mínima de una tabla para limitar la aparición de errores de capacidad de rendimiento insuficiente, pero esto no reduce el costo de la tabla. Si su tabla tiene periodos de baja utilización seguidos de un repentino pico de alta utilización, fijar el mínimo puede evitar que Application Auto Scaling fije la capacidad de la tabla demasiado baja.

**Unidades de capacidad máxima**  
Puede establecer la capacidad máxima de una tabla para limitar el escalado de una tabla por encima de lo previsto. Considere la posibilidad de aplicar un máximo para las tablas de desarrollo o prueba, en las que no se desea realizar pruebas de carga a gran escala. Puede establecer un máximo para cualquier tabla, pero asegúrese de evaluar periódicamente este ajuste con respecto a la línea de base de la tabla cuando la utilice en producción a fin de evitar errores accidentales de capacidad de rendimiento insuficiente.

**Utilización objetivo**  
El establecimiento de la utilización objetivo de la tabla es el principal medio de optimización de costos para una tabla de capacidad aprovisionada. Establecer aquí un valor porcentual más bajo aumenta la medida en que la tabla se sobreaprovisiona, lo que incrementa el costo, pero reduce el riesgo de errores de capacidad de rendimiento insuficiente. Establecer aquí un valor porcentual más alto reduce la medida en que la tabla se sobreaprovisiona, lo que disminuye el costo, pero aumenta el riesgo de errores de capacidad de rendimiento insuficiente.

## Factores adicionales que se deben tener en cuenta al elegir un modo de capacidad de tabla
<a name="CostOptimization_TableCapacityMode_AdditionalFactors"></a>

A la hora de decidir entre los dos modos de capacidad, hay algunos factores adicionales que vale la pena considerar.

 Al decidir entre los dos modos de tabla, tenga en cuenta en qué medida este descuento adicional afecta al costo de la tabla. En muchos casos, incluso una carga de trabajo relativamente impredecible puede ser más rentable ejecutarla en una tabla de capacidad aprovisionada sobreaprovisioanda con capacidad reservada. 

**Mejora de la previsibilidad de la carga de trabajo**  
En algunas situaciones, una carga de trabajo podría tener aparentemente tanto un patrón predecible como uno impredecible. Si bien esto se puede admitir con facilidad con una tabla bajo demanda, es probable que los costos sean menores si se pueden mejorar los patrones impredecibles de la carga de trabajo.

Una de las causas más comunes de estos patrones son las importaciones por lotes. Este tipo de tráfico puede superar a menudo la capacidad de base de la tabla hasta tal punto que, si se ejecutara, se producirían errores de capacidad de rendimiento insuficiente. Para mantener una carga de trabajo como esta en una tabla de capacidad aprovisionada, considere las siguientes opciones:
+ Si el lote se procesa en horas programadas, puede programar un aumento de la capacidad de escalado automático de su aplicación antes de que se ejecute.
+ Si el lote se procesa de forma aleatoria, considere la posibilidad de ampliar el tiempo que tarda en ejecutarse en vez de hacerlo lo más rápido posible.
+ Añada un periodo de aceleración a la importación, en el que la velocidad de la importación empiece siendo pequeña pero aumente lentamente a lo largo de unos minutos hasta que Application Auto Scaling haya tenido la oportunidad de empezar a ajustar la capacidad de la tabla.

# Evaluación de los ajustes de Application Auto Scaling de su tabla
<a name="CostOptimization_AutoScalingSettings"></a>

En esta sección se proporciona información general sobre cómo evaluar la configuración de Application Auto Scaling de las tablas de Amazon Keyspaces. [Amazon Keyspaces Application Auto Scaling](autoscaling.md) es una característica que administra el rendimiento de las tablas en función del tráfico de su aplicación y de su métrica de utilización objetivo. Esto garantiza que sus tablas tengan la capacidad necesaria para sus patrones de aplicación.

El servicio Application Auto Scaling monitorea el uso actual de sus tablas y lo compara con el valor de utilización objetivo: `TargetValue`. Le notifica si ha llegado el momento de aumentar o reducir la capacidad asignada. 

**Topics**
+ [Comprensión de los ajustes de Application Auto Scaling](#CostOptimization_AutoScalingSettings_UnderProvisionedTables)
+ [Cómo identificar tablas con una utilización objetivo baja (<=50 %)](#CostOptimization_AutoScalingSettings_IdentifyLowUtilization)
+ [Cómo abordar las cargas de trabajo con variaciones estacionales](#CostOptimization_AutoScalingSettings_SeasonalVariance)
+ [Cómo abordar cargas de trabajo con picos con patrones desconocidos](#CostOptimization_AutoScalingSettings_UnknownPatterns)
+ [Cómo abordar las cargas de trabajo con aplicaciones enlazadas](#CostOptimization_AutoScalingSettings_BetweenRanges)

## Comprensión de los ajustes de Application Auto Scaling
<a name="CostOptimization_AutoScalingSettings_UnderProvisionedTables"></a>

Definir el valor correcto para el uso objetivo, el paso inicial y los valores finales es una actividad que requiere la participación del equipo de operaciones. Esto le permite definir adecuadamente los valores basados en el uso histórico de la aplicación, que se utilizan para activar las políticas de Application Auto Scaling. El objetivo de utilización es el porcentaje de su capacidad total que debe alcanzarse durante un periodo de tiempo antes de que se apliquen las reglas de Application Auto Scaling.

Establecer un objetivo de **utilización alta (un objetivo en torno al 90 %)** significa que su tráfico necesita ser superior al 90 % durante un cierto periodo antes de que se active Application Auto Scaling. No debe usar un objetivo de alta utilización a menos que la aplicación sea muy constante y no reciba picos de tráfico.

Establecer una **utilización muy baja (un objetivo inferior al 50 %)** significa que su aplicación necesitaría alcanzar el 50 % de la capacidad aprovisionada antes de que se active una política de Application Auto Scaling. A menos que el tráfico de la aplicación crezca a un ritmo muy agresivo, esto normalmente se traduce en capacidad no utilizada y en recursos desperdiciados. 

## Cómo identificar tablas con una utilización objetivo baja (<=50 %)
<a name="CostOptimization_AutoScalingSettings_IdentifyLowUtilization"></a>

Puede usar AWS CLI o Consola de administración de AWS para monitorear e identificar las `TargetValues` políticas de Auto Scaling de su aplicación en sus recursos de Amazon Keyspaces.

**nota**  
Cuando utilice tablas multirregión en el modo de capacidad aprovisionada con el escalado automático de Amazon Keyspaces, asegúrese de utilizar las operaciones de la API de Amazon Keyspaces para configurar el escalado automático. Las operaciones subyacentes de la API de Application Auto Scaling a las que Amazon Keyspaces llama en su nombre no tienen capacidades multirregionales. Para obtener más información, consulte [Visualización de la capacidad aprovisionada y la configuración de escalado automático para una tabla multirregional en Amazon Keyspaces](tables-mrr-view.md).

------
#### [ AWS CLI ]

1. Devuelva la lista completa de recursos mediante la ejecución del siguiente comando:

   ```
   aws application-autoscaling describe-scaling-policies --service-namespace cassandra
   ```

   Este comando devuelve la lista completa de políticas de Application Auto Scaling emitidas para cualquier recurso de Amazon Keyspaces. Si solo desea recuperar los recursos de una tabla en particular, puede añadir `–resource-id parameter`. Por ejemplo:

   ```
   aws application-autoscaling describe-scaling-policies --service-namespace cassandra --resource-id "keyspace/keyspace-name/table/table-name”
   ```

1. Devuelva solo las políticas de escalado automático de una tabla en particular ejecutando el siguiente comando

   ```
   aws application-autoscaling describe-scaling-policies --service-namespace cassandra --resource-id "keyspace/keyspace-name/table/table-name”
   ```

   A continuación se destacan los valores de las políticas de Application Auto Scaling. Debe asegurarse de que el valor objetivo sea superior al 50 % para evitar el sobreaprovisionamiento. Debería obtener un resultado similar al siguiente:

   ```
   {
       "ScalingPolicies": [
           {
               "PolicyARN": "arn:aws:autoscaling:us-east-1:111122223333:scalingPolicy:<uuid>:resource/keyspaces/table/table-name-scaling-policy",
               "PolicyName": $<full-table-name>”,
               "ServiceNamespace": "cassandra",
               "ResourceId": "keyspace/keyspace-name/table/table-name",
               "ScalableDimension": "cassandra:table:WriteCapacityUnits",
               "PolicyType": "TargetTrackingScaling",
               "TargetTrackingScalingPolicyConfiguration": {
                   "TargetValue": 70.0,
                   "PredefinedMetricSpecification": {
                       "PredefinedMetricType": "KeyspacesWriteCapacityUtilization"
                   }
               },
               "Alarms": [
                   ...
               ],
               "CreationTime": "2022-03-04T16:23:48.641000+10:00"
           },
           {
               "PolicyARN": "arn:aws:autoscaling:us-east-1:111122223333:scalingPolicy:<uuid>:resource/keyspaces/table/table-name-scaling-policy",
               "PolicyName":$<full-table-name>”,
               "ServiceNamespace": "cassandra",
               "ResourceId": "keyspace/keyspace-name/table/table-name",
               "ScalableDimension": "cassandra:table:ReadCapacityUnits",
               "PolicyType": "TargetTrackingScaling",
               "TargetTrackingScalingPolicyConfiguration": {
                   "TargetValue": 70.0,
                   "PredefinedMetricSpecification": {
                       "PredefinedMetricType": "KeyspacesReadCapacityUtilization"
                   }
               },
               "Alarms": [
                   ...
               ],
               "CreationTime": "2022-03-04T16:23:47.820000+10:00"
           }
       ]
   }
   ```

------
#### [ Consola de administración de AWS ]

1. Inicie sesión Consola de administración de AWS y navegue hasta la página del CloudWatch servicio en [Cómo empezar con](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/getting-started.html). Consola de administración de AWS Seleccione lo apropiado Región de AWS si es necesario.

1. En la barra de navegación izquierda, seleccione **Tablas**. En la página **Tablas**, seleccione el **Nombre** de la tabla.

1. En la página **Detalles de la tabla**, en la pestaña **Capacidad**, revise la configuración de Application Auto Scaling de su tabla.

------

Si los valores de utilización objetivo son inferiores o iguales al 50 %, debe analizar las métricas de uso de la tabla para ver si están [subaprovisionadas o sobreaprovisionadas](CostOptimization_RightSizedProvisioning.md). 

## Cómo abordar las cargas de trabajo con variaciones estacionales
<a name="CostOptimization_AutoScalingSettings_SeasonalVariance"></a>

Considere el siguiente escenario: la aplicación funciona por debajo de un valor medio mínimo la mayor parte del tiempo, pero el objetivo de uso es bajo, por lo que la aplicación puede reaccionar rápidamente ante los eventos que se producen a determinadas horas del día y usted tiene suficiente capacidad y evita que se limite. Este escenario es habitual cuando una aplicación está muy ocupada durante el horario de oficina normal (de 9:00 a 17:00), pero que luego funciona a un nivel básico fuera del horario laboral. Dado que algunos usuarios comienzan a conectarse antes de las 09:00, la aplicación utiliza este umbral bajo para aumentar rápidamente su capacidad hasta alcanzar la *capacidad requerida* durante las horas punta.

Este escenario podría ser así: 
+ Entre las 17:00 y las 9:00, las unidades de `ConsumedWriteCapacityUnits` permanecen entre 90 y 100
+ Los usuarios comienzan a conectarse a la aplicación antes de las 9:00 y la capacidad de las unidades aumenta considerablemente (el valor máximo que ha visto es de 1500 WCU)
+ Por término medio, el uso de la aplicación varía entre 800 y 1200 durante las horas de trabajo

Si el escenario anterior se aplica a su aplicación, considere el uso de [escalado automático de aplicaciones programado](https://docs.aws.amazon.com/autoscaling/application/userguide/examples-scheduled-actions.html), en el que su tabla podría seguir teniendo configurada una regla de Application Auto Scaling, pero con una utilización objetivo menos agresiva que solo aprovisione la capacidad extra en los intervalos específicos que usted requiera.

Puede usar el AWS CLI para ejecutar los siguientes pasos a fin de crear una regla de autoescalado programada que se ejecute en función de la hora del día y el día de la semana.

1. Registre su tabla de Amazon Keyspaces como objetivo de escalado con Application Auto Scaling. Un destino escalable es un recurso que Application Auto Scaling puede escalar horizontalmente o escalar verticalmente.

   ```
   aws application-autoscaling register-scalable-target \
       --service-namespace cassandra \
       --scalable-dimension cassandra:table:WriteCapacityUnits \
       --resource-id keyspace/keyspace-name/table/table-name \
       --min-capacity 90 \
       --max-capacity 1500
   ```

1. Configure acciones programadas según los requisitos.

   Necesita dos reglas para cubrir el escenario: una para escalar verticalmente y otra para reducir verticalmente. La primera regla para escalar verticalmente la acción programada se muestra en el siguiente ejemplo.

   ```
   aws application-autoscaling put-scheduled-action \
       --service-namespace cassandra \
       --scalable-dimension cassandra:table:WriteCapacityUnits \
       --resource-id keyspace/keyspace-name/table/table-name \
       --scheduled-action-name my-8-5-scheduled-action \
       --scalable-target-action MinCapacity=800,MaxCapacity=1500 \
       --schedule "cron(45 8 ? * MON-FRI *)" \
       --timezone "Australia/Brisbane"
   ```

   La segunda regla para reducir verticalmente la acción programada se muestra en este ejemplo.

   ```
   aws application-autoscaling put-scheduled-action \
       --service-namespace cassandra \
       --scalable-dimension cassandra:table:WriteCapacityUnits \
       --resource-id keyspace/keyspace-name/table/table-name \
       --scheduled-action-name my-5-8-scheduled-down-action \
       --scalable-target-action MinCapacity=90,MaxCapacity=1500 \
       --schedule "cron(15 17 ? * MON-FRI *)" \
       --timezone "Australia/Brisbane"
   ```

1. Ejecute el siguiente comando para validar que ambas reglas se han activado:

   ```
   aws application-autoscaling describe-scheduled-actions --service-namespace cassandra
   ```

   Debería obtener un resultado como este:

   ```
   {
       "ScheduledActions": [
           {
               "ScheduledActionName": "my-5-8-scheduled-down-action",
               "ScheduledActionARN": "arn:aws:autoscaling:us-east-1:111122223333:scheduledAction:<uuid>:resource/keyspaces/table/table-name:scheduledActionName/my-5-8-scheduled-down-action",
               "ServiceNamespace": "cassandra",
               "Schedule": "cron(15 17 ? * MON-FRI *)",
               "Timezone": "Australia/Brisbane",
               "ResourceId": "keyspace/keyspace-name/table/table-name",
               "ScalableDimension": "cassandra:table:WriteCapacityUnits",
               "ScalableTargetAction": {
                   "MinCapacity": 90,
                   "MaxCapacity": 1500
               },
               "CreationTime": "2022-03-15T17:30:25.100000+10:00"
           },
           {
               "ScheduledActionName": "my-8-5-scheduled-action",
               "ScheduledActionARN": "arn:aws:autoscaling:us-east-1:111122223333:scheduledAction:<uuid>:resource/keyspaces/table/table-name:scheduledActionName/my-8-5-scheduled-action",
               "ServiceNamespace": "cassandra",
               "Schedule": "cron(45 8 ? * MON-FRI *)",
               "Timezone": "Australia/Brisbane",
               "ResourceId": "keyspace/keyspace-name/table/table-name",
               "ScalableDimension": "cassandra:table:WriteCapacityUnits",
               "ScalableTargetAction": {
                   "MinCapacity": 800,
                   "MaxCapacity": 1500
               },
               "CreationTime": "2022-03-15T17:28:57.816000+10:00"
           }
       ]
   }
   ```

La siguiente imagen muestra un ejemplo de carga de trabajo que siempre mantiene el objetivo de utilización del 70 %. Observe cómo las reglas de escalado automático siguen aplicándose y el rendimiento no se reduce.

![\[Un gráfico que muestra el uso de escritura en unidades por segundo y compara la capacidad aprovisionada con la consumida durante un día.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/CostOptimization/AutoScalingSettings3.png)


Al ampliar el zoom, podemos ver que hubo un aumento en la aplicación que desencadenó el umbral de escalado automático del 70 %, lo que obligó a que el escalado automático entrara en vigor y proporcionara la capacidad adicional necesaria para la tabla. La acción de escalado automático programada afectará a los valores máximo y mínimo y es su responsabilidad configurarlos.

![\[Una vista más detallada del gráfico que muestra el uso de escritura en unidades por segundo y compara la capacidad aprovisionada con la consumida durante un día, ampliando un momento específico.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/CostOptimization/AutoScalingSettings4.png)


![\[Vista en detalle de un gráfico que muestra el uso de escritura en unidades por segundo y compara la capacidad aprovisionada con la consumida durante un día.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/CostOptimization/AutoScalingSettings5.png)


## Cómo abordar cargas de trabajo con picos con patrones desconocidos
<a name="CostOptimization_AutoScalingSettings_UnknownPatterns"></a>

En este escenario, la aplicación utiliza un objetivo de utilización muy bajo, porque aún no conoce los patrones de la aplicación y quiere asegurarse de que su carga de trabajo no experimenta errores de rendimiento de baja capacidad.

Considere utilizar el [modo de capacidad bajo demanda](ReadWriteCapacityMode.OnDemand.md) en su lugar. Las tablas bajo demanda son perfectas para cargas de trabajo con picos en los que no se conocen los patrones de tráfico. Con el modo de capacidad bajo demanda, usted paga por solicitud por las lecturas y escrituras de datos que la aplicación realiza en las tablas. No necesita especificar el rendimiento de lectura y escritura que espera de su aplicación, dado que Amazon Keyspaces se adapta instantáneamente a sus cargas de trabajo a medida que aumentan o disminuyen.

## Cómo abordar las cargas de trabajo con aplicaciones enlazadas
<a name="CostOptimization_AutoScalingSettings_BetweenRanges"></a>

En este escenario, la aplicación depende de otros sistemas, como los escenarios de procesamiento por lotes, en los que se pueden producir grandes picos de tráfico en función de los eventos de la lógica de la aplicación.

Considere la posibilidad de desarrollar una lógica de escalado automático de la aplicación personalizada que reaccione a esos eventos en los que puede aumentar la capacidad de la tabla y `TargetValues` en función de sus necesidades específicas. Podría beneficiarse de una combinación de AWS servicios como λ Amazon EventBridge y Step Functions y utilizarlos para responder a las necesidades específicas de sus aplicaciones.

# Identificación de recursos no utilizados optimizar los costos en Amazon Keyspaces
<a name="CostOptimization_UnusedResources"></a>

En esta sección se ofrece una visión general de cómo evaluar periódicamente sus recursos sin utilizar. A medida que evolucionan los requisitos de su aplicación, debe asegurarse de que no quedan recursos sin utilizar que contribuyan a generar costos innecesarios de Amazon Keyspaces. Los procedimientos que se describen a continuación utilizan CloudWatch las métricas de Amazon para identificar los recursos no utilizados y tomar medidas para reducir los costes.

Puede monitorizar Amazon Keyspaces utilizando CloudWatch, que recopila y procesa datos sin procesar de Amazon Keyspaces para convertirlos en métricas legibles y prácticamente en tiempo real. Estas estadísticas se conservan durante un periodo de tiempo, de modo que pueda acceder a la información histórica para comprender mejor su utilización. De forma predeterminada, los datos métricos de Amazon Keyspaces se envían automáticamente a CloudWatch . Para obtener más información, consulta [¿Qué es Amazon CloudWatch?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) y [retención de métricas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#metrics-retention) en la *Guía del CloudWatch usuario de Amazon*. 

**Topics**
+ [Cómo identificar los recursos sin utilizar](#CostOptimization_UnusedResources_Identifying)
+ [Identificación de recursos de tabla sin utilizar](#CostOptimization_UnusedResources_Tables)
+ [Limpieza de los recursos de tabla no utilizados](#CostOptimization_UnusedResources_Tables_Cleanup)
+ [Limpiar las copias de seguridad point-in-time de recuperación no utilizadas (PITR)](#CostOptimization_UnusedResources_Backups)

## Cómo identificar los recursos sin utilizar
<a name="CostOptimization_UnusedResources_Identifying"></a>

Para identificar las tablas no utilizadas, puedes echar un vistazo a las siguientes CloudWatch métricas durante un período de 30 días para saber si hay alguna lectura o escritura activa en una tabla específica:

**`ConsumedReadCapacityUnits`**  
Número de unidades de capacidad de lectura consumidas durante el periodo de tiempo especificado, para que pueda hacer un seguimiento de la capacidad consumida. Puede recuperar la capacidad de lectura total consumida de una tabla.

**`ConsumedWriteCapacityUnits`**  
Número de unidades de capacidad de escritura consumidas durante el periodo de tiempo especificado, para que pueda hacer un seguimiento de la capacidad consumida. Puede recuperar la capacidad de escritura total consumida para una tabla.

## Identificación de recursos de tabla sin utilizar
<a name="CostOptimization_UnusedResources_Tables"></a>

Amazon CloudWatch es un servicio de supervisión y observabilidad que proporciona las métricas de la tabla Amazon Keyspaces que puede utilizar para identificar los recursos no utilizados. CloudWatch las métricas se pueden ver tanto a través de Consola de administración de AWS como a través de. AWS Command Line Interface

------
#### [ AWS Command Line Interface ]

Para ver las métricas de sus tablas a través de AWS Command Line Interface, puede utilizar los siguientes comandos.

1. En primer lugar, evalúe las lecturas de su tabla:
**nota**  
Si el nombre de la tabla no es único dentro de su cuenta, deberá especificar también el nombre del espacio de claves.

   ```
   aws cloudwatch get-metric-statistics --metric-name
   ConsumedReadCapacityUnits --start-time <start-time> --end-time <end-
   time> --period <period> --namespace AWS/Cassandra --statistics Sum --
   dimensions Name=TableName,Value=<table-name>
   ```

   Para evitar la identificación falsa de una tabla como no utilizada, evalúe las métricas durante un periodo más largo. Elija un intervalo de tiempo de inicio y fin apropiado, como **30 días**, y un periodo apropiado, como **86400**.

   En los datos devueltos, cualquier **suma** superior a **0** indica que la tabla que está evaluando recibió tráfico de lectura durante ese periodo.

   En el siguiente resultado se muestra una tabla que recibe tráfico de lectura en el periodo evaluado:

   ```
           {
               "Timestamp": "2022-08-25T19:40:00Z",
               "Sum": 36023355.0,
               "Unit": "Count"
           },
           {
               "Timestamp": "2022-08-12T19:40:00Z",
               "Sum": 38025777.5,
               "Unit": "Count"
           },
   ```

   En el siguiente resultado se muestra una tabla que no recibe tráfico de lectura en el periodo evaluado:

   ```
           {
               "Timestamp": "2022-08-01T19:50:00Z",
               "Sum": 0.0,
               "Unit": "Count"
           },
           {
               "Timestamp": "2022-08-20T19:50:00Z",
               "Sum": 0.0,
               "Unit": "Count"
           },
   ```

1. A continuación, evalúe las escrituras de su tabla:

   ```
   aws cloudwatch get-metric-statistics --metric-name
   ConsumedWriteCapacityUnits --start-time <start-time> --end-time <end-
   time> --period <period> --namespace AWS/Cassandra --statistics Sum --
   dimensions Name=TableName,Value=<table-name>
   ```

   Para evitar la identificación falsa de una tabla como no utilizada, es recomendable evaluar las métricas durante un periodo más largo. Elija un intervalo de tiempo de inicio y de finalización apropiado, como **30 días**, y un periodo apropiado, como **86 400**.

   En los datos devueltos, cualquier **suma** superior a **0** indica que la tabla que está evaluando recibió tráfico de lectura durante ese periodo.

   En el siguiente resultado se muestra una tabla que recibe el tráfico de escritura en el periodo evaluado:

   ```
           {
               "Timestamp": "2022-08-19T20:15:00Z",
               "Sum": 41014457.0,
               "Unit": "Count"
           },
           {
               "Timestamp": "2022-08-18T20:15:00Z",
               "Sum": 40048531.0,
               "Unit": "Count"
           },
   ```

   En el siguiente resultado se muestra una tabla que no recibe tráfico de escritura en el periodo evaluado:

   ```
           {
               "Timestamp": "2022-07-31T20:15:00Z",
               "Sum": 0.0,
               "Unit": "Count"
           },
           {
               "Timestamp": "2022-08-19T20:15:00Z",
               "Sum": 0.0,
               "Unit": "Count"
           },
   ```

------
#### [ Consola de administración de AWS ]

Los pasos siguientes le permiten evaluar la utilización de sus recursos a través de la Consola de administración de AWS.

1. Inicie sesión en Consola de administración de AWS y navegue hasta la página CloudWatch de servicio en [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/). Si es necesario, selecciona la opción correspondiente Región de AWS en la parte superior derecha de la consola.

1. En la barra de navegación izquierda, localice la sección **Métricas** y elija **Todas las métricas**.

1. La acción anterior abre un panel de control con dos paneles. En el panel superior, puede ver las métricas graficadas actualmente. En la parte inferior puede seleccionar las métricas disponibles para graficar. Elija Amazon Keyspaces en el panel inferior.

1. En el panel de selección de métricas de Amazon Keyspaces, elija la categoría **Métricas de tabla** para mostrar las métricas de sus tablas en la región actual.

1. Identifique el nombre de su tabla desplazándose por el menú y, a continuación, elija las métricas `ConsumedReadCapacityUnits` y `ConsumedWriteCapacityUnits` de su tabla.

1. Elija la pestaña **Métricas gráficas (2)** y ajuste la columna **Estadística** a **Suma**.

1. Para evitar una falsa identificación de una tabla como no utilizada, evalúe las métricas de la tabla durante un periodo más largo. En la parte superior del panel de gráficos, elija un periodo de tiempo apropiado, como 1 mes, para evaluar su tabla. Elija **Personalizar**, luego **1 Mes** en el menú desplegable y finalmente **Aplicar**.

1. Evalúe la métrica diagramada de su tabla para determinar si se está utilizando. Las métricas que han subido por encima de **0** indican que se ha utilizado una tabla durante el periodo de tiempo evaluado. Un gráfico plano en **0** tanto para lectura como para escritura indica que la tabla no se utiliza.

------

## Limpieza de los recursos de tabla no utilizados
<a name="CostOptimization_UnusedResources_Tables_Cleanup"></a>

Si ha identificado los recursos de tabla no utilizados, puede reducir sus costos continuos de las siguientes maneras.

**nota**  
Si ha identificado una tabla que no se utiliza, pero quiere mantenerla disponible por si es necesario acceder a ella en el futuro, considere la posibilidad de cambiarla al modo bajo demanda. Caso contrario, puede plantearse la posibilidad de eliminar la tabla.

**Modos de capacidad**  
Amazon Keyspaces cobra por leer, escribir y almacenar datos en sus tablas de Amazon Keyspaces.

Amazon Keyspaces dispone de [dos modos de capacidad](ReadWriteCapacityMode.md), que tienen opciones de facturación específicas para el procesamiento de lecturas y escrituras en sus tablas: bajo demanda y aprovisionada. El modo read/write de capacidad controla cómo se le cobra por el rendimiento de lectura y escritura y cómo administra la capacidad.

Para tablas en modo en diferido, no necesita especificar el rendimiento de lectura y escritura que espera de su aplicación. Amazon Keyspaces le cobra por las lecturas y escrituras que su aplicación realiza en sus tablas en términos de unidades de solicitud de lectura y unidades de solicitud de escritura. Si no hay actividad en su tabla, no paga por rendimiento, pero sigue incurriendo en un cargo por almacenamiento.

**Eliminación de tablas**  
Si ha descubierto una tabla sin utilizar y desea eliminarla, considere la posibilidad de hacer primero una copia de seguridad o exportar los datos.

Las copias de seguridad realizadas AWS Backup pueden aprovechar la organización en niveles del almacenamiento en frío, lo que reduce aún más los costos. Consulte la documentación de [Administración de planes de copias de seguridad](https://docs.aws.amazon.com/aws-backup/latest/devguide/about-backup-plans) para obtener información sobre cómo utilizar un ciclo de vida para trasladar la copia de seguridad al almacenamiento en frío.

Una vez realizada la copia de seguridad de la tabla, puede eliminarla a través de la Consola de administración de AWS o la AWS Command Line Interface.

## Limpiar las copias de seguridad point-in-time de recuperación no utilizadas (PITR)
<a name="CostOptimization_UnusedResources_Backups"></a>

Amazon Keyspaces ofrece Point-in-time recuperación, que proporciona copias de seguridad continuas durante 35 días para ayudarlo a protegerse contra escrituras o eliminaciones accidentales. Las copias de seguridad de PITR tienen costos asociados.

Consulte la documentación en [Backup y restauración de datos con point-in-time recuperación para Amazon Keyspaces](PointInTimeRecovery.md) para determinar si sus tablas tienen habilitadas copias de seguridad que tal vez ya no sean necesarias.

# Evaluación de los patrones de uso de las tablas para optimizar el rendimiento y los costos
<a name="CostOptimization_TableUsagePatterns"></a>

En esta sección se ofrece información general sobre cómo evaluar si sus tablas de Amazon Keyspaces se utilizan de forma eficiente. Existen determinados patrones de uso que no son óptimos para Amazon Keyspaces y que permiten un margen de optimización tanto desde el punto de vista de rendimiento como de costo.

**Topics**
+ [Realización de menos operaciones de lectura altamente coherente](#CostOptimization_TableUsagePatterns_StronglyConsistentReads)
+ [Habilitación del período de vida (TTL)](#CostOptimization_TableUsagePatterns_TTL)

## Realización de menos operaciones de lectura altamente coherente
<a name="CostOptimization_TableUsagePatterns_StronglyConsistentReads"></a>

Amazon Keyspaces le permite configurar [la coherencia de lectura](consistency.md#ReadConsistency) en función de cada solicitud. Las solicitudes de lectura tienen coherencia final de forma predeterminada. Las lecturas coherentes posteriores se cobran a 0,5 RCU para hasta 4 KB de datos.

La mayoría de las partes de las cargas de trabajo distribuidas son flexibles y pueden tolerar una coherencia eventual. Sin embargo, puede haber patrones de acceso que requieran lecturas altamente coherentes. Las lecturas altamente coherentes se cobran a 1 RCU para hasta 4 KB de datos, lo que básicamente duplica sus costos de lectura. Amazon Keyspaces le ofrece la flexibilidad de utilizar ambos modelos de coherencia en la misma tabla. 

Puede evaluar la carga de trabajo y el código de la aplicación para confirmar si solo se utilizan lecturas altamente coherentes cuando sea necesario.

## Habilitación del período de vida (TTL)
<a name="CostOptimization_TableUsagePatterns_TTL"></a>

[Periodo de vida (TTL)](TTL.md) le ayuda a simplificar la lógica de su aplicación y a optimizar el precio de almacenamiento al expirar automáticamente los datos de las tablas. Los datos que ya no necesite se eliminan automáticamente de su tabla en función del valor de tiempo de vida que establezca.



# Evaluación de la capacidad aprovisionada para lograr un aprovisionamiento del tamaño adecuado
<a name="CostOptimization_RightSizedProvisioning"></a>

En esta sección se ofrece información general sobre cómo evaluar si dispone de un aprovisionamiento de tamaño adecuado en sus tablas de Amazon Keyspaces. A medida que evolucione la carga de trabajo, debe modificar los procedimientos operativos de manera adecuada, en particular si la tabla de Amazon Keyspaces está configurada en modo aprovisionado y corre el riesgo de sobreaprovisionar o subaprovisionar sus tablas.

Los procedimientos que se describen en esta sección requieren información estadística que se debería capturar de tablas de Amazon Keyspaces que sean compatibles con la aplicación de producción. Para entender el comportamiento de la aplicación, debe definir un periodo de tiempo que sea lo suficientemente significativo como para captar la estacionalidad de los datos de su aplicación. Por ejemplo, si la aplicación muestra patrones semanales, utilizar un periodo de tres semanas debería darle suficiente espacio para analizar las necesidades de rendimiento de la aplicación.

Si no sabe por dónde empezar, utilice al menos un mes de uso de datos para los cálculos que se indican a continuación.

Al evaluar la capacidad, para las tablas de Amazon Keyspaces puede configurar las unidades de capacidad de **lectura (RCUs) y las unidades de capacidad de escritura (****WCU**) de forma independiente.

**Topics**
+ [Recuperación de métricas de consumo de sus tablas de Amazon Keyspaces](#CostOptimization_RightSizedProvisioning_ConsumptionMetrics)
+ [Identificación de tablas de DynamoDB subaprovisionadas](#CostOptimization_RightSizedProvisioning_UnderProvisionedTables)
+ [Identificación de tablas de DynamoDB sobreaprovisionadas](#CostOptimization_RightSizedProvisioning_OverProvisionedTables)

## Recuperación de métricas de consumo de sus tablas de Amazon Keyspaces
<a name="CostOptimization_RightSizedProvisioning_ConsumptionMetrics"></a>

Para evaluar la capacidad de la tabla, supervise las siguientes CloudWatch métricas y seleccione la dimensión adecuada para recuperar la información de la tabla:


| Unidades de capacidad de lectura | Unidades de capacidad de escritura | 
| --- | --- | 
|  `ConsumedReadCapacityUnits`  |  `ConsumedWriteCapacityUnits`  | 
|  `ProvisionedReadCapacityUnits`  |  `ProvisionedWriteCapacityUnits`  | 
|  `ReadThrottleEvents`  |  `WriteThrottleEvents`  | 

Puede hacerlo mediante el AWS CLI o el Consola de administración de AWS.

------
#### [ AWS CLI ]

Antes de recuperar las métricas de consumo de la tabla, debes empezar por capturar algunos puntos de datos históricos mediante la CloudWatch API.

Comience por crear dos archivos: `write-calc.json` y `read-calc.json`. Estos archivos representan los cálculos de la tabla. Debe actualizar algunos de los campos, como se indica en la tabla siguiente, para que coincidan con su entorno.

**nota**  
Si el nombre de la tabla no es único dentro de su cuenta, deberá especificar también el nombre del espacio de claves.


| Nombre del campo | Definición | Ejemplo | 
| --- | --- | --- | 
| <table-name> | El nombre de la tabla que vaya a analizar | SampleTable | 
| <period> | El periodo que utilizará para evaluar el objetivo de utilización, en segundos | Para un periodo de 1 hora, debe especificar: 3600 | 
| <start-time> | El comienzo del intervalo de evaluación, especificado en el ISO8601 formato | 2022-02-21T23:00:00 | 
| <end-time> | El final del intervalo de evaluación, especificado en el ISO8601 formato | 2022-02-22T06:00:00 | 

El archivo de cálculos de escritura recupera el número de WCU aprovisionadas y consumidas en el periodo de tiempo para el intervalo de fechas especificado. También genera un porcentaje de utilización que puede utilizarse para el análisis. El contenido completo del archivo `write-calc.json` debería asemejarse al del siguiente ejemplo.

```
{
  "MetricDataQueries": [
    {
      "Id": "provisionedWCU",
      "MetricStat": {
        "Metric": {
          "Namespace": "AWS/Cassandra",
          "MetricName": "ProvisionedWriteCapacityUnits",
          "Dimensions": [
            {
              "Name": "TableName",
              "Value": "<table-name>"
            }
          ]
        },
        "Period": <period>,
        "Stat": "Average"
      },
      "Label": "Provisioned",
      "ReturnData": false
    },
    {
      "Id": "consumedWCU",
      "MetricStat": {
        "Metric": {
          "Namespace": "AWS/Cassandra",
          "MetricName": "ConsumedWriteCapacityUnits",
          "Dimensions": [
            {
              "Name": "TableName",
              "Value": "<table-name>""
            }
          ]
        },
        "Period": <period>,
        "Stat": "Sum"
      },
      "Label": "",
      "ReturnData": false
    },
    {
      "Id": "m1",
      "Expression": "consumedWCU/PERIOD(consumedWCU)",
      "Label": "Consumed WCUs",
      "ReturnData": false
    },
    {
      "Id": "utilizationPercentage",
      "Expression": "100*(m1/provisionedWCU)",
      "Label": "Utilization Percentage",
      "ReturnData": true
    }
  ],
  "StartTime": "<start-time>",
  "EndTime": "<end-time>",
  "ScanBy": "TimestampDescending",
  "MaxDatapoints": 24
}
```

El archivo de cálculos de lectura utiliza una métrica similar. Este archivo recupera cuántos RCUs se aprovisionaron y consumieron durante el período correspondiente al intervalo de fechas especificado. El contenido del archivo `read-calc.json` debería asemejarse al del siguiente ejemplo.

```
{
  "MetricDataQueries": [
    {
      "Id": "provisionedRCU",
      "MetricStat": {
        "Metric": {
          "Namespace": "AWS/Cassandra",
          "MetricName": "ProvisionedReadCapacityUnits",
          "Dimensions": [
            {
              "Name": "TableName",
              "Value": "<table-name>"
            }
          ]
        },
        "Period": <period>,
        "Stat": "Average"
      },
      "Label": "Provisioned",
      "ReturnData": false
    },
    {
      "Id": "consumedRCU",
      "MetricStat": {
        "Metric": {
          "Namespace": "AWS/Cassandra",
          "MetricName": "ConsumedReadCapacityUnits",
          "Dimensions": [
            {
              "Name": "TableName",
              "Value": "<table-name>"
            }
          ]
        },
        "Period": <period>,
        "Stat": "Sum"
      },
      "Label": "",
      "ReturnData": false
    },
    {
      "Id": "m1",
      "Expression": "consumedRCU/PERIOD(consumedRCU)",
      "Label": "Consumed RCUs",
      "ReturnData": false
    },
    {
      "Id": "utilizationPercentage",
      "Expression": "100*(m1/provisionedRCU)",
      "Label": "Utilization Percentage",
      "ReturnData": true
    }
  ],
  "StartTime": "<start-time>",
  "EndTime": "<end-time>",
  "ScanBy": "TimestampDescending",
  "MaxDatapoints": 24
}
```

Una vez creados los archivos, puede empezar a recuperar los datos de utilización.

1. Para recuperar los datos de utilización de escritura, ejecute el siguiente comando:

   ```
   aws cloudwatch get-metric-data --cli-input-json file://write-calc.json
   ```

1. Para recuperar los datos de utilización de lectura, ejecute el siguiente comando:

   ```
   aws cloudwatch get-metric-data --cli-input-json file://read-calc.json
   ```

El resultado de ambas consultas es una serie de puntos de datos en formato JSON que pueden utilizarse para el análisis. Sus resultados dependen del número de puntos de datos que haya especificado, del periodo y de sus propios datos específicos de carga de trabajo. Podría asemejarse al ejemplo siguiente.

```
{
    "MetricDataResults": [
        {
            "Id": "utilizationPercentage",
            "Label": "Utilization Percentage",
            "Timestamps": [
                "2022-02-22T05:00:00+00:00",
                "2022-02-22T04:00:00+00:00",
                "2022-02-22T03:00:00+00:00",
                "2022-02-22T02:00:00+00:00",
                "2022-02-22T01:00:00+00:00",
                "2022-02-22T00:00:00+00:00",
                "2022-02-21T23:00:00+00:00"
            ],
            "Values": [
                91.55364583333333,
                55.066631944444445,
                2.6114930555555556,
                24.9496875,
                40.94725694444445,
                25.61819444444444,
                0.0
            ],
            "StatusCode": "Complete"
        }
    ],
    "Messages": []
}
```

**nota**  
Si especifica un periodo corto y un intervalo de tiempo largo, es posible que tenga que modificar el valor `MaxDatapoints`, que de forma predeterminada está fijado en 24 en el script. Este representa un punto de datos por hora y 24 por día.

------
#### [ Consola de administración de AWS ]

1. Inicie sesión en Consola de administración de AWS y navegue hasta la página del CloudWatch servicio en [Cómo empezar con](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/getting-started.html). Consola de administración de AWS Seleccione lo apropiado Región de AWS si es necesario.

1. Localice la sección Métricas en la barra de navegación izquierda y elija **Todas las métricas**.

1. Esto abre un panel de control con dos paneles. El panel superior le muestra el gráfico y el panel inferior tiene las métricas que desea graficar. Elija el panel Amazon Keyspaces.

1. Elija la categoría **Métricas de tabla** en los subpaneles. Esto le mostrará las tablas actuales Región de AWS.

1. Identifique el nombre de la tabla desplazándose hacia abajo en el menú y seleccionando las métricas de operaciones de escritura: `ConsumedWriteCapacityUnits` y `ProvisionedWriteCapacityUnits`
**nota**  
En este ejemplo se habla de las métricas de las operaciones de escritura, pero también puede utilizar estos pasos para representar gráficamente las métricas de las operaciones de lectura.

1. Seleccione la pestaña **Métricas diagramadas (2)** para modificar las fórmulas. De forma predeterminada, CloudWatch elige la función estadística **Promedio** para los gráficos.

1. Con ambas métricas gráficas seleccionadas (la casilla de verificación de la izquierda), seleccione el menú **Agregar matemática**, seguido de **Común** y, a continuación, seleccione la función **Porcentaje**. Repita el procedimiento dos veces.

   Primera vez al seleccionar la función **Porcentaje**.

   Segunda vez al seleccionar la función **Porcentaje**.

1. En este punto, debería tener cuatro métricas en el menú inferior. Vamos a trabajar en el cálculo de `ConsumedWriteCapacityUnits`. Para ser coherente, debe hacer coincidir los nombres con los que utilizó en la AWS CLI sección. Haga clic en **ID de m1** y cambie este valor a **consumedWCU**. 

1. Cambie la estadística de **Media** a **Suma**. Esta acción crea automáticamente otra métrica denominada **ANOMALY\$1DETECTION\$1BAND**. En el ámbito de este procedimiento, puede ignorar esto desmarcando la casilla de verificación en la **Métrica ad1** recién generada.

1. Repita el paso 8 para cambiar el nombre de **ID de m2** a **provisionedWCU**. Deje la estadística establecida en **Media**.

1. **Elija la etiqueta **Expression1** y actualice el valor a **m1** y la etiqueta a Consumed. WCUs**
**nota**  
Asegúrese de haber seleccionado solo **m1** (casilla de verificación de la izquierda) y **provisionedWCU** para visualizar correctamente los datos. Actualice la fórmula haciendo clic en **Detalles** y cambiándola a **consumedWCU/PERIOD(consumedWCU)**. Es posible que este paso también genere otra métrica **ANOMALY\$1DETECTION\$1BAND**, pero para el ámbito de este procedimiento puede ignorarla.

1. Ahora debería tener dos gráficos: uno que indica el aprovisionamiento WCUs en la tabla y otro que indica el consumo. WCUs 

1. Actualice la fórmula porcentual seleccionando el gráfico Expression2 (**e2**). **Cambie el nombre de las etiquetas a IDs UtilizationPercentage.** Cambie el nombre de la fórmula para que coincida con **100\$1(m1/provisionedWCU)**.

1. Desmarque la casilla de verificación de todas las métricas excepto **utilizationPercentage** para visualizar sus patrones de utilización. El intervalo predeterminado es de 1 minuto, pero siéntase libre de modificarlo según sus necesidades.

Los resultados que obtiene dependen de los datos reales de su carga de trabajo. Los intervalos con una utilización superior al 100 % son propensos a sufrir eventos de error de baja capacidad de rendimiento. Amazon Keyspaces ofrece [capacidad de ampliación](throughput-bursting.md), pero en cuanto esta se agote, todo lo que supere el 100 % experimenta eventos de error de baja capacidad de rendimiento.

------

## Identificación de tablas de DynamoDB subaprovisionadas
<a name="CostOptimization_RightSizedProvisioning_UnderProvisionedTables"></a>

Para la mayoría de las cargas de trabajo, una tabla se considera subaprovisionada cuando consume de forma continua más del 80 % de la capacidad aprovisionada.

La [capacidad de ráfaga](throughput-bursting.md) es una función de Amazon Keyspaces que permite a los clientes consumir temporalmente RCUs/WCUs más de lo que se había aprovisionado originalmente (más del rendimiento aprovisionado por segundo que se definió en la tabla). La capacidad de ampliación se creó para absorber los aumentos repentinos del tráfico debido a eventos especiales o picos de uso. Esta capacidad de ampliación es limitada. Para obtener más información, consulte [Uso eficaz de la capacidad de ampliación en Amazon Keyspaces](throughput-bursting.md). Tan pronto como la capacidad no utilizada RCUs y WCUs se agote, se pueden producir errores de rendimiento de baja capacidad si intentas consumir más capacidad de la aprovisionada. Cuando el tráfico de su aplicación se acerque a la tasa de utilización del 80 %, el riesgo de experimentar eventos de error de baja capacidad de rendimiento será significativamente mayor.

La regla de la tasa de utilización del 80 % varía según la estacionalidad de los datos y el crecimiento del tráfico. Considere los siguientes escenarios: 
+ Si el tráfico se ha mantenido **estable** a una tasa de utilización de aproximadamente el 90 % durante los últimos 12 meses, la tabla tiene la capacidad adecuada
+ Si el tráfico de la aplicación **crece** a un ritmo del 8 % mensual en menos de 3 meses, llegará al 100 %
+ Si el tráfico de la aplicación **crece** a un ritmo del 5 % mensual en un poco más de 4 meses, llegará al 100 %

Los resultados de las consultas anteriores proporcionan una imagen de la tasa de utilización. Úselos como guía para evaluar con más detalle otras métricas que pueden ayudarle a aumentar la capacidad de la tabla según sea necesario (por ejemplo, una tasa de crecimiento mensual o semanal). Trabaje con el equipo de operaciones para definir cuál es un buen porcentaje para la carga de trabajo y las tablas.

Existen escenarios especiales en los que los datos se sesgan al analizarlos a diario o semanalmente. Por ejemplo, con aplicaciones estacionales que tienen picos de utilización durante las horas de trabajo (pero luego caen casi a cero fuera de las horas de trabajo), podría beneficiarse de [programar el escalado automático de la aplicación](https://docs.aws.amazon.com/autoscaling/application/userguide/examples-scheduled-actions.html), donde usted especifica las horas del día (y los días de la semana) para aumentar la capacidad aprovisionada, así como cuándo reducirla. En vez de optar por una mayor capacidad para poder cubrir las horas de mayor actividad, también podría beneficiarse de las configuraciones de [escalado automático de tablas de Amazon Keyspaces](autoscaling.md) si su estacionalidad es menos pronunciada.

## Identificación de tablas de DynamoDB sobreaprovisionadas
<a name="CostOptimization_RightSizedProvisioning_OverProvisionedTables"></a>

Los resultados de la consulta obtenidos de los scripts anteriores proporcionan los puntos de datos necesarios para realizar algunos análisis iniciales. Si el conjunto de datos presenta valores de utilización inferiores al 20 % durante varios intervalos, es posible que la tabla tenga sobreaprovisionamiento. Para definir con más detalle si es necesario reducir la cantidad de RCUs WCUs y RCUs, debería revisar las demás lecturas de los intervalos.

Si su tabla contiene varios intervalos de baja utilización, puede beneficiarse del uso de políticas de Application Auto Scaling, ya sea programando Application Auto Scaling o simplemente configurando las políticas de Application Auto Scaling predeterminadas para la tabla que se basen en la utilización.

Si tiene una carga de trabajo con un índice de utilización bajo y una relación de aceleración alta (**máx. (ThrottleEvents) /minuto (ThrottleEvents)** en el intervalo), esto podría ocurrir si tiene una carga de trabajo muy intensa, en la que el tráfico aumenta considerablemente en días (o momentos del día) específicos, pero por lo demás es constantemente bajo. En estos escenarios, podría ser beneficioso utilizar [Application Auto Scaling programado](https://docs.aws.amazon.com/autoscaling/application/userguide/examples-scheduled-actions.html).