How to effectively use AWS Support for public sector organizations

For public sector organizations running workloads on Amazon Web Services (AWS), AWS Support helps troubleshoot issues and provides expert technical guidance. Getting the most out of AWS Support goes beyond merely opening a ticket. Knowing how to choose the right severity level, communicate through the right channel, and provide the right information can significantly reduce your time to resolution. In this post, we explore ways to best use your AWS Support.

Choosing the right severity level

AWS Support can be contacted through three channels: web (email), live chat, and phone. Each method will open a support case. AWS addresses support cases based on severity of the reported issue and the human response times for your support tier.

The severity level you choose signals the time and mission or business sensitivity of your issue. Understanding these levels is important because customers frequently underestimate the severity of their cases, which can delay response.

The severity levels are:

• General guidance [low] – You have a general question about an AWS service or feature.
• System impaired [normal] – Noncritical functions of your application are behaving abnormally, or you have a time-sensitive development question.
• Production system impaired [high] – Important functions of your application are impaired or degraded.
• Production system down [urgent] – Your business is significantly impacted. Critical functions of your application are unavailable.
• Business-critical system down [critical] – Your business is at risk. Critical functions of your application are unavailable.

Choosing the correct severity helps your case be prioritized appropriately. If your situation worsens after opening a case, you can and should increase the severity.

Selecting your communication channel

Engaging support through live chat or phone will connect you to the next available support engineer. For both high-severity and low-severity but blocking issues, we recommend contacting support over live chat or phone. This can significantly reduce initial response time and lead to a faster time to resolution. The AWS Support team has engineers who are assigned directly to monitor the queues for live chat and phone. During a mission-impacting event, this can further accelerate the time to response in addition to case severity. For issues that aren’t high severity, live chat or phone support can reduce time to response from hours to minutes even if the event doesn’t impact production or the organization as a whole.

Escalating to service teams

Support engagements can sometimes involve complex solutions. Issues that can’t be solved through direct support engineer troubleshooting or are of the highest urgency can escalate to a service’s engineering team. Service team engagement is driven and prioritized by issue criticality. Your support engineer manages escalation to service teams acting as an intermediary and advocate.

Providing business impact information

When creating a support case for a critical issue, it’s important to provide the right data on business impact so your support agent can accurately advocate for you. Providing this information proactively can also save vital time for the support agent in determining impact when it becomes clear an issue needs to be addressed by the service team.

For a support case that might require escalation or is of the highest priority, be sure to include the end user impact, scale, mission and monetary impact, and internal visibility level. For example, a law enforcement agency supporting a large metro area might include the following data:

400 officers across 12 precincts unable to access real-time crime center feeds impairing all active patrol and dispatch operations. The issue constitutes a direct public safety risk across the state capital region supporting 2.3 million constituents. The agency’s CIO and superintendent have been briefed and are monitoring for resolution. 

At the time of an incident, impact might not be fully measured, but including as much information as available will allow our teams to best prioritize the request.

Sharing the right troubleshooting data

In addition to providing data on impact, providing the right data for troubleshooting is also important. Make sure to provide the Amazon Resource Name (ARN) of any impacted resource, and providing relevant service logs is also crucial. Copying and pasting the logs is more useful than providing screenshots because the engineer can interact with the text directly. Finally, including the time(s) of when incidents occurred and the observed behavior at those times will assist with troubleshooting.

Keeping your case active

After a support case is opened, keeping it active is important. Cases that go without updates can stall, and support engineers might deprioritize them if there is no indication the issue persists. If you haven’t received a response within a reasonable window, update the case with any new information or increase the severity if the situation has worsened. Additionally, if an issue resurfaces after a case has been marked resolved, you can reopen the case rather than starting from scratch. This preserves the troubleshooting history and context from the original engagement.

Using self-service resources first

Before opening a support case for nonurgent issues, it’s worth checking AWS self-service resources. The AWS Health Dashboard can tell you whether your issue is part of a known service event, saving you time and giving you useful context to include if you do open a case. Similarly, AWS Trusted Advisor can surface configuration issues or service limit concerns that might be the root cause. For general questions or common errors, AWS re:Post, AWS documentation, and AWS generative AI–powered tools such as Amazon Q can often provide faster answers than waiting for a support case response. Checking these resources first can either resolve your issue outright or give you better information to include when you do engage support.

Using support proactively

AWS Support is not only for break-fix issues. Support provides a way for you to directly engage domain and service experts. AWS customers who effectively use AWS Support create support cases often and even for small issues. When building or working with AWS services, if a problem has been blocking progress for even an hour, use support as an additional troubleshooting resource. In addition to service-specific expertise, support agents can search internally for similar issues that have been observed and solved. This high frequency utilization of AWS Support is an excellent strategy to combine with the selection of chat or phone communication channels for low-severity issues that benefit from quick engagement.

Conclusion

In this post, we discussed ways to effectively use AWS Support that might not be commonly known. Choosing the right communication channel and severity level can speed time to resolution. Checking self-service resources such as AWS Health Dashboard, Trusted Advisor, and Amazon Q before opening a case can save time or provide better context. Providing clear business impact along with comprehensive ARNs and logs can reduce back-and-forth exchanges. Keeping cases active and reopening them when issues resurface keeps continuity. Using support beyond break-glass issues can accelerate development and give insight into how to best use AWS services.

To explore your support options and find the right plan for your organization, visit the AWS Support plans page. To get started with the self-service tools mentioned in this post, refer to the AWS Health Dashboard documentation, the AWS Trusted Advisor documentation, and Getting started with Amazon Q.