High outbound connection count / SNAT port exhaustion: provider appears to open a new TCP connection per ARM API call (no conne

  1. Symptom — SNAT exhaustion at -parallelism=20 , ~1100+ ports > ~1024 cap.
  2. Debug output — the maxStream=1 / closing idle conn log lines, plus the negatives (0 GOAWAY, 0 Connection: close , server allows 100 streams) that prove it’s not server-driven.
  3. Expected vs actual — should reuse a small pool; actually ~1 connection per ARM call.
  4. Root cause — the fresh- http.Transport -per-request in go-azure-sdk with file:line refs, framed as “I believe I’ve found — please confirm/correct” (appropriately humble for a question).
  5. Minimal reproduction — the 30→30 vs 30→1 httptrace result (no Azure resources needed, so anyone can run it).
  6. Already ruled out — MaxIdleConnsPerHost , IdleConnTimeout , server-side — so maintainers don’t suggest dead ends.
  7. Three direct questions — is anyone else seeing it / is it intentional / would they accept a shared-transport fix.