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: 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.
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.
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.
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’.
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'.
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..
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.