Amazon Redshift will no longer support the creation of new Python UDFs starting Patch 198. Existing Python UDFs will continue to function until June 30, 2026. For more information, see the [ blog post ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). # Getting started with multi-warehouse writes using data sharing in Amazon Redshift Getting started with multi-warehouse writes You can share database objects for both reads and writes across different Amazon Redshift clusters or Amazon Redshift Serverless workgroups within the same AWS account, across accounts, and across regions. The procedures in this topic show how to set up data sharing that includes write permissions. You can grant permissions such as SELECT, INSERT, and UPDATE for different tables and USAGE and CREATE for schemas. Data is live and available to all warehouses as soon as you commit a write transaction Producer account administrators can determine whether or not specific namespaces or regions get read-only, read-and-write, or any access to the data. The procedures assume you're working in a database in a provisioned cluster or Amazon Redshift Serverless workgroup. With Amazon Redshift, you can manage data sharing with writes using the console or the SQL interface to control access and govern data across Amazon Redshift clusters and AWS accounts. The following sections provide step-by-step instructions on configuring and managing data sharing with writes using Amazon Redshift. For a list of Regions where data sharing is available, see [AWS Regions where data sharing is available](data_sharing_regions.md). For considerations and limitations for writes, see [Considerations for data sharing in Amazon Redshift](datashare-considerations.md). **Note** Amazon Redshift multi-warehouse writes using data sharing is only supported on Amazon Redshift patch 186 for provisioned clusters on current track version 1.0.78881 or greater, and for Amazon Redshift Serverless workgroups on version 1.0.78890 or greater. **Topics** + [ # Connecting to a database in Amazon Redshift ](connect-database-console-writes.md) + [ # Producer actions for new datashares in Amazon Redshift ](writes-producer-new.md) + [ # Consumer actions for new datashares in Amazon Redshift ](writes-consumer-new.md) + [ # Producer actions for existing datashares in Amazon Redshift ](writes-producer-existing.md) + [ # Consumer actions for existing datashares in Amazon Redshift ](writes-consumer-existing.md) # Connecting to a database in Amazon Redshift Connecting to a database With Amazon Redshift, you can establish a connection to your data warehouse cluster and execute SQL queries, load data, or perform administrative tasks. Connecting to a database refers to the process of creating a secure channel between a client application or tool and the Amazon Redshift cluster. The following sections provide step-by-step instructions on how to connect to an Amazon Redshift database. ------ #### [ Console ] Connect to a database to view databases and objects within databases or to view datashares in the Amazon Redshift data warehouse. The user credentials used to connect to a specified database must have the necessary permissions to view all datashares. If there is no local connection, do one of the following: + If you are a producer administrator, go to the **Clusters** tab for provisioned clusters, or the **Namespaces configuration** tab for Serverless endpoints. Select the respective cluster or namespace from the list. + In the cluster or namespace details page, from the **Datashares** tab, choose **Connect to database** and do one of the following: + In the **Datashares from other namespaces and AWS accounts** section, view datashares from other clusters, namespaces, or accounts. + In the **Datashares created in my cluster** section, view datashares in your cluster. + On the **Connect to database** window, do one of the following: + If you choose **Create a new connection**, choose **AWS Secrets Manager** to use a stored secret to authenticate access for the connection. Or, choose **Temporary credentials** to use database credentials to authenticate access for the connection. Specify values for **Database name** and **Database user**. Choose **Connect**. + Choose **Use a recent connection** to connect to another database that you have the necessary permissions. Amazon Redshift automatically makes the connection. After a database connection is established, you can start creating datashares, querying datashares, or creating databases from datashares. ------ # Producer actions for new datashares in Amazon Redshift Producer actions for new datashares With Amazon Redshift, you can share live data across Amazon Redshift clusters or AWS accounts using datashares. A datashare is a consumer-producer object that allows you to share live data from your Amazon Redshift cluster with other clusters or AWS accounts. Creating datashares enables secure data sharing while maintaining control over access and ensuring data remains up-to-date. The following sections provide details on creating datashares and adding database objects such as schemas, tables, and views to share live data securely. **Topics** + [ # Creating a datashare in Amazon Redshift ](writes-creating-datashare.md) + [ # Adding objects to a datashare in Amazon Redshift ](writes-adding-datashare.md) + [ # Adding data consumers to a datashare in Amazon Redshift ](writes-adding-data-consumer.md) + [ # Authorizing a datashare in Amazon Redshift ](writes-authorizing.md) # Creating a datashare in Amazon Redshift Creating a datashare A datashare is a logical container of database objects, permissions, and consumers. Consumers are Amazon Redshift provisioned clusters or Amazon Redshift Serverless namespaces in your account and other AWS accounts. Each datashare is associated with the database it's created in and only objects from that database can be added. As a producer administrator, you can create datashares on the console and with SQL by following one of the below procedures. ------ #### [ Console ] On the console, you can create datashares from the **Datashares** tabs in the cluster or namespace details page. After the datashare is created, you can create databases from the datashare on a consumer as a consumer administrator. 1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/). 1. On the navigation menu, choose **Clusters**, then choose your cluster. The cluster details page appears. 1. In the cluster or namespace details page, from the **Datashares** tab, in the **Datashares** section, connect to a database if you don't have a database connection. In the **Datashares created in my account** section, choose **Create datashare**. The **Create datashare** page appears. 1. Choose **Create datashare**. You can only create a datashare from a local database. If you haven't connected to the database, the **Connect to database** page appears. Follow the steps in [Connecting to a database](connect-database-console.md) to connect to a database. If there is a recent connection, the **Create datashare** page appears. 1. In the **Datashare information** section, choose one of the following: + Choose **Datashare** to create datashares to share data for read or write purpose across different Amazon Redshift data warehouses (provisioned clusters or Serverless endpoints) or in the same AWS account or different AWS accounts. + Choose **AWS Data Exchange datashare** to create datashares to license your data through AWS Data Exchange. 1. Specify values for **Datashare name**, **Database name**, and **Publicly accessible**. When you change the database name, make a new database connection. 1. Add objects to your datashare either using the **Scoped permissions** or **Direct permissions** sections. To add objects to a datashare, see [Creating a datashare in Amazon Redshift](#writes-creating-datashare). 1. In the **Data consumers** section, you can choose to publish to Amazon Redshift, or publish to the AWS Glue Data Catalog, which starts the process of sharing data with Lake Formation. Publishing your datashare to Amazon Redshift means sharing your data with another namespace or Amazon Redshift account that acts as the consumer. **Note** Once the datashare is created, you can't edit the configuration to publish to the other option. 1. Choose **Create datashare**. ------ #### [ SQL ] The following command creates a datashare: ``` CREATE DATASHARE salesshare; ``` At the time of datashare creation, each datashare is associated with a database. Only objects from that database can be shared in that datashare. Multiple datashares can be created on the same database with the same or different granularity of objects. There is no limit on the number of datashares a cluster can create. You can also use the Amazon Redshift console to create datashares. For more information, see [CREATE DATASHARE](r_CREATE_DATASHARE.md). You can also control security restrictions to the datashare during creation. The following example shows that the consumer with a public IP access is allowed to read the datashare. ``` CREATE DATASHARE my_datashare [PUBLICACCESSIBLE = TRUE]; ``` Setting PUBLICACCESSIBLE = TRUE allows consumers to query your datashare from publicly accessible clusters and provisioned workgroups. Leave this out or explicitly set it to false if you do not want to allow it. You can modify properties about the type of consumers after you create a datashare. For example, you can define that clusters that want to consume data from a given datashare can't be publicly accessible. Queries from consumer clusters that don't meet security restrictions specified in datashare are rejected at query runtime. For more information, see [ALTER DATASHARE](r_ALTER_DATASHARE.md). ------ # Adding objects to a datashare in Amazon Redshift Adding objects to a datashare You can add database objects of various types on the console and with SQL by following one of the below procedures. ------ #### [ Console ] You can add objects to your datashare either using **Scoped permissions** or **Direct permissions** sections. Select either **Grant scoped permissions** or **Grant direct permissions** to add objects. Select the **Add** button to add objects. A dialog appears. Perform the following steps: 1. If you select **Grant scoped permissions**, the **Grant scoped permissions** page appears where you can grant scoped permissions at either a database or a schema level. Datashares with scoped permissions have the specified permissions on all current and future objects within the database or schema. For more details see, [Scoped permissions](t_scoped-permissions.md). 1. Next, select **Database scoped permissions** to grant scoped permissions at the database level. When you grant scoped permissions, they apply to the current database while creating the datashare. These permissions can’t be granted to individual objects and are applicable to both existing and new objects (schemas, tables, views, UDFs). 1. Select the scoped permission(s) for the schemas, table or views or user-defined functions. This means all objects in the database have the selected permissions granted to consumers. Select **Grant** to complete granting database scoped permissions. 1. Then, select **Schema scoped permissions** to grant scoped permissions at the schema level. When you grant schema-scoped permissions, all objects added to the schema have the specified datashare permissions. 1. Select the schema you want to add to the datashare from the dropdown. You can select only a single schema at a time. Then, select direct permission(s) you want to grant on the selected schema. 1. Select scoped permission(s) for your schema objects such as tables, views and user-defined functions. Permissions are granted on all matching objects in the schema. These can be either existing objects or those added in the future. When it's applied, you can't remove a permission from an object without revoking the scoped permissions. 1. Select **Grant** to complete granting schema scoped permissions. 1. If you select **Grant direct permissions**, the **Grant direct permissions** page appears where you can grant direct permissions at each objects level such as schema, table, view or user-defined function. To grant direct permissions, you must first add the relevant schemas to the datashare. 1. Next, select **Grant direct permissions** to schemas to apply direct permissions on specific schema. Then, select schema permission(s) for your schema objects such as tables, views and user-defined functions and select the schema you want added to the datashare. Select **Grant** to complete adding schema to the datashare. 1. After you have a schema added to your datashare, you can proceed with adding direct permissions for your schema objects. Select **Grant direct permissions ** again. The **Grant direct permissions** page appears. Then, navigate to the direct permissions tabs for schema objects. 1. Select **Grant direct permissions to tables and views** to grant object level direct permissions on these objects. Select the required direct permission(s) and the required objects from the list. Use the search field to find datashare objects. Select Grant to complete adding tables and views to the datashare. 1. Select **Grant direct permissions to user-defined functions** to grant object level direct permissions on user-defined functions. Select the required direct permission(s) and the required objects from the list. Use the search field to find datashare objects. Select **Grant** to complete adding user-defined functions to the datashare. 1. You can also choose whether you want to **Add future objects**. When you choose to include datashare objects added to the schema, it means that objects added to the schema are added to the datashare automatically. 1. Choose **Add** to complete the section and add the objects. They're listed under the **Datashare objects**. 1. After you add objects, you can select individual objects and edit their permissions. If you select a schema, a dialog appears that asks if you would like to add **Scoped permissions**. This makes it so each existing or added object to the schema has a pre-selected set of permissions, appropriate for the object type. For instance, the administrator can set that all added tables have SELECT and UPDATE permissions, for instance. 1. All datashare objects are listed under the **Scoped permissions** or **Direct permissions** sections. 1. In the **Data consumers** section, you can add namespaces or add AWS accounts as consumers of the datashare. 1. Choose **Create datashare** to save your changes. After you create the datashare, it appears in the list under **Datashares created in my namespace**. If you choose a datashare from the list, you can view its consumers, its objects, and other properties. ------ #### [ SQL ] With SQL, the datashare owner must grant USAGE on the schemas they want to add to the datashare. The GRANT is used to grant various actions on the schema, including CREATE and USAGE. The schemas hold shared objects: ``` CREATE SCHEMA myshared_schema1; CREATE SCHEMA myshared_schema2; GRANT USAGE ON SCHEMA myshared_schema1 TO DATASHARE my_datashare; GRANT CREATE, USAGE ON SCHEMA myshared_schema2 TO DATASHARE my_datashare; ``` Alternatively, the administrator can continue to run ALTER commands to add a schema to the datashare. Only USAGE permissions are granted when a schema is added this way. ``` ALTER DATASHARE my_datashare ADD SCHEMA myshared_schema1; ``` After the administrator adds schemas, they can grant datashare permissions on objects in the schema. These can be both read and write permissions. The GRANT ALL sample shows how to grant all permissions. ``` GRANT SELECT, INSERT ON TABLE myshared_schema1.table1, myshared_schema1.table2, myshared_schema2.table1 TO DATASHARE my_datashare; GRANT ALL ON TABLE myshared_schema1.table4 TO DATASHARE my_datashare; ``` You can continue to run commands like ALTER DATASHARE to add tables. When you do, only SELECT permissions are granted on the objects added. ``` ALTER DATASHARE my_datashare ADD TABLE myshared_schema1.table1, myshared_schema1.table2, myshared_schema2.table1; ``` You can grant scoped permissions to a datashare on all objects of a type within a database or schema. Datashares with scoped permissions have the specified permissions on all current and future objects within the database or schema. You can view the scope of database-level scoped permissions in [SVV\$1DATABASE\$1PRIVILEGES](r_SVV_DATABASE_PRIVILEGES.md). You can view the scope of schema-level scoped permissions in [SVV\$1SCHEMA\$1PRIVILEGES](r_SVV_SCHEMA_PRIVILEGES.md). The following is the syntax for granting scoped permissions to datashares. For more information about scoped permissions, see [Scoped permissions](t_scoped-permissions.md). ``` GRANT { CREATE | USAGE | ALTER | DROP } [,...] | ALL [ PRIVILEGES ] }FOR SCHEMAS IN DATABASE db_name TO DATASHARE { datashare_name} GRANT { { SELECT | INSERT | UPDATE | DELETE | DROP | ALTER | TRUNCATE | REFERENCES } [, ...] } | ALL [PRIVILEGES] } }FOR TABLES IN {SCHEMA schema_name [DATABASE db_name ] | DATABASE db_name } TO DATASHARE { datashare_name} GRANT { EXECUTE | ALL [ PRIVILEGES ] }FOR FUNCTIONS IN {SCHEMA schema_name [DATABASE db_name ] | DATABASE db_name } TO DATASHARE { datashare_name} ``` ------ # Adding data consumers to a datashare in Amazon Redshift Adding data consumers to a datashare You can add one or more data consumers to the datashares on the console or with SQL. Data consumers can be namespaces that uniquely identified Amazon Redshift clusters or AWS accounts. ------ #### [ Console ] You must explicitly choose to turn off or turn on sharing your datashare to clusters with public access. + Choose **Add namespaces to the datashare**. Namespaces are globally unique identifier (GUID) for Amazon Redshift cluster. + Choose **Add AWS accounts** to the datashare. The specified AWS accounts must have access permissions to the datashare. ------ #### [ SQL ] With SQL, the administrator grants usage on the datashare to a specific namespace in the account. You can find the namespace ID as part of the ARN in the cluster details page, in the Amazon Redshift Serverless namespace details page, or by running the command `SELECT current_namespace;`. For more information, see [CURRENT\$1NAMESPACE](https://docs.aws.amazon.com/redshift/latest/dg/r_CURRENT_NAMESPACE.html). ``` GRANT USAGE ON DATASHARE my_datashare TO NAMESPACE '86b5169f-012a-234b-9fbb-e2e24359e9a8'; ``` The following is an example of how to grant usage of a datashare to an AWS account. ``` GRANT USAGE ON DATASHARE salesshare TO ACCOUNT '123456789012'; ``` The following is an example of how to grant usage of a datashare to a Lake Formation account. ``` GRANT USAGE ON DATASHARE salesshare TO ACCOUNT '123456789012' VIA DATA CATALOG; ``` ------ # Authorizing a datashare in Amazon Redshift Authorizing a datashare With Amazon Redshift, you can control access to datashares by authorizing specified consumers. Datashares allow you to share live data across Amazon Redshift clusters in the same or different AWS accounts, providing a seamless way to distribute and consume analytical data. This section provides step-by-step instructions for authorizing and revoking consumer access to your datashares in Amazon Redshift. **Note** If you are adding a namespace as a data consumer, you don't have to perform authorization. To authorize a datashare, there must be at least one data consumer added to the datashare. ------ #### [ Console ] As a producer administrator on the console, you can choose which data consumers to authorize to access datashares or to remove authorization from. Authorized data consumers receive notifications to take actions on datashares. If you are adding a namespace as a data consumer, you don't have to perform authorization. 1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/). 1. On the navigation menu, choose **Datashares**. From here you can see a list called **Datashares consumers**. Choose one or more consumer clusters that you want to authorize. Then choose **Authorize**. 1. The **Authorize account** dialog appears. You can choose among a couple authorization types. + **Read-only on [cluster name or workgroup name]** – This means that no write permissions are available on the consumer, even if the datashare creator granted write permissions. + **Read and write on [cluster name or workgroup name]** – This means that all permissions granted by the creator, including write permissions, are available on the consumer. 1. Choose **Save**. You can also authorize AWS Data Exchange as a consumer. 1. If you chose **Publish to AWS Glue Data Catalog** when creating the datashare, you can only grant authorization of the datashare to a Lake Formation account. For AWS Data Exchange datashare, you can only authorize one datashare at a time. When you authorize an AWS Data Exchange datashare, you are sharing the datashare with the AWS Data Exchange service and allowing AWS Data Exchange to manage access to the datashare on your behalf. AWS Data Exchange allows access to consumers by adding consumer accounts as data consumers to the AWS Data Exchange datashare when they subscribe to the products. AWS Data Exchange doesn't have read access to the datashare. 1. Choose **Save**. After data consumers are authorized, they can access datashare objects and create a consumer database to query the data. ------ #### [ API ] The producer security administrator determines the following: + Whether or not another account can have access to the datashare. + If an account has access to the datashare, whether or not that account has write permissions. The following IAM permissions are required to authorize a datashare: **redshift:AuthorizeDataShare** You can authorize usage and writes using either a CLI call or with the API: ``` authorize-data-share --data-share-arn --consumer-identifier [--allow-writes | --no-allow-writes] ``` For more information about the command, see [authorize-data-share](https://docs.aws.amazon.com/cli/latest/reference/redshift/authorize-data-share.html). The consumer identifier can be either: + A twelve digit AWS account ID. + The namespace identifier ARN. **Note** Write permissions aren’t granted at the authorizing step. Authorizing a datashare for writes just allows the account to have write permissions that were granted by the datashare administrator. If an administrator does not allow writes, the only permissions available to the specific consumer are SELECT, USAGE, and EXECUTE. You can change the authorization of a datashare consumer by calling `authorize-data-share` again, but with a different value. The old authorization is overwritten by the new authorization. So if you originally authorize and allow writes, but re-authorize and specify `no-allow-writes` or simply do not specify a value, the consumer will have their write permissions revoked. ------ # Consumer actions for new datashares in Amazon Redshift Consumer actions for new datashares With Amazon Redshift, you can consume datashares from other AWS accounts, enabling cross-account data sharing and collaboration. A datashare is a secure way to share live data across Amazon Redshift clusters, even if they are in different AWS accounts. The following sections provide detailed steps for configuring access, creating databases from datashares, granting object level permissions, and querying shared data. **Topics** + [ # Associating a datashare from a different AWS account in Amazon Redshift ](writes-associating.md) + [ # Creating a database from a datashare in Amazon Redshift ](writes-creating-database.md) + [ # Granting object level permissions to consumer users and roles in Amazon Redshift ](writes-granting.md) + [ # Querying data in a datashare in Amazon Redshift ](writes-querying.md) # Associating a datashare from a different AWS account in Amazon Redshift Associating a datashare With Amazon Redshift, you can associate datashares shared by other AWS accounts, enabling seamless and secure data sharing across organizational boundaries. Datashares are shareable database objects that encapsulate data from one or more Amazon Redshift databases. The following sections demonstrate the process of associating datashares. ------ #### [ Console ] As a consumer administrator, you can associate one or more datashares that are shared from other accounts to your entire AWS account or specific namespaces in your account. 1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/). 1. On the navigation menu, choose **Datashares**. The datashare list page appears. Choose **From other accounts**. 1. In the **Datashares from other accounts** section, choose the datashare that you want to associate and choose **Associate**. When the **Associate** datashare page appears, choose one of the following association types: + Choose **Entire AWS account** to associate all existing and future namespaces across different AWS Regions in your AWS account with the datashare. + If the datashare is published to the AWS Glue Data Catalog, you can only associate the datashare with the entire AWS account. 1. From here you can choose **Allowed permissions**. The choices are: + **Read-only** – If you choose read only, write permissions like UPDATE or INSERT aren't available on the consumer, even if these permissions were granted and authorized on the producer. + **Read and write** – Consumer datashare users will have all of the permissions, both read and write, that were granted and authorized by the producer. 1. Alternatively, choose **Specific AWS Regions and namespaces** to associate one or more AWS Regions and specific namespaces with the datashare. Choose **Add Region** to add specific AWS Regions and namespaces to the datashare. The **Add AWS Region** page appears. 1. Choose an **AWS Region**. 1. Do one of the following: + Choose **Add all namespaces** to add all existing and future namespaces in this Region to the datashare. + Choose **Add specific namespaces** to add one or more specific namespaces in this Region to the datashare. + Choose one or more namespaces and choose **Add AWS Region**. 1. Choose **Associate**. It's possible for the producer to go back and change settings for an authorization, which can affect association settings on consumers. If you're associating the datashare with a Lake Formation account, go to the Lake Formation console to create a database, then define permissions over the database. For more information, see [ Setting up permissions for Amazon Redshift datashares](https://docs.aws.amazon.com/lake-formation/latest/dg/setup-ds-perms.html) in the AWS Lake Formation Developer Guide. Once you create a AWS Glue database or a federated database, you can use query editor v2 or any preferred SQL client with your consumer cluster to query the data. After the datashare is associated, the datashares become available. **Note** You can also change datashare association at any time. When changing association from specific AWS Regions and namespaces to the entire AWS account, Amazon Redshift overwrites the specific Region and namespaces information with AWS account information. All the AWS Regions and namespaces in the AWS account then have access to the datashare. ------ #### [ API ] **Note** The steps in this section are performed after the producer administrator grants specific actions on the shared database objects and, if the datashare is being shared with another account, the producer security administrator authorizes access. The consumer security administrator determines the following: + Whether or not all namespaces in an account, namespaces in specific regions in the account, or specific namespaces have access to the datashare. + If namespaces have access to the datashare, whether or not those namespace have write permissions. The consumer security administrator can associate the datashare with the following command: ``` associate-data-share-consumer --data-share-arn --consumer-identifier [--allow-writes | --no-allow-writes] ``` For more information about the command, see [associate-data-share-consumer](https://docs.aws.amazon.com/cli/latest/reference/redshift/associate-data-share-consumer.html). The consumer security administrator must explicitly set `allow-writes` to true when associating a datashare with a namespace, to allow use of INSERT and UPDATE commands. If they don't, the users can perform only read operations, such as SELECT, USAGE, or EXECUTE privileges. You can change the association of a namespace for a datashare by calling `associate-data-share-consumer` again, with a different value. The old association is overwritten by the new association, so if you originally associate and set `allow-writes`, but associate and specify `no-allow-writes`, or simply do not specify a value, the consumer will have their write permissions revoked. ------ # Creating a database from a datashare in Amazon Redshift Creating a database from a datashare With Amazon Redshift, you can use a datashare to create a database, and then query data across datashares from producer clusters to securely access live data without copying or transferring it. The following steps cover the details of setting up a database in your Amazon Redshift environment. ------ #### [ Console ] Before you can query data in the datashare, you must create a database from a datashare. You can create only one database from a specified datashare. 1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/). 1. On the navigation menu, choose **Clusters**, then choose your cluster. The cluster details page appears. 1. Choose **Datashares**. The datashare list appears. 1. In the **Datashares from other clusters** section, choose **Connect to database**. For more information, see [Connecting to a database](connect-database-console.md). 1. Choose a datashare that you want to create databases from, then choose **Create database from datashare**. The Create database from datashare page appears. 1. In the **Database name**, specify a database name. The database name must be 1–64 alphanumeric characters (lowercase only) and it can't be a reserved word. 1. Choose **Create**. After the database is created, you can query data in the database or perform write operations, if they have been granted, authorized, and associated by the consumer administrator. ------ #### [ API ] To share data for read purposes as a consumer administrator, perform the following steps. 1. List the datashares that are made available to you and view the content of datashares. For more information, see [DESC DATASHARE](r_DESC_DATASHARE.md) and [SHOW DATASHARES](r_SHOW_DATASHARES.md). The following example displays the information of inbound datashares of a specified producer namespace. When you run DESC DATASHARE as a consumer administrator, you must specify the NAMESPACE option to view inbound datashares. ``` DESC DATASHARE salesshare OF NAMESPACE '13b8833d-17c6-4f16-8fe4-1a018f5ed00d'; producer_account | producer_namespace | share_type | share_name | object_type | object_name | include_new -------------------+--------------------------------------+------------+------------+-------------+---------------------------------+------------------ 123456789012 | 13b8833d-17c6-4f16-8fe4-1a018f5ed00d | INBOUND | salesshare | table | public.tickit_users_redshift | 123456789012 | 13b8833d-17c6-4f16-8fe4-1a018f5ed00d | INBOUND | salesshare | table | public.tickit_venue_redshift | 123456789012 | 13b8833d-17c6-4f16-8fe4-1a018f5ed00d | INBOUND | salesshare | table | public.tickit_category_redshift | 123456789012 | 13b8833d-17c6-4f16-8fe4-1a018f5ed00d | INBOUND | salesshare | table | public.tickit_date_redshift | 123456789012 | 13b8833d-17c6-4f16-8fe4-1a018f5ed00d | INBOUND | salesshare | table | public.tickit_event_redshift | 123456789012 | 13b8833d-17c6-4f16-8fe4-1a018f5ed00d | INBOUND | salesshare | table | public.tickit_listing_redshift | 123456789012 | 13b8833d-17c6-4f16-8fe4-1a018f5ed00d | INBOUND | salesshare | table | public.tickit_sales_redshift | 123456789012 | 13b8833d-17c6-4f16-8fe4-1a018f5ed00d | INBOUND | salesshare | schema | public | 123456789012 | 13b8833d-17c6-4f16-8fe4-1a018f5ed00d | INBOUND | salesshare | view | public.sales_data_summary_view | ``` Only cluster superusers can do this. You can also use SVV\$1DATASHARES to view the datashares and SVV\$1DATASHARE\$1OBJECTS to view the objects within the datashare. The following example displays the inbound datashares in a consumer cluster. ``` SHOW DATASHARES LIKE 'sales%'; share_name | share_owner | source_database | consumer_database | share_type | createdate | is_publicaccessible | share_acl | producer_account | producer_namespace ------------+-------------+-----------------+-------------------+------------+------------+---------------------+-----------+------------------+-------------------------------------- salesshare | | | | INBOUND | | t | | 123456789012 | 13b8833d-17c6-4f16-8fe4-1a018f5ed00d ``` 1. As a database superuser, you can create local databases that reference to the datashares. For more information, see [CREATE DATABASE](r_CREATE_DATABASE.md). ``` CREATE DATABASE sales_db FROM DATASHARE salesshare OF NAMESPACE '13b8833d-17c6-4f16-8fe4-1a018f5ed00d'; ``` If you want more granular control over access to the objects in the local database, use the WITH PERMISSIONS clause when creating the database. This lets you grant object-level permissions for objects in the database in step 4. ``` CREATE DATABASE sales_db WITH PERMISSIONS FROM DATASHARE salesshare OF NAMESPACE '13b8833d-17c6-4f16-8fe4-1a018f5ed00d'; ``` You can see databases that you created from the datashare by querying the [SVV\$1REDSHIFT\$1DATABASES](r_SVV_REDSHIFT_DATABASES.md) view. You can connect to these databases directly, or you can connect to a local database on your consumer cluster and perform a cross-database query to query the data from the datashare databases. **Note** You can't create a datashare on top of database objects created from an existing datashare. However, you can copy the data into a separate table on the consumer cluster, perform any processing needed, and then share the new objects that were created. You can also use the Amazon Redshift console to create databases from datashares. For more information, see [Creating databases from datashares](query-datashare-console.md#create-database-from-datashare-console). ------ # Granting object level permissions to consumer users and roles in Amazon Redshift Granting object level permissions As a consumer administrator, you can grant permissions to consumer users and roles at the object level by completing the following steps. ------ #### [ SQL ] If you created your database without WITH PERMISSIONS, you can only assign permissions on the entire database created from the datashare to your users and roles. ``` GRANT USAGE ON DATABASE sales_db TO Bob; ``` ``` GRANT USAGE ON SCHEMA sales_schema TO ROLE Analyst_role; ``` You can also create late-binding views on top of shared objects and use these to assign granular permissions. You can also consider having producer clusters create additional datashares for you with the granularity required. If you created your database with WITH PERMISSIONS, you must assign object-level permissions for objects in the shared database. A user with only the USAGE permission can’t access any objects in a database created with WITH PERMISSIONS until they’re granted additional object-level permissions.. ``` GRANT SELECT ON sales_db.public.tickit_sales_redshift to Bob; ``` ------ For more information about granting permissions with multi-warehouse writes, see [Managing permissions for a datashares in Amazon Redshift](writes-managing-permissions.md). # Querying data in a datashare in Amazon Redshift Querying data in a datashare With Amazon Redshift, you can query data across datashares from producer clusters to securely access live data without copying or transferring it. The following section covers querying datashares in your Amazon Redshift environment. Users and roles with permissions on consumer databases and schemas on consumer clusters can explore and navigate the metadata of any shared objects. They can also explore and navigate local objects in a consumer cluster. To do this, they use JDBC or ODBC drivers or SVV\$1ALL and SVV\$1REDSHIFT views. Producer clusters might have many schemas in the database, tables, and views within each schema. The users on the consumer side can see only the subset of objects that are made available through the datashare. These users can't see the entire metadata from the producer cluster. This approach helps provide granular metadata security control with data sharing. You continue to connect to local cluster databases. But now, you can also read from the databases and schemas that are created from the datashare using the three-part database.schema.table notation. You can perform queries that span across any and all databases that are visible to you. These can be local databases on the cluster or databases created from the datashares. Consumer clusters can't connect to the databases created from the datashares. You can access the data using full qualification. For more information, see [Cross-database query examples](cross-database_example.md). ------ #### [ SQL ] ``` SELECT * FROM sales_db.public.tickit_sales_redshift ORDER BY 1,2 LIMIT 5; salesid | listid | sellerid | buyerid | eventid | dateid | qtysold | pricepaid | commission | saletime ---------+--------+----------+---------+---------+--------+---------+-----------+------------+--------------------- 1 | 1 | 36861 | 21191 | 7872 | 1875 | 4 | 728.00 | 109.20 | 2008-02-18 02:36:48 2 | 4 | 8117 | 11498 | 4337 | 1983 | 2 | 76.00 | 11.40 | 2008-06-06 05:00:16 3 | 5 | 1616 | 17433 | 8647 | 1983 | 2 | 350.00 | 52.50 | 2008-06-06 08:26:17 4 | 5 | 1616 | 19715 | 8647 | 1986 | 1 | 175.00 | 26.25 | 2008-06-09 08:38:52 5 | 6 | 47402 | 14115 | 8240 | 2069 | 2 | 154.00 | 23.10 | 2008-08-31 09:17:02 ``` You can only use SELECT statements on shared objects. However, you can create tables in the consumer cluster by querying the data from the shared objects in a different local database. ------ # Producer actions for existing datashares in Amazon Redshift Producer actions for existing datashares With Amazon Redshift, you can manage existing datashares to control access to your data in an Amazon Redshift cluster. The following sections provide step-by-step guidance on modifying datashare objects, managing datashare permissions, and updating datashare properties to effectively control and audit data access in your Amazon Redshift environment. **Topics** + [ # Viewing a datashare in Amazon Redshift ](writes-viewing.md) + [ # Editing datashares created in your account in Amazon Redshift ](writes-editing.md) + [ # Removing authorization from a datashare in Amazon Redshift ](writes-removing-authorization.md) + [ # Removing datashare objects from a datashare in Amazon Redshift ](writes-removing-datashare-object.md) + [ # Removing data consumers from a datashare in Amazon Redshift ](writes-removing-data-consumer.md) + [ # Deleting a datashare created in your account in Amazon Redshift ](writes-deleting.md) # Viewing a datashare in Amazon Redshift Viewing a datashare You can view datashares from the console or with SQL. ------ #### [ Console ] You can view datashares from the **Datashares** or **Clusters** tab. + Use the **Datashares** tab to list datashares in your account or from other accounts. + To view datashares created in your account, choose **In my account**, then choose the datashare you want to view. + To view datashares that are shared from other accounts, choose **From other accounts**, then choose the datashare you want to view. + Use the **Clusters** tab to list datashares in your cluster or from other clusters. First, connect to a database. Then, choose a datashare either from the **Datashares from other clusters** or **Datashares created in my cluster** section to view its details. ------ #### [ SQL ] You can list datashares created in the cluster and look into the contents of the datashare. The following example displays the information of a datashare named `salesshare`. ``` DESC DATASHARE salesshare; producer_account | producer_namespace | share_type | share_name | object_type | object_name | include_new -------------------+--------------------------------------+------------+------------+-------------+--------------------------------+------------------- 123456789012 | 13b8833d-17c6-4f16-8fe4-1a018f5ed00d | OUTBOUND | salesshare | table | public.tickit_users_redshift | 123456789012 | 13b8833d-17c6-4f16-8fe4-1a018f5ed00d | OUTBOUND | salesshare | table | public.tickit_venue_redshift | 123456789012 | 13b8833d-17c6-4f16-8fe4-1a018f5ed00d | OUTBOUND | salesshare | table | public.tickit_category_redshift| 123456789012 | 13b8833d-17c6-4f16-8fe4-1a018f5ed00d | OUTBOUND | salesshare | table | public.tickit_date_redshift | 123456789012 | 13b8833d-17c6-4f16-8fe4-1a018f5ed00d | OUTBOUND | salesshare | table | public.tickit_event_redshift | 123456789012 | 13b8833d-17c6-4f16-8fe4-1a018f5ed00d | OUTBOUND | salesshare | table | public.tickit_listing_redshift | 123456789012 | 13b8833d-17c6-4f16-8fe4-1a018f5ed00d | OUTBOUND | salesshare | table | public.tickit_sales_redshift | 123456789012 | 13b8833d-17c6-4f16-8fe4-1a018f5ed00d | OUTBOUND | salesshare | schema | public | t 123456789012 | 13b8833d-17c6-4f16-8fe4-1a018f5ed00d | OUTBOUND | salesshare | view | public.sales_data_summary_view | ``` The following example displays the outbound datashares in a producer cluster. ``` SHOW DATASHARES LIKE 'sales%'; ``` The output looks similar to the following. ``` share_name | share_owner | source_database | consumer_database | share_type | createdate | is_publicaccessible | share_acl | producer_account | producer_namespace -----------+--------------+-----------------+-------------------+------------+---------------------+----------------------+-----------+------------------+--------------------------------------- salesshare | 100 | dev | | OUTBOUND | 2020-12-09 02:27:08 | True | | 123456789012 | 13b8833d-17c6-4f16-8fe4-1a018f5ed00d ``` For more information, see [DESC DATASHARE](r_DESC_DATASHARE.md) and [SHOW DATASHARES](r_SHOW_DATASHARES.md). You can also use [SVV\$1DATASHARES](r_SVV_DATASHARES.md), [SVV\$1DATASHARE\$1CONSUMERS](r_SVV_DATASHARE_CONSUMERS.md), and [SVV\$1DATASHARE\$1OBJECTS](r_SVV_DATASHARE_OBJECTS.md) to view the datashares, the objects within the datashare, and the datashare consumers. ------ # Editing datashares created in your account in Amazon Redshift Editing a datashare You can edit a datashare created in your account using the console and with SQL. ------ #### [ Console ] On the console, take the following steps to connect to a database first to see the list of datashares created in your account. 1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/). 1. On the navigation menu, choose **Clusters**, then choose your cluster. The cluster details page appears. 1. Choose **Datashares**. 1. In the **Datashares created in my account** section, choose **Connect to database**. 1. Choose the datashare you want to edit, then choose **Edit**. The datashare details page appears. 1. Make any changes in the **Datashare objects** or **Data consumers** section. 1. Choose **Save changes**. Amazon Redshift updates your datashare with the changes. **Note** If you chose to publish your datashare to the AWS Glue Data Catalog, you can't edit the configuration to publish the datashare to other Amazon Redshift accounts. ------ #### [ SQL ] Use ALTER DATASHARE to remove objects from datashares at any point from the datashare. To remove a schema, use the following command: ``` ALTER DATASHARE salesshare REMOVE SCHEMA PUBLIC; ``` To remove a table, use the following command: ``` ALTER DATASHARE salesshare REMOVE TABLE public.tickit_sales_redshift; ``` Use REVOKE USAGE ON to revoke permissions on the datashare to certain consumers. It revokes USAGE permissions on objects within a datashare and instantly stops access to all consumer clusters. Listing datashares and the metadata queries, such as listing databases and tables, doesn't return the shared objects after access is revoked. Revoke access to the datashare from namespaces if you don't want to share the data with the consumers anymore. ``` REVOKE USAGE ON DATASHARE salesshare FROM NAMESPACE '13b8833d-17c6-4f16-8fe4-1a018f5ed00d'; ``` If you don't want to share the data with the consumers anymore, revoke access to the datashare from AWS accounts: ``` REVOKE USAGE ON DATASHARE salesshare FROM ACCOUNT '123456789012'; ``` ------ # Removing authorization from a datashare in Amazon Redshift Removing authorization from a datashare With Amazon Redshift, you can control access to datashares by revoking authorization for specified consumers. This sections provides instructions for revoking consumer access to your datashares in Amazon Redshift. **Note** To remove authorization for the datashare, there must be at least one data consumer added to the datashare. ------ #### [ Console ] Choose one or more consumer clusters that you want to remove authorization from. Then, choose **Remove authorization**. After authorization is removed, data consumers lose access to the datashare immediately. ------ #### [ API ] The producer security administrator determines the following: + Whether or not another account can have access to the datashare. + If an account has access to the datashare, whether or not that account has write permissions. The following IAM permissions are required to deauthorize a datashare: **redshift:DeauthorizeDataShare** You can deauthorize usage and writes using either a CLI call or with the API: ``` deauthorize-data-share --data-share-arn --consumer-identifier ``` For more information about the command, see [deauthorize-data-share](https://docs.aws.amazon.com/cli/latest/reference/redshift/deauthorize-data-share.html). ------ # Removing datashare objects from a datashare in Amazon Redshift Removing datashare objects from a datashare You can remove one or more objects from a datashare by using the following procedure. ------ #### [ Console ] To remove one or more objects from a datashare on the consoe, follow these steps. 1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/). 1. On the navigation menu, choose **Clusters**, then choose your cluster. The cluster details page appears. 1. Choose **Datashares**. 1. In the **Datashares created in my account** section, choose **Connect to database**. For more information, see [Connecting to a database](connect-database-console.md). 1. Choose the datashare you want to edit, then choose **Edit**. The datashare details page appears. 1. To remove one or more datashare objects to the datashare, do one of the following: + To remove schemas from the datashare, choose one or more schemas. Then choose **Remove**. Amazon Redshift removes the specified schemas and all the objects of the specified schemas from the datashare. + To remove tables and views from the datashare, choose one or more tables and views. Then choose **Remove**. Alternatively, choose **Remove by schema** to remove all tables and views in the specified schemas. + To remove user-defined functions from the datashare, choose one or more user-defined functions. Then choose **Remove**. Alternatively, choose **Remove by schema** to remove all user-defined functions in the specified schemas. ------ #### [ SQL ] Use ALTER DATASHARE to remove objects from datashares at any point from the datashare. To remove a schema, use the following command: ``` ALTER DATASHARE salesshare REMOVE SCHEMA PUBLIC; ``` To remove a table, use the following command: ``` ALTER DATASHARE salesshare REMOVE TABLE public.tickit_sales_redshift; ``` ------ # Removing data consumers from a datashare in Amazon Redshift Removing data consumers from a datashare You can remove one or more data consumers from a datashare. Data consumers can be namespaces that uniquely identified Amazon Redshift clusters or AWS accounts. ------ #### [ Console ] To remove one or more data consumers from a datashare on the console, choose one or more data consumers either from the namespace IDs or AWS account. Then, choose **Remove**. Amazon Redshift removes the specified data consumers from the datashare. They lose access to the datashare immediately. ------ #### [ SQL ] Use REVOKE USAGE ON to revoke permissions on the datashare to certain consumers. It revokes USAGE permissions on objects within a datashare and instantly stops access to all consumer clusters. Listing datashares and the metadata queries, such as listing databases and tables, doesn't return the shared objects after access is revoked. Revoke access to the datashare from namespaces if you don't want to share the data with the consumers anymore. ``` REVOKE USAGE ON DATASHARE salesshare FROM NAMESPACE '13b8833d-17c6-4f16-8fe4-1a018f5ed00d'; ``` ------ # Deleting a datashare created in your account in Amazon Redshift Deleting a datashare You can delete a datashare created in your account using the console or with SQL. ------ #### [ Console ] To delete a datashare created in your account using the console, first connect to a database to see the list of datashares created in your account. 1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/). 1. On the navigation menu, choose **Clusters**, then choose your cluster. The cluster details page appears. 1. Choose **Datashares**. The datashare list appears. 1. In the **Datashares created in my account** section, choose **Connect to database**. 1. Choose one or more datashares you want to delete, then choose **Delete**. The Delete datashares page appears. Deleting a datashare shared with Lake Formation doesn't automatically remove the associated permissions in Lake Formation. To remove them, go to the Lake Formation console. 1. Type **Delete** to confirm deleting the specified datashares. 1. Choose **Delete**. After datashares are deleted, datashare consumers lose access to the datashares. ------ #### [ SQL ] You can use SQL to delete the datashare objects at any point using [DROP DATASHARE](r_DROP_DATASHARE.md). Cluster superusers and owners of datashare can drop datashares. The following example drops a datashare named `salesshare`. ``` DROP DATASHARE salesshare; ``` ------ # Consumer actions for existing datashares in Amazon Redshift Consumer actions for existing datashares With Amazon Redshift, you can manage existing datashares to control access to your data in an Amazon Redshift cluster. The following sections provide step-by-step guidance on managing datashares in your Amazon Redshift environment as a consumer administrator. **Topics** + [ # Managing permissions for a datashares in Amazon Redshift ](writes-managing-permissions.md) + [ # Removing association of a datashare from data consumers in a different AWS account in Amazon Redshift ](writes-disassociating-datashare.md) + [ # Declining a datashare from a different AWS account in Amazon Redshift ](writes-declining-datashare.md) # Managing permissions for a datashares in Amazon Redshift Managing permissions for a datashare As a producer administrator, you retain control for the datasets you are sharing. You can add new objects to or remove them from the datashare. You can also grant or revoke access to datashares as a whole for the consumer clusters, AWS accounts, or AWS Regions. When permissions are revoked, consumer clusters immediately lose access to the shared objects and stop seeing them in the list of INBOUND datashares in SVV\$1DATASHARES. The following example creates the datashare `salesshare`, adds the schema `public`, and adds the table `public.tickit_sales_redshift` to `salesshare`. It also grants usage permissions on `salesshare` to the specified namespace. ``` CREATE DATASHARE salesshare; ALTER DATASHARE salesshare ADD SCHEMA public; ALTER DATASHARE salesshare ADD TABLE public.tickit_sales_redshift; GRANT USAGE ON DATASHARE salesshare TO NAMESPACE '13b8833d-17c6-4f16-8fe4-1a018f5ed00d'; ``` For CREATE DATASHARE, superusers and database owners can create datashares. For more information, see [CREATE DATASHARE](r_CREATE_DATASHARE.md). For ALTER DATASHARE, the owner of the datashare with the required permissions on the datashare objects to be added or removed can alter the datashare. For information, see [ALTER DATASHARE](r_ALTER_DATASHARE.md). As a producer administrator, when you drop a datashare, it stops being listed on consumer clusters. The databases and schema references created on the consumer cluster from the dropped datashare continue to exist with no objects in them. The consumer administrator must delete these databases manually. On the consumer side, a consumer administrator can determine which users and roles should get access to the shared data by creating a database from the datashare. Depending on the options you choose when creating the database, you can control access to it as follows. For more information about creating a database from a datashare, see [CREATE DATABASE](r_CREATE_DATABASE.md). For more information about setting up a datashare and reading data from a consumer, see [Sharing read access to data within an AWS account](https://docs.aws.amazon.com/redshift/latest/dg/within-account.html). **Creating the database without the WITH PERMISSIONS clause** An administrator can control access at the database or schema level. To control access at the schema level, the administrator must create an external schema from the Amazon Redshift database created from the datashare. The following example grants permissions to access a shared table at the database level and schema level. ``` GRANT USAGE ON DATABASE sales_db TO Bob; CREATE EXTERNAL SCHEMA sales_schema FROM REDSHIFT DATABASE sales_db SCHEMA 'public'; GRANT USAGE ON SCHEMA sales_schema TO ROLE Analyst_role; ``` To further restrict access, you can create views on top of shared objects, exposing only the necessary data. You can then use these views to give access to the users and roles. After the users are granted access to the database or schema, they will have access to all shared objects in that database or schema. **Creating the database with the WITH PERMISSIONS clause** After granting usage rights on the database or schema, an administrator can further control access using the same permission granting process as they would on a local database or schema. Without individual object permissions, users can’t access any objects in the datashared database or schema even after being granted the USAGE permission. The following example grants permissions to access a shared table at the database level. ``` GRANT USAGE ON DATABASE sales_db TO Bob; GRANT USAGE FOR SCHEMAS IN DATABASE sales_db TO Bob; GRANT SELECT ON sales_db.public.tickit_sales_redshift TO Bob; ``` After being granted access to the database or schema, users still need to be given the relevant permissions for any objects in the database or schema that you want them to access. ## Granular sharing using WITH PERMISSIONS You can use granular sharing using WITH PERMISSIONS to enable clusters or Serverless workgroups to query the datashare. This process assumes the datashare is originating from another cluster or Amazon Redshift Serverless namespace in your account, or it is coming from another account and has been associated with the namespace you are using. 1. The consumer database administrator can create a database from the datashare. ``` CREATE DATABASE my_ds_db [WITH PERMISSIONS] FROM DATASHARE my_datashare OF NAMESPACE 'abc123def'; ``` If you create a database WITH PERMISSIONS, you can grant granular permissions on datashare objects to different users and roles. Without this, all users and roles granted USAGE permission on the datashare database are granted all permissions on all objects within the datashare database. 1. The following shows how to grant permissions to a Redshift database user or role. You must be connected to a local database to run these statements. You cannot run these statements if you execute a USE command on the datashare database before running the grant statements. ``` GRANT USAGE ON DATABASE my_ds_db TO ROLE data_eng; GRANT CREATE, USAGE ON SCHEMA my_ds_db.my_shared_schema TO ROLE data_eng; GRANT ALL ON ALL TABLES IN SCHEMA my_ds_db.my_shared_schema TO ROLE data_eng; GRANT USAGE ON DATABASE my_ds_db TO bi_user; GRANT USAGE ON SCHEMA my_ds_db.my_shared_schema TO bi_user; GRANT SELECT ON my_ds_db.my_shared_schema.table1 TO bi_user; ``` # Removing association of a datashare from data consumers in a different AWS account in Amazon Redshift Removing association of a datashare from data consumers With Amazon Redshift, you can remove association from datashares shared by other AWS accounts. Datashares are shareable database objects that encapsulate data from one or more Redshift databases. The following sections demonstrate the process of disassociating datashares within your Redshift environment. ------ #### [ Console ] As a consumer administrator, you can remove association of datashares from data consumers on the console. 1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/). 1. On the navigation menu, choose **Datashares**. The datashare list page appears. 1. Choose **From other accounts**. 1. In the **Datashares from other accounts** section, choose the datashare to remove association from data consumers. 1. In the **Data consumers** section, choose one or more data consumers to remove association from. Then choose **Remove association**. 1. When the Remove association page appears, choose **Remove association**. After association is removed, data consumers will lose access to the datashare. You can change the data consumer association at any time. ------ #### [ SQL ] **Note** The steps in this section are performed after the producer administrator grants specific actions on the shared database objects and, if the datashare is being shared with another account, the producer security administrator authorizes access. The consumer security administrator can disassociate the datashare with the following command: ``` disassociate-data-share-consumer --data-share-arn ``` For more information about the command, see [disassociate-data-share-consumer](https://docs.aws.amazon.com/cli/latest/reference/redshift/disassociate-data-share-consumer.html). ------ # Declining a datashare from a different AWS account in Amazon Redshift Declining a datashare With Amazon Redshift, you can decline datashares shared by other AWS accounts, enabling seamless and secure data sharing across organizational boundaries. Datashares are shareable database objects that encapsulate data from one or more Amazon Redshift databases. As a consumer administrator, you can reject any datashare whose state is available or active. After you reject a datashare, consumer cluster users lose access to the datashare. Amazon Redshift doesn't return the rejected datashare if you call the `DescribeDataSharesForConsumer` API operation. If the producer administrator runs the `DescribeDataSharesForProducer` API operation, they will see that the datashare was rejected. Once a datashare is rejected, the producer administrator can authorize the datashare to a consumer cluster again, and the consumer administrator can choose to associate their AWS account with the datashare or reject it. If your AWS account has an association to a datashare and a pending association to a datashare that's managed by Lake Formation, rejecting the datashare association that's managed by Lake Formation also rejects the original datashare. To reject a specific association, the producer administrator can remove authorization from a specified datashare. This action doesn't affect other datashares. To reject a datashare, use the AWS console, the API operation `RejectDataShare`, or `reject-datashare` in the AWS CLI. ------ #### [ Console ] To reject a datashare using the AWS console, perform the following steps. 1. Sign in to the AWS Management Console and open the Amazon Redshift console at [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/). 1. In the navigation menu, choose **Datashares**. 1. Choose **From other accounts**. 1. In the **Datashares from other accounts** section, choose the datashare you want to decline. When the **Decline datashare** page appears, choose **Decline**. After you decline the datashares, you can't revert the change. Amazon Redshift removes the datashares from the list. To see the datashare again, the producer administrator must authorize it again. ------ #### [ CLI ] To reject a datashare, the administrator uses the following command: ``` reject-data-share --data-share-arn ``` For more information about the command, see [reject-data-share](https://docs.aws.amazon.com/cli/latest/reference/redshift/reject-data-share.html). ------