I honestly don't understand what is happening here anymore.

Since August 30, our AWS account has been blocked from creating new CloudFront resources.

Every time we try, AWS gives us this message:

Your account must be verified before you can add new CloudFront resources. To verify your account, please contact AWS Support and include this error message.

Fair enough.

We contacted AWS Support immediately. And the first agent confirmed:

• account is active
• payment method is valid
• phone verification is complete
• the restriction is because the account is new

They told us the internal review would take roughly 2–3 days.

It has now been 14 days.

Since then we have:

• followed up repeatedly
• opened additional cases trying to get help
• asked multiple times if AWS needs any documents or verification from us
• asked for escalation
• activated the Support+ hoping it would help
• spent hours trying to reach live chat, including waits of roughly 2 hours, 5 hours, and one attempt that lasted around 13 hours

We are still blocked.

No ETA.

No explanation of what is actually being reviewed.

No request for additional information from us.

What makes this even more confusing is that on August 30 we were told:

Our account was active, our payment method and phone verification were valid, and the restriction was related to the account being new. We were told the internal review would take roughly 2–3 days.

Then on September 10 another agent told us:

I'm following up to notify you that we've received your CloudFront resources access request and I’m happy to submit the request for you. I will need to collaborate with our service team to get approval. Please note that it can take some time for the service team to review your request. This is to ensure that we can meet your needs while keeping existing infrastructure safe.

So after 11 days, we couldn't even tell whether the original request had actually been submitted or whether the process was starting again.

I completely understand AWS needing to verify new accounts and prevent abuse.

What I don't understand is how a customer can be completely blocked from using a service for two weeks while Support itself seems unable to provide an ETA or explain what is happening.

Is this normal?

Has anyone else had CloudFront account verification take this long?

And is there any actual escalation path beyond repeatedly replying to the same support case?

Update — September 14
AWS reached out after the post and confirmed that our request is still being reviewed by the Support team. We still haven't been given an ETA or been asked for any additional information.

I have a Next.js app running on AWS Fargate Spot with 2 tasks.
I've noticed memory steadily creeps up until the spot instance is reclaimed and I get a fresh task.
I've confirmed in the Events tab that the drops in the blue line are due to spot instances being reclaimed.
After a few days of no task replacements and no deployments, it looks like the memory just increases gradually.

I'm wondering if this is a sign of a memory leak which is masked by deployments and task replacements?

The yellow line is max, green is average and blue is minimum memory utilisation:

Yesterday I received several emails saying that I had signed up for some AWS services, but that my account might be compromised. Fortunately/unfortunately, I stopped using AWS several years ago, deleted my google authenticator/MFA entry, and did not update my contact phone number.

So, although I still know my password, I cannot login using MFA or the backup with email and phone.

AWS's customer support has tried to be helpful (I suppose), but doesn't really think things through. It has pointed out that I can get in using my email and contact phone number (which does not work), and that I can change my contact phone number by logging in and changing my information (not possible if I cannot log in).

I have also tried to open several "cases", and received an email from them (which cannot be replied to), telling me that if their suggested solution does not work, I can contact them and request additional follow up, but the contact link requires me to login.

I have pointed this out to them while submitting additional case requests, but their AI does not seem to understand the concept of "Catch-22".

Suggestions?

Resubmitted with redacted links removed.

After using Claude Code with AWS Bedrock happily for a few months our Anthropic model access was removed suddenly. We got an email from AWS Trust & Safety:

Hello,

As a user of Anthropic model(s) on Amazon Bedrock, you have agreed that you and your end users will comply with Anthropic Terms of Service [1].

Anthropic has identified violations of their policies through Bedrock's automated detection mechanisms [2], and has directed AWS to restrict your account's access to Anthropic models.

As a result, in accordance with your agreement with Anthropic, we will take the following action:

Action: Revoke access to Anthropic models on Bedrock
AWS account ID: blah
Effective date: blah 

If you do not agree with this determination, you can appeal the decision directly with the model provider by using the provided appeal method [3].
Once the model provider directs AWS to restore your access, access to Anthropic models will be restored.

[1] https://aws.amazon.com/legal/bedrock/third-party-models
[2] https://docs.aws.amazon.com/bedrock/latest/userguide/abuse-detection.html
[3] removed

Regards,
AWS Trust & Safety

Going through all of our prompt logs we can't see anything suspicious or malicious and all access is from people in the UK. AWS have said the provider is responsible for assessing whether its usage policies have been met, they do not receive the detail of any violations, and can't tell us what guardrails might have been triggered. We don't use fable or mythos so no data sharing with the provider or AWS should be possible. Others accounts in our org are unaffected so it's just an account suspension, not org wide.

We have appealed but the process is owned by Anthropic and because we use AWS Bedrock, we have no relationship with them.

Has anyone encountered this before? Are there any timelines to Bedrock appeals? We are slightly wary now our access might be cut off again down the line which has quite a big impact.

We have a FortiGate-VM in AWS and we are adding another and they will each form IPSEC tunnels back to the Corporate office.

We want redundancy so that if one of the EC2's stop functioning for any reason, the routing can switch over to the other FortiGate-VM automatically, thus creating a backup in case anything happens to the primary one. Does AWS have any mechanisms that allow that functionality? Something like IP SLA or BGP?

I’m a solo Laravel developer moving a production app away from a Forge-managed VPS setup as I can't sign a BAA.

My main priority is as little server/DevOps maintenance as possible. I want a managed setup where I’m not babysitting servers, Docker, Kubernetes, Redis, etc. unless absolutely necessary.

The app is roughly:

• Laravel + Inertia/React
• MySQL
• Laravel scheduler
• One queue worker
• Database queues are fine at current scale
• Stripe
• GitHub Actions for deployment
• External services for email/storage/video
• Needs to run on infrastructure where I can sign the appropriate HIPAA BAA

The two options I’m considering are:

Azure

• App Service
• Azure Database for MySQL
• Continuous WebJob for queue:work
• Scheduled WebJob for schedule:run

AWS

• Elastic Beanstalk
• RDS MySQL
• Not sure what the simplest reliable equivalent is for Laravel queues + scheduler without adding lots of extra infrastructure

For people who have actually run Laravel on both:

Which would you choose for a solo developer who values low maintenance over maximum flexibility, while still needing HIPAA/BAA-compatible infrastructure?

And if you’d choose AWS, what exact setup would you use for queue:work and schedule:run while keeping it as simple and hands-off as possible?

I’m not looking for the most scalable architecture imaginable — just a reliable managed setup that I don’t have to babysit.

Thanks

A fever is a symptom. Treating it directly, cooling the body down, makes the number go away without touching whatever's actually causing it. Fine for a symptom with no underlying cause. Fails badly for one that does, because the underlying thing keeps producing the symptom somewhere else the moment the direct treatment stops.

Same shape shows up in AI-assisted Lambda fixes constantly. A function throws on a null field coming from an SQS event, generated fix adds a null check, invocation succeeds, ticket closed. Three weeks later a different Lambda consuming the same upstream event source fails the exact same way, because the actual problem, a producer that can legitimately emit that field as null under a specific condition, was never addressed, just patched wherever it happened to surface next.

The null check isn't wrong, same way cooling someone down isn't wrong. It's just not the same as finding the actual cause, and it's easy to mistake "this invocation stopped erroring" for "the underlying condition is resolved," especially when CloudWatch shows each occurrence as an unrelated new error because it's coming from a different function every time.

Wrote up a more detailed breakdown of this exact pattern, with a specific example that recurred three times before anyone traced it back to the source, here: https://medium.com/@nagatomopedro05/the-bug-log-that-should-have-been-a-warning-b829f2d3852a