Amazon SAA-C03: Computação, Auto Scaling e Gerenciamento de Instâncias — Guia de estudos

By Laurynas Brazys · 18 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Faz parte do AWS SAA-C03 — Guia de estudos completo. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Tipos de Instância EC2 e AMIs

A seleção da família de instâncias EC2 correta é a base de uma camada de computação bem arquitetada, porque a família, a geração e o tamanho determinam juntos a arquitetura da CPU, a proporção de memória por vCPU, a largura de banda de rede e os aceleradores disponíveis. Uso geral (M6i, M7g, série T) adequa-se a camadas web balanceadas e cargas de trabalho mistas. Otimizadas para computação (C7i, C7gn) servem para simulações que exigem muito da CPU, codificação, processamento em lote e front-ends web. Otimizadas para memória (R7i, X2idn) visam bancos de dados em memória e caches. Otimizadas para armazenamento (I4i, D3) visam NoSQL, HDFS e data warehousing. Aceleradas (P5, G5, Trn1, Inf) fornecem GPUs ou silício de ML. As instâncias Graviton (sufixo g) normalmente oferecem um preço-desempenho 20–40% melhor para cargas de trabalho de scale-out que compilam sem problemas para ARM64.

A família T é expansível (burstable) e opera por padrão no modo padrão, onde os créditos de CPU se acumulam durante a inatividade e são consumidos durante os picos; quando os créditos se esgotam, o desempenho é limitado à linha de base. Para cargas de trabalho com picos imprevisíveis — pequenas camadas web, dev/test ou ambientes Elastic Beanstalk que suportam um front-end com picos de uso — as instâncias T no modo ilimitado permitem que a instância tome créditos emprestados e fature uma pequena sobretaxa por vCPU-hora de excedente, evitando o throttling visível ao usuário. É por isso que ambientes Beanstalk com breve saturação de CPU geralmente são corrigidos habilitando o modo ilimitado, em vez de fazer o upgrade para uma família otimizada para computação mais cara. É importante reservar a série T para cargas de trabalho genuinamente com picos e baixa média de uso: o uso sustentado de CPU no modo padrão esgota os créditos em minutos.

O escalonamento vertical (mudar para um tamanho maior dentro da mesma família) é limitado pela maior instância disponível, força um tempo de inatividade para a mudança, introduz um ponto único de falha e não pode distribuir a carga de trabalho entre Zonas de Disponibilidade. Sempre que a carga varia significativamente, o escalonamento horizontal com um grupo de Auto Scaling é a resposta correta.

As Golden AMIs incorporam o código da aplicação, o tempo de execução e as dependências no snapshot raiz, produzindo lançamentos rápidos e determinísticos — crucial quando o Auto Scaling reage a um pico. O bootstrapping através de user data a cada lançamento adiciona minutos de latência exatamente no momento errado.

Opções de Armazenamento: Instance Store vs. EBS, Snapshots e Fast Snapshot Restore

As instâncias oferecem dois substratos de armazenamento: instance store (NVMe efêmero conectado ao host físico) e Amazon EBS (bloco anexado por rede). O instance store oferece a menor latência possível, mas seus dados são destruídos em caso de parada, hibernação, término ou falha de hardware. Tratá-lo como armazenamento durável é um erro comum e perigoso — ele é apropriado apenas para espaço temporário, buffers, caches ou dados replicados, como um nó de dados HDFS cujas réplicas existem em outros nós. Dados duráveis pertencem ao EBS, com backup por snapshots armazenados no S3.

Os snapshots são incrementais e independentes uma vez criados, portanto, restaurar um para um novo volume nunca afeta a origem. A maneira canônica de duplicar um grande conjunto de dados de produção em um ambiente de teste é criar um snapshot do volume de origem e criar novos volumes a partir desse snapshot. No entanto, volumes restaurados de snapshots fazem o lazy-load dos blocos do S3 na primeira leitura, causando latência significativa de E/S até que cada bloco seja carregado. O mesmo lazy-loading afeta novas instâncias lançadas de AMIs cujos snapshots raiz são grandes — elas parecem lentas por vários minutos após o lançamento.

O EBS Fast Snapshot Restore (FSR) elimina essa penalidade. Habilite o FSR no snapshot para as AZs onde o ASG lança instâncias, e os volumes criados a partir dele entregam o desempenho total provisionado imediatamente:

aws ec2 enable-fast-snapshot-restores \
  --availability-zones us-east-1a us-east-1b \
  --source-snapshot-ids snap-0123456789abcdef0

Isso é essencial quando eventos de scale-out precisam adicionar capacidade em segundos, em vez de minutos.

Rede Otimizada com ENA e EFA

O throughput de rede anunciado escala com o tamanho da instância, mas só é alcançável quando o driver do Elastic Network Adapter (ENA) está presente. O ENA fornece rede otimizada baseada em SR-IOV, suportando até 200 Gbps em instâncias mais novas. AMIs modernas (Amazon Linux 2, Ubuntu recente, Windows) já vêm com o ENA habilitado; verifique com:

aws ec2 describe-instances --instance-ids i-0abc \
  --query 'Reservations[].Instances[].EnaSupport'

modinfo ena | grep version
ethtool -i eth0

Sem o ENA, as instâncias retornam silenciosamente para um throughput mais baixo e um jitter mais alto, minando qualquer projeto de baixa latência, independentemente da escolha do grupo de posicionamento.

Para coletivos em escala de microssegundos — CFD, modelagem meteorológica, dinâmica molecular, treinamento de modelos grandes — adicione o Elastic Fabric Adapter (EFA). O EFA expõe um transporte com bypass do sistema operacional (Libfabric) para MPI e NCCL, evitando completamente a pilha de rede do kernel. O EFA só entrega seu benefício dentro de um grupo de posicionamento de cluster em tipos de instância suportados (c7gn, hpc7a, p5), e requer o driver EFA mais uma compilação compatível de MPI (Open MPI, Intel MPI) ou NCCL.

aws ec2 create-placement-group --group-name hpc-cg --strategy cluster
aws ec2 run-instances --instance-type hpc7a.96xlarge \
  --placement GroupName=hpc-cg \
  --network-interfaces InterfaceType=efa,DeviceIndex=0,SubnetId=subnet-abc

Placement Groups

Placement groups controlam a topologia física das instâncias:

A escolha errada desperdiça o recurso. Um grupo do tipo cluster não pode se estender por várias AZs — ele é intra-AZ por design. O tipo spread não pode hospedar cem servidores web devido ao teto de sete por AZ. O posicionamento do tipo partition, e não spread, é a ferramenta correta para um cluster Kafka de 40 nós, pois alinha o posicionamento das réplicas com os domínios de falha. Para alta disponibilidade geral, não confine um ASG a um único placement group em uma única AZ — distribua o ASG por várias AZs.

Para workloads de streaming analytics ou MPI que precisam de latência mínima entre nós, a combinação correta é um placement group do tipo cluster mais instâncias com ENA habilitado; o cluster reduz o número de saltos (hops) e o ENA entrega a capacidade de pacotes por segundo necessária para concretizar esse benefício de latência.

Auto Scaling Groups e Launch Templates

Um Auto Scaling group (ASG) é a unidade de tempo de execução que mantém um número desejado de instâncias EC2 em uma ou mais AZs, definido por três números inteiros — MinSize, DesiredCapacity, MaxSize — e uma lista de subnets. O ASG em si não descreve o que lançar; essa é a responsabilidade de um launch template, o substituto moderno para as launch configurations. Launch templates suportam versionamento, políticas de instâncias mistas, combinação de Spot/On-Demand, imposição do IMDSv2, reservas de capacidade e instâncias T no modo ilimitado. Um launch template referencia uma AMI, tipo(s) de instância, security groups, IAM instance profile, user data e mapeamentos de block device.

O padrão canônico para aplicações web stateless é AMI + Launch Template + ASG + ALB. A AMI proporciona um boot rápido; o ALB (ou NLB para TCP/UDP) distribui o tráfego e executa os health checks; o ASG registra novas instâncias no target group automaticamente e encerra as que não estão saudáveis. A implantação Multi-AZ (no mínimo duas AZs, três para sistemas de quórum) é obrigatória — um ASG vinculado a uma única subnet não pode sobreviver a uma interrupção de AZ, pois o próprio ASG não consegue lançar substituições enquanto a AZ estiver comprometida.

MyASG:
  Type: AWS::AutoScaling::AutoScalingGroup
  Properties:
    MinSize: 2
    MaxSize: 20
    DesiredCapacity: 4
    VPCZoneIdentifier: [subnet-a, subnet-b]
    TargetGroupARNs: [!Ref AppTargetGroup]
    LaunchTemplate:
      LaunchTemplateId: !Ref AppLT
      Version: !GetAtt AppLT.LatestVersionNumber
    HealthCheckType: ELB
    HealthCheckGracePeriod: 120

Políticas de Scaling: Target Tracking, Step, Scheduled, Predictive

O scaling de ASG tem quatro modos, cada um resolvendo um problema diferente:

• Target tracking escolhe uma métrica e a mantém próxima de um ponto de ajuste (ex: ASGAverageCPUUtilization = 50%, ALBRequestCountPerTarget = 1000). Ele se autoajusta — a AWS gerencia os alarmes e ajusta a velocidade à medida que a métrica se desvia. Esta deve ser a escolha padrão.
• Step scaling adiciona ou remove capacidade em níveis graduados com base no quão fora do intervalo uma métrica está, útil quando a magnitude da reação deve escalar com a gravidade do alarme.
• Simple scaling é legado: um único ajuste por alarme, bloqueia durante o cooldown e não deve ser escolhido para novos projetos.
• Scheduled scaling altera MinSize/DesiredCapacity/MaxSize em horários definidos (cron).
• Predictive scaling usa machine learning em até 14 dias de histórico para prever as próximas 48 horas, pré-provisionando capacidade antes do pico de demanda.

O scaling dinâmico é inerentemente reativo (lagging) — ele reage apenas depois que uma métrica é violada, e as novas instâncias precisam de minutos para iniciar, registrar e aquecer. Para uma aplicação corporativa onde todos os usuários chegam às 09:00 e enfrentam 2 a 3 horas de lentidão enquanto o ASG se ajusta, o scaling dinâmico por si só é a resposta errada. Adicione uma camada de ações agendadas (scheduled actions) antes do pico para aumentar MinSize e DesiredCapacity antes que a demanda chegue:

ScheduledAction:
  AutoScalingGroupName: web-asg
  ScheduledActionName: pre-sale-warmup
  Recurrence: "0 8 * * *"
  MinSize: 20
  DesiredCapacity: 30
  MaxSize: 200

Depois, deixe o target tracking absorver a variabilidade residual. O predictive scaling é a escolha certa quando a forma do pico é estável, mas seu horário exato varia de um dia para o outro. Para desligamentos previsíveis em ambientes de não produção (ambientes de dev desligados à noite e nos fins de semana), uma ação agendada para desired=0, min=0 na sexta-feira à noite e para voltar na segunda de manhã é a solução com menor sobrecarga — o próprio ASG é o motor de agendamento, sem necessidade de código de integração (glue) com Lambda ou EventBridge.

A escolha da métrica importa tanto quanto a escolha da política. CPU funciona para workloads web limitadas por CPU (CPU-bound), mas para workers orientados por backlog que consomem de uma fila SQS, você deve escalar com base no tamanho da fila, não na CPU: um worker bloqueado em I/O pode mostrar 10% de CPU enquanto milhões de mensagens se acumulam. Use ApproximateNumberOfMessagesVisible por instância, exposta como uma métrica customizada ou através do alvo integrado SQSQueueBacklogPerInstance:

backlog_per_instance = messages_visible / running_instances
target = acceptable_latency_seconds / avg_processing_seconds_per_msg

TargetTrackingConfiguration:
  CustomizedMetricSpecification:
    MetricName: BacklogPerInstance
    Namespace: MyApp/Scaling
    Statistic: Average
  TargetValue: 100

Da mesma forma, camadas HTTP sensíveis à latência devem monitorar TargetResponseTime ou RequestCountPerTarget; aplicações limitadas por memória, disco ou latência de serviços downstream devem publicar uma métrica customizada que reflita o gargalo real. Escalar com base na CPU quando a CPU não é a restrição produz exatamente o modo de falha onde as instâncias nunca escalam horizontalmente (scale out), as filas crescem sem limites e o ALB retorna erros 5xx.

Verificações de Saúde e Lifecycle Hooks

Por padrão, os ASGs usam as verificações de status do EC2, que detectam falhas no hypervisor, mas não na aplicação. Habilitar as verificações de saúde do ELB no ASG delega a decisão de substituição para a sonda de nível de aplicação do load balancer, o que é essencial quando o sistema operacional está funcionando, mas o processo está travado. Defina o HealthCheckGracePeriod com tempo suficiente para que os dados do usuário (user data) sejam concluídos; caso contrário, instâncias recém-lançadas serão terminadas no meio do bootstrap, em um loop.

A escolha do load balancer afeta o significado de “saudável”:

Uma aplicação HTTP por trás de um NLB que faz apenas verificações de saúde TCP continuará a servir tráfego de uma instância que aceita conexões, mas retorna erros 500. Mude para um ALB — ou configure verificações de saúde HTTP no NLB — para restaurar uma sinalização significativa.

Os Lifecycle hooks pausam instâncias nos estados Pending:Wait ou Terminating:Wait para que automações externas possam agir. No lançamento, um hook permite que você registre a instância em um sistema de gerenciamento de configuração, aqueça caches ou obtenha segredos antes que o ALB envie tráfego. Na terminação, um hook permite drenar sessões, descarregar logs e cancelar o registro de um service mesh. Os hooks emitem eventos no EventBridge; os manipuladores (handlers) devem chamar CompleteLifecycleAction ou o hook expirará para sua ação padrão (CONTINUE ou ABANDON).

Warm Pools e Hibernação

O tempo de inicialização a frio (cold-launch) é um problema real para aplicações que carregam modelos grandes, aquecem caches ou compilam com JIT antes de servir. Um warm pool é uma reserva pré-inicializada anexada ao ASG: as instâncias são lançadas, executam o bootstrap e, em seguida, são paradas, mantidas em execução ou hibernadas, permanecendo no pool até que o ASG precise escalar horizontalmente (scale out). Puxar uma instância do pool economiza minutos de inicialização.

A Hibernação suspende o sistema operacional para o volume raiz EBS criptografado, de modo que o heap da JVM, os pesos de ML e o cache de páginas do SO retornem no reinício. Requisitos: volume raiz criptografado grande o suficiente para conter a RAM, RAM da instância ≤ 150 GB em uma família suportada e HibernationOptions.Configured = true no lançamento. Um warm pool com PoolState: Hibernated combina ambos — as instâncias não têm custo de computação enquanto estão paradas e reiniciam em segundos com a memória já populada. Este é o padrão correto quando uma aplicação “leva muito tempo para carregar a memória antes de se tornar produtiva”.

Recuperação Automática para Cargas de Trabalho Não Escaláveis

Nem toda carga de trabalho escala horizontalmente. Aplicações legadas com licenças vinculadas ao endereço MAC, travas baseadas em arquivos ou estado de sessão em memória sem um armazenamento compartilhado não podem ser executadas em mais de uma instância — iniciar nós adicionais causa corrupção de dados ou violações de licença. Para essas, a resiliência vem da recuperação automática, não do scale-out.

Dois padrões funcionam. Um alarme do CloudWatch em StatusCheckFailed_System combinado com a ação de recuperação do EC2 preserva o ID da instância, o IP privado, o Elastic IP e os anexos EBS durante uma falha do host subjacente. Mais simples ainda: um ASG com MinSize=MaxSize=1 abrangendo múltiplas AZs substitui uma instância com falha e, ao contrário da ação de recuperação, pode sobreviver a uma falha de AZ — desde que o estado seja externalizado do volume raiz ou a AMI seja reconstruível.

Load Balancers e Posicionamento em Sub-redes

O ALB opera na camada 7 (L7), terminando HTTP/HTTPS, oferecendo roteamento por host/caminho/cabeçalho, HTTP/2, WebSockets e integração com WAF/Cognito/OIDC. O NLB opera na camada 4 (L4), preserva o IP do cliente, suporta IPs estáticos e TLS passthrough, PrivateLink e sustenta milhões de conexões por segundo. O Gateway Load Balancer insere appliances de terceiros (firewalls, IDS) no caminho do tráfego.

O posicionamento em sub-redes (subnets) é onde as arquiteturas mais frequentemente falham. Um ALB voltado para a internet deve ser anexado a sub-redes públicas — sub-redes com uma rota 0.0.0.0/0 para um Internet Gateway — uma por AZ onde os alvos (targets) residem. Os próprios alvos permanecem em sub-redes privadas. Se o ALB for colocado em sub-redes privadas, ou se as sub-redes “públicas” não tiverem uma rota padrão para o IGW, os clientes enfrentarão timeouts de conexão. A alcançabilidade do alvo exige que o security group do alvo permita tráfego de entrada vindo do security group do ALB na porta do alvo; não é necessário NAT entre o ALB e os alvos na mesma VPC.

Client → IGW → ALB (public subnets, SG: allow 443 from 0.0.0.0/0)
              → Targets (private subnets, SG: allow 8080 from ALB-SG)

Habilite as verificações de saúde do ELB no ASG para que os alvos não saudáveis sejam substituídos, e não apenas desregistrados. O balanceamento de carga entre zonas (cross-zone load balancing), padrão no ALB e opcional no NLB, uniformiza a distribuição de requisições, independentemente do número de instâncias por AZ. O Route 53 deve resolver para o ALB por meio de um registro de alias (ou política ponderada/de latência entre múltiplos ALBs) — nunca aponte o Route 53 para IPs de instâncias EC2 individuais, pois uma instância com falha continuaria recebendo tráfego até a expiração do TTL, e a instância de substituição do ASG terá um IP diferente.

Modelos de Compra e Frotas de Instâncias Mistas

A escolha do modelo de compra é a maior alavanca para reduzir os gastos com EC2, independentemente do padrão de arquitetura.

A estratégia racional: carga base (baseline) em Reserved Instances ou Savings Plan, picos (bursts) em On-Demand, trabalho tolerante a falhas em Spot. Em um ASG, isso é expresso como uma política de instâncias mistas (mixed-instances policy):

MixedInstancesPolicy:
  LaunchTemplate:
    LaunchTemplateSpecification:
      LaunchTemplateId: lt-0abc123
      Version: $Latest
    Overrides:
      - InstanceType: m5.large
      - InstanceType: m5a.large
      - InstanceType: m6i.large
      - InstanceType: m6a.large
  InstancesDistribution:
    OnDemandBaseCapacity: 4          # covered by Savings Plan
    OnDemandPercentageAboveBaseCapacity: 20
    SpotAllocationStrategy: price-capacity-optimized

Diversificar os tipos de instância aprofunda o pool de Spot e reduz interrupções correlacionadas. price-capacity-optimized (ou capacity-optimized) equilibra o preço com a profundidade do pool para que as instâncias tenham menor probabilidade de serem retomadas.

Spot é apropriado para cargas de trabalho stateless, que permitem checkpoint, retentativa ou que são horizontalmente redundantes: web workers atrás de um ALB, jobs do Batch com retentativa automática, executores Spark, runners de CI. Não é apropriado como a única capacidade para serviços críticos sempre ativos, bancos de dados primários stateful ou nós líderes sem um caminho de recuperação — o aviso de dois minutos não pode garantir um desligamento seguro, e a retomada correlacionada de um tipo de instância específico em toda a frota é um modo de falha real. Quando o requisito diz “não deve ser interrompido”, o Spot está desqualificado.

A armadilha inversa é aplicar RIs ou Savings Plans a cargas de trabalho genuinamente variáveis: você paga o compromisso por hora, usando-o ou não. Assim, uma carga de trabalho que roda 40 horas por semana sob um compromisso de 168 horas desperdiça 76% da reserva. Quando a preocupação é a capacidade em si — e não o preço — (picos orientados a eventos, recuperação de desastres), use uma On-Demand Capacity Reservation: uma garantia pura com escopo de AZ, com taxas On-Demand, combinável com um Savings Plan para obter o desconto.

Computação Serverless: Lambda e Fargate

Serverless transfere o gerenciamento de capacidade para a plataforma. Lambda é adequado para trabalho orientado a eventos e de curta duração: gatilhos ObjectCreated do S3, DynamoDB Streams, consumidores SQS de baixo volume, backends do API Gateway, lógica de integração (glue logic). A memória (128 MB – 10.240 MB) provisiona a CPU proporcionalmente, então ajustar a memória para cima geralmente reduz o custo ao encurtar a duração. Limites rígidos definem seu escopo: execução máxima de 15 minutos, 10 GB de memória, 10 GB em /tmp, 250 MB de pacote de implantação descompactado (ou 10 GB via imagem de contêiner), 6 MB de payload síncrono. Usar Lambda para uma transcodificação de vídeo de 30 minutos, um ETL de várias horas ou treinamento de GPU é arquiteturalmente errado — a função sofrerá timeout no meio do trabalho e a lógica de retentativa apenas multiplicará o desperdício. Para caminhos sensíveis à latência, mitigue os cold starts e o tempo de inicialização da ENI anexada à VPC com Provisioned Concurrency.

Fargate executa contêineres sem gerenciar hosts EC2. É a escolha certa quando as tarefas excedem 15 minutos, precisam de runtimes personalizados ou se encaixam na orquestração do ECS/EKS, mas a equipe não quer gerenciar a capacidade. Fargate é mais caro por vCPU-hora do que EC2 Spot, então, quando a utilização em estado estável é alta e previsível, um ASG de instâncias mistas com Spot no ECS é mais barato. Para tráfego com picos ou imprevisível, a cobrança por segundo do Fargate é vantajosa.

Para orquestração de muitas Lambdas, Step Functions é preferível ao encadeamento via SNS/SQS porque oferece histórico de execução visual, semântica de retentativa, tratamento de erros centralizado e estado durável. Workflows Standard cobram por transição de estado e podem rodar por até um ano; workflows Express otimizam para processamento de eventos de alto volume e curta duração.

Para distribuição (fan-out) de milhares de jobs parametrizados em contêineres — genômica, Monte Carlo, ETL — o AWS Batch gerencia o enfileiramento, resolução de dependências, retentativas e provisionamento em EC2 gerenciado, Spot ou Fargate. Os jobs referenciam uma definição de job (contêiner + vCPU/memória + IAM role) e o Batch os agrupa (bin-packs) em instâncias de tamanho adequado. O Step Functions frequentemente orquestra o Batch, Lambda e ECS dentro de uma única máquina de estados.

Elastic Beanstalk

O Beanstalk é um PaaS gerenciado que provisiona o ALB, ASG, instâncias EC2 e, opcionalmente, o RDS a partir de um pacote de aplicação (application bundle). Ele suporta implantações do tipo rolling, rolling-with-additional-batch, immutable e blue/green com integração ao CloudWatch. As políticas de scaling são expostas como opções do ambiente (métrica, limiares, min/max). Como o Beanstalk usa por padrão tipos de instância com capacidade de burst (burstable), habilitar o modo T-unlimited é a correção de baixo esforço para saturação breve de CPU. Ações de scaling agendadas anexam-se ao ASG gerenciado pelo Beanstalk como qualquer outro. Escolha o Beanstalk quando a equipe deseja uma topologia de aplicação web padrão sem criar CloudFormation manualmente e quando atualizações contínuas (rolling updates) e pacotes versionados se alinham à cadência de lançamento.

Gerenciamento de Frotas com o Systems Manager

Padrões de SSH e bastion hosts são frágeis e caros de proteger. O AWS Systems Manager os substitui. O SSM Agent (pré-instalado no Amazon Linux 2, Ubuntu, Windows) e um instance profile que concede a permissão AmazonSSMManagedInstanceCore é tudo o que é necessário.

• Run Command executa scripts de shell/PowerShell em frotas com tags específicas, com saída consolidada.
• Session Manager abre shells interativos através da API da AWS — sem porta 22 de entrada, sem bastion host, autenticação completa via IAM, com sessões registradas no S3 ou CloudWatch Logs.
• Patch Manager aplica patches de sistema operacional de forma agendada, usando janelas de manutenção.

aws ssm send-command \
  --targets Key=tag:Env,Values=prod \
  --document-name AWS-RunShellScript \
  --parameters 'commands=["yum -y update"]'

Automação de Start/Stop Agendado

Para instâncias EC2 e RDS de ambientes não produtivos que devem ser desligadas fora do horário comercial, o padrão de baixa manutenção é EventBridge Scheduler → Lambda. Uma regra cron (cron(0 19 ? * MON-FRI *)) invoca uma função Lambda que para os recursos com tags específicas; uma segunda regra às 07:00 os inicia.

import boto3
ec2 = boto3.client('ec2'); rds = boto3.client('rds')

def handler(event, _):
    action = event['action']  # 'start' or 'stop'
    ids = [i['InstanceId'] for r in ec2.describe_instances(
        Filters=[{'Name':'tag:AutoStop','Values':['true']}]
    )['Reservations'] for i in r['Instances']]
    getattr(ec2, f'{action}_instances')(InstanceIds=ids)
    for db in rds.describe_db_instances()['DBInstances']:
        if any(t['Key']=='AutoStop' and t['Value']=='true' for t in db['TagList']):
            getattr(rds, f'{action}_db_instance')(DBInstanceIdentifier=db['DBInstanceIdentifier'])

Essa abordagem é serverless, não tem uma frota para aplicar patches e escala por tag. A solução AWS Instance Scheduler funciona de forma equivalente. Uma sutileza: uma instância RDS parada reinicia automaticamente após sete dias, então o agendamento de parada deve ser recorrente para pará-la novamente. Combinado com ASGs cujas ações agendadas zeram a capacidade nos fins de semana, o custo durante as horas ociosas se aproxima de zero.

Armadilhas de Rede em Ambientes de Computação Escaláveis

Posicionamento do NAT Gateway. Um NAT gateway reside em uma única AZ. Uma frota que se estende por três AZs e roteia todo o tráfego de saída (egress) através de um único NAT em us-east-1a paga pela transferência entre AZs em cada pacote de us-east-1b/us-east-1c, e perde totalmente a saída quando us-east-1a sofre uma degradação. O padrão correto é um NAT gateway por AZ, com a tabela de rotas de cada sub-rede privada apontando para o NAT em sua própria AZ. Isso localiza o tráfego e remove o modo de falha de AZ única.

Instâncias NAT. Uma única instância NAT baseada em EC2 se torna um gargalo de largura de banda e PPS (pacotes por segundo) à medida que a frota cresce, e é um ponto único de falha (SPOF). Os NAT Gateways gerenciados escalam para 100 Gbps por gateway. Para o tráfego de serviços da AWS, os VPC endpoints (Gateway para S3/DynamoDB, Interface para os demais) contornam completamente o NAT, reduzindo custos e eliminando o risco de saturação durante eventos de escalonamento.

Armadilhas de Design Recorrentes

• ASGs em uma única AZ não sobrevivem a uma interrupção de AZ — sempre associe sub-redes de pelo menos duas AZs (três para sistemas de quórum) e mantenha MinSize ≥ 2.
• Assumir que toda carga de trabalho escala horizontalmente. Aplicações que mantêm estado (stateful), de gravador único (single-writer) ou com licenças não clusterizáveis pioram sob um ASG. Use recuperação automática ou refatore primeiro.
• Escalonamento reativo para picos previsíveis produz o sintoma de “lentidão nas primeiras 2 a 3 horas”. Use escalonamento agendado ou preditivo para pré-aquecer (pre-warm).
• Escalonar com base em CPU quando a CPU não é o gargalo. Publique uma métrica que reflita o gargalo real — profundidade da fila, tempo de resposta, número de conexões.
• Simple scaling e launch configurations são legados — prefira target tracking e launch templates.
• Health checks apenas TCP em aplicações HTTP mantêm instâncias com falha em rotação. Use health checks HTTP (via ALB ou os checks em modo HTTP do NLB).
• Usar Spot para cargas de trabalho com estado (stateful) ou que não podem ser interrompidas — Spot exige workers que permitam checkpoint e sejam substituíveis.
• Usar Reserved Instances ou Savings Plans em cargas de trabalho genuinamente variáveis — o compromisso não utilizado é puro desperdício; reduza os custos com dimensionamento correto (right-sizing) e Spot.
• Apontar o Route 53 para IPs de instâncias EC2 individuais — roteie para o alias do ALB para que o DNS reflita as mudanças na frota (churn).
• Tratar o instance store como durável — os dados desaparecem ao parar, terminar ou em caso de falha do host.
• Ignorar a latência de carregamento lento (lazy-load) após a restauração de um snapshot ou o lançamento de uma AMI — habilite o Fast Snapshot Restore nas AZs de destino.

Todos os domínios · Contêineres e Orquestração →

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

Navegar Amazon →