Getting Support on AWS

Lesson purpose

Good support is a routing decision: choose the right knowledge source, the right support capability, and the right proactive check for the business impact. This lesson reconciles uCertify Lesson 3, sections 3.1–3.5, with the current AWS lineup represented in the Lesson 3 Modern deck. Exact prices and response targets change, so students should use the current AWS plan comparison for time-sensitive details.

Learning objectives

• Match learning, troubleshooting, optimization, and transformation needs to AWS resources.
• Distinguish Basic, Business Support+, Enterprise Support, and Unified Operations.
• Describe severity by business impact rather than by a requester’s title.
• Find, validate, and cite authoritative AWS documentation and guidance.
• Prepare a strong support case and report suspected abuse without exposing secrets.
• Explain the five Trusted Advisor categories and the effect of plan level on checks and automation.

1. Begin with the kind of help required

Use Learn for documentation, training, whitepapers, and architecture guidance. Use Troubleshoot for re:Post, Knowledge Center articles, logs, metrics, and support cases. Use Optimize for Trusted Advisor, Well-Architected reviews, and expert guidance. Use Transform when Professional Services or an AWS Partner adds delivery capacity for a migration or redesign. Starting with the type of help prevents a support case from becoming a substitute for basic research.

2. Current support plans and operational risk

The current lineup is Basic Support, Business Support+, Enterprise Support, and Unified Operations. Older material may mention Developer Support, Business Support, or Enterprise On-Ramp; those legacy names are scheduled to retire January 1, 2027. Teach the current names first and treat exact response times, pricing, and feature matrices as values to verify on the AWS plan page.

Plan	Best fit	Distinguishing capability
Basic	Learning and noncritical use	Account/billing help, self-service, health information, and limited checks
Business Support+	Production workloads	24/7 technical case access and full Trusted Advisor checks
Enterprise Support	Business-critical portfolios	Proactive guidance, escalation relationships, and designated expertise
Unified Operations	Complex operations	Broad operational partnership across a complicated environment

The decision rule is operational risk, not prestige. Ask what happens if the workload is impaired at 2 a.m., how quickly a human must respond, and whether the team needs proactive planning rather than only case handling.

3. Severity and response targets

Severity is a description of business impact. General guidance is a how-to or design question without production impairment. System impaired means important functions are degraded or unavailable. Production down means a production workload is unavailable or severely affected. Business-critical means immediate, severe impact to core operations. A requester’s job title does not determine severity; the evidence and impact do.

Response targets are capabilities of a selected plan, not a promise that AWS will repair the application. The architecture, runbooks, monitoring, backups, failover, and customer containment steps remain necessary while a case is open. Ask students to state the workload, current symptom, start time, user impact, and mitigation before choosing a severity.

4. Basic, Business+, and Enterprise capabilities

Basic Support anchors self-service: account and billing questions, documentation, health information, and the limited Trusted Advisor checks available at that level. Business Support+ adds 24/7 technical access, severity-based targets, production guidance, and full Trusted Advisor checks and programmatic features. Enterprise Support adds designated guidance, escalation relationships, proactive launch and migration programs, and a portfolio view of business-critical outcomes. Unified Operations extends the partnership for complex operational environments.

Professional Services helps plan and execute complex transformations. The AWS Partner Network adds consulting and technology partners with specialized capability. These are different from a support case: they add delivery or design capacity rather than simply answering a question.

5. Documentation and guidance channels

Start with the most authoritative source that answers the question:

• A service guide explains behavior, concepts, setup, APIs, quotas, and troubleshooting.
• An API or CLI reference gives exact parameters, syntax, and response definitions.
• The Architecture Center provides reference designs and decision guidance.
• Release information confirms whether a feature, Region, or behavior recently changed.
• Prescriptive Guidance supplies patterns and migration playbooks; check publication date and scope.
• The Knowledge Center handles recurring support questions; verify the applicable service and Region.
• AWS re:Post offers community and expert answers; look for accepted answers and freshness.
• AWS Blogs provide announcements and examples, but a blog is not automatically normative guidance.

For security questions, use service security documentation, the AWS Security Blog, AWS Artifact for compliance reports and agreements, and the AWS Trust Center for programs and standards.

6. Support cases and abuse reporting

A strong case accelerates diagnosis. Provide the account or organization, Region, service, resource IDs, exact symptom, start time, business impact, recent changes, evidence, and safe reproduction steps. Redact secrets and unrelated personal data. In the guided practice, define one precise question, search official documentation first, verify Region and prerequisites, and cite the direct URL in your own words.

Suspected abuse requires evidence and care. Identify IP addresses, domains, timestamps, time zone, and observed behavior. Preserve relevant logs while protecting secrets and unrelated personal data. Report through the AWS abuse channel when AWS resources are involved. Protect the local environment with containment and incident response; a report does not replace either one. Do not run penetration tests against AWS resources without the required authorization.

7. Trusted Advisor as proactive feedback

Trusted Advisor organizes recommendations into five categories: cost optimization, performance, security, fault tolerance, and service limits. Basic Support includes Service Limits and a selected subset of Security and Fault Tolerance checks. Paid plans expand check coverage and add API or programmatic access. A recommendation is evidence for a decision, not an instruction to click “fix.” Validate the workload’s purpose, exception, data sensitivity, and operational context before changing it.

Use the same loop as the lesson decks: review a check, confirm its scope and last update, decide whether the recommendation applies, document the exception or action, and recheck after the change. Pair Trusted Advisor with Well-Architected reviews and current service documentation.

Classroom application

Give students a scenario with a production outage, a Region-specific feature question, and a compliance request. Have them route each to a plan, a source, or a human resource, then write a three-sentence support case. The answer should name impact, scope, evidence, and the next safe action.

Common misconceptions

• The most expensive plan is always correct. Support should match operational risk and needed expertise.
• A community answer is authoritative because it is recent. Verify against service documentation and release information.
• Severity means “how important my job is.” Severity is based on workload impact.
• Trusted Advisor automatically fixes findings. Recommendations require judgment and change control.
• Reporting abuse is the same as incident response. Keep containment and evidence handling active locally.

Lesson summary

AWS support is a system of sources, plans, people, and checks. Start with the kind of help needed, match the plan to business impact, describe severity with evidence, validate the authoritative source, and use Trusted Advisor proactively. The next lesson applies that judgment to physical placement: Regions, Availability Zones, edge locations, and the shared-responsibility boundary.