Guidelines and quotas - Amazon Lex

Guidelines and quotas

Regions

For a list of AWS Regions where Amazon Lex V2 is available, see AWS regions and endpoints in the AWS general reference.

General guidelines

This topic describes general guidelines when using Amazon Lex V2.

  • Signing requests – All Amazon Lex V2 model-building and runtime requests in the API reference use signature V4 for authenticating requests. For more information about authenticating requests, see Signature Version 4 signing process in the Amazon Web Services general reference.

  • Note the following about how Amazon Lex V2 captures slot values from user utterances:

    Amazon Lex V2 uses the enumeration values that you provide in a slot type definition to train its machine learning models. Suppose that you define an intent called GetPredictionIntent with the following sample utterance:

    "Tell me the prediction for {sign}"

    where {sign} is a slot with the custom type ZodiacSign. It has 12 enumeration values, Aries through Pisces. From the user utterance "Tell me the prediction for ..." Amazon Lex V2 understands that the following is a zodiac sign.

    When the valueSelectionStrategy field is set to OriginalValue using the CreateSlotType operation, or if Expand values is selected in the console, if the user says "Tell me the prediction for earth", Amazon Lex V2 infers that "earth" is a ZodiacSign value and passes it to your client application or Lambda function. You must check that slot values are valid values before using them in your fulfillment activity.

    If you set the valueSelectionStrategy field to TopResolution using the CreateSlotType operation or if Restrict to slot values and synonyms is selected in the console, the values that are returned are limited to the values that you defined for the slot type. For example, if the user says "Tell me the prediction for earth", the value would not be recognized because it is not one of the values defined for the slot type. When you define synonyms for slot values, they are recognized the same as a slot value, however, the slot value is returned instead of the synonym.

    When Amazon Lex V2 calls a Lambda function or returns the result of a speech interaction with your client, the case of the slot values is not guaranteed. In text interactions, the case of the slot values matches the text entered or the slot value, depending on the value of the valueResolutionStrategy field.

  • When defining slot values that contain acronyms, use the following patterns:

    • Capital letters separated by periods (D.V.D.)

    • Capital letters separated by spaces (D V D)

  • The AMAZON.Date and AMAZON.Time built-on slot types capture both absolute and relative dates and times. Relative dates and times are resolved in the region where Amazon Lex V2 is processing the request.

    For the AMAZON.Time built-in slot type, if the user doesn't specify that a time is before or after noon, the time is ambiguous and Amazon Lex V2 will prompt the user again. We recommend prompts that elicit an absolute time. For example, use a prompt such as "When do you want your pizza delivered? You can say 6 PM or 6 in the evening."

  • Providing confusable training data in your bot reduces the ability of Amazon Lex V2 to understand user input. Consider these examples:

    Suppose you have two intents (OrderPizza and OrderDrink) in your bot and both are configured with an "I want to order" utterance. This utterance does not map to a specific intent that Amazon Lex V2 can learn from while building the language model for the bot at build time. As a result, when a user inputs this utterance at runtime, Amazon Lex V2 can't pick an intent with a high degree of confidence.

    When you have two intents with the same utterance, use input contexts to help Amazon Lex distinguish between the two intents at runtime. For more information, see Setting intent context .

  • When you use the TSTALIASID alias, keep in mind the following:

    • The TSTALIASID alias of your bot points to the Draft version and should only be used for manual testing. Amazon Lex limits the number of runtime requests that you can make to the TSTALIASID alias of the bot.

    • When you update the Draft version of the bot, Amazon Lex terminates any in-progress conversations for any client application using the TSTALIASID alias of the bot. Generally, you should not use the TSTALIASID alias of a bot in production because the Draft version can be updated. You should publish a version and an alias and use them instead.

    • When you update an alias, Amazon Lex takes a few minutes to pick up the changes. When you modify the Draft version of the bot, the change is picked up by the TSTALIASID alias immediately.

  • The runtime API operations RecognizeText and RecognizeUtterance take a session ID as a required parameter. Developers can set this to any value that meets the constraints described in the API. We recommend that you don't use this parameter to send any confidential information such as user logins, emails, or social security numbers. This ID is primarily used to uniquely identify a conversation with a bot.

Quotas

Service quotas, also referred to as limits, are the maximum number of service resources for you AWS account. For more information, see AWS service quotas in the AWS general reference.

Service quotas can be adjusted or increased. Contact AWS customer support to increase a quota. It can take a few days to increase a service quota. If you're increasing your quota as part of a larger project, be sure to add this time to your plan.

Build-time quotas

The following maximum quotas are enforced when you are creating a bot.

Description Default
Bots per AWS account 100
Bot channel associations per AWS account 5,000
Versions per bot 100
Intents per locale in each bot
  • 1,000 in en-AU, en-GB, and en-US

  • 250 in all other locales

Slots per locale in each bot
  • 4,000 in en-AU, en-GB, and en-US

  • 2,000 in all other locales

Custom slot types per bot locale
  • 250 in en-AU, en-GB, and en-US

  • 100 in all other locales

Custom slot type values and synonyms per locale in each bot 50,000
Total characters in sample utterances per locale in each bot
  • 2,000,000 in en-AU, en-GB, and en-US

  • 200,000 in all other locales

Channel associations per bot alias 10
Slots per intent 100
Sample utterances per intent 1,500
Characters per sample utterance 500
Text response length 4,000
Sample utterances per slot 10
Characters per sample slot utterance 500
Prompts per slot 30
Values and synonyms per custom slot type 10,000
Characters per custom slot type value 500
Characters in a channel association name 100

Runtime quotas

The following maximum quotas are enforced at runtime.

Description Default
Input text size for RecognizeText and RecognizeUtterance 1024 Unicode characters
Speech input length for RecognizeUtterance operation 15 seconds
Size of RecognizeUtterance headers 16 KB
Size of combined request and session headers for RecognizeUtterance 12 KB
Maximum number of concurrent conversations for RecognizeText, RecognizeUtterance, or StartConversation for the TestBotAlias 2
Maximum number of concurrent conversations for RecognizeText, RecognizeUtterance, or StartConversation for other aliases 25
Maximum number of concurrent session management operations (PutSession, GetSession, or DeleteSession) when using the TestBotAlias 2
Maximum number of concurrent session management operations (PutSession, GetSession, or DeleteSession) when using other aliases 25
Maximum input size to a Lambda function 12 KB
Maximum output size of a Lambda function 25 KB
Maximum size of session attributes in Lambda function output 12 KB