• Skip to primary navigation
  • Skip to main content
Last Week in AWS Logo
Master your cloud costs
  • About
    • Community
    • Contact
  • Blog
  • Newsletter
  • Podcasts
    • Last Week in AWS Podcast
    • Screaming in the Cloud
    • Nominate a Guest
  • Merch
  • Resources
    • AWS Network Map
The Fun Way
07.22.2020

Route 53, Amazon’s Premier Database

By Corey Quinn
I’ve periodically made reference in a bunch of places to Route 53 being my preferred database. But I’ve only really told the story in podcast and tweet thread form. I’ve never gone…
FacebookXLinkedInReddit
Home Blog Route 53, Amazon’s Premier Database
Prev
Next

I’ve periodically made reference in a bunch of places to Route 53 being my preferred database.

But I’ve only really told the story in podcast and tweet thread form. I’ve never gone in depth as to how this terrible, terrible antipattern came to be in a blog post—which is far easier to cite.

Today is your lucky day!

Before I begin, I want to emphasize that this is tongue-in-cheek. Please do not do this.

There are, in 2020, far better ways to solve this problem.

DNS isn’t really a database

Many years ago, I worked at a company that looked a lot like a traditional on-premises build-out, because it was. Cloud was nascent in those days, and the 2008 financial collapse was yet to come. We had a bunch of virtual machines (VMs) that were themselves running on physical hosts in racks.

Everything you might expect of such an environment was true. We had cabling problems, we bled on the rack nuts, we drove at unsafe speeds in the middle of the night to frantically restore service when things broke.

As I said, it was a different time.

We had some limited ability to migrate VMs between physical hosts. Live migration didn’t work in our configuration, so these VMs tended to stay pretty much where we put them. This led to a series of problems that in hindsight were entirely avoidable.

Note to future self: You have two DNS resolvers for redundancy; perhaps do not put them both on the same physical host.

Which of course brings us to DNS.

We wanted to know in a hurry upon which host any given VM lived, so we struck upon a somewhat novel solution. DNS TXT records are a type of resource record in DNS that support arbitrary strings. They’re used for a variety of “validate you own the domain,” DMARC / SPF spam reduction systems, DNS-based service discovery, and other various use cases. Being the geniuses we were, we struck upon the idea of using these records to set each VM’s host VM.

From there, it didn’t take us too long to hit upon the idea that this worked super well with our sysadmin scripting language of choice: crappy shell scripts. dig TXT vm1.web.prod.ord.twitterforpets.com returned a neat defiant.prod.ord.twitterforpets.com answer. (We’ll save my “Federation Starships” server naming convention for another day.) Thus, it became super easy for us to work this into our crappy management scripts.

“Validate that the physical host has no more VMs on it BEFORE you yank the power cable out” stopped being a sticky note that got ignored. Instead, it became a script that was generally ignored instead until right after it really needed to have worked. “This VM seems slow, which host is it on?” was now a quick DNS query away. And times were good.

Of course, this is horrifying today.

Most environments have a control plane that can give you these answers in the form of metadata. It’s also close-to-but-not-the-most horrifying abuse of tagging possible in a cloud environment.

Functionally, what you’re really looking for is something like a configuration management database or something fairly robust like Device 42. Instead of twisting low-level primitives (not to mention yourself) in knots, use something that’s purpose-built for the task at hand.

And yet…

Route 53 (Amazon’s managed DNS service) is the only AWS service with a public 100% SLA on the data plane. It incurs no charges for data transfer anywhere inside of AWS or out to the internet. As long as you move a hosted zone to either a new zone or a different AWS account within 12 hours, the 50¢ per month charge per zone doesn’t apply.

The world has been rife with misuses of DNS: serving as a tunnel, a filesystem, and a DDoS cannon, for example. As such, viewing it as a database isn’t the strangest idea in the world.

And so…

Route 53 is a database

I do declare that Route 53 is in fact a database.

There are libraries to make it more user-friendly to query. Every system, every language, and every SDK knows how to speak to it. It loses considerably less data than MongoDB. The pricing is reasonable even without weasel-tricks to get around it. And its underlying technology has been proven out over decades.

It provides “CA” on the CAP theorem conjoined triangle of success. It is, for the moment, non-relational. And it’s super hard to raise $2 billion in venture money from Softbank around a technology this unexciting.

All of that goes to show that DNS—and, by extension, Route 53—is not only a perfectly suitable database option, it’s the best database money can buy.

I dare you to prove me wrong.

Corey Quinn Headshot
by Corey Quinn

Corey is the Chief Cloud Economist at Duckbill, where he specializes in helping companies improve their AWS bills by making them smaller and less horrifying. He also hosts the "Screaming in the Cloud" and "AWS Morning Brief" podcasts; and curates "Last Week in AWS," a weekly newsletter summarizing the latest in AWS news, blogs, and tools, sprinkled with snark and thoughtful analysis in roughly equal measure.

More Posts from Corey

Back to the Blog

Infinidash: AWS’s New Observability Play Has Great Bones and a Terrible Bedside Manner

By Corey Quinn

Infinidash: AWS’s New Observability Play Has Great Bones and a Terrible Bedside Manner AWS has just released something fascinating in the form of CloudWatch Omni. I want to be upfront before I dive further: “CloudWatch Omni” is a wretched name that I will not be using, so for the rest of this article and the […]

Read Moreabout Infinidash: AWS’s New Observability Play Has Great Bones and a Terrible Bedside Manner

Reading Observability Tools? That’s a Robot’s Job

By Corey Quinn

Last Thursday Honeycomb was kind enough to hand me the closing keynote slot at O11yCon, a conference whose entire premise is that observability matters and the people in the room are the ones who would know. I used that slot to argue that the primary reader of your telemetry is no longer a human, and […]

Read Moreabout Reading Observability Tools? That’s a Robot’s Job

S3 Is Not a Filesystem (But Now There’s One In Front of It)

By Corey Quinn

I’ve been saying “S3 is not a filesystem” for over a decade. I’ve said it on stages, in newsletters, on podcasts, and directly to the faces of large company employees who were too polite to tell me to shut up before they went back to their FUSE monstrosities. It was one of those reliable truths […]

Read Moreabout S3 Is Not a Filesystem (But Now There’s One In Front of It)
Billie Holding Mail Email Subscribe Icon

Get the newsletter!

Stay up to date on the latest AWS news, opinions, and tools, all lovingly sprinkled with a bit of snark.

You’re faced with tough questions about cloud costs. You should have confident answers.
Get in touch.
  • Newsletter
  • Podcasts
  • Blog
  • Merch
  • About
  • Contact
  • Disclosures
Billie Footer
footprint-orange
© 2026 L9 Labs, Inc. All Rights Reserved.
Terms of Service Privacy Policy Cookie Policy