No, I contacted them directly after seeing this report and confirmed they did not even use accelerated networking (which is a free, but opt-in service on Azure), much less things like placement proximity groups (which only recently went public). So machines were communicating across availability zones (separated physically by miles and logically by additional networking layers) and a bunch of networking was happening in CPU rather than offloaded to FPGA.
(I'm sending this feedback here because Azure feedback via official channels is printed out and then fed directly into a shredder.)
Can you answer why -- for the love of God -- why Azure IPv6 networking is doled out in microscopically small /124 blocks (16 addresses)!?
The standard is a /64 at a minimum for residential connections, and /48 is recommended for most premises, particularly business connections. Azure could easily obtain a /32 for each of their regions, providing a very roomy 4 billion /64 scopes per data centre.
Right now, if I want to "embrace IPv6" and all of its advantages, such as a flat address space and the elimination of NATs, I will have to either:
1) Juggle a bunch of /124 prefixes and carefully allocate services to them. This is a load of fiddly scripting or manual work.
2) Probably be forced to NAT anyway!
3) Pay for addresses that ought to be too cheap to meter.
Why is accelerated networking opt in? It seems like making it default would improve these comparisons a lot and would help a lot of your customers who likely haven't found this setting either.
I don't know offhand, it's a different team that runs it. I'd guess it's something related to backwards compatibility and the general "roll big changes out slowly so it doesn't break" credo. And it may be tied to a certain kind of HW that supports it, which doesn't exist everywhere, since cloud providers can't just throw out all their HW each time a new feature comes in (as much as we wish we could). But that's just a guess.
Disclosure: I work for Azure networking.