Authentication for reactor rules for AWS (Reactor Events for Lambda functions; Reactor Firehose for AWS SQS and Kinesis)

When adding a Reactor rule for an AWS endpoint (e.g. a Reactor Events rule for an AWS Lambda function, or a Reactor Firehose rule for AWS Kinesis or AWS SQS), you can choose one of two ways to authenticate Ably to invoke your function or publish to your kinesis stream:


  1. Credentials
  2. ARN of an assumable role


1. Credentials


These are a set of AWS credentials (in AWS terminology, an 'access key id' and a 'secret access key') of an AWS IAM user which has permissions to invoke your function, publish to your AWS SQS queue or AWS Kinesis stream, etc.


This is the simplest, least error-prone way, and is recommended for most people. If you're not sure which way to use, use credentials.


2. ARN of an assumable role


This way lets you delegate access to resources on your account using an IAM role that Ably can assume, avoiding the need to share user credentials with Ably. See .


To do this, create an IAM role with a trust policy specifying the root ARN of account 203461409171 as the Principal, and an externalId condition that will be shown in the rule creation dialogue once you select this authentication method (which is a function of your account ID and app ID, so will be the same for all rules made in a particular app).


"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Principal": {
"AWS": "arn:aws:iam::203461409171:root"
"Condition": {"StringEquals": {"sts:ExternalId": "<accountID>.<appId>"}}


and give that role permissions to invoke your function, publish to your AWS Kinesis stream or AWS SQS Queue, etc.


(While setting up permissions, please note that Ably will generally use the batch version of the action where relevant; e.g. for AWS SQS we use the `SendMessageBatch` action, not the `SendMessage` action)