Conectores SaaS nativos do Glue: contra AppFlow, zero-ETL e código próprio

Quando um time de finanças pede "as transações do Adyen no lake até amanhã", hoje existem quatro respostas na AWS.

Conector nativo do Glue: um job Spark no Glue 5.0 lê a entidade pelo connection_type do SaaS, com ENTITY_NAME, SELECTED_FIELDS, FILTER_PREDICATE em Spark SQL e particionamento por PARTITION_FIELD, LOWER_BOUND, UPPER_BOUND e NUM_PARTITIONS. O segredo fica no Secrets Manager, um por conexão.

Zero-ETL do Glue: replicação gerenciada, sem job, para Redshift, S3 ou S3 Tables pela arquitetura de lakehouse do SageMaker. O problema é a cobertura: na documentação atual, as fontes SaaS são Salesforce, Salesforce Marketing Cloud Account Engagement, SAP OData, ServiceNow, Zendesk, Zoho CRM, Facebook Ads e Instagram Ads. Nenhum dos conectores de pagamento do anúncio está nessa lista.

Amazon AppFlow: fluxo gerenciado cobrado por execução e por GB processado, bom para cópia agendada sem transformação.

Extrator próprio: Lambda ou Step Functions chamando a API, gravando em S3. Controle total, e dívida total.

O anúncio muda o equilíbrio porque o primeiro caminho passou a cobrir a cauda longa que antes só o quarto cobria. Para fontes fora dos 100, ainda existe o conector REST do Glue (RegisterConnectionType), com OAuth2 client credentials, authorization code, JWT, basic ou autenticação customizada, e paginação por cursor ou offset. Ou seja, mesmo o caso "meu SaaS não está na lista" tem saída declarativa antes de partir para código.

A documentação do conector Stripe deixa claro um detalhe que vale para boa parte da cauda longa: só existe particionamento por campo. Não há particionamento por registro (o conector não tem como obter a contagem total) nem por ID, porque a chave primária é string. Na prática, isso significa que o paralelismo e o incremental dependem de um campo de tempo que você escolhe, e a responsabilidade pela marca d'água é sua.

O desenho que uso é simples. Uma tabela DynamoDB com partition key source#entity guarda o último created processado. O job lê esse valor, monta FILTER_PREDICATE com uma janela de sobreposição de 15 a 30 minutos para trás, define LOWER_BOUND e UPPER_BOUND sobre o mesmo campo e grava num staging em Iceberg. O MERGE pela chave natural da transação (o ID do pagamento no adquirente) torna a reexecução idempotente. Só depois do commit o job atualiza a marca d'água, com ConditionExpression sobre o valor anterior para evitar duas execuções concorrentes avançando o ponteiro.

A sobreposição existe porque API de pagamento não é append-only. Estorno, chargeback e mudança de status alteram registro antigo, e um campo updated nem sempre está disponível como filtro. Sem janela, você perde a atualização. Sem MERGE, você duplica a transação. Os dois erros aparecem do mesmo jeito: a conciliação com o extrato bancário não fecha, e alguém descobre no fechamento do mês, não no dia.

Faço a conta para uma fonte de pagamento puxada de hora em hora. Um job com 2 workers G.1X (2 DPU) rodando 10 minutos consome cerca de 0,33 DPU-hora: uns US$ 0,15 por execução a US$ 0,44, ou perto de US$ 105 por mês com 24 execuções diárias. Em Flex, a US$ 0,29, cai para perto de US$ 70, ao custo de início não garantido. O mesmo volume no AppFlow, com 720 execuções e 1 GB por execução, fica em torno de US$ 15: US$ 0,72 de execuções e US$ 14,40 de dados.

Olhando só a fatura, o AppFlow ganha. Mas a fatura não é o custo. O AppFlow cobra execução que não encontrou dado novo e cobra como sucesso a execução que falhou por configuração errada, e ele não transforma: alguém ainda precisa deduplicar, tipar e fazer o MERGE depois. Se essa etapa já é um job Glue, você paga o DPU de qualquer forma e ganha uma segunda ferramenta para operar.

O extrator próprio tem a fatura mais baixa de todas, centavos de Lambda. O custo dele aparece em outro lugar: rotação de credencial, mudança de versão da API, rate limit novo, campo renomeado. Em plataformas que mantive, um extrator de adquirente consumia algo como dois a três dias de engenharia por trimestre só para continuar funcionando, e esse número nunca entrava no business case.

Regra que uso: se a frequência é horária ou menor, comece por Flex e só mova para padrão quando o SLO de frescor exigir.

O ganho de governança mais concreto é a conexão como recurso do Data Catalog. Antes, cada extrator tinha seu próprio jeito de guardar chave de API, quase sempre uma variável de ambiente que alguém copiou entre contas. Agora existe um segredo por conexão no Secrets Manager, e o acesso passa por IAM.

Três ajustes que faço antes de liberar em produção:

Escopo do role: o exemplo da documentação concede secretsmanager:GetSecretValue, PutSecretValue e as ações de ENI em "Resource": "*". Em ambiente auditado por BACEN 4.893 ou PCI-DSS, eu restrinjo o recurso ao ARN do segredo da conexão e uso aws:ResourceTag/data-domain para que o job de finanças não leia o segredo do Gusto, que tem dado de folha.

Minimização na origem: SELECTED_FIELDS não é só otimização. Se o relatório de transações do adquirente traz dados de titular que a análise não precisa, não traga. O que não entra no lake não entra no escopo da auditoria.

Rede: a conexão aceita opções de rede próprias. Rodar o job em subnet privada com saída por NAT de IP fixo facilita a allowlist do lado do SaaS, e alguns adquirentes exigem isso.

Por fim, observabilidade: alarme em glue.driver.aggregate.numCompletedTasks igual a zero não basta. O sinal que importa é volume ingerido contra a média móvel da mesma hora, porque o modo de falha típico não é erro, é zero linha com status de sucesso.