How to fix the "AccessDeniedException" for ram:AssociateResourceSharePermission after upgrading Lake Formation cross-account sharing from V3 to V5

---

You've just upgraded your AWS Lake Formation cross-account settings from Version 3 to Version 5, and now you're getting an AccessDeniedException when trying to grant cross-account permissions. Here's how to fix it.

What's happening?

After upgrading Lake Formation cross-account sharing from Version 3 to Version 5, you might see this error when granting permissions on databases that were shared before the upgrade:

An error occurred (AccessDeniedException) when calling the GrantPermissions operation:
User: arn:aws:sts::<account-id>:assumed-role/<role-name>/<session>
is not authorized to perform: ram:AssociateResourceSharePermission
on resource: arn:aws:ram:<region>:<account-id>:resource-share/<share-id>
because no identity-based policy allows the ram:AssociateResourceSharePermission action
(Service: AWSRAM; Status Code: 403; Error Code: AccessDeniedException)

You'll hit this error when all three of these are true:

1. You upgraded from cross-account version 3 (or lower) to version 4 or above.
2. Your account has RAM resource shares that were created before the upgrade.
3. Your cross-account permission grantor role uses a custom IAM policy — not the AWS managed policy AWSLakeFormationCrossAccountManager.

⚠️ Heads up: There's no going back. AWS Lake Formation doesn't support downgrading from Version 5 to a lower version.

Why does this happen?

When Lake Formation upgrades to Version 5, it changes how managed permissions get attached to RAM resource shares. The key difference is when the share was created:

Scenario	When the RAM share was created	What happens	Extra permissions needed?
A	After the V5 upgrade	Lake Formation attaches the right managed permission at creation time. No issue.	❌ No
B	Before the V5 upgrade	Lake Formation needs to associate a new managed permission onto the older share — and that requires ram:AssociateResourceSharePermission.	✅ Yes

This is why the same grant operation might work for one database but fail for another in the same account. It's all about whether the underlying RAM share was created before or after the upgrade.

The good news? This is a one-time fix. Once the managed permission is updated on the legacy RAM share, you won't need ram:AssociateResourceSharePermission for that share again.

How to fix it

Step 1: Check if you're using the managed policy

First, see if your cross-account role already has the AWS managed policy attached:

aws iam list-attached-role-policies --role-name <your-cross-account-role-name>

• If AWSLakeFormationCrossAccountManager is attached — you shouldn't need extra permissions. The managed policy already covers this. Something else might be going on.
• If you're using a custom policy — move on to Step 2.

Step 2: Add the missing RAM permissions

Add these permissions to your cross-account grantor role's IAM policy:

{
  "Sid": "LakeFormationRAMCrossAccountPermissions",
  "Effect": "Allow",
  "Action": [
    "ram:AssociateResourceShare",
    "ram:DisassociateResourceShare",
    "ram:GetResourceShares",
    "ram:AssociateResourceSharePermission",
    "ram:DisassociateResourceSharePermission",
    "ram:UpdateResourceShare"
  ],
  "Resource": "*",
  "Condition": {
    "StringLike": {
      "ram:ResourceShareName": "LakeFormation*"
    }
  }
}

What each action does:

Action	Why it's needed
ram:AssociateResourceSharePermission	Attaches the new managed permission to the legacy RAM share
ram:DisassociateResourceSharePermission	Removes the old managed permission if needed
ram:UpdateResourceShare	Updates share properties during the permission migration
ram:AssociateResourceShare	Associates resources with the share
ram:DisassociateResourceShare	Removes resources from the share
ram:GetResourceShares	Reads share metadata for validation

💡 Tip: The Condition block scopes these permissions to RAM shares named LakeFormation* only — so you're following least privilege while giving Lake Formation what it needs.

Step 3: Retry the grant

Now try your cross-account permission grant again:

aws lakeformation grant-permissions \
  --principal DataLakePrincipalIdentifier=arn:aws:iam::<consumer-account-id>:role/<role-name> \
  --resource '{"Database":{"Name":"<database-name>"}}' \
  --permissions "ALL" \
  --region <region>

Step 4: Confirm it worked

Verify the permission is in place:

aws lakeformation list-permissions \
  --resource-type DATABASE \
  --region <region>

No more AccessDeniedException — you're good to go.

FAQ

Q: Does this apply to RAM resources created before July 2023?

Yes. The Lake Formation team has confirmed this policy update works for RAM resources created before July 2023. The documentation mentions that accounts created before that date need permissions reshared at least once — the fix above takes care of that.

Q: Will upgrading to V5 break my third-party tools (Databricks, Snowflake, dbt, Starburst, etc.)?

No. Version 5 adds new capabilities — it doesn't remove or change anything that would break existing integrations. Your third-party tools will continue working as expected.

Q: I tried to reproduce this in a test account with the same V3→V5 upgrade, but didn't get the error. Why?

The error only shows up when Lake Formation hits a RAM share with an outdated managed permission version. If your test account's shares were recently created or already have the latest managed permission, the ram:AssociateResourceSharePermission call never fires — so no error.

Q: Can I roll back to Version 3 if something goes wrong?

No. Once you upgrade to Version 5, there's no downgrade path. This is a service-level restriction. Always test the upgrade in non-production environments first.

Related resources

• Optimizing cross-account sharing with AWS RAM
• Cross-account version differences
• Required permissions for updating cross-account version settings
• Sharing a Lake Formation resource using hybrid access mode
• Hybrid access mode prerequisites
• AWSLakeFormationCrossAccountManager managed policy
• Sharing Glue Data Catalog databases and tables cross-account with Lake Formation

---