Two months ago I picked up a ticket that looked routine: a job that reads mailbox data from Microsoft 365 through EWS, running fine for over a year, started failing on a subset of mailboxes in one tenant. Same app registration, same code path, same service account. The error in the logs pointed at throttling, so that's where the admin had already spent three days looking. Wrong direction. The actual cause had nothing to do with throttling budgets.
This mix-up happens constantly right now, and it's worth understanding why, because the fix for one problem does nothing for the other, and chasing the wrong one wastes days.
TL;DR: if your EWS failures don't scale with request volume, stop tuning throttling and go check your Application Access Policy scope groups instead.
What EWS throttling actually looks like
Exchange Online throttles EWS the same way it always has: budget-based. Every account gets a policy (the default is EwsDefaultThrottlingPolicy, but plenty of tenants layer custom ones on top) that tracks a slowly-refilling budget rather than a simple call count. When you overspend it, you get back a 503 or 429 with an X-MS-Diagnostics header telling you which budget got exhausted, usually the connection count or the concurrent-request limit.
