# Manage Amazon EMR Service Quotas **Topics** + [What are Amazon EMR Service Quotas](emr-service-limits-what-are.md) + [How to manage Amazon EMR Service Quotas](emr-service-limits-strategy.md) + [When to set up EMR events in CloudWatch](emr-service-limits-cloudwatch-events.md) The topics in this section describe EMR service quotas (formerly referred to as service limits), how to manage them in the AWS Management Console, and when it's advantageous to use CloudWatch events instead of service quotas to monitor clusters and trigger actions. # What are Amazon EMR Service Quotas Your AWS account has default service quotas, also known as limits, for each AWS service. The EMR service has two types of limits: + *Limits on resources* - You can use EMR to create EC2 resources. However, these EC2 resources are subject to service quotas. The resource limitations in this category are: + The maximum number of active clusters that can be run at the same time. + The maximum number of active instances per instance group. + *Limits on APIs* - When using EMR APIs, the two types of limitations are: + *Burst limit* – This is the maximum number of API calls you can make at once. For example, the maximum number of AddInstanceFleet API requests that you can make per second is set at 5 calls/second as a default. This implies that the burst limit of AddInstanceFleet API is 5 calls/second, or that, at any given time, you can make at most 5 AddInstanceFleet API calls. However, after you use the burst limit, your subsequent calls are limited by the rate limit. + *Rate limit* – This is the replenishment rate of the API's burst capacity. For example, replenishment rate of AddInstanceFleet calls is set at 0.5 calls/second as a default. This means that after you reach the burst limit, you have to wait at least 2 seconds (0.5 calls/second X 2 seconds = 1 call) to make the API call. If you make a call before that, you are throttled by the EMR web service. At any point, you can only make as many calls as the burst capacity without being throttled. Every additional second you wait, your burst capacity increases by 0.5 calls until it reaches the maximum limit of 5, which is the burst limit. # How to manage Amazon EMR Service Quotas Service Quotas is an AWS feature that you can use to view and manage your Amazon EMR service quotas or limits from a central location, using the AWS Management Console, the API or the AWS CLI. To learn more about viewing quotas and requesting increases, see [AWS service quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) in the *Amazon Web Services General Reference*. **Important** Service quotas can be enforced independent of each other and at times their effects can overlap. Some are scoped to specific APIs, and other quotas enforce limits at the account level. Specifically, the following quotas are applied at the account level: *The maximum rate at which your bucket replenishes for all EMR operations* *The maximum number of API requests that you can make per second* Note that if you successfully request a specific quota increase and you continue to see throttling, for example for API requests, it's possible that one of these account-level quotas are continuing to limit API call rates. For troubleshooting, you can use the Service quotas console, which is available at [https://console.aws.amazon.com/servicequotas/home](https://console.aws.amazon.com/servicequotas/home), to check quota limits and request increases. If you make requests for increases and continue to see throttling, contact support. You can also find default limits and descriptions for EMR [Service quotas](https://docs.aws.amazon.com/general/latest/gr/emr.html#limits_emr) in the **AWS General Reference** *Reference guide*. For some APIs, setting up a CloudWatch event might be a better option than increasing service quotas. You can also save time by using CloudWatch to set alarms and trigger increase requests proactively, before you reach the service quota. For more details, see [When to set up EMR events in CloudWatch](emr-service-limits-cloudwatch-events.md). # When to set up EMR events in CloudWatch For some polling APIs, such as DescribeCluster, DescribeStep, and ListClusters, setting up a CloudWatch event can reduce the response time to changes and free up your service quotas. For example, if you have a Lambda function set up to run when a cluster's state changes, such as when a step completes or a cluster terminates, you can use that trigger to start the next action in your workflow instead of waiting for the next poll. Otherwise, if you have dedicated Amazon EC2 instances or Lambda functions constantly polling the EMR API for changes, you not only waste compute resources but might also reach your service quota. Following are a few cases when you might benefit by moving to an event-driven architecture. ## Case 1: Polling EMR using DescribeCluster API calls for step completion **Example Polling EMR using DescribeCluster API calls for step completion** A common pattern is to submit a step to a running cluster and poll Amazon EMR for status about the step, typically using the DescribeCluster or DescribeStep APIs. This task can also be accomplished with minimal delay by hooking into Amazon EMR Step Status Change event in. This event includes the following information in its payload. ``` { "version": "0", "id": "999cccaa-eaaa-0000-1111-123456789012", "detail-type": "EMR Step Status Change", "source": "aws.emr", "account": "123456789012", "time": "2016-12-16T20:53:09Z", "region": "us-east-1", "resources": [], "detail": { "severity": "ERROR", "actionOnFailure": "CONTINUE", "stepId": "s-ZYXWVUTSRQPON", "name": "CustomJAR", "clusterId": "j-123456789ABCD", "state": "FAILED", "message": "Step s-ZYXWVUTSRQPON (CustomJAR) in Amazon EMR cluster j-123456789ABCD (Development Cluster) failed at 2016-12-16 20:53 UTC." } } ``` In the detail map, a Lambda function could parse for "state", "stepId", or "clusterId" to find pertinent information. ## Case 2: Polling EMR for available clusters to run workflows **Example Polling EMR for available clusters to run workflows** A pattern for customers who run multiple clusters is to run workflows on clusters as soon as they're available. If there are many clusters running and a workflow needs to be performed on a cluster that's waiting, a pattern could be to poll EMR using DescribeCluster or ListClusters API calls for available clusters. Another way to reduce the delay in knowing when a cluster is ready for a step, would be to process Amazon EMR Cluster State Change event in. This event includes the following information in its payload. ``` { "version": "0", "id": "999cccaa-eaaa-0000-1111-123456789012", "detail-type": "EMR Cluster State Change", "source": "aws.emr", "account": "123456789012", "time": "2016-12-16T20:43:05Z", "region": "us-east-1", "resources": [], "detail": { "severity": "INFO", "stateChangeReason": "{\"code\":\"\"}", "name": "Development Cluster", "clusterId": "j-123456789ABCD", "state": "WAITING", "message": "Amazon EMR cluster j-123456789ABCD ..." } } ``` For this event, a Lambda function could be set up to immediately send a waiting workflow to a cluster as soon as its status changes to WAITING. ## Case 3: Polling EMR for cluster termination **Example Polling EMR for cluster termination** A common pattern of customers running many EMR clusters is polling Amazon EMR for terminated clusters so that work is no longer sent to it. You can implement this pattern with the DescribeCluster and ListClusters API calls or by using Amazon EMR Cluster State Change event in. Upon cluster termination, the event emitted looks like the following example. ``` { "version": "0", "id": "1234abb0-f87e-1234-b7b6-000000123456", "detail-type": "EMR Cluster State Change", "source": "aws.emr", "account": "123456789012", "time": "2016-12-16T21:00:23Z", "region": "us-east-1", "resources": [], "detail": { "severity": "INFO", "stateChangeReason": "{\"code\":\"USER_REQUEST\",\"message\":\"Terminated by user request\"}", "name": "Development Cluster", "clusterId": "j-123456789ABCD", "state": "TERMINATED", "message": "Amazon EMR Cluster jj-123456789ABCD (Development Cluster) has terminated at 2016-12-16 21:00 UTC with a reason of USER_REQUEST." } } ``` The "detail" section of the payload includes the clusterId and state that can be acted on.