GoKawiilLaunching Route 53 Files
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.
... continue reading