# Capacidade de throughput do DynamoDB
<a name="capacity-mode"></a>

Esta seção apresenta uma visão geral dos dois modos de throughput disponíveis para a tabela do DynamoDB e considerações sobre a seleção do modo de capacidade adequado para a aplicação. O modo de throughput de uma tabela determina como a capacidade de uma tabela é gerenciada. O modo de throughput também determina como é realizada a cobrança de operações de leitura e de gravação nas tabelas. No Amazon DynamoDB, é possível escolher entre o modo **sob demanda** e o modo **provisionado** para que as tabelas possam atender a diferentes requisitos de workload.

**Topics**
+ [Modo sob demanda](#capacity-mode-on-demand)
+ [Modo provisionado](#capacity-mode-provisioned)
+ [Modo de capacidade sob demanda do DynamoDB](on-demand-capacity-mode.md)
+ [Modo de capacidade provisionada do DynamoDB](provisioned-capacity-mode.md)
+ [Noções básicas sobre o throughput a quente do DynamoDB](warm-throughput.md)
+ [Capacidade de expansão e capacidade adaptável do DynamoDB](burst-adaptive-capacity.md)
+ [Considerações ao alternar os modos de capacidade no DynamoDB](bp-switching-capacity-modes.md)

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

O modo sob demanda do Amazon DynamoDB é uma opção de throughput sem servidor que simplifica o gerenciamento do banco de dados e escala automaticamente para comportar as aplicações mais exigentes dos clientes. O DynamoDB sob demanda permite que você crie uma tabela sem se preocupar com planejamento de capacidade, monitoramento de uso e configuração de políticas de ajuste de escala. Para solicitações de leitura e de gravação, o DynamoDB sob demanda oferece o modelo de preço de pagamento por solicitação para que você pague apenas pelo que usar. Para tabelas do modo sob demanda, não é necessário especificar o throughput de leitura e gravação que você espera que sua aplicação execute. 

O modo sob demanda é a opção de throughput padrão e recomendada para a maioria das workloads do DynamoDB. O DynamoDB lida com todos os aspectos do gerenciamento e do ajuste de escala de throughput para comportar workloads que podem começar pequenas e chegar a milhões de solicitações por segundo. É possível ler e gravar em suas tabelas do DynamoDB conforme necessário sem gerenciar a capacidade de throughput na tabela. Para obter mais informações, consulte [Modo de capacidade sob demanda do DynamoDB](on-demand-capacity-mode.md).

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

No modo provisionado, especifique o número de leituras e de gravações por segundo de que você precisa para a aplicação. Você será cobrado com base na capacidade de leitura e de gravação por hora provisionada, não na quantidade de capacidade provisionada que você realmente consumiu. Isso ajuda a governar seu uso do DynamoDB para permanecer no lugar ou abaixo de uma taxa de solicitação definida para obter previsão de custos.

É possível optar por usar a capacidade provisionada se tiver workloads estáveis com crescimento previsível e se puder prever com segurança os requisitos de capacidade para sua aplicação. Para obter mais informações, consulte [Modo de capacidade provisionada do DynamoDB](provisioned-capacity-mode.md).

# Modo de capacidade sob demanda do DynamoDB
<a name="on-demand-capacity-mode"></a>

O Amazon DynamoDB sob demanda oferece uma experiência de banco de dados verdadeiramente sem servidor que escala automaticamente para acomodar as workloads mais exigentes sem planejamento de capacidade. O modo sob demanda simplifica o processo de configuração, elimina o gerenciamento e o monitoramento da capacidade e oferece rápido ajuste de escala automático. Com o preço de pagamento por solicitação, você não precisa se preocupar com a capacidade ociosa, pois paga apenas pelo throughput que realmente usa. Você é cobrado por solicitação de leitura ou de gravação, portanto, seus custos refletem diretamente o uso real. 

Quando você escolhe o modo sob demanda, o DynamoDB acomoda instantaneamente o crescimento e a redução das workloads para qualquer nível de tráfego previamente registrado. Se o nível de tráfego de uma workload atingir um novo pico, o DynamoDB escalará automaticamente para acomodar os maiores requisitos de throughput. O modo sob demanda é a opção de throughput padrão, recomendada porque simplifica a criação de aplicações modernas e sem servidor que podem começar pequenas e chegar a milhões de solicitações por segundo. Depois que a escala de sua tabela sob demanda for aumentada horizontalmente, você poderá voltar a ter instantaneamente o mesmo throughput no futuro, sem controle de utilização. Se você não estiver direcionando tráfego para sua tabela, com o sistema sob demanda, não haverá cobranças por throughput. Para ter mais informações sobre as propriedades de escalabilidade do modo sob demanda, consulte [Throughput inicial e propriedades de escalabilidade](#on-demand-capacity-mode-initial). 

Tabelas que usam o modo sob demanda entregam a mesma latência de milissegundo de digito único, o acordo de serviço (SLA) e a segurança já oferecidos pelo modo provisionado do DynamoDB.

**nota**  
Por padrão, o DynamoDB protege você contra o uso indesejado e descontrolado. Para escalar além dos limites de throughput de leitura e gravação em nível de tabela de 40.000 para todas as tabelas em sua conta, você pode solicitar um aumento dessa cota. As solicitações de throughput que excedem a cota de throughput de tabela padrão têm controle de utilização. Para obter mais informações, consulte [Cotas padrão de throughput](ServiceQuotas.md#default-limits-throughput).

Você também pode configurar o throughput máximo de leitura ou de gravação (ou de ambas) por segundo para tabelas individuais sob demanda e índices secundários globais. Ao configurar o throughput, é possível manter o uso e os custos por tabela limitados, proteger-se contra o aumento inadvertido nos recursos consumidos e evitar o uso excessivo para ter um gerenciamento previsível dos custos. As solicitações de throughput que excedem o throughput máximo da tabela são limitadas. É possível modificar o throughput máximo específico da tabela a qualquer momento, com base nos requisitos da aplicação. Para obter mais informações, consulte [Throughput máximo do DynamoDB para tabelas sob demanda](on-demand-capacity-mode-max-throughput.md).

Para começar, crie ou atualize um modo sob demanda. Para obter mais informações, consulte [Operações básicas em tabelas do DynamoDB](WorkingWithTables.Basics.md).

É possível alternar as tabelas do modo de capacidade provisionada para o modo sob demanda até quatro vezes em um período contínuo de 24 horas. É possível alternar as tabelas do modo sob demanda para o modo de capacidade provisionada a qualquer momento. 

Para ter mais informações sobre como alternar entre os modos de capacidade de leitura e de gravação, consulte [Considerações ao alternar os modos de capacidade no DynamoDB](bp-switching-capacity-modes.md). Para se informar sobre cotas de tabela sob demanda, consulte [Throughput de leitura e gravação](ServiceQuotas.md#default-limits-throughput-capacity-modes).

**Topics**
+ [Unidades de solicitação de leitura e unidades de solicitação de gravação](#read-write-request-units)
+ [Throughput inicial e propriedades de escalabilidade](#on-demand-capacity-mode-initial)
+ [Throughput máximo do DynamoDB para tabelas sob demanda](on-demand-capacity-mode-max-throughput.md)

## Unidades de solicitação de leitura e unidades de solicitação de gravação
<a name="read-write-request-units"></a>

O DynamoDB cobra pelas leituras e gravações que sua aplicação realiza nas tabelas em termos de *unidades de solicitação de leitura* e *unidades de solicitação de gravação*.

Uma *unidade de solicitação de leitura* representa uma leitura altamente consistente por segundo, ou duas leituras finais consistentes por segundo, para um item com até 4 KB de tamanho. Para ter mais informações sobre os modelos de consistência de leitura do DynamoDB, consulte [Consistência de leitura do DynamoDB](HowItWorks.ReadConsistency.md).

Uma *unidade de solicitação de gravação* representa uma operação de gravação por segundo para um item com até 1 KB de tamanho.

Para ter mais informações sobre como as unidades de leitura e de gravação são consumidas, consulte [Operações de leitura e de gravação do DynamoDB](read-write-operations.md).

## Throughput inicial e propriedades de escalabilidade
<a name="on-demand-capacity-mode-initial"></a>

Tabelas do DynamoDB usando modo de capacidade sob demanda automaticamente adaptam-se ao volume de tráfego da sua aplicação. Novas tabelas sob demanda poderão comportar até 4 mil gravações por segundo e 12 mil leituras por segundo. O modo de capacidade sob demanda acomoda instantaneamente até o dobro do pico de tráfego anterior em uma tabela. Por exemplo, suponha que o padrão de tráfego da aplicação varie entre 25 mil e 50 mil leituras altamente consistentes por segundo, e 50 mil leituras por segundo seja o pico de tráfego atingido anteriormente. O modo de capacidade sob demanda atende instantaneamente ao tráfego continuado de até cem mil leituras por segundo. Se a aplicação comportar o tráfego de cem mil leituras por segundo, esse pico vai se tornar o novo pico anterior. Esse pico anterior possibilita que o tráfego subsequente alcance até duzentas mil leituras por segundo.

Se a workload gerar mais do que o dobro do pico anterior em uma tabela, o DynamoDB alocará automaticamente uma capacidade maior à medida que o volume de tráfego aumentar. Essa alocação de capacidade ajuda a garantir que a workload não sofra controle de utilização. No entanto, pode ocorrer controle de utilização se você exceder o dobro de seu pico anterior dentro de 30 minutos. Por exemplo, suponha que o padrão de tráfego da aplicação varie entre 25 mil e 50 mil leituras altamente consistentes por segundo, e 50 mil leituras por segundo sejam o pico de tráfego atingido anteriormente. Recomendamos pré-preparar a tabela ou espaçar o aumento do tráfego por pelo menos trinta minutos antes de gerar mais de cem mil leituras por segundo. Para ter mais informações sobre pré-preparação, consulte [Noções básicas sobre o throughput a quente do DynamoDB](warm-throughput.md).

O DynamoDB não impõe a restrição de controle de utilização de 30 minutos se o pico de tráfego da workload permanecer dentro do dobro do pico anterior. Se o pico de tráfego exceder o dobro do pico, garanta que esse aumento ocorra 30 minutos depois da última vez que você atingiu o pico.

# Throughput máximo do DynamoDB para tabelas sob demanda
<a name="on-demand-capacity-mode-max-throughput"></a>

Em relação a tabelas sob demanda, é possível especificar o throughput máximo de leitura ou de gravação (ou de ambas) por segundo em tabelas individuais e índices secundários globais (GSIs) associados. Especificar um throughput máximo sob demanda ajuda a manter o uso e os custos por tabela limitados. Por padrão, as configurações de throughput máximo não se aplicam e sua taxa de throughput sob demanda é limitada pelas [cotas de serviço da AWS](ServiceQuotas.md#default-limits-throughput) de 40.000 referente a throughput de leitura e gravação em nível de tabela para todas as tabelas na conta. Se necessário, é possível solicitar um aumento na cota do serviço.

Ao configurar o throughput máximo para uma tabela sob demanda, as solicitações de throughput que excederem a quantidade máxima especificada terão controle de utilização. É possível modificar as configurações de throughput por tabela a qualquer momento, com base nos requisitos da aplicação.

Veja a seguir alguns casos de uso comuns que podem se beneficiar do uso do throughput máximo para tabelas sob demanda:
+ **Otimização do custo de throughput**: o uso de throughput máximo para tabelas sob demanda oferece um nível adicional de previsibilidade e capacidade de gerenciamento de custos. Além disso, oferece maior flexibilidade para usar o modo sob demanda para comportar workloads com diferentes padrões de tráfego e orçamentos.
+ **Proteção contra uso excessivo**: ao definir o throughput máximo, é possível evitar um aumento acidental no consumo de leitura ou de gravação, que pode surgir de código não otimizado ou de processos não autorizados, em uma tabela sob demanda. Essa configuração por tabela pode proteger as organizações contra o consumo excessivo de recursos em determinado período.
+ **Proteger os serviços subsequentes**: uma aplicação do cliente pode incluir tecnologias com e sem servidor. A parte sem servidor da arquitetura pode ser escalada rapidamente para atender à demanda. No entanto, os componentes subsequentes com capacidades fixas podem ficar sobrecarregados. A implementação de configurações de throughput máximo para tabelas sob demanda pode impedir a propagação de um grande volume de eventos para vários componentes subsequentes com efeitos secundários inesperados.

É possível configurar o throughput máximo para o modo sob demanda para tabelas de região única novas e existentes, além de tabelas globais e GSIs. Também é possível configurar o throughput máximo durante a restauração da tabela e a importação de dados dos fluxos de trabalho do Amazon S3.

É possível especificar as configurações de throughput máximo para tabelas sob demanda usando o [console do DynamoDB](https://console.aws.amazon.com/dynamodb/), a [AWS CLI](AccessingDynamoDB.md#Tools.CLI), o [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-dynamodb-table.html) ou a [API do DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/Welcome.html).

**nota**  
O throughput máximo de uma tabela sob demanda é aplicado de acordo com o melhor esforço e deve ser considerado como alvo e não como limite máximo garantido de solicitações. A workload pode exceder temporariamente o throughput máximo especificado devido à [*capacidade de expansão*](burst-adaptive-capacity.md#burst-capacity). Em alguns casos, o DynamoDB usa a *capacidade de expansão* para atender a leituras ou gravações que ultrapassam as configurações de throughput máximo da tabela. Com a capacidade de expansão, as solicitações de leitura ou gravação inesperadas podem ter êxito onde, de outra forma, seriam limitadas.

**Topics**
+ [Considerações ao usar o throughput máximo para o modo sob demanda](#consideration-use-max-throughput-ondemand)
+ [Controle de utilização de solicitações e métricas do CloudWatch](#max-throughput-ondemand-request-throttle)

## Considerações ao usar o throughput máximo para o modo sob demanda
<a name="consideration-use-max-throughput-ondemand"></a>

Ao usar o throughput máximo para tabelas no modo sob demanda, as seguintes considerações se aplicam:
+ É possível definir de forma independente o throughput máximo de leituras e gravações de qualquer tabela sob demanda ou índice secundário global individual dentro dessa tabela para ajustar a abordagem com base em requisitos específicos.
+ Você pode usar o Amazon CloudWatch para monitorar e entender as métricas de uso por tabela do DynamoDB e para determinar as configurações de throughput máximo apropriadas para o modo sob demanda. Para obter mais informações, consulte [Métricas e dimensões do DynamoDB](metrics-dimensions.md).
+ Ao especificar as configurações de throughput máximo de leitura ou de gravação (ou de ambas) em uma réplica de tabela global, as mesmas configurações de throughput máximo são aplicadas automaticamente a todas as tabelas de réplica. É importante que as tabelas de réplica e os índices secundários em uma tabela global tenham configurações idênticas de throughput para garantir a replicação apropriada dos dados. Para obter mais informações, consulte [Melhores práticas para tabelas globais](globaltables-bestpractices.md).
+ O menor throughput máximo de leitura ou de gravação que você pode especificar é de uma unidade de solicitação por segundo.
+ O throughput máximo especificado deve ser menor do que a cota de throughput padrão que está disponível para qualquer tabela sob demanda ou índice secundário global individual dentro dessa tabela.

## Controle de utilização de solicitações e métricas do CloudWatch
<a name="max-throughput-ondemand-request-throttle"></a>

Se a aplicação exceder o throughput máximo de leitura ou de gravação definido na tabela sob demanda, o DynamoDB começará a controlar a utilização dessas solicitações. Quando o DynamoDB limita uma leitura ou gravação, ele retorna uma `ThrottlingException` para o chamador. Depois, você poderá tomar as medidas apropriadas, se necessário. Por exemplo, é possível aumentar ou desabilitar a configuração de throughput máximo da tabela ou aguardar um curto intervalo antes de repetir a solicitação.

Para simplificar o monitoramento do throughput máximo configurado para uma tabela ou um índice secundário global, o CloudWatch fornece as seguintes métricas: [OnDemandMaxReadRequestUnits](metrics-dimensions.md#OnDemandMaxReadRequestUnits) e [OnDemandMaxWriteRequestUnits](metrics-dimensions.md#OnDemandMaxWriteRequestUnits).

# Modo de capacidade provisionada do DynamoDB
<a name="provisioned-capacity-mode"></a>

Ao criar uma tabela provisionada no DynamoDB, é necessário especificar a *capacidade de throughput provisionado*. Essa é a quantidade de throughput de leitura e de gravação que a tabela pode comportar. Você será cobrado com base na capacidade de leitura e de gravação por hora provisionada, não na quantidade de capacidade provisionada que você realmente consumiu.

À medida que os dados da aplicação e os requisitos de acesso mudarem, talvez seja necessário ajustar as configurações de throughput da tabela. Você pode usar Auto Scaling para ajustar a capacidade provisionada da tabela automaticamente em resposta às alterações de tráfego. O ajuste de escala automático do DynamoDB usa uma [política de ajuste de escala](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html) no [Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html). Para configurar o ajuste de escala automático no DynamoDB, você define os níveis mínimo e máximo de capacidade de leitura e de gravação, além da porcentagem de utilização pretendida. O Application Auto Scaling cria e gerencia os alarmes do CloudWatch que acionam eventos de escalabilidade quando a métrica se desvia do destino. O ajuste de escala automático monitora a atividade da tabela e ajusta suas configurações de capacidade para cima ou para baixo com base em limites predefinidos. O ajuste de escala automático é acionado quando a capacidade consumida ultrapassa a meta de utilização configurada em dois minutos consecutivos. Os alarmes do CloudWatch podem ter um pequeno atraso de até alguns minutos antes de acionar o ajuste de escala automático. Para obter mais informações, consulte [Gerenciar a capacidade de throughput automaticamente com o ajuste de escala automático do DynamoDB](AutoScaling.md).

Se você estiver usando o Auto Scaling do DynamoDB as configurações de throughput serão automaticamente ajustadas em resposta às workloads reais. Também é possível usar a operação [UpdateTable](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateTable.html) para ajustar manualmente a capacidade de throughput da tabela. Por exemplo, você pode optar por fazer isso se precisar fazer o carregamento em massa de dados de um datastore existente para sua nova tabela do DynamoDB. Você pode criar a tabela com uma configuração alta de throughput de gravação e, em seguida, reduzir essa configuração depois que o carregamento de dados em massa for concluído.

**nota**  
Por padrão, o DynamoDB protege você contra o uso indesejado e descontrolado. Para escalar além dos limites de throughput de leitura e gravação em nível de tabela de 40.000 para todas as tabelas em sua conta, você pode solicitar um aumento dessa cota. As solicitações de throughput que excedem a cota de throughput de tabela padrão têm controle de utilização. Para obter mais informações, consulte [Cotas padrão de throughput](ServiceQuotas.md#default-limits-throughput).

É possível alternar as tabelas do modo de capacidade provisionada para o modo sob demanda até quatro vezes em um período contínuo de 24 horas. É possível alternar as tabelas do modo sob demanda para o modo de capacidade provisionada a qualquer momento. 

Para ter mais informações sobre como alternar entre os modos de capacidade de leitura e de gravação, consulte [Considerações ao alternar os modos de capacidade no DynamoDB](bp-switching-capacity-modes.md).

**Topics**
+ [Unidades de capacidade de leitura e unidades de capacidade de gravação](#read-write-capacity-units)
+ [Escolher as configurações iniciais de throughput](#choosing-initial-throughput)
+ [Auto Scaling do DynamoDB](#ddb-autoscaling)
+ [Gerenciar a capacidade de throughput automaticamente com o ajuste de escala automático do DynamoDB](AutoScaling.md)
+ [Capacidade reservada do DynamoDB](reserved-capacity.md)

## Unidades de capacidade de leitura e unidades de capacidade de gravação
<a name="read-write-capacity-units"></a>

Para tabelas do modo provisionado, você precisa especificar os requisitos de throughput em termos de *unidades de capacidade*. Essas unidades representam o volume de dados que a aplicação precisa ler ou gravar por segundo. Você pode modificar essas configurações mais tarde, se necessário, ou permitir que o Auto Scaling do DynamoDB os modifique automaticamente.

Em relação a um item de até 4 KB, uma *unidade de capacidade de leitura* (RCU) representa uma operação de leitura altamente consistente por segundo ou duas operações de leitura final consistente por segundo. Para ter mais informações sobre os modelos de consistência de leitura do DynamoDB, consulte [Consistência de leitura do DynamoDB](HowItWorks.ReadConsistency.md).

Uma *unidade de capacidade de gravação* (WCU) representa uma gravação por segundo para um item de até 1 KB. Para ter mais informações sobre as diferentes operações de gravação e de leitura, consulte [Operações de leitura e de gravação do DynamoDB](read-write-operations.md).

## Escolher as configurações iniciais de throughput
<a name="choosing-initial-throughput"></a>

Cada aplicação tem diferentes requisitos para operações de leitura e gravação em um banco de dados. Quando estiver determinando as configurações iniciais de throughput de uma tabela do DynamoDB, leve em conta o seguinte:
+ **Taxas esperadas de solicitações de leitura e de gravação**: você precisa calcular o número de leituras e de gravações que precisa realizar por segundo.
+ **Tamanhos de item**: alguns itens são pequenos o suficiente para que possam ser lidos ou gravados usando uma única unidade de capacidade. Itens maiores exigem várias unidades de capacidade. Ao estimar o tamanho médio dos itens que estarão na tabela, você poderá especificar configurações precisas para o throughput provisionado.
+ **Requisitos da consistência de leitura**: as unidades de capacidade de leitura baseiam-se em operações de leitura altamente consistente, que consomem duas vezes mais recursos de banco de dados que as leituras finais consistentes. Você deve determinar se o seu aplicativo requer leituras altamente consistentes, ou se ele pode ignorar essa exigência e executar leituras finais consistentes em vez disso. As operações de leitura no DynamoDB são finais consistentes por padrão. É possível solicitar leituras altamente consistentes para essas operações, se necessário.

Por exemplo, vamos supor que você queira ler oitenta itens por segundo de uma tabela. O tamanho desses itens é 3 KB, e você deseja leituras altamente consistentes. Nesse caso, cada leitura requer uma unidade de capacidade de leitura provisionada. Para determinar esse número, divida o tamanho do item da operação por 4 KB. Depois, arredonde o resultado para o número inteiro mais próximo, conforme mostrado no seguinte exemplo:
+ 3 KB/4 KB = 0,75 ou **1** unidade de capacidade de leitura

Portanto, para ler oitenta itens por segundo de uma tabela, defina o throughput de leitura provisionado da tabela como oitenta unidades de capacidade de leitura, conforme mostrado no seguinte exemplo:
+ 1 unidade de capacidade de leitura por item × 80 leituras por segundo = **80** unidades de capacidade de leitura

Agora, vamos supor que você queira gravar cem itens por segundo na tabela e que cada item tenha 512 bytes. Nesse caso, cada gravação requer uma unidade de capacidade de gravação provisionada. Para determinar esse número, divida o tamanho do item da operação por 1 KB. Depois, arredonde o resultado para o número inteiro mais próximo, conforme mostrado no seguinte exemplo:
+ 512 bytes/1 KB = 0,5 ou **1** unidade de capacidade de gravação.

Para gravar cem itens por segundo na tabela, defina o throughput de gravação provisionado da tabela como cem unidades de capacidade de gravação:
+ 1 unidade de capacidade de gravação por item × 100 gravações por segundo = **100** unidades de capacidade de gravação

## Auto Scaling do DynamoDB
<a name="ddb-autoscaling"></a>

O ajuste de escala automático do DynamoDB gerencia ativamente a capacidade de throughput de tabelas e de índices secundários globais. Com o Auto Scaling, você define um intervalo (limites superior e inferior) para unidades de capacidade de leitura e gravação. Você também define um percentual de utilização-alvo dentro desse intervalo. O Auto Scaling do DynamoDB procura manter sua utilização alvo, mesmo que a workload da sua aplicação aumente ou diminua.

Com o Auto Scaling do DynamoDB, uma tabela ou um índice secundário global pode aumentar sua capacidade provisionada de leitura e gravação para lidar com aumentos repentinos no tráfego, sem a controle de utilização de solicitações. Quando a workload diminuir, o Auto Scaling do DynamoDB diminuirá o throughput para que você não precise pagar por uma capacidade provisionada não utilizada.

**nota**  
Se você usar o Console de gerenciamento da AWS para criar uma tabela ou um índice secundário global, o Auto Scaling do DynamoDB será habilitado por padrão.  
É possível gerenciar as configurações de Auto Scaling a qualquer momento usando o console, a AWS CLI ou um dos AWS SDKs. Para obter mais informações, consulte [Gerenciar a capacidade de throughput automaticamente com o ajuste de escala automático do DynamoDB](AutoScaling.md).

### Taxa de utilização
<a name="ddb-autoscaling-utilization-rate"></a>

A taxa de utilização pode ajudar você a determinar se está sobrecarregando a capacidade de provisionamento. Nesse caso, você deve reduzir a capacidade da tabela para reduzir os custos. Inversamente, também pode ajudar você a determinar se está com pouca capacidade de provisionamento. Nesse caso, é necessário aumentar a capacidade da tabela para evitar um possível controle de utilização de solicitações durante instâncias de alto tráfego inesperado. Para ter mais informações, 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/).

Se você estiver usando o ajuste de escala automático do DynamoDB, também precisará definir uma meta de porcentagem de utilização. O ajuste de escala automático usará essa porcentagem como meta para ajustar a capacidade para cima ou para baixo. Recomendamos definir a meta de utilização como 70%. Para obter mais informações, consulte [Gerenciar a capacidade de throughput automaticamente com o ajuste de escala automático do DynamoDB](AutoScaling.md).

# Gerenciar a capacidade de throughput automaticamente com o ajuste de escala automático do DynamoDB
<a name="AutoScaling"></a>

Muitas workloads de banco de dados são cíclicas por natureza, enquanto outras são difíceis de prever com antecedência. Por exemplo, considere um aplicativo de rede social na qual a maioria dos usuários está ativa durante o horário diurno. O banco de dados deve ser capaz de lidar com a atividade durante o dia, mas não há necessidade dos mesmos níveis de throughput à noite. Outro exemplo: considere um novo aplicativo de jogos para celular que está sendo adotado de maneira rápida e inesperada. Se o jogo se tornar muito comum, talvez ele exceda os recursos de banco de dados disponíveis, resultando em performance lenta e clientes insatisfeitos. Esses tipos de workloads muitas vezes exigem intervenção manual para dimensionar recursos de banco de dados, aumentando-os ou diminuindo-os em resposta a diferentes níveis de uso.

O Auto Scaling do Amazon DynamoDB usa o serviço AWS Application Auto Scaling para ajustar dinamicamente a capacidade de throughput provisionado em seu nome em resposta aos padrões de tráfego reais. Isso permite que uma tabela ou um índice secundário global (GSI) aumente a capacidade provisionada de leitura e de gravação para processar aumentos repentinos no tráfego, sem controle de utilização. Quando a workload diminuir, o Application Auto Scaling diminuirá o throughput para que você não precise pagar por uma capacidade provisionada não utilizada.

**nota**  
Se você usar o Console de gerenciamento da AWS para criar uma tabela ou um índice secundário global, o Auto Scaling do DynamoDB será habilitado por padrão. É possível modificar as configurações de Auto Scaling a qualquer momento. Para obter mais informações, consulte [Usar o Console de gerenciamento da AWS com o Auto Scaling do DynamoDB](AutoScaling.Console.md).  
Ao remover manualmente uma tabela ou uma réplica de tabela global, você não remove automaticamente as metas escaláveis associadas, as políticas de escalabilidade nem os alarmes do CloudWatch.

Com o Application Auto Scaling, você cria um *política de escalabilidade* para uma tabela ou um índice secundário global. A política de escalabilidade especifica se você deseja dimensionar a capacidade de leitura ou a capacidade de gravação (ou ambas), bem como as configurações mínimas e máximas de unidades de capacidade provisionadas para a tabela ou o índice.

A política de escalabilidade também contém uma *utilização pretendida*: o percentual de throughput provisionado consumida em um determinado ponto no tempo. O Application Auto Scaling usa um *algoritmo de rastreamento* para ajustar o throughput provisionado da tabela (ou índice) para cima ou para baixo em resposta a workloads reais para que a utilização da capacidade real permaneça em ou perto de sua utilização pretendida.

As saídas do DynamoDB consumiram o throughput provisionado por períodos de um minuto. O ajuste de escala automático é acionado quando a capacidade consumida ultrapassa a meta de utilização configurada em dois minutos consecutivos. Os alarmes do CloudWatch podem ter um pequeno atraso de até alguns minutos antes de acionar o ajuste de escala automático. Esse atraso garante uma avaliação precisa da métrica do CloudWatch. Se os picos de throughput consumidos tiverem mais de um minuto de intervalo, o ajuste de escala automático poderá não ser acionado. Da mesma forma, um evento de redução de escala verticalmente pode ocorrer quando 15 pontos de dados consecutivos estão abaixo da meta de utilização. Nos dois casos, depois que o ajuste de escala automático é acionado, a API [UpdateTable](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateTable.html) é invocada. Depois, leva alguns minutos para atualizar a capacidade provisionada da tabela ou do índice. Durante esse período, todas as solicitações que excederem a capacidade provisionada anterior das tabelas terão controle de utilização.

**Importante**  
Não é possível ajustar o número de pontos de dados a serem violados antes do acionamento do alarme subjacente (embora o número atual possa mudar no futuro).

 É possível definir os valores de utilização do destino de Auto Scaling entre 20% e 90% como sua capacidade de gravação e leitura. 

**nota**  
Além de tabelas, o Auto Scaling do DynamoDB também oferece suporte a índices secundários globais. Cada índice secundário global tem sua própria capacidade de throughput provisionado separadamente daquela da tabela-base. Quando você cria uma política de escalabilidade para um índice secundário global, o Application Auto Scaling ajusta as configurações de throughput provisionado do índice para garantir que sua utilização real permaneça em ou perto da proporção de utilização desejada.

## Como o Auto Scaling do DynamoDB funciona
<a name="AutoScaling.HowItWorks"></a>

**nota**  
Para começar a trabalhar rapidamente com o Auto Scaling do DynamoDB, consulte [Usar o Console de gerenciamento da AWS com o Auto Scaling do DynamoDB](AutoScaling.Console.md).

O diagrama a seguir fornece uma visão geral de alto nível de como o Auto Scaling do DynamoDB gerencia a capacidade de throughput de uma tabela.

![\[O ajuste de escala automático do DynamoDB ajusta a capacidade de throughput de uma tabela para atender à demanda.\]](http://docs.aws.amazon.com/pt_br/amazondynamodb/latest/developerguide/images/auto-scaling.png)


As etapas a seguir resumem o processo de Auto Scaling, conforme mostrado no diagrama anterior:

1. Você cria uma política do Application Auto Scaling para sua tabela do DynamoDB.

1. O DynamoDB publica métricas de capacidade consumida no Amazon CloudWatch. 

1. Se a capacidade consumida da tabela exceder sua utilização pretendida (ou cair abaixo do valor desejado) por um período específico, o Amazon CloudWatch disparará um alarme. Você pode visualizar o alarme no console receber notificações por SMS usando o Amazon Simple Notification Service (Amazon SNS).

1. O alarme do CloudWatch invoca o Application Auto Scaling para avaliar sua política de escalabilidade.

1. O Application Auto Scaling emite uma solicitação `UpdateTable` para ajustar o throughput provisionado da sua tabela.

1. O DynamoDB processa a solicitação `UpdateTable`, aumentando (ou diminuindo) dinamicamente a capacidade de throughput provisionado da tabela de forma que ela se aproxime da sua utilização pretendida.

Para entender como o Auto Scaling do DynamoDB funciona, suponha que você tenha uma tabela chamada `ProductCatalog`. A tabela é raramente carregada em massa com dados e, por isso, não provoca muita atividade de gravação. No entanto, ela é submetida a um alto grau de atividades de leitura, que variam ao longo do tempo. Ao monitorar as métricas do Amazon CloudWatch para o `ProductCatalog`, você determina que a tabela requer 1.200 unidades de capacidade de leitura (para evitar que o controle de utilização do DynamoDB leia solicitações durante picos de atividades). Você também determina que o `ProductCatalog` requer no mínimo 150 unidades de capacidade de leitura quando o tráfego de leitura está em seu ponto mais baixo. Para obter mais informações sobre como evitar o controle de utilização, consulte [Solução de problemas de controle de utilização no Amazon DynamoDB](TroubleshootingThrottling.md).

No intervalo de 150 a 1.200 unidades de capacidade de leitura, você decide que uma utilização de destino de 70% seria apropriada para a tabela `ProductCatalog`. A *utilização pretendida* é a proporção entre unidades de capacidade consumidas e unidades de capacidade provisionadas, expressa como um percentual. O Application Auto Scaling usa seu algoritmo de rastreamento de capacidade pretendida para garantir que a capacidade de leitura provisionada de `ProductCatalog` seja ajustada conforme o necessário para que a utilização permaneça em ou perto de 70%.

**nota**  
A autoescalabilidade do DynamoDB modifica as configurações de throughput provisionado somente quando a workload real permanece elevada ou baixa por um período constante de vários minutos. O algoritmo de rastreamento de alvo do Application Auto Scaling procura manter a utilização pretendida em ou perto do seu valor escolhido em longo prazo.  
Picos de atividade súbitos de curta duração são acomodados pela capacidade de expansão interna da tabela. Para obter mais informações, consulte [Capacidade de expansão](burst-adaptive-capacity.md#burst-capacity).

Para habilitar o Auto Scaling do DynamoDB para a tabela `ProductCatalog`, você cria uma política de escalabilidade. A política especifica o seguinte:
+ A tabela ou o índice secundário global que você deseja gerenciar
+ Qual tipo de capacidade gerenciar (capacidade de leitura ou capacidade de gravação)
+ Os limites superior e inferior das configurações de throughput provisionado
+ Utilização de destino

Quando você criar uma política de escalabilidade, o Application Auto Scaling cria um par de alarmes do Amazon CloudWatch em seu nome. Cada par representa os limites superiores e inferiores das configurações de throughput provisionado. Esses alarmes do CloudWatch são disparados quando a utilização real da tabela se desvia da utilização pretendida por um período prolongado.

Quando um dos alarmes do CloudWatch for disparado, o Amazon SNS enviará uma notificação (caso você tenha habilitado esse recurso). O alarme do CloudWatch chama o Application Auto Scaling, que, por sua vez, notifica o DynamoDB para ajustar a capacidade provisionada da tabela `ProductCatalog` para cima ou para baixo conforme apropriado.

Durante um evento de ajuste de escala, o AWS Config é cobrado por item de configuração registrado. Quando ocorre um evento de ajuste de escala, quatro alarmes do CloudWatch são criados para cada evento de ajuste de escala automático de leitura e gravação: alarmes ProvisionedCapacity (ProvisionedCapacityLow e ProvisionedCapacityHigh) e alarmes ConsumedCapacity (AlarmHigh e AlarmLow). Isso soma um total de oito alarmes. Portanto, o AWS Config registra oito itens de configuração para cada evento de ajuste de escala.

**nota**  
Também é possível programar o ajuste de escala do DynamoDB para que ele ocorra em determinados horários. Conheça as etapas básicas [aqui](https://docs.aws.amazon.com/autoscaling/application/userguide/get-started-exercise.html).

## Observações de uso
<a name="AutoScaling.UsageNotes"></a>

Antes de começar a usar o Auto Scaling do DynamoDB, você deve estar ciente do seguinte:
+ O Auto Scaling do DynamoDB pode aumentar a capacidade de leitura ou gravação sempre que necessário, de acordo com a sua política de Auto Scaling. Todas as cotas do DynamoDB permanecem em vigor, conforme descrito em [Cotas no Amazon DynamoDB](ServiceQuotas.md).
+ O Auto Scaling do DynamoDB não impede a modificação manual de configurações de throughput provisionado. Esses ajustes manuais não afetam alarmes existentes do CloudWatch que estejam relacionados ao Auto Scaling do DynamoDB.
+ Se você habilitar o Auto Scaling do DynamoDB para uma tabela que tenha um ou mais índices secundários globais, é altamente recomendável que você também aplique o Auto Scaling uniformemente e esses índices. Isso ajudará a garantir uma performance melhor para gravações e leituras de tabelas e ajudará a evitar o controle de utilização. É possível habilitar a autoescalabilidade selecionando **Apply same settings to global secondary indexes** (Aplicar as mesmas configurações a índices secundários globais) no Console de gerenciamento da AWS. Para obter mais informações, consulte [Habilitar o Auto Scaling do DynamoDB em tabelas existentes](AutoScaling.Console.md#AutoScaling.Console.ExistingTable).
+ Ao remover manualmente uma tabela ou uma réplica de tabela global, você não remove automaticamente as metas escaláveis associadas, as políticas de dimensionamento nem os alarmes do CloudWatch.
+ Ao criar um GSI para uma tabela existente, o Auto Scaling não está habilitado para GSI. Você terá que gerenciar manualmente a capacidade enquanto o GSI está sendo compilado. Quando o provisionamento no GSI for concluído e atingir o status ativo, a autoescalabilidade funcionará normalmente.

# Usar o Console de gerenciamento da AWS com o Auto Scaling do DynamoDB
<a name="AutoScaling.Console"></a>

Quando você usa o Console de gerenciamento da AWS para criar uma nova tabela, o Auto Scaling do Amazon DynamoDB é habilitado para essa tabela por padrão. Você também pode usar o console para habilitar o Auto Scaling de tabelas existentes, modificar as configurações de Auto Scaling ou desabilitar o Auto Scaling.

**nota**  
 Para obter recursos mais avançados, como a definição de redução e expansão de períodos de cooldown, use a AWS Command Line Interface (AWS CLI) para gerenciar o dimensionamento automático do DynamoDB. Para obter mais informações, consulte [Usar a AWS CLI para gerenciar o Auto Scaling do Amazon DynamoDB](AutoScaling.CLI.md).

**Topics**
+ [Antes de começar: concessão de permissões de usuário ao Auto Scaling do DynamoDB](#AutoScaling.Permissions)
+ [Criar uma nova tabela com Auto Scaling habilitado](#AutoScaling.Console.NewTable)
+ [Habilitar o Auto Scaling do DynamoDB em tabelas existentes](#AutoScaling.Console.ExistingTable)
+ [Visualizar atividades de Auto Scaling no console](#AutoScaling.Console.ViewingActivities)
+ [Modificar ou desabilitar configurações de Auto Scaling do DynamoDB](#AutoScaling.Console.Modifying)

## Antes de começar: concessão de permissões de usuário ao Auto Scaling do DynamoDB
<a name="AutoScaling.Permissions"></a>

No AWS Identity and Access Management (IAM), a política `DynamoDBFullAccess`, gerenciada pela AWS, fornece as permissões necessárias para usar o console do DynamoDB. No entanto, para a autoescalabilidade do DynamoDB, os usuários precisam de permissões adicionais. 

**Importante**  
 Para excluir uma tabela habilitada para ajuste de escala automático, são necessárias permissões `application-autoscaling:*`. A política `DynamoDBFullAccess`, gerenciada pela AWS, inclui essas permissões.

Para configurar um usuário para acesso ao console do DynamoDB e autoescalabilidade do DynamoDB, crie um perfil e adicione a política **AmazonDynamoDBFullAccess** a esse perfil. Depois, atribua o perfil a um usuário.

## Criar uma nova tabela com Auto Scaling habilitado
<a name="AutoScaling.Console.NewTable"></a>

**nota**  
A autoescalabilidade do DynamoDB requer a presença de um perfil vinculado ao serviço (`AWSServiceRoleForApplicationAutoScaling_DynamoDBTable`) que realize ações de auescalabilidade em seu nome. Esta função é criada automaticamente para você. Para ter mais informações, consulte [Service-linked roles for Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html), no *Manual do usuário do Application Auto Scaling*.

**Para criar uma nova tabela com Auto Scaling habilitada**

1. Abra o console do DynamoDB em [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/).

1. Escolha **Create table**.

1. Na página **Criar tabela**, insira o **Nome de tabela** e os detalhes da chave primária.

1. Se você escolher **Configurações padrão**, o ajuste de escala automático será ativado na nova tabela.

   Caso contrário, selecione **Personalizar configurações** e faça o seguinte para especificar configurações personalizadas para a tabela: 

   1. Em **Classe de tabela**, mantenha a seleção padrão do **DynamoDB Standard**.

   1. Em **Configurações da capacidade de leitura/gravação**, mantenha a seleção padrão de **Provisionado** e faça o seguinte:

      1. Em **Capacidade de leitura**, verifique se o **Ajuste de escala automático** está definido como **Ativado**.

      1. Em **Capacidade de gravação**, verifique se o **Ajuste de escala automático** está definido como **Ativado**.

      1. Em **Capacidade de leitura** e **Capacidade de gravação**, defina a política de escalabilidade desejada para a tabela e, opcionalmente, todos os índices secundários globais da tabela.
         + **Unidades de capacidade mínima**: insira o limite inferior para o intervalo de autoescalabilidade.
         + **Unidades de capacidade máxima**: insira o limite superior para o intervalo de autoescalabilidade.
         + **Utilização pretendida**: insira a porcentagem de utilização pretendida para a tabela.
**nota**  
Se você criar um índice secundário global para a nova tabela, a capacidade do índice no momento da criação será a mesma da capacidade da tabela base. Você pode alterar a capacidade do índice nas configurações da tabela depois de criar a tabela.

1. Escolha **Criar tabela**. Isso cria a tabela com os parâmetros de ajuste de escala automático especificados.

## Habilitar o Auto Scaling do DynamoDB em tabelas existentes
<a name="AutoScaling.Console.ExistingTable"></a>

**nota**  
A autoescalabilidade do DynamoDB requer a presença de um perfil vinculado ao serviço (`AWSServiceRoleForApplicationAutoScaling_DynamoDBTable`) que realize ações de auescalabilidade em seu nome. Esta função é criada automaticamente para você. Para obter mais informações, consulte[ Funções vinculadas ao serviço para o Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html).

**Para habilitar o Auto Scaling do DynamoDB para uma tabela existente**

1. Abra o console do DynamoDB em [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/).

1. No painel de navegação, no lado esquerdo do console, selecione **Tables** (Tabelas).

1. Selecione a tabela na qual você deseja habilitar o ajuste de escala automático e, depois, faça o seguinte:

   1. Selecione a guia **Configurações adicionais**.

   1. Na seção **Capacidade de leitura/gravação**, selecione **Editar**.

   1. Na seção **Modo de capacidade**, selecione **Provisionada**.

   1. Na seção **Capacidade da tabela**, deixe **Ajuste de escala automático** no modo **Ativado** para **Capacidade de leitura**, **Capacidade de gravação** ou ambos. Para cada um deles, defina a política de escalabilidade desejada para a tabela e, opcionalmente, todos os índices secundários globais da tabela.
      + **Unidades de capacidade mínima**: insira o limite inferior para o intervalo de autoescalabilidade.
      + **Unidades de capacidade máxima**: insira o limite superior para o intervalo de autoescalabilidade.
      + **Utilização pretendida**: insira a porcentagem de utilização pretendida para a tabela.
      + **Usar as mesmas configurações de capacidade de leitura/gravação para todos os índices secundários globais**: escolha se os índices secundários globais devem usar a mesma política de autoescalabilidade que a tabela de base.
**nota**  
Para obter uma melhor performance, recomendamos habilitar **Use the same read/write capacity settings for all global secondary indexes (Usar as mesmas configurações de capacidade de leitura/gravação para todos os índices secundários globais).** Essa opção permite que o Auto Scaling do DynamoDB dimensione uniformemente todos os índices secundários globais na tabela-base. Isso inclui índices secundários globai existentes e quaisquer outros que você crie no futuro para essa tabela.  
Com essa opção habilitada, não é possível definir uma política de escalabilidade em um índice secundário global individual.

1. Quando estiver satisfeito com as configurações, clique em **Salvar**.

## Visualizar atividades de Auto Scaling no console
<a name="AutoScaling.Console.ViewingActivities"></a>

À medida que a sua aplicação direciona tráfego de leitura e gravação para a sua tabela, o Auto Scaling do DynamoDB modifica dinamicamente as configurações de throughput da tabela. O Amazon CloudWatch acompanha a capacidade provisionada e consumida, eventos limitados, latência e outras métricas para todas as tabelas do DynamoDB e índices secundários.

Para visualizar essas métricas no console do DynamoDB, escolha a tabela com a qual você deseja trabalhar e selecione a guia **Monitor**. Para criar uma visualização personalizável das métricas de tabela, selecione **View all in CloudWatch (Visualizar tudo no CloudWatch)**.

## Modificar ou desabilitar configurações de Auto Scaling do DynamoDB
<a name="AutoScaling.Console.Modifying"></a>

É possível usar o Console de gerenciamento da AWS para modificar configurações de Auto Scaling do DynamoDB. Para fazer isso, vá até a guia **Configurações adicionais** referente à sua tabela e selecione **Editar** na seção **Capacidade de leitura/gravação**. Para ter mais informações sobre essas configurações, consulte [Habilitar o Auto Scaling do DynamoDB em tabelas existentes](#AutoScaling.Console.ExistingTable).

# Usar a AWS CLI para gerenciar o Auto Scaling do Amazon DynamoDB
<a name="AutoScaling.CLI"></a>

Em vez de usar o Console de gerenciamento da AWS, você pode usar a AWS Command Line Interface (AWS CLI) para gerenciar o Auto Scaling do Amazon DynamoDB. O tutorial desta seção demonstra como instalar e configurar a AWS CLI para gerenciar o Auto Scaling do DynamoDB. Neste tutorial, você faz o seguinte:
+ Crie uma tabela do DynamoDB chamada `TestTable`. As configurações de throughput iniciais são 5 unidades de capacidade de leitura e 5 unidades de capacidade de gravação.
+ Crie uma política do Application Auto Scaling para `TestTable`. A política procura manter uma taxa de destino de 50% entre a capacidade de gravação consumida e a capacidade de gravação provisionada. O intervalo dessa métrica é entre 5 e 10 unidades de capacidade de gravação. (O Application Auto Scaling não tem permissão para ajustar o throughput além desse intervalo.)
+ Execute um programa Python para direcionar o tráfego de gravação para `TestTable`. Quando a taxa pretendida ultrapassar 50% por período contínuo, o Application Auto Scaling notificará o DynamoDB para aumentar o throughput de `TestTable` para que os 50% da utilização pretendida possam ser mantidos.
+ Verifique se o DynamoDB ajustou com sucesso a capacidade de gravação provisionada de `TestTable`.

**nota**  
Também é possível programar o ajuste de escala do DynamoDB para que ele ocorra em determinados horários. Conheça as etapas básicas [aqui](https://docs.aws.amazon.com/autoscaling/application/userguide/get-started-exercise.html).

**Topics**
+ [Antes de começar](#AutoScaling.CLI.BeforeYouBegin)
+ [Etapa 1: Crie uma tabela do DynamoDB](#AutoScaling.CLI.CreateTable)
+ [Etapa 2: registrar uma capacidade pretendida escalável](#AutoScaling.CLI.RegisterScalableTarget)
+ [Etapa 3: criar uma política de dimensionamento](#AutoScaling.CLI.CreateScalingPolicy)
+ [Etapa 4: direcionar o tráfego de gravação para TestTable](#AutoScaling.CLI.DriveTraffic)
+ [Etapa 5: visualizar ações do Application Auto Scaling](#AutoScaling.CLI.ViewCWAlarms)
+ [Etapa 6 (opcional): limpar](#AutoScaling.CLI.CleanUp)

## Antes de começar
<a name="AutoScaling.CLI.BeforeYouBegin"></a>

Antes de iniciar o tutorial, é necessário concluir as tarefas a seguir.

### Instalar o AWS CLI
<a name="AutoScaling.CLI.BeforeYouBegin.InstallCLI"></a>

Caso ainda não tenha feito isso, você deve instalar e configurar a AWS CLI. Para fazer isso, siga estas instruções no *Guia do usuário do AWS Command Line Interface*:
+ [Instalar a AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/installing.html)
+ [Configurando a AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)

### Instalar o Python
<a name="AutoScaling.CLI.BeforeYouBegin.InstallPython"></a>

Parte deste tutorial requer que você execute um programa Python (consulte [Etapa 4: direcionar o tráfego de gravação para TestTable](#AutoScaling.CLI.DriveTraffic)). Caso ainda não esteja instalado, você poderá [fazer download do Python](https://www.python.org/downloads). 

## Etapa 1: Crie uma tabela do DynamoDB
<a name="AutoScaling.CLI.CreateTable"></a>

Nesta etapa, use a AWS CLI para criar uma `TestTable`. A chave primária de `pk` consiste em (chave de partição) e `sk` (chave de classificação). Ambos os atributos são do tipo `Number`. As configurações de throughput iniciais são 5 unidades de capacidade de leitura e 5 unidades de capacidade de gravação.

1. Use o comando AWS CLI a seguir para criar a tabela:

   ```
   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 verificar o status da tabela, use o comando a seguir.

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

   A tabela está pronta para uso quando seu status é `ACTIVE`.

## Etapa 2: registrar uma capacidade pretendida escalável
<a name="AutoScaling.CLI.RegisterScalableTarget"></a>

Agora você registrará a capacidade de gravação da tabela como uma capacidade pretendida escalável com o Application Auto Scaling. Isso permite que o Application Auto Scaling ajuste a capacidade de gravação provisionada de *TestTable*, mas apenas no intervalo de 5 a 10 unidades de capacidade.

**nota**  
O Auto Scaling do DynamoDB requer a presença de uma função vinculada ao serviço (`AWSServiceRoleForApplicationAutoScaling_DynamoDBTable`) que realize ações de Auto Scaling em seu nome. Esta função é criada automaticamente para você. Para ter mais informações, consulte [Funções vinculadas a serviço do Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html), no *Guia do usuário do Application Auto Scaling*. 

1. Agora, insira o comando a seguir para registrar a capacidade pretendida. 

   ```
   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 verificar o registro, use o comando a seguir:

   ```
   aws application-autoscaling describe-scalable-targets \
       --service-namespace dynamodb \
       --resource-id "table/TestTable"
   ```
**nota**  
 Você também pode registrar um valor pretendido escalável em relação a um índice secundário global. Por exemplo, em um índice secundário global (“test-index”), o ID do recurso e os argumentos de dimensão escalável são atualizados adequadamente.   

   ```
   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
   ```

## Etapa 3: criar uma política de dimensionamento
<a name="AutoScaling.CLI.CreateScalingPolicy"></a>

Nesta etapa, você cria uma política de escalabilidade para `TestTable`. A política define os detalhes sob os quais o Application Auto Scaling pode ajustar o throughput provisionado da tabela e as ações que serão executadas quando ele fizer isso. Você associa essa política à capacidade pretendida que definiu na etapa anterior (unidades de capacidade de gravação da tabela `TestTable`).

A política contém os elementos a seguir:
+ `PredefinedMetricSpecification`: a métrica que o Application Auto Scaling tem permissão para ajustar. Para o DynamoDB, os valores a seguir são válidos para `PredefinedMetricType`:
  + `DynamoDBReadCapacityUtilization`
  + `DynamoDBWriteCapacityUtilization`
+ `ScaleOutCooldown`: a quantidade mínima de tempo (em segundos) entre cada evento do Application Auto Scaling que aumenta o throughput provisionado. Esse parâmetro permite que o Application Auto Scaling aumente o throughput de forma contínua, mas não agressivamente, em resposta às workloads do mundo real. A configuração padrão de `ScaleOutCooldown` é 0.
+ `ScaleInCooldown`: a quantidade mínima de tempo (em segundos) entre cada evento do Application Auto Scaling que diminui o throughput provisionado. Esse parâmetro permite que o Application Auto Scaling diminua o throughput de forma gradual e previsível. A configuração padrão de `ScaleInCooldown` é 0.
+ `TargetValue`: o Application Auto Scaling garante que o índice de capacidade consumida para capacidade provisionada permaneça nesse valor ou próximo a ele. Você define `TargetValue` como uma porcentagem.

**nota**  
Para compreender melhor como o `TargetValue` funciona, suponha que você tenha uma tabela com uma configuração de throughput provisionado de 200 unidades de capacidade de gravação. Você decide criar uma política de dimensionamento para essa tabela, com um `TargetValue` de 70%.  
Agora, suponha que você comece a direcionar tráfego de gravação para a tabela de forma que o throughput de gravação real seja de 150 unidades de capacidade. A taxa consumida-para-provisionada agora é (150/200), ou 75%. Essa taxa excede o valor pretendido. Portanto, o Application Auto Scaling aumenta a capacidade de gravação provisionada para 215 de modo que a taxa seja (150/215) ou 69,77% — tão próxima ao seu `TargetValue` quanto possível, mas sem excedê-lo.

Para `TestTable`, defina `TargetValue` como 50%. O Application Auto Scaling ajusta o throughput provisionado da tabela dentro do intervalo de 5 a 10 unidades de capacidade (consulte [Etapa 2: registrar uma capacidade pretendida escalável](#AutoScaling.CLI.RegisterScalableTarget)) para que a taxa consumida-para-provisionada permaneça em 50% ou próxima a isso. Você define os valores de `ScaleOutCooldown` e `ScaleInCooldown` para 60 segundos.

1. Crie um arquivo denominado `scaling-policy.json` com os conteúdos a seguir.

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

1. Use o comando da AWS CLI a seguir para criar a 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. Na saída, observe que o Application Auto Scaling criou dois alarmes do Amazon CloudWatch: um para o limite superior e outro para o limite inferior da faixa de escalabilidade prevista.

1. Use o comando da AWS CLI a seguir para visualizar mais detalhes sobre a política de escalabilidade.

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

1. Na saída, verifique se as configurações da política correspondem às suas especificações de [Etapa 2: registrar uma capacidade pretendida escalável](#AutoScaling.CLI.RegisterScalableTarget) e [Etapa 3: criar uma política de dimensionamento](#AutoScaling.CLI.CreateScalingPolicy).

## Etapa 4: direcionar o tráfego de gravação para TestTable
<a name="AutoScaling.CLI.DriveTraffic"></a>

Agora, você pode testar a política de escalabilidade gravando dados em `TestTable`. Para fazer isso, execute um programa Python.

1. Crie um arquivo denominado `bulk-load-test-table.py` com os conteúdos a seguir.

   ```
   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 executar o programa, insira o comando a seguir.

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

   A capacidade de gravação provisionada de `TestTable` é muito baixa (5 unidades de capacidade de gravação), para que o programa pare ocasionalmente devido a limitações de gravação. Esse comportamento é esperado.

   Deixe o programa continuar em execução enquanto você avança para a próxima etapa.

## Etapa 5: visualizar ações do Application Auto Scaling
<a name="AutoScaling.CLI.ViewCWAlarms"></a>

 Nesta etapa, você visualiza as ações do Application Auto Scaling que são iniciadas em seu nome. Você também pode verificar se o Application Auto Scaling atualizou a capacidade de gravação provisionada de `TestTable`.

1. Insira o comando a seguir para visualizar as ações do Application Auto Scaling.

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

   Execute esse comando ocasionalmente, enquanto o programa Python está em execução. (Alguns minutos serão necessários antes que sua política de escalabilidade seja invocada.) Você deve finalmente ver a saída a seguir.

   ```
   ...
   {
       "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"
   }, 
   ...
   ```

   Isso indica que o Application Auto Scaling emitiu uma solicitação `UpdateTable` para o DynamoDB.

1. Digite o comando a seguir para verificar se o DynamoDB aumentou a capacidade de gravação da tabela.

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

   As `WriteCapacityUnits` devem ter sido dimensionadas de `5` para `10`.

## Etapa 6 (opcional): limpar
<a name="AutoScaling.CLI.CleanUp"></a>

Neste tutorial, você criou vários recursos. Você pode excluir esses recursos se eles não forem mais necessários.

1. Excluir a política de escalabilidade de `TestTable`.

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

1. Cancelar o registro de capacidade pretendida escalável.

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

1. Exclua a tabela `TestTable`.

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

# Usar o AWS SDK para configurar o Auto Scaling em tabelas do Amazon DynamoDB
<a name="AutoScaling.HowTo.SDK"></a>

Além de usar o Console de gerenciamento da AWS e a AWS Command Line Interface (AWS CLI), você pode escrever aplicações que interagem com o Auto Scaling do Amazon DynamoDB. Esta seção contém dois programas Java que podem ser usados para testar essa funcionalidade:
+ `EnableDynamoDBAutoscaling.java`
+ `DisableDynamoDBAutoscaling.java`

## Habilitação do Application Auto Scaling para uma tabela
<a name="AutoScaling.HowTo.SDK-enable"></a>

O programa a seguir mostra um exemplo de configuração de uma política de Auto Scaling para uma tabela do DynamoDB (`TestTable`). Ele procede da seguinte maneira:
+ O programa registra unidades de capacidade de gravação como um destino dimensionável para a `TestTable`. O intervalo dessa métrica é entre 5 e 10 unidades de capacidade de gravação.
+ Depois que o destino escalável é criado, o programa cria uma configuração de rastreamento de destino. A política procura manter uma taxa de destino de 50% entre a capacidade de gravação consumida e a capacidade de gravação provisionada.
+ Em seguida, o programa cria a política de escalabilidade com base na configuração de rastreamento de destino.

**nota**  
Ao remover manualmente uma tabela ou uma réplica de tabela global, você não remove automaticamente os destinos escaláveis associados, políticas de escalabilidade nem alarmes do 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 ]

O programa exige que você forneça um nome do recurso da Amazon (ARN) para uma função vinculada ao serviço Application Auto Scaling válida. (Por exemplo: `arn:aws:iam::122517410325:role/AWSServiceRoleForApplicationAutoScaling_DynamoDBTable`.) No seguinte programa, substitua `SERVICE_ROLE_ARN_GOES_HERE` pelo 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());
		}

	}

}
```

------

## Desabilitar o Application Auto Scaling para uma tabela
<a name="AutoScaling.HowTo.SDK-disable"></a>

O programa a seguir inverte o processo anterior. Ele remove a política de Auto Scaling e cancela o registro do destino dimensionável.

------
#### [ 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());
		}

	}

}
```

------

# Capacidade reservada do DynamoDB
<a name="reserved-capacity"></a>

Para tabelas de capacidade provisionada que usam a [classe de tabela](HowItWorks.TableClasses.md) padrão, o DynamoDB oferece a opção de comprar capacidade reservada para leitura e gravação. A compra de capacidade reservada é um acordo para pagar por uma quantidade mínima de capacidade de throughput provisionado, durante a vigência do contrato, em troca de preços com desconto.

**nota**  
Não é possível comprar capacidade reservada para unidades de capacidade de gravação replicada (rWCUs). A capacidade reservada é aplicada somente à região onde foi comprada. A capacidade reservada também não está disponível para tabelas que usam a classe de tabela Standard-IA do DynamoDB ou o modo de capacidade sob demanda.

A capacidade reservada é adquirida em alocações de 100 WCUs ou 100 RCUs. A menor oferta de capacidade reservada é de cem unidades de capacidade (leituras ou gravações). A capacidade reservada do DynamoDB é oferecida como um compromisso de um ano ou, em regiões selecionadas, como um compromisso de três anos. É possível economizar até 54% nas taxas padrão por um período de um ano e 77% nas taxas padrão por um período de três anos. Para ter mais informações sobre como e quando você deve comprar, consulte [Amazon DynamoDB Reserved Capacity](https://aws.amazon.com/dynamodb/reserved-capacity/).

**nota**  
Você pode adquirir até 1 milhão de unidades de capacidade reservada para unidades de capacidade de gravação (WCUs) e unidades de capacidade de leitura (RCUs) usando o Console de Gerenciamento da AWS. Se você quiser adquirir mais de 1 milhão de unidades de capacidade provisionada em uma única compra ou ter capacidade reservada ativa e comprar capacidade reservada adicional que resultaria em mais de 1 milhão de unidades de capacidade provisionada ativas, siga o processo mencionado na seção “Como adquirir capacidade reservada” em [Capacidade reservada do Amazon DynamoDB](https://aws.amazon.com/dynamodb/reserved-capacity/).

Ao comprar a capacidade reservada do DynamoDB, você realiza um único pagamento antecipado parcial e recebe uma taxa horária reduzida pelo uso provisionado. Você paga por todo o uso provisionado comprometido, independentemente do uso real; portanto, a redução de custos está estreitamente ligada ao uso. Qualquer capacidade que você provisionar além da capacidade reservada comprada será cobrada de acordo com as taxas de capacidade provisionada padrão. Ao reservar suas unidades de capacidade de leitura e gravação com antecedência, há economia de custo significativa nos custos de capacidade provisionada.

Não é permitido vender, cancelar nem transferir a capacidade reservada para outra região ou conta.

# Noções básicas sobre o throughput a quente do DynamoDB
<a name="warm-throughput"></a>

*Throughput a quente* refere-se ao número de operações de leitura e de gravação que sua tabela do DynamoDB pode comportar instantaneamente. Esses valores estão disponíveis por padrão para todas as tabelas e índices secundários globais (GSI) e representam o quanto eles foram ajustados com base no histórico de uso. Se você estiver usando o modo sob demanda ou se atualizar o throughput provisionado para esses valores, sua aplicação poderá emitir solicitações até esses valores instantaneamente.

O DynamoDB ajustará automaticamente os valores de throughput a quente à medida que o uso aumentar. Você também pode aumentar esses valores de maneira proativa quando necessário, o que é especialmente útil para eventos de pico futuros, como lançamentos de produtos ou vendas. Em relação a eventos de pico planejados, nos quais as taxas de solicitação para sua tabela do DynamoDB podem aumentar em 10x, 100x ou mais, agora você pode avaliar se o throughput a quente atual é suficiente para lidar com o tráfego esperado. Caso não seja, você poderá aumentar o valor de throughput a quente sem alterar suas configurações de throughput nem o [modo de faturamento](capacity-mode.md). Esse processo é conhecido como *preaquecimento* de uma tabela. Ele permite que você defina uma linha de base que suas tabelas possam comportar instantaneamente. Isso garante que as aplicações possam lidar com taxas de solicitação mais altas a partir do momento em que elas ocorrem. Depois de aumentados, os valores de taxa de throughput a quente não podem ser diminuídos.

É possível aumentar o valor do throughput a quente para operações de leitura, de gravação ou ambas. É possível aumentar esse valor para tabelas de região única novas e existentes, tabelas globais e GSIs. Em relação a tabelas globais, esse recurso está disponível para a [versão 2019.11.21 (atual)](GlobalTables.md), e as configurações de throughput a quente que você definir serão aplicadas automaticamente a todas as tabelas de réplica na tabela global. Não há limite para o número de tabelas do DynamoDB que você pode preaquecer a qualquer momento. O tempo para concluir o preaquecimento depende dos valores definidos e do tamanho da tabela ou do índice. É possível enviar solicitações simultâneas de preaquecimento, e essas solicitações não interferirão em nenhuma operação da tabela. É possível preaquecer a tabela até o limite de cota de tabela ou do índice da sua conta nessa região. Use o [console do Service Quotas](https://console.aws.amazon.com/servicequotas) para conferir seus limites atuais e aumentá-los, se necessário. 

Os valores de throughput a quente estão disponíveis por padrão para todas as tabelas e índices secundários, sem nenhum custo. No entanto, se você aumentar proativamente esses valores padrão de throughput a quente para preaquecer as tabelas, haverá cobranças por essas solicitações. Para obter mais informações, consulte a [Definição de preço do Amazon DynamoDB](https://aws.amazon.com/dynamodb/pricing/).

Para ter mais informações sobre throughput a quente, consulte os seguintes tópicos:

**Topics**
+ [Conferir o throughput a quente atual da tabela do DynamoDB](check-warm-throughput.md)
+ [Aumentar o throughput a quente de sua tabela existente do DynamoDB](update-warm-throughput.md)
+ [Criar uma tabela do DynamoDB com um throughput a quente mais alto](create-table-warm-throughput.md)
+ [Noções básicas sobre throughput a quente do DynamoDB em diferentes cenários](warm-throughput-scenarios.md)

# Conferir o throughput a quente atual da tabela do DynamoDB
<a name="check-warm-throughput"></a>

Use as instruções a seguir da AWS CLI e do console da AWS para conferir o valor atual do throughput a quente da tabela ou do índice.

## Console de gerenciamento da AWS
<a name="warm-throughput-check-console"></a>

Para conferir o throughput a quente da sua tabela do DynamoDB usando o console do DynamoDB:

1. Faça login no Console de gerenciamento da AWS e abra o console do DynamoDB em [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/).

1. No painel de navegação à esquerda, selecione Tables (Tabelas).

1. Na página **Tabelas**, escolha a tabela desejada.

1. Selecione **Configurações adicionais** para visualizar o valor atual do throughput a quente. Esse valor é mostrado como unidades de leitura e de gravação por segundo.

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

O exemplo da AWS CLI a seguir mostra como conferir o throughput a quente da tabela do DynamoDB.

1. Execute a operação `describe-table` na tabela do DynamoDB.

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

1. Você receberá uma resposta semelhante à seguinte. Suas configurações de `WarmThroughput` serão exibidas como `ReadUnitsPerSecond` e `WriteUnitsPerSecond`. O `Status` será `UPDATING` quando o valor de throughput a quente estiver sendo atualizado, e `ACTIVE` quando o novo valor de throughput a quente for definido.

   ```
   {
       "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"
           }
       }
   }
   ```

# Aumentar o throughput a quente de sua tabela existente do DynamoDB
<a name="update-warm-throughput"></a>

Depois de conferir o valor atual do throughput a quente da tabela do DynamoDB, você poderá atualizá-lo por meio das seguintes etapas:

## Console de gerenciamento da AWS
<a name="warm-throughput-update-console"></a>

Para conferir o throughput a quente da sua tabela do DynamoDB usando o console do DynamoDB:

1. Faça login no Console de gerenciamento da AWS e abra o console do DynamoDB em [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/).

1. No painel de navegação à esquerda, selecione Tables (Tabelas).

1. Na página **Tabelas**, escolha a tabela desejada.

1. No campo **Throughput a quente**, selecione **Editar**.

1. Na página **Editar throughput a quente**, escolha **Aumentar throughput a quente**.

1. Ajuste as **unidades de leitura por segundo** e **unidades de gravação por segundo**. Essas duas configurações definem o throughput que sua tabela pode processar instantaneamente.

1. Selecione **Salvar**.

1. Suas **unidades de leitura por segundo** e **unidades de gravação por segundo** serão atualizadas no campo **Throughput a quente** quando o processamento da solicitação for concluído.
**nota**  
Atualizar o valor de throughput a quente é uma tarefa assíncrona. O `Status` mudará de `UPDATING` para `ACTIVE` quando a atualização for concluída.

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

O exemplo de AWS CLI a seguir mostra como atualizar o valor de throughput a quente da tabela do DynamoDB.

1. Execute a operação `update-table` na tabela do 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. Você receberá uma resposta semelhante à seguinte. Suas configurações de `WarmThroughput` serão exibidas como `ReadUnitsPerSecond` e `WriteUnitsPerSecond`. O `Status` será `UPDATING` quando o valor de throughput a quente estiver sendo atualizado, e `ACTIVE` quando o novo valor de throughput a quente for definido.

   ```
   {
       "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>

Os exemplos de SDK a seguir mostram como atualizar o valor de throughput a quente da tabela do 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;
  }
}
```

------

# Criar uma tabela do DynamoDB com um throughput a quente mais alto
<a name="create-table-warm-throughput"></a>

É possível ajustar os valores de throughput a quente ao criar sua tabela do DynamoDB seguindo as etapas abaixo. Essas etapas também se aplicam ao criar uma [tabela global](GlobalTables.md) ou um [índice secundário](SecondaryIndexes.md).

## Console de gerenciamento da AWS
<a name="warm-throughput-create-console"></a>

Para criar uma tabela do DynamoDB e ajustar os valores de throughput a quente por meio do console:

1. Faça login no Console de gerenciamento da AWS e abra o console do DynamoDB em [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/).

1. Selecione **Criar tabela**.

1. Escolha o **Nome da tabela**, a **Chave de partição** e a **Chave de classificação (opcional)**.

1. Em **Configurações da tabela**, selecione **Personalizar configurações**.

1. No campo **Throughput a quente**, escolha **Aumentar throughput a quente**.

1. Ajuste as **unidades de leitura por segundo** e **unidades de gravação por segundo**. Essas duas configurações definem o throughput máximo que sua tabela pode processar instantaneamente.

1. Continue adicionando os detalhes restantes da tabela e selecione **Criar tabela**.

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

O exemplo da AWS CLI a seguir mostra como criar uma tabela do DynamoDB com valores personalizados de throughput a quente.

1. Execute a operação `create-table` para criar a tabela do DynamoDB a seguir.

   ```
   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. Você receberá uma resposta semelhante à seguinte. Suas configurações de `WarmThroughput` serão exibidas como `ReadUnitsPerSecond` e `WriteUnitsPerSecond`. O `Status` será `UPDATING` quando o valor de throughput a quente estiver sendo atualizado, e `ACTIVE` quando o novo valor de throughput a quente for definido.

   ```
   {
       "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>

Os exemplos de SDK a seguir mostram como criar uma tabela do DynamoDB com valores personalizados de throughput a quente.

------
#### [ 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;
  }
}
```

------

# Noções básicas sobre throughput a quente do DynamoDB em diferentes cenários
<a name="warm-throughput-scenarios"></a>

Veja a seguir alguns cenários diferentes que você pode encontrar ao trabalhar com o throughput a quente do DynamoDB.

**Topics**
+ [Throughput a quente e padrões de acesso desiguais](#warm-throughput-scenarios-uneven)
+ [Throughput a quente para uma tabela provisionada](#warm-throughput-scenarios-provisioned)
+ [Throughput a quente para uma tabela sob demanda](#warm-throughput-scenarios-ondemand)
+ [Throughput a quente para uma tabela sob demanda com throughput máximo configurado](#warm-throughput-scenarios-max)

## Throughput a quente e padrões de acesso desiguais
<a name="warm-throughput-scenarios-uneven"></a>

Uma tabela pode ter um throughput a quente de 30 mil unidades de leitura por segundo e 10 mil unidades de gravação por segundo, mas você ainda pode experimentar controle de utilização em leituras ou gravações antes de atingir esses valores. Isso provavelmente se deve a uma partição sobrecarregada. Embora o DynamoDB possa continuar a escalar para comportar um throughput praticamente ilimitado, cada partição individual é limitada a mil unidades de gravação por segundo e 3 mil unidades de leitura por segundo. Se a aplicação direcionar muito tráfego para uma pequena parte das partições da tabela, poderá ocorrer controle de utilização mesmo antes de você atingir os valores de throughput a quente da tabela. Recomendamos seguir as [práticas recomendadas do DynamoDB](bp-partition-key-design.md) para garantir uma escalabilidade perfeita e evitar partições sobrecarregadas.

## Throughput a quente para uma tabela provisionada
<a name="warm-throughput-scenarios-provisioned"></a>

Pense em uma tabela provisionada que tenha um throughput a quente de 30 mil unidades de leitura por segundo e 10 mil unidades de gravação por segundo, mas que atualmente tenha um throughput provisionado de 4 mil RCU e 8 mil WCU. É possível escalar instantaneamente o throughput provisionado da tabela até 30 mil RCU ou 10 mil WCU atualizando suas configurações de throughput provisionado. À medida que você aumenta o throughput provisionado além desses valores, o throughput a quente se ajustará automaticamente aos novos valores mais altos, porque você estabeleceu um novo throughput de pico. Por exemplo, se você definir o throughput provisionado para 50 mil RCU, o throughput a quente aumentará para 50 mil unidades de leitura por segundo.

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

## Throughput a quente para uma tabela sob demanda
<a name="warm-throughput-scenarios-ondemand"></a>

Uma nova tabela sob demanda começa com um throughput a quente de 12 mil unidades de leitura por segundo e 4 mil unidades de gravação por segundo. Sua tabela pode acomodar instantaneamente o tráfego sustentado até esses níveis. Quando suas solicitações excederem 12 mil unidades de leitura por segundo ou 4 mil unidades de gravação por segundo, o throughput a quente se ajustará automaticamente a valores mais altos.

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

## Throughput a quente para uma tabela sob demanda com throughput máximo configurado
<a name="warm-throughput-scenarios-max"></a>

Pense em uma tabela sob demanda com um throughput a quente de 30 mil unidades de leitura por segundo, mas com um [throughput máximo](on-demand-capacity-mode-max-throughput.md) configurado em 5 mil unidades de solicitação de leitura (RRU). Nesse cenário, o throughput da tabela será limitado ao máximo de 5 mil RRU que você definiu. Qualquer solicitação de throughput que exceda esse máximo terá controle de utilização. No entanto, é possível modificar o throughput máximo específico da tabela a qualquer momento, com base nas necessidades da aplicação.

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

# Capacidade de expansão e capacidade adaptável do DynamoDB
<a name="burst-adaptive-capacity"></a>

Para minimizar o controle de utilização decorrente de exceções de throughput, o DynamoDB usa a *capacidade de expansão* para lidar com picos de uso. O DynamoDB usa a *capacidade adaptável* para ajudar a acomodar padrões de acesso desiguais.

## Capacidade de expansão
<a name="burst-capacity"></a>

O DynamoDB fornece alguma flexibilidade para o provisionamento de throughput com *capacidade de expansão*. Quando você não está usando totalmente o throughput disponível, o DynamoDB reserva uma parte dessa capacidade não utilizada para *expansões* posteriores do throughput com o objetivo de lidar com os picos de uso. Com a capacidade de expansão, as solicitações de leitura ou gravação inesperadas podem ter êxito onde, de outra forma, seriam limitadas.

O DynamoDB retém até cinco minutos (trezentos segundos) de capacidade de leitura e de gravação não utilizada. Durante uma expansão ocasional de atividades de leitura e de gravação, essas unidades de capacidade extra podem ser consumidas muito rapidamente, ainda mais depressa do que a capacidade de throughput provisionado por segundo que você definiu para a tabela.

O DynamoDB também pode consumir capacidade de intermitência para manutenção em segundo plano e para outras tarefas sem aviso prévio.

Note que esses detalhes da capacidade de intermitência podem mudar no futuro.

## Capacidade adaptável
<a name="adaptive-capacity"></a>

O DynamoDB distribui automaticamente os dados entre as [partições](HowItWorks.Partitions.md), armazenando-os em vários servidores na Nuvem AWS. Nem sempre é possível distribuir a atividade de leitura e de gravação uniformemente o tempo todo. Quando o acesso aos dados é desequilibrado, uma partição "dinâmica" pode receber um volume mais alto de tráfego de leitura e gravação em comparação com outras partições. Como as operações de leitura e de gravação em uma partição são gerenciadas de forma independente, haverá controle de utilização se uma única partição receber mais de três mil operações de leitura ou mais de mil operações de gravação. A capacidade adaptável funciona por meio do aumento automático da capacidade de throughput para as partições que recebem mais tráfego.

 Para acomodar melhor padrões desiguais de acesso, a capacidade adaptável do DynamoDB permite que a aplicação continue a ler e gravar em partições dinâmicas sem ser limitado, desde que o tráfego não exceda a capacidade total provisionada da tabela ou a capacidade máxima da partição. A capacidade adaptável funciona por meio do aumento automático e instantâneo da capacidade de throughput para as partições que recebem mais tráfego.

O diagrama a seguir mostra como a capacidade adaptável funciona. A tabela de exemplo é provisionada com 400 WCUs compartilhadas uniformemente em quatro partições, permitindo que cada partição comporte até 100 WCUs por segundo. As partições 1, 2 e 3 recebem tráfego de gravação de 50 WCU/s. Partição 4 recebe 150 WCU/s. Essa partição dinâmica poderá aceitar tráfego de gravação enquanto tiver capacidade não utilizada, mas em algum momento limitará o tráfego que exceder 100 WCU/s.

A capacidade adaptável do DynamoDB responde por meio do aumento da capacidade da partição 4 para que ela comporte uma workload maior de 150 WCUs/s sem controle de utilização.

![\[A capacidade adaptável aumenta automaticamente o throughput da partição 4 com tráfego mais alto para evitar o controle de utilização.\]](http://docs.aws.amazon.com/pt_br/amazondynamodb/latest/developerguide/images/adaptive-capacity.png)


A capacidade adaptável é habilitada automaticamente para todas as tabelas do DynamoDB sem custo adicional. Não é necessário habilitá-la ou desabilitá-la explicitamente.

### Isolar itens acessados com frequência
<a name="isolate-frequent-access-items"></a>

Se o aplicativo direcionar tráfego desproporcionalmente alto para um ou mais itens, a capacidade adaptável reequilibrará as partições de modo que os itens acessados ​​com frequência não residam na mesma partição. Esse isolamento dos itens acessados com frequência reduz a probabilidade da limitação de solicitação devido à workload exceder a cota de throughput em uma única partição. Você também pode dividir um conjunto de itens em segmentos por chave de classificação, desde que esse conjunto não seja um tráfego rastreado por uma diminuição ou um aumento monotônico da chave de classificação.

Se a aplicação direciona alto tráfego constantemente a um único item, a capacidade adaptável poderá reequilibrar os dados de modo que uma partição contenha somente esse único item acessado com frequência. Nesse caso, o DynamoDB pode entregar um throughput de no máximo de 3 mil RCUs da partição ou mil WCUs para a chave primária desse único item. A capacidade adaptável não dividirá as coleções de itens em várias partições da tabela quando houver um [índice secundário local](LSI.md) na tabela.

# Considerações ao alternar os modos de capacidade no DynamoDB
<a name="bp-switching-capacity-modes"></a>

Ao criar uma tabela do DynamoDB, é necessário selecionar o modo de capacidade sob demanda ou provisionada.

É possível alternar as tabelas do modo de capacidade provisionada para o modo sob demanda até quatro vezes em um período contínuo de 24 horas. É possível alternar as tabelas do modo sob demanda para o modo de capacidade provisionada a qualquer momento. 

**Topics**
+ [Alternar do modo de capacidade provisionada para o modo de capacidade sob demanda](#switch-provisioned-to-ondemand)
+ [Alternar do modo de capacidade sob demanda para o modo de capacidade provisionada](#switch-ondemand-to-provisioned)

## Alternar do modo de capacidade provisionada para o modo de capacidade sob demanda
<a name="switch-provisioned-to-ondemand"></a>

No modo provisionado, você define a capacidade de leitura e de gravação com base nas necessidades esperadas da aplicação. Quando você atualiza uma tabela de um modo sob demanda provisionado, não é necessário especificar o throughput de leitura e gravação que você espera que seu aplicativo execute. O DynamoDB sob demanda oferece o modelo de preço de pagamento por solicitação (de leitura e de gravação) para que você pague apenas pelo que usar, o que permite contrabalançar com facilidade custos e performance. Você também pode configurar o throughput máximo de leitura ou de gravação (ou de ambas) para tabelas individuais sob demanda e índices secundários globais associados a fim de ajudar a limitar os custos e o uso. Para ter mais informações sobre como definir o throughput máximo para uma tabela ou um índice específico, consulte [Throughput máximo do DynamoDB para tabelas sob demanda](on-demand-capacity-mode-max-throughput.md).

Quando se altera o modo de capacidade provisionado para o modo de capacidade sob demanda, o DynamoDB faz várias alterações na estrutura da tabela e das partições. Esse processo pode levar alguns minutos. Durante o período de troca, sua tabela entrega throughput que é consistente com as unidades de valor de capacidade de gravação provisionada anteriormente e unidade de capacidade de leitura.

### Throughput inicial para modo de capacidade sob demanda
<a name="initial-throughput-ondemand-mode"></a>

Se recentemente você tiver alterado uma tabela existente para o modo de capacidade sob demanda pela primeira vez, ela terá as configurações de pico anterior a seguir, mesmo se não tiver apresentado tráfego anteriormente usando o modo de capacidade sob demanda.

Veja a seguir exemplos de possíveis cenários:
+ **Qualquer tabela provisionada configurada abaixo de 4.000 WCUs e 12.000 RCUs, que nunca tenha sido provisionada anteriormente para mais.** Quando essa tabela for alterada para sob demanda pela primeira vez, o DynamoDB garantirá que ela aumente a escala horizontalmente para comportar instantaneamente pelo menos 4.000 WCUs/segundo e 12.000 RCUs/segundo.
+ **Uma tabela provisionada configurada como 8.000 WCUs e 24.000 RCUs.** Ao alterar essa tabela para sob demanda, ela continuará comportando pelo menos 8.000 WCUs/segundo e 24.000 RCUs/segundo a qualquer momento.
+ **Uma tabela provisionada configurada com 8 mil WCU e 24 mil RCU, que consumiu 6 mil unidades de gravação/segundo e 18 mil unidades de leitura/segundo por um período prolongado.** Ao alterar essa tabela para sob demanda, ela continuará comportando pelo menos 8.000 WCUs/segundo e 24.000 RCUs/segundo. O tráfego anterior pode ainda permitir que a tabela sustente níveis muito mais altos de tráfego sem controle de utilização.
+ **Uma tabela anteriormente provisionada com 10 mil WCU e 10 mil RCU, mas atualmente provisionada com 10 RCU e 10 WCU.** Ao alterar essa tabela para sob demanda, ela poderá comportar pelo menos 10.000 WCUs/segundo e 10.000 RCUs/segundo.

### Configurações de ajuste de escala automático
<a name="autoscaling-settings"></a>

Quando você atualiza uma tabela do modo provisionado para sob demanda:
+ Se estiver usando o console, todas as suas configurações de Auto Scaling (se houver alguma) serão excluídas.
+ Se estiver usando a AWS CLI ou o AWS SDK, todas as suas configurações de Auto Scaling serão preservadas. Essas configurações podem ser aplicadas quando você atualiza sua tabela para o modo de cobrança provisionado novamente.

### Modo de capacidade de edição em massa no [console do DynamoDB](https://console.aws.amazon.com/dynamodb).
<a name="bulk-edit-capacity-mode"></a>

É possível editar em massa várias tabelas para alternar do modo de capacidade provisionada para o modo de capacidade sob demanda usando o [console do DynamoDB](https://console.aws.amazon.com/dynamodb). Para editar em massa o modo de capacidade:

1. No console do DynamoDB, acesse a página **Tabelas**.

1. Marque as caixas de seleção das tabelas que você deseja atualizar para o modo de capacidade sob demanda.

1. Escolha **Ações** e selecione **Atualização para o modo de capacidade sob demanda**.

Essa operação em massa permite alternar várias tabelas com eficiência para o modo de capacidade sob demanda sem precisar atualizar cada tabela individualmente.

## Alternar do modo de capacidade sob demanda para o modo de capacidade provisionada
<a name="switch-ondemand-to-provisioned"></a>

Ao voltar para o modo de capacidade sob demanda para modo de capacidade provisionado, sua tabela entrega um throughput consistente com o pico anterior alcançado quando a tabela foi definida como modo de capacidade sob demanda.

### Gerenciamento da capacidade
<a name="switch-ondemand-capacity"></a>

Considere o seguinte ao atualizar uma tabela de modo sob demanda para provisionado:
+  Se estiver usando a AWS CLI ou o AWS SDK, escolha as configurações de capacidade provisionadas certas de sua tabela e índices secundários globais usando o Amazon CloudWatch para procurar seu consumo histórico (métricas `ConsumedWriteCapacityUnits` e `ConsumedReadCapacityUnits`) para determinar as novas configurações de throughput.
**nota**  
Se você estiver alternando uma tabela global para o modo provisionado, examine o consumo máximo entre todas as suas réplicas regionais para tabelas de base e índices secundários globais ao determinar as novas configurações de throughput. 
+ Se você estiver alterando o modo sob demanda de volta para o modo provisionado, não se esqueça de definir as unidades provisionadas iniciais como um valor alto o suficiente para lidar com a capacidade da tabela ou do índice durante a transição.

### Gerenciar o Auto Scaling
<a name="switch-ondemand-autoscaling"></a>

Quando você atualiza uma tabela do modo sob demanda para provisionado:
+ Se estiver usando o console, recomendamos habilitar o ajuste de escala automático com os seguintes padrões:
  + Utilização pretendida: 70%
  + Capacidade provisionada mínima: 5 unidades
  + Capacidade máxima provisionada: o máximo da região
+  Se estiver usando a AWS CLI ou o SDK, suas configurações anteriores de Auto Scaling (se houver) serão preservadas.