DEV Community: Leonan Viana

ECS Fargate com Service Discovery usando AWS Cloud Map e Terraform

Leonan Viana — Sun, 22 Mar 2026 23:25:15 +0000

Toda vez que preciso conectar dois serviços ECS Fargate, alguém no time sugere um ALB. Funciona, mas pagar ~$16/mês fixo pra resolver tráfego interno entre containers na mesma VPC é dinheiro jogado fora.

Nesse projeto montei uma alternativa usando AWS Cloud Map: dois serviços Fargate em subnets privadas, sem IP público, sem ALB. O serviço interno se registra no Cloud Map e o Nginx resolve o nome via proxy_pass — tudo dentro da VPC, tudo via Terraform.

O código está no GitHub.

leonanviana / terraform-ecs-fargate-service-discovery

Terraform example: ECS Fargate services communicating via AWS Cloud Map service discovery, with Nginx as reverse proxy — no ALB, no public IPs

terraform-ecs-fargate-service-discovery

Português | English

Português

Exemplo em Terraform demonstrando o uso do AWS Cloud Map Service Discovery com ECS Fargate.

Todos os serviços rodam em subnets privadas, sem IP público. O serviço interno se registra em um namespace DNS privado do Cloud Map (myapp.internal), e o Nginx resolve esse nome via proxy_pass para rotear o tráfego internamente na VPC.

Arquitetura

VPC (privada)
    │
    ▼
 [Nginx - ECS Fargate]  ← subnet privada, sem IP público
    │
    │  proxy_pass via DNS do Cloud Map
    └──► internal-tool.myapp.internal → [Internal Tool - ECS Fargate]

Estrutura

stage/
├── main.tf                    # Providers Terraform, backend
├── vpc.tf                     # Módulo VPC (subnets, NAT Gateway)
├── locals.tf                  # Prefixo e tags comuns
├── variables.tf               # Todas as variáveis de entrada
├── cloudmap.tf                # Namespace Cloud Map + registros de service discovery
├── cluster.tf                 # Cluster ECS
├── cluster-sg.tf              # Security groups e regras
├── service-nginx.tf           #

…

View on GitHub

Arquitetura

VPC (privada)
│
▼
[Nginx — ECS Fargate]        ← subnet privada, sem IP público
│
│  proxy_pass via DNS do Cloud Map
│
└──► internal-tool.myapp.internal → [Internal Tool — ECS Fargate]

O Nginx é a única porta de entrada. O internal-tool nunca expõe IP público — o Cloud Map registra o IP da task automaticamente e o Nginx resolve esse nome sem precisar de configuração adicional a cada deploy.

Estrutura dos arquivos

stage/
├── main.tf                    # Providers, backend, módulo VPC
├── locals.tf                  # Prefixo e tags comuns
├── variables.tf               # Variáveis de entrada
├── cloudmap.tf                # Namespace DNS + service discovery
├── cluster.tf                 # Cluster ECS
├── cluster-sg.tf              # Security groups
├── service-nginx.tf           # ECS service do Nginx
├── task-nginx.tf              # Task definition do Nginx
├── service-internal-tool.tf   # ECS service da ferramenta interna
├── task-internal-tool.tf      # Task definition da ferramenta interna
└── templates/
    ├── nginx-json.tpl
    └── internal-tool-json.tpl

Prefiro um arquivo por recurso. Quando o projeto cresce, você não fica caçando aws_ecs_service enterrado no meio de um main.tf com 400 linhas.

1. Namespace DNS privado com Cloud Map

O cloudmap.tf cria a zona DNS myapp.internal, privada à VPC:

resource "aws_service_discovery_private_dns_namespace" "ecs" {
  name        = "myapp.internal"
  vpc         = module.vpc.vpc_id
  description = "Private DNS namespace for myapp ECS services"
}

Nenhum tráfego sai pra internet. É um DNS interno só pra dentro da VPC.

O registro do serviço define como os IPs das tasks são publicados:

resource "aws_service_discovery_service" "internal_tool" {
  name = "internal-tool"

  dns_config {
    namespace_id = aws_service_discovery_private_dns_namespace.ecs.id

    dns_records {
      ttl  = 10
      type = "A"
    }

    routing_policy = "MULTIVALUE"
  }

  health_check_custom_config {}
}

MULTIVALUE faz o Cloud Map retornar todos os IPs de tasks ativas quando consultado. Com mais de uma task rodando, o Nginx distribui o tráfego entre elas sem configuração extra.

2. Serviço interno com registro no Cloud Map

O service-internal-tool.tf tem dois blocos que fazem o serviço aparecer no DNS:

resource "aws_ecs_service" "internal_tool" {
  name            = "${local.prefix}-internal-tool"
  cluster         = aws_ecs_cluster.main.id
  task_definition = aws_ecs_task_definition.task_internal_tool.id
  launch_type     = "FARGATE"
  desired_count   = var.app_count

  network_configuration {
    security_groups  = [aws_security_group.internal_tool_sg.id]
    subnets          = [module.vpc.private_subnets[1]]
    assign_public_ip = false
  }

  # Service Connect — sidecar proxy do ECS com métricas embutidas
  service_connect_configuration {
    enabled   = true
    namespace = aws_service_discovery_private_dns_namespace.ecs.name
  }

  # Registra o IP da task no Cloud Map
  # Nginx resolve: internal-tool.myapp.internal → IP da task
  service_registries {
    registry_arn   = aws_service_discovery_service.internal_tool.arn
    container_name = "myapp-internal-tool"
  }

  lifecycle {
    ignore_changes = [desired_count]
  }

  force_new_deployment = true
}

O bloco service_registries conecta o ECS ao Cloud Map. Quando uma task sobe, o ECS registra o IP dela no namespace DNS. Quando desce ou é substituída num deploy, o registro atualiza sozinho.

O service_connect_configuration habilita o sidecar proxy do ECS — métricas de latência e erro entre serviços sem instrumentar o código da aplicação.

3. Nginx como proxy reverso

O Nginx resolve internal-tool.myapp.internal via proxy_pass porque está na mesma VPC. Não precisa se registrar no Cloud Map.

resource "aws_ecs_service" "nginx" {
  name            = "${local.prefix}-nginx"
  cluster         = aws_ecs_cluster.main.id
  task_definition = aws_ecs_task_definition.task_nginx.id
  launch_type     = "FARGATE"
  desired_count   = var.app_count

  network_configuration {
    security_groups  = [aws_security_group.nginx_ecs_sg.id]
    subnets          = [module.vpc.private_subnets[0]]
    assign_public_ip = false
  }

  force_new_deployment = true
}

assign_public_ip = false nos dois serviços. Nenhum dos dois é acessível diretamente da internet.

Pré-requisitos

Conta AWS com permissões para ECS, ECR e VPC
Bucket S3 criado — atualize o nome no backend em main.tf
IAM role ecsTaskExecutionRole com as managed policies do ECS

Como usar

cd stage/
terraform init
terraform plan
terraform apply

Cloud Map vs ALB — quando vale a troca

ALB faz sentido quando você precisa expor um serviço publicamente, quer roteamento por path/host, ou precisa de SSL termination gerenciado. Pra tráfego interno entre containers na mesma VPC, você paga pela infraestrutura sem usar a maior parte do que ela oferece.

Cloud Map cobra por instância registrada e por consultas DNS. Em workloads moderados, a diferença de custo é relevante. Você também elimina um hop de rede — a latência entre os serviços cai.

A contrapartida: sem ALB você perde os health checks dele e o SSL termination. Pra comunicação interna isso raramente importa — o Service Connect já traz métricas e os health checks do ECS cuidam das tasks.

Se você usa ECS Fargate com múltiplos serviços internos e ainda não conhecia o Cloud Map, vale testar. O repositório tem tudo pronto pra subir num terraform apply.

Checkov Scan para Terraform com Azure Pipelines

Leonan Viana — Sun, 22 Mar 2026 21:39:09 +0000

Esse post mostra como usar o Checkov para escanear seu IaC Terraform dentro de uma esteira do Azure Pipelines. O objetivo é ter um step dedicado ao scan de segurança antes de qualquer plan ou apply chegar no ambiente.

O que é o Checkov?

Checkov é uma ferramenta de análise estática para infraestrutura como código. Ela verifica configurações de recursos cloud e aponta misconfigurations antes que elas sejam provisionadas. Suporta Terraform, CloudFormation, Kubernetes, Helm, ARM Templates, Serverless e AWS CDK.

Etapa 1 — Criando o template do Checkov

Como vamos usar Azure Pipelines, faz sentido isolar as tasks do Checkov em um template reutilizável. O arquivo fica em:

.azuredevops/templates/terraform-build-checkov.yml

O template usa duas variáveis predefinidas do Azure DevOps para instalar o Checkov no runner de execução:

Predefined variables - Azure Pipelines | Microsoft Learn

A comprehensive list of all available predefined variables

learn.microsoft.com

$(Agent.ToolsDirectory) — diretório de ferramentas do agente
$(Agent.OS) — sistema operacional do agente

parameters:
  - name: CheckovVersion
    type: string
    default: ''
  - name: WorkingDir
    type: string
    default: '.'

steps:

  # Cache do Checkov para evitar reinstalação a cada run
  - task: Cache@2
    displayName: Restore checkov $(CheckovVersion) from cache
    name: checkov_restore_cache
    inputs:
      key: '"checkov $(CheckovVersion)" | $(Agent.OS)'
      path: $(Agent.ToolsDirectory)/checkov
      cacheHitVar: CACHE_RESTORED

  # Instala o Checkov apenas se o cache não existir
  - task: CmdLine@2
    displayName: Install checkov $(CheckovVersion)
    condition: and(succeeded(), ne(variables.CACHE_RESTORED, 'true'))
    inputs:
      targetType: 'inline'
      script: |
        CHECKOV_DIR=${AGENT_TOOLSDIRECTORY}/checkov
        mkdir -p $CHECKOV_DIR
        python3 -m venv $CHECKOV_DIR
        source $CHECKOV_DIR/bin/activate
        pip3 install checkov==${{ parameters.CheckovVersion }}
        echo "##vso[task.prependpath]$CHECKOV_DIR/bin"

  # Adiciona o Checkov ao PATH do agente
  - task: CmdLine@2
    displayName: Add checkov to PATH
    inputs:
      targetType: 'inline'
      script: |
        CHECKOV_DIR=${AGENT_TOOLSDIRECTORY}/checkov
        echo "##vso[task.prependpath]$CHECKOV_DIR/bin"

  # Executa o scan no diretório Terraform informado
  - task: CmdLine@2
    displayName: Run checkov
    inputs:
      targetType: 'inline'
      script: checkov --directory "${{ parameters.WorkingDir }}" --framework terraform

Por que usar cache? O Checkov tem algumas dependências Python que levam tempo para instalar. Com a task Cache@2, a instalação só acontece uma vez por versão — nas runs seguintes o agente restaura direto do cache.

Etapa 2 — Configurando a Pipeline principal

Na raiz do repositório, o azure-pipelines.yaml referencia o template criado acima. A variável $(System.DefaultWorkingDirectory) aponta para o diretório dos arquivos Terraform.

trigger:
  branches:
    include:
      - main
  paths:
    exclude:
      - '**/*.md'

pool:
  vmImage: ubuntu-latest

variables:
  CheckovVersion: '2.3.110'

steps:

  - task: TerraformTaskV4@4
    displayName: Terraform Init
    inputs:
      provider: 'aws'
      command: 'init'
      workingDirectory: '$(System.DefaultWorkingDirectory)/tf'

  - template: .azuredevops/templates/terraform-build-checkov.yaml

O exemplo acima tem apenas o Init e o template do Checkov para manter a demonstração simples. Na prática, você vai querer adicionar Validate, TfLint, Plan e Apply conforme a maturidade da sua esteira.

Etapa 3 — Executando e interpretando o resultado

Ao rodar a pipeline, o log vai mostrar:

Quantos recursos foram verificados
Quantos checks passaram, falharam ou foram pulados (skipped)

Se um check falhar, a pipeline quebra. Esse é o comportamento esperado — a ideia é bloquear o deploy até que a configuração seja corrigida ou explicitamente ignorada.

Como fazer skip de um check específico

Quando um item é avaliado como falso positivo ou está dentro de uma exceção aceitável para o contexto, você pode declarar o skip diretamente no bloco do resource Terraform:

resource "aws_eks_cluster" "cluster-eks" {

  #checkov:skip=CKV_AWS_39: "Ensure Amazon EKS public endpoint disabled"
  #checkov:skip=CKV_AWS_37: "Ensure Amazon EKS control plane logging enabled for all log types"
  #checkov:skip=CKV_AWS_38: "Ensure Amazon EKS public endpoint not accessible to 0.0.0.0/0"
  #checkov:skip=CKV_AWS_58: "Ensure EKS Cluster has Secrets Encryption Enabled"

  # ... restante da configuração

}

O comentário segue o padrão #checkov:skip=<CHECK_ID>: "<justificativa>". A justificativa é opcional mas recomendada para rastreabilidade — especialmente em auditorias.

Conclusão

Com esse template, o scan de segurança vira parte do ciclo normal de desenvolvimento. Qualquer misconfiguration no Terraform é bloqueada antes de chegar no plan, o que reduz bastante o risco de provisionar recursos fora de conformidade.

O Checkov suporta os seguintes frameworks:

Terraform e Terraform Plan
CloudFormation
Kubernetes
ARM Templates
Serverless
Helm
AWS CDK

Adicionando Headers no Nginx com Ansible

Leonan Viana — Mon, 08 Apr 2024 02:25:56 +0000

Como automatizar a inserção de security headers no Nginx usando Ansible — backup, remoção de duplicatas, incremento via AWK e restart em múltiplos hosts de uma vez.

Num projeto recente eu precisava adicionar security headers no Nginx de vários hosts ao mesmo tempo. Fazer isso na mão, host por host, estava fora de questão — qualquer mudança futura viraria uma dor de cabeça. Resolvi automatizar com Ansible, e foi mais simples do que esperava.

O repositório tá disponível no GitHub caso queira já ir direto ao código.

leonanviana / add-headers-nginx

add-headers-nginx

🇧🇷 Português | 🇺🇸 English

Português

Playbooks Ansible para adição e remoção de security headers no Nginx de forma automatizada e idempotente.

Por que security headers?

Security headers protegem aplicações web contra ataques como XSS, clickjacking e MIME sniffing. São exigidos em auditorias de segurança e compliance (OWASP, PCI-DSS).

Estrutura

add-headers-nginx/
├── nginx.conf                      # Exemplo de configuração Nginx
└── playbooks/
    ├── headers_nginx.txt           # Headers a serem inseridos
    ├── add_headers_nginx.yml       # Playbook para adicionar headers
    └── remove_headers_nginx.yml    # Playbook para remover headers

Pré-requisitos

Ansible instalado
Acesso sudo ao host alvo
Nginx instalado

Como usar

1. Configure os paths no playbook conforme seu ambiente:

vars:
  PATH_ADD_HEADERS_TXT: /seu/path/playbooks/headers_nginx.txt
  PATH_NGINX_CONF: /etc/nginx/nginx.conf

2. Adicionar headers:

ansible-playbook playbooks/add_headers_nginx.yml

3. Remover headers:

ansible-playbook playbooks/remove_headers_nginx.yml

O que o playbook faz

Faz backup do nginx.conf (duas cópias de segurança)
Remove headers existentes para evitar duplicação
Injeta os novos headers após a diretiva gzip_vary on
Mantém…

View on GitHub

O problema

A aplicação web precisava de uma lista de headers específicos para não quebrar em certas páginas:

Strict-Transport-Security
Content-Security-Policy
X-XSS-Protection
X-Frame-Options
X-Content-Type-Options
Referrer-Policy
Permissions-Policy

Com muitos hosts e a possibilidade de ajustes frequentes nos valores, qualquer processo manual ia escalar mal. Ansible resolve isso.

Etapa 1 — arquivo de headers

Crio um arquivo headers_nginx.txt com todas as diretivas add_header que quero inserir:

add_header Strict-Transport-Security 'max-age=63072000; includeSubDomains; preload';
add_header Content-Security-Policy "connect-src 'self' www.google-analytics.com ...";
add_header X-XSS-Protection "1; mode=block";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
add_header Referrer-Policy "strict-origin";
add_header Permissions-Policy "geolocation=(self),midi=(self),...";

Esse arquivo é a fonte da verdade. Quando precisar mudar um header, edito aqui e rodo a playbook de novo — sem tocar no nginx.conf manualmente.

Etapa 2 — a Playbook

A playbook tem seis jobs em sequência:

Backup do nginx.conf — duas formas, pelo fetch e pelo cp
Remoção das linhas add_header existentes — evita duplicidade
Remoção das linhas add_header comentadas com #
Limpeza de linhas em branco que ficam após a remoção
Inserção dos novos headers via AWK
Restart do Nginx

- name: Adicionar Headers no Nginx
  hosts: localhost
  become: yes
  become_method: sudo

  vars:
    PATH_ADD_HEADERS_TXT: /Users/leonanviana/Repos/add_headers_nginx/playbooks/headers_nginx.txt
    PATH_NGINX_CONF: /opt/homebrew/etc/nginx/nginx.conf

  tasks:

    - name: Fazer backup do nginx.conf via fetch
      fetch:
        src: /opt/homebrew/etc/nginx/nginx.conf
        dest: /var/tmp/
        flat: yes
      become: true

    - name: Fazer backup do nginx.conf via cp
      shell: cp "{{ PATH_NGINX_CONF }}" /var/tmp/default_nginx_bkp

    - name: Remover linhas com add_header
      lineinfile:
        path: "{{ PATH_NGINX_CONF }}"
        state: absent
        regexp: '^(\s*add_header\s.*;)$'

    - name: Remover linhas add_header comentadas com #
      lineinfile:
        path: "{{ PATH_NGINX_CONF }}"
        state: absent
        regexp: '^(\s*#add_header\s.*;)$'

    - name: Remover linhas em branco
      replace:
        path: "{{ PATH_NGINX_CONF }}"
        regexp: '^\s*$'
        replace: ''

    - name: Inserir headers via AWK
      shell: >
        awk '/gzip_vary on;/ {print; system("cat \"{{ PATH_ADD_HEADERS_TXT }}\""); next} 1'
        "{{ PATH_NGINX_CONF }}" > tmpfile && mv tmpfile "{{ PATH_NGINX_CONF }}"

    - name: Restart Nginx
      service:
        name: nginx
        state: restarted

Como o AWK funciona aqui

O job de inserção merece atenção. Ele usa awk para localizar a string gzip_vary on; dentro do nginx.conf como ponto de ancoragem. Quando encontra essa linha, imprime ela e logo em seguida injeta todo o conteúdo do headers_nginx.txt. O resultado vai para um arquivo temporário, que substitui o original se tudo correr bem.

Você pode trocar gzip_vary on; por qualquer outra string que já exista no seu nginx.conf — o comportamento é o mesmo.

Fluxo de execução

Com tudo configurado, o fluxo fica assim:

nginx.conf sem nenhum add_header
Playbook roda — backup, limpeza, inserção, restart
nginx.conf com todos os headers no lugar certo

Se precisar remover os headers depois, criei uma segunda playbook específica para isso — sem precisar editar o arquivo na mão.

Conclusão

Parece simples porque é. O ganho real aparece quando você tem dezenas de hosts: um único ansible-playbook propaga a mudança em todos ao mesmo tempo, com backup automático e sem risco de duplicidade.

O código tá no GitHub — pull requests são bem-vindos.