Route 53 Files Console

Route 53 Files mirrors a hosted zone onto a filesystem you can mount: your DNS records appear as files, and editing a file changes the record.

This page does two things: it gets you started, in five steps below, and it lets you leave, at the bottom. It shows no status — there is nothing here to log in to, and nothing that knows who you are. Once a zone is enrolled it syncs on its own, and this page has nothing further to tell you about it.

1. Generate IAM Role bundle

This step runs entirely in your browser. It has no network access and asks for no credentials: the documents below are generated here and go straight to your downloads.

Twelve digits. It appears in the resource patterns to restrict access to your account's data.
Comma-separated. Use * to grant access to every Route 53 zone in your account.

2. Install IAM Roles in your AWS account

Unpack the download and read README.txt: it lists what you are granting and why. The policy documents are the whole of it — ten documents, a trust policy and a permissions policy for each of five IAM roles. There is nothing else, and nothing hidden.

Then run create-roles.sh, or the commands inside it, with your own AWS credentials. It creates the four roles enrollment needs. A fifth, the only one that can delete anything, is behind its own flag — --deprovisioning — and is needed only on the day you leave.

Keep the external id. It is in the bundle and in every trust policy, we never see it until you enrol, and we cannot recover it for you.

3. Enrol a zone

Once the roles exist, enrol a zone. This step posts to Route 53 Files; nothing else on this page ever leaves your browser.

The same account the roles were created in. Filled in for you if you created a bundle above.
One zone per enrollment. A zone may be enrolled in several regions, each with its own bucket and file system.
Where the file system is created, and where you will mount from. The list is a convenience — any region S3 Files supports will work.
The one from your bundle. If you generated it in a previous visit, paste it — we never see it until you submit, and cannot recover it for you.

Operational notices. We collect no address, so the reply to this form is the only thing Route 53 Files will ever send you. To hear about anything after that — incidents, planned changes, the service moving accounts — email r53fs-announce-subscribe@tarsnap.com. Low volume, operational only, and not linked to your enrollment: we do not know which subscriber runs which zone.

4. Create a mount target

Enrolling gives you a file system id. Before anything can reach it, create a mount target in the VPC you will mount from — the enrollment reply repeats this command with your own id filled in:

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 us-east-1

One per Availability Zone, all in the same VPC — both are AWS constraints, so choose the VPC before you start rather than after a second command fails. An instance in an AZ with no mount target cannot mount at all. They take about five minutes to become available.

Your records sync whether or not you ever do this. The mount is only how you read them.

5. Mount the filesystem

You need amazon-efs-utils version 3.0.0 or later; earlier versions predate S3 Files and cannot mount one. Amazon Linux 2023 does not ship it:

sudo yum install amazon-efs-utils

Then:

sudo mkdir -p /mnt/r53fs/example.com
sudo mount -t s3files -o nodirects3read \
    fs-0123456789abcdef0 /mnt/r53fs/example.com

If the mount fails with "Failed to resolve", wait ten minutes and try again. The mount target's DNS name takes time to propagate after the target is created, and until it does the error names your file system id — which is the one thing that is not wrong.

nodirects3read turns off S3 Files' direct-from-S3 read path. That path exists for large sequential reads — megabytes at a time — and DNS records are tens of bytes, so it never engages here. Turning it off means your instance role needs no access to the underlying bucket at all: one managed policy and nothing else. It also avoids a startup delay when the direct path is unreachable, which it is on a private subnet without an S3 gateway endpoint.

The instance needs an IAM role granting it access to S3 Files. Use AmazonS3FilesClientFullAccess. Of the three client policies only that one grants root access, and AmazonS3FilesClientReadWriteAccess — which sounds sufficient — lets the mount succeed and then refuses every write. See IAM role for your compute resource, and Mounting S3 file systems on Amazon EC2.

The mount helper always uses TLS and IAM authentication; neither can be turned off. Your DNS records are then files: read them, edit them, and the changes go back to Route 53.

Leaving

Offboard a zone whenever you like. Your DNS is untouched by this — Route 53 Files only ever mirrored it — and nothing here can reach anything except the bucket and file system we created for that zone.

Unmount first. We strongly recommend unmounting your Route 53 Files file systems before deprovisioning them, since otherwise you may be stuck with a broken file system mount you can't unmount.

sudo umount /mnt/r53fs/example.com
The same external id you enrolled with. We compare it before touching anything, and we cannot recover it for you.
This deletes the bucket and file system for that zone. They are not recoverable, so it is worth typing twice.