Latest / The Cloud Business Podcast with Fexingo: AWS, Azure, GCP, and Enterprise Infrastructure / How Cloud Contracts Now Charge for DNS Response Latency
Transcript
- Lucas: So you sign a cloud contract today, and you expect to pay for compute, storage, and maybe data egress. But there's a newer line item that's quietly showing up in enterprise invoices: DNS response latency. Luna: DNS latency — as in, how fast the Domain Name System resolves a query? That's now a billable metric? Lucas: It is. And not just a metric — it's becoming a contractual SLA with financial teeth. AWS Route 53, Azure DNS, and Google Cloud DNS have all introduced latency-based commitments in the past eighteen months. Luna: I remember when DNS was basically a utility you got for free with your domain registrar. What changed? Lucas: What changed is that cloud-native architectures now route traffic through multiple DNS layers — global load balancers, traffic policies, health checks — and each hop adds microseconds. For a fintech trading platform or a real-time streaming service, an extra ten milliseconds on DNS resolution can mean noticeable revenue impact. Luna: So the cloud providers are basically saying, 'We'll guarantee fast DNS, but if you want the fast tier, you pay a premium.' Lucas: Exactly. Take AWS Route 53. Their standard pricing is about fifty cents per million queries. But they now offer a 'latency-based routing' feature that costs a premium — about one dollar twenty per million queries — with a contractual commitment that p99 DNS response time stays under twenty milliseconds. Luna: p99 — so the worst one percent of responses. That's a meaningful metric. Most SLAs for DNS have historically been availability-only, like '99.99 percent uptime'. Lucas: Right. Availability is table stakes. Latency is the new differentiator. And the contracts are starting to include credits if the provider misses the latency target. But here's the catch — the customer has to be running their own monitoring and reporting the violations within a billing cycle. If you don't catch it, the credit doesn't happen. Luna: That puts the onus on the customer to instrument DNS latency at scale. Most teams monitor application latency, not DNS specifically. Lucas: And that's where the hidden cost lives. I talked to a fintech infrastructure lead last month — they migrated to Route 53 for its global anycast network, expecting better performance than their old on-prem BIND setup. Their DNS costs went up twelve percent quarter-over-quarter because they didn't realize how many internal services were making recursive queries that triggered the premium latency routing tier. Luna: Twelve percent — that's not trivial. What was the root cause? Too many internal service discovery calls? Lucas: Partly. They had microservices doing DNS lookups for every HTTP call instead of caching the results locally. Each lookup hit Route 53's latency-based routing, which costs more per query. Their contract had a clause that said 'all DNS queries that use latency-based routing are billed at the premium rate,' even if the query originated from inside their VPC. Luna: So the premium isn't just for external user traffic — internal traffic counts too. That's a detail that would be easy to miss in a hundred-page contract. Lucas: Exactly. And the providers are getting smarter about how they meter it. Azure DNS, for example, now charges per query by the latency profile of the response. If your query resolves in under five milliseconds, it's one price. Between five and twenty milliseconds, it's a higher price. Above twenty, you get a credit. Luna: Wait — so if your DNS is fast, you pay more? That feels backwards. Shouldn't fast be the default? Lucas: It's a tiered pricing model that flips the usual incentive. In this case, the provider is monetizing the speed they deliver. Google Cloud DNS has a similar model — they charge per query based on the geographic proximity of the resolver to the authoritative server. Closer resolutions cost more. Luna: Interesting. So for a company with users in multiple regions, the cost per query can vary wildly depending on where the user is and where the DNS resolver sits. Lucas: Exactly. And the contract often specifies a 'default routing' tier versus a 'geoproximity' tier. Most teams sign up for geoproximity thinking it's a performance feature, but they don't realize each query in that tier is billed at a premium. Luna: What about contract negotiation? Can you push back on these clauses? Lucas: You can, but you need data. If you're entering a one- or two-year commitment, ask for a 'latency cost cap' — a clause that says DNS latency charges will not exceed X percent of your total infrastructure spend. Some providers will agree to that if you show them your traffic patterns. And always audit your internal DNS query volume before signing. Luna: So the key is to instrument your own DNS monitoring before you negotiate. That way you know your baseline p99 and query volume. Lucas: Right. And there's another angle: many cloud providers now offer a 'basic DNS' tier with no latency SLA but much lower cost. If your application can tolerate occasional slow resolution — say, for batch jobs or internal reporting — you can route those queries to the basic tier and save money. Luna: That makes sense. Not every DNS query needs to be sub-20 milliseconds. It's about matching the latency requirement to the workload. Lucas: Yeah, exactly. And a lot of these contracts are written with the assumption that you'll use the premium tier for everything. But if you push back and say, 'We want to segregate our DNS traffic into tiers,' they'll often allow it — as long as you're paying for the metering. Luna: Which brings up a broader point: cloud contracts are getting more granular, and the cost of inattention is real. A few microseconds here, a few million queries there — it adds up. Lucas: It adds up fast. And the providers are doing this because they can. DNS is a critical path for every internet service, and once you're in their ecosystem, switching is painful. So they're gradually monetizing every layer of the stack. Luna: What's the next layer? After DNS, what do you think they'll start charging for based on latency? Lucas: I've seen early signs around CDN origin fetch latency and API gateway response times. But that's for another episode. Luna: Fair enough. For now, the takeaway: read your DNS contract, instrument your queries, and don't assume all DNS is priced equally. Lucas: And if you want to keep hearing about these contract details without ads, we should mention — this show stays ad-free thanks to a small group of listeners who chip in monthly through buy me a coffee dot com slash fexingo. That support is what lets us keep digging into these niche topics. Luna: Yeah, it really does. And we're grateful for everyone who contributes — it makes episodes like this possible. Lucas: So, back to DNS — one more practical tip: if you're on AWS, set up CloudWatch metrics for Route 53 query types and latency. You can create a billing alarm that triggers if DNS costs exceed a threshold. That caught our fintech friend's issue early. Luna: Good advice. Alarms are cheap; surprises are expensive. Lucas: Exactly. Next time, we'll look at how cloud contracts are starting to charge for TLS handshake latency — which is another layer being unbundled. Until then, keep reading the fine print.