Post Syndicated from Maneesh Sharma original https://aws.amazon.com/blogs/big-data/enable-cross-region-fine-grained-data-access-with-aws-lake-formation-and-trusted-identity-propagation/

Organizations that store analytics data on AWS often need two things at once. The first is fine-grained access control that limits each person to only the data they are authorized to see. The second is auditability down to the individual user level so that every query is traceable to the person who ran it rather than to a shared AWS Identity and Access Management (IAM) role.

AWS IAM Identity Center Trusted Identity Propagation (TIP) meets both requirements. A user signs in once, and that identity propagates from the client application through the query engine to Lake Formation and the storage layer, so that every request is authorized as the actual user and every query is logged in AWS CloudTrail.

AWS now extends TIP across Regions: IAM Identity Center replicates its identity objects such as users, groups, and session information to every AWS Region that you choose, so services across the stack can recognize the same user identity even when they span different Regions.

This is Part 1 of a three-part series. This post covers the foundation and querying from Amazon SageMaker Unified Studio (Amazon Athena and Amazon Redshift). Part 2 covers Amazon Quick, and Part 3 covers Amazon EMR.

Overview

In this post, the producer shares data from the Asia Pacific (Sydney) Region (ap-southeast-2) and the consumer queries it from the South America (São Paulo) Region (sa-east-1) as themselves. We cover two cases that follow the same pattern. In Case 1, you share Amazon Simple Storage Service (Amazon S3) data governed by Lake Formation, queried from Amazon SageMaker Unified Studio (Athena). In Case 2, you share Amazon Redshift data through a datashare registered to the AWS Glue Data Catalog, queried from Amazon Redshift Serverless.

Figure 1: Cross-Region and cross-account architecture

Starting on the left of the diagram, your identity provider syncs users and groups into AWS IAM Identity Center through the System for Cross-domain Identity Management (SCIM) protocol. Running as an organization instance in the management account, IAM Identity Center replicates those identities to every Region in use. In the center, the producer account in Sydney uses AWS Lake Formation to centrally govern both Amazon S3 and Amazon Redshift data. When the producer shares a table or database, that share flows to the consumer account in São Paulo, shown on the right, where a resource link makes the shared data queryable as if it were local. On the right, the data analyst signs in to Amazon SageMaker Unified Studio with corporate credentials. With Trusted Identity Propagation enabled, the analyst’s identity travels with every request to Lake Formation. Lake Formation authorizes each query based on who the user is rather than which IAM role they assumed.

The example uses three accounts across three Regions. The producer account runs Amazon S3, AWS Glue Data Catalog, Lake Formation, and Amazon Redshift Serverless in ap-southeast-2 (Sydney). The consumer account queries from sa-east-1 (São Paulo) using SageMaker Unified Studio or Amazon Redshift. IAM Identity Center runs in us-east-1 (Virginia) in the management account.

Cross-account sharing through Lake Formation can span AWS Organizations, but the TIP integration adds a tighter requirement. For the user’s identity to propagate, the producer and consumer accounts must be in the same organization and share the same organization instance of IAM Identity Center. You can repeat the consumer steps to add more accounts or Regions. With this launch, you can query that shared data from a different Region while Lake Formation authorizes every request as the actual user.

How the pieces fit together

Four capabilities underpin this architecture. IAM Identity Center provides a single identity plane across Regions, so the same users and groups are available in every account. Each service in the stack supports Trusted Identity Propagation, so the user’s identity flows from the client application to Lake Formation without falling back to IAM roles. Corporate sign-in through IAM Identity Center makes that identity available across Regions and accounts within the organization. Finally, AWS Resource Access Manager (AWS RAM) shares and resource links bridge the Region gap so the consumer can query data cataloged in the producer’s Region.

Prerequisites

Before you begin, make sure that you have the following in place:

• The producer account and consumer account are in the same organization.
• An organization instance of IAM Identity Center, with users and groups provisioned.
• IAM Identity Center replicated to every Region where you operate. See Deploy AWS applications and access AWS accounts across multiple Regions with IAM Identity Center.
• You have permissions to administer AWS Lake Formation, AWS Glue, AWS RAM, Amazon Simple Storage Service (Amazon S3), Amazon SageMaker Unified Studio, and Amazon Redshift in the relevant accounts.
• In the producer Lake Formation Data catalog settings, the Use only IAM access control options should be cleared.
• The AWS services used in this post are integrated with AWS IAM Identity Center in both the producer and consumer accounts, across the Regions used in this walkthrough. See Trusted identity propagation use cases for more information.

Case 1: Share S3 data (Lake Formation)

In this case, the S3 data and its catalog stay in the producer’s account and Region the whole time, with Lake Formation governing them in Sydney (ap-southeast-2). What crosses Regions is the query itself. The consumer, in a different account, connects from São Paulo (sa-east-1) and queries that same data through Amazon Athena (through SageMaker Unified Studio). This is a federated query pattern: the data stays in place, and only the query crosses Regions. That split (catalog and data in one Region, client and query in another) is what makes this genuinely cross-Region, not just cross-account.

Part 1: Producer account (Sydney, ap-southeast-2)

Region note: the walkthrough uses ap-southeast-2 (producer) and sa-east-1 (consumer and query). Substitute your own Regions and account IDs where you see placeholders. All cross-account Lake Formation grants must be made in the producer Region. The only exception is the resource link and its Describe grant, which are created in the consumer’s query Region.

Step 1.1: Create the sample data file

Create a file named customers.csv with the following content.

customer_id,first_name,last_name,email,city,state,signup_date
1,Martha,Rivera,[email protected],Seattle,WA,2024-01-15
2,Jane,Doe,[email protected],Portland,OR,2024-02-20
3,Mateo,Jackson,[email protected],Denver,CO,2024-03-10
4,Saanvi,Sarkar,[email protected],Austin,TX,2024-04-05
5,Mary,Major,[email protected],Chicago,IL,2024-05-12

Step 1.2: Create an S3 bucket and upload the data

1. Open the Amazon S3 console in the producer account (ap-southeast-2).
2. Choose Create bucket, enter a unique name (for example, amzn-s3-demo-sydney-lakehouse-bucket), and choose Create bucket.
3. Open the bucket, create a folder named customers, and upload customers.csv into it.

Step 1.3: Create the Lake Formation registration role (with sts:SetContext)

Create an IAM role that Lake Formation assumes to read the S3 bucket. This role is used when registering the data lake location and for vending credentials, including for TIP. Don’t use the Lake Formation service-linked role. It doesn’t include sts:SetContext.

1. Open the IAM console, choose Roles, then Create role.
2. For Trusted entity type, choose Custom trust policy and paste the following trust policy.
3. Choose Next, skip attaching managed policies, and choose Next.
4. Name the role (for example, LakeFormation-DataLocation-role) and choose Create role.
5. Open the role, choose Add permissions, then Create inline policy, and paste the following permissions policy.
6. Name the inline policy (for example, LF-S3Access) and save it.

Trust policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "lakeformation.amazonaws.com" },
      "Action": [
        "sts:AssumeRole",
        "sts:SetContext"
      ]
    }
  ]
}

Permissions policy (replace the bucket name):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket",
        "s3:GetBucketLocation"
      ],
      "Resource": [
        "arn:aws:s3:::<your-s3-bucket>",
        "arn:aws:s3:::<your-s3-bucket>/*"
      ]
    }
  ]
}

Note: The sts:SetContext action in the trust policy is required for TIP. The Lake Formation service-linked role doesn’t include it, which is why a custom role is required here.

Step 1.4: Register the S3 location in Lake Formation

1. Open the Lake Formation console in ap-southeast-2.
2. Under Administration, choose Data lake locations, then Register location.
3. For Amazon S3 path, enter your bucket path (for example, s3://amzn-s3-demo-sydney-lakehouse-bucket).
4. For IAM role, choose the LakeFormation-DataLocation-role created in Step 1.3.
5. For Permission mode, choose Lake Formation, then choose Register location.

Step 1.5: Create the AWS Glue database

1. In the Lake Formation console, under Data catalog, choose Databases.
2. Choose Create database.
3. Enter the database name, for this post sydney_lakehouse, and choose Create database.

Step 1.6: Create the table manually

1. Open the AWS Glue console in ap-southeast-2.
2. Under Data Catalog, choose Tables, Add table, then Add table manually.
3. For Table name, enter customers.
4. For Database, choose sydney_lakehouse.
5. For the data store, choose Amazon S3 and set the location to s3://amzn-s3-demo-sydney-lakehouse-bucket/customers/.
6. For the data format, choose CSV with comma (,) as the delimiter.
7. Define the schema using the following columns.
8. Add the table property skip.header.line.count with value 1 to skip the CSV header row.
9. Review and choose Create.

When you create the table as CSV on the console, define all columns as string. The CSV serializer/deserializer used for this table doesn’t parse typed columns such as date or bigint reliably. Cast values in your queries as needed (for example, CAST(signup_date AS date)).

Step 1.7: Grant DATABASE permission to the external (consumer) account

1. In the Lake Formation console, choose Permissions, Data lake permissions, then Grant.
2. Under Principals, choose External accounts and enter the consumer account ID (<CONSUMER_ACCOUNT_ID>).
3. Choose Named Data Catalog resources. For Databases, choose your database, in this post sydney_lakehouse.
4. For Database permissions, select Describe, and select Describe under Grantable permissions.
5. Choose Grant.

Step 1.8: Grant TABLE permission to the external (consumer) account

1. Choose Permissions, Data lake permissions, then Grant.
2. Under Principals, choose External accounts and enter <CONSUMER_ACCOUNT_ID>.
3. Choose Named Data Catalog resources. For Databases choose sydney_lakehouse. For Tables choose customers.
4. For Table permissions, select Select and Describe, and select the same under Grantable permissions.
5. Choose Grant.

Step 1.9: Grant DATABASE permission to the IAM Identity Center group/user

1. Choose Permissions, Data lake permissions, then Grant.
2. Under Principals, choose IAM Identity Center and select the group or user (for example, admin).
3. Choose Named Data Catalog resources. For Databases choose your database, in this post sydney_lakehouse.
4. For Database permissions, select Describe.
5. Choose Grant.

Step 1.10: Grant TABLE permission to the IAM Identity Center group/user

1. Choose Permissions, Data lake permissions, then Grant.
2. Under Principals, choose IAM Identity Center and select the group or user (for example, admin).
3. Choose Named Data Catalog resources. For Databases choose your database and table, in this post sydney_lakehouse and for Tables choose customers.
4. For Table permissions, select Select and Describe.
5. Choose Grant.

Note: Because the accounts share one organization instance of IAM Identity Center, the producer can grant the IAM Identity Center group directly on the underlying table. The consumer only grants Describe on the local resource link (Step 2.3).

At this point, the producer side is complete. You have the necessary Lake Formation permissions for both the consumer account and your users. To verify, open Data lake permissions in the Lake Formation console and confirm you see four grants covering the database and table.

Part 2: Consumer account

In this part, you switch to the consumer account to accept the AWS RAM share, create a resource link that points back to the shared database, and grant your users access to it. After these steps, the consumer account is ready to query the producer’s data from a different Region.

Step 2.1: Accept the AWS RAM share (Sydney Region)

1. Open the AWS RAM console and switch to ap-southeast-2 (Sydney).
2. Under Shared with me, choose Resource shares.
3. Select the resource share from the producer account and choose Accept resource share.

Step 2.2: Create the resource link (sa-east-1 Region)

1. Open the Lake Formation console and switch to sa-east-1.
2. Under Data catalog, choose Databases, then Create resource link.
3. For Resource link name, enter a name, for example rl_sydney_s3_datalake.
4. For Shared database’s Region, choose Asia Pacific (Sydney) ap-southeast-2.
5. For Shared database, choose your database. In this post the database is called sydney_lakehouse.
6. Shared database’s catalog ID populates automatically (the producer account).
7. Choose Create.

Step 2.3: Grant Describe on the resource link to the IAM Identity Center group/user

1. In the Lake Formation console (sa-east-1), choose Permissions, Data lake permissions, then Grant.
2. Under Principals, choose IAM Identity Center and select the group or user (for example, admin).
3. Choose Named Data Catalog resources. For Databases choose rl_sydney_s3_datalake.
4. For Resource link permissions, select Describe.
5. Choose Grant.

Part 3: SageMaker Unified Studio (sa-east-1)

With the producer and consumer accounts configured, you now set up SageMaker Unified Studio in the query Region and run the cross-Region query.

Step 3.1: Create the SageMaker Unified Studio domain

Open the Amazon SageMaker console in sa-east-1, choose Unified Studio, then Create domain. See the SageMaker Unified Studio administration guide for the quick setup. Because your IAM Identity Center integration is already complete, you can specify an IAM Identity Center user in the domain configuration settings.

Figure 2: Adding an SSO user in the Amazon SageMaker Unified Studio domain

To enable Trusted Identity Propagation (TIP) in SageMaker Unified Studio, refer to the following sections in this post:

1. Enable TIP in SageMaker Unified Studio.
2. Enable user access for SageMaker Unified Studio domain.
3. Add project members.
4. Create a SQL analytics project in Unified Studio. For this post, we use the project name my_project_idc.

Step 3.2: Enable TIP

1. Sign in to the SageMaker Unified Studio portal by choosing Sign in with SSO as an IAM Identity Center user.

Figure 3: Sign in with SSO in Amazon SageMaker Unified Studio

2. Open the project (my_project_idc) and go to the Query Editor.
3. Under Catalogs, choose AwsDataCatalog.
4. Choose rl_sydney_s3_datalake, then tables, and then select customers.
5. Choose the three dots next to the customers table and choose Preview data.

Figure 4: Access Amazon S3 data in Amazon SageMaker Unified Studio

The query auto-runs using the Athena compute, as shown in the following screenshot:

SELECT * FROM "AwsDataCatalog"."rl_sydney_s3_datalake"."customers" LIMIT 10;

Figure 5: Preview Amazon S3 data in Amazon SageMaker Unified Studio

The customer data from the producer S3 bucket in Sydney is returned, governed by Lake Formation and accessed through the resource link in sa-east-1, with the user identity propagated through TIP.

Case 2: Share Amazon Redshift data using AWS Glue federated catalog

This case follows the same centralized-catalog pattern as Case 1, but the consumer queries the data with Amazon Redshift Serverless instead of Athena. The analyst runs these queries from SageMaker Unified Studio using its Amazon Redshift query experience.

Part 1: Producer account (Sydney, ap-southeast-2)

Make sure that your Amazon Redshift consumer cluster is configured with IAM Identity Center in both ap-southeast-2 and sa-east-1 Regions. If you need to review the procedure, see Integrate Identity Provider (IdP) with Amazon Redshift Query Editor V2 using AWS IAM Identity Center for seamless Single Sign-On.

Step 1.1: Register a serverless namespace to the AWS Glue Data Catalog

1. Open the Amazon Redshift console.
2. On the navigation menu, choose Redshift Serverless. The Namespaces / Workgroups section shows your namespaces and workgroups for the current Region.
3. Choose the name of the namespace you want to register.
4. From Actions, choose Register to AWS Glue Data Catalog.

Figure 6: Amazon Redshift Serverless namespace to register with the AWS Glue Data Catalog

5. Choose Do not register with Amazon Redshift federated permissions.
6. Select Use AWS Lake Formation permissions.
7. For Destination account ID, enter the producer account ID (<PRODUCER_ACCOUNT_ID>), the account that will hold the catalog.
8. Choose Register. You are taken to the AWS Lake Formation console.

Figure 7: Register the Amazon Redshift Serverless namespace with the AWS Glue Data Catalog

9. Follow the catalog creation process in Lake Formation. See Creating Amazon Redshift federated catalogs and follow these steps:
   1. Review a namespace invitation and accept it.
   2. Create a federated catalog.

Step 1.2: Grant DATABASE permission to the external (consumer) account

1. In the Lake Formation console (ap-southeast-2), choose Permissions, Data lake permissions, then Grant.
2. Under Principals, choose External accounts and enter <CONSUMER_ACCOUNT_ID>.
3. Choose Named Data Catalog resources. For Catalogs/Databases, choose the federated database (for example, ns-redshift/dev, schema sales_schema).
4. For Database permissions, select Describe (and Describe under Grantable permissions).
5. Choose Grant.

Step 1.3: Grant TABLE permission to the external (consumer) account

1. Choose Permissions, Data lake permissions, then Grant.
2. Under Principals, choose External accounts and enter <CONSUMER_ACCOUNT_ID>.
3. Choose Named Data Catalog resources and select the shared table (for example, store_sales).
4. For Table permissions, select Select and Describe (and the same under Grantable permissions).
5. Choose Grant.

Step 1.4: Grant DATABASE permission to the IAM Identity Center group/user

1. Choose Permissions, Data lake permissions, then Grant.
2. Under Principals, choose IAM Identity Center and select the group or user.
3. Choose Named Data Catalog resources and select the federated database (schema).
4. For Database permissions, select Describe.
5. Choose Grant.

Step 1.5: Grant TABLE permission to the IAM Identity Center group/user

1. Choose Permissions, Data lake permissions, then Grant.
2. Under Principals, choose IAM Identity Center and select the group or user.
3. Choose Named Data Catalog resources and select the shared table (for example, store_sales).
4. For Table permissions, select Select and Describe.
5. Choose Grant.

Part 2: Consumer account

At this point, the producer side for Case 2 is complete. To verify, open Data lake permissions in the Lake Formation console and confirm you see four grants covering the federated database and shared table.

In this part, you switch to the consumer account to accept the AWS RAM share, configure the IAM role for cross-Region Amazon Redshift access, and set up TIP so that users can query the producer’s Amazon Redshift data from a different Region.

Step 2.1: Accept the AWS RAM share (Sydney Region)

1. Open the AWS RAM console and switch to ap-southeast-2.
2. Under Shared with me, choose Resource shares.
3. Select the resource share from the producer account and choose Accept resource share.

Step 2.2: Update the trust relationship for the IAM role

Navigate to the IAM role (IAMIDCRedshiftRole) created in this post.

Make sure the trust policy includes Amazon Redshift and Amazon Redshift Serverless for sts:AssumeRole and sts:SetContext, as shown in the following policy:

Trust policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "redshift.amazonaws.com" },
      "Action": ["sts:AssumeRole", "sts:SetContext"]
    },
    {
      "Effect": "Allow",
      "Principal": { "Service": "redshift-serverless.amazonaws.com" },
      "Action": ["sts:AssumeRole", "sts:SetContext"]
    }
  ]
}

Step 2.3: Add a new policy to the IAM role

Navigate to the IAM role (IAMIDCRedshiftRole) created in this post and add the following policy for AWS Glue and Lake Formation.

Permissions policy 1 (AWS Glue read and Lake Formation data access):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "GlueGetTable",
      "Effect": "Allow",
      "Action": [
        "glue:GetTable",
        "glue:GetTables",
        "glue:GetDatabase",
        "glue:GetDatabases",
        "glue:GetPartition",
        "glue:GetPartitions"
      ],
      "Resource": "*"
    },
    {
      "Sid": "LakeFormationDataAccess",
      "Effect": "Allow",
      "Action": [
        "lakeformation:GetDataAccess",
        "lakeformation:GetTemporaryGlueTableCredentials"
      ],
      "Resource": "*"
    }
  ]
}

Note: These actions require "Resource": "*" because they are used for catalog-level discovery, which does not support resource-scoped permissions. Lake Formation column-level and row-level grants still enforce least-privilege access to the underlying data.

Step 2.4: Set up cross-Region Trusted Identity Propagation (TIP) access in Amazon Redshift

1. Sign in to the Amazon Redshift console using the admin role.
2. Navigate to Query Editor V2.
3. Choose the options menu (three dots) next to the cluster and choose Create connection.
4. Connect as the admin user and run the following command to create an external schema that points to your cross-Region AWS Glue Data Catalog:

Syntax:

CREATE EXTERNAL SCHEMA <schema_name>
FROM DATA CATALOG
DATABASE '<glue_db_name>'
REGION '<producer region where glue Data Catalog lives>'
CATALOG_ID '<catalog_name>';

Example:

CREATE EXTERNAL SCHEMA redshift_cross_region_tip
FROM DATA CATALOG
DATABASE 'sales_schema'
REGION 'ap-southeast-2'
CATALOG_ID '123456789012:ns-producer-redshift-syd/dev';

You can get this catalog_name information from the producer account Lake Formation in the Sydney Region. Navigate to Databases on the left and choose the respective Amazon Redshift catalog ID from the drop-down.

Figure 8: AWS Lake Formation showing the catalog ID of the Amazon Redshift namespace registered with the AWS Glue Data Catalog

5. Grant the IAM Identity Center group access to the external schema.

GRANT USAGE ON schema redshift_cross_region_tip TO ROLE "AWSIDC:admin";

Step 2.5: Query the data from Amazon Redshift Query Editor V2

1. In Query Editor V2, choose the options menu (three dots) next to the cluster and choose Edit connection, and for authentication, select IAM Identity Center.
2. A pop-up redirects you to your IdP login page. Enter your IdP credentials.
3. After successful authentication, you are redirected to Query Editor V2 as an IAM Identity Center user.
4. Run the following query.

SELECT * FROM "dev"."redshift_cross_region_tip"."store_sales";

Figure 9: Query cross-Region, cross-account data using Amazon Redshift Query Editor V2

Step 2.6: Query the data from SageMaker Unified Studio

For a consumer cluster to use in SageMaker Unified Studio, you need to tag the Amazon Redshift cluster or workgroup with one of the following options. Choose one before proceeding.

Option 1 – Add a tag to allow only a specific SageMaker Unified Studio project to access it: AmazonDataZoneProject=<projectID>

Option 2 – Add a tag to allow all SageMaker Unified Studio projects in this account to access it: for-use-with-all-datazone-projects=true

After the Amazon Redshift cluster or workgroup has a tag, continue with the following steps.

1. Sign in to the SageMaker Unified Studio portal by choosing Sign in with SSO as an IAM Identity Center user.
2. In SageMaker Unified Studio, navigate to Query Editor and expand Connections.
3. Choose redshift_cross_region_tip, then tables, and then select store_sales.
4. Choose the three dots next to the store_sales table and choose Preview data. The query auto-runs using the Amazon Redshift compute, as shown in the following screenshot:

Figure 10: Query data using Amazon Redshift compute in Amazon SageMaker Unified Studio

The Amazon Redshift data shared from the producer in Sydney is returned. It is governed and centralized in one account and Region (ap-southeast-2) using Lake Formation and accessed from the consumer account in a second Region (sa-east-1), with the user identity propagated through TIP.

Both cases use the same Region split. The catalog and the data stay in the producer Region (Sydney), and only the client and the query run from the consumer Region (São Paulo). They differ only in the query engine. Case 1 uses Amazon Athena, and Case 2 uses Amazon Redshift Serverless. That difference in engine is also what changes their cross-Region behavior. With Athena (Case 1), queries work cross-Region without additional constraints. However, if you use an Amazon Redshift datashare, the Amazon Redshift query engine must be in the same Region as the Amazon Redshift namespace.

Clean up

To avoid ongoing charges, remove the resources that you created.

Consumer account:

1. Delete the SageMaker Unified Studio project and domain (Case 1).
2. Delete the Amazon Redshift Serverless workgroup and namespace (Case 2).
3. In Lake Formation (sa-east-1), delete the resource links (rl_sydney_s3_datalake, rl_redshift_cross_db_tip).
4. Revoke any Lake Formation grants you created and, if applicable, leave/deny the AWS RAM share.

Producer account:

1. Revoke the Lake Formation grants to the consumer account and to the IAM Identity Center group.
2. Revoke the AWS RAM share.
3. Deregister the S3 data lake location, and delete the customers table and the sydney_lakehouse database.
4. Empty and delete the S3 bucket.
5. Deregister the Amazon Redshift namespace from the AWS Glue Data Catalog and delete the federated catalog (Case 2).
6. Delete the IAM roles you created (LakeFormation-DataLocation-role, IAMIDCRedshiftRole).

Conclusion

In this post, you configured AWS Lake Formation Trusted Identity Propagation so that data governed and shared in one Region (Sydney) can be queried from another Region (São Paulo). Lake Formation cross-account grants are made in the producer Region, and the consumer reaches the shared data from the query Region in the way that fits each engine. For Amazon S3 data queried through Amazon Athena (Case 1), the consumer creates a resource link in the query Region that points back to the shared database. For Amazon Redshift data shared through a datashare and AWS Glue federated catalog (Case 2), the consumer instead creates an external schema in Amazon Redshift that references the producer’s Glue Data Catalog directly in the producer Region. No resource link is required. In both cases, because access is authorized against the user’s IAM Identity Center identity rather than a shared role, you get least-privilege access, per-user auditability in AWS CloudTrail, and a single place to manage permissions.

To add more consumer accounts or query Regions, repeat the consumer-side steps for the relevant case: accept the AWS RAM share in the producer Region, then either create a resource link in the query Region and grant Describe on it to your IAM Identity Center principals (Amazon S3 and Athena), or create an external schema that references the producer’s Glue catalog and grant usage to your IAM Identity Center principals for Amazon Redshift.

As a next step, review the Trusted Identity Propagation supported applications and services to plan which services in your stack to enable with TIP, using the Lake Formation cross-account sharing documentation as a reference.

About the authors