AWS ECR (Registry de Contêineres)

O Amazon Elastic Container Registry (ECR) é o serviço gerenciado da AWS para armazenar, versionar e distribuir imagens de contêineres, compatível com a API do OCI/Docker Registry. Ele funciona como o repositório central do pipeline de entrega: o CI constrói a imagem, faz push para o ECR, e o ECS, EKS ou qualquer ambiente com credenciais da AWS faz pull da mesma referência imutável. Por ser nativo, integra-se diretamente com IAM para autorização, com CloudTrail para auditoria, com EventBridge para reação a eventos e com serviços de scan de vulnerabilidades. Em produção, o registry é infraestrutura crítica: se ele estiver indisponível ou lento, deploys param e clusters não conseguem restaurar réplicas. Tratar o ECR com o mesmo cuidado dedicado a banco e fila, incluindo políticas de retenção, segurança e replicação, é parte da maturidade de uma plataforma de entrega.

Conceito e problema que resolve

Sem um registry gerenciado, o time improvisa com daemon local, servidor de artefatos artesanal ou imagens públicas sem governança. Os problemas típicos incluem imagens com segredos vazados, tags sobrescritas que quebram rollback, ausência de rastreabilidade até o commit e pulls lentos atravessando a internet. O ECR resolve cada ponto com mecanismos nativos: repositórios privados por padrão, integração IAM para autenticação e autorização, endpoints VPC para tráfego interno, scan automático de CVEs e políticas de ciclo de vida.

O objeto central é o repositório, que abriga uma aplicação ou imagem e suas tags. Cada push de tag gera um novo manifesto com digest único e imutável. O registro de imagens pública separado permite publicar artefatos externos quando necessário, mas o caso de produção é o repositório privado, acessível por entidades IAM autorizadas dentro da conta ou por contas confiáveis via policy de repositório.

Integração com IAM e com o ECS

A autenticação no ECR usa token temporário obtido com credenciais AWS, não login persistente. O comando aws ecr get-login-password gera o token que o Docker usa para push e pull; em ECS e EKS, o agente resolve credenciais automaticamente via role de execução, sem token manual. A autorização é declarada por políticas IAM que restringem ações como ecr:GetAuthorizationToken, ecr:BatchGetImage e ecr:PutImage por repositório e por condição.

# Autentica o Docker no ECR usando credenciais da CLI da AWS
aws ecr get-login-password --region sa-east-1 \
  | docker login --username AWS --password-stdin 123456789012.dkr.ecr.sa-east-1.amazonaws.com

# Cria um repositório privado com scan no push e tags imutáveis
aws ecr create-repository \
  --repository-name pedidos/api \
  --image-scanning-configuration scanOnPush=true \
  --image-tag-mutability IMMUTABLE \
  --region sa-east-1

# Build, tag e push da imagem versionada pelo hash do commit
docker build -t pedidos/api:1.8.3 .
docker tag pedidos/api:1.8.3 123456789012.dkr.ecr.sa-east-1.amazonaws.com/pedidos/api:1.8.3
docker push 123456789012.dkr.ecr.sa-east-1.amazonaws.com/pedidos/api:1.8.3

# Lista as tags mais recentes e o digest de cada manifesto
aws ecr describe-images --repository-name pedidos/api \
  --query 'sort_by(imageDetails,&imagePushedAt)[-5:].[imageTags[0],imageDigest]'

No ECS, a task definition referencia a URI completa do repositório; a execution role precisa de permissão de leitura no ECR e de acesso ao KMS quando o repositório usa criptografia com chave própria. Em pipelines, o princípio é que a mesma imagem aprovada em QA seja promovida a produção, sem rebuild, apenas reutilizando o digest original.

Scan de vulnerabilidades

O ECR integra dois motores de scan. O scanning básico usa o Clair e cobre os sistemas operacionais mais comuns, listando CVEs com severidade. O scanning aprimorado, baseado em Amazon Inspector, realiza variação contínua: à medida que novas CVEs são divulgadas, o ECR reavalia imagens já armazenadas e publica resultados atualizados, permitindo detectar vulnerabilidades em artefatos que já estão em produção.

O valor operacional aparece na política de porta de qualidade: o pipeline bloqueia push ou deploy quando existem CVEs de severidade crítica ou alta, e a visão agregada de repositórios expõe imagens antigas que deveriam ser removidas ou reconstruídas. Integrar o resultado do scan como gate no CI transforma o registry em ponto de controle de segurança, e não apenas em armazém.

Lifecycle policies e retenção

Imagens acumulam rápido em ambientes com deploy frequente, e o custo de armazenamento cresce junto. As lifecycle policies do ECR automatizam a remoção por regras declaradas, avaliadas aproximadamente uma vez ao dia. Regras comuns combinam manter as últimas N imagens com tag, expirar imagens não apontadas há X dias e expirar tags mutáveis como main mantendo versões semânticas.

{
  "rules": [
    {
      "rulePriority": 1,
      "description": "Mantém as 30 versões semânticas mais recentes",
      "selection": {
        "tagStatus": "tagged",
        "tagPatternList": ["^v?[0-9]+\\.[0-9]+\\.[0-9]+$"],
        "countType": "imageCountMoreThan",
        "countNumber": 30
      },
      "action": { "type": "expire" }
    },
    {
      "rulePriority": 2,
      "description": "Expira imagens sem tag com mais de 7 dias",
      "selection": {
        "tagStatus": "untagged",
        "countType": "sinceImagePushed",
        "countUnit": "days",
        "countNumber": 7
      },
      "action": { "type": "expire" }
    }
  ]
}

Ao escrever políticas, o campo rulePriority define a ordem de avaliação, e a primeira regra que casa com a imagem decide seu destino. Sempre valide com a operação de pré-visualização antes de aplicar, pois uma regra mal escrita pode apagar versões que o rollback precisaria. Convenções estáveis de tags facilitam escrever regras seguras e previsíveis.

Replicação multi-região e imutabilidade

A replicação do ECR copia automaticamente imagens de um repositório de origem para repositórios em outras regiões ou outras contas. O caso de uso mais claro é o deploy global: o cluster de cada região faz pull do repositório local, reduzindo latência de transferência, custo de dados entre regiões e dependência de uma única região disponível. A configuração fica no registro, com prefixos de repositório como filtro, e o status de replicação é observável em CloudWatch.

A imutabilidade de tags, ativada por repositório, impede que uma tag existente seja sobrescrita. Sem isso, a tag latest pode apontar para conteúdos diferentes ao longo da semana, quebrando rollback e auditoria. Com tags imutáveis e versões semânticas geradas pelo CI, cada referência aponta para um conteúdo exato, e o digest confirma a correspondência em qualquer ambiente. Para distribuição entre contas, políticas de repositório autorizam contas específicas a fazer pull, viabilizando padrões multi-conta com conta central de artefatos.

ECR frente a outras opções de registry

A escolha do registry envolve critérios de governança, custo e ecossistema. A tabela posiciona o ECR frente às alternativas mais usadas.

Para um time já imerso na AWS, o ECR elimina a gestão de infraestrutura de registry e a sincronização de credenciais entre sistemas. Um Harbor auto-hospedado faz sentido quando a exigência é controle soberano dos artefatos ou múltiplas nuvens sem dependência de IAM; nesse caso, o time assume a responsabilidade de disponibilidade, backup e atualização do próprio registry, tratando-o como plataforma crítica.

Auditoria, monitoramento e custo

A operação do registry também é observável. CloudTrail registra cada push, pull e mudança de política, permitindo responder quem publicou o artefato executado em produção em determinado dia. CloudWatch expõe métricas de tamanho de repositório e contagem de imagens, base para alarmes de crescimento anômalo, e o EventBridge emite eventos de scan concluído e de mudanças de imagem, úteis para automatizar reações, como bloquear deploy quando um scan aponta severidade crítica.

O custo concentra-se em três componentes: armazenamento mensal por GB, tráfego de saída para transferências fora da AWS e chamadas de API. Replicação multi-região dobra o armazenamento por região adicional, o que é aceitável quando o benefício de pull local compensa; em cenários de deploy concentrado, avalie antes. Lifecycle policies, compressão de camadas no build e uso de imagens base menores reduzem os três componentes simultaneamente, e o efeito é multiplicado pela frequência de deploy do time.

Erros comuns e boas práticas

Os problemas recorrentes giram em torno de credenciais, retenção e governança. Reconhecê-los antecipadamente evita incidentes e desperdício.

• Executar pull pela internet em vez de usar endpoints VPC, pagando NAT e sofrendo latência; configure interface endpoints do ECR na sub-rede do cluster.
• Esquecer a permissão ecr:GetAuthorizationToken na role de execução, deixando tasks travadas em estado pendente.
• Ausência de lifecycle policy, acumulando terabytes de imagens abandonadas; defina retenção no primeiro dia de uso do repositório.
• Tags mutáveis em produção, impossibilitando rollback confiável; ative imutabilidade e use versões do pipeline.
• Ignorar findings de scan críticos; estabeleça SLA de correção e bloqueio de deploy por severidade.
• Criar um repositório por ambiente com builds separados, quebrando a promoção da mesma imagem; um repositório por aplicação, com tags por ambiente de destino, preserva a promessa de que o que foi testado é o que roda.
• Negligenciar o pull-through cache para imagens públicas, resultando em builds dependentes de taxas do Docker Hub e disponibilidade externa; configure o cache upstream e referencie o proxy do ECR.

Boas práticas consolidam o registry como parte da plataforma. Padronize nomes de repositório por domínio de aplicação; gere tags a partir de versão semântica e hash de commit; teste a imagem antes do push e scanne depois; monitore métricas de uso e tamanho de repositório; e mantenha políticas IAM mínimas, revisadas em cadência fixa. O ECR é simples de começar e fácil de negligenciar; o esforço de governança inicial se paga na primeira auditoria e no primeiro rollback em produção.