How AWS Partners can determine AWS Support plans in an organization

Solutions providers who engage with their end customers in a resale arrangement must manage different business models and support delivery models. AWS Organizations makes it possible to build the right account structure to support a resale arrangement. Monthly end-customer invoicing often poses a huge challenge in a shared resale arrangement, where you need to know the support plan subscriptions of each member (linked) account in a management (payer) account to bill end customers correctly.

In this blog post, I’ll share an overview of the business and support delivery models for resale arrangements. I’ll also provide a technical workaround you can use to determine support plans in an organization created in AWS Organizations.

Business and support delivery models

There are two resale models under the Solution Provider Addendum that dictate how a solution provider can engage and contract with their end customers:

Solution provider account model (SPAM)
End customer account model (ECAM)

Solution provider account model (SPAM)

Under this model, the solution provider’s agreement governs all access to and use of AWS services. The solution provider can create their own terms and conditions with respect to AWS services and their authorized use for their end customer. Under the solution provider account model, the email domain for the management (payer) account and all member (linked) accounts should be from the solution provider. AWS services are resold through the solution provider’s accounts.

Default for public sector. Resell through solution provider’s AWS accounts. Root domain belongs to solution provider. Solution provider accepts the AWS Customer Agreement.

Figure 1: Solution provider account model

End customer account model (ECAM)

Under this model, the end customer’s agreement governs all access to and use of AWS services with the exception of fees, payment, pricing, and tax terms, which are superseded by the terms set forth in the solution provider’s agreement with the end customer. The management (payer) account is set up with the solution provider’s email domain, but all member (linked) accounts should have the end customer’s email domain. The solution provider in this model is set up as the payer (i.e., they own the management account in the consolidated billing organization) so they can receive the bill, but all AWS services are resold through the accounts owned by the end customer.

Default for commercial. Resell through end user’s AWS accounts. Domain belongs to end user. End user accepts the AWS Customer Agreement.

Figure 2: End customer account model

The AWS Solution Provider Program, which was designed for APN Partners to resell AWS services to end customers, offers both Resold Support and AWS Partner-Led Support delivery models.

Resold Support delivery model

Resold Support allows a solution provider’s customer to interact with the AWS Support team directly when on Business or Enterprise Support. The solution provider is not responsible for handling technical inquiries, but they must make sure the customer can contact AWS Support through the AWS Support Center and provide support for non-technical customer inquiries (for example, billing and account management questions).

Diagram shows interaction between end customer, Resold Support partner, and AWS Support, as described in the post.

Figure 3: Resold Support

Partner-Led Support delivery model

In the Partner-Led Support delivery model, the solution provider is their customer’s sole point of contact for technical support. The customer doesn’t contact AWS directly for technical assistance. If the solution provider cannot answer a customer’s question, the provider can use the Business or Enterprise support plans to get guidance from AWS and then pass this information to their customer.

Diagram shows interaction between end customer, Partner-Led partner, and AWS Support, as described in the post.

Figure 4: Partner-Led Support

Solution providers cannot mix these two delivery models in the same organization created in AWS Organizations. The solution provider must maintain at least one AWS Organizations management account for each delivery model and support type.

Figure 5 shows the allowed support-plan combinations that the member accounts can be subscribed to. The management account must be set to an appropriate delivery model whether Partner-Led or Resold. They additionally need an AWS support plan to produce accurate invoices for customers and receive solution provider discounts. When the management (payer) account is registered as Basic, the member (linked) accounts will bill public list-price minimums and will not receive solution provider discounts.

Figure 5: Basic, Business, and Enterprise comparison

If an AWS management (payer) account has Partner-Led or Resold Support delivery model enabled with a Business support plan subscription, the member (linked) accounts can have Basic, Developer, or Business support plans (but not the Enterprise support plan). Also note that the delivery model (Partner-Led or Resold) must be the same on all member accounts linked under a given management account. As an example, if you have an AWS management account enabled with Partner-Led support delivery model and with a Business support plan subscription, all member accounts must also be on Partner-Led.

Enterprise support management accounts should have the AWS Support Enterprise plan enabled on member accounts. As with the Business support model, the delivery method must also be the same.

The Solution Provider’s management account set up is designed to be flexible. You can create as many consolidated billing organizations as necessary for your business. Figure 6 shows some examples of the management account scenarios that you can experience with your end customers. Because certain service configurations are not supported on the same management account, you will need to create additional management accounts if certain conditions exist, as shown in the figure 6 below.

Payer 1 is SPAM with Resold delivery model and Business support. Payer 2 is ECAM with Resold delivery model and Business support. Payer 3 is ECAM with Partner-Led delivery model and Enterprise support. Payer 4 is ECAM with Resold delivery model, Enterprise support, and a single customer.

Figure 6: Payer details

Determining AWS Support plans for member accounts

In a typical solution provider resale arrangement that involves either a shared partner-led or resold support model, a management account has multiple customer member accounts linked with various support plan subscriptions and has no visibility into what support plan each customer member account has.

To help with monthly invoicing and to bill their end customers correctly, solution providers need a self-service feature that will help them infer the AWS Support plan (Basic, Developer, Business, or Enterprise) of each member account in an organization at the level of the management account. Today, this level of information is only available by relying on manual support from AWS to extract the information.

In the following section, I share a couple approaches for determining the AWS Support plans currently enabled in the member accounts in an organization.

Using the AWS Management Console to determine AWS Support plans

For a shared resale arrangement, you can use the AWS Management Console to see which AWS Support plan an account is subscribed to. Sign in to the AWS Management Console and choose the AWS Support Plans page at https://console.aws.amazon.com/support/plans/. Under Support plans, check the value set for Current support plan.

For more complex account structure setups that involves multiple customer member accounts with various support plan subscriptions, it’s not feasible to use the AWS Management Console to extract this information. For a programmatic solution, the describe-severity-levels API can be used to determine the AWS Support level associated with an account.

The describe-severity-levels API returns the list of severity levels that you can assign to an AWS Support case. These severity levels map to or can be used to infer a support plan for an account. The values returned by the API are different from the values that appear in the AWS Support Center. For example, the API uses the code low, but the name appears as General guidance in Support Center.

The following are the API code names and how they appear in the console:

low – General guidance
normal – System impaired
high – Production system impaired
urgent – Production system down
critical – Business-critical system down

For example, if an AWS account has an Enterprise support plan, the highest severity levels returned are critical and urgent. Likewise, if an account has a Business support plan, the highest severity level returned is urgent. For the Developer support plan, the severity levels returned are low and normal.

If a premium AWS Support plan is not currently enabled, the following error is returned: "An error occurred (SubscriptionRequiredException) when calling the DescribeSeverityLevels operation: AWS Premium Support Subscription is required to use this service."

Because the severity levels are returned in the output, you can use describe-severity-levels to determine the AWS Support plan that the account is subscribed to.

Using the AWS CLI to determine AWS Support plans

In this section, I share sample screenshots from accounts with different AWS Support plans.

To get the list of the severity levels from an AWS account, run the describe-severity-levels AWS CLI command.

Figure 7 shows the severityLevels of an AWS account that is subscribed to the Enterprise support plan. You’ll see the highest returned code is critical, which indicates that the account has an Enterprise support plan.

aws support describe-severity-levels –region us-east-1 returns severityLevels.

Figure 7: Enterprise support plan

Figure 8 shows the severityLevels of an AWS account that is subscribed to the Business support plan. You’ll see that the highest returned code is urgent, which indicates that the account has a Business support plan.

aws support describe-severity-levels –region us-east-1 returns severityLevels.

Figure 8: Business support plan

If an account only has the Basic support plan, the following output (error) is returned, which indicates that a premium support plan is not enabled on this account.

Figure 9: Basic support plan

This is how you can infer the support plan using the AWS CLI. Ideally, you can use the AWS SDKs to do this programmatically. To use this workaround, the management account must have read-only support access to member accounts to execute this API call. This means that you must create a cross-account IAM role in the member accounts and provide read-only support level permissions so that the management account can assume this role and make the API call. For information about how to configure cross-account roles, see IAM tutorial: Delegate access across AWS accounts using IAM roles in the IAM User Guide.

Cross-account roles are also helpful when you’re creating management tools. You can use the DescribeSeverityLevels API to programmatically scan multiple member accounts and infer their support plans. The Python example using the Boto3 interface to AWS in Switching to an IAM role (AWS API) shows how to call AssumeRole. It also shows how to use the temporary security credentials returned by AssumeRole to make API calls in the account that owns the role.

The code snippet in Discover Amazon Web Services and issue severity levels demonstrates API calls to the AWS Support DescribeServices and DescribeSeverityLevel operations. You can use these code snippets to develop a programmatic and automated way of inferring support plans.

The following Java code snippet demonstrates calls to the AWS Support DescribeSeverityLevel operation. Each call returns a JSON-formatted object that include severity levels and their corresponding names.

// DescribeSeverityLevels example
public static void getSeverityLevels(AWSSupportClient client) 
{
    DescribeSeverityLevelsResult result = client.describeSeverityLevels();
    for (SeverityLevel level : result.getSeverityLevelsList()) 
    {
        System.out.println("Severity level (name): " + 
            level.getCode() + level.getName() + ")");
    }
}

To make the workaround setup easier, you can use the following CloudFormation template to help facilitate the creation and configuration of the role in the member accounts and grant the read-only support level permissions to the management account:

---
AWSTemplateFormatVersion: '2010-09-09'
Description: Read Only Support role to allow support level visibility into the member
  account
Parameters:
  RoleNameParameter:
    Description: Please enter the role name. Use alphanumeric and '+=,.@-_' characters.
      Maximum 64 characters.
    Type: String
    MinLength: 1
    MaxLength: 64
    Default: PartnerReadOnlySupportRole
  PartnerAccountParameter:
    Description: Please enter the partner's management/payer account ID. Type the
      12-digit account number
    Type: String
    MinLength: 12
    MaxLength: 12
Resources:
  ReadOnlySupportRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Statement:
          - Action: sts:AssumeRole
            Effect: Allow
            Principal:
              AWS: !Sub 'arn:${AWS::Partition}:iam::${PartnerAccountParameter}:root'
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/job-function/SupportUser
      Path: /
      RoleName: !Ref 'RoleNameParameter'
Outputs:
  PartnerRoleName:
    Description: Role's name created for the partner with this CF template
    Value: !Ref 'RoleNameParameter'

Conclusion

In this post, I shared information about business and support delivery models and how they apply to a resold arrangement setup in AWS Organizations. I showed how you can use the AWS Support DescribeSeverityLevels API to infer the support plans of member accounts linked to a management account in AWS Organizations. By using cross-account access and DescribeSeverityLevels API calls, you programmatically determine support plans and automate this process for monthly end customer invoicing.

AWS Cloud Operations Blog