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

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 and cross-account networking/guardrail patterns exist. For semantic views over the lake, see virtual data modeling. We ship a data sharing decision matrix, LF-Tag grant skeleton, and cross-account query checklist.

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

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 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 — SELECT 1 should fail with SQL errors, not Glue AccessDenied.

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

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

Download the decision matrix 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 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; 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.

Related: Cross-account patterns · Virtual data modeling · KMS architecture · Data lake on S3/Glue/Athena · Data analytics services