AWS re:Invent 2025 - Simplify permissions management across Amazon Redshift warehouses (ANT350)

🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.

Overview

📖 AWS re:Invent 2025 - Simplify permissions management across Amazon Redshift warehouses (ANT350)

In this video, Sandeep Adwankar introduces Amazon Redshift Federated Permissions, a new feature that simplifies permission management across multiple data warehouses. The solution allows permissions to be defined once in a producer warehouse and automatically enforced across all consuming warehouses through AWS Glue Data Catalog registration. It supports fine-grained access controls including data masking, row-level security, and column-level access using global identities via IAM roles or IAM Identity Center. A live demo demonstrates how a marketing warehouse can share data with a sales warehouse, applying masking and row-level policies without requiring configuration on the consumer side. The feature enables horizontal scalability and auto-mounting of databases, eliminating the need for manual data share creation. Available in Redshift patch version 1.97.

; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.

Main Part

Introducing Amazon Redshift Federated Permissions: Simplifying Multi-Warehouse Data Access

Hello everyone. Welcome to the session, Lightning Talk ANT350, Simplifying Permission Management for Amazon Redshift Warehouses. This is a new launch, so we are launching Amazon Redshift Federated Permissions that will enable customers to simplify the permission management. I'm Sandeep Adwankar. I'm a Product Manager for AWS and really excited to talk about this new launch.

Amazon Redshift is Amazon's cloud data warehouse. It provides high scalability across petabyte-scale warehouses. It provides 2x price performance improvements compared to any other warehouse solutions in the market, and it provides access to data across multiple data sets for multiple use cases. What customers are also using is they're building multiple warehouses. As the data is increasing, they want to add additional warehouses, and that's where the multi-warehouse architecture becomes important.

Customers can now have data for different use cases, for example, reporting dashboards or exploratory analytics or streaming and batch, in different clusters or warehouses at the same time, keeping those workloads isolated and having the ability to manage those separately, have the cost attribution, and have a way to start those and manage those very quickly. What we wanted to do with this is to simplify this multi-warehouse architecture, and to do that, what we wanted to do was basically simplify the governance.

For this launch, we thought about what if we can make all the warehouses' data accessible for any new warehouse that comes in. For example, you have a new warehouse in the blue, which is the marketing warehouse. You have the marketing data, but these marketing analysts want to access the data across all your other warehouses, right? So your warehouses could be your data science or streaming or others. How can that marketing analyst role start accessing the data without creating an additional set of permissions? What if the access is based on the existing permissions model?

So let's say you have in your different warehouses you applied permissions for roles, for groups, for row level or masking level for the marketing analyst role. Those permissions should be enforced without doing anything, right? And then lastly, we want to ensure that the access is based on who you are rather than what you connect to, right?

As me, as a marketing analyst with my role, I should be able to access the data from any warehouse based on the permissions that are provided to that particular role. So with that in mind, we are really excited to announce Amazon Redshift Federated Permissions. It provides simplified permission management across your multiple warehouses. You define your permissions once where your data is, and it's enforced across all your warehouses.

You can apply your existing set of Redshift permissions models, for example, fine-grained access models such as data masking, column level access, row level access, and those will be applied and enforced as you query in any different warehouse. This provides you improved user experience.

Instead of creating data shares, you register your warehouse once into a global catalog, and now all these warehouses will be auto-mounted in all the clusters. And this provides the horizontal scalability, right?

With the warehouses, you are now bringing the warehouse very quickly, but with this permissions model, you're also getting the data share and getting access across the different warehouses.

And we know that some of the customers already are using local permissions models for specific clusters, and for them this provides an incremental path where their existing permissions on their local users continue to work, but you can have the global identity-based new model working as well. So the high level architecture looks like this where you have multiple warehouses.

These warehouses will be registered in the common catalog, which in AWS's case is AWS Glue Data Catalog. And the new thing is you can, on that Glue Data Catalog, apply Redshift Federated Permissions, and those permissions will be enforced in each of the warehouses as you make the queries. And you can apply different permission models, whether it's table level, coarse-grained, masked data, column, row level, or cell level. Any of these permission models will be applied, and the data is managed through Redshift Managed Storage based on these.

Core Concepts: Producer Warehouses, Global Identity, and Two-Phase Authorization

Based on these three concepts, let me explain a couple of key ideas here. If you have data that you want to share, all you have to do is register with the AWS Glue Data Catalog. This is also called a producer warehouse. If you want to access the data, it's a consuming warehouse. In that case, you don't have to really do anything. The warehouses will be auto-mounted, and now you can start querying the data from those warehouses based on the permissions that you have.

The second concept here is global identity, because we are talking about multiple warehouses. The local identity, which is on a per-cluster basis, is something that we want to migrate customers from to global identity. The two global identity models that customers use are, first, the IAM role, and second, they may have their own Okta or some other identity provider, which they can bring those IDP roles into the IAM Identity Center and then apply the permissions on the IDC roles. Whether you use IAM role or IDC user, in both cases, it's a trusted identity propagation. So the identity as it moves follows the propagation through the trusted services path, and it's always logged and available for auditing purposes.

And one of the last concepts is authorization. It's a two-phase authorization. So you are making calls from warehouse one to warehouse N. Warehouse N, where your data is, is where your policy stays, and the policies are validated at the warehouse end. Then warehouse one, where you're actually making the query, is where the permissions are enforced. So if you have data masking, the columns will be masked at warehouse one, and all the coarse-grain and fine-grain access control permissions will apply, for example, row-level security or column-level or dynamic masking support.

So for admins, what do they have to do to register a warehouse? All they have to do is use a one-click option to register their warehouse in the AWS Glue Data Catalog. Just by registering, it creates the federated catalog on the Glue catalog side. For example, here it shows there are multiple warehouses, and as they register, the corresponding federated catalog gets created. This federated catalog is auto-mounted on all the warehouses in your account. So you have the auto-mounting happening there.

Now, as the analyst or anyone who makes a query, the authentication and the token information is propagated through the trusted identity path. So in this case, if you're making a query from warehouse one to warehouse N, it passes that token and authorization information through a trusted identity through the Glue catalog to the warehouse end where the verification happens. The policy is collected, the policy is sent back to warehouse one, where it's actually getting enforced.

Live Demonstration: Implementing Data Masking and Row-Level Security Across Warehouses

All right, so let's look at a demo. This is a new launch, so the demo will help in understanding. For this demo, think about there being two warehouses. There's a marketing warehouse and there's a sales warehouse. The sales warehouse is new. They wanted to get access to the marketing warehouse, so the marketing warehouse, all they have to do is start registering their warehouse with the Glue catalog. So it's a one-time thing.

And the way it works is a simple option. You have the warehouse already created. You go into the actions, and there is an option there to register with the Glue catalog. So you select that option, and if you just use the default, you can go and register it. There's another checkbox there where you can check that box, and it will allow you to set up the IDC as the second identity model. So that's the checkbox over there if you have to do that.

So once it's registered, they can go and verify it. For example, here you can see that the Glue catalog is registered and the permissions model is registered permissions model. So now it is already part of the catalog, and they can go and start adding the tables. So in this case, the marketing team wants to create a new table, let's say a credit card table, and they want to apply a masking policy because they don't want to expose the credit card number to the consumers or whoever is accessing the data. So how do they go about doing that? Let's look at the path of creating it. Let me walk through that.

So first, as part of the explorer, we are showing the Query Editor V2.

The admin is creating the table. In this case, it's creating a simple table of credit card. Then it's adding certain data which includes the credit card numbers in it. So now the data is populated. Now it's creating a masking policy where the credit card number is masked. Now it's attaching the masking policy to the particular credit card table for a particular role. Let's say the analyst role. For admin, if they do a SQL query, they can see the credit card numbers. So for admin they have full access.

Now that they have created that masking policy, they decide to grant access, and granting the access is as simple as they just want to grant select access to the analyst role. So now that completes the administrative part of the marketing admin, which is they have gone and created, registered the table with the AWS Glue Data Catalog, created the table, added the data to it, created the policies, and shared the access.

Now what do I have to do on the sales warehouse side to get access to the data? The answer is sales admins don't have to do anything. Sales analyst will just go to their favorite editor, which is, for example, here they're using the Query Editor V2 and start querying it. So when they query the data, the query path, as I explained before, goes from the warehouse one to warehouse and they see the masked data there. So here is the read-only analyst role, and they are able to see the different auto-mounted databases here. And for this particular auto-mounted database, they found this table that marketing just created, and for this table they're just going to query it.

So this query that is being run on the sales warehouse is making calls to this table in the marketing warehouse. The policy stays with the marketing warehouse getting enforced in the sales warehouse. So that is the path there. And as it is enforced, the masking policy is enforced. No masking setup needed on the sales side. So then there is some governance changes and there's a new rule on these new compliance policies where the marketing admin has to apply additional policies. If the analyst is from a state of California, they should only get access to rows which are from the consumers in the state of California.

So to apply that across multiple warehouses, previously you would have to apply those policies across multiple warehouses. With this, they will have to do it only once. So in this case, to apply that policy, they will have to create the row level policy, attach the row level policy, and enable the row level policy. So these are the three steps. So let's look at that. So the admin logs in. In this case it's creating the row level security policy where the state is California. It is attaching the row level security policy where it's providing the table name and the role, and then it's turning on the row level security policy. The row level security policy is now enabled on that particular table.

So now that the policy is set up, sales analyst just goes there and starts querying it. Now this particular table has now two policies. It has a masking policy and it has row level policies. So the output that they will get is the combination of these two policies. So they will continue to have masked results as you can see, but the rows are only for the state of California. So you have these multiple policies that are applied on the producer side, on the marketing side. You don't need explicit data shares, but those are enforced on each of the warehouses.

So let's recap this demo. So what we just saw was there's a simplified registration setup. Marketing admin was able to just register with the AWS Glue Data Catalog as part of the registration option. If they want to create a cluster as part of cluster creation, the similar option applies. So it's the default option that gets a warehouse registered with the AWS Glue Data Catalog. The granular access control compliance, the policies that are needed, data masking and row level security for the credit card information, was applied by the marketing warehouse.

These warehouses don't need to be configured on any of the consuming warehouses. Once the policies are applied on the producer warehouse, they just apply automatically. There was an improved user experience when the sales analyst went and accessed the data. He saw the auto-mounted warehouses, the tables were already accessible, and he could just query the data. When he queried the data, those policies were enforced so that he would only see the output which is compliant to the policies.

Lastly is the horizontal scalability. You can spin up these clusters and warehouses in minutes, and now you don't even have to apply or create additional permissions and policies and shares and users and groups and all those things. That complexity goes away because now you have the ability to access it without additional work on the sales side.

All right, so this is a new launch. It's currently getting rolled out as part of Redshift 1.97 patch version. So when you create a cluster and if you see the Redshift patch 1.97, you will have access to it and you can start using this capability. We have a documentation page that provides end-to-end information about how you can go and apply all this set of permissions, how you can apply the IAM configurations. What I didn't show in the demonstration is the IDC path, and it's also very easy to set up.

We provided a wizard for you to walk through it, so this documentation provides an easy way for you to set up the producers, set up the consumer clusters, and get going on building your warehouses. So thank you for coming to this talk. This is a new feature. We'd like to advise you to start out and see how it works and provide feedback. There is a survey in the mobile app, so please provide the feedback of the session there. Thank you.

---

; This article is entirely auto-generated using Amazon Bedrock.