

After careful consideration, we have decided to discontinue Amazon Kinesis Data Analytics for SQL applications:

1. From **September 1, 2025**, we won't provide any bug fixes for Amazon Kinesis Data Analytics for SQL applications because we will have limited support for it, given the upcoming discontinuation.

2. From **October 15, 2025**, you will not be able to create new Kinesis Data Analytics for SQL applications.

3. We will delete your applications starting **January 27, 2026**. You will not be able to start or operate your Amazon Kinesis Data Analytics for SQL applications. Support will no longer be available for Amazon Kinesis Data Analytics for SQL from that time. For more information, see [Amazon Kinesis Data Analytics for SQL Applications discontinuation](discontinuation.md).

# Authentication and Access Control for
<a name="authentication-and-access-control"></a>

Access to requires credentials. Those credentials must have permissions to access AWS resources, such as an application or an Amazon Elastic Compute Cloud (Amazon EC2) instance. The following sections provide details on how you can use [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) and to help secure access to your resources. 

## Access Control
<a name="access-control"></a>

You can have valid credentials to authenticate your requests, but unless you have permissions you cannot create or access resources. For example, you must have permissions to create an application.

The following sections describe how to manage permissions for . We recommend that you read the overview first.
+ [Overview of Managing Access Permissions to Your Resources](access-control-overview.md)
+ [Using Identity-Based Policies (IAM Policies) for](using-identity-based-policies.md)
+ [API Permissions: Actions, Permissions, and Resources Reference](api-permissions-reference.md)

## Authenticating with identities
<a name="security_iam_authentication"></a>

Authentication is how you sign in to AWS using your identity credentials. You must be authenticated as the AWS account root user, an IAM user, or by assuming an IAM role.

You can sign in as a federated identity using credentials from an identity source like AWS IAM Identity Center (IAM Identity Center), single sign-on authentication, or Google/Facebook credentials. For more information about signing in, see [How to sign in to your AWS account](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*.

For programmatic access, AWS provides an SDK and CLI to cryptographically sign requests. For more information, see [AWS Signature Version 4 for API requests](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) in the *IAM User Guide*.

### AWS account root user
<a name="security_iam_authentication-rootuser"></a>

 When you create an AWS account, you begin with one sign-in identity called the AWS account *root user* that has complete access to all AWS services and resources. We strongly recommend that you don't use the root user for everyday tasks. For tasks that require root user credentials, see [Tasks that require root user credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) in the *IAM User Guide*. 

### Federated identity
<a name="security_iam_authentication-federated"></a>

As a best practice, require human users to use federation with an identity provider to access AWS services using temporary credentials.

A *federated identity* is a user from your enterprise directory, web identity provider, or Directory Service that accesses AWS services using credentials from an identity source. Federated identities assume roles that provide temporary credentials.

For centralized access management, we recommend AWS IAM Identity Center. For more information, see [What is IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) in the *AWS IAM Identity Center User Guide*.

### IAM users and groups
<a name="security_iam_authentication-iamuser"></a>

An *[IAM user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* is an identity with specific permissions for a single person or application. We recommend using temporary credentials instead of IAM users with long-term credentials. For more information, see [Require human users to use federation with an identity provider to access AWS using temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) in the *IAM User Guide*.

An [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) specifies a collection of IAM users and makes permissions easier to manage for large sets of users. For more information, see [Use cases for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) in the *IAM User Guide*.

### IAM roles
<a name="security_iam_authentication-iamrole"></a>

An *[IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* is an identity with specific permissions that provides temporary credentials. You can assume a role by [switching from a user to an IAM role (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) or by calling an AWS CLI or AWS API operation. For more information, see [Methods to assume a role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) in the *IAM User Guide*.

IAM roles are useful for federated user access, temporary IAM user permissions, cross-account access, cross-service access, and applications running on Amazon EC2. For more information, see [Cross account resource access in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) in the *IAM User Guide*.

# Overview of Managing Access Permissions to Your Resources
<a name="access-control-overview"></a>

**Warning**  
For new projects, we recommend that you use the new Managed Service for Apache Flink Studio over for SQL Applications. Managed Service for Apache Flink Studio combines ease of use with advanced analytical capabilities, enabling you to build sophisticated stream processing applications in minutes.

To provide access, add permissions to your users, groups, or roles:
+ Users and groups in AWS IAM Identity Center:

  Create a permission set. Follow the instructions in [Create a permission set](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html) in the *AWS IAM Identity Center User Guide*.
+ Users managed in IAM through an identity provider:

  Create a role for identity federation. Follow the instructions in [Create a role for a third-party identity provider (federation)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html) in the *IAM User Guide*.
+ IAM users:
  + Create a role that your user can assume. Follow the instructions in [Create a role for an IAM user](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-user.html) in the *IAM User Guide*.
  + (Not recommended) Attach a policy directly to a user or add a user to a user group. Follow the instructions in [Adding permissions to a user (console)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) in the *IAM User Guide*.

**Note**  
An *account administrator* (or administrator user) is a user with administrator privileges. For more information, see [IAM Best Practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) in the *IAM User Guide*.

**Topics**
+ [Resources and Operations](#access-control-resources)
+ [Understanding Resource Ownership](#access-control-resource-ownership)
+ [Managing Access to Resources](#manage-access-overview)
+ [Specifying Policy Elements: Actions, Effects, and Principals](#specify-policy-elements)
+ [Specifying Conditions in a Policy](#specifying-conditions-overview)

## Resources and Operations
<a name="access-control-resources"></a>

In , the primary resource is *an application*. In a policy, you use an Amazon Resource Name (ARN) to identify the resource that the policy applies to.

These resources have unique Amazon Resource Names (ARNs) associated with them, as shown in the following table. 


****  

| Resource Type | ARN Format | 
| --- | --- | 
| Application |  `arn:aws:kinesisanalytics:region:account-id:application/application-name`  | 

 provides a set of operations to work with resources. For a list of available operations, see [Actions](API_Operations.md).

## Understanding Resource Ownership
<a name="access-control-resource-ownership"></a>

The AWS account owns the resources that are created in the account, regardless of who created the resources. Specifically, the resource owner is the AWS account of the [principal entity](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html) (that is, the root account, a user, or an IAM role) that authenticates the resource creation request. The following examples illustrate how this works:
+ If you use the root account credentials of your AWS account to create an application, your AWS account is the owner of the resource. (In , the resource is an application.)
+ If you create a user in your AWS account and grant permissions to create an application to that user, the user can create an application. However, your AWS account, to which the user belongs, owns the application resource. We strongly recommend you grant permissions to roles and not users.
+ If you create an IAM role in your AWS account with permissions to create an application, anyone who can assume the role can create an application. Your AWS account, to which the user belongs, owns the application resource. 

## Managing Access to Resources
<a name="manage-access-overview"></a>

A *permissions policy* describes who has access to what. The following section explains the available options for creating permissions policies.

**Note**  
This section discusses using IAM in the context of . It doesn't provide detailed information about the IAM service. For complete IAM documentation, see [What Is IAM?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) in the *IAM User Guide*. For information about IAM policy syntax and descriptions, see [IAM JSON Policy Reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html) in the *IAM User Guide*.

Policies that are attached to an IAM identity are referred to as *identity-based* policies (IAM policies). Policies that are attached to a resource are referred to as *resource-based* policies. supports only identity-based policies (IAM policies). 

**Topics**
+ [Identity-Based Policies (IAM Policies)](#manage-access-iam-policies)
+ [Resource-Based Policies](#manage-access-resource-policies)

### Identity-Based Policies (IAM Policies)
<a name="manage-access-iam-policies"></a>

You can attach policies to IAM identities. For example, you can do the following:
+ **Attach a permissions policy to a user or a group in your account** – To grant a user permissions to create an resource, such as an application, you can attach a permissions policy to a user or group that the user belongs to.
+ **Attach a permissions policy to a role (grant cross-account permissions)** – You can attach an identity-based permissions policy to an IAM role to grant cross-account permissions. For example, the administrator in account A can create a role to grant cross-account permissions to another AWS account (for example, account B) or an Amazon service as follows:

  1. Account A administrator creates an IAM role and attaches a permissions policy to the role that grants permissions on resources in account A.

  1. Account A administrator attaches a trust policy to the role identifying account B as the principal who can assume the role. 

  1. Account B administrator can then delegate permissions to assume the role to any users in account B. Doing this allows users in account B to create or access resources in account A. The principal in the trust policy can also be an Amazon service principal if you want to grant an Amazon service permissions to assume the role.

  For more information about using IAM to delegate permissions, see [Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html) in the *IAM User Guide*.

The following is an example policy that grants permission for the `kinesisanalytics:CreateApplication `action, which is required to create an application.

**Note**  
This is an introductory example policy. When you attach the policy to the user, the user will be able to create an application using the AWS CLI or AWS SDK. But the user will need more permissions to configure input and output. In addition, the user will need more permissions when using the console. The later sections provide more information.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "Stmt1473028104000",
            "Effect": "Allow",
            "Action": [
                "kinesisanalytics:CreateApplication"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}
```

------

For more information about using identity-based policies with , see [Using Identity-Based Policies (IAM Policies) for](using-identity-based-policies.md). For more information about users, groups, roles, and permissions, see [Identities (Users, Groups, and Roles)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html) in the *IAM User Guide*. 

### Resource-Based Policies
<a name="manage-access-resource-policies"></a>

Other services, such as Amazon S3, also support resource-based permissions policies. For example, you can attach a policy to an S3 bucket to manage access permissions to that bucket. doesn't support resource-based policies.

## Specifying Policy Elements: Actions, Effects, and Principals
<a name="specify-policy-elements"></a>

For each resource, the service defines a set of API operations. To grant permissions for these API operations, defines a set of actions that you can specify in a policy. Some API operations can require permissions for more than one action in order to perform the API operation. For more information about resources and API operations, see [Resources and Operations](#access-control-resources) and [Actions](API_Operations.md).

The following are the most basic policy elements:
+ **Resource** – You use an Amazon Resource Name (ARN) to identify the resource that the policy applies to. For more information, see [Resources and Operations](#access-control-resources).
+ **Action** – You use action keywords to identify resource operations that you want to allow or deny. For example, you can use `create` to allow users to create an application.
+ **Effect** – You specify the effect, either allow or deny, when the user requests the specific action. If you don't explicitly grant access to (allow) a resource, access is implicitly denied. You can also explicitly deny access to a resource, which you might do to make sure that a user cannot access it, even if a different policy grants access.
+ **Principal** – In identity-based policies (IAM policies), the user that the policy is attached to is the implicit principal. For resource-based policies, you specify the user, account, service, or other entity that you want to receive permissions (applies to resource-based policies only). doesn't support resource-based policies.

To learn more about IAM policy syntax and descriptions, see [IAM JSON Policy Reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html) in the *IAM User Guide*.

For a table showing all of the API operations and the resources that they apply to, see [API Permissions: Actions, Permissions, and Resources Reference](api-permissions-reference.md).

## Specifying Conditions in a Policy
<a name="specifying-conditions-overview"></a>

When you grant permissions, you can use the access policy language to specify the conditions when a policy should take effect. For example, you might want a policy to be applied only after a specific date. For more information about specifying conditions in a policy language, see [Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Condition) in the *IAM User Guide*.

To express conditions, you use predefined condition keys. There are no condition keys specific to . However, there are AWS-wide condition keys that you can use as appropriate. For a complete list of AWS-wide keys, see [Available Keys for Conditions](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#AvailableKeys) in the *IAM User Guide*.

# Using Identity-Based Policies (IAM Policies) for
<a name="using-identity-based-policies"></a>

The following are examples of identity-based policies that demonstrate how an account administrator can attach permissions policies to IAM identities (that is, users, groups, and roles) and grant permissions to perform operations on resources.

**Important**  
We recommend that you first review the introductory topics that explain the basic concepts and options available to manage access to your resources. For more information, see [Overview of Managing Access Permissions to Your Resources](access-control-overview.md). 

**Topics**
+ [Permissions Required to Use the Console](#console-permissions)
+ [Amazon-Managed (Predefined) Policies for](#access-policy-aws-managed-policies)
+ [Customer Managed Policy Examples](#access-policy-customer-managed-examples)

The following shows an example of a permissions policy.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "Stmt1473028104000",
            "Effect": "Allow",
            "Action": [
                "kinesisanalytics:CreateApplication"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}
```

------

The policy has one statement:
+ The first statement grants permissions for one action (`kinesisanalytics:CreateApplication`) on a resource using the Amazon Resource Name (ARN) for the application. The ARN in this case specifies a wildcard character (\$1) to indicate that the permission is granted for any resource.

For a table showing all of the API operations and the resources that they apply to, see [API Permissions: Actions, Permissions, and Resources Reference](api-permissions-reference.md). 

## Permissions Required to Use the Console
<a name="console-permissions"></a>

For a user to work with the console, you must grant the necessary permissions. For example, if you want a user to have permissions to create an application, grant permissions that show them the streaming sources in the account so that the user can configure input and output on the console.

We recommend the following:
+ Use the Amazon-managed policies to grant user permissions. For available policies, see [Amazon-Managed (Predefined) Policies for](#access-policy-aws-managed-policies).
+ Create custom policies. In this case, we recommend that you review the example provided in this section. For more information, see [Customer Managed Policy Examples](#access-policy-customer-managed-examples).





## Amazon-Managed (Predefined) Policies for
<a name="access-policy-aws-managed-policies"></a>

AWS addresses many common use cases by providing standalone IAM policies that are created and administered by AWS. These Amazon-managed policies grant necessary permissions for common use cases so that you can avoid having to investigate what permissions are needed. For more information, see [Amazon-Managed Policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the *IAM User Guide*. 

The following Amazon-managed policies, which you can attach to users in your account, are specific to :
+ **`AmazonKinesisAnalyticsReadOnly`** – Grants permissions for actions that enable a user to list applications and review input/output configuration. It also grants permissions that allow a user to view a list of Kinesis streams and Firehose delivery streams. As the application is running, the user can view source data and real-time analytics results in the console.

   
+ **`AmazonKinesisAnalyticsFullAccess`** – Grants permissions for all actions and all other permissions that allows a user to create and manage applications. However, note the following:

   
  + These permissions are not sufficient if the user wants to create a new IAM role in the console (these permissions allow the user to select an existing role). If you want the user to be able to create an IAM role in the console, add the `IAMFullAccess` Amazon-managed policy.

     
  + A user must have permission for the `iam:PassRole` action to specify an IAM role when configuring application. This Amazon-managed policy grants permission for the `iam:PassRole` action to the user only on the IAM roles that start with the prefix `service-role/kinesis-analytics`. 

    If the user wants to configure the application with a role that does not have this prefix, you first must explicitly grant the user permission for the `iam:PassRole` action on the specific role. 

You can also create your own custom IAM policies to allow permissions for actions and resources. You can attach these custom policies to the users or groups that require those permissions. 

## Customer Managed Policy Examples
<a name="access-policy-customer-managed-examples"></a>

The examples in this section provide a group of sample policies that you can attach to a user. If you are new to creating policies, we recommend that you first create a user in your account. Then attach the policies to the user in sequence, as outlined in the steps in this section. You can then use the console to verify the effects of each policy as you attach the policy to the user. 

Initially, the user doesn't have permissions and can't do anything on the console. As you attach policies to the user, you can verify that the user can perform various actions on the console. 

We recommend that you use two browser windows. In one window, create the user and grant permissions. In the other, sign in to the AWS Management Console using the user's credentials and verify permissions as you grant them.

 For examples that show how to create an IAM role that you can use as an execution role for your application, see [Creating IAM Roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) in the *IAM User Guide*.

**Topics**
+ [Step 1: Create an IAM User](#console-permissions-createuser)
+ [Step 2: Allow the User Permissions for Actions that Are Not Specific to](#console-permissions-grant-non-ka-permissions)
+ [Step 3: Allow the User to View a List of Applications and View Details](#console-permissions-grant-list-applications)
+ [Step 4: Allow the User to Start a Specific Application](#console-permissions-start-app)
+ [Step 5: Allow the User to Create an Application](#console-permissions-grant-create-applications)
+ [Step 6: Allow the Application to Use Lambda Preprocessing](#console-permissions-grant-lambda)



### Step 1: Create an IAM User
<a name="console-permissions-createuser"></a>

First, you need to create a user, add the user to an IAM group with administrative permissions, and then grant administrative permissions to the user that you created. You can then access AWS using a special URL and that user's credentials. 

For instructions, see [Creating Your First IAM User and Administrators Group](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started_create-admin-group.html) in the *IAM User Guide*. 

### Step 2: Allow the User Permissions for Actions that Are Not Specific to
<a name="console-permissions-grant-non-ka-permissions"></a>

First, grant a user permission for all actions that aren't specific to that the user will need when working with applications. These include permissions for working with streams (Amazon Kinesis Data Streams actions, Amazon Data Firehose actions), and permissions for CloudWatch actions. Attach the following policy to the user.

You need to update the policy by providing an IAM role name for which you want to grant the `iam:PassRole` permission, or specify a wildcard character (\$1) indicating all IAM roles. This is not a secure practice; however you might not have a specific IAM role created during this testing.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "kinesis:CreateStream",
                "kinesis:DeleteStream",
                "kinesis:DescribeStream",
                "kinesis:ListStreams",
                "kinesis:PutRecord",
                "kinesis:PutRecords"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "firehose:DescribeDeliveryStream",
                "firehose:ListDeliveryStreams"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "cloudwatch:GetMetricStatistics",
                "cloudwatch:ListMetrics"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": "logs:GetLogEvents",
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:ListPolicyVersions",
                "iam:ListRoles"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": "iam:PassRole",
            "Resource": "arn:aws:iam::*:role/service-role/role-name"
        }
    ]
}
```

------

### Step 3: Allow the User to View a List of Applications and View Details
<a name="console-permissions-grant-list-applications"></a>

The following policy grants a user the following permissions:
+ Permission for the `kinesisanalytics:ListApplications` action so the user can view a list of applications. This is a service-level API call, and therefore you specify "\$1" as the `Resource` value.
+ Permission for the `kinesisanalytics:DescribeApplication` action so that you can get information about any of the applications.

Add this policy to the user. 

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "kinesisanalytics:ListApplications"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "kinesisanalytics:DescribeApplication"
            ],
            "Resource": "arn:aws:kinesisanalytics:us-east-1:123456789012:application/*"
        }
    ]
}
```

------

 Verify these permissions by signing into the console using the user credentials.

### Step 4: Allow the User to Start a Specific Application
<a name="console-permissions-start-app"></a>

If you want the user to be able to start one of the existing applications, attach the following policy to the user. The policy provides the permission for the `kinesisanalytics:StartApplication` action. You must update the policy by providing your account ID, AWS Region and application name. 

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "kinesisanalytics:StartApplication"
            ],
            "Resource": "arn:aws:kinesisanalytics:us-east-1:123456789012:application/application-name"
        }
    ]
}
```

------

### Step 5: Allow the User to Create an Application
<a name="console-permissions-grant-create-applications"></a>

If you want the user to create an application, you can then attach the following policy to the user. You must update the policy and provide an AWS Region, your account ID, and either a specific application name that you want the user to create, or a "\$1" so that the user can specify any application name (and thus create multiple applications).

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "Stmt1473028104000",
            "Effect": "Allow",
            "Action": [
                "kinesisanalytics:CreateApplication"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "kinesisanalytics:StartApplication",
                "kinesisanalytics:UpdateApplication",
                "kinesisanalytics:AddApplicationInput",
                "kinesisanalytics:AddApplicationOutput"
            ],
            "Resource": "arn:aws:kinesisanalytics:us-east-1:123456789012:application/application-name"
        }
    ]
}
```

------

### Step 6: Allow the Application to Use Lambda Preprocessing
<a name="console-permissions-grant-lambda"></a>

If you want the application to be able to use Lambda preprocessing, attach the following policy to the role. 

```
     {
       "Sid": "UseLambdaFunction",
       "Effect": "Allow",
       "Action": [
           "lambda:InvokeFunction",
           "lambda:GetFunctionConfiguration"
       ],
       "Resource": "<FunctionARN>"
   }
```

# API Permissions: Actions, Permissions, and Resources Reference
<a name="api-permissions-reference"></a>

When you are setting up [Access Control](authentication-and-access-control.md#access-control) and writing a permissions policy that you can attach to an IAM identity (identity-based policies), you can use the following table as a reference. The table lists each API operation, the corresponding actions for which you can grant permissions to perform the action, and the AWS resource for which you can grant the permissions. You specify the actions in the policy's `Action` field, and you specify the resource value in the policy's `Resource` field. 

You can use AWS-wide condition keys in your policies to express conditions. For a complete list of AWS-wide keys, see [Available Keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#AvailableKeys) in the *IAM User Guide*. 

**Note**  
To specify an action, use the `kinesisanalytics` prefix followed by the API operation name (for example, `kinesisanalytics:AddApplicationInput`).

Use the scroll bars to see the rest of the table.




**API and Required Permissions for Actions**  

|  API Operations | Required Permissions (API Actions) | Resources | 
| --- | --- | --- | 
|  [AddApplicationInput](API_AddApplicationInput.md)   |  kinesisanalytics:AddApplicationInput  |  `arn:aws:kinesisanalytics: region:accountId:application/application-name`  | 
|  [AddApplicationOutput](API_AddApplicationOutput.md)   |  kinesisanalytics:AddApplicationOutput  |  `arn:aws:kinesisanalytics: region:accountId:application/application-name`  | 
|  [AddApplicationReferenceDataSource](API_AddApplicationReferenceDataSource.md)   |  kinesisanalytics:AddApplicationReferenceDataSource  |  `arn:aws:kinesisanalytics: region:accountId:application/application-name`  | 
|  [CreateApplication](API_CreateApplication.md)   |  kinesisanalytics:CreateApplication  |  `arn:aws:kinesisanalytics: region:accountId:application/application-name`  | 
|  [DeleteApplication](API_DeleteApplication.md)   |  kinesisanalytics:DeleteApplication  |  `arn:aws:kinesisanalytics: region:accountId:application/application-name`  | 
|  [DeleteApplicationOutput](API_DeleteApplicationOutput.md)   |  kinesisanalytics:DeleteApplicationOutput  |  `arn:aws:kinesisanalytics: region:accountId:application/application-name`  | 
|  [DeleteApplicationReferenceDataSource](API_DeleteApplicationReferenceDataSource.md)   |  kinesisanalytics:DeleteApplicationReferenceDataSource  |  `arn:aws:kinesisanalytics: region:accountId:application/application-name`  | 
|  [DescribeApplication](API_DescribeApplication.md)   |  kinesisanalytics:DescribeApplication  |  `arn:aws:kinesisanalytics: region:accountId:application/application-name`  | 
|  [DiscoverInputSchema](API_DiscoverInputSchema.md)   |  kinesisanalytics:DiscoverInputSchema  |  \$1  | 
|  [ListApplications](API_ListApplications.md)   |  kinesisanalytics:ListApplications  |  \$1  | 
|  [StartApplication](API_StartApplication.md)   |  kinesisanalytics:StartApplication  |  `arn:aws:kinesisanalytics: region:accountId:application/application-name`  | 
|  [StopApplication](API_StopApplication.md)   |  kinesisanalytics:StopApplication  |  `arn:aws:kinesisanalytics: region:accountId:application/application-name`  | 
|  [UpdateApplication](API_UpdateApplication.md)   |  kinesisanalytics:UpdateApplication  |  `arn:aws:kinesisanalytics: region:accountId:application/application-name`  | 
|  Access or sample data in the console   |  kinesisanalytics:GetApplicationState  |  `arn:aws:kinesisanalytics: region:accountId:application/application-name`  | 





## GetApplicationState
<a name="api-permissions-reference-gas"></a>

The console uses an internal method called `GetApplicationState` to sample or access application data. Your service application needs to have permissions for the internal `kinesisanalytics:GetApplicationState` API to sample or access application data through the AWS Management Console.