# The Amazon EC2 instances for your Elastic Beanstalk environment
This topic explains the Amazon EC2 instances and the configuration options that affect your Elastic Beanstalk environment.
When you create a web server environment, AWS Elastic Beanstalk creates one or more Amazon Elastic Compute Cloud (Amazon EC2) virtual machines, known as *Instances*.
The instances in your environment are configured to run web apps on the platform that you choose. You can make changes to various properties and behaviors of your environment's instances when you create your environment or after it's already running. Or, you can already make these changes by modifying the source code that you deploy to the environment. For for more information, see [Configuration options](command-options.md).
**Note**
The [Auto Scaling group](using-features.managing.as.md) in your environment manages the Amazon EC2 instances that run your application. When you make configuration changes that are described in this topic, the launch configuration also changes. The launch configuration is either an Amazon EC2 launch template or an Auto Scaling group launch configuration resource. This change requires [replacement of all instances](environments-updating.md). It also triggers either a [rolling update](using-features.rollingupdates.md) or [immutable update](environmentmgmt-updates-immutable.md), depending on which one is configured.
**EC2 instance purchasing options**
Elastic Beanstalk supports several Amazon EC2 [instance purchasing options](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html):
+ **On-Demand** — An *On-Demand Instance *is a pay-as-you-go resource—there's no long-term commitment required when you use it.
+ **Reserved** — A *Reserved Instance *is a pre-purchased billing discount applied automatically to matching On-Demand instances in your environment.
+ **Spot** — A *Spot Instance *is an unused Amazon EC2 instance that is available for less than the On-Demand price. You can enable and configure the allocation of Spot Instances in your environment. For more information, see [Auto Scaling your Elastic Beanstalk environment instances](using-features.managing.as.md).
**Topics**
+ [Amazon EC2 instance types](using-features.managing.ec2.instance-types.md)
+ [Configuring Amazon EC2 instances using the Elastic Beanstalk console](using-features.managing.ec2.console.md)
+ [Managing EC2 security groups](using-features.managing.ec2.instances.sg.md)
+ [Configuring Amazon EC2 security groups and instance types using the AWS CLI](using-features.managing.ec2.aws-cli.md)
+ [Configuring Amazon EC2 instances with namespace options](using-features.managing.ec2.namespace.md)
+ [Configuring the IMDS on your Elastic Beanstalk environment's instances](environments-cfg-ec2-imds.md)
# Amazon EC2 instance types
This topic explains the term *instance type*. When you create a new environment, Elastic Beanstalk provisions Amazon EC2 instances that are based on the Amazon EC2 *instance types *that you choose. The instance types that you choose determine the host hardware that runs your instances. EC2 instance types can be categorized by which processor architecture each is based on. Elastic Beanstalk supports instance types based on the following processor architectures: AWS Graviton 64-bit Arm architecture (arm64), 64-bit architecture (x86), and 32-bit architecture (i386). Elastic Beanstalk selects the x86 processor architecture by default when you create a new environment.
**Note**
The i386 32-bit architecture is no longer supported by the majority of Elastic Beanstalk platforms. We recommended that you choose the x86 or arm64 architecture types instead. Elastic Beanstalk provides [configuration options](command-options.md) for i386 processor instance types in the [`aws:ec2:instances`](command-options-general.md#command-options-general-ec2instances) namespace.
All of the instance types in the configuration for a given Elastic Beanstalk environment must have the same type of processor architecture. Assume that you add a new instance type to an existing environment that already has a t2.medium instance type, which is based on x86 architecture. You can only add another instance type of the same architecture, such as t2.small. If you want to replace the existing instance types with those from a different architecture, you can do so. But make sure that all of the instance types in the command are based on the same type of architecture.
Elastic Beanstalk regularly adds support for new compatible instance types after Amazon EC2 introduces them. For information about instance types that are available, see [Instance types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) in the *Amazon EC2 User Guide*.
**Note**
Elastic Beanstalk now offers support for Graviton on all of the latest Amazon Linux 2 platforms across all AWS Graviton supported Regions. For more information about creating an Elastic Beanstalk environment with arm64 based instances types, see [Configuring Amazon EC2 instances using the Elastic Beanstalk console](using-features.managing.ec2.console.md).
Create new environments that run Amazon EC2 instances on arm64 architecture and migrate your existing applications to them with the [deployment options](using-features.deploy-existing-version.md) in Elastic Beanstalk.
To learn more about Graviton arm64 based processors, see these AWS resources:
Benefits — [The AWS Graviton Processor](https://aws.amazon.com/ec2/graviton/)
*Getting started* and other topics, such as *Language-specific considerations* — [Getting started with AWS Graviton](https://github.com/aws/aws-graviton-getting-started#getting-started-with-aws-graviton) GitHub article
# Configuring Amazon EC2 instances using the Elastic Beanstalk console
You can create or modify your Elastic Beanstalk environment's Amazon EC2 instance configuration in the Elastic Beanstalk console.
**Note**
Although the Elastic Beanstalk console doesn't provide the option to change the processor architecture of an existing environment, you can do so with the AWS CLI. For example commands, see [Configuring Amazon EC2 security groups and instance types using the AWS CLI](using-features.managing.ec2.aws-cli.md).
**To configure Amazon EC2 instances in the Elastic Beanstalk console during environment creation**
1. Open the [Elastic Beanstalk console](https://console.aws.amazon.com/elasticbeanstalk), and in the **Regions** list, select your AWS Region.
1. In the navigation pane, choose **Environments**.
1. Choose [Create a new environment](environments-create-wizard.md) to start creating your environment.
1. On the wizard's main page, before choosing **Create environment**, choose **Configure more options**.
1. In the **Instances** configuration category, choose **Edit**. Make changes to settings in this category, and then choose **Apply**. For setting descriptions, see the section [Instances category settings](#using-features.managing.ec2.console.instances) on this page.
1. In the **Capacity** configuration category, choose **Edit**. Make changes to settings in this category, and then choose **Continue**. For setting descriptions, see the section [Capacity category settings](#using-features.managing.ec2.console.capacity) on this page.
**Selecting processor architecture**
Scroll down to **Processor** to select a processor architecture for your EC2 instances. The console lists processor architectures that are supported by the platform that you chose earlier in the **Create environment** panel.
If you don't see the processor architecture that you need, return to the configuration category list to select a platform that supports it. From the **Modify Capacity** panel, choose **Cancel**. Then, choose **Change platform version** to choose new platform settings. Next, in the **Capacity** configuration category choose **Edit** tot see the processor architecture choices again.
![\[Amazon EC2 instance settings on Elastic Beanstalk capacity configuration window for running environment\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-env-config-ec2-capacity-create-env-page.png)
1. Choose **Save**, and then make any other configuration changes that your environment requires.
1. Choose **Create environment**.
**To configure a running environment’s Amazon EC2 instances in the Elastic Beanstalk console**
1. Open the [Elastic Beanstalk console](https://console.aws.amazon.com/elasticbeanstalk), and in the **Regions** list, select your AWS 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 **Instances** configuration category, choose **Edit**. Make changes to settings in this category, and then choose **Apply**. For setting descriptions, see the section [Instances category settings](#using-features.managing.ec2.console.instances) on this page.
1. In the **Capacity** configuration category, choose **Edit**. Make changes to settings in this category, and then choose **Continue**. For setting descriptions, see the section [Capacity category settings](#using-features.managing.ec2.console.capacity) on this page.
## Instances category settings
The following settings related to Amazon EC2 instances are available in the **Instances** configuration category.
**Topics**
+ [Monitoring interval](#using-features.managing.ec2.monitoring-interval)
+ [Root volume (boot device)](#using-features.managing.ec2.rootvolume)
+ [Instance metadata service](#using-features.managing.ec2.imds)
+ [EC2 security groups](#using-features.managing.ec2.securitygroups)
![\[Amazon EC2 instance settings on Elastic Beanstalk instances configuration window\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-env-config-ec2-instances-page.png)
### Monitoring interval
By default, the instances in your environment publish [basic health metrics](using-features.healthstatus.md) to Amazon CloudWatch at five-minute intervals at no additional cost.
For more detailed reporting, you can set the **Monitoring interval** to **1 minute** to increase the frequency that the resources in your environment publish [basic health metrics](using-features.healthstatus.md#monitoring-basic-cloudwatch) to CloudWatch at. CloudWatch service charges apply for one-minute interval metrics. For more information, see [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/).
### Root volume (boot device)
Each instance in your environment is configured with a root volume. The root volume is the Amazon EBS block device attached to the instance to store the operating system, libraries, scripts, and your application source code. By default, all platforms use general-purpose SSD block devices for storage.
You can modify **Root volume type** to use magnetic storage or provisioned IOPS SSD volume types and, if needed, increase the volume size. For provisioned IOPS volumes, you must also select the number of **IOPS** to provision. **Throughput** is only applicable to gp3 SSD volume types. You might enter the desired throughput to provision. It can range between 125 and 1000 mebibytes per second (MiB/s). Select the volume type that meets your performance and price requirements.
**Important**
The `RootVolumeType` 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).
For more information, see [Amazon EBS Volume Types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html) in the *Amazon EC2 User Guide* and [Amazon EBS Product Details](https://aws.amazon.com/ebs/details/).
### Instance metadata service
The instance metadata service (IMDS) is an on-instance component that code on the instance uses to securely access instance metadata. Code can access instance metadata from a running instance using one of two methods. They are Instance Metadata Service Version 1 (IMDSv1) or Instance Metadata Service Version 2 (IMDSv2). IMDSv2 is more secure. Disable IMDSv1 to enforce IMDSv2. For more information, see [Configuring the IMDS on your Elastic Beanstalk environment's instances](environments-cfg-ec2-imds.md).
**Note**
The IMDS section on this configuration page appears only for platform versions that support IMDSv2.
### EC2 security groups
The security groups that are attached to your instances determine which traffic is allowed to reach and exit the instances.
The default EC2 security group that Elastic Beanstalk creates allows all incoming traffic from the internet or load balancers on the standard ports for HTTP (80) and SSH(22). You may also define your own custom security groups to designate firewall rules for the EC2 instances. The security groups can allow traffic on other ports or from other sources. For example, you can create a security group for SSH access that allows inbound traffic on port 22 from a restricted IP address range. Or for additional security, you can create one that allows traffic from a bastion host that only you can access.
You can select to opt out your environment from the default EC2 security group by setting the `DisableDefaultEC2SecurityGroup` option in the [aws:autoscaling:launchconfiguration](command-options-general.md#command-options-general-autoscalinglaunchconfiguration) namespace to `true`. This option is not available in the console, but you can set it with the AWS CLI. For more information, see [Managing EC2 security groups](using-features.managing.ec2.instances.sg.md).
For more information about Amazon EC2 security groups, see [Amazon EC2 Security Groups](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html) in the *Amazon EC2 User Guide*.
**Note**
To allow traffic between environment A's instances and environment B's instances, you can add a rule to the security group that Elastic Beanstalk attached to environment B. Then, you can specify the security group that Elastic Beanstalk attached to environment A. This allows inbound traffic from, or outbound traffic to, environment A's instances. However, doing so creates a dependency between the two security groups. If you later try to terminate environment A, Elastic Beanstalk can't delete the environment's security group, because environment B's security group is dependent on it.
Therefore, we recommend that you instead first create a separate security group. Then, attach it to environment A, and specify it in a rule of environment B's security group.
## Capacity category settings
The following settings related to Amazon EC2 instances are available in the **Capacity** configuration category.
**Topics**
+ [Instance types](#using-features.managing.ec2.instancetypes)
+ [AMI ID](#using-features.managing.ec2.customami)
![\[Amazon EC2 instance settings on Elastic Beanstalk capacity configuration window for create environment\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-env-config-ec2-capacity-page2.png)
### Instance types
The **Instance types** setting determines the type of Amazon EC2 instance that's launched to run your application. This configuration page shows a list of **Instance types**. You can select one or more instance types. The Elastic Beanstalk console only displays the instance types based on the processor architecture that's configured for your environment. Therefore, you can only add instance types of the same processor architecture.
**Note**
Although the Elastic Beanstalk console doesn't provide the option to change the processor architecture of an existing environment, you can do so with the AWS CLI. For example commands, see [Configuring Amazon EC2 security groups and instance types using the AWS CLI](using-features.managing.ec2.aws-cli.md).
Choose an instance that's powerful enough to run your application under load, but not so powerful that it's idle most of the time. For development purposes, the t2 family of instances provides a moderate amount of power with the ability to burst for short periods of time. For large-scale, high-availability applications, use a pool of instances to ensure that capacity isn't too strongly affected if any single instance goes down. Start with an instance type that you can use to run five instances under moderate loads during normal hours. If any instance fails, the rest of the instances can absorb the rest of the traffic. The capacity buffer also allows time for the environment to scale up as traffic begins to rise during peak hours.
For more information about Amazon EC2 instance families and types, see [Instance types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) in the *Amazon EC2 User Guide*. To determine which instance types meet your requirements and their supported Regions, see [Available instance types](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/instance-types.html#AvailableInstanceTypes) in the *Amazon EC2 User Guide*.
### AMI ID
The Amazon Machine Image (AMI) is the Amazon Linux or Windows Server machine image that Elastic Beanstalk uses to launch Amazon EC2 instances in your environment. Elastic Beanstalk provides machine images that contain the tools and resources required to run your application.
Elastic Beanstalk selects a default AMI for your environment based on the Region, platform version and processor architecture that you choose. If you have created a [custom AMI](using-features.customenv.md), replace the default AMI ID with your own default custom one.
# Managing EC2 security groups
When Elastic Beanstalk creates an environment, it assigns a default security group to the EC2 instances that are launched with it. The security groups that are attached to your instances determine which traffic is allowed to reach and exit the instances.
The default EC2 security group that Elastic Beanstalk creates allows all incoming traffic from the internet or load balancers on the standard ports for HTTP (80) and SSH(22). You may also define your own custom security groups to designate firewall rules for the EC2 instances. The security groups can allow traffic on other ports or from other sources. For example, you can create a security group for SSH access that allows inbound traffic on port 22 from a restricted IP address range. Or for additional security, you can create one that allows traffic from a bastion host that only you can access.
You can select to opt out your environment from the default EC2 security group by setting the `DisableDefaultEC2SecurityGroup` option in the [aws:autoscaling:launchconfiguration](command-options-general.md#command-options-general-autoscalinglaunchconfiguration) namespace to `true`. Use the [AWS CLI](using-features.managing.ec2.aws-cli.md) or configuration files to apply this option to your environment and to attach custom security groups to the EC2 instances.
## Managing EC2 security groups in multi-instance environments
If you create a custom EC2 security group in a multi-instance environment you must also consider how the load balancers and incoming traffic rules keep your instances secure and accessible.
Inbound traffic to an environment with multiple EC2 instances is managed by the [load balancer](using-features.managing.elb.md), which directs incoming traffic among all of the EC2 instances. When Elastic Beanstalk creates a default EC2 security group, it also defines inbound rules that allow incoming traffic from the load balancer. Without this inbound rule in the security group, the incoming traffic will not be allowed to enter the instances. This condition would essentially block the instances from external requests.
If you disable the default EC2 security group for a load balanced environment, Elastic Beanstalk validates some configuration rules. If the configuration doesn't meet the validation checks, it issues messages instructing you to provide the required configuration. The validation checks are the following:
+ At least one security group must be assigned to the load balancer using the `SecurityGroups` option of the [aws:elbv2:loadbalancer](command-options-general.md#command-options-general-elbv2) or [aws:elb:loadbalancer](command-options-general.md#command-options-general-elbloadbalancer), depending on whether it's an application load balancer or classic load balancer, respectively. For AWS CLI examples see [Configuring with the AWS CLI](using-features.managing.ec2.aws-cli.md).
+ Inbound traffic rules must exist that allow your EC2 instances to receive traffic from the load balancer. Both your EC2 security groups and your load balancer security groups must reference these inbound rules. For more information, see the [Inbound rules for traffic](#using-features.managing.ec2.instances.sg.load-balancer-security.rules) section that follows.
### Inbound rules for traffic
The EC2 security group(s) for a multi-instance environment, must include an inbound rule that references the load balancer security group. This applies to environments with any type of load balancer, dedicated or shared, and with either custom or default load balancer security groups.
You can view all of the security groups that are attached to your environment components in the EC2 console. The following image shows the EC2 console listing of security groups that Elastic Beanstalk creates by default during the create environment operation.
The **Security Groups** screen shows environments and their associated security groups. Both *GettingStarted-env* and *GettingStarted3-env* are multi-instance environments with dedicated load balancers. Each of these environments has two security groups listed, one for the EC2 instances and another for the load balancer. Elastic Beanstalk creates these security groups when it creates the environments. *GettingStarted5-env* doesn't have a load balancer security group, because it only has one EC2 instance, and thus no load balancer.
The **Inbound rules** screen drills down into the EC2 security group for the instances of *GettingStarted3-env*. This example defines the inbound rules for the EC2 security group. Note that the *Source* column in the *Inbound rules* lists the security group id of the load balancer security group listed in the prior image. This rule allows the EC2 instances of *GettingStarted3-env* to receive inbound traffic from that specific load balancer on port 80.
![\[Amazon EC2 console displays Elastic Beanstalk security groups for each environment.\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-env-config-ec2-ec2console-sg-to-rule.png)
For more information, see [ Change security groups for your instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/changing-security-group.html) and [ Elastic Load Balancing rules](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules-reference.html#sg-rules-elb) in the *Amazon EC2 User Guide*.
# Configuring Amazon EC2 security groups and instance types using the AWS CLI
You can use the AWS Command Line Interface (AWS CLI) to configure the Amazon EC2 instances in your Elastic Beanstalk environments.
## Configuring EC2 security groups using the AWS CLI
This topic provides examples for different EC2 security group configurations for both single-instance and load balanced (multi-instance) environments. For more information about the options in these examples, see [aws:autoscaling:launchconfiguration](command-options-general.md#command-options-general-autoscalinglaunchconfiguration).
**Notes**
The create environment operation provides an EC2 security group by default. It also creates an environment with an application load balancer by default.
The update environment operation can be used to either disable or enable the default EC2 security group for your environment with the boolean option `DisableDefaultEC2SecurityGroup`. *Example 5* shows how to set your environment back to the default security configuration if you had previously modified it.
The following examples show a [create-environment](https://docs.aws.amazon.com/cli/latest/reference/elasticbeanstalk/create-environment.html) command opting out of the default EC2 security group and providing custom security groups instead. Since the `DisableDefaultEC2SecurityGroup` option is set to `true`, the default EC2 security group that Elastic Beanstalk normally associates to the EC2 instances is not created. Therefore, you must provide other security groups with the `SecurityGroups` option.
Note that the [aws:elasticbeanstalk:environment](command-options-general.md#command-options-general-elasticbeanstalkenvironment) `EnvironmentType` option is set to `SingleInstance`. To create a single instance environment, you must specify this option, because `LoadBalanced` is the default `EnvironmentType`. Since this environment does not include a load balancer, we don't need to specify a load balancer security group.
**Example 1 — New single-instance environment with custom EC2 security groups (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 v6.5.0 applrunning Node.js 22" \
--option-settings \
Namespace=aws:elasticbeanstalk:environment,OptionName=EnvironmentType,Value=SingleInstance \
Namespace=aws:autoscaling:launchconfiguration,OptionName=IamInstanceProfile,Value=aws-elasticbeanstalk-ec2-role \
Namespace=aws:autoscaling:launchconfiguration,OptionName=DisableDefaultEC2SecurityGroup,Value=true \
Namespace=aws:autoscaling:launchconfiguration,OptionName=SecurityGroups,Value=sg-abcdef01, sg-abcdef02 \
Namespace=aws:autoscaling:launchconfiguration,OptionName=EC2KeyName,Value=my-keypair
```
As an alternative, use an `options.json` file to specify the namespace options instead of including them inline.
**Example 2 — New single-instance environment with custom EC2 security groups (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 v6.5.0 running Node.js 22" \
--option-settings file://options.json
```
**Example**
```
### example options.json ###
[
{ "Namespace" : "aws:elasticbeanstalk:environment",
"OptionName" : "EnvironmentType",
"Value" : "SingleInstance"
},
{
"Namespace": "aws:autoscaling:launchconfiguration",
"OptionName": "IamInstanceProfile",
"Value": "aws-elasticbeanstalk-ec2-role"
},
{
"Namespace": "aws:autoscaling:launchconfiguration",
"OptionName": "DisableDefaultEC2SecurityGroup",
"Value": "true"
},
{
"Namespace": "aws:autoscaling:launchconfiguration",
"OptionName": "SecurityGroups",
"Value": "sg-abcdef01, sg-abcdef02"
},
{
"Namespace": "aws:autoscaling:launchconfiguration",
"OptionName": "EC2KeyName",
"Value": "my-keypair"
}
]
```
The following example creates a load-balanced environment. It specifies the [aws:elasticbeanstalk:environment](command-options-general.md#command-options-general-elasticbeanstalkenvironment) namespace option `LoadBalancerType` set to `application`. Since we're disabling the default EC2 security group with the `DisableDefaultEC2SecurityGroup` option, we need to provide our own custom security groups for the EC2 instances again, with the [aws:autoscaling:launchconfiguration](command-options-general.md#command-options-general-autoscalinglaunchconfiguration) `SecurityGroups` option, like the previous example. Since this environment has a load balancer to route traffic, we must provide security groups for the load balancer as well.
To create an environment with a with a classic load balancer, but otherwise the same configuration, update the configuration for the [aws:elasticbeanstalk:environment](command-options-general.md#command-options-general-elasticbeanstalkenvironment) namespace option `LoadBalancerType` to `classic`.
The different load balancer types have different namespaces that hold the options to specify the security groups:
+ application load balancer – [aws:elbv2:loadbalancer](command-options-general.md#command-options-general-elbv2) `SecurityGroups` option
+ classic load balancer – [aws:elb:loadbalancer](command-options-general.md#command-options-general-elbloadbalancer) `SecurityGroups` option
+ network load balancer – since network load balancers do not have security groups, configure the EC2 security groups with VPC identifiers. For more information, see [ Update the security groups for your Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-security-groups.html) in the *User Guide for Network Load Balancers*.
**Example 3 — New multi-instance environment with custom EC2 security groups (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 v6.5.0 running Node.js 22" \
--option-settings file://options.json
```
**Example**
```
### example options.json ###
[
{
"Namespace" : "aws:elasticbeanstalk:environment",
"OptionName" : "EnvironmentType",
"Value" : "LoadBalanced"
},
{
"Namespace" : "aws:elasticbeanstalk:environment",
"OptionName" : "LoadBalancerType",
"Value" : "application"
},
{
"Namespace" : "aws:elbv2:loadbalancer",
"OptionName" : "SecurityGroups",
"Value" : "sg-abcdefghikl012345"
},
{
"Namespace": "aws:autoscaling:launchconfiguration",
"OptionName": "IamInstanceProfile",
"Value": "aws-elasticbeanstalk-ec2-role"
},
{
"Namespace": "aws:autoscaling:launchconfiguration",
"OptionName": "DisableDefaultEC2SecurityGroup",
"Value": "true"
},
{
"Namespace": "aws:autoscaling:launchconfiguration",
"OptionName": "SecurityGroups",
"Value": "sg-abcdef01, sg-abcdef02"
},
{
"Namespace": "aws:autoscaling:launchconfiguration",
"OptionName": "EC2KeyName",
"Value": "my-keypair"
}
]
```
You can disable the default EC2 security group for an existing environment with the [update-environment](https://docs.aws.amazon.com/cli/latest/reference/elasticbeanstalk/update-environment.html) command. The following example command disables the default EC2 security group and assigns the environment's EC2 instances custom EC2 security groups.
Use the example `options.jason` files in examples 4(a), 4(b), or 4(c), depending on whether the environment is load balanced and the type of load balancer. Configuration file 4(a) specifies the security groups for a single-instance environment. Since it doesn't require a load balancer, we only provide the security group for the EC2 instances. Configuration files 4(b) and 4(c) specify the security groups for an application load balancer and a classic load balancer. For these cases we also need to specify security groups for the load balancer.
**Example 4 — Update an existing environment to disable default EC2 security group (namespace options in `options.json` file)**
```
aws elasticbeanstalk update-environment \
--region us-east-1 \
--application-name my-app \
--environment-name my-env \
--solution-stack-name "64bit Amazon Linux 2023 v6.5.0 running Node.js 22" \
--option-settings file://options.json
```
**Example 4(a) — Configuration file for single-instance environment (no load balancer)**
```
### example options.json ###
[
{
"Namespace": "aws:autoscaling:launchconfiguration",
"OptionName": "DisableDefaultEC2SecurityGroup",
"Value": "true"
},
{
"Namespace": "aws:autoscaling:launchconfiguration",
"OptionName": "SecurityGroups",
"Value": "sg-abcdef01, sg-abcdef02"
}
]
```
To update an environment that uses an application load balancer, use the `aws:elbv2:loadbalancer` namespace to specify the security groups for the load balancer.
**Example 4(b) — Configuration file for environment with an application load balancer**
```
### example options.json ###
[
{
"Namespace" : "aws:elbv2:loadbalancer",
"OptionName" : "SecurityGroups",
"Value" : "sg-abcdefghikl012345"
},
{
"Namespace": "aws:autoscaling:launchconfiguration",
"OptionName": "DisableDefaultEC2SecurityGroup",
"Value": "true"
},
{
"Namespace": "aws:autoscaling:launchconfiguration",
"OptionName": "SecurityGroups",
"Value": "sg-abcdef01, sg-abcdef02"
}
]
```
To update an environment that uses a classic load balancer use the `aws:elb:loadbalancer` namespace to specify the security groups for the load balancer.
**Example 4(c) — Configuration file for environment with a classic load balancer**
```
### example options.json ###
[
{
"Namespace" : "aws:elb:loadbalancer",
"OptionName" : "SecurityGroups",
"Value" : "sg-abcdefghikl012345"
},
{
"Namespace": "aws:autoscaling:launchconfiguration",
"OptionName": "DisableDefaultEC2SecurityGroup",
"Value": "true"
},
{
"Namespace": "aws:autoscaling:launchconfiguration",n
"OptionName": "SecurityGroups",
"Value": "sg-abcdef01, sg-abcdef02"
}
]
```
To return your environment to the default behavior and configuration with the default security group that Elastic Beanstalk assigns, use the [update-environment](https://docs.aws.amazon.com/cli/latest/reference/elasticbeanstalk/update-environment.html) command to set the `DisableDefaultEC2SecurityGroup` to `false`. For a multi-instance environment, Elastic Beanstalk also handles the security groups and network traffic rules for your environment's load balancer.
The following example applies to both a single-instance or multi-instance (load balanced) environment:
**Example 5 — Update an environment back to using the default security group (namespace options in `options.json` file)**
```
aws elasticbeanstalk update-environment \
--region us-east-1 \
--application-name my-app \
--environment-name my-env \
--solution-stack-name "64bit Amazon Linux 2023 v6.5.0 running Node.js 22" \
--option-settings file://options.json
```
**Example**
```
### example options.json ###
[
{
"Namespace": "aws:autoscaling:launchconfiguration",
"OptionName": "DisableDefaultEC2SecurityGroup",
"Value": "false"
}
]
```
## Configuring EC2 with instance types using the AWS CLI
This topic provides examples for configuring the instance types of the EC2 instances in your environment.
The first two examples creates a new environment. The command specifies an Amazon EC2 instances type, t4g.small, that's based on arm64 processor architecture. Elastic Beanstalk defaults the Image ID (AMI) for the EC2 instances based on the Region, platform version and instance type. The instance type corresponds to a processor architecture. The `solution-stack-name` parameter applies to platform version.
**Example 1 — create a new arm64 based environment (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 2 v3.4.7 running Docker" \
--option-settings \
Namespace=aws:autoscaling:launchconfiguration,OptionName=IamInstanceProfile,Value=aws-elasticbeanstalk-ec2-role \
Namespace=aws:ec2:instances,OptionName=InstanceTypes,Value=t4g.small
```
As an alternative, use an `options.json` file to specify the namespace options instead of including them inline.
**Example 2 — create a new arm64 based environment (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 2 v3.4.7 running Docker" \
--option-settings file://options.json
```
**Example**
```
### example options.json ###
[
{
"Namespace": "aws:autoscaling:launchconfiguration",
"OptionName": "IamInstanceProfile",
"Value": "aws-elasticbeanstalk-ec2-role"
},
{
"Namespace": "aws:ec2:instances",
"OptionName": "InstanceTypes",
"Value": "t4g.small"
}
]
```
The next two examples update the configuration for an existing environment with the [update-environment](https://docs.aws.amazon.com/cli/latest/reference/elasticbeanstalk/update-environment.html) command. In this example we're adding another instance type that's also based on arm64 processor architecture. For existing environments, all instance types that are added must have the same processor architecture. If you want to replace the existing instance types with those from a different architecture, you can do so. But make sure that all of the instance types in the command have the same type of architecture.
**Example 3 — update an existing arm64 based environment (namespace options inline)**
```
aws elasticbeanstalk update-environment \
--region us-east-1 \
--application-name my-app \
--environment-name my-env \
--solution-stack-name "64bit Amazon Linux 2 v3.4.7 running Docker" \
--option-settings \
Namespace=aws:autoscaling:launchconfiguration,OptionName=IamInstanceProfile,Value=aws-elasticbeanstalk-ec2-role \
Namespace=aws:ec2:instances,OptionName=InstanceTypes,Value=t4g.small,t4g.micro
```
As an alternative, use an `options.json` file to specify the namespace options instead of including them inline.
**Example 4 — update an existing arm64 based environment (namespace options in `options.json` file)**
```
aws elasticbeanstalk update-environment \
--region us-east-1 \
--application-name my-app \
--environment-name my-env \
--solution-stack-name "64bit Amazon Linux 2 v3.4.7 running Docker" \
--option-settings file://options.json
```
**Example**
```
### example options.json ###
[
{
"Namespace": "aws:autoscaling:launchconfiguration",
"OptionName": "IamInstanceProfile",
"Value": "aws-elasticbeanstalk-ec2-role"
},
{
"Namespace": "aws:ec2:instances",
"OptionName": "InstanceTypes",
"Value": "t4g.small, t4g.micro"
}
]
```
The next two examples show more [create-environment](https://docs.aws.amazon.com/cli/latest/reference/elasticbeanstalk/create-environment.html) commands. These examples don't provide values for `InstanceTypes`. When `InstanceTypes` values aren't specified, Elastic Beanstalk defaults to x86 based processor architecture. The Image ID (AMI) for the environment's EC2 instances will default according to the Region, platform version and defaulted instance type. The instance type corresponds to a processor architecture.
**Example 5 — create a new x86 based environment (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 2 v3.4.7 running Docker" \
--option-settings \
Namespace=aws:autoscaling:launchconfiguration,OptionName=IamInstanceProfile,Value=aws-elasticbeanstalk-ec2-role
```
As an alternative, use an `options.json` file to specify the namespace options instead of including them inline.
**Example 6 — create a new x86 based environment (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 2 v3.4.7 running Docker" \
--option-settings file://options.json
```
**Example**
```
### example options.json ###
[
{
"Namespace": "aws:autoscaling:launchconfiguration",
"OptionName": "IamInstanceProfile",
"Value": "aws-elasticbeanstalk-ec2-role"
}
]
```
# Configuring Amazon EC2 instances with namespace options
You can use the [configuration options](command-options.md) in the `aws:autoscaling:launchconfiguration` namespace to configure the instances for your environment, including additional options that aren't available in the console.
**Important**
The `DisableIMDSv1`, `RootVolumeType`, or `BlockDeviceMappings` 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 [configuration file](ebextensions.md) example uses the basic configuration options that are explained in this topic. To see examples of additional configuration options when you need to specify security groups for load balancers, see [Configuring with the AWS CLI](using-features.managing.ec2.aws-cli.md).
```
option_settings:
aws:autoscaling:launchconfiguration:
SecurityGroups: my-securitygroup
MonitoringInterval: "1 minute"
DisableIMDSv1: false
DisableDefaultEC2SecurityGroup: true
SecurityGroups: "sg-abcdef01, sg-abcdef02"
EC2KeyName: my-keypair
IamInstanceProfile: "aws-elasticbeanstalk-ec2-role"
BlockDeviceMappings: "/dev/sdj=:100,/dev/sdh=snap-51eef269,/dev/sdb=ephemeral0"
aws:elasticbeanstalk:environment:
EnvironmentType: SingleInstance
```
The `DisableDefaultEC2SecurityGroup` and `BlockDeviceMappings` are not available in the console.
You can use `BlockDeviceMappings` to configure additional block devices for your instances. For more information, see [Block Device Mapping](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/block-device-mapping-concepts.html) in the *Amazon EC2 User Guide*.
The EB CLI and Elastic Beanstalk console apply recommended values for the preceding options. You must remove these settings if you want to use configuration files to configure the same. See [Recommended values](command-options.md#configuration-options-recommendedvalues) for details.
# Configuring the IMDS on your Elastic Beanstalk environment's instances
This topic describes the Instance Metadata Service (IMDS).
*Instance metadata* is data that's related to an Amazon Elastic Compute Cloud (Amazon EC2) instance that applications can use to configure or manage the running instance. The instance metadata service (IMDS) is an on-instance component that code on the instance uses to securely access instance metadata. This code can be Elastic Beanstalk platform code on your environment instances, the AWS SDK that your application might be using, or even your application's own code. For more information, see [Instance metadata and user data](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) in the *Amazon EC2 User Guide*.
Code can access instance metadata from a running instance using one of two methods: Instance Metadata Service Version 1 (IMDSv1) or Instance Metadata Service Version 2 (IMDSv2). IMDSv2 uses session-oriented requests and mitigates several types of vulnerabilities that could be used to try to access the IMDS. For information about these two methods, see [Configuring the instance metadata service](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html) in the *Amazon EC2 User Guide*.
**Topics**
+ [Platform support for IMDS](#environments-cfg-ec2-imds.plat)
+ [Choosing IMDS methods](#environments-cfg-ec2-imds.choose)
+ [Configuring IMDS using the Elastic Beanstalk console](#environments-cfg-ec2-imds.console)
+ [The aws:autoscaling:launchconfiguration namespace](#environments-cfg-ec2-imds.namespace)
## Platform support for IMDS
Elastic Beanstalk platforms running on Amazon Linux 2 and Amazon Linux 2023 and Windows server all support both IMDSv1 and IMDSv2. For more information, see [Configuring IMDS using the Elastic Beanstalk console](#environments-cfg-ec2-imds.console)
## Choosing IMDS methods
When making a decision about the IMDS methods that you want your environment to support, consider the following use cases:
+ *AWS SDK* – If your application uses an AWS SDK, make sure you use an the latest version of the SDK. The AWS SDKs make IMDS calls, and newer SDK versions use IMDSv2 whenever possible. If you ever disable IMDSv1, or if your application uses an old SDK version, IMDS calls might fail.
+ *Your application code* – If your application makes IMDS calls, consider using the AWS SDK so that you can make the calls instead of making direct HTTP requests. This way, you don't need to make code changes to switch between IMDS methods. The AWS SDK uses IMDSv2 whenever possible.
+ *Elastic Beanstalk platform code* – Our code makes IMDS calls through the AWS SDK, and therefore uses IMDSv2 on all supporting platform versions. If your code uses an up-to-date AWS SDK and makes all IMDS calls through the SDK, you can safely disable IMDSv1.
## Configuring IMDS using the Elastic Beanstalk console
You can modify your Elastic Beanstalk environment's Amazon EC2 instance configuration in the Elastic Beanstalk console.
**Important**
The `DisableIMDSv1` 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).
**To configure IMDS on your Amazon EC2 instances in the Elastic Beanstalk console**
1. Open the [Elastic Beanstalk console](https://console.aws.amazon.com/elasticbeanstalk), and in the **Regions** list, select your AWS 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 **Instance traffic and scaling** configuration category, choose **Edit**.
1. Set **Disable IMDSv1** to enforce IMDSv2. Clear **Disable IMDSv1** to enable both IMDSv1 and IMDSv2.
1. To save the changes choose **Apply** at the bottom of the page.
## The aws:autoscaling:launchconfiguration namespace
You can use a [configuration option](command-options.md) in the `aws:autoscaling:launchconfiguration` namespace to configure IMDS on your environment's instances.
**Important**
The `DisableIMDSv1` 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 [configuration file](ebextensions.md) example disables IMDSv1 using the `DisableIMDSv1` option.
```
option_settings:
aws:autoscaling:launchconfiguration:
DisableIMDSv1: true
```
Set **DisableIMDSv1** to `true` to disable IMDSv1 and enforce IMDSv2.
Set **DisableIMDSv1** to `false` to enable both IMDSv1 and IMDSv2.