AWS Support plans

AWS Support plans apply the broader cloud concept of tiered operational support: customers select assistance appropriate to their workloads, business impact, and internal engineering capabilities. Support coverage is separate from the resources running an application. Purchasing a higher support tier does not automatically improve an instance's availability, increase database capacity, or change a service's architectural behavior.

Basic Support is included for AWS customers and provides resources such as customer service, documentation, and support forums, but it does not include technical support cases with cloud support engineers. Paid plans add technical assistance, with differences in contact channels, availability, severity options, response targets, and advisory services. Business-oriented and enterprise-oriented coverage address different operational needs. Compare the actual entitlements rather than assuming that every paid plan provides the same access or guidance.

During an incident, engineers open a support case, identify the affected service and resources, describe the business impact, and select an appropriate severity. A useful case includes the AWS Region, resource identifiers, timestamps with time zones, request IDs, recent changes, and relevant diagnostic output. For example, a team investigating production API failures should explain whether all customers are blocked or only one operation is degraded. Severity should reflect actual impact rather than the team's desire for a faster response.

A target initial response time is not a guaranteed resolution time. The first response starts the support interaction; diagnosis and recovery may require additional evidence, customer actions, or coordination with service teams. Response targets also differ by severity and plan. Teams should therefore maintain their own incident commander, rollback procedures, escalation contacts, and recovery options instead of waiting for support to restore the application.

Support selection is a trade-off between cost and operational exposure. A development environment with flexible recovery expectations may need less coverage than a revenue-generating platform operating continuously. Paid support pricing can include minimum charges and usage-based calculations, so engineers should involve procurement or financial operations when assessing coverage across multiple accounts. Consolidated billing alone should not be treated as proof that every account has identical support entitlements.

Higher support tiers can include more proactive engagement and designated technical account management. A technical account manager helps coordinate operational planning and risk reduction; this role is not a replacement for the customer's administrators or an engineer who operates every workload on the customer's behalf. Likewise, support does not transfer the customer's shared-responsibility obligations to AWS.

Operational tools complement the support relationship. AWS Health can help identify provider-side events, while AWS Trusted Advisor can highlight selected configuration risks. Neither replaces application telemetry or a support case when investigation is required. Before an incident, verify account coverage, authorize the responders who need support access, and rehearse escalation procedures. Never include passwords, access keys, or other secrets in case attachments.