Die Absicht in eine AWS-Kalenderregel übersetzen
Ein AWS-Zeitplan kann grammatisch gültig sein und trotzdem die falsche betriebliche Absicht ausdrücken. Formuliere vor dem Anlegen einer Ressource die Kalenderregel: Minute und Stunde, zulässige Tage, Zeitzone und Jahre. Entscheide danach zwischen EventBridge Scheduler und einer älteren geplanten EventBridge-Regel. Der AWS-Cron-Generator zeigt diese Auswahl neben den berechneten Terminen. Er arbeitet lokal und benötigt weder AWS-Konto noch Zugangsdaten.
Eine Prüftabelle hat sechs Spalten: Minute 0–59, Stunde 0–23, Monatstag 1–31, Monat 1–12 oder JAN–DEC, Wochentag 1–7 oder SUN–SAT und Jahr 1970–2199. Im ungenutzten Tagesfeld steht ?. Bei einer Migration wird Unix 0 9 * * 1-5 zu AWS cron(0 9 ? * MON-FRI *); das ? trägt Bedeutung.
Ein festes Letzter-Freitag-Beispiel prüfen
Nutze einen festen Prüffall: cron(15 10 ? * 6L 2026-2027), EventBridge Scheduler, UTC, nach 2026-09-18T00:00:00Z. Die ersten Treffer sind 2026-09-25T10:15:00.000Z, 2026-10-30T10:15:00.000Z und 2026-11-27T10:15:00.000Z. 6L bezeichnet in der AWS-Zählung den letzten Freitag, ? lässt den Monatstag offen. Der Startzeitpunkt ist ausgeschlossen. Das Beispiel lässt sich mit einem Kalender unabhängig vom heutigen Datum prüfen.
Ergänze zwei Fälle. cron(0/15 * * * ? *) liefert nach 10:00 UTC 10:15, 10:30 und 10:45; es ist ein Kalendermuster, kein Timer ab Bereitstellung. cron(0 8 1 * ? *) liefert nach 2026-07-01T08:00:00Z den 1. August, September und Oktober um 08:00 UTC. Feste Erwartungen machen Fehler sichtbar.
Den Zeitplan in einer festen Reihenfolge prüfen
Wähle zuerst den Dienst. Scheduler erlaubt eine IANA-Zone; ältere Regeln verwenden UTC. Gib Minute, Stunde, Monatstag, Monat, Wochentag und Jahr ein. Setze ? in genau ein Tagesfeld, berechne und prüfe mehrere Treffer über Monatsgrenzen. Vergleiche Ortszeit, Offset und UTC-Zeitpunkt. Kopiere cron(...) erst, wenn die Vorschau der Anforderung entspricht. Ziel, Ausführungsrolle, flexibles Fenster, Wiederholungen und Fehlerziel konfigurierst du getrennt in AWS.
Teste Spezialtage einzeln. Nach 2026-08-01T00:00:00Z wählt cron(0 9 1W * ? *) Montag, den 3. August: Der 1. ist Samstag und der nächstgelegene Tag von Montag bis Freitag bleibt im August. Für cron(0 9 ? * TUE#2 *) sind die nächsten Termine der 11. August, 8. September und 13. Oktober. Listen mehrerer #-Regeln werden nicht akzeptiert.
Sechs Felder und Tagesoperatoren verstehen
Unix-Cron hat meist fünf Felder und kombiniert Tagesfelder nach der jeweiligen Implementierung. AWS verlangt sechs Felder und endet mit einem Jahr von 1970 bis 2199. Monats- und Tagesnamen sind erlaubt. Beim Monatstag bedeutet L den letzten Kalendertag und nW den nächstgelegenen Tag von Montag bis Freitag zum angegebenen Monatstag. Beim Wochentag bedeutet ein alleinstehendes L Samstag, nL den letzten benannten Wochentag und n#k dessen k-tes Auftreten. Mehrdeutige Kombinationen werden abgelehnt.
Lies jedes Feld als Wertemenge. Der Schrägstrich bestimmt Schritte im Feld, kein verstrichenes Intervall. Der Stundenbereich 20-2 umfasst Abend und frühen Morgen. Namen erleichtern Reviews; die Kopie normalisiert Großschreibung. L beim Monatstag ist der letzte Tag, 6L der letzte Freitag. LW, L-Offsets und Spezialoperator-Listen gehören nicht zur unterstützten Teilmenge.
Plausible, aber falsche Ausdrücke erkennen
Ein schwerer Fehler ist, fünf Unix-Felder zu kopieren und nach Gefühl eines hinzuzufügen. Übersetze stattdessen die Anforderung. Ein weiterer Fehler sind Regeln in beiden Tagesfeldern: AWS verlangt in einem Feld ?. Listen mit mehreren #-Ausdrücken sind ebenfalls ungültig. Ein leeres Ergebnis bedeutet nicht immer fehlerhafte Syntax. Die Vorschau sucht fünf Jahre; ein gültiger Ausdruck für 2199 liefert ab 2026 noch keine Termine.
Vereinfache bei Überraschungen: Ersetze das Jahr durch *, verwende UTC und tausche den Spezialtag vorübergehend gegen einen einfachen Wert. Stelle Einschränkungen einzeln wieder her. Prüfe, ob der Start ausgeschlossen ist, das Jahr in den nächsten fünf liegt und ? genau einmal vorkommt. So unterscheidest du Horizontgrenzen von Feld- oder Zonenfehlern.
Zone, Zeitumstellung und Genauigkeit trennen
Scheduler wertet die Ortszeit der gewählten Zone aus. Fehlt eine Uhrzeit beim Sprung im Frühjahr, wird dieses Vorkommen übersprungen. In der wiederholten Herbststunde erfolgt nur ein Aufruf. Ältere Regeln bleiben in UTC; ihre Beziehung zu einer Stadtzeit ändert sich saisonal. AWS dokumentiert Minutengenauigkeit: 10:15 verspricht keine bestimmte Millisekunde. Flexible Zeitfenster und Zustellung sind eigene Einstellungen.
Teste für Madrid cron(30 2 * * ? *) mit Scheduler. Am 29. März 2026 existiert 02:30 nicht und wird übersprungen. Am 25. Oktober kommt 02:30 zweimal vor; Scheduler ruft beim ersten Mal einmal auf. Als Legacy-Regel besitzt UTC weder Lücke noch Falte; die Madrider Anzeige wechselt mit dem saisonalen Offset.
Grenzen einer lokalen Vorschau kennen
Diese Seite simuliert einen Kalender und testet keine AWS-Bereitstellung. Sie akzeptiert 256 Zeichen, liefert bis zu zehn Treffer und endet nach fünf Jahren. IAM-Rechte, Zielnutzlast, Quoten, Wiederholungen, Latenz, Verfügbarkeit und Idempotenz kann sie nicht prüfen. Die angezeigten Zeitpunkte sind erwartete Kalendertreffer, kein Beweis dafür, dass AWS eine Ressource angenommen oder ein Ziel ein Ereignis erhalten hat.
AWS dokumentiert 60-Sekunden-Genauigkeit. Eine Zeile 10:15 bezeichnet die Minute und garantiert keine Latenz. Scheduler kann außerdem ein flexibles Zeitfenster nutzen und Zustellung wiederholen; das Werkzeug modelliert dies nicht. Bei strengen Anforderungen muss das Ziel idempotent sein. Beobachte echte Aufrufprotokolle, statt Vorschauzeilen als Ausführungen zu behandeln.
Nachweise zusammen mit dem Ausdruck sichern
Bewahre Ausdruck, Dienst, Zone, Referenzzeitpunkt und erwartete Termine im Review auf. Prüfe eine normale Woche, eine Monatsgrenze, den Spezialoperator und bei Ortszeit eine Zeitumstellung. Kontrolliere das Jahr. Bestätige in Konsole oder Infrastructure as Code Ausdruck und Zone, teste das Ziel und beobachte Metriken. Verlinke bei einer Migration den Unix-Cron-Leitfaden, damit der Dialektwechsel sichtbar bleibt.
Vor dem Aktivieren sollte eine zweite Person die ersten drei Termine herleiten. Prüfe für W einen Monat mit Wochenende am Ersten, für # oder L einen Monat mit fünf Kandidaten und bei Ortszeit eine Umstellung. Stelle sicher, dass Infrastructure as Code die Zone übernimmt. Teste nach der Bereitstellung ein harmloses Ziel, kontrolliere Metriken und Fehlerziel und dokumentiere die Rücknahme.
Ein abschließendes Review trennt drei Uhren: die im Ausdruck notierte Zeit, die von Scheduler interpretierte Ortszeit und den protokollierten UTC-Zeitpunkt. Bei einer Legacy-Regel zählen nur der UTC-Ausdruck und seine spätere lokale Darstellung. Nutzt das Team Namen wie MON oder JAN, bewahre zusätzlich die Anforderung in Alltagssprache auf; bei Zahlen dokumentierst du ihre Zuordnung. Wiederhole den Test nach Änderungen an Zone oder Jahresbereich, denn beide verändern die Ergebnismenge, ohne Minute und Stunde ändern zu müssen.
Prüfe außerdem kurze Monate und Randlagen. Eine Regel für den 31. hat nicht jeden Monat einen Treffer. Bei 1W darf der Ausweichtermin den Monat nicht verlassen; beim August 2026 führt der Samstag am Ersten deshalb zum Montag am Dritten. Bei # muss klar sein, ob der zweite oder etwa der fünfte Wochentag gemeint ist und ob dieses Auftreten im jeweiligen Monat existiert. Vergleiche solche Fälle mit einem Kalender, bevor du die technische Vorschau als Abnahme verwendest.
Trenne schließlich Kalenderprüfung und Betrieb. Im Infrastruktur-Review gehören Ausdruck, Zone, Diensttyp, Ziel, Rolle, Wiederholungen und Fehlerziel in verschiedene prüfbare Felder. Ein korrekt berechneter Termin sagt nichts über fehlende Berechtigungen oder einen fehlerhaften Payload aus. Nach dem Anlegen sollte ein ungefährliches Testziel die Verbindung bestätigen. Danach liefern AWS-Metriken und Anwendungsprotokolle den Nachweis, den eine lokale Vorschau grundsätzlich nicht erbringen kann.
Bewahre außerdem die exakt zu kopierende Fassung auf. Die Klammern von cron(...) und die Großschreibung der Namen machen den Dialekt im Textreview eindeutig. Kontrolliere den exklusiven Startzeitpunkt: Ein Treffer genau zu diesem Zeitpunkt erscheint nicht als nächster Termin. So wird ein Sprung zur nächsten zulässigen Minute oder zum nächsten Tag nicht fälschlich als Fehler bewertet. Halte bei jeder Änderung fest, welche drei erwarteten Termine sich ändern dürfen und welche unverändert bleiben müssen.
Quellen: Zeitplantypen von AWS EventBridge Scheduler und Muster für geplante AWS-EventBridge-Regeln.