# Auto Scaling your Elastic Beanstalk environment instances Auto Scaling group This topic describes how you can customize the Auto Scaling features to manage your Elastic Beanstalk environment’s workload. You can configure Auto Scaling for your environment using the [Elastic Beanstalk console](environments-cfg-autoscaling-configuration-approaches.md#environments-cfg-autoscaling-console), [namespace configuration options](environments-cfg-autoscaling-configuration-approaches.md#environments-cfg-autoscaling-namespace), the [Amazon CLI](environments-cfg-autoscaling-configuration-approaches.md#environments-cfg-autoscaling-aws-cli), or the [EB CLI](environments-cfg-autoscaling-configuration-approaches.md#environments-cfg-autoscaling-ebcli). **Load-balanced or single instance environments** Your Amazon Elastic Beanstalk environment includes an *Auto Scaling group* that manages the [Amazon EC2 instances](using-features.managing.ec2.md) in your environment. In a single-instance environment, the Auto Scaling group ensures that there is always one instance running. In a load-balanced environment, you configure the group with a range of instances to run, and Auto Scaling adds or removes instances as needed, based on load. **EC2 Instance configuration** The Auto Scaling group also applies your configuration choices to provision and manage the EC2 instances in your environment. You can [modify the EC2 configuration](using-features.managing.ec2.md) to change the instance type, key pair, Amazon Elastic Block Store (Amazon EBS) storage, and other settings that can only be configured when you launch an instance. **On-Demand and Spot Instances** As an option, Elastic Beanstalk can include [Spot Instances](environments-cfg-autoscaling-spot.md) in your environment and manage them in combination with On-Demand instances. You can configure Amazon EC2 Auto Scaling to monitor and automatically respond to changes that affect the availability of your Spot Instances by enabling [Capacity Rebalancing](https://docs.amazonaws.cn/autoscaling/ec2/userguide/capacity-rebalance.html). You can also configure the [Spot allocation strategy](environments-cfg-autoscaling-spot-allocation-strategy.md) that the Auto Scaling service uses to provision Spot Instances to your environment. **Required permissions when enabling Spot Instances** Enabling Spot Instance requests requires using Amazon EC2 launch templates. When you configure this feature during environment creation or updates, Elastic Beanstalk attempts to configure your environment to use Amazon EC2 launch templates (if the environment isn't using them already). In this case, if your user policy lacks the necessary permissions, environment creation or updates might fail. Therefore, we recommend that you use our managed user policy or add the required permissions to your custom policies. For details about the required permissions, see [Required permissions for launch templates](environments-cfg-autoscaling-launch-templates.md#environments-cfg-autoscaling-launch-templates-permissions). **Auto Scaling triggers** The Auto Scaling group uses two Amazon CloudWatch alarms to trigger scaling operations. The default triggers scale when the average outbound network traffic from each instance is higher than 6 MiB or lower than 2 MiB over a period of five minutes. To use Auto Scaling effectively, [configure triggers](environments-cfg-autoscaling-triggers.md) that are appropriate for your application, instance type, and service requirements. You can scale based on several statistics including latency, disk I/O, CPU utilization, and request count. **Schedule Auto Scaling actions** To optimize your environment's use of Amazon EC2 instances through predictable periods of peak traffic, [configure your Auto Scaling group to change its instance count on a schedule](environments-cfg-autoscaling-scheduledactions.md). You can schedule changes to your group's configuration that recur daily or weekly, or schedule one-time changes to prepare for marketing events that will drive a lot of traffic to your site. **Auto Scaling health check** Auto Scaling monitors the health of each Amazon EC2 instance that it launches. If any instance terminates unexpectedly, Auto Scaling detects the termination and launches a replacement instance. To configure the group to use the load balancer's health check mechanism, see [Auto Scaling health check setting for your Elastic Beanstalk environment](environmentconfig-autoscaling-healthchecktype.md). **Topics** + [ # Migrating your Elastic Beanstalk environment to launch templates ](environments-cfg-autoscaling-launch-templates.md) + [ # Spot Instance support for your Elastic Beanstalk environment ](environments-cfg-autoscaling-spot.md) + [ # Auto Scaling triggers for your Elastic Beanstalk environment ](environments-cfg-autoscaling-triggers.md) + [ # Scheduled Auto Scaling actions for your Elastic Beanstalk environments ](environments-cfg-autoscaling-scheduledactions.md) + [ # Auto Scaling health check setting for your Elastic Beanstalk environment ](environmentconfig-autoscaling-healthchecktype.md) # Migrating your Elastic Beanstalk environment to launch templates Launch templates As of October 1, 2024, Amazon EC2 Auto Scaling no longer supports launch configurations for new accounts. Accounts created prior to that date might have launch configurations. We recommend migrating to **launch templates** for the following benefits: + Improved availability for your applications + Better optimization of workloads in your Auto Scaling groups + Access to the latest EC2 and Auto Scaling features For more information, see [Auto Scaling launch configurations](https://docs.amazonaws.cn/autoscaling/ec2/userguide/launch-configurations.html) in the *Amazon EC2 Auto Scaling User Guide*. ## Option settings for launch templates onceOption settings To migrate your environment from launch configurations to launch templates, set one of the following configuration options: + `RootVolumeType` option set to **gp3**. You can set this option with the [console](using-features.managing.ec2.console.md) or the [namespace](using-features.managing.ec2.namespace.md) . + `BlockDeviceMappings` option contains **gp3**. You can set this option with the [console](using-features.managing.ec2.console.md) or the [namespace](using-features.managing.ec2.namespace.md). + `DisableIMDSv1` option set to **true**. We recommend that you set this option using the [namespace](using-features.managing.ec2.namespace.md). + `EnableSpot` option set to **true**. For more information, see [Enabling Spot Instances](environments-cfg-autoscaling-enable-spot.md). **Important** After an environment begins using launch templates, Elastic Beanstalk does not revert to launch configurations, even if you remove the configuration options that originally triggered the use of launch templates. ## Confirm whether your environment has launch configurations or launch templates Check for launch configuration You can confirm if your environment already uses launch templates, or if it's using launch configurations, by inspecting the CloudFormation stack template. **To inspect your environment's CloudFormation stack template** 1. Open the Amazon CloudFormation console at [https://console.amazonaws.cn/cloudformation](https://console.amazonaws.cn/cloudformation/). 1. On the navigation bar at the top of the screen, choose the Amazon Region where you created the environment. 1. On the **Stacks** page of the CloudFormation console, inspect the **Description** column. Locate and select the stack for the Elastic Beanstalk environment. CloudFormation displays the stack details for the environment. 1. In **Stack details** select the **Template** tab. Using your browser's page search, you can search the template text for *launchtemplate* or *launchconfiguration*. For more information, see [View stack information](https://docs.amazonaws.cn/AWSCloudFormation/latest/UserGuide/cfn-console-view-stack-data-resources.html) in the *Amazon CloudFormation User Guide*. ## Required permissions for launch templates Required permissions The default Elastic Beanstalk managed service role policy [AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy](https://docs.amazonaws.cn/aws-managed-policy/latest/reference/AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy.html) provides the required permissions to create and manage launch templates. Elastic Beanstalk must manage launch templates to complete many environment operations, including creating environments. If you attach custom policies to an Elastic Beanstalk service role, verify that the service role includes the following permissions for creating launch templates. These permissions enable Elastic Beanstalk to successfully create and update environments in your account: **Required permissions for Amazon EC2 launch templates** + `ec2:RunInstances` + `ec2:CreateLaunchTemplate` + `ec2:CreateLaunchTemplateVersions` + `ec2:DeleteLaunchTemplate` + `ec2:DeleteLaunchTemplateVersions` + `ec2:DescribeLaunchTemplate` + `ec2:DescribeLaunchTemplateVersions` The following example IAM policy includes these permissions. ``` { "Statement": [ { "Effect": "Allow", "Action": [ "ec2:RunInstances", "ec2:CreateLaunchTemplate", "ec2:CreateLaunchTemplateVersions", "ec2:DeleteLaunchTemplate", "ec2:DeleteLaunchTemplateVersions", "ec2:DescribeLaunchTemplate", "ec2:DescribeLaunchTemplateVersions" ], "Resource": [ "*" ] } ] } ``` For more information, see [Managing Elastic Beanstalk service roles](iam-servicerole.md) and [Managing Elastic Beanstalk user policies](AWSHowTo.iam.managed-policies.md). ## More about launch templates More information To learn more about launch templates, see [Auto Scaling launch templates ](https://docs.amazonaws.cn/autoscaling/ec2/userguide/launch-templates.html) in the *Amazon EC2 Auto Scaling User Guide*. To learn more about the Amazon transition to launch templates and the benefits they offer, see [ Amazon EC2 Auto Scaling will no longer add support for new EC2 features to Launch Configurations](https://amazonaws-china.com/blogs/compute/amazon-ec2-auto-scaling-will-no-longer-add-support-for-new-ec2-features-to-launch-configurations/) in the *Amazon Compute Blog*. **Important** You don't need to follow the procedure referenced in this blog article to transition an older environment to launch templates. To migrate an existing Elastic Beanstalk environment to launch templates, set one of the options listed in [Option settings for launch templates](#environments-cfg-autoscaling-launch-templates-options). # Spot Instance support for your Elastic Beanstalk environment Spot Instance support This topic describes the configuration options that are available for you to manage the capacity and load balancing of Spot Instances in your Elastic Beanstalk environment. It also provides details and examples for the methods you can use to configure these options. You can use the [Elastic Beanstalk console](environments-cfg-autoscaling-configuration-approaches.md#environments-cfg-autoscaling-console), [namespace configuration options](environments-cfg-autoscaling-configuration-approaches.md#environments-cfg-autoscaling-namespace), the [Amazon CLI](environments-cfg-autoscaling-configuration-approaches.md#environments-cfg-autoscaling-aws-cli), or the [EB CLI](environments-cfg-autoscaling-configuration-approaches.md#environments-cfg-autoscaling-ebcli) to manage the configuration options. **Minimize Spot instance interruptions with Capacity Rebalancing** To help minimize the impact of Spot Instance interruptions to your application, you can enable the Capacity Rebalancing option included with Amazon EC2 Auto Scaling. **Important** Demand for Spot Instances can vary significantly from moment to moment, and the availability of Spot Instances can also vary significantly depending on how many unused Amazon EC2 instances are available. It's always possible that your Spot Instance might be interrupted. When you enable Capacity Rebalancing, EC2 automatically attempts to replace Spot Instances in an Auto Scaling group before they are interrupted. To enable this feature use the Elastic Beanstalk console to [configure the Auto Scaling group](environments-cfg-autoscaling-configuration-approaches.md#environments-cfg-autoscaling-console). Alternatively, you can set the Elastic Beanstalk `EnableCapacityRebalancing` [configuration option](environments-cfg-autoscaling-configuration-approaches.md#environments-cfg-autoscaling-namespace) to `true` in the [aws:autoscaling:asg](command-options-general.md#command-options-general-autoscalingasg) namespace. For more information, see [Capacity Rebalancing](https://docs.amazonaws.cn/autoscaling/ec2/userguide/capacity-rebalance.html) in the *Amazon EC2 Auto Scaling User Guide* and [Spot Instance Interruptions](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/spot-interruptions.html) in the *Amazon EC2 User Guide*. **Older Instance Types and Spot Instance Support** Some older Amazon accounts might provide Elastic Beanstalk with default instance types that don't support Spot Instances. If you enable Spot Instance requests and you see the error None of the instance types you specified supports Spot, update your configuration with instance types that support Spot Instances. To choose Spot Instance types, use the [Spot Instance Advisor](https://aws.amazon.com/ec2/spot/instance-advisor/). **Topics** + [ # Enabling Spot Instances for your environment ](environments-cfg-autoscaling-enable-spot.md) + [ # Spot Instance allocation strategy ](environments-cfg-autoscaling-spot-allocation-strategy.md) + [ # Managing On-Demand instances and Spot instances ](environments-cfg-autoscaling-spot-and-demand.md) + [ # Capacity configuration for your Elastic Beanstalk environment ](environments-cfg-autoscaling-configuration-approaches.md) # Enabling Spot Instances for your environment Enabling Spot Instances To take advantage of Amazon EC2 Spot Instances, set the `EnableSpot` option for your environment. Your environment's Auto Scaling group then combines Amazon EC2 purchase options and maintains a mix of On-Demand and Spot Instances. You can use the [Elastic Beanstalk console](environments-cfg-autoscaling-configuration-approaches.md#environments-cfg-autoscaling-console), [namespace configuration options](environments-cfg-autoscaling-configuration-approaches.md#environments-cfg-autoscaling-namespace), the [Amazon CLI](environments-cfg-autoscaling-configuration-approaches.md#environments-cfg-autoscaling-aws-cli), or the [EB CLI](environments-cfg-autoscaling-configuration-approaches.md#environments-cfg-autoscaling-ebcli) to enable Spot Instance requests for your environment. Before you enable Spot Instances for your environment, become familiar with the Auto Scaling, capacity, and load balancing configuration options that are available. Your application's requirements that are related to workload, impact of instance interruptions, and pricing, are all important considerations in your planning to enable Spot Instances. The topics that follow provide details about the Auto Scaling and capacity management options and how their combined use affects your environment. There are procedures and example configurations to inform and guide you about the various options and how to configure them. We also offer tools and features to help you manage your configuration and respond to events. You can schedule automated changes to your configuration based on predictable periods of traffic, configure triggers to respond to factors such as traffic volume, and configure Auto Scaling monitoring and health checks. For more detailed information about Spot Instances, including explanation of key concepts and best practices, see [Spot Instances](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/using-spot-instances.html) in the *Amazon EC2 User Guide*. **Important** The `EnableSpot` option setting can cause Elastic Beanstalk to migrate an existing environment with launch configurations to launch templates. Doing so requires the necessary permissions to manage launch templates. These permissions are included in our managed policy. If you use custom policies instead of our managed policies, environment creation or updates might fail when you update your environment configuration. For more information and other considerations, see [Migrating your Elastic Beanstalk environment to launch templates](environments-cfg-autoscaling-launch-templates.md). # Spot Instance allocation strategy Spot allocation strategy You can select any one of the allocation strategies listed in this topic for your Elastic Beanstalk environment. Use the [Elastic Beanstalk console](environments-cfg-autoscaling-configuration-approaches.md#environments-cfg-autoscaling-console), [namespace configuration options](environments-cfg-autoscaling-configuration-approaches.md#environments-cfg-autoscaling-namespace), or the [Amazon CLI](environments-cfg-autoscaling-configuration-approaches.md#environments-cfg-autoscaling-aws-cli), to set and configure Spot Instance allocation strategy and related attributes for your environment. Amazon EC2 applies an *allocation strategy* to manage and provision Spot instances for your environment. Each allocation strategy optimizes the allocated instances based on how it’s defined to handle available capacity, price, and selection of instance types. Amazon EC2 Auto Scaling provides the following allocation strategies for Spot Instances. + **Capacity optimized** (default) + Requests Spot Instances from the pool, with *optimal capacity* for the number of instances that are launching. + This strategy works well for workloads where the possibility of service disruption must be minimized. + **Price capacity optimized** + Requests Spot Instances from the pools that have the *lowest chance of interruption* and the *lowest possible price*. + This is the preferable choice for most Spot workloads. + **Capacity optimized prioritized** + Requests Spot Instances based on *capacity availability first*, while honoring your choice of *instance type prioritization* on a best-effort basis. You can provide a list of instance types, ordered by priority, when you configure Spot Instance options for Elastic Beanstalk. + This strategy is good for workloads that require minimal service disruption, and a specific instance type prioritization matters. + **Lowest price** + Requests Spot Instances from the *lowest priced pool* with available instances. + It's important to take precaution when using this strategy, since it only considers instance price and not capacity availability, which will result in high interruption rates. For more details about each allocation strategy, see [ Allocation strategies for multiple instance types](https://docs.amazonaws.cn/autoscaling/ec2/userguide/allocation-strategies.html) in the *Amazon EC2 Auto Scaling User Guide*. To help you understand which allocation strategy is best suited to meet your environment's requirements, see [ Choose the appropriate Spot allocation strategy ](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/ec2-fleet-allocation-strategy.html#ec2-fleet-allocation-use-cases) in the *Amazon EC2 User Guide*. # Managing On-Demand instances and Spot instances On-Demand and Spot instances You can launch and automatically scale a fleet of On-Demand Instances and Spot Instances within a single Auto Scaling group. The following options can be used in tandem to configure how the Auto Scaling service manages Spot Instances and On-Demand Instances in your environment. You can configure these options for your environment using the [Elastic Beanstalk console](environments-cfg-autoscaling-configuration-approaches.md#environments-cfg-autoscaling-console), [namespace configuration options](environments-cfg-autoscaling-configuration-approaches.md#environments-cfg-autoscaling-namespace), the [Amazon CLI](environments-cfg-autoscaling-configuration-approaches.md#environments-cfg-autoscaling-aws-cli), or the [EB CLI](environments-cfg-autoscaling-configuration-approaches.md#environments-cfg-autoscaling-ebcli). These options are part of the [aws:ec2:instances](command-options-general.md#command-options-general-ec2instances) namespace: + `EnableSpot` ‐ When set to `true` this setting enables Spot Instance requests for your environment. + `SpotFleetOnDemandBase` ‐ Sets the minimum number of On-Demand Instances that your Auto Scaling group provisions before considering Spot Instances as your environment scales up. + `SpotFleetOnDemandAboveBasePercentage` ‐ The percentage of On-Demand Instances as part of additional capacity that your Auto Scaling group provisions beyond the `SpotOnDemandBase` instances. The previously listed options correlate with the following options in the [aws:autoscaling:asg](command-options-general.md#command-options-general-autoscalingasg) namespace: + `MinSize` ‐ The minimum number of instances that you want in your Auto Scaling group. + `MaxSize` ‐ The maximum number of instances that you want in your Auto Scaling group. **Important** The `EnableSpot` option setting can cause Elastic Beanstalk to migrate an existing environment with launch configurations to launch templates. Doing so requires the necessary permissions to manage launch templates. These permissions are included in our managed policy. If you use custom policies instead of our managed policies, environment creation or updates might fail when you update your environment configuration. For more information and other considerations, see [Migrating your Elastic Beanstalk environment to launch templates](environments-cfg-autoscaling-launch-templates.md). ## Applying both sets of namespace options Applying both namespace options The following points describe how the combination of these option settings affects the scaling for your environment. + Only `MinSize` determines your environment’s initial capacity—the number of instances you want running at a minimum. + `SpotFleetOnDemandBase` doesn't affect initial capacity. When Spot is enabled, this option determines how many On-Demand Instances are provisioned before any Spot Instances are considered. + Consider when `SpotFleetOnDemandBase` is less than `MinSize`. You'll still get exactly `MinSize` instances as initial capacity. At least `SpotFleetOnDemandBase` of them must be On-Demand Instances. + Consider when `SpotFleetOnDemandBase` is greater than `MinSize`. As your environment scales out, you're guaranteed to get at least an additional amount of instances equal to the difference between the two values. In other words, you're guaranteed to get at least an additional `(SpotFleetOnDemandBase - MinSize)` instances that are On-Demand before satisfying the `SpotFleetOnDemandBase` requirement. **Single-instance environments** In production environments, Spot Instances are particularly useful as part of a scalable, load-balanced environment. We don't recommend using Spot in a single-instance environment. If Spot Instances aren't available, you might lose the entire capacity (a single instance) of your environment. You may still wish to use a Spot Instance in a single instance environment for development or testing. When you do, be sure to set both `SpotFleetOnDemandBase` and `SpotFleetOnDemandAboveBasePercentage` to zero. Any other settings result in an On-Demand Instance. ## Examples of scaling options settings Examples The following examples demonstrate different scenarios of setting the various scaling options. All examples assume a load-balanced environment with Spot Instance requests enabled. **Example 1: On-Demand and Spot as part of initial capacity** **Option settings** | **Option** | **Namespace** | **Value** | | --- | --- | --- | | `MinSize` | `aws:autoscaling:asg` | `10` | | `MaxSize` | `aws:autoscaling:asg` | `24` | | `SpotFleetOnDemandBase` | `aws:ec2:instances` | `4` | | `SpotFleetOnDemandAboveBasePercentage` | `aws:ec2:instances` | `50` | In this example, the environment starts with ten instances, of which seven are On-Demand (four base, and 50% of the six above base) and three are Spot. The environment can scale out up to 24 instances. As it scales out, the portion of On-Demand in the part of the fleet above the four base On-Demand instances is kept at 50%, up to a maximum of 24 instances overall, of which 14 are On-Demand (four base, and 50% of the 20 above base) and ten are Spot. **Example 2: All On-Demand initial capacity** **Option settings** | **Option** | **Namespace** | **Value** | | --- | --- | --- | | `MinSize` | `aws:autoscaling:asg` | `4` | | `MaxSize` | `aws:autoscaling:asg` | `24` | | `SpotFleetOnDemandBase` | `aws:ec2:instances` | `4` | | `SpotFleetOnDemandAboveBasePercentage` | `aws:ec2:instances` | `50` | In this example, the environment starts with four instances, all of which are On-Demand. The environment can scale out up to 24 instances. As it scales out, the portion of On-Demand in the part of the fleet above the four base On-Demand instances is kept at 50%, up to a maximum of 24 instances overall, of which 14 are On-Demand (four base, and 50% of the 20 above base) and ten are Spot. **Example 3: Additional On-Demand base beyond initial capacity** **Option settings** | **Option** | **Namespace** | **Value** | | --- | --- | --- | | `MinSize` | `aws:autoscaling:asg` | `3` | | `MaxSize` | `aws:autoscaling:asg` | `24` | | `SpotFleetOnDemandBase` | `aws:ec2:instances` | `4` | | `SpotFleetOnDemandAboveBasePercentage` | `aws:ec2:instances` | `50` | In this example, the environment starts with three instances, all of which are On-Demand. The environment can scale out up to 24 instances. The first additional instance above the initial three is On-Demand, to complete the four base On-Demand instances. As it scales out further, the portion of On-Demand in the part of the fleet above the four base On-Demand instances is kept at 50%, up to a maximum of 24 instances overall, of which 14 are On-Demand (four base, and 50% of the 20 above base) and ten are Spot. # Capacity configuration for your Elastic Beanstalk environment Configuration This topic describes the different approaches to configure Auto Scaling capacity for your Elastic Beanstalk environment. You can use the Elastic Beanstalk console, the EB CLI, the Amazon CLI, or namespace options. **Important** The `EnableSpot` option setting can cause Elastic Beanstalk to migrate an existing environment with launch configurations to launch templates. Doing so requires the necessary permissions to manage launch templates. These permissions are included in our managed policy. If you use custom policies instead of our managed policies, environment creation or updates might fail when you update your environment configuration. For more information and other considerations, see [Migrating your Elastic Beanstalk environment to launch templates](environments-cfg-autoscaling-launch-templates.md). ## Configuration using the console Console You can configure the capacity management of an Auto Scaling group by editing **Capacity** on the environment's **Configuration** page in the [Elastic Beanstalk console](environments-console.md). **To configure Auto Scaling group capacity in the Elastic Beanstalk console** 1. Open the [Elastic Beanstalk console](https://console.amazonaws.cn/elasticbeanstalk), and in the **Regions** list, select your Amazon Web Services Region. 1. In the navigation pane, choose **Environments**, and then choose the name of your environment from the list. 1. In the navigation pane, choose **Configuration**. 1. In the **Capacity** configuration category, choose **Edit**. 1. In the **Auto Scaling group** section, configure the following settings. + **Environment type** – Select **Load balanced**. + **Min instances** – The minimum number of EC2 instances that the group should contain at any time. The group starts with the minimum count and adds instances when the scale-up trigger condition is met. + **Max instances** – The maximum number of EC2 instances that the group should contain at any time. **Note** If you use rolling updates, be sure that the maximum instance count is higher than the [**Minimum instances in service** setting](using-features.rollingupdates.md#rollingupdates-configure) for rolling updates. + **Fleet composition** – The default is **On-Demand Instances**. To enable *Spot Instance* requests, select **Combined purchase options and instances**. **Important** The `EnableSpot` option setting can cause Elastic Beanstalk to migrate an existing environment with launch configurations to launch templates. Doing so requires the necessary permissions to manage launch templates. These permissions are included in our managed policy. If you use custom policies instead of our managed policies, environment creation or updates might fail when you update your environment configuration. For more information and other considerations, see [Migrating your Elastic Beanstalk environment to launch templates](environments-cfg-autoscaling-launch-templates.md). The following options are enabled if you select to enable *Spot Instance* requests: + **Spot allocation strategy** – Determines the method used to manage and provision the Spot Instances in your environment, based on available capacity, price, and selection of instance types. Select from *Capacity optimized* (default), *Price capacity optimized*, *Capacity optimized prioritized*, or *Lowest price*. For a description of each allocation strategy and more information, see [Spot Instance allocation strategy](environments-cfg-autoscaling-spot-allocation-strategy.md). + **Maximum spot price** – For recommendations about maximum price options for Spot Instances, see [Spot Instance pricing history](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/using-spot-instances-history.html) in the *Amazon EC2 User Guide*. + **On-Demand base** – The minimum number of On-Demand Instances that your Auto Scaling group provisions before considering Spot Instances as your environment scales out. + **On-Demand above base** – The percentage of On-Demand Instances as part of any additional capacity that your Auto Scaling group provisions beyond the On-Demand base instances. **Note** The options **On-Demand base** and **On-Demand above base** correlate to the **Min** and **Max** *Instances* options listed earlier. For more information about these options and examples, see [Spot Instance support for your Elastic Beanstalk environment](environments-cfg-autoscaling-spot.md). + **Capacity Rebalancing** – This option is only relevant when there is at least one Spot Instance in your Auto Scaling group. When this feature is enabled, EC2 automatically attempts to replace Spot Instances in the Auto Scaling group before they're interrupted, minimizing Spot Instance interruptions to your applications. For more information, see [Capacity Rebalancing](https://docs.amazonaws.cn/autoscaling/ec2/userguide/capacity-rebalance.html) in the *Amazon EC2 Auto Scaling User Guide* + **Architecture** – The processor architecture for your EC2 instances. The processor architecture determines the EC2 Instance types that become available in the next field. + **Instance types** – The types of Amazon EC2 instance launched to run your application. For details, see [Instance types](using-features.managing.ec2.console.md#using-features.managing.ec2.instancetypes). + **AMI ID** – The machine image that Elastic Beanstalk uses to launch Amazon EC2 instances in your environment. For details, see [AMI ID](using-features.managing.ec2.console.md#using-features.managing.ec2.customami). + **Availability Zones** – Choose the number of Availability Zones to spread your environment's instances across. By default, the Auto Scaling group launches instances evenly across all usable zones. To concentrate your instances in fewer zones, choose the number of zones to use. For production environments, use at least two zones to ensure that your application is available in case one Availability Zone goes out. + **Placement** (optional) – Choose the Availability Zones to use. Use this setting if your instances need to connect to resources in specific zones, or if you have purchased [reserved instances](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/concepts-on-demand-reserved-instances.html), which are zone-specific. If you launch your environment in a custom VPC, you cannot configure this option. In a custom VPC, you choose Availability Zones for the subnets that you assign to your environment. + **Scaling cooldown** – The amount of time, in seconds, to wait for instances to launch or terminate after scaling, before continuing to evaluate triggers. For more information, see [Scaling Cooldowns](https://docs.amazonaws.cn/autoscaling/ec2/userguide/Cooldown.html). 1. To save the changes choose **Apply** at the bottom of the page. ## Configuration using namespace options Namespace options Elastic Beanstalk provides [configuration options](command-options.md) for Auto Scaling settings in two namespaces: [`aws:autoscaling:asg`](command-options-general.md#command-options-general-autoscalingasg) and [`aws:ec2:instances`](command-options-general.md#command-options-general-ec2instances). ### The aws:autoscaling:asg namespace The [`aws:autoscaling:asg`](command-options-general.md#command-options-general-autoscalingasg) namespace provides options for overall scale and availability. The following [configuration file](ebextensions.md) example configures the Auto Scaling group to use two to four instances, specific availability zones, and a cooldown period of 12 minutes (720 seconds). It enables [Capacity Rebalancing](https://docs.amazonaws.cn/autoscaling/ec2/userguide/capacity-rebalance.html) for Spot Instances. This `EnableCapacityRebalancing` option only takes effect if `EnableSpot` is set to `true` in the [`aws:ec2:instances`](command-options-general.md#command-options-general-ec2instances) namespace, as shown in the configuration file example following this one. ``` option_settings: aws:autoscaling:asg: Availability Zones: Any Cooldown: '720' Custom Availability Zones: 'us-west-2a,us-west-2b' MaxSize: '4' MinSize: '2' EnableCapacityRebalancing: true ``` ### The aws:ec2:instances namespace **Note** When you update your environment configuration and remove one or more instance types from the `InstanceTypes` option, Elastic Beanstalk terminates any Amazon EC2 instances running on any of the removed instance types. Your environment's Auto Scaling group then launches new instances, as necessary to complete the desired capacity, using your current specified instance types. The [`aws:ec2:instances`](command-options-general.md#command-options-general-ec2instances) namespace provides options related to your environment's instances, including Spot Instance management. It complements [`aws:autoscaling:launchconfiguration`](command-options-general.md#command-options-general-autoscalinglaunchconfiguration) and [`aws:autoscaling:asg`](command-options-general.md#command-options-general-autoscalingasg). The following [configuration file](ebextensions.md) example configures the Auto Scaling group to enable Spot Instance requests for your environment. It designates three possible instance types that can be used. At least one On-Demand Instance is used for baseline capacity, and a sustained 33% of On-Demand Instances is used for any additional capacity. The configuration sets the [spot allocation strategy](environments-cfg-autoscaling-spot-allocation-strategy.md) to `capacity-optimized-prioritized`. This particular allocation strategy prioritizes the instance launches from the pool based on the order of the instance types specified in the `InstanceTypes` option. If `SpotAllocationStrategy` is not specified it defaults to `capacity-optimized`. ``` option_settings: aws:ec2:instances: EnableSpot: true InstanceTypes: 't2.micro,t3.micro,t3.small' SpotAllocationStrategy: capacity-optimized-prioritized SpotFleetOnDemandBase: '1' SpotFleetOnDemandAboveBasePercentage: '33' ``` To choose Spot Instance types, use the [Spot Instance Advisor](https://aws.amazon.com/ec2/spot/instance-advisor/). **Important** The `EnableSpot` option setting can cause Elastic Beanstalk to migrate an existing environment with launch configurations to launch templates. Doing so requires the necessary permissions to manage launch templates. These permissions are included in our managed policy. If you use custom policies instead of our managed policies, environment creation or updates might fail when you update your environment configuration. For more information and other considerations, see [Migrating your Elastic Beanstalk environment to launch templates](environments-cfg-autoscaling-launch-templates.md). ## Configuration using the Amazon CLI Amazon CLI This section provides examples of how you can use the Amazon CLI [create-environment](https://docs.amazonaws.cn/cli/latest/reference/elasticbeanstalk/create-environment.html) command to configure your environment with the Auto Scaling and Capacity options described in these sections. You'll notice the namespace settings for [`aws:autoscaling:asg`](command-options-general.md#command-options-general-autoscalingasg) and [`aws:ec2:instances`](command-options-general.md#command-options-general-ec2instances), as described in the previous [namespace configuration options](#environments-cfg-autoscaling-namespace) section are also configured with this example. The Amazon Command Line Interface provides commands to create and configure Elastic Beanstalk environments. With the `--option-settings` option, you can pass in namespace options that are supported by Elastic Beanstalk. This means that the [namespace configuration options](#environments-cfg-autoscaling-namespace) described previously can be passed into applicable Amazon CLI commands to configure your Elastic Beanstalk environment. **Note** You can also use the [update-environment](https://docs.amazonaws.cn/cli/latest/reference/elasticbeanstalk/update-environment.html) command with `--option-settings` to add or update namespace options. If you need to remove any namespace options from your environment use the **update-environment** command with `--options-to-remove`. The following example creates a new environment. Refer to the previous topic [namespace configuration options](#environments-cfg-autoscaling-namespace) for more context about the options that are passed in. The fist option listed, `IamInstanceProfile` in the [aws:autoscaling:launchconfiguration](command-options-general.md#command-options-general-autoscalinglaunchconfiguration) namespace, is the Elastic Beanstalk [instance profile](concepts-roles-instance.md). It's required when you create a new environment. **Example — create-environment with Auto Scaling options (namespace options inline)** ``` aws elasticbeanstalk create-environment \ --region us-east-1 \ --application-name my-app \ --environment-name my-env \ --solution-stack-name "64bit Amazon Linux 2023 v4.3.0 running Python 3.12" \ --option-settings \ Namespace=aws:autoscaling:launchconfiguration,OptionName=IamInstanceProfile,Value=aws-elasticbeanstalk-ec2-role Namespace=aws:autoscaling:asg,OptionName=Availability Zones,Value=Any \ Namespace=aws:autoscaling:asg,OptionName=Cooldown,Value=720 \ Namespace=aws:autoscaling:asg,OptionName=Custom Availability Zones,Value=us-west-2a,us-west-2b \ Namespace=aws:autoscaling:asg,OptionName=MaxSize,Value=4 \ Namespace=aws:autoscaling:asg,OptionName=MinSize,Value=2 \ Namespace=aws:autoscaling:asg,OptionName=EnableCapacityRebalancing,Value=true \ Namespace=aws:ec2:instances,OptionName=EnableSpot,Value=true \ Namespace=aws:ec2:instances,OptionName=InstanceTypes,Value=t2.micro,t3.micro,t3.small \ Namespace=aws:ec2:instances,OptionName=SpotAllocationStrategy,Value=capacity-optimized-prioritized \ Namespace=aws:ec2:instances,OptionName=SpotFleetOnDemandBase,Value=1 \ Namespace=aws:ec2:instances,OptionName=SpotFleetOnDemandAboveBasePercentage,Value=33 ``` **Important** The `EnableSpot` option setting can cause Elastic Beanstalk to migrate an existing environment with launch configurations to launch templates. Doing so requires the necessary permissions to manage launch templates. These permissions are included in our managed policy. If you use custom policies instead of our managed policies, environment creation or updates might fail when you update your environment configuration. For more information and other considerations, see [Migrating your Elastic Beanstalk environment to launch templates](environments-cfg-autoscaling-launch-templates.md). As an alternative, use an `options.json` file to specify the namespace options instead of including them inline. **Example —create-environment with Auto Scaling options (namespace options in `options.json` file)** ``` aws elasticbeanstalk create-environment \ --region us-east-1 \ --application-name my-app \ --environment-name my-env \ --solution-stack-name "64bit Amazon Linux 2023 v4.3.0 running Python 3.12" --option-settings file://options.json ``` **Example** ``` ### example options.json ### [ { "Namespace": "aws:autoscaling:launchconfiguration", "OptionName": "IamInstanceProfile", "Value": "aws-elasticbeanstalk-ec2-role" }, { "Namespace": "aws:autoscaling:asg", "OptionName": "Availability Zones", "Value": "Any" }, { "Namespace": "aws:autoscaling:asg", "OptionName": "Cooldown", "Value": "720" }, { "Namespace": "aws:autoscaling:asg", "OptionName": "Custom Availability Zones", "Value": "us-west-2a,us-west-2b" }, { "Namespace": "aws:autoscaling:asg", "OptionName": "MaxSize", "Value": "4" }, { "Namespace": "aws:autoscaling:asg", "OptionName": "MinSize", "Value": "2" }, { "Namespace": "aws:autoscaling:asg", "OptionName": "EnableCapacityRebalancing", "Value": "true" }, { "Namespace": "aws:ec2:instances", "OptionName": "EnableSpot", "Value": "true" }, { "Namespace": "aws:ec2:instances", "OptionName": "InstanceTypes", "Value": "t2.micro,t3.micro,t3.small" }, { "Namespace": "aws:ec2:instances", "OptionName": "SpotAllocationStrategy", "Value": "capacity-optimized-prioritized" }, { "Namespace": "aws:ec2:instances", "OptionName": "SpotFleetOnDemandBase", "Value": "1" }, { "Namespace": "aws:ec2:instances", "OptionName": "SpotFleetOnDemandAboveBasePercentage", "Value": "33" } ] ``` ## Configuration using the EB CLI EB CLI When creating an environment using the [**eb create**](eb3-create.md) command, you can specify a few options that are related to your environment's Auto Scaling group. These are some of the options that help you control the capacity of your environment. `--single` Creates the environment with one Amazon EC2 instance and no load balancer. If you don't use this option, a load-balancer is added to the environment that's created. `--enable-spot` Enables Spot Instance requests for your environment. The `enable-spot` option setting can cause Elastic Beanstalk to migrate an existing environment with launch configurations to launch templates. Doing so requires the necessary permissions to manage launch templates. These permissions are included in our managed policy. If you use custom policies instead of our managed policies, environment creation or updates might fail when you update your environment configuration. For more information and other considerations, see [Migrating your Elastic Beanstalk environment to launch templates](environments-cfg-autoscaling-launch-templates.md). The following options for the [**eb create**](eb3-create.md) command can only be used with `--enable-spot`. `--instance-types` Lists the Amazon EC2 instance types that you want your environment to use. `--spot-max-price` The maximum price per unit hour, in US dollars, that you're willing to pay for a Spot Instance. For recommendations about maximum price options for Spot Instances, see [Spot Instance pricing history](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/using-spot-instances-history.html) in the *Amazon EC2 User Guide*. `--on-demand-base-capacity` The minimum number of On-Demand Instances that your Auto Scaling group provisions before considering Spot Instances as your environment scales up. `--on-demand-above-base-capacity` The percentage of On-Demand Instances as part of additional capacity that your Auto Scaling group provisions that's more than the number of instances that's specified by the `--on-demand-base-capacity` option. The following example creates an environment and configures the Auto Scaling group to enable Spot Instance requests for the new environment. For this example, three possible instance types can be used. ``` $ eb create --enable-spot --instance-types "t2.micro,t3.micro,t3.small" ``` **Important** There is another similarly named option that's called `--instance-type` (no “s”) that the EB CLI only recognizes when processing On-Demand Instances. Don't use `--instance-type` (no "s") with the `--enable-spot` option. If you do, the EB CLI ignores it. Instead use `--instance-types` (with "s") with the `--enable-spot` option. # Auto Scaling triggers for your Elastic Beanstalk environment Triggers The Auto Scaling group in your Elastic Beanstalk environment uses two Amazon CloudWatch alarms to trigger scaling operations. The default triggers scale when the average outbound network traffic from each instance is higher than 6 MB or lower than 2 MB over a period of five minutes. To use Amazon EC2 Auto Scaling effectively, configure triggers that are appropriate for your application, instance type, and service requirements. You can scale based on several statistics including latency, disk I/O, CPU utilization, and request count. For more information about CloudWatch metrics and alarms, see [Amazon CloudWatch Concepts](https://docs.amazonaws.cn/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html) in the *Amazon CloudWatch User Guide*. ## Configuring Auto Scaling triggers You can configure the triggers that adjust the number of instances in your environment's Auto Scaling group in the Elastic Beanstalk console. **To configure triggers in the Elastic Beanstalk console** 1. Open the [Elastic Beanstalk console](https://console.amazonaws.cn/elasticbeanstalk), and in the **Regions** list, select your Amazon Web Services Region. 1. In the navigation pane, choose **Environments**, and then choose the name of your environment from the list. 1. In the navigation pane, choose **Configuration**. 1. In the **Capacity** configuration category, choose **Edit**. 1. In the **Scaling triggers** section, configure the following settings: + **Metric** – Metric used for your Auto Scaling trigger. + **Statistic** – Statistic calculation the trigger should use, such as `Average`. + **Unit** – Unit for the trigger metric, such as **Bytes**. + **Period** – Specifies how frequently Amazon CloudWatch measures the metrics for your trigger. + **Breach duration** – Amount of time, in minutes, a metric can be outside of the upper and lower thresholds before triggering a scaling operation. + **Upper threshold** – If the metric exceeds this number for the breach duration, a scaling operation is triggered. + **Scale up increment** – The number of Amazon EC2 instances to add when performing a scaling activity. + **Lower threshold** – If the metric falls below this number for the breach duration, a scaling operation is triggered. + **Scale down increment** – The number of Amazon EC2 instances to remove when performing a scaling activity. 1. To save the changes choose **Apply** at the bottom of the page. ## The aws:autoscaling:trigger namespace Elastic Beanstalk provides [configuration options](command-options.md) for Auto Scaling settings in the [`aws:autoscaling:trigger`](command-options-general.md#command-options-general-autoscalingtrigger) namespace. Settings in this namespace are organized by the resource that they apply to. ``` option_settings: AWSEBAutoScalingScaleDownPolicy.aws:autoscaling:trigger: LowerBreachScaleIncrement: '-1' AWSEBAutoScalingScaleUpPolicy.aws:autoscaling:trigger: UpperBreachScaleIncrement: '1' AWSEBCloudwatchAlarmHigh.aws:autoscaling:trigger: UpperThreshold: '6000000' AWSEBCloudwatchAlarmLow.aws:autoscaling:trigger: BreachDuration: '5' EvaluationPeriods: '1' LowerThreshold: '2000000' MeasureName: NetworkOut Period: '5' Statistic: Average Unit: Bytes ``` # Scheduled Auto Scaling actions for your Elastic Beanstalk environments Scheduled actions To optimize your environment's use of Amazon EC2 instances through predictable periods of peak traffic, configure your Amazon EC2 Auto Scaling group to change its instance count on a schedule. You can configure your environment with a recurring action to scale up each day in the morning, and scale down at night when traffic is low. For example, if you have a marketing event that will drive traffic to your site for a limited period of time, you can schedule a one-time event to scale up when it starts, and another to scale down when it ends. You can define up to 120 active scheduled actions per environment. Elastic Beanstalk also retains up to 150 expired scheduled actions, which you can reuse by updating their settings. ## Configuring scheduled actions You can create scheduled actions for your environment's Auto Scaling group in the Elastic Beanstalk console. **To configure scheduled actions in the Elastic Beanstalk console** 1. Open the [Elastic Beanstalk console](https://console.amazonaws.cn/elasticbeanstalk), and in the **Regions** list, select your Amazon Web Services Region. 1. In the navigation pane, choose **Environments**, and then choose the name of your environment from the list. 1. In the navigation pane, choose **Configuration**. 1. In the **Capacity** configuration category, choose **Edit**. 1. In the **Time-based scaling** section, choose **Add scheduled action**. 1. Fill in the following scheduled action settings: + **Name** – Specify a unique name of up to 255 alphanumeric characters, with no spaces. + **Instances** – Choose the minimum and maximum instance count to apply to the Auto Scaling group. + **Desired capacity** (optional) – Set the initial desired capacity for the Auto Scaling group. After the scheduled action is applied, triggers adjust the desired capacity based on their settings. + **Occurrence** – Choose **Recurring** to repeat the scaling action on a schedule. + **Start time** – For one-time actions, choose the date and time to run the action. For recurrent actions, a start time is optional. Specify it to choose the earliest time the action is performed. After this time, the action recurs according to the **Recurrence** expression. + **Recurrence** – Use a [Cron](http://en.wikipedia.org/wiki/Cron#CRON_expression) expression to specify the frequency with which you want the scheduled action to occur. For example, `30 6 * * 2` runs the action every Tuesday at 6:30 AM UTC. + **End time** (optional) – Optional for recurrent actions. If specified, the action recurs according to the **Recurrence** expression, and is not performed again after this time. When a scheduled action ends, Auto Scaling doesn't automatically go back to its previous settings. Configure a second scheduled action to return Auto Scaling to the original settings as needed. 1. Choose **Add**. 1. To save the changes choose **Apply** at the bottom of the page. **Note** Scheduled actions will not be saved until applied. ## The aws:autoscaling:scheduledaction namespace If you need to configure a large number of scheduled actions, you can use [configuration files](ebextensions.md) or [the Elastic Beanstalk API](environment-configuration-methods-after.md#configuration-options-after-awscli-commandline) to apply the configuration option changes from a YAML or JSON file. These methods also let you access the [`Suspend` option](command-options-general.md#command-options-general-autoscalingscheduledaction) to temporarily deactivate a recurrent scheduled action. **Note** When working with scheduled action configuration options outside of the console, use ISO 8601 time format to specify start and end times in UTC. For example, 2015-04-28T04:07:02Z. For more information about ISO 8601 time format, see [Date and Time Formats](http://www.w3.org/TR/NOTE-datetime). The dates must be unique across all scheduled actions. Elastic Beanstalk provides configuration options for scheduled action settings in the [`aws:autoscaling:scheduledaction`](command-options-general.md#command-options-general-autoscalingscheduledaction) namespace. Use the `resource_name` field to specify the name of the scheduled action. **Example Scheduled-scale-up-specific-time-long.config** This configuration file instructs Elastic Beanstalk to scale out from five instances to 10 instances at 2015-12-12T00:00:00Z. ``` option_settings: - namespace: aws:autoscaling:scheduledaction resource_name: ScheduledScaleUpSpecificTime option_name: MinSize value: '5' - namespace: aws:autoscaling:scheduledaction resource_name: ScheduledScaleUpSpecificTime option_name: MaxSize value: '10' - namespace: aws:autoscaling:scheduledaction resource_name: ScheduledScaleUpSpecificTime option_name: DesiredCapacity value: '5' - namespace: aws:autoscaling:scheduledaction resource_name: ScheduledScaleUpSpecificTime option_name: StartTime value: '2015-12-12T00:00:00Z' ``` **Example Scheduled-scale-up-specific-time.config** To use the shorthand syntax with the EB CLI or configuration files, prepend the resource name to the namespace. ``` option_settings: ScheduledScaleUpSpecificTime.aws:autoscaling:scheduledaction: MinSize: '5' MaxSize: '10' DesiredCapacity: '5' StartTime: '2015-12-12T00:00:00Z' ``` **Example Scheduled-scale-down-specific-time.config** This configuration file instructs Elastic Beanstalk to scale in at 2015-12-12T07:00:00Z. ``` option_settings: ScheduledScaleDownSpecificTime.aws:autoscaling:scheduledaction: MinSize: '1' MaxSize: '1' DesiredCapacity: '1' StartTime: '2015-12-12T07:00:00Z' ``` **Example Scheduled-periodic-scale-up.config** This configuration file instructs Elastic Beanstalk to scale out every day at 9AM. The action is scheduled to begin May 14, 2015 and end January 12, 2016. ``` option_settings: ScheduledPeriodicScaleUp.aws:autoscaling:scheduledaction: MinSize: '5' MaxSize: '10' DesiredCapacity: '5' StartTime: '2015-05-14T07:00:00Z' EndTime: '2016-01-12T07:00:00Z' Recurrence: 0 9 * * * ``` **Example Scheduled-periodic-scale-down.config** This configuration file instructs Elastic Beanstalk to scale in to no running instance every day at 6PM. If you know that your application is mostly idle outside of business hours, you can create a similar scheduled action. If your application must be down outside of business hours, change `MaxSize` to `0`. ``` option_settings: ScheduledPeriodicScaleDown.aws:autoscaling:scheduledaction: MinSize: '0' MaxSize: '1' DesiredCapacity: '0' StartTime: '2015-05-14T07:00:00Z' EndTime: '2016-01-12T07:00:00Z' Recurrence: 0 18 * * * ``` **Example Scheduled-weekend-scale-down.config** This configuration file instructs Elastic Beanstalk to scale in every Friday at 6PM. If you know that your application doesn’t receive as much traffic over the weekend, you can create a similar scheduled action. ``` option_settings: ScheduledWeekendScaleDown.aws:autoscaling:scheduledaction: MinSize: '1' MaxSize: '4' DesiredCapacity: '1' StartTime: '2015-12-12T07:00:00Z' EndTime: '2016-01-12T07:00:00Z' Recurrence: 0 18 * * 5 ``` # Auto Scaling health check setting for your Elastic Beanstalk environment Health check setting Amazon EC2 Auto Scaling monitors the health of each Amazon Elastic Compute Cloud (Amazon EC2) instance that it launches. If any instance terminates unexpectedly, Auto Scaling detects the termination and launches a replacement instance. By default, the Auto Scaling group created for your environment uses [Amazon EC2 status checks](https://docs.amazonaws.cn/autoscaling/latest/userguide/healthcheck.html). If an instance in your environment fails an Amazon EC2 status check, Auto Scaling takes it down and replaces it. Amazon EC2 status checks only cover an instance's health, not the health of your application, server, or any Docker containers running on the instance. If your application crashes, but the instance that it runs on is still healthy, it may be kicked out of the load balancer, but Auto Scaling won't replace it automatically. The default behavior is good for troubleshooting. If Auto Scaling replaced the instance as soon as the application crashed, you might not realize that anything went wrong, even if it crashed quickly after starting up. If you want Auto Scaling to replace instances whose application has stopped responding, you can use a [configuration file](ebextensions.md) to configure the Auto Scaling group to use Elastic Load Balancing health checks. The following example sets the group to use the load balancer's health checks, in addition to the Amazon EC2 status check, to determine an instance's health. **Example .ebextensions/autoscaling.config** ``` Resources: AWSEBAutoScalingGroup: Type: "AWS::AutoScaling::AutoScalingGroup" Properties: HealthCheckType: ELB HealthCheckGracePeriod: 300 ``` For more information about the `HealthCheckType` and `HealthCheckGracePeriod` properties, see [AWS::AutoScaling::AutoScalingGroup](https://docs.amazonaws.cn/AWSCloudFormation/latest/UserGuide/aws-properties-as-group.html) in the *Amazon CloudFormation User Guide* and [Health Checks for Auto Scaling Instances](https://docs.amazonaws.cn/autoscaling/ec2/userguide/healthcheck.html) in the *Amazon EC2 Auto Scaling User Guide*. By default, the Elastic Load Balancing health check is configured to attempt a TCP connection to your instance over port 80. This confirms that the web server running on the instance is accepting connections. However, you might want to [customize the load balancer health check](using-features.managing.elb.md) to ensure that your application, and not just the web server, is in a good state. The grace period setting sets the number of seconds that an instance can fail the health check without being terminated and replaced. Instances can recover after being kicked out of the load balancer, so give the instance an amount of time that is appropriate for your application.