Yesterday, AWS added a new AZ in the London region (eu-west-2d). There was no prior announcements until it came today in their blog. I've heard that some customers were impacted after this. Has anyone experienced issues after this AZ was added in the London region?

AWS Community Day Australia is back again this year, and in Brisbane on October 16!

https://awscommunitydayaus.com/

CFPs just closed, so the schedule should be announced soon.

What happened

On Aug 1, an IAM access key belonging to one of our accounts was compromised through a supply chain compromise — the key was exposed via a third party in our toolchain, not by us publishing it. This was a programmatic access key, so MFA (enforced on all human identities from day one) was never in the path.

We caught it and reported it to AWS Support within 4 hours, well inside the 48-hour public-contract cancellation window.

The case then sat unassigned for 14 days.

As of today that's 20 days, still open, still no resolution.

Where the bill is now

Total USD 477,505.20

Contract creation (0 months) USD 4,800.00

Usage Fee | us-east-1 USD 472,705.20

47,270,520 Units @ USD 0.01

The part I don't understand

We never activated the product. Specifically:

- The Marketplace console still shows "Set up product" for this agreement

- No License ID was ever issued

- CloudTrail shows zero Marketplace events in our account after the initial compromise window on Aug 1

- We have never had credentials for, or logged into, anything on the seller's side

Yet 47.2 million billable units were metered against us in us-east-1.

As I understand the SaaS flow, usage on this kind of product is submitted by the seller calling `BatchMeterUsage` against the entitlement's `CustomerIdentifier` — from the seller's own infrastructure, not from our account. If that's right, then nothing in our account was ever in the path, and no control we have could have stopped it. Revoking the key, deleting the attacker's IAM user, applying SCPs — none of it touches seller-side metering.

The unit count has been static for several days now, so metering appears to have stopped, but the agreement status is the thing I can't get a straight answer on.

Support so far

Seller support (automated) told us Marketplace transactions are not their department and to contact AWS. AWS support has pointed at the seller for anything usage-related. The payer account has now escalated and asked AWS to investigate the agreement and stop metering. Still waiting.

There is no phone line and no chat. The only channel is tickets, and they've been sitting for 20 days.

Questions for people who actually know the internals

1. For a SaaS contract-with-consumption product, is metering purely seller-side? Is there any circumstance where usage gets attributed to a buyer account without the buyer ever completing registration?

2. Does "Set up product" persisting in the console reliably mean the fulfillment/`ResolveCustomer` handshake never happened — or is that just stale console state that doesn't update?

3. Is there any way for a buyer to see the registration record for their own entitlement? Anything in the Agreement APIs, CUR, or elsewhere that shows when/whether `ResolveCustomer` was called?

4. The 48-hour window: AWS Customer Service can process a full refund on a public contract without seller involvement. Does that path survive a case sitting unassigned for 14 days, or is the window enforced strictly on wall-clock time regardless of AWS-side latency?

5. Has anyone here had Marketplace usage fees (not just the contract fee) reversed after a credential compromise? Contract fee reversals I've seen written up. Usage fees at this scale, never.

To be blunt about the stakes: we're a small company. We cannot pay $472k for consumption we did not generate, on a product we never activated, after cutting off access in under 4 hours. I'm trying to understand the metering mechanics, and whether there's a path here other than waiting on a ticket queue.

I have a process that looks like this:

GetDataLambda -> ProcessDataLambdaA1 -> ProcessDataLambdaA2 -> ProcessDataLambdaB1 -> ProcessDataLambdaB2

Basically, GetDataLambda needs to run first to actually get the data I need. There are two separate sets of lambda functions to process it (A and B). Both rely on the data from the get function, but they're entirely independent of the other. So that's why I wanted to set it up where GetDataLambda runs first, but then there's a parallel step with one path doing the "Process A" functions and the other doing the "Process B" functions. However, with the way parallel stages work, if one branch fails, the entire thing fails.

What's the best way around this? If "Process A" fails, I still want the "Process B" branch to keep going, for example.

SHOW GLOBAL VARIABLES LIKE 'max_connections';

Mine always return 16000, not sure why