Airflow na AWS: MWAA ou no EKS?-Como escolher a solução ideal

Nos últimos anos a orquestração de workflows se tornou um dos pilares das arquiteturas de dados modernas. O Apache Airflow, com sua sintaxe declarativa em Python e o rico ecossistema de operadores, continua sendo a escolha preferida para construir, agendar e monitorar pipelines complexas.

Com a migração massiva para a nuvem, a AWS oferece algumas formas distintas para rodar o Airflow:

MWAA (Managed Workflows for Apache Airflow) – um serviço totalmente gerenciado que cuida da infraestrutura, backups, alta disponibilidade e integração nativa com outros recursos da AWS.
Airflow auto‑hospedado no EKS – a liberdade de implantar o Airflow em um cluster Kubernetes, definindo exatamente quem controla o executor, os recursos de hardware, as versões de bibliotecas e as estratégias de monitoramento.

Mas qual dessas abordagens entrega o melhor custo‑benefício, a flexibilidade necessária e a tranquilidade operacional que sua equipe precisa? Neste post vamos fazer uma análise técnica detalhada, comparando custos, benefícios, limitações e estratégias de monitoramento de ambas as opções. Ao final, você terá um roteiro claro para decidir qual caminho seguir ao construir a próxima camada de orquestração de dados na AWS.

Visão geral

Item	AWS  MWAA – Managed Airflow	Airflow rodando no EKS
Tipo de serviço	SaaS/gerenciado – a AWS cria e gerencia a infraestrutura (scheduler, web‑server, workers, metadatabase, storage).	Self‑hosted – você provisiona todo o stack (K8s, pods, PVCs, banco de metadados, workers) dentro de um cluster EKS.
Responsabilidade operacional	AWS cuida de patches, upgrades de versão, alta disponibilidade, backups de metadatabase, escalonamento de workers.	Você (ou seu time) é responsável por instalação, upgrade, backup, HA, scaling, monitoramento, segurança de componentes.
Escalabilidade	Auto‑scale de workers via worker‑queue (SQS) e scheduler configuráveis. Limite de 10 000 tasks/segundo por ambiente (pode ser ajustado).	Escala via HorizontalPodAutoscaler (HPA) ou Cluster Autoscaler; pode usar múltiplas pools de nodes, GPU, spot, etc.
Atualizações de versão	Upgrade de versão via console/CLI (downtime mínimo, migração automática de DB).	Você controla a versão (docker image) e o momento da atualização – porém tem que validar compatibilidade de DB, plugins, etc.
Integração nativa AWS	Conexões predefinidas para S3, Redshift, RDS, DynamoDB, EMR, Glue, Athena, Secrets Manager, SSM, KMS, CloudWatch, EventBridge.	Integração via SDK/CLI ou AWS SDK nos DAGs; pode usar service‑account com IAM‑Roles for Service Accounts (IRSA) para acesso a recursos AWS.
Segurança	VPC‑isolated, IAM‑based permissions, encryption‑at‑rest (S3, RDS) e in‑transit, integração com Secrets Manager/SSM Parameter Store.	Você configura VPC, RBAC, NetworkPolicies, IAM‑Roles via IRSA, encriptação de volumes EBS, Secrets via Kubernetes secrets ou Secrets Store CSI.
Custo	Cobrança por vCPU‑hour, storage‑GB‑hour, executions (SQS) + metadatabase (RDS). Não há custo de EC2/EKS.	Cobrança por EKS control‑plane (0,10 USD/h), EC2/Spot/On‑Demand para nodes, EBS (GB‑mes), ALB/NLB, S3, CloudWatch, Data Transfer.
Operacional	UI de gerenciamento, environment variables no console, logs em CloudWatch, monitoramento de métricas padrão.	Você precisa instalar e manter Helm chart (ex.: `astronomer/airflow` ou `apache/airflow`), configurar Ingress/LoadBalancer, montar PV, habilitar logging (FluentBit/Fluentd) e monitoramento (Prometheus/Grafana, CloudWatch).
Flexibilidade	Conjunto de plugins oficiais + custom plugins via requirements.txt; limites de recursos por worker (máx 4 vCPU/30 GiB).	Total controle sobre imagens Docker, recursos por pod, número de workers, executor (Celery, Kubernetes, Local, etc.), custom plugins, operadores de terceiros.
Disponibilidade	Multi‑AZ, fail‑over automático da metadatabase (RDS Multi‑AZ).	Você precisa provisionar multi‑AZ (node groups espalhados) e configurar HA para metadatabase (ex.: RDS Multi‑AZ ou Aurora).
Backup & Recovery	Snapshots automáticos diários da metadatabase + retenção configurável.	Você define backup (RDS snapshots ou dump manual), políticas de retenção, e restauração.

A seguir, detalhamos cada ponto, com foco em custos, benefícios, contras e monitoramento.

1. Custos detalhados

1.1 AWS MWAA

Componente	Modelo de cobrança	Exemplo de custo (US‑East‑1)
Ambiente	`vCPU‑hour` (Scheduler + Webserver) + `worker‑vCPU‑hour` (dependente do número de workers)	2 vCPU (scheduler) ≈ 0,30 USD/h; cada worker 1 vCPU ≈ 0,15 USD/h (preços variam por região).
Armazenamento	`GB‑hour` (S3 + RDS)	30 GiB de RDS ≈ 0,10 USD/h; 100 GB de S3 ≈ 0,023 USD/GB‑mes.
Execuções	Task → SQS + CloudWatch (log ingestion)	1 M de mensagens SQS ≈ 0,40 USD; logs CloudWatch ≈ 0,50 USD/GB.
Data Transfer	Dentro da VPC (gratuito) ; entre regiões (tarifas padrão).
Licença	Não há licenças adicionais – tudo incluído.

Observação: O custo total de um ambiente típico (2 workers, 30 GiB RDS) gira em torno de 0,70 a 1,00/h (≈ 500‑500‑720/mês). A conta cresce linearmente com o número de workers, tamanho da DB e volume de logs.

1.2 Airflow no EKS

Componente	Modelo de cobrança	Exemplo de custo (US‑East‑1)
EKS control‑plane	$0,10 USD/h (independente do número de clusters)	≈ $72/mês por cluster.
EC2 (nodes)	On‑Demand/Spot + `vCPU‑hour` + `RAM‑hour`	3 x t3.medium (2 vCPU, 4 GiB) ≈ 0,0416 USD/h cada → $90/mês.
EBS (volumes)	$0,10 USD/GB‑mes (gp2)	100 GB → $10/mês.
Load Balancer (ALB/NLB)	0,0225 USD/h+0,0225 USD/h+0,008 USD/LCU‑h	1 ALB ≈ 18‑18‑20/mês.
Data Transfer	1 GB‑out free, depois $0,09/GB (regional)	Depende do volume.
S3 (artefatos, logs)	$0,023 USD/GB‑mes	Depende do uso.
CloudWatch	$0,50 USD/GB (logs) + métricas	idem MWAA.
Pods/Workers	Não há custo direto, mas requer recursos nos nodes.	Cada worker pod consome vCPU/RAM; dimensionamento impacta número de nodes.

Custo total aproximado (cluster pequeno 3 t3.medium, 100 GB EBS, 1 ALB, 2 workers): 250 a 300/mês.
Se usar Spot Instances (70 % de desconto) ou Fargate, o custo pode cair para 150 a 200/mês.

Comparativo de custos operacionais

Item	MWAA	EKS
Custo fixo	Nenhum (não paga EC2/EKS).	$72/mês (control‑plane) + custo dos nodes.
Escala	Custo linear por worker‑vCPU.	Custo linear por node + por pod (vCPU/RAM).
OPEX	Baixo – menos administração.	Alto – necessidade de DevOps/K8s expertise.
CAPEX	Não há.	Pode usar Spot/Reserved para otimizar.
Elasticidade	Auto‑scale via MWAA (max workers configurável).	Auto‑scale via HPA + Cluster‑autoscaler (maior flexibilidade).

2. Benefícios (prós) e Contras de cada abordagem

2.1 AWS MWAA – Managed Airflow

Benefícios (Prós)

Área	Detalhes
Operacional	Zero esforço de provisionamento de clusters, instalação de Airflow, upgrade de versão ou manutenção de RDS.
Alta Disponibilidade	Scheduler/Webserver em múltiplas AZs, metadatabase Multi‑AZ (RDS).
Segurança	IAM‑based access, VPC‑isolated, encriptação automática (S3, RDS).
Integração nativa	Conexões pré‑configuradas para S3, Redshift, EMR, Athena, Glue, Secrets Manager, etc.
Simplicidade de Deploy	Apenas “Create environment”, apontar para bucket S3 e pronto.
Escala automática de workers	Configuração de max_workers e min_workers; o service gerencia a fila (SQS) e cria/destroi containers.
Monitoramento pronto	Métricas de scheduler, workers, dag runs no CloudWatch; logs consolidados; health checks integrados.
Custo previsível	Modelo pay‑as‑you‑go por vCPU‑hour; sem surpresas de custos de EC2/EBS.
Compliance	Fica dentro dos limites de certificação da AWS (SOC 2, ISO 27001, PCI‑DSS).

Contras

Item	Por quê
Limitações de customização	Não é possível mudar o executor (é sempre Celery ou Kubernetes via MWAA). Não dá para rodar plugins que exigem bibliotecas nativas não suportadas (ex.: `opencv`, `tensorflow` sem wheels).
Restrição de recursos por worker	Máximo de 4 vCPU / 30 GiB por worker (não pode usar GPU ou instâncias com > 64 GiB).
Versão fixa	A AWS mantém um catálogo de versões (ex.: 2.2.5, 2.3.0). Você depende do roadmap da AWS para upgrades.
Bloqueio de fornecedor	Migração para outro serviço requer re‑escrever pipelines e mover DAGs.
Custo por hora pode ser alto em workloads pesados	Se precisar de muitos workers por longos períodos, o custo pode superar o de um cluster EKS bem dimensionado.
Logs em CloudWatch	Necessário configurar retenção e custos associados a logs.
Sem suporte a algumas extensões	Ex.: KubernetesExecutor não é suportado (MWAA usa CeleryExecutor com workers baseados em containers).

2.2 Airflow Self‑Hosted no EKS

Benefícios (Prós)

Área	Detalhes
Flexibilidade total	Pode escolher qualquer executor (Celery, K8s, Local, Dask), qualquer imagem Docker (incluindo GPU, libs nativas, custom operators).
Escala granular	HPA por pod; pode usar node‑affinity para workers especializados (GPU, memória alta).
Controle de custos	Pode usar Spot Instances, Reserved Instances, Fargate; pode dimensionar nodes para “burst” e desligar nos períodos de baixa carga.
Integração avançada	Possibilidade de usar service‑accounts com IRSA, montar Secrets Store CSI para Secrets Manager, montar PVCs para artefatos.
Custom plugins	Deploy de plugins via Docker image ou ConfigMap; pode usar Helm chart com extraPipPackages, extraPythonPackages, extraEnv.
Observabilidade avançada	Prometheus + Grafana, OpenTelemetry, Loki, Kube‑state‑metrics, métricas de pod/containers.
Multi‑tenancy	Pode criar namespaces separados por equipe/projeto, com RBAC e quotas de recursos.
Backup flexível	Snapshots de RDS/Aurora, dumps de PostgreSQL, backup de PVC via CSI.
Resiliência customizada	Pode usar PodDisruptionBudget, node‑affinity, pod‑anti‑affinity para alta disponibilidade.
Custo otimizado em escala	Em grandes volumes, o custo por vCPU pode ser menor usando Spot + autoscaling.

Contras

Item	Por quê
Complexidade operacional	Você precisa provisionar EKS, configurar networking, IAM, RBAC, Helm charts, backup, monitoramento.
Responsabilidade de upgrades	Upgrade de Airflow, do Helm chart, das imagens Docker, do PostgreSQL – risco de incompatibilidade.
Manutenção de alta disponibilidade	Configurar multi‑AZ, backups, fail‑over da metadatabase (RDS/Aurora) – exige conhecimento de infra.
Segurança	Gerenciar secrets, políticas de rede, segurança de pods (seccomp, AppArmor).
Custo de operação	Necessita de pessoal (SRE/DevOps) e tempo de engenharia, que pode superar o custo direto da nuvem.
Possível “over‑provisioning”	Se o autoscaling não for bem afinado, pode haver nós ociosos e custos desnecessários.
Gerenciamento de logs	Precisa configurar FluentBit/Fluentd ou sidecar para enviar logs ao CloudWatch ou a um bucket S3.
Dependência de K8s	Problemas de versão do Kubernetes, de incompatibilidade de API (ex.: mudanças de `apiVersion` de recursos).

3. Monitoramento & Observabilidade

3.1 MWAA

Camada	Como funciona	Métricas padrão (CloudWatch)
Scheduler	Logs enviados para CloudWatch Logs; métricas `SchedulerRunTime`, `TaskQueued`, `TaskRunning`.
Workers	Cada worker container envia métricas de CPU/Memory (via CloudWatch Container Insights).
Webserver	Métricas de HTTP 2xx/4xx/5xx, latência.
DAG Runs	Métricas `DagRunSuccess`, `DagRunFailed`, `TaskInstanceSuccess`, `TaskInstanceFailed`.
Fila (SQS)	Métricas de número de mensagens (tasks) na fila, tempo de espera.
Logs	Logs de execução (task logs) são enviados para CloudWatch Logs (ou S3 via `logging_config`).
Alertas	Pode criar alarmes CloudWatch (ex.: `TaskInstanceFailed > 0` por 5 min) e acionar SNS, PagerDuty.
Health checks	Endpoint `/health` no Webserver (não exposto publicamente).

Ferramentas adicionais

AWS X‑Ray: opcional, para traçar chamadas a serviços AWS.
AWS Managed Grafana: pode consumir métricas do CloudWatch e criar dashboards.
EventBridge: pode disparar eventos ao mudar o estado de DAGs (via AirflowEventBridge).

Limitações

Visibilidade limitada a nível de pod/container, não há métricas de K8s nativas (ex.: pod restarts).
Logs são centralizados mas não há integração nativa com Loki ou Elastic.

3.2 Airflow no EKS

Camada	Ferramentas típicas	O que monitorar
Kubernetes	Prometheus + Grafana (via `kube‑state‑metrics`, `node‑exporter`).	CPU/Memory/Pod restarts, Node health, Deployments, HPA.
Airflow	Exporter `airflow-exporter` (expondo `/metrics` para Prometheus).	`airflow_dagrun_success_total`, `airflow_task_instance_failed_total`, `airflow_scheduler_heartbeat`.
Logs	FluentBit → CloudWatch ou Loki → Grafana.	Logs de Scheduler, Workers, Webserver, Task logs.
Tracing	OpenTelemetry (OTLP) → Jaeger/Zipkin.	Tracing de chamadas a APIs externas (S3, Redshift).
Alertas	Alertmanager (Prometheus) + PagerDuty, SNS via webhook.	Falhas de DAG, alta latência, falta de workers.
Backup	Velero (snapshot de PVC), RDS snapshots.	Verificar sucesso de backups.
Security	Kube‑audit, OPA/Gatekeeper, Kubernetes NetworkPolicy.	Violação de políticas, acesso não autorizado.

Exemplo de pipeline de observabilidade

[Airflow pods] --> (sidecar FluentBit) --> CloudWatch Logs
                 --> (metrics endpoint) --> Prometheus --> Grafana
                 --> (OpenTelemetry collector) --> Jaeger

Pontos de atenção

Retenção de logs: configure logRetentionInDays no CloudWatch ou use S3 + lifecycle.
Escala de métricas: Prometheus pode precisar de remote‑write para long‑term storage (Thanos, Cortex).
Segurança: habilite PodSecurityPolicy ou OPA para evitar containers privilegiados.
Alertas de dead‑letter: SQS pode ficar cheio se os workers falharem – monitore ApproximateNumberOfMessagesVisible.

4. Quando escolher cada opção?

Cenário	Melhor escolha
Time pequeno / sem expertise K8s	MWAA – menor overhead, start‑up rápido.
Workloads críticos com SLA de < 5 min	MWAA (gerenciado) ou EKS bem dimensionado – depende da tolerância a risco.
Necessidade de GPUs ou bibliotecas nativas	EKS – pode usar nodes GPU e imagens customizadas.
Ambientes regulatórios que exigem controle total de dados	EKS (controle total sobre rede, criptografia, localização de dados).
Custo previsível e baixa variação	MWAA – modelo pay‑per‑use por vCPU, sem surpresas de custos de EC2.
Grande volume de tarefas (milhares por hora) e necessidade de burst	EKS (Spot + auto‑scale) pode ser mais barato.
Multi‑tenant (vários squads)	EKS (namespaces, quotas).
Integração profunda com serviços AWS	MWAA (conexões nativas).
Política “no‑vendor‑lock‑in”	EKS (pode migrar para outro provedor K8s).

5. Checklist rápido de implementação

MWAA

Criar ambiente (Console/CLI) → escolher VPC, subnets, security groups.
Definir executor → Celery (padrão).
Configurar requirements.txt (bibliotecas Python).
Upload de DAGs → bucket S3 (pasta dags/).
Configurar Connections/Variables → UI ou Secrets Manager.
Ajustar min_workers / max_workers.
Criar alarmes CloudWatch → falhas de DAG, alta latência.
Habilitar logging → CloudWatch ou S3.
Testar → execute um DAG de teste.

EKS (Airflow)

Provisionar cluster EKS (eksctl ou CloudFormation).
Criar node group (on‑demand / spot) com instance profile que tem permissão para S3, RDS, etc.
Instalar Helm → helm repo add astronomer https://helm.astronomer.io && helm repo update.
Deploy Airflow (helm install airflow astronomer/airflow --set executor=Celery|Kubernetes).
Configurar metadatabase → RDS PostgreSQL (Multi‑AZ) ou Aurora.
Criar Secrets → via kubectl create secret generic ou Secrets Store CSI.
Configurar Ingress/ALB → exposição do Web UI.
Instalar Prometheus & Grafana (Helm charts).
Instalar FluentBit → enviar logs ao CloudWatch ou a Loki.
Configurar Auto‑Scaling – HPA para workers + Cluster‑autoscaler.
Backup – snapshots RDS + Velero para PVC.
Testar – rode um DAG de exemplo.

6. Conclusão

AWS MWAA é a escolha mais simples e rápida se você quer começar a rodar Airflow com baixo overhead operacional, aproveitando a integração nativa com serviços AWS e pagando por vCPU‑hour. Ele entrega alta disponibilidade e segurança “out‑of‑the‑box”, porém tem limitações de customização (executor fixo, recursos máximos por worker) e pode ficar caro em ambientes de alta demanda.
Airflow no EKS oferece máxima flexibilidade, controle de custos (Spot, Reserved) e observabilidade avançada (Prometheus, OpenTelemetry). É ideal para cenários complexos (GPU, libs nativas, multi‑tenant, políticas de segurança customizadas) e para grandes volumes onde o custo de MWAA pode ser proibitivo. Contudo, exige expertise em K8s, um time de SRE e processos de backup/upgrade bem definidos.

A decisão deve levar em conta custo total de propriedade (TCO), competências da equipe, requisitos de performance e compliance, e o grau de customização que sua organização precisa. Avalie um PoC com ambos (MWAA por 1‑2 semanas e um pequeno cluster EKS) para medir latência, custos de execução e esforço operacional antes de firmar a escolha final.

Airflow na AWS: MWAA ou no EKS? – Como escolher a solução ideal para orquestrar suas pipelines

Visão geral