Connection troubleshooting

Connection problems usually fall into a few predictable categories: trust policy misconfiguration, wrong External ID, missing IAM permissions, or organization-level guardrails. This guide covers the failures we see most often during onboarding verification and early scans.

"Access denied" or "Not authorized to perform sts:AssumeRole" during verify

Cause: Parsivex cannot assume your role — the trust relationship is missing, incorrect, or blocked.

Fix:

1. Go to IAM → Roles → your Parsivex role (default name: ParsivexReadOnly)

2. Open the Trust relationships tab → Edit trust policy

3. Verify the policy matches the trust relationship on our security page:

   • Principal must be arn:aws:iam::PARSIVEX-ACCOUNT-ID:root (use the Parsivex account ID from your dashboard)
   • Action must include sts:AssumeRole
   • Condition must include sts:ExternalId set to your External ID

4. Save and click Test connection again in Parsivex

If you deployed with CloudFormation or Terraform, re-check that ParsevixAccountId / parsivex_account_id and ExternalId / external_id were set correctly at deploy time. See Deploy with CloudFormation or Terraform.

Trust policy External ID mismatch ("Invalid External ID")

Cause: The External ID in your IAM trust policy does not match the value Parsivex sends when assuming the role.

Fix:

1. Copy the External ID from the Parsivex onboarding wizard or Integrations → AWS connections
2. Go to IAM → Roles → your Parsivex role → Trust relationships
3. Update the sts:ExternalId condition to match exactly — same casing, no extra spaces or quotes
4. Re-test the connection

Each Parsivex workspace has its own External ID. If you recreated the AWS connection in Parsivex, you may need to update the trust policy with the new value. Read External ID explained for background.

"Role does not exist" or "Invalid ARN"

Cause: The Role ARN entered in Parsivex is wrong, truncated, or points to a deleted role.

Fix:

1. Go to IAM → Roles and confirm the role exists
2. Copy the full ARN from the role summary page — it must start with arn:aws:iam::
3. Paste into Parsivex with no extra spaces or line breaks
4. If you renamed the role during IaC deployment, use the ARN from your CloudFormation Outputs tab or terraform output role_arn

Missing permissions during verify or scan

Cause: The role exists and Parsivex can assume it, but the attached policy does not grant the read-only actions Parsivex needs.

Fix:

1. Go to IAM → Roles → your Parsivex role → Permissions
2. Confirm a read-only policy is attached — either:
   • The Parsivex minimal policy from our security page, or
   • The policy created by the CloudFormation/Terraform templates (ParsivexReadOnlyPolicy)
3. If missing, attach the policy from /security or redeploy the IaC template

The minimal policy grants read-only access to Cost Explorer, CloudWatch, EC2, RDS, ELB, DynamoDB, Lambda, and S3 bucket metadata. It cannot create, modify, or delete resources.

Partial scan warnings due to permission gaps

Cause: Verification succeeded (Parsivex can assume the role), but some AWS APIs returned access denied during the scan. The scan still completes, but you may see Partial scan — some data was unavailable warnings on your report.

Common examples:

Partial scans do not fail your connection — they mean some finding types were skipped. After fixing permissions, run a new scan to pick up the missing coverage.

Organization or SCP constraints

Cause: Your AWS account is in an AWS Organization with Service Control Policies (SCPs) or permission boundaries that block sts:AssumeRole from external accounts, or deny the read-only actions Parsivex needs — even when the role's own policy looks correct.

What to check:

1. SCPs on the account or OU — confirm they allow sts:AssumeRole for cross-account access and do not deny ce:*, ec2:Describe*, or other read actions Parsivex uses
2. Permission boundaries on the role — ensure they do not restrict the read-only actions beyond what Parsivex requires
3. Delegated administrator restrictions — some enterprise setups restrict Cost Explorer or CloudWatch access to specific roles

SCP troubleshooting is account-specific. If your role and trust policy look correct but verification or scans still fail with access denied, contact your cloud platform team with the Parsivex policy from /security and ask which SCP statements block it.

Connection was working but stopped

Cause: The IAM role was modified, the trust policy was changed, the policy was detached, or the role was deleted.

Fix:

1. Confirm the role still exists in IAM → Roles
2. Verify the trust policy still references the correct Parsivex Account ID and External ID
3. Confirm the read-only policy is still attached
4. If the role was deleted, recreate it using Set up a read-only IAM role or Deploy with CloudFormation or Terraform, then update the Role ARN in Parsivex

Still stuck?

Contact support@parsivex.com with:

• Your AWS Account ID (top-right of the AWS Console)
• The exact error message from Test connection or the failed scan
• A screenshot of your role's Trust relationships tab
• Whether you used manual setup, CloudFormation, or Terraform

We typically respond within a few hours on business days.

Related articles

• Set up a read-only IAM role — manual IAM console walkthrough
• Deploy with CloudFormation or Terraform — IaC templates and parameters
• External ID explained — why the External ID matters
• Security FAQ — data access, retention, and revocation