‫Okay, so now let's talk about AWS Limits
‫or called as well Quotas.
‫So, you have two types of limits.
‫You have API Rate Limits
‫which is how many times you can call an AWS API in a row.
‫So for example, the DescribeInstances API for Amazon EC2
‫has a limit of 100 calls per seconds.
‫And the GetObject on Amazon S3
‫has a limit of 5,500 GET
‫per second per prefix.
‫So when we go over,
‫we are getting into an Intermittent Error
‫because we'll be throttled.
‫And so we should use an Exponential Backoff Strategy,
‫and I'll describe this in the very next slide.
‫And in case we are getting these errors consistently
‫because we are having heavy usage of our application
‫and we consistently go over these limits,
‫then instead we should request
‫an API throttling limit increase
‫to make sure that we can for example,
‫issue more than 100 calls per second
‫for DescribeInstances,
‫maybe we need 300, okay?
‫And so we would ask AWS for this.
‫So this is for the API Rate Limits,
‫and the other kind of limits we have is Service Quotas
‫which is Service Limits,
‫which is how many resources we can run of something.
‫For example, for your On-Demand Standard Instances,
‫we can run up to 1,152
‫virtual CPUs,
‫and if you want to run a more vCPUs in your accounts
‫then you can request a Service Limit increase
‫by just simply opening a tickets.
‫And you can request a Service Quota increase
‫by using this Service Quota API as well
‫to do this programmatically, okay?
‫So we have API Rate Limits
‫and as well as Service Quotas for your resources.
‫Now, what did I say?
‫If we get Intermittent Errors
‫then we should use Exponential Backoff.
‫So when do we use Exponential Backoff?
‫Well, when we get a ThrottlingException.
‫And so this is an exam question,
‫anytime you see that there is a ThrottlingException
‫because we did too many API calls,
‫usually the answer is to do Exponential Backoff.
‫So if you're using the AWS SDK
‫then this retry mechanism is already included
‫into the SDK behavior.
‫But if you are using the AWs API as-is yourself
‫then you are the one responsible
‫for implementing the Exponential Backup.
‫And so a question in the exam may ask you
‫which kind of errors should you retry
‫on an Exponential Backoff?
‫And if you are explaining, implementing your own SDK,
‫your own custom HTTP calls
‫then you must only implement the retries
‫when you receive a server error
‫that has error code that start with 500.
‫So 503 or whatever,
‫5XX,
‫because these server errors and Throttling Errors
‫are the ones that can be retried,
‫but you should not implement a retry or Exponential Backoff
‫on the 4XX client errors, okay?
‫The 400 errors, because that means that something
‫has been sent wrong by your clients,
‫and so if you keep on retrying them
‫you will keep on receiving the same errors.
‫So how does Exponential Backoff work?
‫Well, we are trying the first request say for one second,
‫then we're going to double the time
‫to wait until the next request.
‫So two seconds maybe because we're doubling
‫for the next retry we're going to double again.
‫So four seconds and we double again.
‫So for the next retry, we're going to go to eight seconds,
‫and then for the next retry,
‫we're going to go to 16 seconds.
‫So the idea is with this Exponential Backoff,
‫the more we retry the more we wait,
‫and so if many clients are doing this at the same time
‫the result of this is that
‫there's going to be less and less load on your server,
‫allowing your server to serve as many answers as possible.
‫And this is the whole concept of Exponential Backoff.
‫So that's it.
‫I hope you liked this lecture,
‫and I will see you in the next lecture.