# Ensure EMR Clusters Do Not Have Public IPs Assigned - Source: https://support.icompaas.com/support/solutions/articles/62000233361-ensure-emr-clusters-do-not-have-public-ips-assigned - Section: [Solutions](https://support.icompaas.com/support/solutions) › [AWS Checks New Version](https://support.icompaas.com/support/solutions/62000112673) › [AWS New Checks](https://support.icompaas.com/support/solutions/folders/62000169206) - Last updated: 2026-05-29 - Publisher: iCompaas, Inc. (https://www.icompaas.com) **Profile Applicability:** - **Level 2** **Description:** Amazon EMR (Elastic MapReduce) clusters should be launched without assigning public IP addresses to their instances to minimize the attack surface and exposure to the public internet. Instead, EMR clusters should operate within a private subnet and leverage NAT Gateways or VPC Endpoints for secure communication with AWS services. Ensuring that EMR cluster instances do not have public IPs reduces the risk of unauthorized access and data breaches ### **Rationale:** - Enhanced Security: Prevents direct access to EMR cluster instances from the internet. - Minimized Attack Surface: Reduces the chances of brute-force attacks, unauthorized access, and data leaks. - Compliance: Meets security and compliance standards that mandate private network configurations. - Controlled Network Access: Encourages the use of bastion hosts, VPNs, or AWS PrivateLink for secure access. ### **Impact:** - **Pros:** - Improved security posture by isolating EMR instances from the public internet. - Reduced risk of data breaches and external attacks. - Compliance with strict security policies and standards. - **Cons:** - May require additional setup for private access via NAT Gateways or VPNs. - Direct SSH or web-based access to cluster instances is restricted unless accessed through a bastion host. ### **Default Value:** - By default, EMR clusters may assign public IPs if launched in a public subnet or if the assignPublicIp setting is enabled. - Public IPs are disabled if the cluster is launched in a private subnet without Auto-assign Public IP enabled. ### **Pre-Requisite:** - **IAM Permissions:** - elasticmapreduce:DescribeCluster - elasticmapreduce:ListClusters - elasticmapreduce:RunJobFlow - ec2:DescribeInstances - Ensure the VPC has appropriate private subnets and NAT Gateways configured for EMR communication with AWS services. ### **Remediation:** #### **Test Plan:** ##### **Using AWS Console:** 1. Sign in to the [AWS Management Console](https://console.aws.amazon.com/). 2. Navigate to EMR Dashboard → Clusters. ![](https://support.icompaas.com/assets/kb/d27aa0ad4b8c9e71.png) 3. For each EMR Cluster: - Click on the Cluster ID to open its details. - Under Hardware, check the Instance Groups or Instance Fleets. ![](https://support.icompaas.com/assets/kb/b00081382effc53f.png) - Review the EC2 instances attached to the cluster. - Verify if the Public IP column is populated. - If any instances have a Public IP, the cluster is non-compliant. ##### **Using AWS CLI:** **List all active EMR clusters:** aws emr list-clusters --active --query 'Clusters\[\*\].Id' --output text **Check instance details for each cluster:** aws emr list-instances --cluster-id --query 'Instances\[\*\].{ID:Ec2InstanceId,PublicIP:PublicIpAddress}' -- **Expected Output (Pass):** ------------------------ | ListInstances | +----------------------+ | ID | PublicIP | | i-1234567890 | None | | i-0987654321 | None | +----------------------+ Fail Output (Public IP assigned): ------------------------ | ListInstances | +----------------------+ | ID | PublicIP | | i-1234567890 | 54.23.11.45| +----------------------+ ### **Implementation Steps:** #### **Using AWS Console:** 1. Sign in to the [AWS Console](https://console.aws.amazon.com/). 2. Navigate to EMR Dashboard → Create Cluster. 3. Under Network, select a VPC and ensure: - Subnet: Choose a Private Subnet (without Auto-assign Public IP enabled). - Auto-assign Public IP: Set to Disabled. 4. Proceed with configuring other cluster settings. 5. Click Create Cluster. #### **Using AWS CLI:** **Launch an EMR Cluster in a Private Subnet (No Public IP):** aws emr create-cluster \\ --name "Private EMR Cluster" \\ --release-label emr-6.12.0 \\ --applications Name=Hadoop Name=Spark \\ --ec2-attributes SubnetId=,EmrManagedMasterSecurityGroup=,EmrManagedSlaveSecurityGroup= \\ --instance-type m5.xlarge \\ --instance-count 3 \\ --use-default-roles \\ --no-termination-protected \\ --region us-east-1 **Verify the Cluster Instances: ** aws emr list-instances --cluster-id --query 'Instances\[\*\].{ID:Ec2InstanceId,PublicIP:PublicIpAddress}' --output table ### **Backout Plan:** **If disabling public IPs causes issues:** 1. Re-launch the EMR cluster in a public subnet with Auto-assign Public IP enabled. **Using AWS CLI:** aws emr create-cluster \\ --name "Public EMR Cluster" \\ --release-label emr-6.12.0 \\ --applications Name=Hadoop Name=Spark \\ --ec2-attributes SubnetId=,EmrManagedMasterSecurityGroup=,EmrManagedSlaveSecurityGroup= \\ --instance-type m5.xlarge \\ --instance-count 3 \\ --use-default-roles \\ --region us-east-1 2. Consider adding a Bastion Host for secure access to private EMR clusters if public IPs are not an option. ### **References:** 1. [Amazon EMR Documentation](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-iam-roles.html) 2. [AWS EMR Best Practices](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-vpc.html) 3. [AWS CLI EMR Commands](https://docs.aws.amazon.com/cli/latest/reference/emr/index.html) ### **CIS Controls:**

Version	Control ID	Control Description	IG1	IG2	IG3
v8	4.2	Securely Manage Network Boundaries – Ensure sensitive resources are not exposed to public networks.	●	●	●
v8	13.1	Implement Network Segmentation – Segment resources to reduce exposure and improve security.	●	●	●
v7	9.4	Limit Network Exposure – Ensure instances are not directly accessible from public networks.	●	●	●

## Related compliance guidance - [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them. - [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.