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).
# Identity and Access Management in Kinesis Data Analytics
Amazon Kinesis Data Analytics needs permissions to read records from a streaming source that you specify in your application input configuration. Amazon Kinesis Data Analytics also needs permissions to write your application output to streams that you specify in your application output configuration.
You can grant these permissions by creating an IAM role that Amazon Kinesis Data Analytics can assume. Permissions that you grant to this role determine what Amazon Kinesis Data Analytics can do when the service assumes the role.
**Note**
The information in this section is useful if you want to create an IAM role yourself. When you create an application in the Amazon Kinesis Data Analytics console, the console can create an IAM role for you at that time. The console uses the following naming convention for IAM roles that it creates:
```
kinesis-analytics-ApplicationName
```
After the role is created, you can review the role and attached policies in the IAM console.
Each IAM role has two policies attached to it. In the trust policy, you specify who can assume the role. In the permissions policy (there can be one or more), you specify the permissions that you want to grant to this role. The following sections describe these policies, which you can use when you create an IAM role.
## Trust Policy
To grant Amazon Kinesis Data Analytics permissions to assume a role to access a streaming or reference source, you can attach the following trust policy to an IAM role:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "kinesisanalytics.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
## Permissions Policy
If you are creating an IAM role to allow Amazon Kinesis Data Analytics to read from an application's streaming source, you must grant permissions for relevant read actions. Depending on your source (for example, an Kinesis stream, a Firehose delivery stream, or a reference source in an Amazon S3 bucket), you can attach the following permissions policy.
### Permissions Policy for Reading an Kinesis Stream
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ReadInputKinesis",
"Effect": "Allow",
"Action": [
"kinesis:DescribeStream",
"kinesis:GetShardIterator",
"kinesis:GetRecords",
"kinesis:ListShards"
],
"Resource": [
"arn:aws:kinesis:us-east-1:123456789012:stream/inputStreamName"
]
}
]
}
```
------
### Permissions Policy for Reading a Firehose Delivery Stream
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ReadInputFirehose",
"Effect": "Allow",
"Action": [
"firehose:DescribeDeliveryStream",
"firehose:Get*"
],
"Resource": [
"arn:aws:firehose:us-east-1:123456789012:deliverystream/inputFirehoseName"
]
}
]
}
```
------
**Note**
The `firehose:Get*` permission refers to an internal accessor that Kinesis Data Analytics uses to access the stream. There is no public accessor for a Firehose delivery stream.
If you direct Amazon Kinesis Data Analytics to write output to external destinations in your application output configuration, you need to grant the following permission to the IAM role.
### Permissions Policy for Writing to a Kinesis Stream
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "WriteOutputKinesis",
"Effect": "Allow",
"Action": [
"kinesis:DescribeStream",
"kinesis:PutRecord",
"kinesis:PutRecords"
],
"Resource": [
"arn:aws:kinesis:us-east-1:123456789012:stream/output-stream-name"
]
}
]
}
```
------
### Permissions Policy for Writing to a Firehose Delivery Stream
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "WriteOutputFirehose",
"Effect": "Allow",
"Action": [
"firehose:DescribeDeliveryStream",
"firehose:PutRecord",
"firehose:PutRecordBatch"
],
"Resource": [
"arn:aws:firehose:us-east-1:123456789012:deliverystream/output-firehose-name"
]
}
]
}
```
------
### Permissions Policy for Reading a Reference Data Source from an Amazon S3 Bucket
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:Get*",
"s3:List*"
],
"Resource": "*"
}
]
}
```
------
# Cross-service confused deputy prevention
In AWS, cross-service impersonation can occur when one service (the calling service) calls another service (the called service). The calling service can be manipulated to act on another customer's resources even though it shouldn't have the proper permissions, resulting in the confused deputy problem.
To prevent confused deputies, AWS provides tools that help you protect your data for all services using service principals that have been given access to resources in your account. This section focuses on cross-service confused deputy prevention specific to Kinesis Data Analytics however, you can learn more about this topic at [The confused deputy problem](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) section of the *IAM User Guide*.
In the context of Kinesis Data Analytics for SQL, we recommend using the [aws:SourceArn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) and [aws:SourceAccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) global condition context keys in your role trust policy to limit access to the role to only those requests that are generated by expected resources.
Use `aws:SourceArn` if you want only one resource to be associated with the cross-service access. Use `aws:SourceAccount` if you want to allow any resource in that account to be associated with the cross-service use.
The value of `aws:SourceArn` must be the ARN of the resource used by Kinesis Data Analytics, which is specified with the following format: `arn:aws:kinesisanalytics:region:account:resource`.
The recommended approach to the confused deputy problem is to use the `aws:SourceArn` global condition context key with the full resource ARN.
If you don't know the full ARN of the resource or if you are specifying multiple resources, use the `aws:SourceArn` key with wildcard characters (\$1) for the unknown portions of the ARN. For example: `arn:aws:kinesisanalytics::111122223333:*`.
While most actions in the Kinesis Data Analytics for SQL API such as [CreateApplication](https://docs.aws.amazon.com/kinesisanalytics/latest/dev/API_CreateApplication.html), [AddApplicationInput](https://docs.aws.amazon.com/kinesisanalytics/latest/dev/API_AddApplicationInput.html) and [DeleteApplication](https://docs.aws.amazon.com/kinesisanalytics/latest/dev/API_DeleteApplication.html) are made in context of specific applications, the [DiscoverInputSchema](https://docs.aws.amazon.com/kinesisanalytics/latest/dev/API_DiscoverInputSchema.html) action is not executed in the context of any application. That means the role used in this action must not fully specify a resource in the `SourceArn` condition key. Following is an example that uses a wildcard ARN:
```
{
...
"ArnLike":{
"aws:SourceArn":"arn:aws:kinesisanalytics:us-east-1:123456789012:*"
}
...
}
```
The default role generated by Kinesis Data Analytics for SQL uses this wildcard. This ensures discovering input schema works seamlessly in the console experience. However, we recommend editing the Trust Policy to use a full ARN after discovering the schema to implement complete confused deputy mitigation.
Policies of roles that you provide to Kinesis Data Analytics as well as trust policies of roles generated for you can make use of [aws:SourceArn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) and [aws:SourceAccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) condition keys.
In order to protect against the confused deputy problem, carry out the following steps:
**To protect against the confused deputy problem**
1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Choose **Roles** and then choose the role you want to modify.
1. Choose **Edit trust policy**.
1. On the **Edit trust policy** page, replace the default JSON policy with a policy that uses one or both of the `aws:SourceArn` and `aws:SourceAccount` global condition context keys. See the following example policy:
1. Choose **Update policy**.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Principal":{
"Service":"kinesisanalytics.amazonaws.com"
},
"Action":"sts:AssumeRole",
"Condition":{
"StringEquals":{
"aws:SourceAccount":"Account ID"
},
"ArnEquals":{
"aws:SourceArn":"arn:aws:kinesisanalytics:us-east-1:123456789012:application/my-app"
}
}
}
]
}
```
------