SW BBANG P

Você acabou de receber a tarefa de compartilhar um diretório entre cinco instâncias EC2 — parece simples, mas a escolha errada entre EBS e EFS pode resultar em dados corrompidos, arquitetura não suportada, ou horas de retrabalho. A dúvida entre EBS vs EFS para múltiplas instâncias é uma das mais comuns em ambientes AWS, e a resposta não é óbvia para quem vem de infraestrutura on-premises. TL;DR — EBS vs EFS para Múltiplas Instâncias Critério EBS EFS Compartilhamento entre instâncias Limitado (Multi-Attach apenas em volumes io1/io2, mesma AZ) Nativo — múltiplas instâncias, múltiplas AZs Tipo de acesso Block storage File storage (NFS v4.1/v4.2) Sistema de arquivos compartilhado Não (sem coordenação de cluster) Sim, gerenciado pela AWS Caso de uso típico Volume dedicado por instância, banco ...

Você sobe uma instância T3 para um ambiente de staging, tudo funciona bem por horas — até que, do nada, a CPU trava em 5% e a aplicação começa a responder com latência absurda. Sem erro no log, sem alarme disparado, sem explicação óbvia. Esse é o comportamento clássico de esgotamento de créditos de CPU em instâncias T3, e entender o mecanismo por trás disso é o que separa um diagnóstico de 5 minutos de horas de investigação inútil. TL;DR: Instâncias T3 e CPU Credits Conceito Comportamento CPU Credit Unidade que permite uso de CPU acima da baseline por 1 minuto Baseline de CPU Percentual garantido de CPU por tipo de instância (ex: t3.micro = 10%) Acúmulo de créditos Créditos acumulam quando CPU fica abaixo da baseline Esgotamento CPU é limitada à baseline quando créditos acabam (modo Standard) Modo Un...

Você acabou de subir um cluster de instâncias privadas e percebe que o yum update trava — sem rota de saída para a internet. A pergunta imediata é: NAT Gateway gerenciado ou uma instância EC2 fazendo NAT? A escolha errada aqui aparece tarde, geralmente quando o tráfego aumenta ou quando você precisa escalar e descobre que a solução escolhida não acompanha. TL;DR — NAT Gateway vs NAT Instance Critério NAT Gateway NAT Instance (EC2) Gerenciamento Totalmente gerenciado pela AWS Você opera, patcha e monitora Alta disponibilidade Redundância interna por AZ Você implementa com Auto Scaling + script Escalabilidade Automática até limites do serviço Limitada pelo tipo de instância EC2 Custo base Cobrança por hora + por GB processado Custo da instância EC2 + EIP Security Gro...

Você acabou de criar uma AMI base e precisa que cada nova instância já suba com Nginx instalado, configurado e rodando — sem intervenção manual. O recurso que resolve isso é o EC2 User Data , e entender exatamente onde ele executa, quando falha silenciosamente e quais armadilhas existem na prática faz toda a diferença entre um bootstrap confiável e horas de depuração. TL;DR — Resumo Rápido Ponto Detalhe O que é User Data Script shell (ou cloud-init) executado pelo cloud-init na primeira inicialização da instância Quando executa Por padrão, apenas uma vez — no primeiro boot após o lançamento Onde colar o script Console AWS → EC2 → Launch Instance → seção 'Advanced Details' → campo 'User data' Log de execução /var/log/cloud-init-output.log na instância Permissão de execução O script roda como root — sem necessidade de sudo Limite de tamanho 16 KB (em texto puro); scripts maiores...

Uma instância EC2 sumiu em produção e ninguém assume a responsabilidade. Antes de escalar o incidente, o primeiro passo é consultar o CloudTrail — ele registra cada chamada de API na sua conta, incluindo exatamente quem executou o TerminateInstances e quando. TL;DR — Resumo Rápido Etapa O que fazer 1 Abrir o CloudTrail Event History no console ou usar a CLI 2 Filtrar pelo nome do evento TerminateInstances 3 Identificar o campo userIdentity no evento retornado 4 Confirmar ARN, tipo de principal e hora exata da ação Como o CloudTrail Registra Ações de EC2 O CloudTrail captura chamadas de API feitas à AWS — via console, CLI, SDK ou serviços internos. Para o EC2, cada ação de controle (criar, parar, terminar instância) gera um evento de gerenciamento ( management event ) que fica disponível no Event History por 90 dias, sem necessidade de configurar uma trail separada. O evento TerminateInstances ...