Hi @Kirsten,
I've checked internally. Based on what you described, this appears most consistent with the AWS credential/cross-account role validation failing early in workspace creation, rather than a later-stage workspace issue.
Can you verify the following?
- When you create the cross-account role in AWS, the trusted Databricks AWS account should be 414351767826, and the required External ID should be your Databricks account ID from the account console, not your AWS account ID.
- Databricks validates the credential configuration when you add the role in the account console, and a 400 at that step can indicate an invalid ARN or incorrect role permissions.
- If your AWS organisation uses SCPs or permission boundaries, please make sure they do not block sts:AssumeRole or the required EC2/VPC actions. Databricks docs explicitly note that cross-account role setup can fail even when the IAM policy itself looks correct if SCPs deny AssumeRole or EC2/VPC access.
- If you are using a Databricks-managed VPC, the role needs EC2/VPC provisioning permissions such as ec2:CreateVpc, ec2:CreateSubnet, ec2:CreateRouteTable, and related actions used during initial workspace setup.
If the workspace is still stuck in PROVISIONING and cannot be deleted from the account console, please open a Databricks Support case and include:
- Databricks account ID
- Workspace ID or deployment name
- AWS region
- The exact 400 response body / error text from the credential configuration step
- Whether you are using Databricks-managed VPC or customer-managed VPC
- Whether SCPs / permission boundaries are enforced in the AWS account
That will let Support inspect the failed provisioning attempt and help with cleanup or next steps.
If this answer resolves your question, could you mark it as “Accept as Solution”? That helps other users quickly find the correct fix.
Regards,
Ashwin | Delivery Solution Architect @ Databricks
Helping you build and scale the Data Intelligence Platform.
***Opinions are my own***