# MWAA com Airflow 3.3.1: estado, linguagem e disciplina operacional

Eu vejo o suporte do Amazon MWAA ao Apache Airflow 3.3.1 como uma evolução importante para pipelines que não cabem mais no modelo puramente stateless. O ganho real está em estado durável, particionamento de assets e melhor ergonomia de operação; o risco está em tratar recursos experimentais como plataforma corporativa madura cedo demais.

- URL: https://fernando.moretes.com/blog/mwaa-com-airflow-3-3-1-estado-linguagem-e-disciplina-operacional-amazon-mwaa-

- Markdown: https://fernando.moretes.com/blog/mwaa-com-airflow-3-3-1-estado-linguagem-e-disciplina-operacional-amazon-mwaa-/article.md?lang=pt

- Published: 2026-09-01T19:52:51.537Z

- Category: IA & Agentes

- Tags: AWS, MWAA, Airflow 3.3, Data Platform, Orchestration, FinOps, Reliability, Governance

- Reading time: 9 min

- Source: [Amazon MWAA supports Apache Airflow version 3.3.1](https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-mwaa-apache-airflow-3-3-1/)

---

O anúncio de 1 de setembro de 2026, colocando o Apache Airflow 3.3.1 no Amazon MWAA, parece pequeno se lido como simples atualização de versão. Eu não leio assim. Para ambientes financeiros, plataformas de dados reguladas e operações com centenas de DAGs, o ponto central é que Airflow começa a reconhecer formalmente três realidades que arquitetos já resolviam por fora: tarefas precisam lembrar progresso, nem todo código de domínio deve virar Python, e retentativas precisam entender a causa da falha. O MWAA reduz parte da carga operacional de manter scheduler, workers, webserver e metadatabase, mas não remove a obrigação de desenhar idempotência, isolamento, controle de custo e observabilidade. Minha avaliação: vale estudar e adotar seletivamente, principalmente para workloads incrementais e long-running jobs; não vale transformar todo DAG em laboratório de SDK experimental.

## Números que moldam a decisão

- **3.3.1** — Versão do Airflow agora suportada no MWAA. O release do Apache Airflow 3.3.1 é de 12 de agosto de 2026; o suporte no MWAA foi anunciado em 1 de setembro de 2026.
- **25** — Workers por ambiente como quota padrão. A quota documentada de MWAA lista 25 workers por ambiente, 5 webservers e 10 ambientes por conta por região, todos ajustáveis.
- **$0.49/h** — Exemplo público para ambiente pequeno em us-east-1. A página de preços usa $0.49 por hora para ambiente small e $0.055 por hora por worker small adicional em um exemplo de N. Virginia.

## O que realmente mudou

Eu separo esta versão em dois blocos: o que muda a modelagem de workflows e o que melhora a operação diária. No primeiro grupo entram o Task and Asset State Store, o particionamento expandido de assets, as retry policies plugáveis e o Language Task SDK experimental para Java e Go. No segundo entram ações em massa para DAG runs e task instances, correções de estabilidade, segurança e interface, além de melhorias úteis para quem opera muitos pipelines.

O State Store é o ponto mais arquitetural. Até aqui, muita equipe usava XCom, Variables, DynamoDB, S3 ou tabelas auxiliares para guardar cursor, job id externo, watermark e checkpoints. Algumas dessas soluções eram corretas; outras viravam dívida técnica com semântica confusa. Airflow 3.3 cria um lugar explícito para esse estado: task state para a instância de tarefa e asset state para metadados associados ao asset. Isso não elimina DynamoDB ou bancos externos quando o estado é de domínio, auditável ou compartilhado por sistemas fora do Airflow. Mas melhora a higiene do DAG quando o estado é operacional e pertence ao ciclo de execução.

No MWAA, essa mudança é particularmente relevante porque o serviço já coloca scheduler e workers em Fargate e mantém um metadatabase gerenciado. A tentação será encher o metadatabase com estado demais. Eu faria o oposto: usaria o store para ponteiros pequenos, versionados e descartáveis, e deixaria dados de negócio em S3, DynamoDB, Aurora ou no lakehouse.

## Onde eu vejo valor

- Checkpoints de jobs externos ficam mais limpos: um task state pode guardar o job id de EMR Serverless, Glue, Batch, ECS ou SageMaker antes do polling terminar.
- Watermarks por asset reduzem acoplamento: uma partição processada no S3 ou em uma tabela pode carregar estado sem virar Variable global.
- Retry policies plugáveis ajudam a separar erro transitório de erro permanente, especialmente em APIs com throttling, credenciais expiradas e validação de contrato.
- Java e Go entram como opção para lógica de domínio existente, mas eu trataria o SDK como experimental até provar empacotamento, logs e suporte operacional.
- As ações em massa reduzem atrito operacional em reprocessamentos, mas também pedem controles de mudança e trilha de auditoria mais fortes.

## Estado durável não é permissão para esquecer idempotência

O principal erro que eu espero ver com Airflow 3.3 é transformar state store em banco de aplicação. Em sistemas financeiros, uma tarefa que liquida arquivos, publica eventos, calcula exposição ou reconcilia posições não pode depender apenas de “lembrar onde parou”. Ela precisa ser idempotente por desenho. Isso significa chaves naturais, deduplicação, escrita condicional e limites explícitos de reprocessamento.

Um desenho que eu aceitaria: um DAG recebe eventos de chegada de arquivo, materializa metadados em DynamoDB com partition key como `dataset#business_date` e sort key como `source_file#version`, grava os dados brutos em S3 com versioning e SSE-KMS, e usa o task state apenas para guardar o identificador de um job Glue ou EMR Serverless já submetido. Se o worker morrer, a próxima tentativa recupera o job id, consulta o estado do job e decide se acompanha, cancela ou abre uma tentativa nova com token de idempotência. O estado durável evita trabalho duplicado; a tabela de controle continua sendo o livro-caixa auditável.

Eu também colocaria TTL ou retenção curta nos estados de task sempre que possível. Para cursores de asset, usaria payloads pequenos: último offset confirmado, hash do contrato, janela de partição e versão do produtor. Se o valor começa a parecer documento, evento ou snapshot, ele provavelmente não pertence ao state store.

## Como eu desenharia o uso seguro do State Store

O diagrama mostra o padrão que eu prefiro: Airflow guarda estado operacional mínimo; o estado auditável e os dados continuam em serviços próprios.

### 🟦 Orquestração MWAA

- DAG Python asset-aware (compute)
- Task State Store job_id, checkpoint (data)
- Asset State Store watermark, partition (data)

### 🟧 Execução AWS

- AWS Glue / EMR long-running job (compute)
- Amazon S3 raw + curated data (storage)
- DynamoDB control ledger (data)

### 🛡️ Governança e Operação

- IAM + KMS least privilege (security)
- CloudWatch logs, metrics, alarms (edge)
- Runbook replay window (ci)

### Fluxos

- dag -> glue: submete job com token idempotente
- dag -> taskstate: persiste job_id antes do polling
- glue -> s3: grava saídas particionadas
- glue -> ddb: atualiza livro de controle
- dag -> assetstate: avança watermark após commit
- iam -> dag: assume role restrito
- dag -> cw: emite duração, retry e lag
- cw -> runbook: aciona replay controlado

## SDK Java/Go: integração útil, maturidade ainda em prova

Eu gosto da direção do Language Task SDK porque ela reconhece que plataformas de dados corporativas raramente são 100% Python. Há bibliotecas de precificação em Java, validadores de contrato em Go, clientes internos com políticas de segurança já revisadas e binários que equipes de plataforma preferem não reescrever. O modelo documentado mantém o DAG em Python e declara tarefas stub com `@task.stub(queue=...)`; o worker delega para um coordenador, como `JavaCoordinator` para JVM ou `ExecutableCoordinator` para binários autocontidos como Go.

A oportunidade é reduzir wrappers frágeis. Em vez de chamar um script via BashOperator e perder semântica de task, retries, pools e XCom, a tarefa não Python participa do grafo. Isso melhora legibilidade e ownership: a equipe de dados mantém a orquestração, a equipe de domínio mantém a implementação.

Mas eu seria conservador. A própria documentação marca esse recurso como experimental, e isso importa. Em MWAA, eu validaria primeiro se o empacotamento do binário ou JAR é compatível com o fluxo de plugins, requirements, imagem gerenciada e diretórios disponíveis no worker. Também testaria cold start, tamanho de artefato, logs remotos, segredos via Connections, limites de memória da classe escolhida e comportamento em rollback. Para produção regulada, eu começaria com tarefas de baixo risco, sem side effects irreversíveis, e deixaria o Python puro como caminho de recuperação.

> **O risco escondido está no metadatabase:** O metadatabase do Airflow já carrega DAG runs, task instances, XComs, logs indiretos, serialização e estado de scheduler. Ao adicionar state store, eu monitoraria crescimento, limpeza e cardinalidade desde o primeiro dia. Em MWAA, a cobrança também inclui armazenamento do metadatabase em GB-mês; em uma plataforma com muitos mapeamentos dinâmicos, cursores por partição e reruns frequentes, o custo pequeno pode ser menos importante que o impacto operacional de uma base inchada.

## Operação MWAA: versão gerenciada não é operação terceirizada

MWAA continua sendo uma escolha pragmática quando a empresa quer Airflow sem administrar Kubernetes, Celery, metadatabase e patching de imagem. A documentação confirma que schedulers e workers rodam em Fargate, com metadatabase Aurora PostgreSQL gerenciado e integração com CloudWatch, S3, SQS e KMS. Isso tira esforço indiferenciado da equipe, mas não transforma Airflow em serviço invisível.

Eu começaria qualquer upgrade 3.3.1 com um ambiente paralelo, não com uma alteração direta no ambiente crítico. Como o anúncio permite novo ambiente 3.3.1 e upgrade a partir de 3.2 ou posterior, eu usaria o caminho paralelo para validar dependências, constraints, imports de `airflow.sdk`, providers e DAG serialization. A tabela pública de versões do MWAA também mostra a disciplina de ciclo de vida: AWS suporta pelo menos três versões menores e avisa fim de suporte com 180 dias de antecedência, mas a responsabilidade de manter ambientes atuais permanece do cliente.

Em capacidade, eu não dimensionaria por quantidade de DAGs apenas. As classes vão de `mw1.micro`, com 3 tarefas concorrentes padrão e sem autoscaling, até `mw1.2xlarge`, com 80 tarefas concorrentes padrão e recursos bem maiores. Schedulers para Airflow v3 aceitam de 2 a 5 em ambientes acima de micro, e workers têm default 10, mínimo 1 e máximo 25. Esses números pedem teste de carga com DAGs reais, não planilha otimista.

## Onde colocar estado no desenho
| Critério | Uso correto | Evitar | Decisão prática |
| --- | --- | --- | --- |
| Task State Store | Job id externo, checkpoint de retry, progresso pequeno dentro da task instance. | Resultado de negócio, payload grande, evento auditável ou contrato de dados. | Use para retomar execução; não use como fonte de verdade. |
| Asset State Store | Watermark, última partição confirmada, hash de esquema e metadado operacional do asset. | Catálogo corporativo, linhagem completa, regras de qualidade ou autorização. | Bom para coordenação de DAG; complemente com Glue Data Catalog, Lake Formation ou ferramenta de lineage. |
| DynamoDB / Aurora | Controle auditável, idempotência cross-system, locks, aprovação, SLA e reconciliação. | Estado efêmero que só uma task precisa durante uma retentativa. | Use quando auditoria, consulta externa ou retenção formal forem requisitos. |

## Retries plugáveis mudam o contrato com falhas

Retentativa é um dos lugares onde plataformas de dados perdem dinheiro silenciosamente. Um `retries=3` com delay fixo parece inocente, mas em APIs transacionais pode triplicar custo, gerar duplicidade e mascarar erro permanente. Em workloads de mercado, risco, antifraude ou dados regulatórios, eu quero que o DAG saiba a diferença entre `ThrottlingException`, falha de rede, `AccessDenied`, validação de schema e quebra de contrato semântico.

As retry policies do Airflow 3.3 permitem regras por tipo de exceção e ações como retry, fail ou comportamento padrão. Isso aproxima a orquestração de uma política operacional explícita. Eu aplicaria esse recurso em torno de operadores que chamam APIs externas, jobs gerenciados e integrações sujeitas a rate limit. Para AWS SDK, eu ainda deixaria o retry de baixo nível do botocore tratar falhas transitórias curtas; o retry do Airflow deve ser usado para decisões de workflow, com delay compatível com SLA e janelas de processamento.

Um padrão saudável: falha de permissão deve falhar rápido e acionar runbook; throttling deve usar backoff e alarmar apenas depois de N minutos de backlog; erro de schema deve abrir incidente de contrato e bloquear downstream; falha de job externo deve verificar estado remoto antes de reenviar. Esse detalhe reduz custo e melhora confiança no reprocessamento.

## Como eu adotaria em produção

1. **Criar ambiente paralelo 3.3.1** — Eu clonaria DAGs, requirements, plugins e configurações, mantendo o ambiente atual intacto. Validaria constraints, imports, permissões IAM, Connections, pools e serialização antes de qualquer tráfego real.

2. **Classificar DAGs por risco** — Separaria DAGs somente leitura, DAGs idempotentes, DAGs com side effects e DAGs regulatórios. O state store entraria primeiro em workflows incrementais com rollback simples.

3. **Definir contrato de estado** — Cada chave precisa ter dono, formato JSON, escopo, retenção, política de limpeza e relação com auditoria. Eu rejeitaria chave livre criada dentro de task sem convenção.

4. **Instrumentar antes de migrar** — Eu acompanharia duração por task, queue time, scheduler lag, workers ativos, retries por causa, tamanho do metadatabase, crescimento de XCom e contagem de estados.

5. **Fazer cutover por janela de dados** — Em vez de migrar todos os DAGs, eu moveria uma janela ou domínio, congelaria reprocessamentos concorrentes e manteria runbook claro para replay e retorno.

## Anti-padrões que eu evitaria

- Migrar para 3.3.1 só para estar na versão mais nova, sem inventário de DAGs, providers e dependências transitivas.
- Guardar payload de negócio no Task State Store e depois tentar reconstruir auditoria por metadatabase de orquestração.
- Usar SDK Java/Go para contornar governança de imagem, secret scanning, revisão de dependências e observabilidade.
- Aumentar workers até a quota padrão de 25 sem verificar gargalo real em scheduler, banco, API externa, pool ou downstream.
- Permitir bulk clear ou rerun amplo sem aprovação, anotação de mudança e janela explícita de reprocessamento.

## Leitura Well-Architected

- **security**: Eu manteria MWAA em acesso privado quando o público-alvo for interno, usaria IAM com escopo por ambiente, KMS para buckets de DAGs/logs/dados e políticas condicionais em S3 como `aws:SecureTransport` e prefixos por domínio. Connections devem referenciar segredos gerenciados, não credenciais embutidas em DAGs ou bundles.
- **reliability**: State Store melhora recuperação, mas confiabilidade vem de idempotência, replay controlado, pools, retries por causa e isolamento de domínios. Para workloads críticos, eu separaria ambientes por criticidade ou domínio para evitar que DAGs experimentais pressionem scheduler e workers compartilhados.
- **performance**: As classes MWAA devem ser escolhidas por medições: tempo de parse, scheduler lag, duração de tasks, uso de CPU/memória e concorrência efetiva. A configuração de webserver escala por CPU acima de 70 ou ActiveConnectionCount acima de 15, mas isso resolve UI/API, não gargalos de processamento.

## Meu veredito técnico antes do veredito final

Esta versão não muda minha regra básica para Airflow: ele deve orquestrar, não processar pesado dentro do worker. Em MWAA, eu continuaria chamando Glue, EMR Serverless, Batch, ECS, EKS, Lambda ou serviços especializados para o trabalho substancial, deixando o DAG coordenar dependências, janelas, contratos, estado de execução e decisões de retry. O State Store torna essa coordenação mais honesta, principalmente quando o worker pode morrer depois de submeter um job remoto e antes de gravar o resultado.

Também vejo uma tendência mais ampla nos sinais recentes da AWS: serviços gerenciados recebendo controles operacionais mais finos. CloudWatch ganhou warm-up para alarmes, DocumentDB recebeu upgrade major direto, Redshift reforçou autenticação com IAM Identity Center e roteamento VPC, e agora MWAA acompanha a evolução do Airflow em estado e execução multi-linguagem. A direção é clara: menos operação indiferenciada, mais responsabilidade por política, governança e desenho de mudança.

Para liderança de engenharia, a conversa correta não é “vamos habilitar Airflow 3.3.1?”. A pergunta é: quais incidentes, retrabalhos e controles manuais esta versão remove sem aumentar risco? Se a resposta aponta para reprocessamento incremental, jobs longos, retries mais inteligentes e separação limpa de código Python versus domínio Java/Go, há valor concreto. Se a resposta é apenas novidade, eu esperaria.

> **Nota de curadoria:** Eu adotaria MWAA com Airflow 3.3.1 primeiro em um domínio de dados com reprocessamento frequente e impacto controlado, não no fluxo mais sensível da empresa. Minha lição prática é que orquestradores falham menos por falta de feature e mais por estado mal definido, retry preguiçoso e ownership difuso. O State Store é bom justamente porque obriga a nomear o estado; usado sem disciplina, ele só muda a dívida de lugar. Para Java e Go, eu esperaria a equipe provar empacotamento, logs e rollback antes de chamar de padrão.

## Referências verificadas

- [AWS What's New: Amazon MWAA supports Apache Airflow version 3.3.1](https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-mwaa-apache-airflow-3-3-1/)
- [Amazon MWAA User Guide: What is Amazon MWAA?](https://docs.aws.amazon.com/mwaa/latest/userguide/what-is-mwaa.html)
- [Amazon MWAA User Guide: Apache Airflow versions](https://docs.aws.amazon.com/mwaa/latest/userguide/airflow-versions.html)
- [Amazon MWAA User Guide: Environment classes](https://docs.aws.amazon.com/mwaa/latest/userguide/environment-class.html)
- [Amazon MWAA User Guide: Service quotas](https://docs.aws.amazon.com/mwaa/latest/userguide/mwaa-quotas.html)
- [Amazon MWAA Pricing](https://aws.amazon.com/managed-workflows-for-apache-airflow/pricing/)
- [Apache Airflow 3.3.1 Release Notes](https://airflow.apache.org/docs/apache-airflow/3.3.1/release_notes.html)
- [Apache Airflow 3.3.1 Non-Python Task SDKs](https://airflow.apache.org/docs/apache-airflow/3.3.1/authoring-and-scheduling/language-sdks/index.html)

## Veredito

Minha recomendação é adoção seletiva: forte para pipelines incrementais, jobs longos, recuperação após falha de worker, particionamento de assets e políticas de retry mais explícitas; cautelosa para SDKs Java/Go até a organização provar empacotamento, segurança, observabilidade e suporte. Em uma escala de arquitetura corporativa, eu daria 8/10 para MWAA com Airflow 3.3.1 como plataforma de orquestração gerenciada, desde que o time mantenha estado operacional pequeno, dados auditáveis fora do Airflow e um plano de upgrade testado. Eu não usaria esta versão como desculpa para colocar lógica pesada dentro dos workers nem para substituir governança de dados por metadados de DAG.

**Rating:** 8/10