Amazon SAP-C02: Computação e Auto Scaling — Guia de estudos
Faz parte do AWS Solutions Architect Professional SAP-C02 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.
Design, armazenamento e rede de instâncias EC2
O design de instâncias EC2 começa com a correspondência das características da carga de trabalho com as famílias de instâncias, equilibrando vCPU, memória, rede e armazenamento local. Escolha tipos otimizados para computação (C), otimizados para memória (R/X), otimizados para armazenamento (I/D) ou com GPU (P/G) com base no profiling. Utilize instâncias baseadas em Nitro e ENA/SR-IOV para alta taxa de transferência de rede e baixa latência. Para dados temporários sensíveis à latência ou com alto IOPS, considere o instance store (efêmero) em SSDs I3/I4 ou Nitro; para armazenamento em bloco durável, use o EBS com Provisioned IOPS (io2/io2 Block Express) e habilite a criptografia do EBS com o KMS para gerenciamento de chaves. Quando as instâncias estiverem em VPCs atrás de Application Load Balancers, garanta que os ALBs voltados para a internet sejam colocados em sub-redes públicas e que os targets residam em sub-redes privadas; posicionar ALBs incorretamente ou configurar security groups de forma errada é uma armadilha comum. Use Placement Groups (cluster para HPC de baixa latência, partition para sistemas stateful distribuídos em larga escala, spread para isolamento de falhas) para influenciar o posicionamento, mas aceite os trade-offs: o tipo cluster oferece o melhor desempenho, mas reduz a tolerância a falhas no nível de AZ. Para dados criptografados em trânsito, use TLS terminando no ALB ou TLS de ponta a ponta com passthrough do NLB. Os critérios de decisão ponderam o custo versus o desempenho: tipos de instância mais densos reduzem o custo, mas podem aumentar o blast radius e os custos de licenciamento; prefira o right-sizing orientado pelo CloudWatch, AWS Compute Optimizer e testes de carga, em vez de regras práticas.
Auto Scaling Groups, políticas e gerenciamento do ciclo de vida
Os Auto Scaling Groups (ASGs) devem ser projetados para elasticidade, resiliência e eficiência de custos usando uma combinação de launch templates, políticas de instâncias mistas, lifecycle hooks e políticas de escalonamento. Use launch templates para versionar AMI, substituições de tipo de instância, configurações do EBS e user-data; instâncias mistas com alocação Spot otimizada para capacidade ou uma estratégia diversificada reduzem o risco de interrupção e diminuem o custo. Para o comportamento de escalonamento, prefira políticas de target tracking para métricas previsíveis (CPU, contagem de requisições por target) e step scaling quando ações de múltiplos estágios acionadas por limiares forem necessárias; o predictive scaling pode pré-provisionar capacidade para padrões diurnos conhecidos. Implemente lifecycle hooks para executar tarefas de inicialização personalizadas ou de drenagem antes da terminação; combine warm pools para reduzir o tempo para servir e scheduled scaling para linhas de base de horário comercial. As verificações de saúde (health checks) devem integrar os health checks do ELB e do EC2 para evitar substituições prematuras. Fique atento a armadilhas como a rotatividade (churn) no scale-in causada por cooldowns agressivos, ponderação inadequada de instâncias em ASGs mistos e não levar em conta o aquecimento (warm-up) da aplicação. Para serviços stateful, evite um scale-in rápido que perde caches em memória; para custo vs. resiliência, a capacidade baseada em Spot com fallback para On-Demand oferece economia, mas exige tratamento de interrupções, enquanto 100% On-Demand maximiza a previsibilidade a um custo mais alto.
Contêineres e orquestração: escolhas entre ECS, EKS e Fargate
A escolha entre Amazon ECS, EKS e Fargate depende do modelo operacional, das necessidades de controle e dos padrões da carga de trabalho. O Fargate remove o gerenciamento de nós e é ideal para equipes que priorizam a simplicidade operacional, mas tem um preço por vCPU mais alto e limites de armazenamento efêmero; ele suporta Fargate Spot para economia de custos. O ECS oferece uma integração forte com a AWS e simplicidade para clientes que desejam orquestração de contêineres sem a complexidade do Kubernetes. O EKS é apropriado quando o ecossistema Kubernetes, a portabilidade ou o agendamento avançado são necessários; considere managed node groups ou nós autogerenciados (Self-Managed) + Karpenter para right-sizing dinâmico. Limites de rede (densidade de ENI/pod) e o comportamento do CNI influenciam a densidade de pods e o dimensionamento dos nós; no EKS, o uso de IAM Roles for Service Accounts e do EBS CSI para volumes persistentes reduz a proliferação de credenciais e habilita o armazenamento por pod. Para sistemas de arquivos compartilhados, use EFS (NFS) ou FSx (Lustre) dependendo das necessidades de throughput e latência; evite contêineres com backend NFS para operações de metadados intensas — prefira EFS com modos de throughput ajustados à carga de trabalho. Implemente o cluster autoscaler ou o Karpenter para escalonamento de nós e o auto scaling de serviço com métricas do ALB/serviço ECS. Armadilhas comuns incluem ignorar pod disruption budgets, subestimar a cota do control plane do Kubernetes e superprovisionar nós em vez de usar estratégias de bin-packing — os trade-offs entre controle, custo e sobrecarga operacional devem orientar a seleção.
Padrões de computação serverless, restrições do Lambda e design orientado a eventos
O modelo serverless reduz a sobrecarga operacional, mas requer padrões de arquitetura que lidam com concorrência, estado e limites de sistemas downstream. O Lambda é excelente para tarefas de curta duração e orientadas a eventos, back-ends de API via API Gateway ou ALB, e processamento assíncrono com SQS ou SNS. Use o Step Functions para orquestrar fluxos de trabalho de longa duração e o DynamoDB ou RDS Proxy para acesso a bancos de dados, a fim de mitigar tempestades de conexão. Esteja ciente da sobrecarga de cold start do Lambda em VPCs, causada pela criação de ENIs; mitigue isso com concorrência provisionada para endpoints sensíveis à latência ou use VPC endpoints e o RDS Proxy para limitar conexões. Implemente o padrão fan-out/fan-in via SNS + SQS, ou Kinesis/MKS para processamento ordenado de streams; use filas de mensagens mortas (dead-letter queues) do SQS e handlers idempotentes para gerenciar novas tentativas e duplicatas. Limites de concorrência, concorrência reservada e throttling devem ser planejados para evitar falhas em cascata; projete para contrapressão (backpressure) usando throttles, novas tentativas com jitter e circuit breakers (API Gateway ou customizados). As compensações de custo-desempenho são claras: o Lambda é econômico para cargas de trabalho intermitentes e de curta duração, enquanto o Fargate ou o EC2 são melhores para tarefas de alta utilização de CPU ou de longa execução. Armadilhas comuns incluem depender de novas tentativas síncronas que sobrecarregam sistemas downstream, armazenar estado no diretório local /tmp esperando persistência e não provisionar para cold starts em fluxos críticos de latência.
Problema Prático: Migração do contact center da NovaTel Enterprise
Cenário: A NovaTel Enterprise opera um contact center híbrido com roteamento de chamadas on-premises e um Direct Connect para a AWS. Eles executam session brokers em instâncias EC2 em duas Zonas de Disponibilidade e querem migrar para um contact center gerenciado pela AWS com alta disponibilidade e latência previsível entre o PBX on-premises e os serviços na nuvem.
Desafio: Eles precisam de conectividade de baixa latência para tráfego SIP, uma camada de computação escalável para o tratamento de voz que tolere interrupções de instâncias Spot e uma estratégia de DR (recuperação de desastres) entre Regiões sem aumentar a complexidade operacional.
Abordagem Recomendada:
- Provisione o Amazon Connect para a funcionalidade de contact center e use uma Site-to-Site VPN ou um Direct Connect com um AWS Transit Gateway para SIP trunking de baixa latência, terminando em um NLB com TLS passthrough na frente dos session brokers.
- Execute os componentes de processamento de sessão como um Auto Scaling Group misto com launch templates usando instâncias Spot otimizadas para capacidade com fallback para On-Demand, e use Placement Groups (spread) para isolamento de falhas dos brokers críticos.
- Para mídias de chamada stateful que exigem armazenamento efêmero de baixa latência, use instâncias com instance store (Nitro) para buffering de mídia e replique os metadados da sessão para o DynamoDB ou ElastiCache com replicação multi-AZ; empregue o RDS (Multi-AZ) ou o Aurora Global DB para dados persistentes com réplicas de leitura entre Regiões para DR.
- Implemente lifecycle hooks e warm pools para minimizar o cold start dos brokers, failover ponderado do Route 53 para DR entre Regiões, e CloudWatch + SNS/SQS para alertas e runbooks de failover automatizados.
Justificativa: Usar serviços de contact center gerenciados reduz a carga operacional, enquanto ASGs mistos com Spot otimizam o custo; isolar mídias efêmeras em instance stores preserva o desempenho, e a replicação de estado durável para o DynamoDB/ElastiCache mais RDS/Aurora multi-AZ fornece resiliência e failover rápido, de forma consistente com as melhores práticas de arquitetura profissional.
← Segurança · Todos os domínios · Armazenamento e Gerenciamento de Dados →
Pratique estas questões → · Prática cronometrada no ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Passe no seu exame →