EurosHub builds AI-powered business systems that automate operations and scale companies. One lesson from the AWS outage in October 2025 is clear: even highly reliable cloud platforms can experience major failures. Businesses need systems that can continue working when a cloud service, region, database, or network component goes down.
The AWS outage in October 2025 affected multiple AWS services in the US-EAST-1 (Northern Virginia) region. The first major trigger was a DNS problem involving Amazon DynamoDB. The failure then spread through services that depended on DynamoDB, EC2, and network load balancing.
AWS later explained that a race condition in its DynamoDB DNS management system caused an empty DNS record for the regional DynamoDB endpoint. This meant customers and AWS internal systems could not properly resolve the DynamoDB endpoint.
This article explains what caused the AWS outage, what businesses were affected, and what companies can do to build more resilient systems.
What Was the AWS Outage in October 2025?
The AWS outage happened mainly in the US-EAST-1 region on October 20, 2025.
AWS reported increased errors and latency beginning around 11:49 PM PDT on October 19. The first major issue involved DynamoDB. AWS identified DNS resolution problems for the regional DynamoDB endpoint as the trigger.
The wider incident later affected services including:
- Amazon DynamoDB
- Amazon EC2
- Elastic Load Balancing
- AWS Lambda
- Amazon Redshift
- AWS IAM-related functions
- Amazon CloudWatch
- Amazon Connect
- AWS Config
- Other services that depended on the affected infrastructure
AWS reported that core services returned to normal by around 3:01 PM PDT on October 20, although some services still had backlogs to process.
What Caused the AWS Outage?
The Short Answer
The root cause was a DNS management failure inside Amazon DynamoDB in US-EAST-1.
AWS explained that a race condition in the automated DNS management system caused the DynamoDB regional endpoint to receive an incorrect empty DNS record. The automation that should have corrected the problem did not repair the record as expected.
The affected endpoint was:
dynamodb.us-east-1.amazonaws.com
Because applications need DNS to find the correct service endpoint, the DNS problem prevented many systems from connecting to DynamoDB.
Why Did a DNS Problem Become Such a Large Outage?
This is one of the most important lessons from the event.
DynamoDB was not an isolated system. Many AWS services and customer applications depend on it.
Once DynamoDB became unavailable, services that needed DynamoDB also started experiencing problems.
The incident then developed into several connected failure stages:
DynamoDB DNS failure → dependent services fail → EC2 launch problems → network load balancer issues → additional service failures
This is known as a dependency chain.
A failure in one important component can create failures in other components when systems are tightly connected.
AWS Outage October 20, 2025 Timeline
Here is a simplified AWS outage timeline.
TimeEvent
Oct. 19, 11:48 PM PDT
DynamoDB problems begin in US-EAST-1
Around 12:26 AM
AWS identifies DNS resolution problems
Around 2:24–2:40 AM
DynamoDB DNS recovery completes and connections begin recovering
Around 2:25 AM
EC2 launch problems continue because of dependencies on DynamoDB
Around 5:30 AM
Some Network Load Balancer health checks begin failing
Around 9:38 AM
NLB health check issues are recovered
Around 3:01 PM
AWS services return to normal operation
After recovery
Some services continue processing backlogs
AWS's public service history confirms that the US-EAST-1 multiple-service event started late on October 19 and continued through October 20.
What Services Were Impacted by the AWS Outage?
The incident was larger than a simple DynamoDB outage.
Amazon DynamoDB
DynamoDB was the first major component affected.
Customers using DynamoDB in US-EAST-1 experienced API errors because the regional endpoint could not be resolved correctly.
Customers using DynamoDB Global Tables could continue using replicas in other regions, but replication involving US-EAST-1 was delayed.
Amazon EC2
Existing EC2 instances that were already running were not the main problem.
However, customers had problems launching new EC2 instances.
This happened because parts of the EC2 control plane depended on DynamoDB.
This is an important distinction:
Your running infrastructure can remain healthy while your ability to create new infrastructure fails.
That is why businesses should test both application availability and recovery operations.
Network Load Balancer
Network Load Balancers were also affected.
Some NLB health checks failed, creating connectivity problems for services using the load balancers.
AWS eventually changed the health-check behavior during recovery to restore healthy nodes and backend targets.
AWS Lambda
Lambda customers also experienced problems.
The initial DynamoDB issue affected several Lambda operations. Later, EC2 and NLB problems created additional capacity and invocation issues.
AWS temporarily throttled some Lambda-related operations during recovery to protect more important workloads.
Amazon Redshift
Redshift was also affected.
Some Redshift operations depended on DynamoDB and EC2-related processes.
This shows how a service that appears unrelated to DynamoDB can still be affected by a shared dependency.
AWS IAM and Console Access
Some customers also experienced authentication and AWS console problems.
AWS reported that IAM-related functions depending on the affected infrastructure experienced increased failures during the incident.
Was the AWS Outage a Cyberattack?
There is an important difference between an outage and a cyberattack.
The October 2025 AWS event was attributed by AWS to an internal technical failure involving DynamoDB's DNS management system. AWS's post-event information did not identify the incident as a DDoS attack or external hack.
Businesses should therefore avoid assuming that every major cloud outage is caused by a security attack.
Cloud failures can also come from:
- Software bugs
- DNS problems
- Configuration errors
- Network failures
- Automation failures
- Database problems
- Dependency failures
- Control-plane issues
- Human error
Why the AWS Outage Matters for Businesses
The biggest lesson is not simply that AWS can go down.
The bigger lesson is that cloud dependency must be designed carefully.
Many businesses assume that using AWS automatically gives them high availability.
It does not.
AWS provides powerful infrastructure, but the resilience of your application still depends on how you design it.
For example, an application can be hosted on AWS but still have a single point of failure because it relies on:
- One AWS Region
- One database
- One DNS path
- One API
- One authentication provider
- One queue
- One third-party service
- One control-plane dependency
If that dependency fails, the application can fail too.
How to Future-Proof Your Business After the AWS Outage
Future-proofing does not mean making your system impossible to break.
That is unrealistic.
The goal is to limit the impact of failures and recover quickly.
Here are the most important steps.
1. Design for Multiple Availability Zones
Do not place every critical component in one Availability Zone.
Use multiple Availability Zones where appropriate.
This can help your application continue running when infrastructure in one zone experiences problems.
AWS itself recommends multi-AZ architectures for applications that require high availability.
2. Consider Multi-Region Architecture
For critical applications, consider using more than one AWS Region.
For example:
Primary Region → Secondary Region → Automated or controlled failover
A multi-region design can reduce the risk of one regional failure taking down the entire business.
However, multi-region architecture also adds cost and complexity.
It should be used when the business impact of downtime justifies it.
AWS guides cross-region failover and evacuation strategies for resilient DynamoDB applications.
3. Reduce Single Points of Failure
Create a dependency map for your application.
Ask:
- What happens if our database fails?
- What happens if DNS fails?
- What happens if authentication fails?
- What happens if our cloud region becomes unavailable?
- What happens if our payment provider goes down?
- What happens if our email provider stops working?
- What happens if our API provider becomes unavailable?
This exercise can reveal hidden risks.
4. Build Reliable Backups
Backups should not simply exist.
They should be tested.
A good backup strategy should answer:
Can we restore the data?
How long will recovery take?
Where will we restore it?
Can the business operate while recovery happens?
Regular restore testing is more useful than simply checking whether backup jobs completed.
5. Define RTO and RPO
Two important disaster recovery terms are RTO and RPO.
RTO — Recovery Time Objective
RTO answers:
How quickly must the system be restored?
For example:
RTO: 30 minutes
This means the business aims to restore the service within 30 minutes.
RPO — Recovery Point Objective
RPO answers:
How much data can the business afford to lose?
For example:
RPO: 5 minutes
This means the company aims to recover data to a point no more than five minutes before the incident.
Your architecture should be designed around these business requirements.
6. Use Health Checks and Monitoring
Do not wait for customers to report that your application is down.
Use:
- Application monitoring
- Infrastructure monitoring
- Synthetic tests
- Database monitoring
- API monitoring
- Error-rate alerts
- Latency alerts
- Log monitoring
- Cloud provider health information
Monitoring should detect both availability problems and unusual behavior.
7. Create a Real Disaster Recovery Plan
A disaster recovery document is not enough.
Your team should practice it.
Run controlled tests such as:
What happens if Region A becomes unavailable?
What happens if the primary database cannot be reached?
What happens if DNS is unavailable?
What happens if authentication stops working?
This type of testing is often called chaos engineering or resilience testing.
The purpose is not to break production randomly.
The purpose is to understand how the system behaves before a real incident happens.
8. Avoid Hidden Cloud Dependencies
One of the most important lessons from the October 2025 AWS outage is that dependencies can be difficult to see.
Your application may appear to use:
App → Database
But the real dependency chain may be:
App → API → Authentication → DNS → Database → Network → Cloud control plane
Every additional dependency creates another possible failure point.
Document these dependencies before designing your disaster recovery strategy.
9. Pre-Provision Critical Recovery Resources
Recovery should not depend entirely on creating new infrastructure during an outage.
If your recovery process requires you to create new resources through a cloud control plane that is itself impaired, recovery can become much harder.
AWS's fault-isolation guidance recommends pre-provisioning certain resources rather than depending on control-plane actions during recovery.
This is a powerful lesson for enterprise architecture.
Prepare before the outage, not during it.
10. Build Business Continuity, Not Just Technical Recovery
Technical recovery is only one part of resilience.
Ask what your employees and customers can do if the main application is unavailable.
For example:
- Can customer support continue?
- Can employees access customer records?
- Can orders still be accepted?
- Can payments be processed?
- Can customers contact your team?
- Can essential reports still be produced?
- Can staff work from an alternative system?
A resilient business needs more than resilient servers.
What Companies Should Learn From AWS Outage 2025
The AWS outage provides several important lessons.
Lesson 1: Cloud providers can fail
AWS, Azure, and Google Cloud are highly reliable, but none can promise zero downtime.
Lesson 2: Dependencies matter
A database problem can affect compute, networking, authentication, monitoring, and other services.
Lesson 3: One region may not be enough
If your business cannot tolerate a regional outage, consider multi-region architecture.
Lesson 4: Backups must be tested
A backup that has never been restored is not a fully proven recovery plan.
Lesson 5: Recovery needs to be automated
Manual recovery can be slow during a major incident.
Automation can reduce human error and recovery time.
Lesson 6: Business continuity matters
Your goal should not simply be to keep servers online.
Your goal should be to keep the business operating.
How EurosHub Helps Businesses Build More Resilient Systems
At EurosHub, we focus on building AI-powered business systems that automate operations and scale companies.
For businesses that depend heavily on cloud infrastructure, resilience should be part of the system design from the beginning.
A modern Business Automation System can include:
- Cloud-based application architecture
- CRM workflows
- AI-powered customer support
- Automated business processes
- Monitoring and reporting
- Backup and recovery planning
- API integrations
- Database architecture
- Disaster recovery workflows
- Multi-region planning where required
The goal is not to add technology simply for the sake of technology.
The goal is to build systems that help the business continue operating when individual services fail.
AWS Outage 2025: A Simple Resilience Checklist
Use this checklist to review your current infrastructure:
- Do we know our critical cloud dependencies?
- Do we use multiple Availability Zones?
- Do we need multi-region protection?
- Are our databases backed up?
- Have we tested restoring those backups?
- Do we have clear RTO and RPO targets?
- Do we monitor application health?
- Do we have automated alerts?
- Can our application survive a database failure?
- Can customers still contact us during an outage?
- Do we have a documented disaster recovery plan?
- Has the team tested the recovery plan?
- Are critical recovery resources pre-provisioned?
- Do we have a fallback process for critical business operations?
If several answers are "no," your business may have more outage risk than you realize.
Frequently Asked Questions
What caused the AWS outage in October 2025?
The main trigger was a DNS resolution failure involving the DynamoDB regional endpoint in US-EAST-1. AWS said a race condition in its automated DynamoDB DNS management system caused an incorrect empty DNS record.
When did the AWS outage happen?
The major AWS incident began late on October 19, 2025, and continued into October 20 in the US-EAST-1 region. AWS reported the wider multi-service event from around 11:49 PM PDT on October 19 until services returned to normal on October 20.
What was affected by the AWS outage?
DynamoDB was the initial major service affected. The incident then affected or disrupted services and functions involving EC2, Network Load Balancers, Lambda, Redshift, IAM-related operations, CloudWatch, and other AWS services.
Final Thoughts
The AWS outage in October 2025 showed how a problem in one important service can spread through a complex cloud ecosystem.
The incident started with a DynamoDB DNS problem in US-EAST-1. From there, dependencies involving EC2, networking, Lambda, Redshift, and other services increased the overall impact.
The right response is not to stop using cloud technology.
Instead, businesses should use the incident as a lesson.
Build systems with:
Redundancy + monitoring + tested backups + clear recovery plans + automated failover + strong dependency management.
That is how companies can move from simply being cloud-hosted to being truly cloud-resilient.
EurosHub helps businesses design AI-powered business systems, automation workflows, CRM solutions, and scalable digital infrastructure built around real business needs—not just individual technology tasks.
