Guides / AWS Console sign-in, access denied, or wrong region
Part of: Sign-in, password and MFA problems
Last reviewed · By Harry
AWS Console sign-in, access denied, or wrong region
AWS Management Console access denied, wrong region, or sign-in loop? Root vs IAM, SSO, SCPs and a real AWS health event — desk triage.
Someone cannot open the AWS Management Console. The ticket says "AWS is down" or "access denied". Those words hide a pile of ordinary IAM, SSO and region mistakes — and the occasional real Health Dashboard event. Split them before you page the cloud team.
Is AWS actually having an incident?
Check the AWS status page we mirror from official sources, and the AWS Health Dashboard / Service Health for your account. A console sign-in problem that hits many accounts in a region may be IAM Identity Center or a regional console endpoint. One engineer denied on s3:ListBucket while colleagues work fine is not us-east-1 burning.
Sign-in path: root, IAM user, or SSO
- Root user. Root signs in at the account's root URL with the root email. MFA on root is expected. Root should rarely be used day to day; if root works and IAM does not, the account is fine.
- IAM user. Needs the account-specific sign-in URL (
https://account-id.signin.aws.amazon.com/consoleor the alias). Using the wrong account ID is the most common "my password stopped working" report after someone bookmarked a different account. - IAM Identity Center (SSO) / external IdP. Users start at your access portal or Okta/Entra tile. A failed SAML assertion, expired signing cert, or removed permission set looks like "AWS login is broken". See Okta SSO not working when the tile is the entry point.
Access denied after a successful sign-in
- Wrong region. Console defaults to a region where the resource was never created. Switch region in the top-right. "Access denied" on a resource that simply is not in eu-west-2 wastes hours.
- IAM policy deny. Explicit Deny beats Allow. Inline policies, permission boundaries, and session policies all count. Use the policy simulator or CloudTrail on the denied API call.
- SCP (Organisations). A Service Control Policy can deny even administrators in member accounts. Check the organisation management account if every Allow seems ignored.
- Resource-based policies. Bucket policies, KMS key policies and VPC endpoint policies deny independently of the user's identity policy.
- Temporary credentials expired. Assumed-role sessions and Identity Center sessions time out. Re-authenticate from the portal; do not rotate keys blindly.
Console blank, loop, or MFA pain
- Private window to rule out stale cookies; clear cookies for
aws.amazon.comandsignin.aws.amazon.com. - MFA device lost — an account admin must deactivate/reassign MFA for that IAM user, or use break-glass root with controls. Do not share root MFA.
- Federated users looping often have a bad RelayState or assertion clock skew; confirm IdP time sync.
- Browser extensions that rewrite headers break console XHR — test a clean profile.
Admin verification steps
- Confirm which account ID the user intends (screenshot the alias).
- CloudTrail: look for
ConsoleLoginand the denied API (AccessDenied) with the exact action and resource. - Identity Center: user assigned to the right permission set on the right account?
- Organisations: any new SCP or tag policy deployed this week?
- AWS Health: account-specific events (often invisible on the public status page) for IAM or Console.
When to escalate
Open an AWS Support case when Health shows an incident, console login fails across multiple users and networks for an account that previously worked, and your IdP traces show successful assertions. Attach UTC timestamps, account ID, role/permission set names, and request IDs. A single missing IAM Allow is an internal change request, not AWS Support.
Related status pages
Related guides
- AWS Console or Azure Portal sign-in stuck or looping
- Okta SSO not working: outage, MFA, or account lockout?
- Microsoft 365 sign-in loop or 'More information required'
FAQ
- Why does AWS Console say access denied?
- Usually an IAM Deny, permission boundary, SCP, resource policy, or the wrong region. Sign-in succeeding but APIs denying means identity worked and authorisation did not.
- How do I know if AWS sign-in is down?
- Check AWS Health and our AWS status page, then try root or another account from a different network. Wide failure lines up with a service event; one user does not.
- Why do I not see my resources after signing in?
- Most often the console is in the wrong region, or you signed into a different account than the one that owns the resources.
- SSO works in Okta but AWS shows an error
- The IdP authenticated you; the SAML assertion, permission set assignment or SCP is failing on the AWS side. Check Identity Center assignments and CloudTrail.
Did this help?
Thanks. That stays in this tab.