---
title: Secure Cross-Account Data Sharing on AWS (2026): Lake Formation, LF-Tags, and Data Mesh Without Copying the Lake
description: Copying curated Parquet into every consumer account is how data platforms drown in storage cost and permission sprawl. On Feb 11, 2026 AWS shipped Lake Formation cross-account version 5 — wildcard RAM shares for hundreds of thousands of tables. A composite 12-account platform cut duplicate curated copies from 3 to 0 and dropped cross-account access tickets from ~11/month to ~3 by standardizing LF-Tags + resource links.
url: https://www.factualminds.com/blog/aws-secure-cross-account-data-sharing-lake-formation-2026/
datePublished: 2026-06-24T00:00:00.000Z
dateModified: 2026-06-24T00:00:00.000Z
author: palaniappan-p
category: Data & Analytics
tags: aws, aws-lake-formation, data-lake, amazon-athena, aws-glue, multi-account, data-governance
---

# Secure Cross-Account Data Sharing on AWS (2026): Lake Formation, LF-Tags, and Data Mesh Without Copying the Lake

> Copying curated Parquet into every consumer account is how data platforms drown in storage cost and permission sprawl. On Feb 11, 2026 AWS shipped Lake Formation cross-account version 5 — wildcard RAM shares for hundreds of thousands of tables. A composite 12-account platform cut duplicate curated copies from 3 to 0 and dropped cross-account access tickets from ~11/month to ~3 by standardizing LF-Tags + resource links.

**On February 11, 2026, AWS shipped Lake Formation cross-account version 5** — wildcard RAM resource shares that scale to hundreds of thousands of tables without per-table RAM associations. That matters because the default multi-account data pattern — **copy curated Parquet into every consumer account** — doubles storage, forks lineage, and turns revocation into a forensic exercise. Lake Formation was built to share **permissions on the catalog and S3 locations**, not copies of the bytes.

This post is the data-sharing layer after your [landing zone](/blog/aws-multi-account-strategy-landing-zone-best-practices/) and [cross-account networking/guardrail patterns](/blog/aws-cross-account-patterns-beyond-landing-zone-2026/) exist. For semantic views over the lake, see [virtual data modeling](/blog/aws-virtual-data-modeling-guide/). We ship a [data sharing decision matrix](https://www.factualminds.com/examples/architecture-blog-2026/secure-data-sharing/data-sharing-decision-matrix.md), [LF-Tag grant skeleton](https://www.factualminds.com/examples/architecture-blog-2026/secure-data-sharing/lf-tag-policy-example.json), and [cross-account query checklist](https://www.factualminds.com/examples/architecture-blog-2026/secure-data-sharing/cross-account-query-checklist.md).

> **Benchmark pattern (not a cited client)** — Composite multi-account data platform, **12 AWS accounts**, centralized **Glue Data Catalog** in a dedicated data account, **3 consumer accounts** (finance analytics, product BI, ML feature store) needing column-level access to a **~4 TB curated zone** on S3. Prior pattern: monthly ETL copies into each consumer bucket (**~12 TB duplicated** across accounts, **~$280/mo** incremental Standard storage at us-east-1 rates, plus Glue crawler sprawl). After LF-TBAC + resource links: **0 duplicate curated copies**, cross-account access tickets dropped from **~11/month → ~3/month** (remainder were KMS key policy gaps, not LF logic). Athena scan waste fell **~18%** in the finance account because analysts stopped querying stale copied partitions.

## Four jobs — four mechanisms

| Job                                   | Mechanism                                 | Wrong default                 |
| ------------------------------------- | ----------------------------------------- | ----------------------------- |
| Share catalog + S3 paths without copy | **Lake Formation** + RAM + resource links | Cross-account IAM role to S3  |
| Warehouse-native consumer             | **Redshift datashares**                   | LF resource links on Redshift |
| Untrusted collaborator analytics      | **AWS Clean Rooms**                       | LF grant to external account  |
| Block outsiders on producer S3        | **RCP** data perimeter                    | Bucket policy alone           |

**Opinionated take:** **LF-Tags over named resources** once you pass ~50 tables or 3+ consumer teams. Named grants are fine for pilots; they do not scale with daily table churn. **RAM is not authorization** — it is discovery transport for the catalog share.

## Producer setup (data account)

1. **Register S3 locations** in Lake Formation for curated and published zones — not the entire org's raw landing bucket on day one.
2. **Revoke `IAMAllowedPrincipals`** on LF-managed databases/tables so IAM cannot bypass LF on those paths.
3. **Define LF-Tag keys** — we use three to start: `Environment`, `Sensitivity`, `Domain`. Lake Formation allows **one value per key per resource**; plan cardinality accordingly.
4. **Assign LF-Tags** to databases/tables (cannot assign at resource creation time — automate via Glue crawler post-hook or IaC).
5. **Grant cross-account** with an LF-Tag expression (`Environment=Production` AND `Sensitivity=Internal`) to the consumer account ID or OU.
6. **Upgrade to cross-account v5** before bulk grants if you expect **1,000+ tables** — console/API upgrade, announced **Feb 11, 2026**.

Pair with [KMS CMK strategy](/blog/aws-kms-encryption-architecture-cmk-strategy-2026/) when curated data uses SSE-KMS — consumer roles need key policy **and** LF grants.

## Consumer setup (analyst account)

1. **Accept RAM share** (same-org shares often auto-accept).
2. **Create resource links** for each database/table analysts will reference in SQL — queries use **link names**, not producer names.
3. Register Athena/Spark execution roles as **Lake Formation data lake principals** with `SELECT`/`DESCRIBE` via inherited LF-Tag grants.
4. Run the [checklist artifact](https://www.factualminds.com/examples/architecture-blog-2026/secure-data-sharing/cross-account-query-checklist.md) — `SELECT 1` should fail with SQL errors, not Glue `AccessDenied`.

Context for smoke test — AWS CLI 2.x, consumer analyst role:

```bash
aws lakeformation list-permissions --catalog-id <PRODUCER_ACCOUNT_ID>
aws athena start-query-execution \
  --query-string 'SELECT count(*) FROM <resource_link_db>.<resource_link_table> LIMIT 1' \
  --work-group primary
```

## LF-Tags vs named resources

| Criterion                | LF-Tags (TBAC)              | Named resources        |
| ------------------------ | --------------------------- | ---------------------- |
| Table count              | Hundreds → millions         | Pilots, <50 tables     |
| New table onboarding     | Automatic if tags applied   | Manual grant per table |
| Partner outside taxonomy | Awkward                     | Explicit ARNs          |
| Audit question           | "Who has Internal Finance?" | "Who has table X?"     |

Download the [decision matrix](https://www.factualminds.com/examples/architecture-blog-2026/secure-data-sharing/data-sharing-decision-matrix.md) for Redshift datashare and Clean Rooms rows.

> **What broke** — Week 2 of a LF-TBAC rollout. Finance analysts hit `AccessDenied` on Athena; IAM policy simulator showed **Allow** on S3 and Glue. Root cause: queries referenced `producer_db.gl_balances` instead of the **resource link** `finance_curated_link.gl_balances`, and the Athena workgroup role was never registered in Lake Formation. Detection: `aws lakeformation list-permissions` returned empty for the role. Fix: resource links + `GrantPermissions` for the role as `DataLakePrincipalIdentifier` — **not** an S3 policy change. **IAM-looking errors with LF lakes are usually LF registration gaps.**

## Layer the data perimeter (RCP)

Lake Formation governs **authorized consumers inside your org**. [RCPs](/blog/aws-cross-account-patterns-beyond-landing-zone-2026/) govern **who can touch the S3 objects at all** — including principals bucket policies might accidentally allow. Roll RCP on the **NonProd OU** first; watch CloudTrail `AccessDenied` for partner pipelines before attaching at root.

## Rollout order (lockout-safe)

1. NonProd producer + one NonProd consumer — **named resource** grant (learn RAM + links).
2. Enable LF-Tags on curated zone only — not raw landing.
3. Migrate grants to LF-Tag expressions; enable `Grant with LF-Tag expressions` for delegated admins if needed.
4. Upgrade to **v5**; scale grants to remaining consumer accounts.
5. Add RCP on producer data OU after integration inventory.

## What to do this week

1. Inventory **duplicate curated buckets** per consumer — count TB and monthly storage cost.
2. Confirm producer S3 paths are **Lake Formation registered**; list any `IAMAllowedPrincipals` still enabled.
3. Pilot **one table** cross-account with named grant + resource link + Athena probe.
4. Draft LF-Tag keys with data owners — three keys max for v1.
5. If table count > 1,000, schedule **v5 upgrade** before bulk grants.

## What this post doesn't cover

- **Amazon DataZone** subscription workflows and business glossary — see [DataZone governance](/blog/amazon-datazone-enterprise-governance/); DataZone complements LF, does not replace location registration.
- **AWS Clean Rooms** collaborative SQL — different trust model than in-org LF sharing.
- **QuickSight row-level security** — dataset RLS is separate from LF column grants.
- **Row-level LF cell-level security** — advanced; start with table/column grants.
- **Click-by-click Glue crawler setup** — [data lake architecture guide](/blog/building-a-data-lake-on-aws-s3-glue-athena-architecture/).

**Related:** [Cross-account patterns](/blog/aws-cross-account-patterns-beyond-landing-zone-2026/) · [Virtual data modeling](/blog/aws-virtual-data-modeling-guide/) · [KMS architecture](/blog/aws-kms-encryption-architecture-cmk-strategy-2026/) · [Data lake on S3/Glue/Athena](/blog/building-a-data-lake-on-aws-s3-glue-athena-architecture/) · [Data analytics services](/services/aws-data-analytics/)

## FAQ

### What is the difference between RAM sharing and Lake Formation grants for data lakes?
AWS RAM establishes the cross-account visibility of Glue Data Catalog resources — the consumer account can see that a database or table exists. Lake Formation grants determine whether principals in the consumer account can actually SELECT or DESCRIBE those resources, and whether LF-Tags filter which tables match. RAM without LF grants produces catalog entries that fail at query time with AccessDenied. LF grants without RAM acceptance never appear in the consumer catalog. You need both, plus resource links in the consumer account for analysts to query with Athena or Spark.

### When should we use LF-Tags instead of named-resource grants?
Use LF-Tags (tag-based access control) when you have dozens or thousands of tables and consumers should inherit access by attributes — Environment=Production, Sensitivity=Internal, Domain=Finance — rather than by enumerating every table ARN. Use named-resource grants for one-off shares to a partner account outside your tag taxonomy, or when piloting with fewer than ~20 tables before your LF-Tag keys are stable. LF-Tags require upfront taxonomy discipline; named resources are faster to pilot but rot when new tables ship without grants.

### When should we NOT use Lake Formation cross-account sharing?
Skip LF sharing when consumers need a physical copy for regulatory isolation (air-gapped analytics), when workloads are Redshift-to-Redshift (use datashares instead), or when collaboration requires row-level privacy controls across untrusted parties (consider AWS Clean Rooms). Also avoid LF if your producer data is not registered in Lake Formation — mixing IAM-only S3 policies with LF-registered paths in the same bucket creates dual permission models that confuse auditors.

### What changed in Lake Formation cross-account version 5?
Announced February 11, 2026, version 5 lets Lake Formation set up a single RAM resource share with wildcard patterns for an unlimited number of tables to another account, eliminating per-resource-type association limits that made large-scale sharing operationally painful. Upgrade via the Lake Formation console or API before issuing bulk cross-account grants. Existing shares continue to work; new grants use wildcard RAM patterns automatically after upgrade.

### How do RCPs interact with Lake Formation shared data?
Resource Control Policies bound what can be done to your resources regardless of who calls — including external principals that bucket policies might allow. A data perimeter RCP on producer S3 can deny reads from outside your organization even if a misconfigured bucket policy would permit them. Lake Formation grants still govern catalog-level SELECT/DESCRIBE for in-org consumers. Layer RCP on the producer OU after inventorying legitimate partner access; trial on NonProd first — see the cross-account patterns post for rollout order.

### What could go wrong during consumer onboarding?
The most common failure: analysts query the producer database name directly instead of a resource link in the consumer account, or the Athena workgroup role is not registered as a Lake Formation data lake principal. Symptom is AccessDenied that looks like an IAM error. Fix: create resource links, register the role in LF, re-run grants, and probe with the checklist artifact. Second common failure: IAMAllowedPrincipals still enabled on producer tables — bypasses LF for same-account IAM and masks missing LF grants in tests.

---

*Source: https://www.factualminds.com/blog/aws-secure-cross-account-data-sharing-lake-formation-2026/*