Skip to content

Account still restricted from Lambda after completing all remediation steps (exposed access key)

0

My personal AWS account was flagged for an exposed IAM access key and AWS applied a service restriction. I have completed every step in the notification, but Lambda is still unusable across all regions.

What I did:

  • Deleted the exposed access keys immediately.
  • Reviewed CloudTrail for the affected keys. There were 5 API calls from an unrecognized IP: 4 returned AccessDenied (iam:CreateRole x2, iam:CreateUser, sts:GetFederationToken) and 1 returned Client.VPCIdNotSpecified (ec2:RunInstances). No resources were created.
  • Verified in Cost Explorer that there is no unexpected usage or charge.
  • Confirmed no IAM users, roles or access keys were created by the attacker.
  • Replied in writing to all three support cases (one per key) confirming the above.

Current state:

  • All Lambda invocations fail with AccessDeniedException and no reason given, which suggests an account-level restriction rather than an IAM policy denial. Everything else I use (DynamoDB, CloudWatch Logs, Cost Explorer, CloudTrail) works normally.
  • The three cases were opened by AWS under the "Account" category. I replied to each and reopened them. No response so far.
  • I tried live chat on all three cases. It never connected.
  • I am on the Basic support plan, so phone support is not available.
  • I have already read the existing threads on "Account Reinstated but Lambda Service Still Unavailable" and "Inappropriate Restrictions to Admin Account", so I understand that only the security team can remove the compromised flag. My question is about how to actually reach them.

Questions:

  1. Is there anything else I can do from my side, or is waiting the only option?
  2. Is the "Account" category on these cases correct, or should I open a new case under account-verification instead?
  3. Roughly how long does removal of this flag usually take?
2 Answers
0

Q2: It is best to narrow the category down to "Account Verification."

This is the most effective piece of advice for this situation.

The URL for opening a support case—which routes directly to the security team and is frequently recommended within the community—is as follows:

https://support.console.aws.amazon.com/support/home?issueType=customer-service&serviceCode=account-management&categoryCode=account-verification#/

Cases opened via this URL are classified as non-technical (and are free of charge) and are routed to the security team.

Multiple AWS staff members have consistently pointed out that opening multiple, redundant cases can actually delay the response. When opening a new case, it is safest to clearly list the case numbers of the three existing cases in the body text and state that the new case is intended to consolidate the previous ones.

Q1: Other actions you can take

  1. Clearly state the "impact level" in the case body

The playbook recommends noting the internal escalation level (e.g., "this issue has visibility among executive management") when creating a case. Since phone and chat support are effectively unavailable under the Basic plan, the way you write the case body serves as the only signal regarding priority.

  • Specific impact on business operations or services
  • The fact that services other than Lambda are functioning normally (i.e., explicitly stating that this is a Lambda-specific flag, not a suspension of the entire account)
  • Details of the five incidents confirmed via CloudTrail (four "AccessDenied" errors, one failure due to an unspecified VPC ID, and zero resource creations)
  1. Temporarily upgrade your support plan

With the Basic plan, you cannot use chat or phone support, and there is no guaranteed response SLA. Upgrading to the Developer plan for just one month would at least provide a guaranteed response time. As this is a personal account, cost is likely a concern, but you should weigh that against the losses incurred by having Lambda unavailable across all regions.

Q3: Time required for resolution

There is no publicly stated standard timeframe for resolution. Looking at examples from the community, there is significant variation; while some cases were resolved in just a few days, others remained unresolved even after five days—with some even requiring a restart of the recovery process after the system determined that, although the member account had been cleared, the parent account was also subject to the same restrictions.

EXPERT

answered 14 days ago

EXPERT

reviewed 14 days ago

0

Thank you — this is very helpful.

Update: shortly after posting, the situation moved. AWS consolidated my three cases into one and the remaining case is now in progress. Support has asked me to confirm two things before submitting a reinstatement request to their internal security team: (1) that root MFA is enabled, and (2) location information (country/city, VPN use, whether anyone else has access).

So for anyone finding this later: the two confirmations above appear to be the actual gate to reaching the security team. I have not opened a new account-verification case, since AWS had already engaged on the existing one and additional cases risk re-fragmenting the thread.

answered 14 days ago

EXPERT

reviewed 14 days 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.