Converta a intenção em uma regra da AWS
Um agendamento da AWS pode ser válido e ainda representar a intenção operacional errada. Antes de criar um recurso, escreva o requisito como regra de calendário: minuto e hora, dias permitidos, fuso horário e anos. Depois decida se o destino é EventBridge Scheduler ou uma regra agendada legada. O gerador cron da AWS mantém essas escolhas ao lado das datas calculadas. Ele funciona localmente e não precisa de conta nem credenciais da AWS.
Uma tabela útil tem seis colunas: minuto 0–59, hora 0–23, dia do mês 1–31, mês 1–12 ou JAN–DEC, dia semanal 1–7 ou SUN–SAT e ano 1970–2199. Coloque ? na coluna de dia não usada. Na migração, Unix 0 9 * * 1-5 vira AWS cron(0 9 ? * MON-FRI *); o ? tem significado.
Verifique um exemplo fixo de última sexta-feira
Use um caso fixo: cron(15 10 ? * 6L 2026-2027), EventBridge Scheduler, UTC, depois de 2026-09-18T00:00:00Z. As três primeiras correspondências são 2026-09-25T10:15:00.000Z, 2026-10-30T10:15:00.000Z e 2026-11-27T10:15:00.000Z. 6L indica a última sexta-feira pela numeração da AWS e ? deixa o dia do mês sem especificação. O instante inicial é excluído. O exemplo pode ser conferido em qualquer calendário.
Acrescente dois casos. cron(0/15 * * * ? *) depois das 10:00 UTC gera 10:15, 10:30 e 10:45; é padrão de calendário, não temporizador desde a implantação. cron(0 8 1 * ? *) depois de 2026-07-01T08:00:00Z gera 1º de agosto, setembro e outubro às 08:00 UTC. Datas esperadas revelam falhas.
Revise o agendamento em uma ordem repetível
Escolha primeiro o serviço. Scheduler aceita um fuso IANA; regras legadas usam UTC. Informe minuto, hora, dia do mês, mês, dia da semana e ano. Coloque ? em exatamente um campo de dia, calcule e revise várias correspondências, incluindo viradas de mês. Compare horário local, deslocamento e instante UTC. Copie cron(...) somente quando estiver de acordo com o requisito. Na AWS configure separadamente destino, função, janela flexível, novas tentativas e fila de erros.
Teste dias especiais isoladamente. Em UTC após 2026-08-01T00:00:00Z, cron(0 9 1W * ? *) escolhe segunda-feira, 3 de agosto: dia 1 é sábado e o dia de segunda a sexta fica em agosto. Para cron(0 9 ? * TUE#2 *), as próximas datas são 11 de agosto, 8 de setembro e 13 de outubro. Listas com várias regras # não são aceitas.
Entenda os seis campos e operadores
Cron Unix costuma ter cinco campos e combina os dias conforme sua implementação. A AWS exige seis e termina com um ano de 1970 a 2199. Nomes de meses e dias são aceitos. L expressa uma regra de último dia, nW o dia útil mais próximo de uma data mensal e n#k a k-ésima ocorrência semanal. A ferramenta aceita L isolado como sábado e 6L como última sexta-feira. Combinações ambíguas são recusadas em vez de interpretadas por suposição.
Leia cada campo como conjunto. A barra define incrementos dentro do campo, não intervalo decorrido. O intervalo de horas 20-2 cobre noite e madrugada. Nomes facilitam revisão e a cópia normaliza maiúsculas. L no dia do mês significa o último dia; L isolado significa sábado somente no dia da semana; 6L significa a última sexta-feira. nW procura o dia de segunda a sexta mais próximo. LW, deslocamentos de L e listas especiais ficam fora do subconjunto do simulador.
Diagnostique expressões plausíveis mas erradas
Um erro grave é copiar cinco campos Unix e acrescentar outro por intuição. Traduza o requisito. Outro erro é definir regras nos dois campos de dia: a AWS exige ? em um deles. Listas com várias expressões # também são inválidas. Um resultado vazio nem sempre indica sintaxe errada. A pesquisa cobre cinco anos; uma expressão com 2199 pode ser válida e não mostrar datas partindo de 2026.
Se o resultado surpreender, simplifique: troque o ano por *, use UTC e substitua temporariamente o dia especial por valor simples. Restaure cada restrição. Confira se o instante inicial foi excluído, se o ano está nos próximos cinco e se ? aparece exatamente em um campo de dia. Isso separa limite do horizonte de erro de campo ou fuso.
Separe fuso, horário de verão e precisão
Scheduler avalia a hora civil do fuso escolhido. Se um horário não existe no avanço da primavera, essa execução é ignorada; na hora repetida do outono ocorre uma única invocação. Regras legadas permanecem em UTC, e sua relação com a hora de uma cidade muda conforme a estação. A AWS documenta precisão de minuto: agendar 10:15 não promete um milissegundo exato. Janelas flexíveis e entrega são configurações separadas.
Para Madri, teste cron(30 2 * * ? *) com Scheduler. Em 29 de março de 2026, 02:30 não existe e é ignorado. Em 25 de outubro, 02:30 aparece duas vezes, mas Scheduler invoca uma vez na primeira. Como regra legada, UTC não tem salto nem repetição; a exibição de Madri muda com o deslocamento.
Saiba o que uma visualização local não prova
Esta página simula o calendário; ela não testa uma implantação da AWS. Aceita 256 caracteres, retorna até dez correspondências e para após cinco anos. Não verifica permissões IAM, payloads, cotas, repetição, latência, disponibilidade ou idempotência. Os instantes são correspondências esperadas do calendário, não prova de que a AWS aceitou o recurso ou de que o destino recebeu um evento.
A AWS documenta precisão de 60 segundos. Uma linha 10:15 identifica o minuto, não garante latência. Scheduler também pode usar janela flexível e a entrega pode ser repetida; a ferramenta não modela essas opções. Se o processo exigir exatidão, torne o destino idempotente e observe registros reais em vez de tratar linhas como execuções.
Mantenha evidências junto da expressão
Guarde expressão, serviço, fuso, instante de referência e datas esperadas na revisão. Confira uma semana normal, uma virada de mês, o operador especial e uma mudança de horário ao usar fuso local. Revise o ano. No console ou na infraestrutura como código, confirme expressão e fuso, teste o destino e acompanhe métricas. Inclua a guia de cron Unix ao documentar uma migração.
Antes de ativar, peça que outra pessoa derive as três primeiras datas. Teste um mês cujo dia 1 seja fim de semana para W, um mês com cinco candidatos para # ou L e uma mudança de horário. Confirme que a infraestrutura preserva o fuso. Após implantar, use destino inofensivo, revise métricas e erros e documente a reversão.
Uma revisão final deve separar três relógios: o horário escrito na regra, a hora civil interpretada pelo Scheduler e o instante UTC registrado. Em uma regra legada, entram apenas a expressão UTC e sua representação posterior. Se a equipe usa nomes como MON ou JAN, preserve também o requisito em linguagem comum; se usa números, documente a correspondência. Repita o teste quando mudar o fuso ou o intervalo de anos, pois as duas decisões alteram as datas sem necessariamente mudar minuto e hora. Confira meses curtos e evite confundir uma regra mensal com uma frequência baseada em duração.
Guarde também a versão exata que será copiada. Os parênteses de cron(...) e os nomes em maiúsculas tornam o dialeto visível na revisão textual. Confira o instante inicial exclusivo: uma correspondência exatamente naquele instante não aparece como próximo resultado. Esse detalhe evita interpretar como erro um primeiro resultado que avança até o minuto ou dia permitido seguinte.
Fontes: Tipos de agenda do AWS EventBridge Scheduler e Padrões de regras agendadas do AWS EventBridge.