AWS emr documentation change
Summary
Minor wording changes to improve clarity and conciseness in pre-initialized capacity documentation (e.g., 'recommend' to 'suggest', 'you can set' to 'set', removal of redundant pronouns)
Security assessment
Changes are purely editorial improvements to documentation phrasing and instructions. No security vulnerabilities, configurations, or features are mentioned or modified. The updates focus on operational guidance for resource optimization and cost management.
Diff
diff --git a/emr/latest/EMR-Serverless-UserGuide/pre-init-capacity.md b/emr/latest/EMR-Serverless-UserGuide/pre-init-capacity.md index e9bb63d0b..ef9c1b5db 100644 --- a//emr/latest/EMR-Serverless-UserGuide/pre-init-capacity.md +++ b//emr/latest/EMR-Serverless-UserGuide/pre-init-capacity.md @@ -9 +9 @@ Customizing pre-initialized capacity for Spark and Hive -EMR Serverless provides an optional feature that keeps driver and workers pre-initialized and ready to respond in seconds. This effectively creates a warm pool of workers for an application. This feature is called _pre-initialized capacity_. To configure this feature, you can set the `initialCapacity` parameter of an application to the number of workers you want to pre-initialize. With pre-initialized worker capacity, jobs start immediately. This is ideal when you want to implement iterative applications and time-sensitive jobs. +EMR Serverless provides an optional feature that keeps driver and workers pre-initialized and ready to respond in seconds. This effectively creates a warm pool of workers for an application. This feature is called _pre-initialized capacity_. To configure this feature, set the `initialCapacity` parameter of an application to the number of workers you want to pre-initialize. With pre-initialized worker capacity, jobs start immediately. This is ideal when you want to implement iterative applications and time-sensitive jobs. @@ -11 +11 @@ EMR Serverless provides an optional feature that keeps driver and workers pre-in -Pre-initialized capacity keeps a warm pool of workers ready for jobs and sessions to startup in seconds. You will be paying for provisioned pre-initialized workers even when the application is idle, hence we recommend enabling it for use cases that benefit from the fast start-up time and sizing it for optimal utilization of resources. EMR Serverless applications automatically shut down when idle. We recommend keeping this feature on when using pre-initialized workers to avoid unexpected charges. +Pre-initialized capacity keeps a warm pool of workers ready for jobs and sessions to startup in seconds. You will be paying for provisioned pre-initialized workers even when the application is idle, hence we suggest enabling it for use cases that benefit from the fast start-up time and sizing it for optimal utilization of resources. EMR Serverless applications automatically shut down when idle. We suggest keeping this feature on when using pre-initialized workers to avoid unexpected charges. @@ -17 +17 @@ Pre-initialized capacity is available and ready to use when the application has -You can configure the application to release pre-initialized capacity if it isn't used for a certain period of time, with a default of 15 minutes. A stopped application starts automatically when you submit a new job. You can set these automatic start and stop configurations when you create the application, or you can change them when the application is in a `CREATED` or `STOPPED` state. +You can configure the application to release pre-initialized capacity if it isn't used for a certain period of time, with a default of 15 minutes. A stopped application starts automatically when you submit a new job. You can set these automatic start and stop configurations when you create the application, or change them when the application is in a `CREATED` or `STOPPED` state. @@ -19 +19 @@ You can configure the application to release pre-initialized capacity if it isn' -You can change the `InitialCapacity` counts, and specify compute configurations such as CPU, memory, and disk, for each worker. Because you can't make partial modifications, you should specify all compute configurations when you change values. You can only change configurations when the application is in the `CREATED` or `STOPPED` state. +You can change the `InitialCapacity` counts, and specify compute configurations such as CPU, memory, and disk, for each worker. Because you can't make partial modifications, specify all compute configurations when you change values. You can only change configurations when the application is in the `CREATED` or `STOPPED` state. @@ -23 +23 @@ You can change the `InitialCapacity` counts, and specify compute configurations -To optimize your application’s use of resources, we recommend aligning your container sizes with your pre-initialized capacity worker sizes. For example, if you configure your Spark executor size to 2 CPUs and your memory to 8 GB, but your pre-initialized capacity worker size is 4 CPUs with 16 GB of memory, then the Spark executors only use half of the workers’ resources when they are assigned to this job. +To optimize your application’s use of resources, we suggest aligning your container sizes with your pre-initialized capacity worker sizes. For example, if you configure your Spark executor size to 2 CPUs and your memory to 8 GB, but your pre-initialized capacity worker size is 4 CPUs with 16 GB of memory, then the Spark executors only use half of the workers’ resources when they are assigned to this job. @@ -27 +27 @@ To optimize your application’s use of resources, we recommend aligning your co -You can further customize pre-initialized capacity for workloads that run on specific big data frameworks. For example, when a workload runs on Apache Spark, you can specify how many workers start as drivers and how many start as executors. Similarly, when you use Apache Hive, you can specify how many workers start as Hive drivers, and how many should run Tez tasks. +You can further customize pre-initialized capacity for workloads that run on specific big data frameworks. For example, when a workload runs on Apache Spark, specify how many workers start as drivers and how many start as executors. Similarly, when you use Apache Hive, specify how many workers start as Hive drivers, and how many should run Tez tasks.