Types Of Trigger Node

Trigger types lets you configure the workflow start time. You can either schedule or set up a recurrent trigger. There are following trigger types:

  • Schedule

  • HTTP

  • Alarm

  • Events

The Trigger Node is the first node of any workflow and cannot be deleted

  1. Schedule: Initiates a workflow based on time. You can perform the following configurations in the Time trigger type.

  • Schedule: It triggers the workflow on a specific day of the week, at a specific time. If you want a workflow to start everyday at a specific time, you must select all the days of the week. This trigger is suitable for CRON jobs, Ops tasks, DR tasks, periodic auditing tasks, etc.

You can select Monday from the Day drop down menu, and 9:10 am from the Time drop down menu, your workflow will start every Monday at 9:10 am

  • Recurrent: It triggers the workflow at periodic intervals. This trigger is suitable for workflows invoking Lambda functions, Ops , or monitoring tasks. For example,

    • Trigger the workflow every hour

    • Trigger the workflow every day

    • Trigger the workflow every week

  • Cron: This trigger type triggers the workflow according to a "CRON expression.” With this, you have the flexibility to fine-tune the schedule according to your requirements. This trigger is suitable for a detailed schedule control that a normal Schedule trigger cannot fulfill.

The Cron expression used here should conform with AWS Cron requirements by omitting the 'seconds' part. Read more about this here.

All times are in UTC

2. HTTP: This trigger helps initiate a workflow by using an HTTPS endpoint URL. Each workflow has a unique HTTPS endpoint that can be used to trigger the workflow by calling it manually, using a web hook or using a script.

The endpoint URL to trigger the workflow becomes available only after you save the workflow.

It is also possible to pass data into a workflow via the HTTP node. This data is available for use in the workflow as Trigger node payload.

3. Alarm: An alarm trigger can trigger a workflow in response to a CloudWatch alarm in your AWS cloud. Alarm trigger executes the workflow when a specified CloudWatch alarm changes its state to ‘ALARM’.

To use the Alarms trigger, you must first enable it in the Accounts page and adopt and run a workflow template to configure your AWS EventBridge. More on that here.

The Alarm trigger lets you configure the type of alarms to react to. The following are the parameters;

  • Metric Namespace: The service for which the alarm is raised. Example: EC2, EBS, etc..

  • Metric Name: The metric associated with the alarm. Example: CPUUtilization, DiskReadOps, etc..

  • Statistic (Optional): The statistic associated with the alarm. Example: Average, SampleCount, etc..

  • Dimension (Optional): The dimension of the alarm. Set this field to listen to a particular alarm. Multiple dimensions can be added to improve the particularity. Example: InstanceId, InstanceType, etc..

The alarm trigger node can capture the data associated with the alert to be utilized by the workflow. You need to enable the HTTP Trigger for this. Once enabled, the trigger payload will capture the alarm information. This data can be used in the workflow to target the resource the alarm is associated with.

4. Events: The event trigger can trigger a workflow in response to an event in your AWS cloud. These AWS events could be generated when you perform some action in the AWS cloud (CloudTrail events), such as creating an instance, attaching a policy to an IAM role, etc.. or could be generated as a result of a change in a resource such as, change of state of an EC2 instance from 'stopping' to 'stopped'.

Configuration of the event trigger must be carefully thought out as it is possible for an event-workflow loop to be executed infinitely. For example, If you set a Lambda event as a trigger and then simultaneously perform an action on a Lambda function in the same workflow that can generate the same event, it could end up in an event-workflow loop. This should be avoided at all costs as they could increase your expenditure considerably.

To use the Events trigger, you must first enable it in the Accounts page and adopt and run a workflow template to configure your AWS EventBridge. More on that here.

The Events trigger lets you configure the events to react to. The following are the parameters;

  • Service: The service associated with the event. Example: EC2, S3, etc..

  • Resource: The kind of event to listen to. Example: Api, State Change, etc..

  • Event Type: The type of event to listen to. Example: Aws Event, CloudTrail Event, etc..

  • Events: The specific events to listen to: Example: createSnapshot, stopped, etc..

It is possible to listen to all events of a service by setting 'All Events' for Resource and 'Events'

The JSON pattern on the right side of the Event trigger customization pane, lets you enter any particular configuration information. This is usually used in edge cases where you need to listen to events that are related to a particular resource. For example, if you need to listen to events related to a particular EBS snapshot, you can enter the id of that snapshot in the pattern.

For usage examples of Trigger node, click here.