What happened
AWS has added configurable EBS volume initialization rates to its Elastic Disaster Recovery service, allowing operators to control how aggressively recovered volumes pre-fetch data from Amazon S3 after a failover or drill. Previously, blocks not yet loaded from S3 during snapshot restoration delivered degraded I/O performance until background hydration completed — a window that could stretch workload recovery timelines significantly. Separately, Cloudflare documented a real-world DNSSEC failure in which a botched key rollover for Albania's .AL top-level domain caused widespread resolution failures. To restore service, Cloudflare deployed a Negative Trust Anchor on its 1.1.1.1 resolver and, critically, added Extended DNS Error code 33 to responses — a standardized signal informing clients that DNSSEC validation had been intentionally bypassed rather than simply passing silently.
Why it matters for your business
For teams running disaster recovery on AWS, the initialization rate control closes a gap that made RPO and RTO targets harder to meet in practice: a recovered server that runs slowly for the first hour of a failover can undermine even a well-architected DR plan. Operations and infrastructure leaders should review their DRS configurations and set initialization rates appropriate to the performance tier of their production workloads. On the DNS side, the .AL incident is a reminder that DNSSEC misconfigurations at registry level can silently degrade or eliminate resolution for entire domains — and that organizations relying on external resolvers had no visibility into why validation was bypassed. EDE 33 support in 1.1.1.1 gives security and network teams a programmatic signal they can monitor, log, and alert on rather than debugging blind.
What to watch next
AWS is likely to extend initialization rate controls to additional DRS scenarios as the feature matures, so teams should monitor service documentation for updates to supported instance types and volume classes. On the DNS front, broader adoption of Extended DNS Error codes across other public and enterprise resolvers would standardize incident visibility — worth tracking in resolver vendor roadmaps. The .AL incident also reinforces ongoing industry pressure on registries and registrars to improve DNSSEC rollover tooling and validation pipelines before failures reach production.