Vexel Commerce
9.2 billion events in peak week, and a quieter on-call than in July
Vexel's traffic multiplies by eleven in the last week of November. Their alert volume used to multiply with it. Correlation broke that link — peak week 2025 was their quietest on-call of the year.
- Sector
- E-commerce
- Estate
- AWS + Cloudflare · 5,900 workloads · 34 accounts
- Regions
- us-east-1, us-west-2, eu-west-1
- Plan
- Enterprise
- Customer since
- June 2023
- 9.2BEvents in peak weekvs 3.1B in an average week
- -58%Pages during peak weekyear on year, on 3× the traffic
- 26Situations opened in peak weekfrom 1.4 million raw signals
- 100%Ingest availabilityacross the 11× spike, no sampling applied
Every security tool we have ever run got louder exactly when we could least afford it. The first year on Aegis, I checked the dashboard three times on Black Friday because I did not believe it was working.
Vexel sells 2.1 million SKUs and does 31% of its annual revenue in November. Everything about their infrastructure is built to absorb an eleven-fold spike for nine days. Their security tooling, until 2023, was built to absorb nothing at all.
The problem with per-rule alerting at scale
A detection that fires on “unusual number of failed logins from one IP” is fine in July. In peak week it fires four thousand times an hour, because four thousand times an hour is what normal looks like when you have eleven times the customers. The old answer is to raise the threshold in November, which is the same as turning the detection off during the only week anyone would bother attacking you.
Aegis’s answer is that thresholds are the wrong primitive. A signal is scored against what this environment does at this hour of this week, and signals are then correlated: a credential-stuffing wave that does not also produce a successful authentication from a new device, a session token used from a new ASN, or a change in the checkout service’s egress profile is not a situation. It is weather.
Peak week 2025, by the numbers
Between 24 and 30 November, Vexel’s estate produced 9.2 billion normalised events. Those produced roughly 1.4 million individual signals. Those correlated into 26 situations. Of the 26:
- 19 were resolved as benign within the hour — mostly deploy activity that legitimately looked odd because deploy freeze had been lifted for hotfixes only.
- 5 were genuine misconfigurations introduced under time pressure, including a security
group opened to
0.0.0.0/0on a staging load balancer that was, it turned out, in the card-data VPC. - 2 were real attacks: one credential-stuffing campaign with 1,100 successful logins, and one attempt to modify an IAM role trust policy from a session that had been idle for six days.
The security-group finding is the one Deborah brings up, because it was found at 02:40 on the 26th and closed at 03:05, and a PCI DSS 4.0 assessor would have found it in April.
The part that is not about detection
Vexel’s ingest did not sample, buffer-drop, or degrade during the spike. That is not a detection feature, it is a capacity commitment, and it is the reason the numbers above exist at all. It is also why Vexel is on Enterprise: peak-week burst is provisioned against their contract, not shared.