1.. _guide_retries: 2 3Retries 4======= 5 6Overview 7-------- 8 9Your AWS client might see calls to AWS services fail due to unexpected issues on the client side. Or calls might fail due to rate limiting from the AWS service you're attempting to call. In either case, these kinds of failures often don’t require special handling and the call should be made again, often after a brief waiting period. Boto3 provides many features to assist in retrying client calls to AWS services when these kinds of errors or exceptions are experienced. 10 11This guide provides you with details on the following: 12 13* How to find the available retry modes and the differences between each mode 14* How to configure your client to use each retry mode and other retry configurations 15* How to validate if your client performs a retry attempt 16 17Available retry modes 18--------------------- 19 20Legacy retry mode 21~~~~~~~~~~~~~~~~~~ 22 23Legacy mode is the default mode used by any Boto3 client you create. As its name implies, ``legacy mode`` uses an older (v1) retry handler that has limited functionality. 24 25**Legacy mode’s functionality includes:** 26 27* A default value of 5 for maximum retry attempts. This value can be overwritten through the ``max_attempts`` configuration parameter. 28* Retry attempts for a limited number of errors/exceptions:: 29 30 # General socket/connection errors 31 ConnectionError 32 ConnectionClosedError 33 ReadTimeoutError 34 EndpointConnectionError 35 36 # Service-side throttling/limit errors and exceptions 37 Throttling 38 ThrottlingException 39 ThrottledException 40 RequestThrottledException 41 ProvisionedThroughputExceededException 42 43* Retry attempts on several HTTP status codes, including 429, 500, 502, 503, 504, and 509. 44* Any retry attempt will include an exponential backoff by a base factor of 2. 45 46 47.. note:: 48 For more information about additional service-specific retry policies, see the following `botocore references in GitHub <https://github.com/boto/botocore/blob/develop/botocore/data/_retry.json>`_. 49 50 51Standard retry mode 52~~~~~~~~~~~~~~~~~~~~ 53 54Standard mode is a retry mode that was introduced with the updated retry handler (v2). This mode is a standardization of retry logic and behavior that is consistent with other AWS SDKs. In addition to this standardization, this mode also extends the functionality of retries over that found in legacy mode. 55 56**Standard mode’s functionality includes:** 57 58* A default value of 3 for maximum retry attempts. This value can be overwritten through the ``max_attempts`` configuration parameter. 59* Retry attempts for an expanded list of errors/exceptions:: 60 61 # Transient errors/exceptions 62 RequestTimeout 63 RequestTimeoutException 64 PriorRequestNotComplete 65 ConnectionError 66 HTTPClientError 67 68 # Service-side throttling/limit errors and exceptions 69 Throttling 70 ThrottlingException 71 ThrottledException 72 RequestThrottledException 73 TooManyRequestsException 74 ProvisionedThroughputExceededException 75 TransactionInProgressException 76 RequestLimitExceeded 77 BandwidthLimitExceeded 78 LimitExceededException 79 RequestThrottled 80 SlowDown 81 EC2ThrottledException 82 83* Retry attempts on nondescriptive, transient error codes. Specifically, these HTTP status codes: 500, 502, 503, 504. 84* Any retry attempt will include an exponential backoff by a base factor of 2 for a maximum backoff time of 20 seconds. 85 86Adaptive retry mode 87~~~~~~~~~~~~~~~~~~~~ 88 89Adaptive retry mode is an experimental retry mode that includes all the features of standard mode. In addition to the standard mode features, adaptive mode also introduces client-side rate limiting through the use of a token bucket and rate-limit variables that are dynamically updated with each retry attempt. This mode offers flexibility in client-side retries that adapts to the error/exception state response from an AWS service. 90 91With each new retry attempt, adaptive mode modifies the rate-limit variables based on the error, exception, or HTTP status code presented in the response from the AWS service. These rate-limit variables are then used to calculate a new call rate for the client. Each exception/error or non-success HTTP response (provided in the list above) from an AWS service updates the rate-limit variables as retries occur until success is reached, the token bucket is exhausted, or the configured maximum attempts value is reached. 92 93.. note:: 94 Adaptive mode is an experimental mode and is subject to change, both in features and behavior. 95 96 97Configuring a retry mode 98------------------------- 99 100Boto3 includes a variety of both retry configurations as well as configuration methods to consider when creating your client object. 101 102Available configuration options 103~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 104 105In Boto3, users can customize two retry configurations: 106 107* ``retry_mode`` - This tells Boto3 which retry mode to use. As described previously, there are three retry modes available: legacy (default), standard, and adaptive. 108* ``max_attempts`` - This provides Boto3’s retry handler with a value of maximum retry attempts, where the initial call counts toward the ``max_attempts`` value that you provide. 109 110Defining a retry configuration in your AWS configuration file 111~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 112 113This first way to define your retry configuration is to update your global AWS configuration file. The default location for your AWS config file is ``~/.aws/config``. Here’s an example of an AWS config file with the retry configuration options used:: 114 115 [myConfigProfile] 116 region = us-east-1 117 max_attempts = 10 118 retry_mode = standard 119 120Any Boto3 script or code that uses your AWS config file inherits these configurations when using your profile, unless otherwise explicitly overwritten by a ``Config`` object when instantiating your client object at runtime. If no configuration options are set, the default retry mode value is ``legacy``, and the default ``max_attempts`` value is 5. 121 122Defining a retry configuration in a Config object for your Boto3 client 123~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 124 125The second way to define your retry configuration is to use botocore to enable more flexibility for you to specify your retry configuration using a ``Config`` object that you can pass to your client at runtime. This method is useful if you don't want to configure retry behavior globally with your AWS config file 126 127Additionally, if your AWS configuration file is configured with retry behavior, but you want to override those global settings, you can use the ``Config`` object to override an individual client object at runtime. 128 129As shown in the following example, the ``Config`` object takes a ``retries`` dictionary where you can supply your two configuration options, ``max_attempts`` and ``mode``, and the values for each. 130 131.. code-block:: python 132 133 config = Config( 134 retries = { 135 'max_attempts': 10, 136 'mode': 'standard' 137 } 138 ) 139 140.. note:: 141 The AWS configuration file uses ``retry_mode`` and the ``Config`` object uses ``mode``. Although named differently, they both refer to the same retry configuration whose options are legacy (default), standard, and adaptive. 142 143The following is an example of instantiating a ``Config`` object and passing it into an Amazon EC2 client to use at runtime. 144 145.. code-block:: python 146 147 import boto3 148 from botocore.config import Config 149 150 config = Config( 151 retries = { 152 'max_attempts': 10, 153 'mode': 'standard' 154 } 155 ) 156 157 ec2 = boto3.client('ec2', config=config) 158 159.. note:: 160 As mentioned previously, if no configuration options are set, the default mode is ``legacy`` and the default ``max_attempts`` is 5. 161 162 163Validating retry attempts 164-------------------------- 165 166To ensure that your retry configuration is correct and working properly, there are a number of ways you can validate that your client's retries are occurring. 167 168Checking retry attempts in your client logs 169~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 170 171If you enable Boto3’s logging, you can validate and check your client’s retry attempts in your client’s logs. Notice, however, that you need to enable ``DEBUG`` mode in your logger to see any retry attempts. The client log entries for retry attempts will appear differently, depending on which retry mode you’ve configured. 172 173**If legacy mode is enabled:** 174 175Retry messages are generated by ``botocore.retryhandler``. You’ll see one of three messages: 176 177* *No retry needed* 178* *Retry needed, action of: <action_value>* 179* *Reached the maximum number of retry attempts: <attempt_num>* 180 181 182**If standard or adaptive mode is enabled:** 183 184Retry messages are generated by ``botocore.retries.standard``. You’ll see one of three messages: 185 186* *Not retrying request* 187* *Retry needed, retrying request after delay of: <delay_value>* 188* *Retry needed but retry quota reached, not retrying request* 189 190Checking retry attempts in an AWS service response 191~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 192 193You can check the number of retry attempts your client has made by parsing the response botocore provides when making a call to an AWS service API. Responses are handled by an underlying botocore module, and formatted into a dictionary that's part of the JSON response object. You can access the number of retry attempts your client has taken by calling the ``RetryAttempts`` key in the ``ResponseMetaData`` dictionary:: 194 195 'ResponseMetadata': { 196 'RequestId': '1234567890ABCDEF', 197 'HostId': 'host ID data will appear here as a hash', 198 'HTTPStatusCode': 400, 199 'HTTPHeaders': {'header metadata key/values will appear here'}, 200 'RetryAttempts': 4 201 } 202