Cenários de alto desempenho e otimização de custos

Cenário: O banco de dados RDS MySQL de um site de notícias atende a 90% de tráfego de leitura de conteúdo de artigos que muda no máximo uma vez por hora. A CPU do banco de dados tem média de 80%, os custos estão aumentando e a latência é de 200 ms por consulta. Solução: Adicione um cluster ElastiCache Redis na frente do RDS usando o padrão de carregamento lento (cache à parte). A aplicação verifica primeiro o cache — quando encontra o conteúdo no cache, retorna o artigo armazenado em menos de 1 ms. Quando não encontra, consulta o RDS, retorna o resultado e grava-o no cache com um TTL de 1 hora. Resultado esperado: taxa de acerto do cache de 90%, CPU do RDS abaixo de 20% e latência inferior a 5 ms para respostas armazenadas em cache.

Cenário: Usuários da região Ásia-Pacífico enfrentam tempos de carregamento de 2 a 4 segundos para uma aplicação web hospedada no EC2 em us-east-1. A aplicação fornece recursos estáticos grandes (imagens, JS, CSS). Solução: Coloque uma distribuição do CloudFront na frente do ALB. Configure um comportamento de cache para o caminho /static/* com um TTL longo (por exemplo, 1 semana), para que os arquivos estáticos sejam armazenados em cache nos locais de borda do CloudFront próximos aos usuários na Ásia. As solicitações dinâmicas da API ignoram o cache com TTL=0. Os usuários asiáticos carregam os recursos estáticos de um local de borda em Singapura ou Tóquio em menos de 100 ms, em vez de esperar pelas viagens de ida e volta até us-east-1.

Cenário: Uma empresa tem 500 instâncias EC2, muitas provisionadas há 3 anos com tipos de instância grandes. A fatura da AWS é alta, mas a empresa não sabe quais instâncias estão superdimensionadas. Solução: Habilite o AWS Compute Optimizer (gratuito, usa 14 dias de métricas do CloudWatch). O Compute Optimizer analisa a utilização real de CPU, memória, rede e disco de cada instância e fornece recomendações para dimensioná-las corretamente. Uma t3.xlarge com média de 8% de CPU receberia a recomendação de redução para t3.small. Aplicar as recomendações em 500 instâncias normalmente reduz os custos do EC2 em 20% a 40%.

Cenário: Uma empresa de genômica executa trabalhos em lote noturnos que levam 8 horas e podem ser repetidos se forem interrompidos. O custo mensal sob demanda do EC2 para esses trabalhos é de US$ 10.000. Solução: Use EC2 Spot Instances para a frota de processamento em lote. As Spot Instances são capacidade não utilizada do EC2, disponível com descontos de até 90%. Para trabalhos em lote tolerantes a interrupções, use o AWS Batch, que coloca automaticamente na fila novamente os trabalhos Spot com falha e usa uma frota mista (Spot + um fallback mínimo sob demanda). Economia esperada: redução de 70% a 90% nos custos de computação — de US$ 10.000 para US$ 1.000–3.000 por mês.

Cenário: Um placar de jogos usa o DynamoDB com throughput provisionado. Durante os lançamentos de jogos, o tráfego aumenta 50 vezes e a tabela limita as solicitações. Fora dos lançamentos, o throughput é quase zero — a capacidade provisionada é desperdiçada. Solução: Mude o DynamoDB para o modo de capacidade On-Demand. O On-Demand escala instantaneamente para qualquer throughput sem planejamento manual de capacidade e cobra por solicitação, em vez de cobrar por unidade provisionada. Você paga apenas pelas solicitações realizadas — sem custo de capacidade ociosa entre os lançamentos. O On-Demand troca um custo ligeiramente maior por solicitação pela garantia de não haver limitação de solicitações e pela ausência de gerenciamento de capacidade.

Cenário: Uma empresa armazena milhões de imagens geradas por usuários no S3 Standard. Os padrões de acesso variam de forma imprevisível — algumas imagens são acessadas diariamente, enquanto outras não são acessadas por meses. A empresa deseja reduzir os custos de armazenamento sem gerenciar manualmente as políticas de ciclo de vida. Solução: Use o S3 Intelligent-Tiering. Ele move automaticamente os objetos entre níveis com base nos padrões de acesso: acesso frequente (Standard), acesso infrequente (30 dias ou mais sem acesso), acesso instantâneo ao arquivo (90 dias ou mais) e acesso ao arquivo (90 dias ou mais, mediante adesão). Não há taxas de recuperação dentro do Intelligent-Tiering. A cobrança de monitoramento é de US$ 0,0025 por 1.000 objetos por mês — um valor insignificante para grandes conjuntos de dados.

Cenário: Uma startup deseja consultar tabelas de um lago de dados no S3. Ela executa cerca de 10 consultas ad hoc por semana. Um fornecedor propõe o Amazon Redshift com um cluster dc2.large. Solução para uma startup: Comece com o Amazon Athena — custo zero de infraestrutura, pagando apenas pelos dados examinados (cerca de US$ 5/TB). Dez consultas por semana em dados Parquet bem particionados podem custar menos de US$ 5 por mês. O Redshift dc2.large custa cerca de US$ 180 por mês continuamente. O Redshift só se torna economicamente vantajoso quando a concorrência de consultas é alta (50 ou mais consultas por dia) ou quando é necessária uma resposta em menos de um segundo. A expressão-chave “ad hoc, infrequente” aponta claramente para o Athena.

Cenário: Um servidor de banco de dados relacional exige 64.000 IOPS com baixa latência consistente. O volume EBS gp3 atual está atingindo seu limite de IOPS. Solução: Faça a atualização para o io2 Block Express (tipo de volume EBS desenvolvido para bancos de dados com uso intensivo de E/S). O io2 Block Express é compatível com até 256.000 IOPS por volume e latência inferior a um milissegundo. Ele é mais caro que o gp3 (US$ 0,125/GB + US$ 0,065 por IOPS provisionada/mês), mas é a única opção de EBS que atende aos requisitos de 64.000 ou mais IOPS. Para cargas de trabalho de banco de dados críticas em termos de latência, nas quais o limite de 16.000 IOPS do gp3 é insuficiente, o io2 é a única escolha viável de EBS.

Cenário: Uma empresa executa continuamente 20 instâncias r6i.4xlarge do EC2 para um aplicativo de produção e não prevê mudanças nos requisitos durante 3 anos. Os gastos atuais sob demanda são de US$ 80.000 por ano para essas instâncias. Solução: Compre Standard Reserved Instances de 3 anos (ou Compute Savings Plans) com pagamento integral antecipado (All Upfront) para obter o desconto máximo. As Standard Reserved Instances oferecem até 72% de desconto em comparação com o uso sob demanda. As instâncias são executadas 24 horas por dia, 7 dias por semana, com uma carga de trabalho previsível — o perfil clássico para Reserved Instances. Redução de custo esperada: US$ 80.000 × 0,72 = US$ 22.400 por ano em comparação com US$ 80.000 por ano sob demanda — uma economia de US$ 57.600 por ano.

Cenário: Uma empresa executa uma API REST em uma instância t3.micro do EC2 que custa US$ 8 por mês. A API recebe 1 milhão de solicitações por mês, e cada uma leva 100 ms para ser processada. A equipe pergunta se o Lambda seria mais barato. Análise: Preços do Lambda: 1.000.000 de solicitações × US$ 0,0000002 = US$ 0,20 (custo das solicitações) + 1.000.000 × 0,1 s × memória de 128 MB × tarifa = cerca de US$ 1,67 (custo computacional) = cerca de US$ 1,87 por mês. O Lambda é mais barato que o EC2 para essa API de baixo tráfego. À medida que o tráfego ultrapassa cerca de 40 milhões de solicitações por mês, o EC2 se torna mais barato. Use a Calculadora de custos do Lambda para encontrar o ponto de equilíbrio de cada carga de trabalho.

Cenário: Uma API global que atende usuários na Europa, nos US e na Ásia apresenta latência inconsistente porque o tráfego percorre caminhos imprevisíveis na internet. O CloudFront foi considerado, mas as respostas da API são dinâmicas e não podem ser armazenadas em cache. Solução: Use o AWS Global Accelerator. Ele fornece dois endereços IP anycast estáticos globalmente. O tráfego do usuário entra na rede global da AWS pelo local de borda da AWS mais próximo e percorre a rede privada da AWS até a origem na Region de destino, evitando o trecho intermediário congestionado da internet pública. O Global Accelerator melhora o tempo de resposta de APIs dinâmicas em 20% a 60% e fornece failover imediato quando um Endpoint de uma Region fica não íntegro.

Nesta lição, você trabalhou com cenários que abordaram: carregamento lento do ElastiCache para reduzir o uso de CPU do RDS de 80% para 20%, Spot Instances e AWS Batch para economizar de 70% a 90% nos custos de trabalhos em lote, Athena para consultas ad hoc infrequentes em comparação com Redshift para análises com alta concorrência e S3 Intelligent-Tiering para padrões de acesso imprevisíveis sem taxas de recuperação. A seguir, temos o projeto final: um mini exame cronometrado com domínios variados para medir seu nível de preparação.