Pip: Welcome to Azure Advice — where the cloud is always fine, right up until it isn’t, and someone has already written the post-mortem.
Mara: Today we’re covering work from Christoph Corder across two territories: the hidden networking constraints that make Azure App Service quietly dangerous, and the economics of AI getting things wrong and charging you for the privilege.
Pip: Let’s start with the networking side — specifically, why your app might be one busy neighbor away from an outage it can’t explain.
Azure App Service and the Ports You Cannot See
Mara: The tension here is about what Azure actually guarantees versus what most apps quietly depend on. Every App Service instance gets 128 SNAT ports — that number is yours. Everything above that comes from a shared pool that other tenants on the same stamp are also drawing from.
Pip: And the post puts it plainly: “Relying on shared-pool SNAT ports is not a strategy. It is an accident that has not caught up with you yet.”
Mara: What that means in practice is that your architecture may require more than 128 ports to function correctly, and the only thing keeping it alive is that your neighbors haven’t gotten busy yet.
Pip: The failure mode is almost artistically cruel — it doesn’t reproduce in staging, it doesn’t show up in load tests, and by the time you open a support ticket the pool has recovered and your dashboards are green again.
Mara: And the symptoms point the wrong direction. Outbound HTTPS calls fail, logs blame Cosmos or Storage or DNS, and teams spend a week chasing the wrong root cause. The post calls this out directly: the incident looks like something else, and it happens at the worst possible time.
Pip: There is something almost poetic about a system that punishes you most on the day you finally get traction.
Mara: The fixes the post recommends are concrete. A singleton HttpClient eliminates per-request connection churn. A NAT Gateway moves your ceiling from 128 shared ports to roughly 64,000 that are yours alone. Private Endpoints remove Azure PaaS traffic from the SNAT budget entirely — the port never gets allocated in the first place.
Pip: The goal in all three cases is the same: stop depending on the stamp being in a good mood.
Mara: That framing — weather — runs through the whole piece. The shared pool is available when conditions are favorable and gone when they aren’t. The 128 is the only number that holds regardless of conditions. That’s where the architecture needs to land.
Pip: From invisible networking constraints to something equally invisible — the cost of being confidently wrong.
When AI Bills You for the Mistake and the Apology
Mara: The question this piece opens with is sharp: when a model answers with total confidence, you correct it, and it agrees enthusiastically — who pays for the wrong answer?
Pip: The post answers immediately: “Congratulations. You just paid twice. Once for the mistake, once for the apology.”
Mara: What that gets at in practice is that there is no consumer protection mechanism here. No other service routinely charges you for both the error and the correction — except, the post argues, the professions AI is actually imitating.
Pip: Lawyers bill hourly when they lose. Consultants charge to fix their own advice. The post is careful to note this isn’t a new scandal — AI inherited effort-based billing from the industries it’s replacing.
Mara: The sharper point is what it didn’t inherit. No license. No malpractice exposure. No bar association. As the post puts it: “We built a profession with all of the billing and none of the accountability.”
Pip: And yet the market has already started answering the question, which is the part that surprised me.
Mara: Outcome-based pricing is real and growing. Intercom’s Fin charges per resolved conversation. Zendesk introduced per-resolution pricing. HubSpot repriced its Customer Agent. Bessemer’s data shows pure per-seat SaaS pricing dropped from 21 to 15 percent in a single year while outcome models surged.
Pip: So why hasn’t this spread to, say, code review or legal analysis?
Mara: The post calls it the adjudication problem. A resolved support ticket is binary, timestamped, cheap to verify. A correct answer to a complex question is contested. The moment money attaches to correctness, the definition of correctness gets gamed — and verifying a complex answer can cost more compute than generating it did.
Mara: The post’s proposed direction is pricing by provability: separating outputs into tiers — grounded claims, inference, and guesses — so that guarantees attach only where verification is tractable.
Pip: Trust, in other words, is the next thing the market competes on.
Mara: Both pieces are really about the same underlying problem — systems that work until a hidden dependency fails, and the gap between what’s guaranteed and what’s assumed.
Pip: Next time: hopefully fewer surprises. Though the weather has other plans.
Azure Advice 