Four decades ago, when the Berkeley Internet Name Domain Server launched, it stored DNS records in "zone files". You could edit these files in vi, but BIND had to be told to reload them before your changes took effect. Later, other DNS servers came along, like Daniel Bernstein's tinydns, which served records directly out of a database on disk — but even there, after editing the human-readable DNS records, it was necessary to recompile the database file.
With Route 53 Files, it becomes possible to use standard UNIX software to edit your DNS without needing any additional steps. It makes your hosted zones accessible as file systems; this means changes you make to records in the file system are automatically reflected in Route 53, and changes made in Route 53 through any other channel — the AWS Management Console, the Route 53 API, the AWS CLI — automatically appear in the file system. A Route 53 Files file system can be attached to multiple compute resources, enabling shared access to your zones across teams without duplication.
Until now, you had to choose between the Route 53 console, the Route 53 API, and the tools built on top of them. Route 53 Files eliminates that tradeoff. Your hosted zone becomes the central hub for all your organization's DNS records. It's accessible directly from any AWS compute instance, container, or function, whether you're running production applications, responding to an incident, or building agentic AI systems.
You can access any enrolled public or private hosted zone as a native file system on your Amazon Elastic Compute Cloud (Amazon EC2) instances, containers running on Amazon Elastic Container Service (Amazon ECS) or Amazon Elastic Kubernetes Service (Amazon EKS), or AWS Lambda functions. The file system presents each resource record set as a file and each record name as a directory, supporting standard Network File System (NFS) v4.1+ operations like creating, reading, updating, and deleting DNS records.
Alias records are presented as symbolic links to their targets, so ls -l renders them the way you would expect and readlink does what you would hope. Cross-zone aliases are presented as dangling symbolic links — as they should be, given that their targets are not inside the same file system.
Under the hood, Route 53 Files uses S3 Files and delivers ~90s latency for a file save to reach live DNS, and up to 6 minutes of latency for a change made elsewhere in Route 53 to appear in your mount. (Note that changes reaching live DNS does not ensure that they are immediately visible worldwide; the latency for global visibility of DNS changes depends on record TTLs and caching behaviour.) The file system supports concurrent access from multiple compute resources with last-write-wins conflict resolution, making it ideal for shared workloads that mutate authoritative DNS, such as AI agents collaborating through file-based tools and on-call engineers reverting each other's changes using sed.
Let me show you how to get started.
Creating my first Route 53 Files file system, mounting it, and editing DNS from an EC2 instance is straightforward. In this example, I already have a Route 53 hosted zone and an EC2 instance where I want to mount it.
First, I navigate to the Route 53 Files Console and create IAM roles. These are needed to allow Route 53 Files to create resources in my AWS account and read and write to my existing Route 53 hosted zone.
I fill in my 12-digit AWS account ID and the Route 53 hosted zone ID I'm planning on using; if I wanted to I could specify multiple hosted zones or even "*" to allow all Route 53 hosted zones to be enrolled. When I click "Create bundle", a tarball is generated inside the web browser containing IAM role policies with exactly the privileges required; if you're paranoid about security (as you should be), you can audit the role-generation code to confirm that it isn't trying to grant any unnecessary privileges.
Having downloaded the bundle, I extract it and run the included script to create the roles. There's also a README.txt file inside the tarball with instructions, including explaining what you need to adjust if you want to permit additional hosted zones to be enrolled at a later date.
Having now created the necessary IAM roles, I can proceed to enrol a Route 53 hosted zone into Route 53 Files. I enter my AWS account ID, my Route 53 hosted zone ID, the AWS Region I want to create the Route 53 Files file system in — I'm Canadian, so I picked ca-central-1 — and the external ID is autofilled from when I created the role bundle. If I come back to this page later I can get the external ID from the README.txt file in the role bundle tarball I generated. (The External ID makes sure that you, and only you, can enrol your hosted zone; it's also used if you ever want to stop using Route 53 Files.)
When I enrolled my hosted zone, I was given a file system ID of the form "fs-0123456789abcdef0" and now I can create a mount target. Route 53 Files is compatible with S3 Files, so I use the same command:
$ aws s3files create-mount-target \
--file-system-id fs-0123456789abcdef0 \
--subnet-id <a subnet in that VPC> \
--security-groups <a group allowing TCP 2049 from your clients> \
--region <your region>
Once my mount target is available, I can mount it on my EC2 instance. I've already confirmed that I have amazon-efs-utils version 3.0.0 or later and botocore installed, and my EC2 instance has an IAM Role attached containing the AmazonS3FilesClientFullAccess policy.
$ sudo mkdir -p /mnt/r53fs/example.com
$ sudo mount -t s3files -o nodirects3read \
fs-0123456789abcdef0 /mnt/r53fs/example.com
Editing DNS with Route 53 Files
I can now edit my DNS using standard command-line tools. Within the file system, foo/TYPE is a TYPE record named "foo"; in keeping with DNS tradition, the special name "@" refers to the zone apex. For example:
$ echo 1.2.3.4 | sudo tee /mnt/r53fs/example.com/@/A
$ echo 5.6.7.8 | sudo tee -a /mnt/r53fs/example.com/@/A
I want the www host to alias the zone apex, so I create a symlink:
$ sudo mkdir /mnt/r53fs/example.com/www
$ sudo ln -s ../@/A /mnt/r53fs/example.com/www/A
If I want to reduce record TTLs in advance of a migration, I simply need to create a .TTL sibling file:
$ echo 60 | sudo tee /mnt/r53fs/example.com/@/A.TTL
Wildcard records — e.g. *.example.com — are named exactly as you expect; note, however, that * expands in most shells so you'll need to escape it if running from the command line:
$ sudo mkdir /mnt/r53fs/example.com/\*
$ echo www.example.com | sudo tee /mnt/r53fs/example.com/\*/CNAME
Of course, file systems can be accessed by any tooling, not just at the command line; for example, we can update DNS from a cron job:
$ echo "*/5 * * * * root date > /mnt/r53fs/daemonology.net/vixie/TXT" | sudo tee -a /etc/crontab
$ sleep 600
$ dig +short -t txt vixie.daemonology.net
"Tue Aug 25 00:20:01 UTC 2026"
Things to know
Let me share some important technical details that I think you'll find useful.
- Route 53 Files integrates with AWS Identity and Access Management (IAM) for access control. Every role is created by you. The service holds no role-creation authority; if you remove the IAM Roles, the service will immediately and silently stop working.
- If the same record is changed in the file system and in Route 53 at the same time, we aim for last-write-wins. This is not strictly possible, since Route 53 does not expose modification timestamps on records, so sometimes we make an educated guess based on when the record was changed in the file system and the window within which we know the record changed in Route 53.
- A write that Route 53 rejects is reported in a .error file alongside the record. This happens asynchronously, after the malformed data arrives at Route 53; if you look for an .error file immediately after writing a record, you won't see it yet.
- Routing policies, DNSSEC-specific record types, and Aliases with EvaluateTargetHealth set to true are not supported at this time. Any records found in Route 53 which are not supported by Route 53 Files will be reported in a .r53fs-unsupported file in the file system root.
- Changes will appear in Route 53 a period of time after you stop editing a record. Consistent with S3 Files, if you hold a file open and make continuous changes to it, the changes will not propagate to Route 53.
- In order to support text editors which move or delete files before writing new files, there is a short hold-down period; running vi www/A should not result in NXDOMAIN errors.
What customers are saying
Corey Quinn, Chief Cloud Economist, Duckbill:
"I've spent years telling people that Route 53 is a database. Colin embraced this righteous philosophy like a champion, and this insane thing is miles better than the actual Route 53 API, which is an embarrassment to databases everywhere. There are no change timestamps, it features no events, and for some godforsaken reason has a ChangeBatch schema that reads like XML that learned JSON in prison. Meanwhile echo and tee got my record live in 72 seconds. Thanks, Colin!"
Pricing and availability
Route 53 Files is available today in all commercial AWS Regions except Middle East (Bahrain) and Middle East (UAE). Note that since Route 53's control plane operates entirely in the us-east-1 region, a regional outage affecting us-east-1 will prevent your Route 53 Files file systems from updating DNS — although they will still be accessible in their own regions.
You pay for the infrastructure created by Route 53 Files inside your AWS account, but the Route 53 Files service itself is free.
I'd love to hear how you use this new capability. Feel free to share your feedback in the comments below.
Frequently Asked Questions
Q. Is this an official AWS service?
A. Of course not; but I'd be happy to let them have it if they're crazy enough
to want to maintain it.
Q. Why didn't this launch on April 1st?
A. Because S3 Files launched in early April and I didn't want to wait until
April 2027.
Q. Why expose DNS zones over NFS instead of a FUSE file system?
A. Because it's funnier. Also, because that's what S3 Files does (but I
repeat myself).
Q. What happens if you run rm -rf *?
A. Route 53 Files attempts to delete all of your DNS records, of course;
what else would it do? (Note that Route 53 doesn't allow you to delete
your hosted zone's SOA or apex NS records, so those records will silently
reappear in the file system.)
Q. Is there an SLA?
A. Yes, I guarantee a 100% refund of fees paid in any month where
availability is less than 110%.
Q. Is this HIPAA compliant?
A. Please do not store patient information in DNS.
Q. Did anyone at Amazon know you were doing this?
A. Absolutely not. If they knew, they would have had to try to stop me.
Amazonians aren't just people I work with; they're my friends, and I don't
want anyone to get in trouble for me being irredeemably weird.