Amazon Web Services

Amazon Web Services (AWS) offer a variety of cloud-based services, including computing, storage, databases, and more. Unlike many other services, AWS products often go beyond data, providing additional functionality for end users. Through Skuid’s DSTs, you can utilize this additional functionality within your Skuid pages.


The AWS data source types are currently exclusive to Skuid Platform.

Configure an Amazon Authentication Provider

In Amazon

Before configuring data sources within Skuid, you’ll need decide how you’ll be authenticating to your AWS services.


The examples listed for the individual AWS products assume the end user has full access, but Skuid adheres to any policies associated with the AWS access credentials provided to it.

Assume Role [[]]


This is currently Skuid Platform exclusive.

This authentication method allows you to use the ARN of an assumable role instead of hard-coded AWS access keys. Due to this method’s security and ease-of-management after initial setup, we typically recommend it over the access keys method.

When a Skuid user makes a request to access a data source using this authentication method, Skuid will make a secure server-side request to assume the configured role. If this request is successful, Skuid will receive temporary access credentials, which Skuid will cache until the credentials expire after 60 minutes. Each request to assume a role is traceable from the AWS console to the Skuid site and Skuid user who initiated the request, so that as an AWS administrator you have full visibility into who requested access credentials, and when.

Skuid can only access roles with skuid-assumable-role/ within the role name.

To utilize this authentication method:


  1. Create an IAM role with skuid-assumable-role/ in the name that has access to the things you need.

    For example, the following ARN will work:


    The following will not:


  2. Copy the Role’s ARN.

In Skuid

  1. Create a new authentication provider.
  2. Paste the AWS Role ARN in the AWS Role ARN to Assume field.
  3. Save the authentication provider.

After saving your authentication provider, you’ll be presented with a trust relationship policy, which is the final thing you need to apply to the IAM role so Skuid can assume it. Your AWS IAM Role will need to have a Trust Relationship configured so that your Skuid site is allowed to assume the role, while other Skuid sites _cannot_ assume the role—even if the role’s ARN were available.

  1. Copy the policy JSON by clicking the link beneath the policy, or selecting and copying it manually.
  2. Return to the role configuration screen and paste the copied policy into the role’s trust relationship policy editor.


If you want this role to be assumable by multiple Skuid sites—for example a staging site and a production site, make the sts:ExternalId property’s value into an array of Skuid site Ids.

For example, change this key/value:

"sts:ExternalId": "09583eba-de0e-49d3-ae42-61b3927a61b1"

Into this:

"sts:ExternalId": [

Site IDs are accessible from Settings > Site > Profile.


  • AWS Role ARN to Assume: The IAM role ARN to assume when using the data source.

Access Keys [[]]


This is currently Skuid Platform exclusive.

This authentication method utilizes an Amazon Web Service (AWS) IAM role’s access keys to authenticate to an AWS system.

If you are not the manager of your AWS services, follow along with Amazon’s steps for creating access keys with your IT administrator. You’ll need to do the following:


  • Create a new group and select the appropriate policies for that group.
    • These should align with your intended Skuid use. Ensure your access policies match the services (S3, DynamoDB, or SNS) you’ll be using.
  • Create a new user in AWS Identity and Access Management (IAM) within the newly created group.
  • Retrieve the access credentials generated for that user:
    • The secret access is displayed once, immediately after the access key is generated, and cannot be found later. Be sure to copy it to a safe place.


  • AWS Access Key Id: The access key ID to use when authenticating.
  • AWS Secret Access Key: The secret access key to use when authenticating.

In Skuid

Create an authentication provider

With your access credentials handy, you can now use them to configure a Skuid authentication provider that will work with all AWS data sources.

  1. Navigate to Configure > Data Sources > Authentication Providers.
  2. Click New Authentication Provider.
  3. Enter a name, such as AWSAuth.
  4. Under Authentication Method, select the authentication method that best fits your use case.
  5. Enter the information needed for your chosen authentication method, as noted above.
  6. Click Save.

Configure an Amazon Data Source

The creation process for each Amazon data source is similar for each service. Insert the appropriate data source type name where appropriate.

  1. Navigate to Configure > Data Sources > Data Sources..
  2. Click New Data Source.
  3. Select the data source type for the Amazon service.
  4. Enter an appropriate name for the service, such as AWS-ServiceName.
  5. Click Next Step.
  6. Select the authentication provider you configured in the Amazon authentication provider section.
  7. Configure your AWS Connection Details:
    • AWS Region: Select the region where the resources you want to work with within Skuid reside. See AWS documentation on regions for more information.
    • AWS API Version: The API version for this service (formatted as a date). For most use cases, you may leave this field blank as Skuid uses preferred default API versions.
  8. Click Save.

AWS Access Permissions

When using AWS APIs, it is best practice to utilize strict and well-defined IAM policies so end users can only perform actions they have explicit access to.

Listed below are the permissions Skuid’s AWS data source types require to properly function. Use this list to better define your IAM roles.


  • listTables
  • describeTable
  • scan
  • query
  • putItem
  • updateItem
  • deleteItem


  • lambda:ListFunctions
  • lambda:InvokeFunction


Skuid utilizes both the LexRuntime and LexModelBuildingService SDKs.

  • postContent
  • getBot
  • getIntent


  • synthesizeSpeech


  • listBuckets
  • listObjects
  • deleteObject
  • putObject
  • getObject


  • ses:SendEmail


  • listTopics
  • listSubscriptionsByTopic
  • listSubscriptions
  • createTopic
  • deleteTopic
  • publish
  • subscribe
  • unsubscribe