eb create --min-instances 0 --max-instances 0 not working

[shaicoleman]

Description

Running eb create with the --instance-types parameter does not set the instance type.

Steps to reproduce

Run eb create testenv --elb-type application --min-instances 0 --max-instances 0 --scale 0 --debug

Observed result

ebcli.objects.exceptions.ServiceError: Configuration validation exception:
Invalid option value: '0.0' (Namespace: 'aws:autoscaling:updatepolicy:rollingupdate', OptionName: 'MinInstancesInService'):
The minimum instances in service for rolling updates (0) should be less than the maximum instance count for the Autoscaling group (0).

Expected result

Should succeed, create a new environment scaled to zero

Additional environment details (Ex: Windows, Mac, Amazon Linux etc)

OS: Ubuntu 20.04 EBCLI version: EB CLI 3.19.4 (Python 3.8.5) Region: eu-west-1 Platform: Ruby 2.7 running on 64bit Amazon Linux 2

Notes

There is no workaround besides creating the environment, then scaling to zero. Ideally there should be a way to control some of specific configuration details during the create that are currently only available through eb config.

[Palakpatel67]

@shaicoleman thanks for reaching out. Minimum value for --min-instance option and --max-instance option is 1. Elastic Beanstalk don't support creating environment with zero instances. As an alternative you can use eb scale command to scale up or down number of instances in your environment after environment is created.

Could you provide some use case why do you want to create EB environment with 0 instances?

[shaicoleman]

Mainly because creating the Elastic Beanstalk is a very slow multi-step process.

Currently my main usecase is to speed up the process of EB.

Currently it creates the instances, then I need to change the configuration of EB, then it needs to go through the whole process of adjusting the autoscaling, terminating the existing instances, creating new instances, adjusting the autoscaling again, etc. This needlessly wastes 10 minutes of the user's time for no good reason.

There are other reasons to create a zero instance EB, such as as stand-by environment, or just to completely configure all the parts of EB first without paying for instances.

Zero instances is a perfectly valid state for EB, and there's no reason to place artificial technical restriction during the creation.

The only reason zero instances doesn't work at the moment is because there is a default rolling update policy which can't be configured during creation.

In pseudocode:

if min_instance == 0 and max_instance == 0
then rolling_update_policy = all_at_once

Or even better, don't make it an error to have a rolling update policy and zero instances.

[NihalM99]

EB-CLI relies on Auto Scaling groups for instance management . ASGs , rely on three parameters , min instances , max instances and scale. Having minimum and maximum set to 0 would violate the constraints of ASGs to have atleast 1 instance to perform health checks ,resource allocation and updates .ASGs have policies to automatically scale resources up or down based on metrics , if maxsize and minsize were set to 0 , these policies would not work

[shaicoleman]

Again the main issue is that there is no way to specify some parameters during the creation, e.g. eb create testenv --rolling-update-policy=all_at_once If that was possible, then it wouldn't violate any constraints.

The creation of the environment and its scaling shouldn't be coupled to each other.

[jsheld]

@shaicoleman Have you considered using a configuration file to specify the update policy?

For example: option_settings: aws:elasticbeanstalk:command: DeploymentPolicy: Rolling BatchSizeType: Percentage BatchSize: 25

This should allow you to create the environment and decouples the settings you are talking about explicitly from creation.

[NihalM99]

@shaicoleman using a configuration file is a good workaround to decouple environment creation from its scaling/update settings. @jsheld's recommendation of defining the deployment policy within a configuration file during environment creation decouples the default behavior of Elastic Beanstalk. By explicitly setting the deployment policy upfront, we avoid the time-consuming post-creation adjustments like altering autoscaling and reconfiguring instances. This approach streamlines the deployment process, saving time previously lost in manual configuration changes.Would this fix your issue ?