# AWS Support plan

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/aws-support-plan

## Quick definition

AWS Support plans are like service packages you can buy from Amazon Web Services to get help when something goes wrong with your cloud resources. The basic free plan only gives you access to documentation and community forums. Paid plans unlock faster response times, direct access to AWS engineers, and proactive guidance. The more you pay, the more support you get, from basic troubleshooting to architectural guidance and infrastructure management.

## Simple meaning

Imagine you live in a large apartment complex. The building management offers different levels of help for residents. The Basic plan is like the free online portal where you can read the resident handbook and chat with neighbors in the lobby forum. The Developer plan is like having a phone number for the maintenance hotline you can call during business hours if your sink leaks. The Business plan gives you a direct line to a manager who answers within an hour, even on weekends. The Enterprise plan is like having a dedicated building supervisor who lives in your apartment, knows your family, checks your pipes proactively, and can call in a plumber instantly if needed.

In technical terms, AWS Support plans are not a product you deploy or configure in your cloud account. They are a subscription you purchase at the account or organization level. The free Basic plan includes no technical support beyond documentation, whitepapers, and community forums. Paid plans add service quotas, technical account managers, and faster response times based on severity levels of incidents.

A key distinction is that the support plan does not fix your code or manage your infrastructure. It gives you a channel to ask AWS engineers questions about AWS services, get help troubleshooting configuration issues, and receive guidance on best practices. The level of access and speed of response increases as you move up the tiers.

For example, if your application goes down at 2 AM on a Saturday, with the Basic plan you can post on a forum and hope someone answers. With the Business plan, you can open a support case marked critical, and AWS will respond within one hour. With Enterprise, you get a Technical Account Manager who already knows your architecture and can start working on a fix immediately.

This tiered approach works well because different organizations have different needs. A startup building a side project may be fine with the free plan. A bank processing millions of transactions needs immediate support when something breaks. AWS Support plans ensure that every customer gets the level of help they need, while aligning pricing to the value of support provided.

## Technical definition

AWS Support plans are a structured, tiered framework of technical assistance and operational guidance offered by Amazon Web Services to help customers optimize their cloud usage, troubleshoot issues, and maintain high availability. The plans are not infrastructure components but rather service subscriptions attached to an AWS account or an AWS Organizations management account. Each tier defines specific response times for support cases, access to engineering resources, and included services such as infrastructure event management or architectural review.

There are currently five support plan tiers: Basic (free), Developer ($29 per month or 3% of monthly usage), Business ($100 per month or 10% of monthly usage), Enterprise On-Ramp, and Enterprise Support. The Basic plan includes only access to documentation, whitepapers, and AWS re:Post community forums. It also includes limited support for billing and account issues. There is no direct technical support available.

The Developer plan builds upon Basic by adding one primary contact who can open technical support cases. This plan offers general guidance with a response time of less than 24 hours for system impaired cases, and less than 12 hours for guidance. It does not include production-level support for critical workloads.

The Business plan is the first tier that provides production-level support. It allows unlimited contacts and offers full access to AWS Trusted Advisor checks for cost optimization, performance, security, and fault tolerance. Response times are tiered by severity: general guidance in 24 hours, system impaired in 12 hours, production system down in 1 hour, and production system down for business-critical workloads in 30 minutes. This plan also grants access to Infrastructure Event Management, a structured engagement to help plan for events like product launches or migrations. For organizations using AWS Support API, the Business plan enables programmatic case management.

The Enterprise On-Ramp plan is designed for organizations migrating to or building in AWS with a focus on operational maturity. It includes a pool of Technical Account Managers (TAMs) for proactive guidance, infrastructure event management, and faster response times for critical cases (30 minutes). It also includes access to a support concierge and architectural reviews.

The Enterprise plan is the highest tier, intended for large-scale, business-critical workloads. It provides a designated Technical Account Manager (TAM), a support concierge, full Infrastructure Event Management, and proactive guidance through operational reviews and workshops. Response times are the fastest: general guidance in 24 hours, system impaired in 12 hours, production system impacted in 1 hour, and business-critical system down in 15 minutes. The Enterprise plan also includes access to AWS Incident Detection and Response, a service that monitors and responds to high-severity events in real time.

All paid plans include access to AWS Support API for case management, AWS Trusted Advisor (full checks for Business and above), and AWS Personal Health Dashboard. The plans are billed monthly based on either a fixed fee (Developer) or a percentage of the total monthly AWS charges (Business and Enterprise). There is no long-term contract; customers can upgrade or downgrade at any time.

From a security and billing perspective, the support plan itself is not a security control but it enables better security posture by providing access to security-specific Trusted Advisor checks and engineering assistance for compliance issues. In billing, the support plan cost appears as a line item on the monthly AWS bill and is subject to AWS pricing adjustments. Organizations using consolidated billing can apply one support plan to the management account, which then covers all member accounts for case management but not for TAM coverage.

AWS Support plans are a critical component of a well-architected framework for operational excellence. They ensure that customers have the right level of AWS expertise available when needed, tailored to the criticality and scale of their cloud environments. The plans are technical service agreements, not software, and their value lies in the human expertise and prioritization they provide.

## Real-life example

Think of AWS Support plans like roadside assistance packages for your car. Everyone who buys a new car gets some basic level of support: a manual in the glove box, a customer service number for complaints, and maybe access to an online owner community. That’s the Basic Support plan. If you have a flat tire at night, you can look through the manual or post on a forum asking what to do, but no one is coming to help you.

Now imagine you buy a middle-tier roadside assistance package. You get a hotline you can call during office hours. If your car’s check engine light comes on at 3 PM on a Tuesday, you call, and a mechanic talks you through some steps. If it’s serious, they can send someone within 24 hours. That is the Developer plan, it helps, but only during reasonable hours and with slower response.

Now upgrade to the Business roadside package. You get a 24/7 hotline. You break down on a highway at 2 AM in a rainstorm. You call, and within one hour a tow truck arrives. They can also help you plan for long road trips, giving you a checklist before you go. That is the Business plan, fast response, proactive help, and unlimited callers (any driver of the car can call).

The Enterprise plan is like having a personal mechanic assigned to your car. Not only do they respond in 15 minutes when you break down, but they also call you every month to ask about your oil changes, tire rotations, and upcoming trips. They review your car’s health data proactively and recommend fixes before you break down. If you’re planning a month-long cross-country trip, they sit with you and plan the entire journey, making sure you have spare parts and fuel stops. That is the Enterprise support experience, you get a dedicated Technical Account Manager who knows your car better than you do.

In the cloud world, your “car” is your AWS infrastructure. The “breakdown” is when your website goes offline, an EC2 instance fails, or a database corrupts. The “mechanic” is an AWS Support engineer. The “roadside assistance package” is your support plan. Just like you would not want a basic package if you drive a fleet of delivery trucks, you would not want Basic Support if your business runs on AWS.

This analogy also maps to cost. A roadside assistance plan costs money every year, and you hope you never need it. When you do need it, the cost is trivial compared to the benefit of getting help fast. Similarly, AWS Support plan costs are a fraction of what you would lose during an hour of downtime. The Enterprise plan is expensive, but organizations with billion-dollar workloads on AWS often consider it essential insurance.

## Why it matters

AWS Support plans matter because cloud environments are complex and failures happen regardless of how well you architect your systems. Even the most experienced DevOps team can encounter issues that require AWS internal knowledge to resolve, for example, a mysterious network latency spike, a service limit that needs a raise, or an undocumented behavior change. Without a paid support plan, you are limited to community forums and documentation, which may not provide timely or accurate help for time-sensitive incidents.

For IT professionals, the support plan directly affects incident response capabilities. In a production outage, the difference between a 15-minute response time (Enterprise) and a 24-hour response time (Developer) can cost organizations thousands or even millions of dollars in lost revenue, data exposure, and customer trust. Many organizations mandate a Business or Enterprise plan for production workloads as part of their risk management and compliance policies.

AWS Support plans provide access to AWS Trusted Advisor, a tool that offers real-time recommendations for cost savings, security improvements, performance optimization, and fault tolerance. Business and Enterprise plans unlock the full set of Trusted Advisor checks, which can prevent costly misconfigurations like public S3 buckets, overly permissive security groups, or underutilized resources. Without these checks, you are operating blind to many common AWS pitfalls.

Another reason it matters is the human element. When you have a Technical Account Manager (TAM) assigned, you have a single point of contact who understands your architecture, business context, and workload patterns. This accelerates troubleshooting and enables proactive recommendations. For organizations undergoing cloud migrations, compliance audits, or major events like Black Friday sales, a TAM can be the difference between success and failure.

Finally, billing is a practical concern. The cost of an AWS Support plan scales with usage, so you need to budget for it. An organization spending $100,000 per month on AWS might pay $10,000 or more monthly for Enterprise Support. That can impact profitability. IT leaders must evaluate whether the cost is justified by the value of faster support and proactive guidance. For many, losing a few thousand dollars a year to support is better than losing millions to an hour-long outage with no help.

## Why it matters in exams

Understanding AWS Support plans is critical for several cloud certification exams, including the AWS Cloud Practitioner, AWS Developer Associate, AWS Solutions Architect Associate, AWS Solutions Architect Professional, and the AWS SysOps Administrator Associate. The topic also appears in some Microsoft Azure exams like AZ-900 (Azure Fundamentals) when comparing support options between cloud providers, though it is less central. For Google Cloud exams like Google Cloud Digital Leader, the concept of support tiers is analogous but not identical, and AWS-specific questions will use the AWS model.

In the AWS Cloud Practitioner exam (CLF-C02), questions about support plans are very common. The exam covers the four main tiers (Basic, Developer, Business, Enterprise), their response times, and key features like Trusted Advisor, Technical Account Manager, and Infrastructure Event Management. Questions may ask you to recommend a plan based on a scenario, such as a startup wanting 24/7 email support, or a large enterprise needing a dedicated TAM. You need to know that Business offers 1-hour response for production down, and Enterprise offers 15-minute response for business-critical down. Also know that Basic is free but has no technical support, while Developer is the cheapest paid tier with limited hours.

For the AWS Solutions Architect Associate exam (SAA-C03), support plan questions are less frequent but still appear. You may be asked about which plan provides access to Infrastructure Event Management, which plan includes a Technical Account Manager, or which Trusted Advisor checks are available at each tier. The exam may also test your understanding of consolidated billing and how support plans apply across an organization. For example, if a management account has Business Support, member accounts can open cases, but they do not get a TAM unless they also have Enterprise.

For the Developer Associate exam (DVA-C02), you might see questions about using the AWS Support API to automate case management, and which plans allow that (all paid plans). The exam also tests integration with AWS Health Dashboard and how support plans affect incident notification.

For the SysOps Administrator exam (SOA-C02), support plan knowledge is more operational. You might need to troubleshoot why you cannot open a support case (lack of paid plan), or how to escalate a critical issue. You may also be tested on the SLA (Service Level Agreement) for support response times, which only applies to paid plans.

For the AWS Solutions Architect Professional exam (SAP-C02), you might see support plans in questions about multi-account strategies, where you need to decide how to apply support across a landing zone. Enterprise plan is often recommended for large organizations with complex governance requirements.

Question types vary. You might get multiple-choice questions asking which plan offers the fastest response for a critical outage, which plan provides a TAM, or which plan is appropriate for a given scenario. You may also see more complex questions where you have to choose the most cost-effective plan that meets a set of support requirements. Since the AWS Cloud Practitioner exam is often the first certification for IT professionals, mastering support plans builds a foundation for understanding how AWS interacts with customers beyond just the console and APIs.

## How it appears in exam questions

In AWS certification exams, questions about support plans typically fall into one of several patterns: scenario-based recommendation, feature mapping, response time recall, and cost optimization.

Scenario-based recommendation: These questions describe a company’s size, workload criticality, budget, and support needs. For example, “A company has a production application on AWS that processes financial transactions. They need 24/7 support with a response time of less than 1 hour for critical issues. Which support plan should they choose?” The answer is Business Support, because it offers 1-hour response for production system down and includes 24/7 access. Enterprise offers 15-minute response but may be overkill. The trick is to match the need exactly without over-spending.

Feature mapping: You might be asked, “Which AWS Support plan includes access to a Technical Account Manager?” The answer is Enterprise (and also Enterprise On-Ramp, if that tier is included). Another example: “Which support plan provides full AWS Trusted Advisor checks?” The answer is Business and above. Questions may also ask which plan offers Infrastructure Event Management, Business and above have this as a paid engagement for planned events.

Response time recall: You need to memorize the response times for each severity level. A typical question: “With the Developer Support plan, what is the maximum response time for a case marked ‘system impaired’?” The answer is 12 hours. For Business, ‘production system down’ is 1 hour. For Enterprise, ‘business-critical system down’ is 15 minutes. The exam expects you to distinguish between ‘general guidance,’ ‘system impaired,’ ‘production system down,’ and ‘business-critical system down.’

Cost optimization: Some questions ask you to compare the cost of support plans against the AWS bill. For example, “A company spends $50,000 per month on AWS. They are considering Developer, Business, and Enterprise plans. Calculate the approximate monthly cost for each.” You need to know the percentage tiers: Developer is $29 or 3% of monthly usage (whichever is higher), Business is $100 or 10% of monthly usage, Enterprise is $15,000 or 5% of monthly usage for the first $150,000 and then 3% for next tier. But the exam usually does not require precise calculations; it tests which plan offers the best value given the needs.

Trap questions: The exam may try to confuse you by mentioning “premium support” or “advanced support” which are not official AWS plan names. Also, look for answers that include “24/7 phone support” for Developer when Developer only offers email support during business hours. Another common trap is suggesting Basic Support includes technical support for production issues, which is false.

Cross-service integration: Questions may connect support plans with AWS Trusted Advisor or AWS Health. For instance, “Which support plan enables automated alerts from AWS Health for all events?” That actually works with Basic as well, but full customization comes with Business.

Finally, know that support plans are account-level. A question might ask: “A company has multiple AWS accounts under consolidated billing. They want a TAM to oversee all accounts. Which plan do they need on the management account?” Answer: Enterprise. But note that the TAM is assigned to the payer account, not to each linked account.

## Example scenario

Imagine a startup called GreenLeaf Analytics that builds environmental monitoring software. They have just started using AWS to host their website and database. They have a single AWS account, and the CTO is evaluating support plans. The company is small, with only three developers, and they expect to spend about $2,000 per month on AWS services. The website is not revenue-critical yet, but they want to ensure they can get help if the database crashes.

The CTO reads about the free Basic plan and thinks it might be enough. She plans to rely on documentation and the AWS community forum. One Friday afternoon, without warning, the database instance becomes unresponsive. The developers cannot connect, and the website returns 500 errors. The CTO posts a question on the AWS re:Post forum explaining the issue. She waits 30 minutes, then an hour, then two hours. No one has replied. It is a Friday before a long weekend. The team is stuck. They cannot pinpoint the cause. The database is down for the entire weekend. On Monday, someone finally posts a suggestion to check the security group inbound rules. It turns out a recent update accidentally removed the database port. The fix is a two-minute change, but the team wasted two days of downtime because they had no direct support.

After that incident, the CTO upgrades to the Business Support plan. A few months later, during a product launch, the application becomes slow. The developers open a support case with severity “Production system impaired.” Within 1 hour, an AWS Support engineer responds and reviews their application logs. The engineer identifies that a misconfigured load balancer is routing traffic to unhealthy instances. The engineer provides a step-by-step fix. The issue is resolved in under two hours. The team avoids a full outage because they had prompt support.

Later, as the company grows, they hire a dedicated AWS architect and spend $100,000 per month. They upgrade to Enterprise Support. Their Technical Account Manager (TAM) proactively reviews their architecture and suggests migrating to a multi-AZ RDS deployment for high availability. The TAM also helps them plan infrastructure changes before the next product launch. When a critical security vulnerability is announced, the TAM directly informs them and helps patch the system before any exploit occurs.

This scenario illustrates how the right support plan evolves with the organization’s needs. Starting with Basic is fine for experimentation, but once production value is at stake, paid support becomes essential. The cost of downtime far outweighs the monthly support fee.

## Common mistakes

- **Mistake:** Thinking the Basic plan includes technical support for troubleshooting issues.
  - Why it is wrong: The Basic plan only provides access to documentation, whitepapers, and community forums. There are no direct support channels for technical issues. Customers must rely on self-help or pay for a higher tier.
  - Fix: Remember that only paid plans (Developer, Business, Enterprise) include the ability to open technical support cases. Basic is for billing questions and self-study only.
- **Mistake:** Assuming Developer Support provides 24/7 phone support and 1-hour response for critical issues.
  - Why it is wrong: Developer Support offers email support only during business hours, with response times of 24 hours for general guidance and 12 hours for system impaired. There is no critical severity response under Developer.
  - Fix: Developer is for non-production environments. If you need 24/7 support or fast response, you need at least Business (1-hour for production down) or Enterprise (15-minute for business-critical).
- **Mistake:** Believing that all Trusted Advisor checks are available with the Basic or Developer plan.
  - Why it is wrong: The Basic plan only shows service limits. The Developer plan adds core checks. Full Trusted Advisor functionality, including cost optimization, security, fault tolerance, and performance checks, requires Business Support or higher.
  - Fix: If you need the full set of Trusted Advisor recommendations, you need at least Business Support. Many security misconfigurations can be prevented by these checks.
- **Mistake:** Thinking that a Technical Account Manager (TAM) is included with the Business Support plan.
  - Why it is wrong: The TAM is only included with Enterprise Support (and Enterprise On-Ramp). Business Support provides a pool of support engineers but no dedicated TAM.
  - Fix: If you need a dedicated TAM, you must purchase Enterprise Support. Business Support offers fast response but without a dedicated point of contact.
- **Mistake:** Assuming that support plans are applied per AWS account and cannot be shared across consolidated billing.
  - Why it is wrong: Support plans are account-level, but with consolidated billing, the management account’s support plan extends to member accounts for support case opening capabilities. However, the TAM and proactive support are not inherited by member accounts automatically.
  - Fix: If you want all accounts under an organization to have the same support level, you need to apply the plan to the management account and configure accordingly. Member accounts can open cases, but they do not get a TAM.
- **Mistake:** Confusing AWS Support plan response times with AWS Service Level Agreements (SLAs) for service availability.
  - Why it is wrong: AWS Support plan response times are guarantees for how quickly AWS engineers will respond to a support case. AWS SLAs (like EC2 99.99% availability) are guarantees of service uptime, not support responsiveness. They are separate concepts.
  - Fix: Remember: Support response times apply to how fast you get help. SLAs apply to how reliably a service runs. A service can meet its SLA but you still may need support to fix a configuration issue.
- **Mistake:** Believing you need Enterprise Support to get Infrastructure Event Management.
  - Why it is wrong: Infrastructure Event Management (IEM) is available with Business Support and above. Enterprise On-Ramp and Enterprise include it, but it is also purchasable as a separate engagement for Business customers.
  - Fix: IEM is a benefit for Business and higher. You can request it for planned events like migrations or launches. It does not require Enterprise, though Enterprise includes more IEM hours.

## Exam trap

{"trap":"In an exam question, you are told that a company needs 24/7 support with 1-hour response for production issues. The options include Developer Support and Business Support. Many learners choose Developer because it is cheaper, thinking it offers 24/7 support.","why_learners_choose_it":"Learners often see the word 'Developer' and assume it covers all support needs for someone building applications. They may not memorize the specific response times for Developer, or they confuse Developer support hours with Business. The lower price is also tempting.","how_to_avoid_it":"Memorize that Developer Support is only during business hours via email. It does not offer 24/7 support or 1-hour response. Business Support is the first tier that offers 24/7 phone, chat, and email with 1-hour response for production down. Always read the scenario carefully: if it mentions '24/7' or 'production,' the answer is likely Business or above."}

## Commonly confused with

- **AWS Support plan vs AWS Trusted Advisor:** AWS Support plans are subscription levels that include different features. AWS Trusted Advisor is a tool that provides recommendations for cost optimization, security, and performance. The full Trusted Advisor checks are only available with Business Support and above. The two are related but distinct: you need a support plan to access the tool at a certain level. (Example: You can have Basic Support but still see limited Trusted Advisor checks (only service limits). To see the full security checks, you need Business Support.)
- **AWS Support plan vs AWS Health Dashboard:** AWS Health Dashboard (also called Personal Health Dashboard) provides personalized alerts about service events that affect your resources. All support plans, including Basic, provide access to AWS Health Dashboard. However, paid plans offer additional features like proactive notifications and event management. The support plan itself is not the dashboard. (Example: With Basic Support, you can still see that a specific EC2 instance is impaired via Health Dashboard. But you cannot open a support case to investigate further without a paid plan.)
- **AWS Support plan vs AWS Managed Services:** AWS Managed Services (AMS) is a separate service that provides ongoing management of your AWS infrastructure, including patching, monitoring, and incident management. AWS Support plans are only for getting help from AWS engineers when you need it. AMS is a full managed service provider, far more comprehensive and expensive than support plans. (Example: If you have a production system that needs 24/7 monitoring and automated patching, you might use AMS. If you just want someone to answer questions quickly when something breaks, a Support plan is sufficient.)
- **AWS Support plan vs AWS Professional Services:** AWS Professional Services is a team of consultants that helps you design, migrate, and build solutions on AWS. They offer project-based engagements, not day-to-day support. AWS Support plans provide operational support and troubleshooting. Professional Services is for strategic projects like migrations or new architecture design. (Example: If you need help designing a microservices architecture for a new application, you engage Professional Services. If your existing application breaks, you open a support case under your Support plan.)
- **AWS Support plan vs AWS Service Level Agreements (SLAs):** AWS SLAs are formal commitments from AWS regarding the uptime of specific services (e.g., EC2 99.99% availability). If AWS fails to meet the SLA, you can claim credits. Support plans are about human assistance when you have problems. SLAs are about the service itself staying up. (Example: If EC2 goes down for 30 minutes, you may be eligible for a service credit under the SLA. If you need help figuring out why it went down, you open a support case using your Support plan.)

## Step-by-step breakdown

1. **Choose a support plan tier** — The first step is deciding which support plan suits your organization's needs. You evaluate the size of your AWS bill, the criticality of your workloads, and the level of support you require. For small experiments, Basic (free) is enough. For production systems, Business or Enterprise is typically needed. You select the plan via the AWS Support Center in the AWS Management Console.
2. **Select the billing method and sign up** — AWS Support plans are billed monthly. For Developer, you pay a flat $29/month or 3% of monthly AWS charges, whichever is higher. For Business, it is $100/month or 10% of monthly charges. Enterprise has a tiered percentage. You sign up by confirming payment details and agreeing to the terms. The plan takes effect immediately.
3. **Configure access and contacts** — Once enrolled, you can configure who in your organization can open support cases. You define IAM users and roles that have permissions to access the Support Center. You also set up primary contacts for notifications. For Business and Enterprise, you can have unlimited contacts. For Developer, only one primary contact is allowed.
4. **Open a support case when needed** — When you encounter an issue, you navigate to the Support Center and create a new support case. You choose the severity level: general guidance, system impaired, production system down, or business-critical system down. You provide details, logs, and steps to reproduce. The system routes the case to AWS Support engineers based on the plan and severity. For paid plans, you can also use the AWS Support API to automate case creation.
5. **AWS Support engineers respond** — Based on your plan, AWS will respond within the committed timeframe. For Business with a production system down incident, you expect a response within 1 hour. The engineer may ask for more information, provide troubleshooting steps, or escalate if needed. Communication happens via the Support Center dashboard, email, or phone for higher-tier plans.
6. **Leverage proactive services** — With Business and above, you can schedule Infrastructure Event Management (IEM) engagements for planned events. You work with AWS engineers to review your architecture, identify risks, and create a mitigation plan. For Enterprise, your Technical Account Manager (TAM) proactively conducts operational reviews and recommends improvements to avoid incidents.
7. **Monitor and optimize with Trusted Advisor** — With Business Support and higher, you get full access to AWS Trusted Advisor. You regularly review the dashboard for cost savings, security gaps, performance issues, and fault tolerance recommendations. You implement the suggestions to improve your environment. This is an ongoing step that reduces the need for reactive support.
8. **Evaluate and upgrade or downgrade as needed** — As your AWS usage grows or changes, you may need to adjust your support plan. You can upgrade to a higher tier at any time for immediate access to better support. Downgrading is also possible but takes effect at the start of the next billing cycle. You should reassess periodically, especially after major migrations or when business criticality increases.

## Practical mini-lesson

AWS Support plans are not just about getting help when something breaks. They are a strategic tool for risk management and operational efficiency. In practice, IT professionals need to understand how to evaluate which tier to use, how to configure it across a multi-account environment, and how to get the most value from the included features.

First, let’s discuss cost evaluation. The support plan fee scales with your monthly AWS bill. For example, if your organization spends $50,000 per month, Business Support will cost 10% of that, or $5,000 per month. Enterprise Support at the same spend level would be approximately $5,000 per month as well (since the first tier of Enterprise is 10% of the first $150,000). However, the flat fee for Business is $100, which is negligible compared to the percentage. The key is to calculate the break-even point between the percentage-based cost and the value of faster response. Many companies find that the cost of an hour of downtime (lost revenue, productivity, reputation) is much higher than the support plan cost, making Enterprise a rational choice despite the price.

Second, configuration matters. In a multi-account AWS Organization, you can apply the support plan to the management account. Member accounts can then open support cases, but they are routed to the plan’s engineers. However, the TAM assigned to a management account does not automatically cover member accounts for proactive engagements. If you want TAM coverage for a specific workload, that workload’s account must also have Enterprise Support, or you manage it through the management account. This is a common scenario in large enterprises that need to isolate environments.

Third, you need to know how to escalate a case effectively. When you open a case, you set the severity. If the response time passes without a meaningful update, you can escalate by replying to the case requesting an escalation. AWS Support has internal processes to assign a senior engineer. In Enterprise, you can contact your TAM directly. For Business, you may need to call the support hotline. Being professional and providing clear, accurate information speeds up resolution.

Fourth, use the proactive features. Many organizations underuse Infrastructure Event Management (IEM). If you are planning a major launch, migration, or holiday sales event, request an IEM engagement. AWS engineers will review your architecture, run load tests, and advise on scaling. This can prevent incidents before they happen. Similarly, for Enterprise customers, schedule regular operational reviews with your TAM to discuss pain points and upcoming changes.

Fifth, be aware of what can go wrong. One common mistake is relying on the Basic plan for a production system, then not being able to get help quickly. Another is forgetting to set up IAM permissions for support, causing delays when someone tries to open a case. Also, know that the support API is available for all paid plans, but you need to configure programmatic access. For automated incident response, you can use the API to create cases based on alarms, which is a best practice for mature DevOps teams.

Finally, integrate support plans with your incident management process. When an alarm fires, the on-call engineer should know the support plan level and how to open a case. They should have the AWS support phone number ready (for Business and Enterprise). Practice opening a test case during non-critical hours to ensure the process works. Document the support plan details in your runbooks.

a support plan is not a passive purchase. It is an active part of your cloud operations. Use it proactively, configure it correctly, and train your team to use it effectively. The plans are a cost center, but with the right approach, they become an enabler for high availability and faster incident resolution.

## Commands

```
aws support describe-trusted-advisor-checks --language en --region us-east-1
```
Lists all Trusted Advisor checks available for your AWS account. Used to review cost optimization, security, fault tolerance, and performance recommendations.

*Exam note: Tests knowledge of Trusted Advisor access differences among support plans; only Business and Enterprise plans provide full check details via CLI.*

```
aws support describe-cases --include-resolved --max-results 20
```
Retrieves a list of support cases, including resolved ones, to track incident history.

*Exam note: Exams ask which support plan allows case management via CLI/API; Developer, Business, and Enterprise plans include this capability.*

```
aws support add-attachments-to-set --attachments file://attachment.json
```
Attaches files (e.g., logs, screenshots) to a support case. Requires a pre-created attachment set ID.

*Exam note: Tests understanding of case attachment workflow; only Business and Enterprise plans support this via CLI.*

```
aws support create-case --subject "Unable to launch EC2 instance" --communication-body "Instance type t2.micro fails with limit error" --service-code amazon-ec2 --category-code instance-issue --severity-code normal
```
Creates a new support case with specific service and category codes. Used to report production issues.

*Exam note: Exams highlight that only Business and Enterprise plans offer 24/7 phone and chat support; Developer plan is web-only.*

```
aws support describe-communications --case-id CASE123456 --max-results 10
```
Lists all communications (comments, responses) associated with a given support case.

*Exam note: Tests that case communication history is available only with Developer, Business, or Enterprise plans; not with Basic.*

```
aws support describe-trusted-advisor-check-result --check-id d某某example --language en
```
Retrieves the detailed result of a specific Trusted Advisor check, including flagged resources.

*Exam note: Common in questions about cost optimization; only Business and Enterprise support plan customers can view full check results via CLI.*

## Troubleshooting clues

- **Cannot access Trusted Advisor checks via CLI** — symptom: Running 'aws support describe-trusted-advisor-checks' returns an 'AccessDenied' error even with proper IAM permissions.. Trusted Advisor full checks are restricted to Business and Enterprise support plan subscribers. Basic and Developer plans only see limited checks in the console. (Exam clue: Exam questions test that Trusted Advisor CLI access is tied to support plan tier, not just IAM policies.)
- **Support case creation fails with 'SubscriptionRequired' error** — symptom: When trying to create a case via CLI or console, the user gets 'AWS Premium Support Subscription is required to use this operation'.. Only accounts with a paid support plan (Developer, Business, or Enterprise) can open support cases. Basic plan users cannot create cases. (Exam clue: Appears in questions about Basic plan limitations; often contrasted with paid plans.)
- **Phone support option missing in console** — symptom: User sees only web ticket option; phone and chat buttons are grayed out or absent.. Phone support is only available with Business and Enterprise support plans. Developer and Basic plans offer only web-based case submission. (Exam clue: Exams test that phone support is a differentiator between Developer and Business plans.)
- **Case severity cannot be set to 'Critical'** — symptom: When creating a case, the severity dropdown does not show 'Critical' as an option; only 'Low', 'Normal', 'High' appear.. Critical severity is reserved for Enterprise support plan cases. Business plan users can select High but not Critical. (Exam clue: Often tested in scenarios where production systems are down; correct plan selection is key.)
- **Trusted Advisor cost optimization checks show no data** — symptom: The cost optimization category in Trusted Advisor returns empty or 'Not Available' for a Developer plan account.. Only Business and Enterprise plans receive full Trusted Advisor checks across all categories; Developer plan gets limited checks (security only). (Exam clue: Directly correlates to exam questions about Trusted Advisor feature availability per plan.)
- **Support case response time exceeded 24 hours** — symptom: A 'Normal' severity case submitted during business hours has not received a response within 24 hours.. Developer plan has a response time SLA of 24 hours for Normal severity; Business and Enterprise plans have faster SLAs (12 hours and 4 hours respectively). (Exam clue: Tests SLA differences; often presented in scenario-based questions about urgent issues.)
- **Cannot view support case history for another account in an organization** — symptom: A management account admin tries to view support cases from a member account but sees no data.. Support cases are account-specific and not centrally aggregated. AWS Organizations does not consolidate support cases across accounts. (Exam clue: Questions about consolidated billing vs. support case access; tests understanding that support is per-account.)

## Memory tip

Think of the acronym B-D-B-E: Basic (free, no support), Developer (email only, business hours), Business (24/7, 1-hour production down), Enterprise (15-minute critical, TAM). The response time for production down halves at each paid tier: 12 hours (Developer), 1 hour (Business), 15 minutes (Enterprise).

---

Practice questions and the full interactive page: https://courseiva.com/glossary/aws-support-plan