Skip to content

CRITICAL: Backend Database Corruption - Ghost IAM Application After Account Suspension

-1

IAM Identity Center Application Inconsistency After Account Reactivation

I'm experiencing an inconsistency with IAM Identity Center applications after my account was suspended and then reactivated.

Environment:

  • Region: us-east-1
  • IAM Identity Center instance: ssoins-[REDACTED]

Issue: After account reactivation, I'm seeing different application lists between the AWS CLI and Console:

  • CLI list-applications shows only: TrustedIdentityPropagation
  • Console shows an additional application with ID apl-[REDACTED] stuck in "Fetching application name" state
  • Cannot delete the ghost application from console
  • Amazon Q Developer subscription creation fails with: "Failed to create Kiro subscription for 1 user"

Steps taken:

  • Verified IAM Identity Center instance is active
  • Confirmed CLI credentials and permissions
  • Attempted application deletion from console (unsuccessful)

Question: Has anyone experienced similar application visibility inconsistencies between CLI and Console after account suspension/reactivation? What steps resolved this issue?

Any guidance on synchronizing the application state between CLI and Console would be appreciated.

2 Answers
4
Accepted Answer

Regarding the former AI-Answer: I do not agree because I think, clearing cache or refreshing the console will NOT fix this. If list-applications (API) returns nothing but the Console (UI) shows a "Ghost" ID, the resource is stuck in a terminal state in the AWS internal control plane.

Regarding the "Kiro" Error: In my understanding, the "Failed to create Kiro subscription" error is a specific internal indicator that the Q backend cannot map to your Identity Center instance due to this orphaned record. see also -> https://repost.aws/questions/QUJSh5jQygQx6l4K11uxBPvg/error-failed-to-create-kiro-subscription-in-standalone-account-us-east-1

My recommendation is: Re-open your ticket and explicitly request a "Manual Resource Cleanup via Service Engineering." Standard Support (L1/L2) cannot run the DB scripts required to purge apl-[REDACTED]. I would mention that the API and UI states are out of sync, which is a documented trigger for Engineering intervention as far as I know. However, may somebody from the AWS Support Team here can take over.

EXPERT
answered 2 months ago
EXPERT
reviewed 2 months ago
  • "Manual Resource Cleanup via Service Engineering." is not a thing.

-1

I understand you're experiencing issues with your IAM Identity Center applications, but I need to clarify what's actually happening based on how AWS systems work.

What you're describing is not database corruption. The discrepancy between what you see in the AWS Console versus the AWS CLI is likely due to different filtering or display behaviors between these interfaces, or potentially a caching issue in the console.

When you use the CLI command to list applications in IAM Identity Center, it retrieves all applications associated with your instance. The console may display applications differently or include additional metadata that takes time to load, which could explain the "Fetching application name" behavior you're seeing.

Regarding account states: AWS accounts can exist in several states including ACTIVE, SUSPENDED, PENDING ACTIVATION, PENDING CLOSURE, and CLOSED. When an account is in SUSPENDED state, access is restricted, though you can still view billing information and contact Support. If your account was previously suspended and is now active again, there may be residual effects on certain services that need time to fully synchronize.

For your specific situation with the Amazon Q Developer subscription failures and the application you cannot delete, I recommend:

  1. Try refreshing your console session or clearing your browser cache
  2. Verify your account is fully in ACTIVE state
  3. Contact AWS Support directly through your support plan, as they have the tools to investigate service-specific issues and can escalate to the appropriate service teams if needed

This is not a database corruption issue requiring emergency engineering intervention, but rather a service-level issue that AWS Support is equipped to handle through normal channels.
Sources
list-applications — AWS CLI 2.27.41 Command Reference
Monitor the state of your AWS accounts - AWS Organizations

answered 2 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.