AWS emr documentation change
Summary
Minor editorial changes including wording adjustments (e.g., 'see' to 'refer to', 'you can' to imperative verbs), updated subnet planning guidance, and clarification about security group restrictions blocking public internet access.
Security assessment
The changes primarily improve clarity and consistency in documentation. While there is a mention of security groups blocking public internet access (0.0.0.0/0 and ::/0 ranges), this is a restatement of existing security controls rather than a new security fix or feature addition. No explicit vulnerability or incident response is referenced.
Diff
diff --git a/emr/latest/EMR-Serverless-UserGuide/vpc-access.md b/emr/latest/EMR-Serverless-UserGuide/vpc-access.md index ba26dde95..e84dd2a16 100644 --- a//emr/latest/EMR-Serverless-UserGuide/vpc-access.md +++ b//emr/latest/EMR-Serverless-UserGuide/vpc-access.md @@ -13 +13 @@ You can configure EMR Serverless applications to connect to your data stores wit -You must configure VPC access if you want to use an external Hive metastore database for your application. For information about how to configure an external Hive metastore, see [Metastore configuration](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/metastore-config.html). +You must configure VPC access if you want to use an external Hive metastore database for your application. For information about how to configure an external Hive metastore, refer to [Metastore configuration](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/metastore-config.html). @@ -17 +17 @@ You must configure VPC access if you want to use an external Hive metastore data -On the **Create application** page, you can choose custom settings and specify the VPC, subnets and security groups that EMR Serverless applications can use. +On the **Create application** page, choose custom settings and specify the VPC, subnets and security groups that EMR Serverless applications can use. @@ -31 +31 @@ For private subnets: - * For outbound connectivity to the internet, if needed, configure outbound routes using a NAT Gateway. To configure a NAT Gateway, see [NAT gateways](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html#nat-gateway-working-with). + * For outbound connectivity to the internet, if needed, configure outbound routes using a NAT Gateway. To configure a NAT Gateway, refer to [NAT gateways](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html#nat-gateway-working-with). @@ -33 +33 @@ For private subnets: - * For Amazon S3 connectivity, configure either a NAT Gateway or a VPC endpoint. To configure an S3 VPC endpoint, see [Create a gateway endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html#create-gateway-endpoint-s3). + * For Amazon S3 connectivity, configure either a NAT Gateway or a VPC endpoint. To configure an S3 VPC endpoint, refer to [Create a gateway endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html#create-gateway-endpoint-s3). @@ -35 +35 @@ For private subnets: - * If you configure an S3 VPC endpoint and you attach an endpoint policy to control access, you must follow the instructions in [Logging for EMR Serverless with managed storage](logging.html#jobs-log-storage-managed-storage) to provide permissions for EMR Serverless to store and serve application logs. + * If you configure an S3 VPC endpoint and you attach an endpoint policy to control access, follow the instructions in [Logging for EMR Serverless with managed storage](logging.html#jobs-log-storage-managed-storage) to provide permissions for EMR Serverless to store and serve application logs. @@ -37 +37 @@ For private subnets: - * For connectivity to other AWS services outside the VPC, such as to Amazon DynamoDB, configure either VPC endpoints or a NAT gateway. To configure VPC endpoints for AWS services, see [Work with VPC endpoints](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html#working-with-privatelink). + * For connectivity to other AWS services outside the VPC, such as to Amazon DynamoDB, configure either VPC endpoints or a NAT gateway. To configure VPC endpoints for AWS services, refer to [Work with VPC endpoints](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html#working-with-privatelink). @@ -44 +44 @@ For private subnets: -When you set up an Amazon EMR Serverless application in a private subnet, we recommend that you also set up VPC endpoints for Amazon S3. If your EMR Serverless application is in a private subnet without VPC endpoints for Amazon S3, you could incur additional NAT gateway charges that are associated with S3 traffic. This is because the traffic between your EMR application and Amazon S3 will not stay within your VPC when VPC endpoints aren't configured. +When you set up an Amazon EMR Serverless application in a private subnet, we suggest that you also set up VPC endpoints for Amazon S3. If your EMR Serverless application is in a private subnet without VPC endpoints for Amazon S3, you incur additional NAT gateway charges that are associated with S3 traffic. This is because the traffic between your EMR application and Amazon S3 will not stay within your VPC when VPC endpoints aren't configured. @@ -61 +61 @@ When you use AWS Config, EMR Serverless creates an elastic network interface ite -We recommend that you select multiple subnets across multiple Availability Zones. This is because the subnets that you choose determine the Availability Zones available for an EMR Serverless application to launch. Each worker consumes an IP address on the subnet where it is launched. Please ensure that the specified subnets have sufficient IP addresses for the number of workers you plan to launch. For more information on subnet planning, see Best practices for subnet planning. +We suggest that you select multiple subnets across multiple Availability Zones. This is because the subnets that you choose determine the Availability Zones available for an EMR Serverless application to launch. Each worker consumes an IP address on the subnet where it is launched. Please ensure that the specified subnets have sufficient IP addresses for the number of workers you plan to launch. For more information on subnet planning, refer to Best practices for subnet planning. @@ -78 +78 @@ Choose one or more security groups that can communicate with your data stores. T -We recommend that you create a separate security group for EMR Serverless applications. EMR Serverless will not allow you to **Create** /**Update** /**Start application** if security groups have ports open to the public internet on **0.0.0.0/0** or the **::/0** range. This provides enhanced security, isolation, and makes managing network rules more efficient. For example, this blocks unexpected traffic to workers with public IP addresses. To communicate with Amazon Redshift clusters, for instance, you can define the traffic rules between Redshift and EMR Serverless security groups, as demonstrated in the example below. +We suggest that you create a separate security group for EMR Serverless applications. EMR Serverless does not allow you to **Create** /**Update** /**Start application** if security groups have ports open to the public internet on **0.0.0.0/0** or the **::/0** range. This provides enhanced security, isolation, and makes managing network rules more efficient. For example, this blocks unexpected traffic to workers with public IP addresses. To communicate with Amazon Redshift clusters, for instance, define the traffic rules between Redshift and EMR Serverless security groups, as demonstrated in the example in the following section. @@ -88 +88 @@ All TCP | TCP | 5439 | `emr-serverless-security-group` - 2. Add a rule for outbound traffic from one of the EMR Serverless security groups. You can do this in one of two ways. First, you can open outbound traffic to all ports. + 2. Add a rule for outbound traffic from one of the EMR Serverless security groups. Do this in one of two ways. First, open outbound traffic to all ports. @@ -107 +107 @@ You can change the network configuration for an existing EMR Serverless applicat -### View job run details +### Access job run details @@ -109 +109 @@ You can change the network configuration for an existing EMR Serverless applicat -On the **Job run detail** page, you can view the subnet used by your job for a specific run. Note that a job runs only in one subnet selected from the specified subnets. +On the **Job run detail** page, access the subnet used by your job for a specific run. Note that a job runs only in one subnet selected from the specified subnets. @@ -115 +115 @@ AWS resources are created in a subnet which is a subset of available IP addresse -The subnets should be designed keeping in mind your EMR Serverless application scaling limits. For example, if you have an application requesting 4 vCpu workers and can scale up to 4,000 vCpu, then your application will require at most 1,000 workers for a total of 1,000 network interfaces. We recommend that you create subnets across multiple Availability Zones. This allows EMR Serverless to retry your job or provision pre-initialized capacity in a different Availability Zone in an unlikely event when an Availability Zone fails. Therefore, each subnet in at least two Availability Zones should have more than 1,000 available IP addresses. +The subnets should be designed keeping in mind your EMR Serverless application scaling limits. For example, if you have an application requesting 4 vCpu workers and can scale up to 4,000 vCpu, then your application requires at most 1,000 workers for a total of 1,000 network interfaces. We suggest that you create subnets across multiple Availability Zones. This allows EMR Serverless to retry your job or provision pre-initialized capacity in a different Availability Zone in an unlikely event when an Availability Zone fails. Therefore, each subnet in at least two Availability Zones should have more than 1,000 available IP addresses. @@ -117 +117 @@ The subnets should be designed keeping in mind your EMR Serverless application s -You need subnets with mask size lower than or equal to 22 to provision 1,000 network interfaces. Any mask greater than 22 will not meet the requirement. For example, a subnet mask of /23 provides 512 IP addresses, while a mask of /22 provides 1024 and a mask of /21 provides 2048 IP addresses. Below is an example of 4 subnets with /22 mask in a VPC of /16 netmask that can be allocated to different Availability Zones. There is a difference of five between available and usable IP addresses because first four IP addresses and last IP address in each subnet is reserved by AWS. +You need subnets with mask size lower than or equal to 22 to provision 1,000 network interfaces. Any mask greater than 22 does not meet the requirement. For example, a subnet mask of /23 provides 512 IP addresses, while a mask of /22 provides 1024 and a mask of /21 provides 2048 IP addresses. Below is an example of 4 subnets with /22 mask in a VPC of /16 netmask that can be allocated to different Availability Zones. There is a difference of five between available and usable IP addresses because first four IP addresses and last IP address in each subnet is reserved by AWS. @@ -126 +126 @@ Subnet ID | Subnet Address | Subnet Mask | IP Address Range | Available IP Addre -You should evaluate if your workload is best suited for larger worker sizes. Using larger worker sizes requires fewer network interfaces. For example, using 16vCpu workers with an application scaling limit of 4,000 vCpu will require at most 250 workers for a total of 250 available IP addresses to provision network interfaces. You need subnets in multiple Availability Zones with mask size lower than or equal to 24 to provision 250 network interfaces. Any mask size greater than 24 offers less than 250 IP addresses. +You should evaluate if your workload is best suited for larger worker sizes. Using larger worker sizes requires fewer network interfaces. For example, using 16vCpu workers with an application scaling limit of 4,000 vCpu requires at most 250 workers for a total of 250 available IP addresses to provision network interfaces. You need subnets in multiple Availability Zones with mask size lower than or equal to 24 to provision 250 network interfaces. Any mask size greater than 24 offers less than 250 IP addresses. @@ -128 +128 @@ You should evaluate if your workload is best suited for larger worker sizes. Usi -If you share subnets across multiple applications, each subnet should be designed keeping in mind collective scaling limits of all your applications. For example, if you have 3 applications requesting 4 vCpu workers and each can scale up to 4000 vCpu with 12,000 vCpu account-level service based quota, each subnet will require 3000 available IP addresses. If the VPC that you want to use doesn't have a sufficient number of IP addresses, try to increase the number of available IP addresses. You can do this by associating additional Classless Inter-Domain Routing (CIDR) blocks with your VPC. For more information, see [Associate additional IPv4 CIDR blocks with your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#add-ipv4-cidr) in the _Amazon VPC User Guide_. +If you share subnets across multiple applications, each subnet should be designed keeping in mind collective scaling limits of all your applications. For example, if you have 3 applications requesting 4 vCpu workers and each can scale up to 4000 vCpu with 12,000 vCpu account-level service based quota, each subnet requires 3000 available IP addresses. If the VPC that you want to use doesn't have a sufficient number of IP addresses, try to increase the number of available IP addresses. You can do this by associating additional Classless Inter-Domain Routing (CIDR) blocks with your VPC. For more information, refer to [Associate additional IPv4 CIDR blocks with your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#add-ipv4-cidr) in the _Amazon VPC User Guide_.