AWS Route 53 suspension takes client sites and email offline

Amazon Web Services restored access to a suspended Route 53 account used by Digital Takumi after an expired payment card and failed account recovery process took customer websites and related Google Workspace email offline. The incident is a routine billing failure with an industry-relevant lesson: even small DNS and domain accounts can become single points of failure when billing, MFA and recovery email are tied to fragile processes.

Christopher Bradbury, who runs the web design and development firm Digital Takumi, told The Register he discovered on July 16 that domains under his management were no longer resolving. The affected websites and email accounts were connected to domains hosted through AWS Route 53, according to his account of the incident.

Bradbury later found multiple AWS billing messages in a spam folder. The notifications warned that the card attached to the account had expired and that suspension would follow unless the issue was fixed. Some messages also went to an employee who had left the company, he told The Register.

The unpaid amount was not disclosed. Bradbury said he accepted responsibility for missing the alerts, but that acknowledgement did not solve the operational problem: he could not get into the AWS account to update the card and pay the invoices.

Account recovery failed at several layers

The lockout was compounded by a weak recovery setup. Bradbury told The Register the AWS root account had multi-factor authentication enabled through a software authenticator stored on an old laptop. That laptop later suffered a motherboard failure, leaving him without the authenticator used for the account.

He had been relying on email-based MFA recovery rather than updating the authentication method. That shortcut became unusable because the root email address for the AWS account belonged to one of the domains affected by the Route 53 suspension. With DNS down, he could not receive the verification message required by AWS recovery.

Bradbury then tried to contact AWS using another email address. He also created a separate AWS account and bought business support access after a recommendation, according to The Register. Support staff he reached through that route would not discuss the suspended account until he could prove ownership, which was the issue he was trying to resolve.

He said he spoke with several AWS groups, including billing and account recovery, and was passed between teams without being able to complete verification or regain access. In practical terms, the same loop blocked every path: no login, no root email, no MFA device, no card update and no payment from inside the account.

After The Register contacted Amazon and Bradbury while reporting the matter, Bradbury said access was restored. He then logged in, paid the outstanding invoices, changed the payment method, reset MFA credentials and completed the delayed maintenance on the account.

A small account carried production risk

Bradbury described the setup as modest, involving a company marketing site and domains in Route 53 rather than a large infrastructure footprint. That is the point for operators: DNS, billing contacts and authentication recovery are infrastructure, even when the monthly bill is small.

The incident also shows where standard controls break down. Billing alerts routed to spam or former staff are not alerts. A recovery email hosted on the same domain infrastructure it is meant to rescue is a dependency loop. An MFA device left on a failed machine is not a recovery plan.

AWS had resolved the immediate issue by the time Bradbury updated The Register. AWS did not disclose any broader change to its recovery or suspension handling in connection with the incident.

This story draws on original reporting from The Register.