# Error codes with ErrorDetail information in Amazon EMR Error codes When an EMR cluster terminates with an error, the `DescribeCluster` and `ListClusters` APIs return an error code and an error message. For some cluster errors, the `ErrorDetail` data array can help you troubleshoot the failure. Errors that include an `ErrorDetail` array provide the following details: **`ErrorCode`** A unique error code that you can use for programmatic access. **`ErrorData`** A list of identifiers in key-value pairs that you can use for programming or manual lookup. For descriptions of the `ErrorData` values that an error code includes, see the troubleshooting page for the error code. **`ErrorMessage`** Description of the error with a link to more information in the Amazon EMR documentation. We don’t recommend that you parse the text from `ErrorMessage` because this text is subject to change. **Topics** + [Bootstrap failures](emr-troubleshoot-error-errordetail-bootstrap.md) + [Internal errors](emr-troubleshoot-error-errordetail-internal.md) + [Validation failures](emr-troubleshoot-error-errordetail-validation.md) # Bootstrap failure error codes in Amazon EMR Bootstrap failures The following sections provide troubleshooting information for bootstrap failure error codes. **Topics** + [ # BOOTSTRAP\$1FAILURE\$1PRIMARY\$1WITH\$1NON\$1ZERO\$1CODE ](BOOTSTRAP_FAILURE_PRIMARY_WITH_NON_ZERO_CODE.md) + [ # BOOTSTRAP\$1FAILURE\$1BA\$1DOWNLOAD\$1FAILED\$1PRIMARY ](BOOTSTRAP_FAILURE_BA_DOWNLOAD_FAILED_PRIMARY.md) + [ # BOOTSTRAP\$1FAILURE\$1FILE\$1NOT\$1FOUND\$1PRIMARY ](BOOTSTRAP_FAILURE_FILE_NOT_FOUND_PRIMARY.md) + [ # BOOTSTRAP\$1FAILURE\$1INSUFFICIENT\$1DISK\$1SPACE\$1PRIMARY ](BOOTSTRAP_FAILURE_INSUFFICIENT_DISK_SPACE_PRIMARY.md) + [ # BOOTSTRAP\$1FAILURE\$1INSUFFICIENT\$1DISK\$1SPACE\$1WORKER ](BOOTSTRAP_FAILURE_INSUFFICIENT_DISK_SPACE_WORKER.md) + [ # BOOTSTRAP\$1FAILURE\$1HIVE\$1METASTORE\$1CONNECTION\$1ERROR\$1PRIMARY ](BOOTSTRAP_FAILURE_HIVE_METASTORE_CONNECTION_ERROR_PRIMARY.md) + [ # BOOTSTRAP\$1FAILURE\$1HIVE\$1METASTORE\$1CONNECTION\$1ERROR\$1WORKER ](BOOTSTRAP_FAILURE_HIVE_METASTORE_CONNECTION_ERROR_WORKER.md) # BOOTSTRAP\$1FAILURE\$1PRIMARY\$1WITH\$1NON\$1ZERO\$1CODE Primary with non zero code ## Overview When a cluster terminates with a `BOOTSTRAP_FAILURE_PRIMARY_WITH_NON_ZERO_CODE` error, a bootstrap action has failed in the primary instance. For more information about bootstrap actions, see [Create bootstrap actions to install additional software with an Amazon EMR cluster](emr-plan-bootstrap.md). ## Resolution To resolve this error, review the details returned in the API error, modify your bootstrap action script, and create a new cluster with the updated bootstrap action. To troubleshoot the failed EMR cluster, refer to the `ErrorDetail` information returned from the `DescribeCluster` and `ListClusters` APIs. For more information, see [Error codes with ErrorDetail information in Amazon EMR](emr-troubleshoot-error-errordetail.md). The `ErrorData` array within `ErrorDetail` returns the following information for this error code: **`primary-instance-id`** The ID of the primary instance where the bootstrap action failed. **`bootstrap-action`** The ordinal number for the bootstrap action that failed. A script with a `bootstrap-action` value of `1` is the first bootstrap action to run on the instance. **`return-code`** The return code for the bootstrap action that failed. **`amazon-s3-path`** The Amazon S3 location of the bootstrap action that failed. **`public-doc`** The public URL of the documentation for the error code. ## Steps to complete Perform the following steps to identify and fix the root cause of the bootstrap action error. Then launch a new cluster. 1. Review the bootstrap action log files in Amazon S3 to identify the root cause for the failure. To learn more on how to view Amazon EMR logs, see [View Amazon EMR log files](emr-manage-view-web-log-files.md). 1. If you turned on cluster logs when you created the instance, refer to the `stdout` log for more information. You can find the `stdout` log for the bootstrap action in this Amazon S3 location: ``` s3://amzn-s3-demo-bucket/logs/Your_Cluster_Id/node/Primary_Instance_Id/bootstrap-actions/Failed_Bootstrap_Action_Number/stdout.gz ``` For more information on cluster logs, see [Configure Amazon EMR cluster logging and debugging](emr-plan-debugging.md). 1. To determine the bootstrap action failure, review the exceptions in the `stdout` logs, and the `return-code` value in `ErrorData`. 1. Use your findings from the previous step to revise your bootstrap action so that it avoids exceptions or can gracefully handle exceptions when they occur. 1. Launch a new cluster with your updated bootstrap action. # BOOTSTRAP\$1FAILURE\$1BA\$1DOWNLOAD\$1FAILED\$1PRIMARY BA download failed primary ## Overview A cluster terminates with the `BOOTSTRAP_FAILURE_BA_DOWNLOAD_FAILED_PRIMARY` error when the primary instance can’t download a bootstrap action script from the Amazon S3 location that you specify. Potential causes include the following: + The bootstrap action script file isn’t in the specified Amazon S3 location. + The service role for Amazon EC2 instances on the cluster (also called the *EC2 instance profile for Amazon EMR*) doesn't have permissions to access the Amazon S3 bucket where the bootstrap action script resides. For more information about service roles, see [Service role for cluster EC2 instances (EC2 instance profile)](emr-iam-role-for-ec2.md). For more information about bootstrap actions, see [Create bootstrap actions to install additional software with an Amazon EMR cluster](emr-plan-bootstrap.md). ## Resolution To resolve this error, ensure that your primary instance has appropriate access to the bootstrap action script. To troubleshoot the failed EMR cluster, refer to the `ErrorDetail` information returned from the `DescribeCluster` and `ListClusters` APIs. For more information, see [Error codes with ErrorDetail information in Amazon EMR](emr-troubleshoot-error-errordetail.md). The `ErrorData` array within `ErrorDetail` returns the following information for this error code: **`primary-instance-id`** The ID of the primary instance where the bootstrap action failed. **`bootstrap-action`** The ordinal number for the bootstrap action that failed. A script with a `bootstrap-action` value of `1` is the first bootstrap action to run on the instance. **`amazon-s3-path`** The Amazon S3 location of the bootstrap action that failed. **`public-doc`** The public URL of the documentation for the error code. ## Steps to complete Perform the following steps to identify and fix the root cause of the bootstrap action error. Then launch a new cluster. **Troubleshooting steps** 1. Use the `amazon-s3-path` value from the `ErrorData` array to find the relevant bootstrap action script in Amazon S3. 1. If you turned on cluster logs when you created the instance, refer to the `stdout` log for more information. You can find the `stdout` log for the bootstrap action in this Amazon S3 location: ``` s3://amzn-s3-demo-bucket/logs/Your_Cluster_Id/node/Primary_Instance_Id/bootstrap-actions/Failed_Bootstrap_Action_Number/stdout.gz ``` For more information on cluster logs, see [Configure Amazon EMR cluster logging and debugging](emr-plan-debugging.md). 1. To determine the bootstrap action failure, review the exceptions in the `stdout` logs, and the `return-code` value in `ErrorData`. 1. Use your findings from the previous step to revise your bootstrap action so that it avoids exceptions or can gracefully handle exceptions when they occur. 1. Launch a new cluster with your updated bootstrap action. # BOOTSTRAP\$1FAILURE\$1FILE\$1NOT\$1FOUND\$1PRIMARY File not found primary ## Overview The `BOOTSTRAP_FAILURE_FILE_NOT_FOUND_PRIMARY` error indicates that the primary instance can’t find the bootstrap action script that the instance just downloaded from the specified Amazon S3 bucket. ## Resolution To resolve this error, confirm that your primary instance has appropriate access to the bootstrap action script. To troubleshoot the failed EMR cluster, refer to the `ErrorDetail` information returned from the `DescribeCluster` and `ListClusters` APIs. For more information, see [Error codes with ErrorDetail information in Amazon EMR](emr-troubleshoot-error-errordetail.md). The `ErrorData` array within `ErrorDetail` returns the following information for this error code: **`primary-instance-id`** The ID of the primary instance where the bootstrap action failed. **`bootstrap-action`** The ordinal number for the bootstrap action that failed. A script with a `bootstrap-action` value of `1` is the first bootstrap action to run on the instance. **`amazon-s3-path`** The Amazon S3 location of the bootstrap action that failed. **`public-doc`** The public URL of the documentation for the error code. ## Steps to complete Perform the following steps to identify and fix the root cause of the bootstrap action error. Then launch a new cluster. 1. To find the relevant bootstrap action script in Amazon S3, use the `amazon-s3-path` value from the `ErrorData` array. 1. Review the bootstrap action log files in Amazon S3 to identify the root cause for the failure. To learn more on how to view Amazon EMR logs, see [View Amazon EMR log files](emr-manage-view-web-log-files.md). **Note** If you didn't turn on logs for your cluster, you must create a new cluster with the same configurations and bootstrap actions. To ensure the cluster logs are turned on, see [Configure Amazon EMR cluster logging and debugging](emr-plan-debugging.md). 1. Review the `stdout` log for your bootstrap actions and confirm that there are no custom processes that delete files in the `/emr/instance-controller/lib/bootstrap-actions` folder on your primary instances. You can find the `stdout` log for the bootstrap action in this Amazon S3 location: ``` s3://amzn-s3-demo-bucket/logs/Your_Cluster_Id/node/Primary_Instance_Id/bootstrap-actions/Failed_Bootstrap_Action_Number/stdout.gz ``` 1. Launch a new cluster with your updated bootstrap action. # BOOTSTRAP\$1FAILURE\$1INSUFFICIENT\$1DISK\$1SPACE\$1PRIMARY Insufficient disk space primary ## Overview The `BOOTSTRAP_FAILURE_INSUFFICIENT_DISK_SPACE_PRIMARY` error indicates that the primary instance does not have enough disk space when installing necessary software. ## Resolution To resolve this error, confirm that your primary instance has sufficient disk space on the root volume. To troubleshoot the failed EMR cluster, refer to the `ErrorDetail` information returned from the `DescribeCluster` and `ListClusters` APIs. For more information, see [Error codes with ErrorDetail information in Amazon EMR](emr-troubleshoot-error-errordetail.md). The `ErrorData` array within `ErrorDetail` returns the following information for this error code: **`primary-instance-id`** The ID of the primary instance with insufficient disk space. **`public-doc`** The public URL of the documentation for the error code. ## Steps to complete 1. Review the best practices for your cluster’s EBS root device volume. See [Customizing the Amazon EBS root device volume](emr-custom-ami-root-volume-size.md) in the *Amazon EMR Management Guide*. 1. Launch a new cluster with a larger EBS root device volume size. # BOOTSTRAP\$1FAILURE\$1INSUFFICIENT\$1DISK\$1SPACE\$1WORKER Insufficient disk space worker ## Overview The `BOOTSTRAP_FAILURE_INSUFFICIENT_DISK_SPACE_WORKER` error indicates that one or more worker instances do not have enough disk space when installing necessary software. ## Resolution To resolve this error, confirm that your worker instances have sufficient disk space on the root volume. To troubleshoot the failed EMR cluster, refer to the `ErrorDetail` information returned from the `DescribeCluster` and `ListClusters` APIs. For more information, see [Error codes with ErrorDetail information in Amazon EMR](emr-troubleshoot-error-errordetail.md). The `ErrorData` array within `ErrorDetail` returns the following information for this error code: **`worker-instance-ids`** The IDs of the worker instances with insufficient disk space. **`public-doc`** The public URL of the documentation for the error code. ## Steps to complete 1. Review the best practices for your cluster’s EBS root device volume. See [Customizing the Amazon EBS root device volume](emr-custom-ami-root-volume-size.md) in the *Amazon EMR Management Guide*. 1. Launch a new cluster with a larger EBS root device volume size. # BOOTSTRAP\$1FAILURE\$1HIVE\$1METASTORE\$1CONNECTION\$1ERROR\$1PRIMARY Hive metastore connection error primary ## Overview The `BOOTSTRAP_FAILURE_HIVE_METASTORE_CONNECTION_ERROR_PRIMARY` error indicates that the primary instance is unable to establish a connection to the configured external Hive Metastore. ## Resolution To resolve this error, confirm that your external Hive Metastore is configured properly and the primary instance is allowed to connect to it. To troubleshoot the failed EMR cluster, refer to the `ErrorDetail` information returned from the `DescribeCluster` and `ListClusters` APIs. For more information, see [Error codes with ErrorDetail information in Amazon EMR](emr-troubleshoot-error-errordetail.md). The `ErrorData` array within `ErrorDetail` returns the following information for this error code: **`primary-instance-id`** The ID of the primary instance unable to establish a connection to the configured external Hive Metastore. **`public-doc`** The public URL of the documentation for the error code. ## Steps to complete 1. Review the best practices for for configuring an external metastore for Hive. See [Configuring an external metastore for Hive](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-metastore-external-hive.html). 1. Launch a new cluster with your updated cluster configuration. # BOOTSTRAP\$1FAILURE\$1HIVE\$1METASTORE\$1CONNECTION\$1ERROR\$1WORKER Hive metastore connection error worker ## Overview The `BOOTSTRAP_FAILURE_HIVE_METASTORE_CONNECTION_ERROR_WORKER` error indicates that one or more worker instances are unable to establish a connection to the configured external Hive Metastore. ## Resolution To resolve this error, confirm that your external Hive Metastore is configured properly and the worker instances are allowed to connect to it. To troubleshoot the failed EMR cluster, refer to the `ErrorDetail` information returned from the `DescribeCluster` and `ListClusters` APIs. For more information, see [Error codes with ErrorDetail information in Amazon EMR](emr-troubleshoot-error-errordetail.md). The `ErrorData` array within `ErrorDetail` returns the following information for this error code: **`worker-instance-ids`** The IDs of the worker instances unable to establish a connection to the configured external Hive Metastore. **`public-doc`** The public URL of the documentation for the error code. ## Steps to complete 1. Review the best practices for for configuring an external metastore for Hive. See [Configuring an external metastore for Hive](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-metastore-external-hive.html). 1. Launch a new cluster with your updated cluster configuration. # Internal error codes for Amazon EMR Internal errors The following sections provide troubleshooting information for internal error codes, including codes for insufficient capacity or no capacity. **Topics** + [ # INTERNAL\$1ERROR\$1EC2\$1INSUFFICIENT\$1CAPACITY\$1AZ ](INTERNAL_ERROR_EC2_INSUFFICIENT_CAPACITY_AZ.md) + [ # INTERNAL\$1ERROR\$1SPOT\$1PRICE\$1INCREASE\$1PRIMARY ](INTERNAL_ERROR_SPOT_PRICE_INCREASE_PRIMARY.md) + [ # INTERNAL\$1ERROR\$1SPOT\$1NO\$1CAPACITY\$1PRIMARY ](INTERNAL_ERROR_SPOT_NO_CAPACITY_PRIMARY.md) # INTERNAL\$1ERROR\$1EC2\$1INSUFFICIENT\$1CAPACITY\$1AZ EC2 insufficient capacity AZ ## Overview A cluster terminates with an `INTERNAL_ERROR_EC2_INSUFFICIENT_CAPACITY_AZ` error when the selected Availability Zone doesn't have enough capacity to fulfill your Amazon EC2 instance type request. The subnet that you select for a cluster determines the Availability Zone. For more information about subnets for Amazon EMR, see [Configure networking in a VPC for Amazon EMR](emr-plan-vpc-subnet.md). ## Resolution To resolve this error, modify your instance type configurations and create a new cluster with your updated request. To troubleshoot the failed EMR cluster, refer to the `ErrorDetail` information returned from the `DescribeCluster` and `ListClusters` APIs. For more information, see [Error codes with ErrorDetail information in Amazon EMR](emr-troubleshoot-error-errordetail.md). The `ErrorData` array within `ErrorDetail` returns the following information for this error code: **`instance-type`** The instance type that is out of capacity. **`availability-zone`** The Availability Zone that your subnet resolves to. **`public-doc`** The public URL of the documentation for the error code. ## Steps to complete Perform the following steps to identify and fix the root cause of the cluster configuration error: + Review the best practices for cluster configuration. See [Configuring Amazon EMR cluster instance types and best practices for Spot instances](emr-plan-instances-guidelines.md) in the *Amazon EMR Management Guide*. + Troubleshoot the launch issues and review your configuration. See [Troubleshoot instance launch issues ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-launch.html) in the *Amazon EC2 User Guide*. + Launch a new cluster with your updated cluster configuration. # INTERNAL\$1ERROR\$1SPOT\$1PRICE\$1INCREASE\$1PRIMARY Spot price increase primary ## Overview A cluster terminates with an `INTERNAL_ERROR_SPOT_PRICE_INCREASE_PRIMARY` error when Amazon EMR can't fulfill your Spot Instance request for the primary node because instances aren't available at or below your maximum Spot price. For more information, see [Spot Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) in the *Amazon EC2 User Guide*. ## Resolution To resolve this error, specify instance types for your cluster that are within your price target, or increase your price limit for the same instance type. To troubleshoot the failed EMR cluster, refer to the `ErrorDetail` information returned from the `DescribeCluster` and `ListClusters` APIs. For more information, see [Error codes with ErrorDetail information in Amazon EMR](emr-troubleshoot-error-errordetail.md). The `ErrorData` array within `ErrorDetail` returns the following information for this error code: **`primary-instance-id`** The ID for the primary instance of the cluster that failed. **`instance-type`** The instance type that is out of capacity. **`availability-zone`** The Availability Zone where your subnet resides. **`public-doc`** The public URL of the documentation for the error code. ## Steps to complete Perform the following steps to troubleshoot your cluster configuration strategy, and then launch a new cluster: 1. Review the best practices for Amazon EC2 Spot Instances and review your cluster configuration strategy. For more information, see [Best practices for EC2 Spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html) in the *Amazon EC2 User Guide* and [Configuring Amazon EMR cluster instance types and best practices for Spot instances](emr-plan-instances-guidelines.md). 1. Modify your instance type configurations or Availability Zone and create a new cluster with your updated request. 1. If the issue persists, use On-Demand capacity for your primary instance. # INTERNAL\$1ERROR\$1SPOT\$1NO\$1CAPACITY\$1PRIMARY Spot no capacity primary ## Overview A cluster terminates with a `INTERNAL_ERROR_SPOT_NO_CAPACITY_PRIMARY` error when there isn't enough capacity to fulfill a Spot Instance request for your primary node. For more information, see [Spot Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) in the *Amazon EC2 User Guide*. ## Resolution To resolve this error, specify instance types for your cluster that are within your price target, or increase your price limit for the same instance type. To troubleshoot the failed EMR cluster, refer to the `ErrorDetail` information returned from the `DescribeCluster` and `ListClusters` APIs. For more information, see [Error codes with ErrorDetail information in Amazon EMR](emr-troubleshoot-error-errordetail.md). The `ErrorData` array within `ErrorDetail` returns the following information for this error code: **`primary-instance-id`** The ID for the primary instance of the cluster that failed. **`instance-type`** The instance type that is out of capacity. **`availability-zone`** The Availability Zone that your subnet resolves to. **`public-doc`** The public URL of the documentation for the error code. ## Steps to complete Perform the following steps to troubleshoot your cluster configuration strategy, and then launch a new cluster: 1. Review the best practices for Amazon EC2 Spot Instances and review your cluster configuration strategy. For more information, see [Best practices for EC2 Spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html) in the *Amazon EC2 User Guide* and [Configuring Amazon EMR cluster instance types and best practices for Spot instances](emr-plan-instances-guidelines.md). 1. Modify your instance type configurations and create a new cluster with your updated request. 1. If the issue persists, use On-Demand capacity for your primary instance. # Validation failure error codes in Amazon EMR Validation failures The following sections provide troubleshooting information for validation failure error codes. **Topics** + [ # VALIDATION\$1ERROR\$1SUBNET\$1NOT\$1FROM\$1ONE\$1VPC ](VALIDATION_ERROR_SUBNET_NOT_FROM_ONE_VPC.md) + [ # VALIDATION\$1ERROR\$1SECURITY\$1GROUP\$1NOT\$1FROM\$1ONE\$1VPC ](VALIDATION_ERROR_SECURITY_GROUP_NOT_FROM_ONE_VPC.md) + [ # VALIDATION\$1ERROR\$1INVALID\$1SSH\$1KEY\$1NAME ](VALIDATION_ERROR_INVALID_SSH_KEY_NAME.md) + [ # VALIDATION\$1ERROR\$1INSTANCE\$1TYPE\$1NOT\$1SUPPORTED ](VALIDATION_ERROR_INSTANCE_TYPE_NOT_SUPPORTED.md) # VALIDATION\$1ERROR\$1SUBNET\$1NOT\$1FROM\$1ONE\$1VPC Subnet not from one VPC ## Overview When your cluster and the subnets that you reference for your cluster belong to different virtual private clouds (VPCs), the cluster terminates with a `VALIDATION_ERROR_SUBNET_NOT_FROM_ONE_VPC` error. You can launch clusters with Amazon EMR with the instance fleets configuration across subnets in a VPC. For more information about instance fleets, see [Planning and configuring instance fleets for your Amazon EMR cluster](emr-instance-fleet.md) in the *Amazon EMR Management Guide*. ## Resolution To resolve this error, use subnets that belong to the same VPC as the cluster. To troubleshoot the failed EMR cluster, refer to the `ErrorDetail` information returned from the `DescribeCluster` and `ListClusters` APIs. For more information, see [Error codes with ErrorDetail information in Amazon EMR](emr-troubleshoot-error-errordetail.md). The `ErrorData` array within `ErrorDetail` returns the following information for this error code: **`vpc`** For each subnet:VPC pair, the ID for the VPC that the subnet belongs to. **`subnet`** For each subnet:VPC pair, the ID for the subnet. **`public-doc`** The public URL of the documentation for the error code. ## Steps to complete Perform the following steps to identify and fix the error: 1. Review the subnet IDs that are listed in the `ErrorData` array and confirm that they belong to the VPC where you want to launch the EMR cluster. 1. Modify your subnet configurations. You can use one of the following methods to find all available public and private subnets in a VPC. + Navigate to the Amazon VPC Console. Choose **Subnets** and list all of the subnets that reside within the AWS Region for your cluster. To find only public or private subnets, apply the **Auto-assign public IPv4 address** filter. To find and select subnets in the VPC that your cluster uses, use the **Filter by VPC** option. For more information on how to create subnets, see [Create a subnet](https://docs.aws.amazon.com/vpc/latest/userguide/create-subnets.html) in the *Amazon Virtual Private Cloud User Guide*. + Use the AWS CLI to find all available public and private subnets in the VPC that your cluster uses. For more information, see the [describe-subnets](https://amazonaws.com/ec2/describe-subnets.html) API. To create new subnets in a VPC, see the [create-subnet](https://amazonaws.com/ec2/create-subnet.html) API. 1. Launch a new cluster with subnets from the same VPC as the cluster. # VALIDATION\$1ERROR\$1SECURITY\$1GROUP\$1NOT\$1FROM\$1ONE\$1VPC Security group not from one VPC ## Overview When your cluster and the security groups that you assign to your cluster belong to different virtual private clouds (VPCs), the cluster terminates with a `VALIDATION_ERROR_SECURITY_GROUP_NOT_FROM_ONE_VPC` error. For more information about security groups, see [Specifying Amazon EMR-managed and additional security groups](emr-sg-specify.md) and [Control network traffic with security groups for your Amazon EMR cluster](emr-security-groups.md). ## Resolution To resolve this error, use security groups that belong to the same VPC as the cluster. To troubleshoot the failed EMR cluster, refer to the `ErrorDetail` information returned from the `DescribeCluster` and `ListClusters` APIs. For more information, see [Error codes with ErrorDetail information in Amazon EMR](emr-troubleshoot-error-errordetail.md). The `ErrorData` array within `ErrorDetail` returns the following information for this error code: **`vpc`** For each security-group:VPC pair, the ID for the VPC that the security group belongs to. **`security-group`** For each security-group:VPC pair, the ID for the security group. **`public-doc`** The public URL of the documentation for the error code. ## Steps to complete Perform the following steps to identify and fix the error: 1. Review the security group IDs that are listed in the `ErrorData` array and confirm that they belong to the VPC where you want to launch the EMR cluster. 1. Navigate to the Amazon VPC Console. Choose **Security groups** to list all of the security groups within the Region that you select. Find the security groups from the same VPC as your cluster, and then modify your security group configuration. 1. Launch a new cluster with security groups from the same VPC as the cluster. # VALIDATION\$1ERROR\$1INVALID\$1SSH\$1KEY\$1NAME Invalid SSH key name ## Overview A cluster terminates with a `VALIDATION_ERROR_INVALID_SSH_KEY_NAME` error when you use an Amazon EC2 key pair that isn't valid to SSH into the primary instance. The key pair name might be incorrect, or the key pair might not exist in the requested AWS Region. For more information about key pairs, see [Amazon EC2 key pairs and Linux instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) in the *Amazon EC2 User Guide*. ## Resolution To resolve this error, create a new cluster with a valid SSH key pair name. To troubleshoot the failed EMR cluster, refer to the `ErrorDetail` information returned from the `DescribeCluster` and `ListClusters` APIs. For more information, see [Error codes with ErrorDetail information in Amazon EMR](emr-troubleshoot-error-errordetail.md). The `ErrorData` array within `ErrorDetail` returns the following information for this error code: **`ssh-key`** The SSH key pair name that you provided when you created the cluster. **`public-doc`** The public URL of the documentation for the error code. ## Steps to complete Perform the following steps to identify and fix the error: 1. Check your *keypair*.pem file and confirm that it matches the name of the SSH key that you see in the Amazon EMR console. 1. Navigate to the Amazon EC2 console. Verify that the SSH key name that you used is available in the AWS Region that your cluster uses. You can find your AWS Region next to your account ID at the top of the AWS Management Console. 1. Launch a new cluster with a valid SSH key name. # VALIDATION\$1ERROR\$1INSTANCE\$1TYPE\$1NOT\$1SUPPORTED Instance type not supported ## Overview A cluster terminates with a `VALIDATION_ERROR_INSTANCE_TYPE_NOT_SUPPORTED` error when the AWS Region and Availability Zones for your cluster don't support the specified instance type for one or more instance groups. Amazon EMR might support an instance type in one Availability Zone within a Region but not another. The subnet that you select for a cluster determines the Availability Zone within the Region. For a list of instance types and Regions that Amazon EMR supports, see [Supported instance types with Amazon EMR](emr-supported-instance-types.md). ## Resolution To resolve this error, specify instance types for your cluster that Amazon EMR supports in the Region and Availability Zone where you request the cluster. To troubleshoot the failed EMR cluster, refer to the `ErrorDetail` information returned from the `DescribeCluster` and `ListClusters` APIs. For more information, see [Error codes with ErrorDetail information in Amazon EMR](emr-troubleshoot-error-errordetail.md). The `ErrorData` array within `ErrorDetail` returns the following information for this error code: **`instance-types`** The list of unsupported instance types. **`availability-zones`** The list of Availability Zones that your subnet resolves to. **`public-doc`** The public URL of the documentation for the error code. ## Steps to complete Perform the following steps to identify and fix the error: 1. Use the AWS CLI to retrieve the available instance types in an Availability Zone. To do this, you can use the `[ec2 describe-instance-type-offerings](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instance-type-offerings.html)` command to filter available instance types by location (AWS Region or Availability Zone). For example, the following command returns the instance types that are offered in the specified AZ, `us-east-2a`. ``` aws ec2 describe-instance-type-offerings --location-type "availability-zone" --filters Name=location,Values=us-east-2a --region us-east-2 --query "InstanceTypeOfferings[*].[InstanceType]" --output text | sort ``` To learn more about how to discover available instance types, see [Find an Amazon EC2 instance type](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-discovery.html). 1. After you determine the instance types that are available in the same Region and Availability Zone as the cluster, choose one of the following resolutions to continue: 1. Create a new cluster, and choose a subnet for the cluster that is in an Availability Zone where the instance type that you selected is available and supported by Amazon EMR. 1. Create a new cluster in the same Region and Amazon EC2 subnet as the cluster that failed, but with an instance type that is supported in that location by Amazon EMR. For a list of instance types and Regions that Amazon EMR supports, see [Supported instance types with Amazon EMR](emr-supported-instance-types.md). To compare the capabilities of the instance types, see [Amazon EC2 instance types](https://aws.amazon.com/ec2/instance-types).