AMIs e EC2 Image Builder

Um Auto Scaling group adiciona uma instância durante um pico de tráfego. A instância dá boot em uns 40 segundos e depois passa mais 8 minutos no user data: aplicando patches, baixando três agentes e compilando uma dependência. Quando ela finalmente passa no health check, o pico já acabou. Pior: a instância que subiu na terça passada instalou versões de pacote um pouco diferentes da que subiu hoje, porque as duas resolveram "latest" contra um repositório que mudou no meio do caminho.

Os dois problemas têm a mesma solução. Faça esse trabalho uma vez, antes do launch, e guarde o resultado como imagem.

O que uma AMI é de verdade

Uma Amazon Machine Image não é um arquivo que você baixa. É um registro dentro do EC2 que aponta para um ou mais snapshots EBS e carrega os metadados necessários para transformar esses snapshots numa instância que dá boot:

• O block device mapping: qual snapshot vira o volume raiz, qual o tamanho dele, quais volumes adicionais são anexados e se eles são apagados no terminate.
• Os metadados de boot e plataforma: arquitetura (x86_64 ou arm64), tipo de virtualização, tipo de dispositivo raiz e boot mode.
• As launch permissions: quais contas, organizações ou OUs podem subir instâncias a partir dela.

Duas consequências saem dessa estrutura, e as duas aparecem na prova.

Uma AMI é regional. Os snapshots vivem em uma Região, então o AMI ID só faz sentido naquela Região. Para subir a mesma imagem numa segunda Região você copia ela para lá, e a cópia ganha um AMI ID diferente. É por isso que um template do CloudFormation com AMI ID fixo quebra no instante em que alguém implanta ele em outro lugar.

Você não paga pela AMI, você paga pelos snapshots dela. O registro da AMI em si é gratuito. Cada AMI que você já criou está cobrando de você, em silêncio, o armazenamento dos snapshots por trás dela, e é por isso que a seção de limpeza no fim desta lição importa mais do que parece.

A AMI também é fixa em algumas propriedades. Você não transforma uma AMI x86_64 em arm64, nem converte uma AMI instance-store em uma AMI EBS-backed. Quando você precisa de outra combinação, você constrói uma imagem nova.

Assar ou bootstrapar: a decisão que molda todo o resto

Cada pedaço de configuração de que um servidor precisa pode chegar de dois jeitos. Assar coloca ele na imagem, no momento do build. Bootstrapar aplica ele no launch, via user data, uma association do Systems Manager ou uma ferramenta de gestão de configuração.

Nada obriga você a escolher um só. A pergunta útil é qual metade da sua configuração vai para onde.

A regra de decisão que sai dessa tabela: asse o que é lento e estável, bootstrape o que é rápido e varia. Patches do sistema operacional, agentes, runtimes e dependências compiladas são lentos e estáveis, então vão para a imagem. O endpoint do banco, o nome do ambiente e o papel da instância no cluster são rápidos e variam por deploy, então vão para o user data ou o Parameter Store.

Uma imagem construída assim costuma ser chamada de AMI dourada: uma base endurecida, com patches e software pré-carregado, a partir da qual toda carga da organização sobe.

E aqui está o mal-entendido que esta seção existe para matar: "AMI dourada quer dizer que tudo está na imagem." Leve isso longe demais e você vai reconstruir uma imagem para mudar um nível de log, mantendo uma imagem por ambiente por aplicação. A imagem é a linha de largada, não um servidor pronto.

Por que AMIs douradas feitas na mão param de funcionar

A primeira AMI dourada é fácil. Suba uma instância, aplique os patches, instale o que precisa, rode create-image e anote o AMI ID numa página de wiki.

O segundo mês é onde isso desmonta. Novas CVEs aparecem, então a imagem precisa de rebuild, e a pessoa que construiu está de férias e nunca escreveu o passo 4. Ninguém testou a imagem nova antes de um Auto Scaling group começar a subir instâncias com ela. A imagem existe só em us-east-1, e a Região de DR também precisa dela. Não existe registro do que mudou entre a versão 3 e a versão 4.

Essas falhas não são preguiça. São o que acontece quando um processo de build mora na memória de alguém em vez de morar num arquivo. O EC2 Image Builder existe para mover ele para arquivos.

Os cinco recursos do Image Builder

O Image Builder divide um build de imagem em cinco recursos, e quando você vê o que cada um é dono, o serviço para de parecer grande.

Dois desses merecem um olhar mais de perto.

Components são onde sua customização de verdade mora. Um component é um documento YAML simples que o AWSTOE roda na instância de build, e ele vem em dois sabores: build components customizam a instância antes do snapshot, e test components validam a instância depois dele. A AWS publica components gerenciados para tarefas comuns, incluindo update-linux e os conjuntos de hardening STIG e CIS, e você escreve os seus para o que for específico da sua casa.

name: InstallAndVerifyNginx
description: Instala o nginx e confirma que ele responde na porta 80
schemaVersion: 1.0
phases:
  - name: build
    steps:
      - name: InstallNginx
        action: ExecuteBash
        inputs:
          commands:
            - dnf install -y nginx
            - systemctl enable nginx
  - name: validate
    steps:
      - name: ConfirmBinary
        action: ExecuteBash
        inputs:
          commands:
            - nginx -v

Os nomes das fases não são decoração. O Image Builder decide quando um component roda pelas fases que ele define: o component roda no build stage se define build ou validate, e roda no test stage se define test e mais nada. Um component não fica com um pé em cada estágio, e você não encadeia um valor produzido em build dentro de um passo de test, porque esses estágios rodam em instâncias diferentes.

Infrastructure configuration é o recurso de que as pessoas só lembram quando um build falha. A instância de build roda dentro da sua VPC, o que significa que ela precisa de uma subnet com rota para alcançar os repositórios de pacote, um security group que permita esse tráfego e um instance profile com as permissões do Image Builder. É lá também que fica a chave de diagnóstico: por padrão a instância de build é encerrada quando o build falha, e desligar esse comportamento mantém a instância viva para você entrar nela e ler os logs do AWSTOE.

O que uma execução de pipeline faz de fato

Acompanhe um build do começo ao fim, porque a ordem explica várias respostas de prova.

1. Build stage. O Image Builder sobe uma instância EC2 a partir da imagem base, dentro da subnet definida na sua infrastructure configuration. O AWSTOE roda a fase build de cada build component na ordem do recipe, depois a fase validate de cada um. Se qualquer passo falhar, o build para aqui.
2. Snapshot. Com as customizações aplicadas, o Image Builder para a instância e tira um snapshot, produzindo a imagem candidata.
3. Test stage. Num fluxo de AMI, o Image Builder sobe uma instância nova a partir dessa imagem candidata e roda a fase test de cada component do recipe. É um launch de verdade do artefato de verdade, não uma reconferência da instância de build, e é por isso que ele pega um serviço que não sobe no primeiro boot.
4. Distribuição. Só se todos os testes passarem o Image Builder copia a AMI para cada Região das suas distribution settings, aplica a chave KMS configurada, define as launch permissions e, se você quiser, atualiza um launch template para apontar para o novo AMI ID.

Essa última opção merece uma pausa. A distribuição pode escrever o novo AMI ID dentro de uma versão específica de um launch template do EC2, então um Auto Scaling group apontado para a versão $Latest ou $Default desse template pega a imagem nova sem ninguém editar nada.

O serviço em si é gratuito. Você paga pelas instâncias EC2 de build e de teste enquanto elas rodam, pelos snapshots EBS que as imagens ocupam, pelo armazenamento de logs no S3, pelo Amazon Inspector se você ligar a varredura de vulnerabilidades durante o build e pelo armazenamento no ECR quando a saída é imagem de contêiner.

Agendamento: construir por relógio ou construir por mudança

Um pipeline roda sob demanda, num agendamento cron ou em resposta a uma regra do EventBridge. O agendamento tem um segundo ajuste que carrega a maior parte do valor, e ele é alvo frequente de prova.

• Rodar no horário agendado, sempre. Todo horário agendado produz um build, tendo mudado algo lá em cima ou não. Você ganha uma imagem nova numa cadência fixa e paga por um build a cada vez.
• Rodar no horário agendado só se houver atualizações de dependência. O Image Builder checa se a imagem base ou algum component tem uma versão semântica mais nova e pula o build se nada se moveu.

A segunda opção só funciona se o seu recipe usar versionamento semântico para a imagem base e para os components, o que no console significa escolher "usar a última versão de sistema operacional disponível" e "usar a última versão disponível" em vez de fixar uma string de versão exata. Fixe tudo em versões exatas e o Image Builder fica sem nada para comparar, então ou ele reconstrói toda vez ou nunca detecta atualização, dependendo de como o recipe foi escrito.

Um pipeline semanal configurado para construir apenas quando há atualização de dependência é o formato que a maioria dos times quer: nenhuma imagem nova numa semana parada e uma imagem com patch na hora em que a AWS publica uma imagem base nova.

Distribuir e compartilhar o resultado

As distribution settings resolvem o trabalho entre Regiões e entre contas que as pessoas fariam na mão.

Dentro da sua própria conta, a distribuição copia a AMI para cada Região de destino. Entre contas você tem duas opções diferentes, e a diferença é sobre propriedade:

• Launch permissions deixam outra conta subir instâncias a partir da sua AMI. Você continua dono da imagem, continua pagando pelos snapshots, e a outra conta paga só pelas instâncias que ela sobe. Revogue a permissão e os launches futuros dela param.
• Contas e OUs de destino criam uma cópia da AMI em cada conta de destino. Aquela conta passa a ser dona da cópia e paga pelos snapshots dela, e a cópia sobrevive a qualquer coisa que você faça com a original.

A criptografia acrescenta um requisito que derruba mais gente do que qualquer outra parte do compartilhamento de AMI. Uma AMI cujos snapshots estão criptografados com a chave AWS managed padrão não pode ser compartilhada de jeito nenhum, porque você não consegue editar a policy daquela chave. Compartilhar uma AMI criptografada significa criptografar os snapshots dela com uma chave KMS customer managed e conceder às contas de destino permissão de uso dessa chave. O caminho comum é uma cópia: copie a AMI para ela mesma especificando a sua chave e compartilhe a cópia.

Dois comportamentos menores que vale saber. Você não precisa compartilhar os snapshots à parte, porque o EC2 concede o acesso de launch a eles em seu nome. E as tags que você definiu não viajam junto com uma AMI compartilhada, então a conta que recebe vê uma imagem sem tag.

Aposentar uma imagem: três verbos que não são sinônimos

Uma organização que constrói uma AMI dourada por semana tem 52 imagens por ano, por Região, por sistema operacional. Limpar isso é trabalho operacional de verdade, e a AWS dá três ações distintas que os estudantes costumam misturar.

Leia essa tabela como uma escada. Deprecate é um sinal: pare de escolher esta imagem, mas nada quebra. Disable é um freio: os launches falham e você pode desfazer. Deregister é exclusão.

Os números que a AWS cobra direto: você define uma data de deprecation de até 10 anos para uma AMI privada, AMIs públicas recebem deprecation padrão 2 anos depois da criação, e o único jeito de empurrar a deprecation de uma AMI pública para mais longe é torná-la privada, compartilhando com contas específicas.

E existe a armadilha de custo. Fazer deregister de uma AMI não apaga os snapshots por trás dela por padrão. Um time que faz deregister de 40 AMIs velhas esperando a conta de armazenamento cair vai levar um susto, porque os snapshots continuam lá. Passe --delete-associated-snapshots na chamada de deregister ou limpe depois. Um snapshot referenciado por mais de uma AMI é mantido de qualquer forma.

Nada disso precisa ser feito na mão. As lifecycle policies do Image Builder aplicam ações de deprecate, disable e delete às imagens que um pipeline produziu, com regras por idade e por contagem, mais regras de exclusão para proteger imagens que você precisa manter. O Amazon Data Lifecycle Manager cobre o mesmo terreno para AMIs EBS-backed em geral, inclusive as que você não construiu com o Image Builder.

Dicas para a prova

• "Parar os launches agora, com possibilidade de desfazer depois" é disable. "Marcar como desatualizada mas manter funcionando" é deprecate. "Apagar" é deregister. As opções que misturam os efeitos são os distratores.
• Se um enunciado diz que um Auto Scaling group continua subindo instâncias de uma imagem velha depois do time ter feito deprecate, isso é o comportamento esperado, não um defeito. Deprecate esconde uma AMI das listagens; nunca bloqueia um launch por ID.
• Deregister sozinho não para a conta de snapshot. Qualquer resposta que trate deregister como limpeza completa está errada.
• Compartilhar AMI criptografada exige chave KMS customer managed mais permissão de uso para a conta de destino. Se o enunciado menciona a chave AWS managed padrão, o compartilhamento não funciona, e a resposta passa por copiar com a sua chave.
• Um pipeline do Image Builder que falha nos testes não distribui nada. Se a questão pergunta por que uma AMI nova nunca apareceu na Região de DR, um test component com falha é suspeito principal, junto com a Região simplesmente não estar nas distribution settings.
• "Construir só quando a imagem base recebe patch" é o ajuste de atualização de dependência no agendamento, e ele depende de versionamento semântico no recipe.
• O Image Builder em si é gratuito. A cobrança vem das instâncias de build e teste, dos snapshots, dos logs, do Inspector e do ECR.
• Fique de olho na divisão entre assar e bootstrapar nos cenários. Tempo de launch longo aponta para assar; configuração por ambiente aponta para bootstrap.

A ideia para levar daqui é que uma imagem é um artefato de build com versão, suíte de testes e prazo de validade, não um servidor que alguém configurou um dia. Esse enquadramento é o que deixa o domínio inteiro coerente: a imagem é construída a partir de um arquivo, testada antes de sair, distribuída por política e aposentada no prazo.

Tudo nesta lição assumiu que a unidade que você entrega é uma máquina. A próxima lição troca essa premissa. Quando a máquina já existe e só a aplicação muda, você entrega uma imagem de contêiner, e quase toda ideia daqui reaparece numa forma menor e mais rápida.