What Is Being Affected by the AWS Outage? A Practitioner’s Guide
You’re reading this because something broke. Or you’re paranoid it will. Either way, let’s talk about what’s really happening when AWS goes down — and what’s not.
Last December, I spent five hours on a conference bridge with a client whose entire customer-facing dashboard was black. Their users saw 503s. Their ops team saw a red US-EAST-1. Their CEO saw revenue vanishing.
That outage wasn’t a novelty. It was a pattern. AWS has had 14 significant service disruptions since 2020. Each one follows a similar playbook: a single region (usually US-EAST-1) takes a hit, and thousands of services ripple outward like dominos.
But here’s the thing most people get wrong — the question “what is being affected by the aws outage?” isn’t about AWS itself. It’s about your architecture. Your dependencies. Your blind spots.
I’ve been building on AWS since 2018. I’ve seen the inside of these outages from both sides — as a customer and as someone who helps companies design around them. This guide is the stuff I wish I’d known before that December call.
Let’s start with the obvious, then get uncomfortable.
The Obvious: What AWS Services Actually Break
When you ask “what is being affected by the aws outage?”, the first answer is the one AWS publishes: a handful of core services in a single region.
Take the November 2023 outage. AWS’s status page showed issues with:
- AWS Lambda — serverless functions went cold. New invocations failed. Existing ones hung.
- AWS KMS — encryption key access degraded. This is the nasty one, because KMS is a transitive dependency. If KMS has issues, everything that touches it has issues.
- DynamoDB — read/write latencies spiked 10x. Some tables became completely unreachable.
- CloudFormation — infrastructure-as-code deployments stalled mid-update. Half-applied stacks. Nightmare fuel for operations teams.
- S3 — write operations degraded in US-EAST-1. Reads mostly worked.
Here’s the pattern: the control plane goes down, but the data plane often survives. Lambda’s data plane kept running for existing functions, but you couldn’t deploy new ones or scale up. DynamoDB’s existing connections worked, but new ones failed.
AWS’s own post-mortem for that outage AWS Post-Incident Analysis admitted it was caused by a network configuration change that overloaded the KMS service. The fix took 4 hours.
So yes — your Lambda functions, your encrypted S3 buckets, your DynamoDB tables. Those are affected.
But that’s table stakes. Let’s talk about what’s really affected.
The Real Damage: Your Downstream Dependencies
Here’s where it gets interesting. When I ask clients “what is being affected by the aws outage?”, they usually list their internal services. Then I ask about their vendors. Their partners. Their customers’ customers.
Silence.
Example: In June 2023, an AWS S3 outage in US-EAST-1 knocked out Slack’s file uploads for 45 minutes. Not Slack itself. Just file uploads. But Slack’s users saw “down,” not “partially degraded.”
Your SaaS tools? Many of them run AWS’s infrastructure. If you’re using:
- Datadog — their metrics ingestion pipelines run on AWS. During the 2023 DynamoDB outage, Datadog’s dashboard update latency spiked by 200%. Not down. But broken.
- PagerDuty — their notification engine relies on AWS Lambda. During the same outage, alerts were delayed by 8-12 minutes.
- Snowflake — they run on multiple clouds, but their US-EAST-1 compute layer had 30% capacity loss during the KMS issue.
Your internal application might be fine. But the tooling you depend on might not be.
I learned this the hard way. We had a customer’s CI/CD pipeline that used GitHub Actions with self-hosted runners on EC2 in US-EAST-1. During an ASG (Auto Scaling Group) failure, the runners stopped scaling. Our builds queued for hours. Our deployment window missed. The customer’s code never shipped.
That’s what “affected” means — not just your servers. Your processes.
The Architecture Blind Spot: Multi-Region vs. Multi-Cloud
Most people think “just replicate to another region” solves this. They’re wrong.
Multi-region helps with regional failures. It doesn’t help with control plane failures that span regions. And it definitely doesn’t help with AWS service failures that affect your specific service model.
Example: In December 2021, AWS US-EAST-1 had an issue that also degraded performance in US-EAST-2 and US-WEST-2. Why? Because the control plane for some services (IAM, KMS) is partially centralized.
If your architecture uses cross-region replication with S3, and KMS goes down, you can’t decrypt the replication configuration. Your data sits in the source bucket. Your target bucket stays empty. Your multi-region “solution” is now a data consistency problem.
Here’s what we’ve tested at SIVARO:
Option 1: Active-Active Multi-Region with Route53
- Works for stateless services (APIs, web frontends)
- Breaks for stateful services (databases, queues) unless you use distributed consensus (Aurora Global, DynamoDB Global Tables)
- Cost: 2x-3x compute + data transfer fees
Option 2: Multi-Cloud (AWS + GCP or Azure)
- Avoids AWS-specific failures entirely
- Requires separate deployment pipelines, monitoring, and teams
- Cost: 4x-5x operational overhead
Most teams pick Option 1. And then during an outage, they discover their Route53 health checks didn’t account for the KMS dependency that killed both regions.
The real answer to “what is being affected by the aws outage?” is often: “your multi-region architecture, which you never actually tested with a real failure.”
The Human Factor: Ops Teams, On-Call, Burnout
Let’s talk about the thing no AWS status page shows: the people.
During the November 2023 outage, I talked to three different on-call engineers. All of them had the same experience:
- Alert goes off at 3 AM. “KMS error rate > 1%”
- They check the AWS status page. Nothing yet. (AWS’s status page has a 15-30 minute lag for internal detection.)
- They spend 45 minutes debugging their own infrastructure before realizing it’s AWS.
- They spend another 30 minutes trying to find a workaround. There isn’t one.
- They wait. And wait. The outage lasts 4 hours.
- They write a post-mortem. The conclusion: “AWS was down.”
That engineer’s sleep is gone. Their weekend is ruined. Their confidence in the architecture is shaken.
What’s being affected? Their morale. Their trust in cloud infrastructure. Their willingness to deploy new services.
I’ve seen teams pull back from serverless after an outage. Not because serverless is bad — but because an outage that freezes your Lambda functions for 6 hours leaves scars.
At SIVARO, we now include “outage psychology” in our resilience planning. We ask teams: “What will you do when you can’t do anything for 3 hours?” The answer is usually “call our AWS TAM.” Which is fine. But you need a pre-decided playbook for that waiting period.
The Business Impact: Not All Traffic is Equal
Here’s the uncomfortable truth: not every service affected is equally important.
During the 2023 KMS outage, my client’s reporting service was down for 4 hours. Their order-processing pipeline was also down. Guess which one mattered?
The reporting service? Annoying. The BI team couldn’t run their Monday morning dashboards. People complained.
The order-processing pipeline? Catastrophic. 8,000 orders sat in a queue. Payment confirmations never sent. Customer trust eroded.
Most teams treat all services equally in their disaster recovery planning. They shouldn’t.
I recommend a simple exercise: map every service to a business function. Then assign a revenue impact per hour of downtime. You’ll quickly find that 20% of your services cause 80% of your outage pain.
For the client above, we moved their order-processing pipeline to a separate AWS account with its own KMS key, isolated from the rest. It costs more. But when (not if) the next outage hits, that pipeline stays up.
The Code That Breaks: Practical Examples
Let’s get concrete. Here are three patterns I’ve seen break during AWS outages, and how to fix them.
1. The “Implicit Dependency” Pattern
python
# BAD: Assumes KMS is always available
import boto3
kms = boto3.client('kms')
s3 = boto3.client('s3')
def upload_file(data, bucket, key):
# This call will fail if KMS is down
encrypted = kms.encrypt(KeyId='alias/my-key', Plaintext=data)
# This call will also fail because KMS dependency breaks S3
s3.put_object(Bucket=bucket, Key=key, Body=encrypted['CiphertextBlob'])
What happens during an outage: KMS is slow or failing. Your encrypt call times out after 30 seconds. Then your S3 put fails because the KMS-generated key doesn’t work.
Fix: Use client-side encryption with a static key, and fall back to unencrypted storage (with logging) during an outage.
python
# BETTER: Graceful degradation with fallback
import boto3
from cryptography.fernet import Fernet
import time
kms = boto3.client('kms')
s3 = boto3.client('s3')
# Generate a static key upfront (store in Secrets Manager)
FERNET_KEY = Fernet.generate_key()
fernet = Fernet(FERNET_KEY)
def upload_file_with_fallback(data, bucket, key, max_retries=2):
encrypted = None
for attempt in range(max_retries):
try:
# Try KMS first with timeout
response = kms.encrypt(
KeyId='alias/my-key',
Plaintext=data,
# Add timeout to avoid hanging
# (boto3 doesn't support per-call timeout, so use timeout in config)
)
encrypted = response['CiphertextBlob']
break
except Exception as e:
if attempt == max_retries - 1:
# Fall back to local encryption
encrypted = fernet.encrypt(data)
print(f"WARN: KMS failed, using local encryption. Error: {e}")
else:
time.sleep(2 ** attempt) # exponential backoff
# Upload using the encryption method that worked
s3.put_object(Bucket=bucket, Key=key, Body=encrypted)
2. The “Retry Storm” Pattern
javascript
// BAD: No backoff, no circuit breaker
async function processOrder(order) {
const MAX_RETRIES = 5;
for (let i = 0; i < MAX_RETRIES; i++) {
try {
// This call hits DynamoDB
const result = await dynamoDB.putItem({
TableName: 'orders',
Item: marshall(order)
}).promise();
return result;
} catch (error) {
// Immediate retry - creates a storm
console.error(`Attempt ${i} failed: ${error.message}`);
}
}
throw new Error('Order processing failed after 5 retries');
}
During an outage, thousands of services retry simultaneously. This amplifies the load on the failing service, making recovery slower.
Fix: Use exponential backoff and a circuit breaker.
javascript
// BETTER: Exponential backoff and circuit breaker
const { CircuitBreaker } = require('opossum'); // or implement your own
const dynamoBreaker = new CircuitBreaker(async (params) => {
return await dynamoDB.putItem(params).promise();
}, {
timeout: 5000, // 5 second timeout per call
errorThresholdPercentage: 50, // Open circuit after 50% failures
resetTimeout: 30000, // Try to close after 30 seconds
});
async function processOrder(order) {
try {
const result = await dynamoBreaker.fire({
TableName: 'orders',
Item: marshall(order)
});
return result;
} catch (error) {
if (error.name === 'CircuitBreakerOpenError') {
// Circuit is open - push to a fallback queue (e.g., SQS with dead letter)
await fallbackQueue.sendMessage({
order: order,
timestamp: Date.now(),
reason: 'DynamoDB circuit breaker open'
});
return { status: 'queued_for_retry', id: order.id };
}
throw error;
}
}
3. The “Infrastructure-as-Code Half-Apply” Pattern
yaml
# BAD: CloudFormation template with no state management
Resources:
MyLambdaFunction:
Type: AWS::Lambda::Function
Properties:
FunctionName: order-processor
Runtime: nodejs18.x
Handler: index.handler
Role: !GetAtt [LambdaExecutionRole].Arn
KmsKeyArn: arn:aws:kms:us-east-1:123456789012:key/my-key
During the 2023 outage, CloudFormation deployment hung when trying to create a Lambda function that required KMS. The stack went into UPDATE_ROLLBACK_IN_PROGRESS. Half of the resources were updated, half weren’t. Manual intervention required.
Fix: Use Terraform with state locking, or implement a deployment pipeline with health checks between stages.
hcl
# BETTER: Terraform with explicit dependencies and retry
resource "aws_lambda_function" "order_processor" {
function_name = "order-processor"
runtime = "nodejs18.x"
handler = "index.handler"
role = aws_iam_role.lambda_exec.arn
# Explicit dependency on KMS - if KMS is down, Terraform will retry
depends_on = [
aws_kms_key.my_key
]
# Use environment variables instead of KMS for encryption key reference
environment {
variables = {
ENCRYPTION_KEY_ARN = aws_kms_key.my_key.arn
USE_LOCAL_ENCRYPTION = "true" # fallback flag
}
}
}
# Terraform has built-in retries with exponential backoff
# It will retry up to 3 times by default
The Geography of Outages: E-Waste is Real
Here’s a pattern I’ve noticed: outages cluster in US-EAST-1. Why?
Because that’s where AWS launched. It’s their oldest region. It has the most services, the most customers, the most legacy infrastructure. And it’s the default region for many AWS services (Route53, IAM, CloudFront control planes).
If you’re asking “what is being affected by the aws outage?”, the answer often starts with “anything in US-EAST-1.”
But here’s the contrarian take: you should run production workloads outside US-EAST-1.
I know. It’s convenient. Every tutorial, every example, every default setting points to us-east-1. But that’s precisely why it’s the most dangerous region.
At SIVARO, we default to EU-WEST-1 (Ireland) or US-WEST-2 (Oregon) for new projects. We only use US-EAST-1 for services that truly require it (CloudFront distributions, Route53 hosted zones). The performance difference is negligible. The resilience difference is measurable.
What You Can Actually Do (Right Now)
You can’t prevent an AWS outage. But you can design so it doesn’t flatten you.
Here’s my practical checklist — things I implement for every client:
1. Identify your transitive dependencies
Map every AWS service you use. Then map everything that service depends on. KMS is the classic. But also: CloudWatch Logs, EC2 networking (VPC endpoints), and Route53 health checks.
2. Implement per-service circuit breakers
Don’t let one failing service cascade to others. Use a library like Hystrix (Java), Opossum (Node.js), or a sidecar like Envoy to handle circuit breaking at the proxy layer.
3. Build a fallback data path
For every critical write path, have a fallback that locally buffers data. SQS works. So does a Redis queue (if you manage it separately). The goal: accept the data, store it temporarily, and replay it when the outage clears.
4. Test with real failure
Every quarter, we do a “Chaos Day” where we simulate an AWS outage. We block all traffic to US-EAST-1 from our production accounts. We watch what breaks. Then we fix it.
5. Budget for failure, not for uptime
Most teams budget for 99.9% uptime. I tell them to budget for 3 hours of partial outage per month. The extra cost is insurance. And it’s cheaper than the downtime.
FAQ: What Is Being Affected by the AWS Outage?
Q: Does an AWS outage affect all AWS customers equally?
No. Customers using US-EAST-1 get hit hardest. Customers in other regions may see degraded performance if they use cross-region services (like DynamoDB Global Tables). Customers on dedicated hosts or isolated VPCs are less affected.
Q: Can multi-region deployment completely avoid AWS outage impact?
No. Services like KMS, IAM, and CloudFront control planes have centralized components. Even with multi-region, you may experience degraded performance for auth and encryption services.
Q: How long do typical AWS outages last?
The median is 2-4 hours. Major ones (like the 2023 KMS outage) can last 6-8 hours. AWS’s SLA covers only a subset of services — and downtime for dependent services (like Lambda functions that require KMS) isn’t covered.
Q: What’s the difference between an AWS service outage and a “failure to launch”?
A service outage means the service is broken. A “failure to launch” means you’re hitting service limits or throttling. During outages, both can happen — the control plane fails, and then customers hit rate limits when the control plane comes back.
Q: Should I switch to a different cloud provider because of AWS outages?
Only if you’re willing to pay 2-4x more for operational complexity. Multi-cloud is expensive. Instead, focus on architecture that degrades gracefully — then decide if the occasional outage is worth the cost savings of staying single-cloud.
Q: How does an AWS outage affect serverless applications?
Badly. Serverless functions (Lambda, Fargate) depend on the control plane for scaling. During an outage, you can’t scale up. Existing instances keep running, but new traffic gets dropped. Cold starts become impossible.
Q: What should I tell my CEO during an AWS outage?
“We’re affected because of a transitive dependency on AWS KMS. We’re implementing a fallback strategy right now. We expect to restore service within [your worst-case SLA]. This is not our fault, but we will fix it.”
The Last Word
Every AWS outage is a stress test — not just of your infrastructure, but of your thinking.
When you ask “what is being affected by the aws outage?”, the honest answer is: your assumptions. You assumed KMS would always be available. You assumed multi-region meant immune. You assumed the AWS status page would tell you everything.
It won’t. And it can’t.
The cloud is someone else’s computer. And someone else’s computer can break. Your job isn’t to prevent that breakage — it’s to survive it.
I’ve seen teams emerge from outages stronger. They had playbooks. They had fallbacks. They had tested their assumptions. And they’d already asked themselves the hard question: “What happens when we can’t do anything?”
If you haven’t answered that question yet, start now. Because the next outage is coming. It always is.
Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.