Managing a single AWSElastic Beanstalk environment is usually more or less straightforward with the eb cli command. However, when you are responsible for a fleet of environments, gathering information and applying configurations consistently can become cumbersome. The standard eb tool is designed for interactive use within a specific application directory, making it less suitable for automated, fleet-wide operations.
Amazon Web Services (AWS) is a comprehensive and widely adopted cloud computing platform offered by Amazon. It provides a vast collection of services over the internet, including computing power (like virtual servers), storage options, databases, networking, machine learning, and much more, because they have an impressive long list of different products inside the Amazon Web Services umbrella. They allow you to to rent access to these services on a pay-as-you-go basis.
One of these products is AWS Elastic Beanstalk (EB). It is a Platform as a Service (PaaS) designed to simplify the process of deploying, running, and scaling web applications and services. When you use Elastic Beanstalk, you just upload your code, and it automatically handles the deployment details, including capacity provisioning, load balancing, auto-scaling, and application health monitoring. It manages the underlying infrastructure for you, and it even allows you to switch URLs from production to staging and the other way around if needed.
The aws command is the primary tool of the AWS Command Line Interface (CLI), that is, the main tool to manage what you rented in Amazon Web Services via a command line interface. It’s a unified command-line utility that lets you interact with and manage all AWS services directly from your terminal. By using the aws command, you can control your entire AWS account and its resources, making it a powerful tool for scripting and automating cloud operations. It provides low-level access to the AWS APIs for granular control.
There is also an specific CLI tool for Elastic Beanstalk. The eb command is the tool for the Elastic Beanstalk Command Line Interface (EB CLI). Unlike the general-purpose aws command, the eb command is specifically designed for managing Elastic Beanstalk applications and environments. It offers a set of high-level commands that simplify common workflows, such as creating a new environment (eb create), deploying a new version of your application (eb deploy), and checking the health and status of your environment (eb status).
So, how do you bridge the gap when the simple eb command isn’t enough?
To bridge the gap between interactive use within a specific application directory and automated, fleet-wide operations, we can turn to the more powerful aws CLI instead of using eb even when we are trying to manage Elastic Beanstakl related resources, combined with some light shell scripting. This approach allows us to directly query the AWS API and manage resources across all our environments programmatically. The following scripts provide practical solutions to common questions that are difficult to answer using only the eb cli. They are designed to be direct, effective, and easily integrated into your operational toolkit.
Here is the next section of the article, explaining the first script.
Programmatically Update Auto Scaling Triggers
Let’s start with a common task: setting everything up so your environment scales correctly. This script uses the aws CLI to directly modify the auto-scaling trigger configuration for an Elastic Beanstalk environment.
aws elasticbeanstalk update-environment \
--environment-name <NAME_OF_THE_ENVIRONMENT> \
--region eu-west-1 \
--option-settings '[
{
"Namespace": "aws:autoscaling:trigger",
"OptionName": "MeasureName",
"Value": "CPUUtilization"
},
{
"Namespace": "aws:autoscaling:trigger",
"OptionName": "Statistic",
"Value": "Average"
},
{
"Namespace": "aws:autoscaling:trigger",
"OptionName": "Unit",
"Value": "Percent"
},
{
"Namespace": "aws:autoscaling:trigger",
"OptionName": "Period",
"Value": "1"
},
{
"Namespace": "aws:autoscaling:trigger",
"OptionName": "BreachDuration",
"Value": "1"
},
{
"Namespace": "aws:autoscaling:trigger",
"OptionName": "UpperThreshold",
"Value": "80"
},
{
"Namespace": "aws:autoscaling:trigger",
"OptionName": "LowerThreshold",
"Value": "30"
}
]'
The command aws elasticbeanstalk update-environment modifies the configuration of an existing environment. The real power comes from the --option-settings parameter, which accepts a JSON array of configuration options. Here, every option is in the aws:autoscaling:trigger namespace, telling Elastic Beanstalk exactly which part of the configuration we want to change.
The settings define a clear rule: if the average CPU utilization across all instances in the environment stays above 80% for a duration of one minute, the system will trigger a scale-up action (add an instance). Conversely, if the average CPU drops below 30% and stays there for one minute, it will trigger a scale-down.
To adapt this command for your own use, you must first replace <NAME_OF_THE_ENVIRONMENT> with the target environment’s name and update the --region if it’s located elsewhere. Within the --option-settings JSON, the values for UpperThreshold, LowerThreshold, Period, and BreachDuration are the primary values you will adjust to tune the scaling behavior for your application’s specific load profile.
This script can also be adapted for other scaling metrics beyond CPU utilization. To achieve this, you would change the Value for the MeasureName option. For example, to scale based on network traffic, you could set MeasureName to NetworkOut and change the Unit to Bytes. Likewise, for latency-based scaling, you could set the MeasureName to Latency and the Unit to Seconds, so it allows you to tie scaling events to the most critical performance indicator for your service.
This script’s main advantage is providing a non-interactive, repeatable way to configure scaling rules. It allows you to enforce a specific scaling policy across multiple environments programmatically, which is is a core principle of Infrastructure as Code (IaC) and is often more reliable and less error-prone than making manual changes through a web console.
The eb scale command is great for manually changing the number of running instances or for walking through an interactive setup. However, it doesn’t expose all the detailed aws:autoscaling:trigger settings in a single, non-interactive command that’s easy to automate. The eb cli is built for convenience in a development workflow, not for the granular, scriptable control needed to manage infrastructure at scale.
This script is useful in several situations. It’s good for policy enforcement; you can run it as a scheduled task to find and fix any environments that have drifted from the standard configuration. And if you need to make a change to your scaling strategy across the board—say, adjusting the threshold for an anticipated traffic spike—you can loop this command to apply the update to your entire fleet in seconds.
Audit Environment and Instance Types Across Your Fleet
Next, let’s tackle a fairly common challenge: getting a high-level report of your fleet’s configuration. When you need to quickly check what instance types are running where, or confirm that environments are set up correctly, this script gives you an instant summary.
echo "Application Environment Type InstanceType"
echo "------------------ ------------------------ ----------------- ------------"
aws elasticbeanstalk describe-environments \
--query "Environments[*].[ApplicationName,EnvironmentName]" \
--output text | \
while read -r APP_NAME ENV_NAME; do
SETTINGS=$(aws elasticbeanstalk describe-configuration-settings --application-name "$APP_NAME" --environment-name "$ENV_NAME")
ENV_TYPE=$(echo "$SETTINGS" | jq -r '.ConfigurationSettings[].OptionSettings[] | select(.OptionName=="EnvironmentType") | .Value')
INSTANCE_TYPE=$(echo "$SETTINGS" | jq -r '.ConfigurationSettings[].OptionSettings[] | select(.OptionName=="InstanceType") | .Value')
printf "%-18s %-24s %-17s %-12s\n" "$APP_NAME" "$ENV_NAME" "$ENV_TYPE" "$INSTANCE_TYPE"
done
This script is an example of chaining commands together. First, aws elasticbeanstalk describe-environment gets a list of all environment and application names in your account. The output is piped into a while loop, which processes each environment one by one.
Inside the loop, aws elasticbeanstalk describe-configuration-setting fetches the complete configuration for the current environment. Since this returns a large JSON object, the script uses jq—a command-line JSON processor—to parse it. It extracts just two specific values: the EnvironmentType (like LoadBalanced or SingleInstance) and the InstanceType (like t3.micro). Finally, printf formats this information into a clean, readable table.
This script provides visibility so that instead of clicking through the AWS console or running commands for each environment individually, you get a single, consolidated report of your entire fleet’s key settings.
The eb cli is designed to work from within a specific application’s directory. It has no built-in function to report on all environments across your entire account. To get this information with the eb cli, you would have to manually navigate into each project’s folder and run eb config, which is completely impractical for managing a fleet. This script bypasses that limitation by querying AWS directly.
It’s good for configuration auditing, allowing you to instantly verify that all your production environments are using approved instance types. For estimating costs and cost management, it gives you a quick inventory of all running instances, helping you spot expensive resources that could be downsized. It’s also good for migration planning; when a new instance family is released, you can run this script to get a clear to-do list of all environments that need upgrading.
Get an Overview of Instance Counts
This other script provides a real-time summary of the scaling status for every environment in your fleet, and shows the configured minimum, maximum, desired, and current running instance counts.
printf "%-18s %-24s %-12s %-12s %-12s %-12s\n" "Application" "Environment" "Min" "Max" "Desired" "Current"
echo "------------------ ------------------------ ------------ ------------ ------------ ------------"
aws elasticbeanstalk describe-environments \
--query "Environments[*].[ApplicationName,EnvironmentName]" \
--output text | \
while read -r APP_NAME ENV_NAME; do
ASG_NAME=$(aws elasticbeanstalk describe-environment-resources --environment-name "$ENV_NAME" --query "EnvironmentResources.AutoScalingGroups[0].Name" --output text)
if [ "$ASG_NAME" != "None" ] && [ -n "$ASG_NAME" ]; then
ASG_DETAILS=$(aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names "$ASG_NAME")
MIN_SIZE=$(echo "$ASG_DETAILS" | jq -r '.AutoScalingGroups[0].MinSize')
MAX_SIZE=$(echo "$ASG_DETAILS" | jq -r '.AutoScalingGroups[0].MaxSize')
DESIRED_CAP=$(echo "$ASG_DETAILS" | jq -r '.AutoScalingGroups[0].DesiredCapacity')
CURRENT_COUNT=$(echo "$ASG_DETAILS" | jq -r '.AutoScalingGroups[0].Instances | length')
printf "%-18s %-24s %-12s %-12s %-12s %-12s\n" "$APP_NAME" "$ENV_NAME" "$MIN_SIZE" "$MAX_SIZE" "$DESIRED_CAP" "$CURRENT_COUNT"
else
printf "%-18s %-24s %-12s %-12s %-12s %-12s\n" "$APP_NAME" "$ENV_NAME" "1" "1" "1" "1"
fi
done
The script begins by printing a formatted header for the output table. It then initiates a for loop that iterates through every Elastic Beanstalk environment in the account. Inside the loop, it performs several actions for each environment. First, it retrieves the associated Application Name and the underlying Auto Scaling Group (ASG) name.
A conditional check verifies if an ASG exists. If it does, the script queries the Auto Scaling service directly for that group’s details. It then uses the jq utility to parse the resulting JSON and extract four key metrics: the minimum size, maximum size, desired capacity, and a count of the currently running instances. If an environment does not have an ASG, such as a single-instance type, it prints default values. Finally, printf formats this collected data into a clean, aligned row.
One of its main strengths is that it provides immediate operational awareness of your fleet’s capacity and current state. It consolidates scaling metrics from across all environments into a single report.
The eb cli command eb status can show the health and status of a single environment, but it does not display the min/max scaling configuration and to my knowledge it has no capability to generate a summary report across all environments. This script overcomes that limitation by programmatically iterating through all resources and querying the underlying Auto Scaling service for details the eb cli does not expose in this manner.
The script can be used for daily health checks to get a snapshot of the fleet’s status at the start of the day. For cost management, it helps quickly identify environments with a high minimum instance count that might be candidates for optimization. It is also valuable for capacity planning, as it provides an immediate overview of the current versus maximum potential capacity of your entire infrastructure.
Know an Environment’s Scaling History
While fleet-wide reports are useful for monitoring, sometimes you need to investigate the behavior of a single environment. This script allows you to retrieve a detailed log of recent scaling activities, adding useful insights towards answering the question of when and why instances were added or removed.
# First, get the Auto Scaling Group (ASG) name
ASG_NAME=$(aws elasticbeanstalk describe-environment-resources \
--environment-name "my-prod-env" \
--query "EnvironmentResources.AutoScalingGroups[0].Name" \
--output text)
# Now, check its most recent activity
# / ! \ WARNING: it generates A LOT of output
aws autoscaling describe-scaling-activities --auto-scaling-group-name "$ASG_NAME"
Be aware this command can generate a lot of output, depending on your circumstances.
This script operates in two stages. First, it uses aws elasticbeanstalk describe-environment-resources to find the underlying Auto Scaling Group (ASG) associated with a specific Elastic Beanstalk environment name. It extracts just the ASG’s name and stores it in a variable. Second, it passes this variable to the aws autoscaling describe-scaling-activities command, which queries the Auto Scaling service directly for a detailed history of all actions performed on that group.
This command provides the log for your environment’s scaling behavior. When an instance is launched or terminated, the output from this script shows the precise timestamp, the cause of the event, and a description of what happened. This level of detail is critical for debugging and understanding the automatic behavior of your environment.
The eb events command provides a high-level event stream for an environment, but it often obscures the specific root cause of a scaling action. For example, eb events might report that an instance was removed from the environment, but it won’t distinguish between a termination due to a failed health check versus a normal scale-down operation. This mini script provides that low-level detail directly from the source.
This script is primarily a diagnostic and troubleshooting tool. It is the first command you should run when an environment is scaling unexpectedly or failing to scale when you believe it should. If you are experiencing unexplained instance terminations, this log will likely reveal whether they are caused by failing health checks or a misconfigured scaling policy. It is also useful for post-incident reviews to reconstruct the exact timeline of automated scaling responses.
That’s Pretty Much All For Now
And there you have it. Managing a fleet of Elastic Beanstalk environments doesn’t have to be a manual process of clicking through the AWS console. By looking past the convenient eb command and reaching for the more fundamental aws CLI, it is possible to unlock a much deeper level of control and insight.
From programmatically setting scaling policies and auditing instance types across dozens of applications, to getting a real-time snapshot of your fleet’s capacity and digging into the forensic history of a single environment, these scripts allow to switch from managing environments one by one to orchestrating them as a cohesive whole.
The potential the scripts reveal also trascend their usefulness when untweaked. They are also a starting point to build the exact solution you need.
If you wish to contact Álvaro Martínez Majado for professional matters or regarding this post, please email at [email protected].