Amazon SOA-C02: Computação e Auto Scaling — Guia de estudos

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Faz parte do AWS SysOps Administrator Associate SOA-C02 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Este domínio abrange o gerenciamento de instâncias EC2 e Auto Scaling para fornecer capacidade computacional confiável e de custo-benefício. Ele foca em operações do ciclo de vida da instância, estratégias de escalonamento, integração com load balancers, posicionamento para desempenho e resiliência, e comportamentos de manutenção/terminação que afetam a disponibilidade e o estado. O domínio operacional significa escolher os tipos de instância corretos, padrões de configuração de lançamento, políticas de escalonamento e integração de verificação de saúde para atender aos SLAs enquanto controla os custos.

Ciclo de vida e gerenciamento de instâncias EC2

O gerenciamento do ciclo de vida do EC2 começa no ponto da configuração de lançamento: use Launch Templates (aws ec2 create-launch-template / console) para capturar AMI, tipo de instância, perfil de instância IAM, user-data, interfaces de rede, mapeamento de EBS e opções de metadados; os templates suportam versionamento, o que torna as implantações imutáveis diretas. Implantações imutáveis usam uma nova versão do launch template (ou um novo launch template) e criam um novo Auto Scaling group ou usam a atualização de instância do ASG para substituir instâncias; evite atualizações no local de instâncias em execução quando as mudanças afetam o comportamento de tempo de inicialização ou patches no nível da AMI.

Padrões operacionais de CLI/console incluem

undefined

para lançamentos avulsos e

undefined

para lançamentos controlados pelo ASG. Decida entre o baking de AMIs (Packer/CodeBuild) e scripts de inicialização de user-data com base no tempo de inicialização: faça o bake de dependências pesadas nas AMIs para reduzir a duração da inicialização; use user-data para configurações específicas do ambiente. Para armazenamento efêmero, lembre-se que os volumes de instance store são perdidos na terminação; configure os volumes raiz e de dados com DeleteOnTermination=false se você precisar da persistência do EBS após a terminação da instância.

Auto Scaling Groups, políticas e ganchos de ciclo de vida

Auto Scaling Groups (ASGs) são configurados com um launch template ou launch configuration e controlam a capacidade desejada/mínima/máxima entre as Availability Zones. Escolha launch template + MixedInstancesPolicy para frotas otimizadas para custo que mesclam On-Demand e Spot com uma lista de tipos de instância; use ponderação de instâncias e estratégias de alocação otimizadas para capacidade para obter capacidade previsível. Para implantações, prefira padrões imutáveis: crie uma nova versão do launch template e realize uma atualização de instância do ASG ou uma troca blue/green em vez de reconfigurar as instâncias existentes.

As políticas de escalonamento são expressas como:

Target tracking (PolicyType=TargetTrackingScaling): defina uma métrica predefinida como ALB RequestCountPerTarget ou a média de CPU do ASG e um valor alvo; o ASG lida com os ajustes automaticamente.
Step scaling (PolicyType=StepScaling): defina alarmes do CloudWatch que acionam etapas de ajuste específicas (ex: +2, +4) com base na gravidade da violação; útil para cargas de trabalho com picos de uso.
Simple scaling (legado): ajustes de etapa única com cooldown; geralmente substituído pelo target tracking ou step scaling.

Use ganchos de ciclo de vida (

undefined

) para pausar a terminação/lançamento da instância. Os ganchos de ciclo de vida permitem que você drene conexões, replique o estado (para S3/RDS) ou notifique sistemas de orquestração via SNS/SQS/Lambda antes da conclusão; sempre defina um HeartbeatTimeout e uma ação padrão para evitar estados travados.

Tipos de Elastic Load Balancing e verificações de saúde

Escolha o tipo de load balancer pelo padrão de tráfego: Application Load Balancer (ALB) para HTTP/HTTPS com roteamento baseado em conteúdo e regras de host/caminho; Network Load Balancer (NLB) para desempenho extremo e IPs estáticos para TCP/UDP; Classic Load Balancer (CLB) apenas para pilhas legadas. Crie ALBs e target groups com

undefined

; registre os alvos do ASG usando a associação de grupo de destino do ASG para integração automática da saúde do ciclo de vida.

A integração da verificação de saúde requer o alinhamento das verificações de saúde do ASG e do ELB: defina o HealthCheckType do ASG como ELB (

undefined

) para que uma instância seja considerada saudável somente depois que o load balancer marcar seu alvo como saudável. Tipos de verificação de saúde e suas implicações:

Verificação de saúde do target group do ALB/NLB: suporta HTTP/HTTPS/TCP e mede a prontidão no nível da aplicação; recomendado para aplicações web.
Verificações de saúde do ASG sozinhas: use para verificações simples no nível do host (ex: verificações de status do EC2).
HealthCheckGracePeriod: dê tempo para que novas instâncias inicializem, executem o user-data e passem nas verificações no nível da aplicação.

Implicações da aderência: a aderência do target group do ALB usa afinidade baseada em cookie de aplicação (baseada em duração), o que pode melhorar a afinidade de sessão, mas reduz a distribuição uniforme e complica as atualizações contínuas. O NLB suporta afinidade por IP do cliente; use a aderência somente quando o estado da sessão não puder ser externalizado.

Posicionamento de instâncias, planejamento de capacidade e métricas de escalonamento

As decisões de posicionamento (placement) afetam a latência e os domínios de falha: os placement groups (grupos de posicionamento) oferecem estratégias de cluster (rede de baixa latência), spread (uma instância por rack para instâncias críticas) e partition (partições isoladas de falhas). Por padrão, os ASGs balanceiam as instâncias entre as AZs; prefira um planejamento de capacidade ciente das AZs para evitar hotspots em uma única AZ. Para a CLI:

undefined

O planejamento de capacidade considera tipos de instância, opções de compra e métricas:

Tipos de instância: escolha famílias otimizadas para CPU/memória/rede (M/C/R/T/D/I) com base na carga de trabalho; meça com testes de carga representativos.
Compra: On-Demand para previsibilidade, Reserved ou Savings Plans para reduções de custo em estado estável (steady-state), Spot para eficiência de custo transitória; use a MixedInstancesPolicy para combinar tipos e opções de compra.
Métricas de escalonamento: as métricas padrão do ASG usam a média de CPU do grupo; prefira métricas no nível da aplicação, como RequestCountPerTarget do ALB ou métricas personalizadas do CloudWatch (ex: profundidade da fila) para o target tracking. Padrões comuns:
Use o target tracking com ALB/request-count-per-target quando precisar de um número estável de requisições por instância.
Use o step scaling para picos grandes e repentinos, com etapas de recuperação definidas.
Considere o Predictive Scaling para cargas de trabalho com ciclos diários.

Recuperação de instâncias, comportamento de terminação e manutenção

Planeje-se para falhas e manutenções de instâncias habilitando a recuperação automática para problemas de hardware (alarme do CloudWatch com a ação EC2 Recover) e tratando eventos agendados (

undefined

). Configure os flags instance-initiated-shutdown-behavior e DeleteOnTermination do EBS para controlar o ciclo de vida do volume; use

undefined

para ajustar.

Comportamento de terminação em ASGs: as políticas de terminação do ASG decidem qual instância terminar primeiro (Padrão: a launch configuration mais antiga ou heurísticas de saúde da instância e balanceamento de AZ). Detalhes operacionais importantes:

O estado local é efêmero: volumes de instance store e caches em memória são perdidos na terminação. Não presuma que a substituição preserva o estado local; persista dados críticos no EBS (com snapshot/backup apropriado), S3 ou em um cache externo (ElastiCache).
Use lifecycle hooks para drenar o tráfego e descarregar o estado antes da terminação.
Use instance refresh ou blue/green para manutenção, a fim de substituir instâncias com segurança;

undefined

Armadilhas Comuns e Critérios de Decisão

Confiar nos cooldowns padrão e em métricas apenas de CPU: escolha métricas alinhadas ao comportamento da aplicação (RequestCountPerTarget do ALB, profundidade da fila); defina cooldowns que acomodem o tempo de inicialização e o HealthCheckGracePeriod para evitar oscilação.
Não usar lifecycle hooks para uma terminação gradual (graceful termination): sem os hooks, requisições em andamento e caches locais são perdidos; implemente hooks com SNS/SQS/Lambda para drenar e persistir o estado.
Presumir que a substituição da instância preserva o estado local: caches locais de instance store e em memória são efêmeros; projete para instâncias sem estado (stateless) ou replique o estado para armazenamentos duráveis.
Uso excessivo de stickiness (afinidade de sessão): o stickiness aumenta a distribuição desigual de carga e complica o escalonamento e as atualizações; prefira armazenamentos de sessão externos (ElastiCache, DynamoDB) para scale-out.
Ignorar o balanceamento entre AZs e os placement groups: posicionar muitas instâncias em uma única AZ ou em um grupo do tipo cluster pode criar pontos únicos de falha; use a distribuição multi-AZ do ASG e estratégias de placement group apropriadas.
Configuração incorreta da integração do health check: o health-check-type do ASG deve corresponder aos health checks do ELB/target group, e o HealthCheckGracePeriod deve ser longo o suficiente para a inicialização da aplicação, caso contrário, instâncias saudáveis serão terminadas.

Problema Prático: Cenário de Caso de Uso

A StreamingCo opera uma API de miniaturas de vídeo que enfrenta picos de tráfego diários e usa caches em disco local nas instâncias EC2; recentemente, o scale-up tem sido lento e as instâncias terminadas perdem o cache, levando a tempos de resposta ruins.

Migre a launch configuration para um Launch Template e crie (bake) uma AMI leve com as dependências de tempo de execução; use

undefined

e versionamento para deploys imutáveis. 2. Configure um ASG com uma MixedInstancesPolicy que liste vários tipos de instância e uma alocação Spot + On-Demand para balancear custo e capacidade. 3. Anexe um ALB e use TargetTrackingScaling na métrica RequestCountPerTarget do ALB, com um HealthCheckGracePeriod definido para o tempo de bootstrap da aplicação. 4. Implemente lifecycle hooks nas terminações do ASG para drenar conexões e executar um fluxo com Lambda/SNS para persistir chaves de cache necessárias no ElastiCache ou S3 antes da terminação. 5. Externalize o estado de sessão e cache para o ElastiCache ou S3 e use placement groups/distribuição entre AZs para atender aos requisitos de latência e de domínio de falha.

Justificativa: O uso de launch templates e deploys imutáveis reduz a variabilidade na inicialização; o target tracking direcionado ao ALB atrela o escalonamento à carga de requisições em vez da CPU; os lifecycle hooks previnem a perda de dados na terminação; a externalização do cache remove a dependência do estado local efêmero, permitindo um escalonamento rápido e seguro, e um custo menor através de estratégias mistas de instâncias/compra.

← Armazenamento e Gerenciamento de Dados · Todos os domínios · Bancos de Dados e Cache →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →