Account-level Lambda restriction after security review — production outage, case unassigned

The single most likely reason it's unassigned

Restrictions applied after a security review are actioned by AWS's security / Trust & Safety team. That team is not reachable through technical support categories. If your case was opened under Lambda, or under a technical service code, it may be sitting somewhere that has no authority to remove the flag — which looks identical to "not picked up."

The category that routes correctly:

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

This is free on every support plan.

Reply on your existing case asking explicitly for reassignment to the team that can remove the account restriction. Don't open a duplicate — parallel cases for the same issue reliably slow things down. If the existing case is under a technical category and you get no movement, one new case in the above category, cross-referencing the original case ID, is defensible.

Make the outage unmissable in the case text

Your remediation list is thorough. What may be missing is the impact framing, and with security reviews that materially affects prioritisation:

• Published iOS and Android apps fully offline since 16:16 UTC, paying subscribers affected
• Lambda is the entire backend — this is not partial degradation
• Root-with-MFA in console also denied, so this is demonstrably account-level and not a credentials problem
• Every other service functions normally, which scopes the flag to Lambda specifically

That last pair is worth stating explicitly. It pre-empts a reviewer suggesting credential rotation you've already done.

Explain the flagged activity in service terms

You've said it was your own development work. Make it concrete enough that a reviewer can match it to what their tooling saw — volume of invocations, unusual regions touched, new roles created, rapid deploy cycles, whatever actually happened. Automated abuse detection fires on patterns; giving the benign explanation for the specific pattern is more persuasive than asserting there was no compromise.

Two things to check on your side

Alternate security contact. If unset, AWS's security team may have no working channel to reach you. Its absence is a documented reason these stall. Set it now.

Root account email. Confirm it reaches a monitored inbox. Correspondence may already have been sent.

Interim mitigation

Standing up the backend in a second AWS account is technically possible but the restriction may be account-level in a way that affects new accounts under the same payer, and you'd be rebuilding under pressure. I'd exhaust the escalation path first — but if you're facing many more hours down, it's worth knowing whether a separate account (different payer, if you have one) can host a minimal set of critical endpoints.

I'm in day 2 of this nightmare. Worse customer service I've ever received in my life. Overnight, I got movement on the actual ticket. Told in the case notes this morning that my service would be restored shortly. That was over 6 hours ago. Support don't even respond to me anymore. Just awful.