Introduction

Yes, CloudFormation can define a scheduled AWS Glue trigger that is created in an active state. The key resource is AWS::Glue::Trigger, and the important property for activation is StartOnCreation: true when the trigger type is SCHEDULED.

The Core Resource Shape

A scheduled Glue trigger in CloudFormation needs:

• a Glue job to run
• a trigger of type SCHEDULED
• a schedule expression
• one or more actions
• 'StartOnCreation: true if you want it activated immediately'

Here is a minimal YAML example:

1Resources:
2  MyGlueJob:
3    Type: AWS::Glue::Job
4    Properties:
5      Name: my-daily-job
6      Role: !GetAtt GlueRole.Arn
7      Command:
8        Name: glueetl
9        ScriptLocation: s3://my-bucket/scripts/job.py
10      GlueVersion: "4.0"
11
12  MyScheduledTrigger:
13    Type: AWS::Glue::Trigger
14    Properties:
15      Name: my-daily-trigger
16      Type: SCHEDULED
17      Schedule: cron(0 6 * * ? *)
18      StartOnCreation: true
19      Actions:
20        - JobName: !Ref MyGlueJob

This creates a trigger that runs the job every day at the scheduled time and starts in the activated state.

What StartOnCreation Actually Does

Without StartOnCreation: true, the trigger can be created but remain inactive until you start it manually. That is often the missing detail when people say "the trigger exists, but it is not activated."

So the operational distinction is:

• resource exists
• trigger is enabled and ready to fire

CloudFormation can handle both, but you need to declare the second state explicitly.

Schedule Syntax

Glue scheduled triggers use a cron-style expression in AWS format:

Schedule: cron(0 12 * * ? *)

That example runs once per day at 12:00 UTC. The time zone behavior is important because teams often expect local time while AWS services interpret the cron expression in UTC unless another service layer changes that behavior.

Always validate the expression operationally, not just syntactically.

Multiple Actions

A trigger can launch more than one job action:

Actions:
  - JobName: !Ref FirstGlueJob
  - JobName: !Ref SecondGlueJob

That is useful for small coordinated workflows, although more complex dependencies are often better modeled with Glue workflows or other orchestration services.

Full Example with Role

1Resources:
2  GlueRole:
3    Type: AWS::IAM::Role
4    Properties:
5      AssumeRolePolicyDocument:
6        Version: "2012-10-17"
7        Statement:
8          - Effect: Allow
9            Principal:
10              Service: glue.amazonaws.com
11            Action: sts:AssumeRole
12      ManagedPolicyArns:
13        - arn:aws:iam::aws:policy/service-role/AWSGlueServiceRole
14
15  DailyJob:
16    Type: AWS::Glue::Job
17    Properties:
18      Name: daily-etl
19      Role: !GetAtt GlueRole.Arn
20      Command:
21        Name: glueetl
22        ScriptLocation: s3://my-bucket/glue/daily.py
23
24  DailyTrigger:
25    Type: AWS::Glue::Trigger
26    Properties:
27      Name: daily-etl-trigger
28      Type: SCHEDULED
29      Schedule: cron(30 1 * * ? *)
30      StartOnCreation: true
31      Actions:
32        - JobName: !Ref DailyJob

The Glue job still needs all the usual prerequisites such as the IAM role, script location, and access to its data sources.

Operational Checks After Deployment

After the stack is created, verify:

• the trigger exists
• the trigger state is activated
• the cron expression is what you intended
• the job role has enough permissions

A trigger that is perfectly defined in CloudFormation can still fail at runtime if the job script or IAM policy is wrong.

When You Might Not Want Immediate Activation

Sometimes StartOnCreation: true is not desirable. For example:

• you want the stack created before the schedule begins
• upstream datasets are not ready
• the job should be activated in a later release step

In those cases, create the trigger without automatic activation and start it intentionally afterward.

Common Pitfalls

• Creating AWS::Glue::Trigger without StartOnCreation: true and assuming the trigger will be active automatically.
• Using an invalid or unintended cron expression, especially when local time and UTC expectations differ.
• Defining the trigger correctly but forgetting that the referenced Glue job still needs a valid IAM role and script location.
• Assuming scheduled triggers are the right orchestration tool for every workflow, even when dependencies would be clearer in Glue workflows or Step Functions.
• Verifying only stack creation success instead of checking the runtime trigger state in Glue after deployment.

Summary

• CloudFormation can define an activated scheduled Glue trigger with AWS::Glue::Trigger.
• Use Type: SCHEDULED, provide a Schedule, and set StartOnCreation: true.
• The trigger only works if the referenced Glue job is correctly defined and permitted.
• Cron timing should be checked carefully because schedule interpretation matters operationally.
• A created trigger and an activated trigger are not the same thing; declare the state you want.