AWS DNS Race Condition Outage: What It Means For Your Site’s Resilience

AWS has published a postmortem explaining how a race condition in the DNS system used by DynamoDB cascaded into a large cloud outage. Many services that rely on AWS went offline or became unreliable for hours. If your WordPress or WooCommerce site depends on AWS directly, or through third party tools, you may have seen timeouts, broken checkouts or missing emails during the incident.

What happened

Amazon’s own write up describes a fault in the DNS management layer used by DynamoDB. In simple terms, DNS is the internet’s address book. DynamoDB is a key database service inside AWS. The two became tangled in a way that created a feedback loop.

From the public information, the sequence looked roughly like this:

• A race condition in the internal DNS system for DynamoDB caused incorrect or unstable DNS responses.
• Some DynamoDB endpoints became unreachable or very slow to resolve.
• Applications and AWS services that depend on DynamoDB started to fail or retry heavily.
• The extra retries and internal failover attempts increased load on DNS and control plane systems.
• This created a wider outage that affected multiple AWS services and regions for several hours.

The result was that a single low level bug in DNS handling for one core service rippled out into a broad incident across the AWS ecosystem. Many well known brands that rely on AWS saw partial or complete downtime.

It is important to stress that this was not a security breach. It was an internal infrastructure failure that showed how tightly coupled large cloud services can be.

How this affects WordPress and WooCommerce sites

Even if you do not log into the AWS console, your site may still depend on AWS indirectly. Many plugins, payment providers, search tools and email services run on AWS behind the scenes.

During an outage like this, WordPress and WooCommerce sites can be affected in several ways:

1. Full site downtime

If your site is hosted directly on AWS, or your hosting provider’s core infrastructure is in an affected AWS region, you may have seen:

• Pages failing to load or timing out.
• Intermittent 502 / 504 gateway errors.
• Admin access failing or being extremely slow.

In this case, your web server could not reliably talk to its database or other AWS services, so normal redundancy inside a single region did not help.

2. “Partial” outages that are easy to miss

Many sites did not go completely down. Instead they suffered from broken pieces, for example:

• Checkout hanging on “processing” because a payment gateway API call stalled.
• Search, filtering or product recommendations failing if they used a hosted search service running on AWS.
• Contact forms or order emails not sending if your transactional email provider was impacted.

From a customer’s point of view, this looks like your site is unreliable, even if your own server and database were fine.

3. Knock on performance issues

Even when services do not fully fail, DNS problems and slow third party APIs can:

• Increase page load times, especially on checkout and account pages.
• Cause spikes in PHP and database usage as WordPress waits on slow external calls.
• Trigger 502 / 504 errors under load because upstream services do not respond in time.

These symptoms are very similar to normal capacity problems, which can make diagnosis harder in the moment.

How to check if you were affected

If you saw issues around the time of the AWS outage, there are a few simple checks you can do now.

1. Review your own monitoring and logs

• Check any uptime monitoring you use for spikes in downtime or slow response times.
• Look at your web server or application logs for a cluster of 502 / 504 errors or connection timeouts.
• On WooCommerce, review order logs for a period with more failed or “pending payment” orders than usual.

If you do not yet have basic monitoring in place, our guide “Why Uptime Matters and How to Monitor Your WordPress Site Properly” walks through practical options.

2. Check third party service status pages

Most major providers publish incident histories, for example payment gateways, email services and search tools. Look for:

• Incidents on the same date as the AWS outage.
• Mentions of “AWS”, “DynamoDB” or “DNS” in their explanations.

If your plugin or integration uses a specific SaaS tool, it is worth bookmarking its status page for future reference.

3. Ask your hosting provider for their view

Your host should be able to tell you whether:

• Your servers are on AWS or another public cloud.
• They saw network or DNS related issues during the incident window.
• They have any internal postmortem or mitigation plan.

If the answer to all three is “we do not know”, that is useful information in itself when you think about resilience.

What to do next

You cannot prevent AWS or any other large provider from having incidents. You can, however, reduce how much impact they have on your own site.

1. Map your dependencies

Make a simple list of what your site relies on:

• Where the site is hosted.
• Which DNS provider you use.
• Payment gateways and fraud tools.
• Email delivery (order emails, password resets, newsletters).
• Search, analytics, personalisation or recommendation services.

For each one, note whether it runs on AWS or another large cloud. Many providers state this in their documentation or legal pages.

2. Treat DNS as critical infrastructure

This outage started with DNS. For your own domain, you should:

• Use a reputable DNS provider with a clear uptime track record.
• Avoid having DNS, hosting and email all on the same single point of failure where possible.
• Keep DNS records simple and documented so changes can be made quickly if needed.

Our guide “What ‘Redundancy’ Really Means in Hosting” explains how DNS fits into a wider resilience picture.

3. Add timeouts and fallbacks for external services

Many WordPress and WooCommerce plugins assume that external APIs will always respond quickly. When they do not, your whole page can hang.

Where possible:

• Configure sensible timeouts for API calls in plugins that support it.
• Use asynchronous calls or background tasks for non critical features such as analytics and recommendations.
• Provide fallbacks, for example a basic on site search if a hosted search service is unavailable.

If you are not comfortable tuning these settings yourself, a managed hosting provider or developer can help you review the most important integrations.

4. Design for graceful degradation

Not every feature needs to be online for your business to keep trading. When you plan for outages, think in terms of:

• “Must work” features such as checkout, login and account pages.
• “Nice to have” features such as product recommendations, live chat or advanced search.

During a third party incident, it is better for non essential features to switch off cleanly than to slow or break the core journey.

5. Review your hosting architecture and SLAs

Ask your current host:

• Whether your site is in a single data centre, single cloud region or spread across multiple locations.
• What happens if their upstream cloud provider has a regional outage.
• How they monitor and respond to DNS or control plane issues.

Compare their answers with your own tolerance for downtime. If your WooCommerce store cannot afford to be offline on key trading days, you may need a more resilient setup than a single cloud region and a basic uptime guarantee.

How G7Cloud thinks about resilience and DNS risk

G7Cloud runs its own hardware and UK data centre rather than building everything on top of a single public cloud. That does not make us immune to incidents, but it does mean we are not directly affected when an AWS internal service fails.

The G7 Acceleration Network also helps reduce the blast radius of some upstream issues by:

• Caching pages closer to visitors so brief origin issues are less visible.
• Filtering abusive traffic so your servers are not overloaded when external services misbehave.
• Handling image optimisation and security headers at the edge, which reduces the work your origin has to do during stressful periods.

For clients that need higher resilience, we can design architectures with redundant DNS, multi server setups and clear disaster recovery plans. Our guide “From Backups to Business Continuity” covers how to approach this in practical steps.

Conclusion: turn a cloud outage into a resilience review

The AWS DNS race condition incident is a reminder that even the largest providers have bad days, and that many sites rely on AWS indirectly through third parties.

This is a good moment to:

• Map where your dependencies really live.
• Check how your site behaves when external services are slow or unavailable.
• Review whether your current hosting and DNS setup match how critical your site has become.

If you would like fewer surprises and a clearer resilience plan for your WordPress or WooCommerce site, it may be worth exploring managed hosting and a more robust architecture. Whether you stay where you are or move, having an honest view of your risk and a simple plan for outages will pay off the next time a big cloud provider has a bad day.