No exame SAA-C03, a otimizacao de custos de banco de dados se resume a dois principios: escolha o modo de capacidade correto para seu padrao de carga de trabalho e use cache para reduzir a carga no banco de dados. Manter uma instancia rodando em capacidade total o tempo todo nem sempre e a melhor abordagem — adaptar seu modelo de cobranca aos seus padroes de uso reais pode gerar economias significativas.
O que e Aurora Serverless v2?
Por que existe? Bancos de dados tradicionais cobram voce pela instancia quer alguem a use ou nao. Para servicos com trafego imprevisivelou intermitente, isso significa pagar por muito tempo ocioso.
O que e? Pense em um medidor de eletricidade. Quando voce usa muita energia, o medidor gira rapido. Quando ninguem esta em casa, ele quase para. O Aurora Serverless v2 funciona da mesma forma. Quando o trafego aumenta, a capacidade escala automaticamente para cima. Quando as coisas ficam quietas, a capacidade reduz de volta a quase zero. Voce paga apenas pela capacidade de computacao que realmente consome.
Como funciona? A capacidade e medida em ACUs (Aurora Capacity Units). Voce define um ACU minimo e maximo. O Aurora ajusta automaticamente dentro desse intervalo. Defina o minimo como 0,5 ACU e o tempo ocioso custara quase nada.
Quando usar: Ambientes de desenvolvimento e teste que ficam ociosos a noite e nos fins de semana Aplicacoes SaaS pequenas com baixo numero de usuarios ou variavel Geracao de relatorios ou servicos baseados em eventos que ocasionalmente recebem grandes rafadas de trafego
Aurora Provisionado vs Aurora Serverless v2
| Item | Aurora Provisionado | Aurora Serverless v2 | |------|--------------------|--------------------| | Cobranca | Tamanho da instancia (por hora) | Uso de ACU (por segundo) | | Padrao de trafego | Previsivel e estavel | Intermitente ou imprevisivelv | | Custo ocioso | Sempre gerado | Quase zero | | Auto-escalonamento | Configuracao manual | Automatico |
Dica: Se seu trafego e estavel e previsivel, o Aurora Provisionado com Reserved Instances sera mais barato do que Serverless.
!Aurora provisionado vs Aurora Serverless v2
Modos de capacidade do DynamoDB
Por que existem? Os custos do DynamoDB escalam diretamente com o numero de solicitacoes de leitura e escrita. Conhecer seu padrao de trafego permite escolher o modelo de cobranca que minimiza sua fatura.
O que sao? O DynamoDB oferece dois modos de capacidade.
Capacidade Provisionada: Voce define o numero de Unidades de Capacidade de Leitura (RCU) e Unidades de Capacidade de Escrita (WCU) com antecedencia. Como escolher um plano de internet mensal — voce se compromete com "100 GB por mes." Melhor para trafego estavel e previsivel. Combine com Auto Scaling para lidar com variacoes de trafego automaticamente enquanto mantém os custos baixos. Compre Capacidade Reservada para ate 76% de desconto.
Capacidade Sob Demanda: Voce paga por solicitacao, com base no trafego real. Como um plano de dados pre-pago — voce paga exatamente pelo que usa. Melhor para trafego imprevisivel ou novos servicos onde ainda nao foram estabelecidos padroes de uso. Nao requer planejamento de capacidade, mas o preco por solicitacao e mais alto do que o Provisionado.
| Modo | Melhor Para | Preco Unitario | Previsibilidade do Custo | |------|------------|----------------|--------------------------| | Provisionado + Reservado | Trafego estavel e previsivel | Baixo | Facil | | Provisionado + Auto Scaling | Trafego variavel mas previsivel | Baixo a medio | Medio | | Sob Demanda | Trafego irregular e intermitente | Alto | Dificil |
Reduzindo custos de banco de dados com cache
Por que existe? Os custos do banco de dados escalam com o numero de solicitacoes de leitura e escrita. Buscar os mesmos dados do banco de dados repetidamente e um desperdicio. Armazenar dados lidos com frequencia em um cache rapido reduz as solicitacoes ao banco de dados e, portanto, os custos.
Imagine uma sorveteria. Toda vez que um cliente pergunta "Qual e o sabor popular de hoje?", o atendente do balcao vai ao deposito verificar o estoque. Isso e lento e cansativo. Mas se houver um quadro no balcao dizendo "Escolha de hoje: chocolate," o atendente pode responder imediatamente sem ir ao deposito. Esse quadro e o seu cache.
ElastiCache for Redis
O que e? Um armazenamento de dados em memoria de alto desempenho. Resultados de consultas frequentes do banco de dados sao armazenados na memoria. Quando a mesma solicitacao chega novamente, o Redis responde instantaneamente do cache em vez de acessar o banco de dados.
Quando usar: Gerenciamento de sessao (manter usuarios conectados) Cache de resultados de consultas complexas Tabelas de classificacao em tempo real e contadores Ambientes de alta disponibilidade que requerem replicacao e suporte a cluster
ElastiCache for Memcached
O que e? Um cache simples de chave-valor. Menos recursos do que Redis, mas sua arquitetura multi-thread oferece alto throughput para casos de uso de cache simples.
Quando usar: Cache de objetos simples Ambientes de alto throughput que precisam de processamento multi-thread Quando nao e necessaria replicacao ou persistencia de dados
DynamoDB DAX (DynamoDB Accelerator)
Por que existe? Quando voce usa DynamoDB mas os custos de leitura sao altos ou os tempos de resposta sao lentos, voce pode adicionar uma camada de cache com mudancas minimas de codigo.
O que e? Um cache em memoria que fica de forma transparente na frente do DynamoDB. Sua aplicacao chama o endpoint do DAX. Em um acerto de cache, o DAX responde imediatamente. Em um erro de cache, o DAX consulta o DynamoDB, armazena o resultado em cache e o retorna ao solicitante.
Caracteristicas-chave: Apenas para DynamoDB — nao pode ser usado com outros bancos de dados Mudanca de codigo minima (apenas trocar a URL do endpoint) Tempos de resposta em microsegundos (vs milissegundos do DynamoDB)
Otimizacao de custos do RDS
Alem do cache, voce tambem pode otimizar o proprio RDS.
Dimensionamento correto da instancia: Use o AWS Compute Optimizer para revisar a utilizacao real de CPU e memoria de suas instancias RDS Um db.r5.xlarge rodando a 20% de CPU provavelmente pode ser reduzido para db.r5.large
Reserved Instances: Prazo de 1 ano: ate 40% de desconto Prazo de 3 anos: ate 60% de desconto O RDS e frequentemente uma carga de trabalho estavel de longa duracao, tornando as Reserved Instances muito eficazes
Revisao de Multi-AZ: Multi-AZ mantem uma instancia de standby automatica o tempo todo para alta disponibilidade, o que aproximadamente dobra o custo Ambientes de desenvolvimento e teste raramente precisam de alta disponibilidade, entao mudar para Single-AZ reduz o custo pela metade
Combinando Read Replicas com cache: Em vez de executar varias Read Replicas, introduzir uma camada de cache (ElastiCache) pode reduzir o numero de Read Replicas necessarias — economia dupla
Pontos-chave para o exame
"Trafego de BD intermitente ou imprevisivel, minimizar custo ocioso" -- Aurora Serverless v2
"Como um medidor de eletricidade: pague apenas pelo que consome" -- Caracteristica central do Aurora Serverless
"Trafego DynamoDB estavel, menor custo possivel" -- Capacidade Provisionada + Capacidade Reservada
"Trafego DynamoDB irregular, sem necessidade de planejamento de capacidade" -- Modo Sob Demanda
"Reduzir carga de leitura do BD com camada de cache" -- ElastiCache (Redis ou Memcached)
"Cache apenas para DynamoDB, mudancas minimas de codigo" -- DAX
"Redis vs Memcached: precisa de replicacao ou sessoes" -- Redis / "chave-valor simples, multi-thread" -- Memcached
"Reduzir custos de BD em ambientes de desenvolvimento" -- RDS Single-AZ (sem necessidade de Multi-AZ)
"Dimensionar corretamente a instancia RDS" -- AWS Compute Optimizer
Adicionar um cache pode reduzir o numero de Read Replicas, gerando economia dupla