Fundamentação Teórica: Manage Sizing and Scaling for Containers, Including Azure Container Instances and Azure Container Apps

1. Intuição Inicial

Imagine que você tem um restaurante. Cada prato que você serve é preparado em uma cozinha isolada e completamente equipada. Quando chega um cliente, você abre uma cozinha, prepara o prato e fecha a cozinha. Quando chegam 100 clientes ao mesmo tempo, você abre 100 cozinhas em paralelo.

Containers funcionam assim: são ambientes isolados e completos que empacotam uma aplicação com tudo que ela precisa para rodar. O que muda entre os serviços do Azure é quem gerencia essas cozinhas e com que nível de controle você opera.

Sizing é decidir o tamanho de cada cozinha: quanta CPU e memória cada container precisa para funcionar adequadamente.

Scaling é decidir quantas cozinhas operar simultaneamente: uma quando há pouca demanda, cem quando há pico.

No Azure, dois serviços se destacam para este objetivo:

Azure Container Instances (ACI): você faz o pedido de um container e o Azure entrega em segundos. Controle total sobre o sizing, sem scaling automático. Ideal para tarefas pontuais.
Azure Container Apps (ACA): uma plataforma gerenciada que cuida do scaling automático com base em métricas, eventos ou simplesmente na demanda de tráfego. Ideal para aplicações de longa duração.

2. Contexto

Onde esses serviços se encaixam no ecossistema de containers do Azure

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

A escolha entre esses serviços depende principalmente de três fatores: nível de controle desejado, capacidade de escalar automaticamente e complexidade operacional aceitável.

Por que sizing e scaling importam

Sizing inadequado desperdiça dinheiro (superprovisionado) ou causa falhas (subprovisionado). Um container com 0.5 vCPU tentando processar requisições intensivas será lento ou vai falhar. Um container com 4 vCPUs para uma tarefa simples de leitura gera custo desnecessário.

Scaling inadequado significa ficar sem capacidade no pico (usuários recebem erros) ou pagar por capacidade ociosa no vale (custo desnecessário). O objetivo do scaling é manter o equilíbrio entre performance e custo ao longo do tempo.

3. Construção dos Conceitos

3.1 Azure Container Instances (ACI)

O ACI é o serviço mais simples de containers no Azure. Você especifica uma imagem de container e os recursos necessários, e o Azure executa o container diretamente, sem precisar gerenciar VMs, clusters ou orquestradores.

Container Groups

A unidade fundamental do ACI é o Container Group: um conjunto de containers que são agendados no mesmo host, compartilham o mesmo ciclo de vida, rede local e storage.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

O sizing no ACI é definido por container dentro do grupo. O Container Group aloca a soma de todos os recursos dos containers que contém.

Sizing no ACI: limites e configurações

Os recursos são configurados individualmente por container:

Recurso	Mínimo	Máximo (Linux)	Máximo (Windows)
vCPU	0.1	4	4
Memória (GB)	0.1	16	14
GPU	Opcional	4 K80 / 2 V100	Não suportado

Regras de sizing no ACI:

CPU deve ser um número com até uma casa decimal (0.1, 0.5, 1.0, 2.5, 4.0)
Memória deve ser um múltiplo de 0.1 GB
A combinação de CPU e memória deve seguir a proporção máxima de 1:4 (1 vCPU para até 4 GB de memória)

Tipos de restart policy no ACI

O ACI tem três comportamentos de restart que afetam como o sizing é cobrado:

Policy	Comportamento	Caso de uso
Always	Reinicia automaticamente se o container parar	Serviços de longa duração
Never	Executa uma vez e não reinicia	Jobs únicos, scripts de inicialização
OnFailure	Reinicia apenas se terminar com erro	Processamento em lote com retry

3.2 Azure Container Apps (ACA)

O ACA é uma plataforma serverless para containers que abstrai a infraestrutura subjacente (baseada em Kubernetes e KEDA por baixo) e oferece scaling automático sofisticado.

Hierarquia do ACA

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Container Apps Environment é o contêiner lógico que agrupa múltiplas Container Apps. Recursos como a VNet, Log Analytics Workspace e configurações de DAPR são compartilhados no nível do Environment.

Container App é a unidade de deploy: uma aplicação composta por uma ou mais revisões (versões imutáveis do deployment).

Replica é uma instância em execução de uma Container App. O scaling aumenta ou reduz o número de replicas.

Sizing no ACA: CPU e Memória

No ACA, o sizing é definido por Container App e segue combinações predefinidas:

vCPU	Memória disponível
0.25	0.5 Gi
0.5	1.0 Gi
0.75	1.5 Gi
1.0	2.0 Gi
1.25	2.5 Gi
1.5	3.0 Gi
1.75	3.5 Gi
2.0	4.0 Gi

A proporção é sempre 1 vCPU para 2 Gi de memória. Você não pode combinar livremente como no ACI.

Scaling no ACA: os quatro tipos de gatilho

O ACA oferece quatro mecanismos de scaling, todos configuráveis sem código:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

HTTP Scaling: escala baseado no número de requisições HTTP concorrentes por replica. É o gatilho mais simples e mais usado para APIs e web apps. Quando concurrentRequests ultrapassa o threshold por replica, o ACA adiciona mais replicas.

CPU/Memory Scaling: escala baseado na utilização de recursos. Útil para workloads de processamento intensivo onde a carga se manifesta como uso de CPU ou memória.

Event-Driven Scaling (KEDA): escala baseado em métricas externas. Por exemplo, quando uma fila do Service Bus tem mais de 100 mensagens pendentes, scale-out para processar mais rápido. Quando a fila está vazia, scale-in até zero replicas.

Scale-to-Zero

O ACA suporta scale-to-zero: quando não há demanda, o número de replicas pode ser reduzido a zero, eliminando completamente o custo de computação. A primeira requisição após zero replicas tem uma pequena latência de cold start.

Exceção: se uma Container App recebe tráfego HTTP externo via ingress, o ACA mantém pelo menos 1 replica (para evitar cold start percebido pelo usuário final). Scale-to-zero para HTTP só funciona com ingress interno ou sem ingress.

4. Visão Estrutural

Comparação arquitetural: ACI vs. ACA

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Fluxo de decisão de scaling no ACA

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

5. Funcionamento na Prática

Ciclo de vida de um Container Instance (ACI)

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Ciclo de vida de uma Revisão no ACA

O ACA usa o conceito de revisões (revisions): cada deploy gera uma nova revisão imutável. O scaling aplica-se a uma revisão específica.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Comportamentos não óbvios

No ACI, redimensionar recursos requer recriar o container. Não é possível alterar CPU ou memória de um container ACI em execução. Você precisa parar, deletar e recriar com os novos valores. Planeje o sizing adequado antes do deploy em produção.

No ACA, o scaling tem período de estabilização (cooldown). Para evitar flapping (scale-out e scale-in repetidos em curtos períodos), o ACA tem períodos de estabilização: por padrão, espera 120 segundos antes de fazer scale-in. Isso significa que após uma queda de carga, as replicas extras ficam por até 2 minutos antes de serem removidas.

ACA cobra por vCPU e memória consumidos, não pelo número de replicas declaradas. Se você declara maxReplicas: 10 mas há apenas 2 replicas ativas, você paga por 2 replicas. O custo é proporcional ao uso real, não ao máximo configurado.

Container Groups do ACI em VNet não têm IP público disponível. Quando você deploy um Container Group em uma VNet (com delegação de subnet), ele perde o IP público. O acesso externo deve ser feito via Load Balancer ou Application Gateway na mesma VNet.

Scale-to-zero no ACA tem cold start, mas é configurável. O cold start típico é de 2 a 10 segundos dependendo do tamanho da imagem e do tempo de inicialização da aplicação. Para minimizá-lo, use imagens pequenas (alpine-based) e minimize o tempo de inicialização da aplicação.

6. Formas de Implementação

Portal do Azure

ACI pelo portal:

Portal > Container Instances > + Create
Selecionar subscription, RG, nome, região, OS (Linux/Windows)
Selecionar imagem (Docker Hub, ACR, ou outra registry)
Configurar: CPU cores e Memory (GB)
Configurar networking: public IP, DNS label, ports
Configurar restart policy e variáveis de ambiente
Review + Create

ACA pelo portal:

Portal > Container Apps > + Create
Criar ou selecionar Container Apps Environment
Configurar Container App: nome, imagem, CPU e memória
Configurar Ingress (HTTP/HTTPS, externo/interno)
Configurar Scale: minReplicas, maxReplicas
Adicionar regras de scaling (HTTP, CPU, event)
Review + Create

Azure CLI

# ACI: Criar Container Instance com sizing específico
az container create \
  --resource-group "rg-containers" \
  --name "aci-processador" \
  --image "myregistry.azurecr.io/processador:v1.0" \
  --cpu 2 \
  --memory 4 \
  --restart-policy OnFailure \
  --environment-variables BATCH_SIZE=100 \
  --registry-login-server "myregistry.azurecr.io" \
  --registry-username "<username>" \
  --registry-password "<password>" \
  --location "brazilsouth"

# ACI: Criar Container Group com múltiplos containers (via YAML)
cat > container-group.yaml << EOF
apiVersion: 2021-10-01
name: container-group-prod
type: Microsoft.ContainerInstance/containerGroups
location: brazilsouth
properties:
  containers:
  - name: app-web
    properties:
      image: myregistry.azurecr.io/webapp:v1.0
      resources:
        requests:
          cpu: 1.0
          memoryInGb: 2.0
      ports:
      - port: 8080
  - name: sidecar-logger
    properties:
      image: myregistry.azurecr.io/logger:v1.0
      resources:
        requests:
          cpu: 0.5
          memoryInGb: 0.5
  osType: Linux
  restartPolicy: Always
  ipAddress:
    type: Public
    ports:
    - protocol: tcp
      port: 8080
EOF

az container create \
  --resource-group "rg-containers" \
  --file container-group.yaml

# ACI: Ver estado atual e uso de recursos
az container show \
  --resource-group "rg-containers" \
  --name "aci-processador" \
  --query "{State: instanceView.state, CPU: containers[0].resources.requests.cpu, Memory: containers[0].resources.requests.memoryInGb}" \
  --output json

# ACI: Ver logs do container
az container logs \
  --resource-group "rg-containers" \
  --name "aci-processador"

# ACI: Deletar (necessário para resize)
az container delete \
  --resource-group "rg-containers" \
  --name "aci-processador" \
  --yes

# ACA: Criar Environment
az containerapp env create \
  --name "env-producao" \
  --resource-group "rg-containers" \
  --location "brazilsouth" \
  --logs-workspace-id "<log-analytics-workspace-id>" \
  --logs-workspace-key "<workspace-key>"

# ACA: Criar Container App com scaling por HTTP
az containerapp create \
  --name "api-gateway" \
  --resource-group "rg-containers" \
  --environment "env-producao" \
  --image "myregistry.azurecr.io/api-gateway:v1.0" \
  --cpu 0.5 \
  --memory 1.0Gi \
  --min-replicas 1 \
  --max-replicas 10 \
  --ingress external \
  --target-port 8080 \
  --registry-server "myregistry.azurecr.io" \
  --registry-username "<username>" \
  --registry-password "<password>"

# ACA: Adicionar regra de scaling por HTTP
az containerapp update \
  --name "api-gateway" \
  --resource-group "rg-containers" \
  --scale-rule-name "http-scaling" \
  --scale-rule-type "http" \
  --scale-rule-http-concurrency 50

# ACA: Criar Container App com scale-to-zero (processador de fila)
az containerapp create \
  --name "queue-processor" \
  --resource-group "rg-containers" \
  --environment "env-producao" \
  --image "myregistry.azurecr.io/queue-processor:v1.0" \
  --cpu 1.0 \
  --memory 2.0Gi \
  --min-replicas 0 \
  --max-replicas 20

# ACA: Adicionar regra de scaling por Azure Service Bus Queue
az containerapp update \
  --name "queue-processor" \
  --resource-group "rg-containers" \
  --scale-rule-name "servicebus-scaling" \
  --scale-rule-type "azure-servicebus" \
  --scale-rule-metadata "queueName=fila-trabalho" "namespace=mynamespace" "messageCount=10" \
  --scale-rule-auth "connection=servicebus-connection-secret"

# ACA: Atualizar sizing (CPU e memória)
az containerapp update \
  --name "api-gateway" \
  --resource-group "rg-containers" \
  --cpu 1.0 \
  --memory 2.0Gi

# ACA: Atualizar min/max replicas
az containerapp update \
  --name "api-gateway" \
  --resource-group "rg-containers" \
  --min-replicas 2 \
  --max-replicas 15

# ACA: Ver número atual de replicas
az containerapp replica list \
  --name "api-gateway" \
  --resource-group "rg-containers" \
  --output table

# ACA: Ver revisões e qual está ativa
az containerapp revision list \
  --name "api-gateway" \
  --resource-group "rg-containers" \
  --output table

Bicep

// ACI: Container Instance com sizing
resource containerInstance 'Microsoft.ContainerInstance/containerGroups@2021-10-01' = {
  name: 'aci-processador'
  location: 'brazilsouth'
  properties: {
    containers: [
      {
        name: 'processador'
        properties: {
          image: 'myregistry.azurecr.io/processador:v1.0'
          resources: {
            requests: {
              cpu: 2
              memoryInGB: 4
            }
          }
          environmentVariables: [
            { name: 'BATCH_SIZE', value: '100' }
          ]
        }
      }
    ]
    osType: 'Linux'
    restartPolicy: 'OnFailure'
    ipAddress: {
      type: 'Public'
      ports: []
    }
  }
}

// ACA Environment
resource environment 'Microsoft.App/managedEnvironments@2023-05-01' = {
  name: 'env-producao'
  location: 'brazilsouth'
  properties: {
    appLogsConfiguration: {
      destination: 'log-analytics'
      logAnalyticsConfiguration: {
        customerId: logAnalyticsWorkspaceId
        sharedKey: logAnalyticsKey
      }
    }
  }
}

// ACA: Container App com scaling por HTTP e por CPU
resource containerApp 'Microsoft.App/containerApps@2023-05-01' = {
  name: 'api-gateway'
  location: 'brazilsouth'
  properties: {
    managedEnvironmentId: environment.id
    configuration: {
      ingress: {
        external: true
        targetPort: 8080
        transport: 'http'
      }
      registries: [
        {
          server: 'myregistry.azurecr.io'
          username: registryUsername
          passwordSecretRef: 'registry-password'
        }
      ]
    }
    template: {
      containers: [
        {
          name: 'api-gateway'
          image: 'myregistry.azurecr.io/api-gateway:v1.0'
          resources: {
            cpu: json('0.5')
            memory: '1.0Gi'
          }
          env: [
            { name: 'ENVIRONMENT', value: 'production' }
          ]
        }
      ]
      scale: {
        minReplicas: 1
        maxReplicas: 10
        rules: [
          {
            name: 'http-scaling'
            http: {
              metadata: {
                concurrentRequests: '50'
              }
            }
          }
          {
            name: 'cpu-scaling'
            custom: {
              type: 'cpu'
              metadata: {
                type: 'Utilization'
                value: '70'
              }
            }
          }
        ]
      }
    }
  }
}

7. Controle e Segurança

Isolamento de recursos entre Container Apps

No ACA, containers dentro do mesmo Environment compartilham a rede interna e podem se comunicar via nome do serviço. Para isolar Container Apps em diferentes ambientes:

Use Environments separados para isolamento de rede completo
Use VNet integration para que o Environment seja injetado numa VNet existente
Configure Ingress interno para Container Apps que não devem ser acessíveis externamente

Managed Identity para pull de imagens

# Atribuir Managed Identity ao Container App
az containerapp identity assign \
  --name "api-gateway" \
  --resource-group "rg-containers" \
  --system-assigned

# Dar permissão de pull no ACR
PRINCIPAL_ID=$(az containerapp show \
  --name "api-gateway" \
  --resource-group "rg-containers" \
  --query "identity.principalId" -o tsv)

az role assignment create \
  --assignee "$PRINCIPAL_ID" \
  --role "AcrPull" \
  --scope "/subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.ContainerRegistry/registries/myregistry"

# Atualizar Container App para usar Managed Identity para o registry
az containerapp registry set \
  --name "api-gateway" \
  --resource-group "rg-containers" \
  --server "myregistry.azurecr.io" \
  --identity system

Secrets no ACA

Credenciais e configurações sensíveis devem ser gerenciadas como secrets, não variáveis de ambiente em texto claro:

# Criar secret no Container App
az containerapp secret set \
  --name "api-gateway" \
  --resource-group "rg-containers" \
  --secrets "db-password=<senha-banco>"

# Referenciar secret em variável de ambiente
az containerapp update \
  --name "api-gateway" \
  --resource-group "rg-containers" \
  --set-env-vars "DB_PASSWORD=secretref:db-password"

8. Tomada de Decisão

ACI vs. ACA

Situação	Escolha	Motivo
Job de processamento que roda 10 minutos por dia	ACI com restart policy Never	Serverless por execução, sem overhead de gerenciamento
API que precisa escalar de 0 a 100 instâncias com tráfego	ACA com HTTP scaling	Scaling automático gerenciado, scale-to-zero possível
Processamento de fila que cresce com mensagens	ACA com KEDA event scaling	Scala exatamente proporcionalmente ao backlog
Tarefa de CI/CD que consome imagem e roda testes	ACI	Simples, rápido para tasks pontuais
Aplicação web de produção com SLA de disponibilidade	ACA com minReplicas >= 1	Garante que sempre há pelo menos uma replica ativa
Workload que nunca pode ter cold start	ACA com minReplicas >= 1	Scale-to-zero introduz latência na primeira requisição
Container com GPU para machine learning	ACI	ACA não suporta GPU; ACI suporta
Múltiplos containers com comunicação na mesma máquina	ACI Container Group	Rede localhost compartilhada, sidecar pattern

Sizing: como definir CPU e memória

Tipo de workload	CPU recomendada	Memória recomendada
API REST simples, I/O bound	0.25-0.5 vCPU	0.5-1.0 Gi
API com processamento leve	0.5-1.0 vCPU	1.0-2.0 Gi
Processamento de dados / compute-intensive	1.0-2.0 vCPU	2.0-4.0 Gi
Machine Learning inference	2.0-4.0 vCPU	4.0-8.0 Gi
Job de transformação de dados em lote	1.0-4.0 vCPU	2.0-8.0 Gi

Configuração de scaling no ACA

Requisito	Configuração
Nunca pode ficar offline	minReplicas: 1 ou mais
Pode ter cold start aceitável	minReplicas: 0 (scale-to-zero)
Tráfego variável mas previsível	HTTP scaling com concurrentRequests ajustado
Processamento assíncrono de fila	KEDA event scaling com messageCount threshold
Baseline garantido + scaling adicional	minReplicas: 2, maxReplicas: 20

9. Boas Práticas

Defina limites de recursos baseado em testes de carga reais, não em estimativas. O sizing correto requer profiling: execute sua aplicação com carga representativa e meça uso de CPU e memória. Um container dimensionado por intuição geralmente resulta em superprovisionamento (custo extra) ou subprovisionamento (falhas).

No ACA, comece com minReplicas: 1 para produção. Scale-to-zero economiza dinheiro mas adiciona latência de cold start. Para APIs públicas, a experiência do primeiro usuário após um período de inatividade será degradada. Avalie o trade-off entre custo e experiência do usuário.

Use revisões do ACA para deploys seguros. O ACA suporta divisão de tráfego entre revisões (ex: 90% na revisão atual, 10% na nova). Isso permite blue/green deployments ou canary releases sem infraestrutura adicional.

# Configurar divisão de tráfego entre revisões
az containerapp ingress traffic set \
  --name "api-gateway" \
  --resource-group "rg-containers" \
  --revision-weight "api-gateway--revision1=90" "api-gateway--revision2=10"

Configure limites de memória conservadores para detectar memory leaks. Se um container constantemente usa 90%+ da memória configurada, ou é necessário aumentar o sizing, ou há um memory leak que precisa ser investigado. Monitore o uso de memória ao longo do tempo.

Para ACI em produção, use container groups com VNet integration. ACI com IP público direto é adequado para testes. Em produção, integre à VNet para controle de acesso de rede e use Private DNS.

No ACA, defina maxReplicas com base na capacidade do backend. Se sua Container App depende de um banco de dados com 100 conexões máximas, não configure maxReplicas acima do número de conexões que sua aplicação usa por instância. 50 replicas com 3 conexões cada = 150 conexões, estourando o banco.

10. Erros Comuns

Erro	Por que acontece	Como evitar
ACI com sizing insuficiente falhando	Estimar CPU/memória sem testes	Testar com carga antes de prod; monitorar métricas na primeira semana
ACA escalando para maxReplicas e saturando banco	Não considerar limites de downstream	Definir maxReplicas com base nos limites de dependências
Container ACI não iniciando por OOMKilled	Memória configurada insuficiente	Monitorar logs; aumentar memória se OOMKilled frequente
Scale-to-zero causando timeouts em usuários	Cold start inesperado em prod	Usar minReplicas: 1 para endpoints públicos sensíveis
ACI sendo usado onde ACA seria melhor	Falta de conhecimento sobre ACA	ACI para jobs; ACA para serviços de longa duração com scaling
Regra de scaling muito agressiva causando flapping	Threshold muito baixo para scale-in	Aumentar threshold de scale-in ou usar período de estabilização maior
CPU 100% mas scaling não ocorre	Threshold de scaling em CPU definido acima do uso	Revisar configuração; CPU scaling precisa de threshold < uso atual
Custo inesperadamente alto no ACA	maxReplicas muito alto atingido em pico	Monitorar número de replicas; ajustar maxReplicas baseado em testes de carga

11. Operação e Manutenção

Monitorar ACI

# Ver estado e eventos de um Container Instance
az container show \
  --resource-group "rg-containers" \
  --name "aci-processador" \
  --query "{State: instanceView.state, Events: instanceView.events}" \
  --output json

# Stream de logs em tempo real
az container attach \
  --resource-group "rg-containers" \
  --name "aci-processador"

# Executar comando dentro do container (debug)
az container exec \
  --resource-group "rg-containers" \
  --name "aci-processador" \
  --exec-command "/bin/bash"

Monitorar ACA

# Ver replicas ativas agora
az containerapp replica list \
  --name "api-gateway" \
  --resource-group "rg-containers" \
  --output table

# Ver histórico de revisões
az containerapp revision list \
  --name "api-gateway" \
  --resource-group "rg-containers" \
  --output table

# Ver logs de uma Container App (via Log Analytics)
az monitor log-analytics query \
  --workspace "<workspace-id>" \
  --analytics-query "
ContainerAppConsoleLogs_CL
| where ContainerAppName_s == 'api-gateway'
| where TimeGenerated > ago(1h)
| project TimeGenerated, Log_s
| order by TimeGenerated desc
| limit 50"

# Ver métricas de CPU e memória
az monitor metrics list \
  --resource "/subscriptions/<sub-id>/resourceGroups/rg-containers/providers/Microsoft.App/containerApps/api-gateway" \
  --metric "CpuPercentage" \
  --interval PT5M \
  --output table

Limites importantes

Serviço	Limite	Valor
ACI	vCPU por container	4
ACI	Memória por container (Linux)	16 GB
ACI	Containers por Container Group	60
ACI	Container Groups por região	100 (padrão, aumentável)
ACA	vCPU por container	2.0
ACA	Memória por container	4.0 Gi
ACA	maxReplicas por Container App	300
ACA	Container Apps por Environment	20 (padrão)
ACA	Revisões por Container App	100

12. Integração e Automação

ACI como executor de jobs em pipelines

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

ACA com KEDA para processamento orientado a eventos

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Terraform para gestão de ACA em escala

resource "azurerm_container_app_environment" "prod" {
  name                       = "env-producao"
  location                   = "brazilsouth"
  resource_group_name        = azurerm_resource_group.main.name
  log_analytics_workspace_id = azurerm_log_analytics_workspace.main.id
}

resource "azurerm_container_app" "api" {
  name                         = "api-gateway"
  container_app_environment_id = azurerm_container_app_environment.prod.id
  resource_group_name          = azurerm_resource_group.main.name
  revision_mode                = "Single"

  template {
    container {
      name   = "api-gateway"
      image  = "myregistry.azurecr.io/api-gateway:v1.0"
      cpu    = 0.5
      memory = "1Gi"
    }

    min_replicas = 1
    max_replicas = 10

    http_scale_rule {
      name                = "http-scaling"
      concurrent_requests = 50
    }
  }

  ingress {
    external_enabled = true
    target_port      = 8080
    traffic_weight {
      percentage      = 100
      latest_revision = true
    }
  }
}

13. Resumo Final

Pontos essenciais:

Azure Container Instances (ACI): serviço simples para executar containers sob demanda; sizing definido na criação (CPU e memória por container); sem scaling automático; ideal para jobs, tarefas pontuais e workloads sem orquestração
Azure Container Apps (ACA): plataforma gerenciada com scaling automático via HTTP, CPU, memória ou eventos externos (KEDA); suporta scale-to-zero; ideal para serviços de longa duração, APIs e processamento orientado a eventos
Sizing no ACI é livre dentro dos limites (0.1 a 4 vCPU, 0.1 a 16 GB); sizing no ACA segue proporções predefinidas (1 vCPU = 2 Gi de memória)
Scale-to-zero no ACA elimina custo quando não há demanda, mas introduz latência de cold start; evite para endpoints com SLA de disponibilidade alta usando minReplicas >= 1
Redimensionar ACI requer deletar e recriar o container; redimensionar ACA é feito via update que gera nova revisão automaticamente

Diferenças críticas:

ACI vs. ACA: ACI é para execuções pontuais sem gerenciamento; ACA é para serviços contínuos com scaling automático
Container Group (ACI) vs. Container App (ACA): Container Group é um conjunto de containers no mesmo host; Container App é uma unidade de deploy que pode ter N replicas idênticas
Scaling HTTP vs. KEDA Event: HTTP scaling responde a requisições concorrentes; KEDA event scaling responde a métricas de sistemas externos como filas e tópicos

O que precisa ser lembrado para o AZ-104:

ACI cobra por vCPU e memória por segundo de execução
ACA cobra por vCPU e memória por replica ativa (scale-to-zero = custo zero)
No ACI, a proporção máxima é 1 vCPU : 4 GB de memória
No ACA, a proporção é sempre 1 vCPU : 2 Gi de memória (fixo)
O limite de maxReplicas no ACA é 300 por Container App
ACI suporta GPU; ACA não suporta GPU
Restart policies do ACI: Always, Never, OnFailure
O scaling do ACA é gerenciado pelo KEDA (Kubernetes Event-Driven Autoscaling) internamente

1. Intuição Inicial​

2. Contexto​

Onde esses serviços se encaixam no ecossistema de containers do Azure​

Por que sizing e scaling importam​

3. Construção dos Conceitos​

3.1 Azure Container Instances (ACI)​

Container Groups​

Sizing no ACI: limites e configurações​

Tipos de restart policy no ACI​

3.2 Azure Container Apps (ACA)​

Hierarquia do ACA​

Sizing no ACA: CPU e Memória​

Scaling no ACA: os quatro tipos de gatilho​

Scale-to-Zero​

4. Visão Estrutural​

Comparação arquitetural: ACI vs. ACA​

Fluxo de decisão de scaling no ACA​

5. Funcionamento na Prática​

Ciclo de vida de um Container Instance (ACI)​

Ciclo de vida de uma Revisão no ACA​

Comportamentos não óbvios​

6. Formas de Implementação​

Portal do Azure​

Azure CLI​

Bicep​

7. Controle e Segurança​

Isolamento de recursos entre Container Apps​

Managed Identity para pull de imagens​

Secrets no ACA​

8. Tomada de Decisão​

ACI vs. ACA​

Sizing: como definir CPU e memória​

Configuração de scaling no ACA​

9. Boas Práticas​

10. Erros Comuns​

11. Operação e Manutenção​

Monitorar ACI​

Monitorar ACA​

Limites importantes​

12. Integração e Automação​

ACI como executor de jobs em pipelines​

ACA com KEDA para processamento orientado a eventos​

Terraform para gestão de ACA em escala​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

Onde esses serviços se encaixam no ecossistema de containers do Azure

Por que sizing e scaling importam

3. Construção dos Conceitos

3.1 Azure Container Instances (ACI)

Container Groups

Sizing no ACI: limites e configurações

Tipos de restart policy no ACI

3.2 Azure Container Apps (ACA)

Hierarquia do ACA

Sizing no ACA: CPU e Memória

Scaling no ACA: os quatro tipos de gatilho

Scale-to-Zero

4. Visão Estrutural

Comparação arquitetural: ACI vs. ACA

Fluxo de decisão de scaling no ACA

5. Funcionamento na Prática

Ciclo de vida de um Container Instance (ACI)

Ciclo de vida de uma Revisão no ACA

Comportamentos não óbvios

6. Formas de Implementação

Portal do Azure

Azure CLI

Bicep

7. Controle e Segurança

Isolamento de recursos entre Container Apps

Managed Identity para pull de imagens

Secrets no ACA

8. Tomada de Decisão

ACI vs. ACA

Sizing: como definir CPU e memória

Configuração de scaling no ACA

9. Boas Práticas

10. Erros Comuns

11. Operação e Manutenção

Monitorar ACI

Monitorar ACA

Limites importantes

12. Integração e Automação

ACI como executor de jobs em pipelines

ACA com KEDA para processamento orientado a eventos

Terraform para gestão de ACA em escala

13. Resumo Final