# Cross-account data sharing decision matrix

Pick the **mechanism** by what the consumer actually needs — not by which service
you already bought. Copying S3 objects per account is the failure mode this matrix
avoids.

> Capabilities reflect mid-2026. Lake Formation **cross-account version 5** (Feb 11,
> 2026) uses wildcard RAM shares for large table counts. Confirm current version and
> region support in the Lake Formation console before committing.

## 1. "I need analysts in account B to query tables that live in account A's lake"

| Consumer need | Use | Notes |
|---------------|-----|-------|
| Column/table access on Glue Data Catalog + S3 (no copy) | **Lake Formation** grants (LF-Tags preferred) | Producer registers S3 in LF; grants via LF-Tag expression or named resource; consumer accepts RAM share and creates **resource links** |
| Many tables (100k+) across accounts | **Lake Formation v5** cross-account upgrade | Single RAM share with wildcard patterns — upgrade via console/API before bulk grants |
| Warehouse-native sharing (Redshift → Redshift) | **Amazon Redshift data sharing** | Datashares for Redshift consumers; not a substitute for lake/catalog sharing |
| Analytics without revealing row-level PII | **AWS Clean Rooms** | Collaborative queries with differential privacy / analysis rules — different job than LF grants |

**Rule:** **RAM shares the catalog link; Lake Formation grants the data permission.**
A RAM accept alone does not make tables queryable — LF grants and resource links must
align.

## 2. "I need to enforce who can touch our data from outside the org"

| Goal | Use | Evaluates against |
|------|-----|-------------------|
| Block external principals on S3/DynamoDB/etc. | **RCP** (Resource Control Policy) | The resource — even anonymous/external callers |
| Cap what your IAM roles can do | **SCP** | The caller's identity |
| Column-level catalog permissions | **Lake Formation** + **LF-Tags** | Data Catalog resource + principal |

Layer all three for a data perimeter — see
[cross-account patterns](/blog/aws-cross-account-patterns-beyond-landing-zone-2026/)
for RCP rollout order.

## 3. "I need governed discovery and stewardship metadata"

| Goal | Use | Notes |
|------|-----|-------|
| Business glossary, lineage, subscription workflows | **Amazon DataZone** | Complements LF; not a replacement for LF S3 location registration |
| Security log normalization | **Amazon Security Lake** | OCSF security data — different domain than analytics lake sharing |

## When NOT to use Lake Formation sharing

- **Don't** copy curated Parquet to consumer buckets "for simplicity" — you lose
  centralized revocation and double storage cost.
- **Don't** use cross-account IAM role assumption to S3 when LF-TBAC can express
  the grant — role chains are harder to audit than LF grants + LF-Tags.
- **Don't** grant `IAM_ALLOWED_PRINCIPALS` on LF-registered resources — it bypasses
  LF enforcement for IAM users/roles in the same account.
- **Don't** enable LF-Tags without a tag taxonomy workshop — orphan tags become
  permission sprawl within a quarter.

## Rollout order (query-safe)

1. Producer: register S3 locations in Lake Formation; disable `IAMAllowed` on those paths.
2. Define LF-Tag keys (`Environment`, `Sensitivity`, `Domain`) — max one value per key per resource.
3. Pilot **named-resource** share to one NonProd consumer account.
4. Migrate to **LF-TBAC** grants with `Grant with LF-Tag expressions` for scale.
5. Upgrade to **cross-account version 5** before granting 1,000+ tables.
6. Add **RCP data perimeter** on producer S3 after partner integration inventory.
7. Consumer: accept RAM share → create resource links → verify Athena/Spark queries.

Full walkthrough:
[Secure cross-account data sharing on AWS](/blog/aws-secure-cross-account-data-sharing-lake-formation-2026/).