AWS Cloud Practitioner Study Notes · Part 39
AWS Support Plan Severity Levels and Response Times
AWS Cloud Practitioner study notes explaining support severity levels, first-response targets, incident actions, and current AWS Support plan changes.
AWS Support severity levels help AWS understand the urgency and business impact of a technical problem. They also determine the target time for AWS Support’s initial response. Choosing the correct severity is part of effective incident communication: a production outage should be escalated quickly, while a normal architecture question should not be labelled as an emergency simply to obtain a faster answer.
This is Part 39 of the AWS Cloud Practitioner Study Notes. Part 38 compared the support plans. This article focuses on what to do for each severity level and how to interpret AWS response targets.
The current Support plan context
AWS’s current commercial support page presents Basic Support, Business Support+, Enterprise Support, and Unified Operations. Developer Support, the legacy Business Support plan, and Enterprise On-Ramp remain relevant to older Cloud Practitioner study materials, but AWS has announced that they will be discontinued on January 1, 2027 outside AWS GovCloud (US).
For current planning, Business Support+ is the minimum recommended plan for production workloads. Enterprise Support adds a designated Technical Account Manager (TAM) and a 15-minute production-critical response target. Unified Operations is the top operations-focused tier and supports a specialised five-minute response through AWS Incident Detection and Response (IDR).
Response targets are not resolution times
The most important distinction is:
Response target
→ How quickly AWS initially engages the support case
Resolution time
→ How long diagnosis, mitigation, and recovery takeFor example, if Enterprise Support has a 15-minute target and an AWS engineer responds after 10 minutes, AWS met the initial-response target even if investigation and recovery take another two hours. AWS makes reasonable efforts to respond within the listed timeframe; the target does not guarantee that every problem will be fixed within that time.
Severity-level response targets
| Severity | Meaning | Business Support+ | Enterprise Support |
|---|---|---|---|
| General guidance | A normal development, architecture, or service question | Under 24 hours | Under 24 hours |
| System impaired | A non-production or non-critical system has reduced functionality | Under 12 hours | Under 12 hours |
| Production system impaired | Production is degraded but is still operating | Under 4 hours | Under 4 hours |
| Production system down | A production workload is unavailable or severely broken | Under 1 hour | Under 1 hour |
| Business-critical system down | A critical business operation is severely affected | Under 30 minutes | Under 15 minutes |
These targets describe the first response from AWS Support. The plan, selected severity, case details, contact method, and the nature of any third-party issue can affect the overall support experience.
General guidance: under 24 hours
Use General guidance when there is no active outage and you need advice or explanation.
Examples include:
- How should an Auto Scaling policy be configured?
- Which S3 storage class fits an access pattern?
- Does an IAM design follow least-privilege principles?
- How should an existing database be migrated to AWS?
Recommended action:
Create a web support case
↓
Describe the question and relevant architecture
↓
Continue normal development
↓
Review AWS guidance when Support respondsDo not select a production-down severity simply because the answer is important to your team.
System impaired: under 12 hours
Use System impaired when a development, test, or other non-production workload is not working correctly.
Examples include:
- Development EC2 instances cannot connect to a test database.
- A test deployment repeatedly fails.
- A non-production API is unavailable.
- A workload has reduced performance, but no production users are affected.
Before opening the case, collect error messages, identify the affected Region and resources, record timestamps, and attach relevant logs. This gives AWS a useful starting point and helps separate an AWS service problem from an application or configuration problem.
Production system impaired: under 4 hours
Use Production system impaired when a production workload still operates but has significant degradation or loss of functionality.
Examples include:
- A meaningful percentage of API requests returns errors.
- Application latency has increased significantly.
- One Availability Zone is unhealthy while another continues serving users.
- A production feature is unavailable, but the main application remains online.
Start your internal incident process at the same time as opening the AWS case. Include the customer impact, affected Regions, resource identifiers, start time, error rate, recent changes, and any workaround. Phone or chat can provide faster engagement for urgent cases than relying only on a web submission.
Production system down: under 1 hour
Use Production system down when a production workload is unavailable or severely broken.
Examples include:
- The production website is inaccessible.
- Customers cannot log in or complete payments.
- A production database is unavailable.
- A core production API is failing for most users.
Recommended action:
Declare the internal incident
↓
Open a Production system down case
↓
Choose phone or live chat
↓
Provide logs, timestamps, resource IDs, and business impact
↓
Keep technical responders availableThe AWS case should complement your own incident response. AWS can help investigate AWS services and provide guidance, but your organisation remains responsible for its application code, data, configuration, deployments, and recovery decisions under the shared responsibility model.
Business-critical system down: under 30 or 15 minutes
Use the highest ordinary severity only when a critical business operation is severely affected. Examples could include a financial transaction platform being unavailable, a major sales event failing completely, or a global production platform having no usable workaround.
For Business Support+, the target is under 30 minutes. For Enterprise Support, the production-critical target is under 15 minutes.
Immediately:
- Open the highest-severity case that accurately describes the impact.
- Use phone or chat rather than relying only on a web form.
- State the exact business and customer impact.
- Provide the account ID, Region, resource IDs or ARNs, and incident start time.
- Include error messages, recent changes, logs, and troubleshooting already performed.
- Provide an incident-bridge or conference-bridge contact when appropriate.
- Keep internal responders available and update the case as the impact changes.
Do not use this severity for a difficult but non-critical technical question. Incorrect severity makes operational communication less reliable and can slow appropriate escalation.
Unified Operations and the five-minute distinction
The five-minute number belongs to a specialised incident-management capability, not to every Unified Operations support question. AWS Unified Operations provides a five-minute incident response for critical cases raised with Incident Detection and Response. AWS Incident Detection and Response can also proactively engage for eligible onboarded workloads after an alarm.
When requesting this response, AWS documentation says to select a Technical case, choose the affected service, select the appropriate category, use Business-critical system down, and include the workload name, affected resource ARNs, business impact, and optional bridge details.
Ordinary Enterprise Support case
→ Production-critical response target: under 15 minutes
Unified Operations + Incident Detection and Response
→ Specialised critical-incident engagement: 5 minutesThe five-minute engagement is still not a promise that the incident will be resolved in five minutes. Resolution depends on the quality of available context, workload onboarding, the issue, and the recovery actions required.
What information should be in an urgent case?
Prepare a concise incident summary containing:
- AWS account ID
- Affected Region or Regions
- Workload name and resource IDs or ARNs
- Incident start time and timezone
- Percentage of customers or requests affected
- Error messages, metrics, and relevant logs
- Recent deployments or configuration changes
- Troubleshooting already completed
- Available workaround or rollback plan
- Technical and incident-bridge contact details
A useful case description answers four questions quickly: what failed, who is affected, when it started, and what has already been tried.
Legacy plan memory map
Older exam resources may still use this mapping:
Billing or account question
→ Basic Support
Development and testing question
→ Developer Support
Production plus 24/7 engineers
→ Business Support
Growing enterprise workload without a designated TAM
→ Enterprise On-Ramp
Critical workload plus a designated TAM
→ Enterprise SupportFor current AWS terminology, map Business Support to Business Support+ where the question refers to the current production plan, and remember that Enterprise On-Ramp is being transitioned to Enterprise Support.
Response-time memory trick
For the classic severity sequence, remember:
24 hours → 12 hours → 4 hours → 1 hour → 30 minutes → 15 minutesThe sequence moves from general guidance to system impaired, production impaired, production down, Business Support+ business-critical, and Enterprise Support production-critical. The specialised IDR number is then:
5 minutes → Unified Operations or eligible Enterprise Support IDR engagementFinal takeaway
Choose a severity based on actual business and technical impact. General questions belong in General guidance, non-production problems in System impaired, degraded production in Production system impaired, and unavailable production in Production system down. Reserve the highest severity for genuinely business-critical outages. Most importantly, AWS response targets measure initial engagement—not guaranteed resolution time.