AWSのcron式で一週目の曜日指定する場合は時差による曜日跨ぎに注意しよう
2025.04.11初めに
AWSでログに記録される時刻、メンテナンスウィンドウ等時刻を取り扱う設定に関して、多くの場所は標準でUTCとなっておりタイムゾーン自体の変更ができない設定も多くあります。
RDSのタイムゾーンに関するre:Postの投稿では夏時間(サマータイム)の影響を避けるためにUTCをベストプラクティスという回答がAWS公式よりされています。
サマータイムに関してはJSTは考慮不要とはなりますが、取り扱いを一貫させるためにJSTを設定可能であってもAWSレイヤーではUTCを採用するというのは多いのではないかと思います。
多くの場合現地時間を使わずUTC基準で問題が起きることは思いますが、以前AWS Backupでスケジューラ設計していた際にあれ？UTCのままでは対応できないのでは？となったので備忘録として残しておきます。
本質はcron式の指定と時差の問題ですのでEvenbBridgeやSystems Manager等のサービスで発生するので注意しましょう。
cron式の曜日指定実行
AWSで利用されるcron式ですが1-7(SAN-SAT)指定といった曜日指定で実行することが可能です。
また本家?(Linux等で利用される)cronにない仕様としてこの曜日指定数値の後に#nをその後につけることで第n月曜日に実行ということが可能です。
さて曜日指定をする場合ですが、タイムゾーンの違いにより日付を跨ぐ場合は当然曜日もそれを考慮してずらす必要があります。
JSTの月曜日のAM 01:00(cron(0 17 ? * MON *))に実行したいとなった場合、UTC基準のcron式では日曜日のPM 17:00(cron(0 17 ? * SUN *))に実行するよう指定する必要があります。
これは問題なさそうです。
今度は第一月曜日のAM01:00に実行したいとなった場合のJST->UTC変換を考えてみましょう。
JST基準ではcron(0 1 ? * MON#1 *)となりますがAM01:00で9時間前...1日戻るから1つ前の曜日...月曜日の前は日曜日だからcron(0 17 ? * SUN#1 *)でしょうか？
さてこれでもうまく動き...あれ？1日(月)の9時間前っていつでしょうか？
第一(X-1)曜日は必ず1日前にあるわけではない
そうです。この場合1日前は第一日曜日ではなく、前月の最終日曜日です。
毎週特定の曜日に動かす場合は問題が出ず、また第一・最終X曜日以外に動かす場合は指定日の1日前後が同じ月に存在するので問題ないのですが、第一X曜日もしくは最終X曜日とした場合に限りその前後が同じ月に存在しないため問題が出ます。
2025/09でUTC基準でcron(0 1 ? * SUN#1 *)とした場合この場合第一日曜日は9/6となるため、実際に動くのは第二月曜日である9/7となります。
JSTの場合地理的に進める方向に考慮することはほぼないかと思いますが、当然進める方向に考慮が必要なタイムゾーンの場合逆に月末最終日で跨ぐ可能性がありますので#4を指定する場合なども同様に注意しましょう。
素直に利用するタイムゾーンを変更しよう
cron(0 17 L * SUN *)及びcron(0 17 2-31 * SUN#1 *)と定義し、UTC基準で「月末最終日かつ月末日曜日」及び「第一日曜日かつ2~31日(第一日曜日が1日以外)」とできればUTCのままでできそうではありますが、残念ならがこういった複合条件的な記載はEventBridgeのcron式では対応していません。
cron 式の日フィールドと曜日フィールドを同時に指定することはできません。一方のフィールドに値または * (アスタリスク) を指定する場合、もう一方のフィールドで ? (疑問符) を使用する必要があります。
現状UTCのままでこれを回避する方法はないので素直にタイムゾーンを実際に動かす環境に合わせる形で対応しましょう。
終わりに
特定の条件の時のみ時差による曜日ずれで発生する問題といったちょっとしたTips的な紹介となりました。
毎月必ず発生する問題ではなく条件的に発生する内容という関係で意識できていないと後で発覚する部分ではありますので意識できていなかった方はぜひ頭の片隅に置いていただけますと幸いです。
