O Amazon EC2 é a oferta de máquinas virtuais da AWS — a base para cargas que precisam de controle de sistema operacional.

🎯 Para a certificação

Questões sobre EC2 costumam combinar escolhas de tipo de instância, trade-offs de preço (Spot, Reserved), integração com armazenamento (EBS), networking e segurança básica de instância (IMDSv2).

---

Resumo

• Tipos de instância: famílias (general purpose, compute-optimized, memory-optimized, storage-optimized etc.) e tamanhos.
• Modelos de preço: On-Demand, Reserved Instances / Savings Plans, Spot Instances, Dedicated Hosts/Instances, Capacity Reservations.
• AMI: imagem que define sistema operacional, configurações e software pré-instalado.
• EBS: volumes persistentes que se ligam às instâncias EC2, com diferentes tipos (SSD de propósito geral, IOPS provisionado, HDD).

Nota didática: pense no EC2 como um servidor virtual onde você escolhe a "caixa" (tipo de instância), o sistema dentro dela (AMI), como ela se conecta à rede (VPC/subnet/ENI) e onde seus dados vivem (EBS vs Instance Store). As decisões são sempre trade-offs entre custo, performance e durabilidade.

---

1. Escolha do tipo de instância

O que é uma instância EC2: uma máquina virtual (VM) com vCPUs, memória, rede e armazenamento alocados — é a unidade de computação que você escolhe para rodar sua aplicação.

• Analise CPU, memória, I/O e rede necessários.
• Use families: t para cargas burstable leves (T-series), m general purpose, c compute, r memória, i storage otimizadas.

Explicação didática: comece medindo sua aplicação em um ambiente representativo. Se o uso médio de CPU for baixo com picos ocasionais, t pode economizar custos; se a aplicação é sensível à latência de CPU, prefira c ou m. Sempre verifique métricas de CloudWatch antes de redimensionar.

Breve orientação por família:

• t (burstable): bom para microserviços leves, ambientes de desenvolvimento e cargas com baixa utilização média.
• m (general purpose): equilíbrio entre CPU e memória para a maioria das aplicações web e APIs.
• c (compute-optimized): workloads CPU-bound (batch, codificação, HPC simples).
• r (memory-optimized): bancos em memória, caches, cargas analíticas que exigem muita RAM.
• i (storage-optimized): I/O intensivo, bancos de dados locais e workloads orientadas a disco.

1.1 CPU Credits — como a série t realmente funciona

As instâncias t (T3, T3a, T4g) não têm CPU dedicada em tempo integral — elas ganham CPU credits continuamente, a uma taxa fixa por hora, mesmo quando ociosas. Usar CPU consome créditos; ficar ocioso acumula créditos (até um teto).

• Enquanto há créditos acumulados, a instância pode usar 100% de CPU ("burst").
• Se os créditos se esgotam, a performance de CPU é limitada de volta à baseline da instância (uma fração fixa de um vCPU completo) até acumular créditos de novo.
• Modo Unlimited: permite estourar além dos créditos acumulados, pagando uma taxa extra por uso sustentado acima do baseline — evita degradação de performance, ao custo de previsibilidade de preço.

💡 Regra para a prova: se o enunciado descreve uma aplicação t3 que "de repente ficou lenta sob carga sustentada", pense em esgotamento de CPU credits — a solução é modo Unlimited, ou migrar para uma família sem esse mecanismo (m, c).

Checklist rápido:

• Recolha métricas: CPU, memória, I/O e latência de rede.
• Compare custo por vCPU e por GB de memória entre famílias.
• Execute benchmarks representativos antes de migrar produção.

---

2. Modelos de preço (detalhado)

O que são modelos de preço: diferentes formas de pagar por instâncias EC2, com trade-offs entre custo, flexibilidade e garantia de capacidade.

• On-Demand: pago por hora/segundo sem compromisso — alto custo, alta flexibilidade.
• Reserved Instances (RIs): compromisso de 1 ou 3 anos por desconto; bom para cargas previsíveis.
• Savings Plans: compromisso de gasto (não de instância específica) por 1 ou 3 anos; mais flexível que RIs entre families/regions.
• Capacity Reservations: reserva capacidade numa AZ — garante capacidade sem desconto automático.
• Spot Instances: descontos significativos, sujeitas a interrupções — ótimo para workloads tolerantes a falhas.
• Dedicated Hosts / Dedicated Instances: capacidade num hardware físico isolado — ver seção 2.2.

2.1 Reserved Instances: Standard vs Convertible

• Standard RI: maior desconto, mas você fica preso ao tipo/família de instância contratado — pode mudar AZ ou tamanho dentro da mesma família em alguns casos, mas não trocar de família.
• Convertible RI: desconto um pouco menor, mas permite trocar a instância por outra de família/tipo diferente durante o período contratado, desde que o valor equivalente ou maior seja mantido — útil quando você espera que suas necessidades de instância mudem ao longo do compromisso.

💡 Se o enunciado menciona "pode precisar mudar de tipo de instância no futuro, mas quer desconto de longo prazo", pense em Convertible RI; se o padrão é fixo e previsível, Standard RI dá mais desconto.

2.2 Dedicated Hosts vs Dedicated Instances

Ambos rodam em hardware físico não compartilhado com outras contas — diferença está em quem controla o quê:

• Dedicated Host: você aluga o servidor físico inteiro, com visibilidade sobre os sockets/cores físicos. Necessário quando há requisitos de licenciamento por socket/core (ex: licenças de software legado que cobram por CPU física) ou compliance que exige isolamento físico auditável.
• Dedicated Instance: roda em hardware dedicado à sua conta, mas você não tem visibilidade/controle sobre a alocação física exata — mais simples, resolve o requisito de "não compartilhar hardware com outras contas", sem a granularidade de licenciamento do Dedicated Host.

2.3 Spot Instances — o aviso de interrupção

Spot Instances usam capacidade ociosa da AWS com desconto de até 90%, mas a AWS pode retomar a instância a qualquer momento, avisando com ~2 minutos de antecedência via evento no metadata da instância (ou EventBridge). Sua aplicação precisa ser tolerante a essa interrupção — tipicamente salvando estado/checkpoint ao receber o aviso, ou sendo stateless o suficiente para simplesmente ser recriada em outro lugar.

Decisão arquitetural: combine modelos (ex.: ASG com mixed instances — on-demand para baseline + spot para capacidade elástica) e use RIs/Savings para cargas estáveis.

Checklist de decisão rápida:

• Flexibilidade máxima → On-Demand.
• Redução de custo em cargas estáveis → RIs ou Savings Plans.
• Trabalho tolerante a interrupções → Spot.
• Garantir capacidade em janelas críticas → Capacity Reservations.
• Requisito de licenciamento por core/socket físico → Dedicated Host.

Exemplo prático: para um serviço web com 1 unidade mínima e picos noturnos (~50%):

• Base: 1–2 instâncias On-Demand cobertas por Savings Plan ou RIs
• Escala: ASG com mixed instances adicionando Spot durante picos

Resultado: menor custo sem sacrificar disponibilidade.

---

3. AMIs e inicialização (detalhes relevantes)

• O que é uma AMI (Amazon Machine Image): uma AMI é uma imagem pré-configurada que representa o estado de uma máquina virtual — inclui o sistema operacional, pacotes instalados, configurações e, opcionalmente, arquivos e scripts de inicialização. Ao lançar uma instância EC2 você especifica uma AMI como base; a AMI define o conteúdo do root volume inicial.

• Analogia didática: pense na AMI como um snapshot de uma máquina pronta para uso — é como um modelo de disco que você pode clonar para criar várias instâncias idênticas.

• Tipos e diferenças importantes:

  • EBS-backed AMI: o root volume é um volume EBS. Permite stop/start mantendo o conteúdo do root; snapshots EBS podem ser criados para backup e versionamento. É o padrão mais usado em produção.
  • Instance-store-backed AMI: o root fica em armazenamento efêmero ligado ao host físico. Se a instância for parada ou o host falhar, os dados do root são perdidos. Útil apenas para casos onde a inicialização é rápida e o estado local não precisa ser preservado.

• Fontes das AMIs:

  • Públicas: fornecidas pela AWS (Amazon Linux, Ubuntu, Windows).
  • Marketplace: imagens de terceiros (controle de licenciamento pode aplicar-se).
  • Customizadas: AMIs construídas pela sua equipe via pipeline (recomendado para produção).

• Como usar AMIs de forma segura e reprodutível:

  • Prefira imagens imutáveis (golden AMI) geradas por um pipeline automatizado (Packer, EC2 Image Builder) que executa testes e injeta versões.
  • Use tags semânticas (ex.: app-ami:v1.2.3) e registre metadados (commit, artefato, data).
  • Automatize a rotação e depreciação de AMIs antigas para evitar drift.

• Inicialização e bootstrapping:

  • Use user-data/cloud-init para comandos de bootstrap simples (instalar pacotes, buscar configurações). Para configurações mais complexas, prefira configuration management (Ansible/Chef) ou imagens já preparadas.
  • Exemplo simples de user-data com cloud-init (instala nginx em Ubuntu):

#!/bin/bash
apt-get update -y
apt-get install -y nginx
systemctl enable nginx
systemctl start nginx

• Checklist rápido ao decidir criar uma AMI customizada:
  • ✅ Scripts de teste automatizados executados durante o bake
  • ✅ Remoção de chaves/credenciais sensíveis antes de salvar a AMI
  • ✅ Tag e versionamento claros
  • ✅ Documentação sobre o propósito da AMI e pacotes incluídos

Dica prática: crie um pipeline de criação de AMI (bake) que executa testes automatizados, valida configurações e publica a AMI com tag de versão. Assim você evita configuração manual pós-lançamento e consegue reproduzir ambientes facilmente.

Diagrama: pipeline de criação de AMI

graph TD
	Repo["Código / Artefatos"] --> CI["CI (build & tests)"]
	CI --> Packer["Packer / Bake"]
	Packer --> AMI["AMI versionada"]
	AMI --> LaunchTemplate["Launch Template"]
	LaunchTemplate --> ASG["ASG / Launch"]
	ASG --> EC2["EC2 (instâncias)"]

---

4. Armazenamento: EBS vs Instance Store

4.1 Tipos de volume EBS

Nem todo EBS é igual — a escolha do tipo é uma decisão de custo x performance, e a prova cobra isso com frequência:

💡 Regra para a prova: "banco de dados transacional, precisa de IOPS alto e consistente" → io2. "propósito geral, custo-benefício" → gp3. "processamento sequencial em lote, throughput alto, custo baixo" → st1. "dados raramente acessados" → sc1.

4.2 Snapshots do EBS

Um snapshot é uma cópia pontual de um volume EBS, armazenada no S3 (de forma gerenciada — você não acessa o bucket diretamente). O primeiro snapshot copia todos os blocos usados; os snapshots seguintes do mesmo volume são incrementais, guardando só os blocos que mudaram desde o último — o que os torna rápidos e baratos de gerar repetidamente. Snapshots podem ser copiados entre regiões (útil para disaster recovery) e usados para criar novos volumes ou AMIs.

4.3 EBS vs Instance Store

• EBS (persistente): persistência entre stop/start, snapshots incrementais, adequado para bancos e dados críticos.
• Instance Store (efêmero): armazenamento local físico com latência baixa — útil para caches, buffers e dados temporários que podem ser recriados.

Quando precisar de persistência durável → EBS
Quando precisar de I/O local muito rápido e dados temporários → Instance Store

Exemplo: uma fila de processamento que descarrega itens no disco temporário para processamento paralelo pode usar Instance Store para máxima I/O; os resultados confirmados são enviados para S3 ou EBS persistente.

Pergunta-chave para decidir: "Se a instância morrer, esses dados podem ser perdidos e recomputados?" Se sim → Instance Store; caso contrário → EBS.

⚠️ Atenção ao atributo "Delete on Termination" do root volume EBS: por padrão, ele é true para o root volume — ou seja, ao terminar a instância, o volume é apagado junto. Se você precisa preservar o disco após terminar a instância (para investigação ou reuso), desmarque essa flag antes de terminar.

---

5. Networking essencial para EC2

• VPC / Subnet: instâncias vivem dentro de subnets (pública vs privada). Subnet pública tem rota para Internet Gateway.
• Endereço IP: instância recebe IP privado (sempre) e pode receber IP público ou Elastic IP (EIP) para acesso fixo público.
• ENI (Elastic Network Interface): interface de rede que pode ter múltiplos IPs; útil para alta disponibilidade (reattach) e múltiplos serviços por instância.
• Security Groups: stateful, aplicados a ENIs/instâncias; defina regras de entrada/saída por porta/protocolo.
• Elastic IP: endereço público estático atribuído a instâncias/ENIs; cuidado com custos quando não em uso.

Relação prática: coloque bancos em subnets privadas sem IP público; aplicações front-end em subnets públicas ou atrás de load balancer.

Exemplo passo-a-passo (básico):

1. Crie uma VPC com subnets por AZ (pública e privada).
2. Coloque ALB em subnets públicas; EC2 de aplicação em subnets privadas.
3. Banco de dados em subnet privada sem rota para Internet Gateway.
4. Use Security Groups: ALB permite 80/443; app permite somente tráfego do ALB; banco permite tráfego apenas da app.

Regra prática: prefira mover recursos para subnets privadas e expor via load balancer em vez de atribuir IPs públicos às instâncias.

Diagrama: arquitetura de rede (public / private / NAT / ENI)

graph LR
	Internet --> IGW["Internet Gateway"]
	IGW --> PublicSubnet["Subnet Pública"]
	PublicSubnet --> ALB["ALB\n(public subnets)"]
	ALB --> PrivateSubnet["Subnet Privada"]
	PrivateSubnet --> EC2["EC2\n(instâncias)"]
	EC2 --> ENI["ENI\n(múltiplos IPs)"]
	PrivateSubnet --> NAT["NAT Gateway\n(EIP)"]
	NAT --> IGW

---

6. Instance Metadata Service (IMDS) e IMDSv2

Toda instância EC2 pode consultar informações sobre si mesma (IP, AMI, role/credenciais IAM anexadas etc.) chamando um endereço interno especial: http://169.254.169.254. Isso é o Instance Metadata Service (IMDS).

O problema: na versão original (IMDSv1), essa chamada é um simples GET HTTP sem autenticação — se a aplicação rodando na instância tiver uma vulnerabilidade de SSRF (Server-Side Request Forgery, onde um atacante induz o servidor a fazer uma requisição HTTP arbitrária), o atacante pode fazer a própria instância "vazar" para si mesma as credenciais temporárias da IAM Role anexada.

IMDSv2 corrige isso exigindo uma sessão: primeiro um PUT para obter um token (com um "hop limit" configurável, dificultando o encaminhamento do pedido a partir de outra camada de rede), e só então um GET usando esse token no header. Isso praticamente elimina a classe de ataque via SSRF simples.

💡 Para a prova: se o cenário menciona "proteger contra SSRF" ou "vazamento de credenciais via metadata service", a resposta é exigir/forçar IMDSv2 (é possível configurar a instância para aceitar só IMDSv2, recusando IMDSv1).

---

7. Ciclo de vida: Stop, Hibernate e Terminate

Hibernate é útil para workloads onde reconstruir o estado de memória do zero (cache quente, sessões em memória) é caro — ao dar start numa instância hibernada, ela volta exatamente de onde parou, RAM incluída.

Termination protection: uma flag que impede a instância de ser terminada acidentalmente (via console/CLI/API) até ser explicitamente desativada — recomendada para instâncias críticas (ex: banco de dados rodando em EC2).

---

8. Auto Scaling e alta disponibilidade

• Auto Scaling Groups (ASG): gerenciam contagem de instâncias com políticas (target tracking, step scaling, scheduled).
• Launch Templates / Launch Configurations: definem a configuração usada pelo ASG (AMI, tipo, ENI, user-data). Launch Templates são recomendados (mais recursos que Launch Configs).
• Load Balancers (ALB/NLB): distribuem tráfego entre instâncias; use health checks para remover instâncias com falha.
• Distribuição entre AZs: configure ASG para lançar instâncias em múltiplas AZs para tolerância a falhas; combine com subnets por AZ.
• Mixed Instances Policy: permite ASG com várias families/tipos + Spot + On-Demand.

Failover e escalabilidade: use ALB + ASG + múltiplas AZs para alta disponibilidade e scaling automático.

Exemplo de configuração simples:

• ASG definido com subnets em 3 AZs
• Launch Template apontando para a AMI versionada
• ALB com health checks configurados para endpoints de /health
• Policy de target tracking baseada em CPU ou em latency

Ponto de atenção: configure health checks adequadamente (application vs EC2) para evitar remoção incorreta de instâncias.

Diagrama: ASG com mixed instances e tratamento de Spot interruption

graph LR
	Client["Clientes / Internet"] --> ALB["ALB"]
	ALB --> ASG["ASG (mixed: on-demand + spot)"]
	ASG --> OnDemand["On-Demand (baseline)"]
	ASG --> Spot["Spot (capacidade elástica)"]

	Spot -. Interruption .-> ASG
	ASG -->|deregister| ALB
	ASG -->|replace| OnDemand
	OnDemand --> EC2["EC2 instances"]

---

9. Placement Groups

• Cluster Placement Group: baixa latência e alta largura entre instâncias (network-optimized). Requer hardware homogêneo, e todas as instâncias ficam numa única AZ — pode falhar se não houver capacidade suficiente naquele hardware específico.
• Spread Placement Group: espalha instâncias em hardware físico distinto, reduzindo risco de falha localizada. Limite prático de 7 instâncias por AZ por spread group — pensado para poucas instâncias críticas, não para clusters grandes.
• Partition Placement Group: divide instâncias em partições (cada uma em hardware distinto, sem partilhar rack), com isolamento de falha entre partições — usado em sistemas distribuídos grandes (ex: Hadoop, Kafka, Cassandra) que já têm noção própria de replicação por partição.

Use placement groups quando a topologia de rede/latência exigir garantias específicas.

Exemplo de aplicação: clusters de processamento distribuído ou HPC que dependem de alta largura de banda entre nós se beneficiam de Cluster Placement Group.

Teste antes de mover produção: placement groups podem falhar ao lançar (InsufficientInstanceCapacity) se não houver capacidade disponível para o tipo/quantidade requisitada — especialmente em Cluster mode.

---

10. Boas práticas

• Projetar para falha: instâncias são efêmeras — use ASG, balancers e múltiplas AZs.
• Isolar bancos/estados em subnets privadas; usar roles para acesso a serviços.
• Automatizar AMI builds e testes; versionar imagens.
• Monitorar métricas de CPU, memória, EBS IOPS e network com CloudWatch e definir alarms.
• Forçar IMDSv2 em todas as instâncias como padrão de segurança.
• Ativar termination protection em instâncias críticas de produção.

Resumo prático:

• Automatize: AMIs, deployments e políticas de scaling
• Segregue rede: subnets privadas para estado; públicas para frontend
• Teste falhas: simule AZ failures e reinícios para validar arquiteturas multi-AZ

Pequeno exercício: configure um ASG com 0 capacidade mínima e um job que escala para 5 instâncias; teste se a aplicação continua saudável quando uma AZ é derrubada (simulada).

---

11. Exercícios práticos conceituais

1. Desenhe uma arquitetura para uma aplicação web com tráfego variável, garantindo alta disponibilidade entre AZs e custo otimizado.
2. Explique como você combinaria RIs/Savings Plans e Spot Instances para reduzir custo mantendo SLA de 99.9%.
3. Proponha uma estratégia para dados temporários (cache) que exige alta I/O local.
4. Defina regras de Security Group para uma aplicação web pública e seu banco em uma subnet privada.
5. Explique por que uma instância t3.micro rodando uma tarefa de processamento contínua pode ficar lenta depois de algum tempo, e duas formas de resolver isso.
6. Descreva como o IMDSv2 mitiga um ataque de SSRF que o IMDSv1 não mitigaria.
7. Escolha o tipo de volume EBS (gp3, io2, st1 ou sc1) para: (a) um banco transacional de alta escrita, (b) um data lake processado em lote uma vez por dia, (c) arquivos de log raramente acessados.

---

12. Como cai na certificação

• Enunciado destaca "tolerância a interrupção" sem necessidade de persistência → pense em Spot + ASG.
• Enunciado pede "garantia de capacidade" → pense em Capacity Reservations (+ RIs se quiser desconto também).
• Enunciado menciona "baixa latência entre nós" → avalie Cluster Placement Group.
• Enunciado menciona licenciamento por core/socket físico → Dedicated Host, não Dedicated Instance.
• Enunciado descreve uma instância t "lenta depois de um tempo sob carga sustentada" → esgotamento de CPU credits; solução é modo Unlimited ou trocar de família.
• Enunciado menciona "proteger contra SSRF" ou vazamento de credenciais via metadata → forçar IMDSv2.
• Enunciado pede "preservar RAM entre paradas" → Hibernate, não Stop simples.
• Enunciado pede performance de disco consistente e alta para banco → io2; propósito geral → gp3; batch sequencial barato → st1; arquivamento raro → sc1.

---

13. Questões de Revisão

Questão 1

Questão 2

Questão 3

Questão 4

Questão 5

Questão 6

Questão 7

Questão 8

Questão 9

Questão 10

Questão 11

Questão 12

Questão 13

Questão 14

Questão 15

Questão 16

Questão 17

Questão 18

Questão 19

Questão 20

Questão 21

Questão 22

Laboratório Prático

Objetivo: lançar uma instância EC2 com IMDSv2 obrigatório, testar snapshots incrementais de EBS, e observar a diferença entre Stop e Hibernate.

Pré-requisitos: conta AWS com permissão para EC2 e EBS.

Tempo estimado: 25 minutos

Possíveis custos: mínimo, se usar t3.micro dentro do free tier e limpar os recursos ao final.

Passos:

1. Lance uma instância EC2 (t3.micro, Amazon Linux), com uma IAM Role anexada com permissão de leitura em um bucket S3 de teste.
2. Nas opções avançadas de rede, configure IMDSv2 como obrigatório ("Required", não "Optional").
3. Conecte na instância via Session Manager e tente obter as credenciais da role usando um GET simples em http://169.254.169.254/latest/meta-data/iam/security-credentials/ sem token — deve falhar.
4. Repita o processo corretamente: faça o PUT para obter o token, depois use o token no header do GET — deve funcionar.
5. Crie um snapshot do volume EBS root da instância. Modifique um arquivo pequeno na instância e crie um segundo snapshot — observe no console que o segundo é significativamente menor/mais rápido (incremental).
6. Habilite hibernação na instância (exige AMI e configuração compatíveis) e pare a instância no modo Hibernate; depois reinicie e confirme que processos em memória continuaram de onde pararam (compare com um Stop comum, onde a RAM é perdida).

Resultado esperado: você confirma na prática que o IMDSv2 bloqueia acesso não autenticado ao metadata, que snapshots são incrementais, e que Hibernate preserva RAM enquanto Stop não preserva.

Limpeza dos recursos: termine a instância, delete os snapshots criados e o volume EBS caso não seja apagado automaticamente.

---

Referências:

• EC2 Instance Types: https://aws.amazon.com/ec2/instance-types/
• EBS Volumes: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html
• Instance Metadata Service (IMDSv2): https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html
• CPU Credits (burstable performance): https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html
• Spot Instances: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html
• Placement Groups: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html