# Deploying applications to Elastic Beanstalk environments Deployments You can use the AWS Elastic Beanstalk console to upload an updated [source bundle](applications-sourcebundle.md) and deploy it to your Elastic Beanstalk environment, or redeploy a previously uploaded version. Each deployment is identified by a deployment ID. Deployment IDs start at `1` and increment by one with each deployment and instance configuration change. If you enable [enhanced health reporting](health-enhanced.md), Elastic Beanstalk displays the deployment ID in both the [health console](health-enhanced-console.md) and the [EB CLI](health-enhanced-ebcli.md) when it reports instance health status. The deployment ID helps you determine the state of your environment when a rolling update fails. Elastic Beanstalk provides several deployment policies and settings. For details about configuring a policy and additional settings, see [Deployment policies and settings](using-features.rolling-version-deploy.md). The following table lists the policies and the kinds of environments that support them. **Supported deployment policies** | Deployment policy | Load-balanced environments | Single-instance environments | Legacy Windows Server environments† | | --- | --- | --- | --- | | **All at once** | ![\[Yes\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/icon-yes.png) Yes | ![\[Yes\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/icon-yes.png) Yes | ![\[Yes\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/icon-yes.png) Yes | | **Rolling** | ![\[Yes\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/icon-yes.png) Yes | ![\[No\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/icon-no.png) No | ![\[Yes\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/icon-yes.png) Yes | | **Rolling with an additional batch** | ![\[Yes\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/icon-yes.png) Yes | ![\[No\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/icon-no.png) No | ![\[No\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/icon-no.png) No | | **Immutable** | ![\[Yes\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/icon-yes.png) Yes | ![\[Yes\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/icon-yes.png) Yes | ![\[No\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/icon-no.png) No | | **Traffic splitting** | ![\[Yes\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/icon-yes.png) Yes (Application Load Balancer) | ![\[No\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/icon-no.png) No | ![\[No\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/icon-no.png) No | † In this table, a *Legacy Windows Server environment* is an environment based on a [Windows Server platform configuration](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.net) that uses an IIS version earlier than IIS 8.5. **Warning** Some policies replace all instances during the deployment or update. This causes all accumulated [Amazon EC2 burst balances](https://docs.aws.amazon.com/AWSEC2/latest/DeveloperGuide/burstable-performance-instances.html) to be lost. It happens in the following cases: Managed platform updates with instance replacement enabled Immutable updates Deployments with immutable updates or traffic splitting enabled ## Choosing a deployment policy Choosing the right deployment policy for your application is a tradeoff of a few considerations, and depends on your particular needs. The [Deployment policies and settings](using-features.rolling-version-deploy.md) page has more information about each policy, and a detailed description of the workings of some of them. The following list provides summary information about the different deployment policies and adds related considerations. + **All at once** – The quickest deployment method. Suitable if you can accept a short loss of service, and if quick deployments are important to you. With this method, Elastic Beanstalk deploys the new application version to each instance. Then, the web proxy or application server might need to restart. As a result, your application might be unavailable to users (or have low availability) for a short time. + **Rolling** – Avoids downtime and minimizes reduced availability, at a cost of a longer deployment time. Suitable if you can't accept any period of completely lost service. With this method, your application is deployed to your environment one batch of instances at a time. Most bandwidth is retained throughout the deployment. + **Rolling with additional batch** – Avoids any reduced availability, at a cost of an even longer deployment time compared to the *Rolling* method. Suitable if you must maintain the same bandwidth throughout the deployment. With this method, Elastic Beanstalk launches an extra batch of instances, then performs a rolling deployment. Launching the extra batch takes time, and ensures that the same bandwidth is retained throughout the deployment. + **Immutable** – A slower deployment method, that ensures your new application version is always deployed to new instances, instead of updating existing instances. It also has the additional advantage of a quick and safe rollback in case the deployment fails. With this method, Elastic Beanstalk performs an [immutable update](environmentmgmt-updates-immutable.md) to deploy your application. In an immutable update, a second Auto Scaling group is launched in your environment and the new version serves traffic alongside the old version until the new instances pass health checks. + **Traffic splitting** – A canary testing deployment method. Suitable if you want to test the health of your new application version using a portion of incoming traffic, while keeping the rest of the traffic served by the old application version. The following table compares deployment method properties. **Deployment methods** | **Method** | **Impact of failed deployment** | **Deploy time** | **Zero downtime** | **No DNS change** | **Rollback process** | **Code deployed to** | | --- | --- | --- | --- | --- | --- | --- | | All at once | Downtime | ![\[Circular icon with a clock face, indicating time-related functionality or waiting period.\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/clock.png) | ![\[No\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/icon-no.png) No | ![\[Yes\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/icon-yes.png) Yes | Manual redeploy | Existing instances | | Rolling | Single batch out of service; any successful batches before failure running new application version | ![\[Circular icon with a clock face, indicating time-related functionality or waiting period.\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/clock.png)![\[Circular icon with a clock face, indicating time-related functionality or waiting period.\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/clock.png)† | ![\[Yes\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/icon-yes.png) Yes | ![\[Yes\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/icon-yes.png) Yes | Manual redeploy | Existing instances | | Rolling with an additional batch | Minimal if first batch fails; otherwise, similar to Rolling | ![\[Circular icon with a clock face, indicating time-related functionality or waiting period.\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/clock.png)![\[Circular icon with a clock face, indicating time-related functionality or waiting period.\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/clock.png)![\[Circular icon with a clock face, indicating time-related functionality or waiting period.\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/clock.png)† | ![\[Yes\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/icon-yes.png) Yes | ![\[Yes\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/icon-yes.png) Yes | Manual redeploy | New and existing instances | | Immutable | Minimal | ![\[Circular icon with a clock face, indicating time-related functionality or waiting period.\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/clock.png)![\[Circular icon with a clock face, indicating time-related functionality or waiting period.\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/clock.png)![\[Circular icon with a clock face, indicating time-related functionality or waiting period.\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/clock.png)![\[Circular icon with a clock face, indicating time-related functionality or waiting period.\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/clock.png) | ![\[Yes\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/icon-yes.png) Yes | ![\[Yes\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/icon-yes.png) Yes | Terminate new instances | New instances | | Traffic splitting | Percentage of client traffic routed to new version temporarily impacted | ![\[Circular icon with a clock face, indicating time-related functionality or waiting period.\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/clock.png)![\[Circular icon with a clock face, indicating time-related functionality or waiting period.\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/clock.png)![\[Circular icon with a clock face, indicating time-related functionality or waiting period.\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/clock.png)![\[Circular icon with a clock face, indicating time-related functionality or waiting period.\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/clock.png)†† | ![\[Yes\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/icon-yes.png) Yes | ![\[Yes\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/icon-yes.png) Yes | Reroute traffic and terminate new instances | New instances | | Blue/green | Minimal | ![\[Circular icon with a clock face, indicating time-related functionality or waiting period.\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/clock.png)![\[Circular icon with a clock face, indicating time-related functionality or waiting period.\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/clock.png)![\[Circular icon with a clock face, indicating time-related functionality or waiting period.\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/clock.png)![\[Circular icon with a clock face, indicating time-related functionality or waiting period.\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/clock.png) | ![\[Yes\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/icon-yes.png) Yes | ![\[No\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/icon-no.png) No | Swap URL | New instances | † *Varies depending on batch size.* †† *Varies depending on **evaluation time** option setting.* ## Deploying a new application version You can perform deployments from your environment's dashboard. **To deploy a new application version to an Elastic Beanstalk environment** 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. Choose **Upload and deploy**. 1. Use the on-screen form to upload the application source bundle. 1. Choose **Deploy**. ## Redeploying a previous version You can also deploy a previously uploaded version of your application to any of its environments from the application versions page. **To deploy an existing application version to an existing environment** 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 **Applications**, and then choose your application's name from the list. 1. In the navigation pane, find your application's name and choose **Application versions**. 1. Select the application version to deploy. 1. Choose **Actions**, and then choose **Deploy**. 1. Select an environment, and then choose **Deploy**. ## Other ways to deploy your application If you deploy often, consider using the [Elastic Beanstalk Command Line Interface](eb-cli3.md) (EB CLI) to manage your environments. The EB CLI creates a repository alongside your source code. It can also create a source bundle, upload it to Elastic Beanstalk, and deploy it with a single command. For deployments that depend on resource configuration changes or a new version that can't run alongside the old version, you can launch a new environment with the new version and perform a CNAME swap for a [blue/green deployment](using-features.CNAMESwap.md). To automate your build, test, and deployment processes, you can implement continuous integration and continuous deployment (CI/CD) with your Elastic Beanstalk environment. For more information, see [Implementing CI/CD integration with your Elastic Beanstalk environment](deployments.cicd.md). # Deployment policies and settings Deployment options AWS Elastic Beanstalk provides several options for how [deployments](using-features.deploy-existing-version.md) are processed, including deployment policies (*All at once*, *Rolling*, *Rolling with additional batch*, *Immutable*, and *Traffic splitting*) and options that let you configure batch size and health check behavior during deployments. By default, your environment uses all-at-once deployments. If you created the environment with the EB CLI and it's a scalable environment (you didn't specify the `--single` option), it uses rolling deployments. With *rolling deployments*, Elastic Beanstalk splits the environment's Amazon EC2 instances into batches and deploys the new version of the application to one batch at a time. It leaves the rest of the instances in the environment running the old version of the application. During a rolling deployment, some instances serve requests with the old version of the application, while instances in completed batches serve other requests with the new version. For details, see [How rolling deployments work](#environments-cfg-rollingdeployments-method). To maintain full capacity during deployments, you can configure your environment to launch a new batch of instances before taking any instances out of service. This option is known as a *rolling deployment with an additional batch*. When the deployment completes, Elastic Beanstalk terminates the additional batch of instances. *Immutable deployments* perform an [immutable update](environmentmgmt-updates-immutable.md) to launch a full set of new instances running the new version of the application in a separate Auto Scaling group, alongside the instances running the old version. Immutable deployments can prevent issues caused by partially completed rolling deployments. If the new instances don't pass health checks, Elastic Beanstalk terminates them, leaving the original instances untouched. *Traffic-splitting deployments* let you perform canary testing as part of your application deployment. In a traffic-splitting deployment, Elastic Beanstalk launches a full set of new instances just like during an immutable deployment. It then forwards a specified percentage of incoming client traffic to the new application version for a specified evaluation period. If the new instances stay healthy, Elastic Beanstalk forwards all traffic to them and terminates the old ones. If the new instances don't pass health checks, or if you choose to abort the deployment, Elastic Beanstalk moves traffic back to the old instances and terminates the new ones. There's never any service interruption. For details, see [How traffic-splitting deployments work](#environments-cfg-trafficsplitting-method). **Warning** Some policies replace all instances during the deployment or update. This causes all accumulated [Amazon EC2 burst balances](https://docs.aws.amazon.com/AWSEC2/latest/DeveloperGuide/burstable-performance-instances.html) to be lost. It happens in the following cases: Managed platform updates with instance replacement enabled Immutable updates Deployments with immutable updates or traffic splitting enabled If your application doesn't pass all health checks, but still operates correctly at a lower health status, you can allow instances to pass health checks with a lower status, such as `Warning`, by modifying the **Healthy threshold** option. If your deployments fail because they don't pass health checks and you need to force an update regardless of health status, specify the **Ignore health check** option. When you specify a batch size for rolling updates, Elastic Beanstalk also uses that value for rolling application restarts. Use rolling restarts when you need to restart the proxy and application servers running on your environment's instances without downtime. ## Configuring application deployments In the [environment management console](environments-console.md), enable and configure batched application version deployments by editing **Updates and Deployments** on the environment's **Configuration** page. **To configure deployments (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 **Rolling updates and deployments** configuration category, choose **Edit**. 1. In the **Application Deployments** section, choose a **Deployment policy**, batch settings, and health check options. 1. To save the changes choose **Apply** at the bottom of the page. The **Application deployments** section of the **Rolling updates and deployments** page has the following options for application deployments: + **Deployment policy** – Choose from the following deployment options: + **All at once** – Deploy the new version to all instances simultaneously. All instances in your environment are out of service for a short time while the deployment occurs. + **Rolling** – Deploy the new version in batches. Each batch is taken out of service during the deployment phase, reducing your environment's capacity by the number of instances in a batch. + **Rolling with additional batch** – Deploy the new version in batches, but first launch a new batch of instances to ensure full capacity during the deployment process. + **Immutable** – Deploy the new version to a fresh group of instances by performing an [immutable update](environmentmgmt-updates-immutable.md). + **Traffic splitting** – Deploy the new version to a fresh group of instances and temporarily split incoming client traffic between the existing application version and the new one. For the **Rolling** and **Rolling with additional batch** deployment policies you can configure: + **Batch size** – The size of the set of instances to deploy in each batch. Choose **Percentage** to configure a percentage of the total number of EC2 instances in the Auto Scaling group (up to 100 percent), or choose **Fixed** to configure a fixed number of instances (up to the maximum instance count in your environment's Auto Scaling configuration). For the **Traffic splitting** deployment policy you can configure the following: + **Traffic split** – The initial percentage of incoming client traffic that Elastic Beanstalk shifts to environment instances running the new application version you're deploying. + **Traffic splitting evaluation time** – The time period, in minutes, that Elastic Beanstalk waits after an initial healthy deployment before proceeding to shift all incoming client traffic to the new application version that you're deploying. ![\[Elastic Beanstalk application deployment configuration page\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/environment-cfg-rollingdeployments.png) The **Deployment preferences** section contains options related to health checks. + **Ignore health check** – Prevents a deployment from rolling back when a batch fails to become healthy within the **Command timeout**. + **Healthy threshold** – Lowers the threshold at which an instance is considered healthy during rolling deployments, rolling updates, and immutable updates. + **Command timeout** – The number of seconds to wait for an instance to become healthy before canceling the deployment or, if **Ignore health check** is set, to continue to the next batch. ![\[Elastic Beanstalk application deployments configuration page\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/environment-cfg-healthchecks.png) ## How rolling deployments work When processing a batch, Elastic Beanstalk detaches all instances in the batch from the load balancer, deploys the new application version, and then reattaches the instances. If you enable [connection draining](environments-cfg-clb.md#using-features.managing.elb.draining), Elastic Beanstalk drains existing connections from the Amazon EC2 instances in each batch before beginning the deployment. After reattaching the instances in a batch to the load balancer, Elastic Load Balancing waits until they pass a minimum number of Elastic Load Balancing health checks (the **Healthy check count threshold** value), and then starts routing traffic to them. If no [health check URL](environments-cfg-clb.md#using-features.managing.elb.healthchecks) is configured, this can happen very quickly, because an instance will pass the health check as soon as it can accept a TCP connection. If a health check URL is configured, the load balancer doesn't route traffic to the updated instances until they return a `200 OK` status code in response to an `HTTP GET` request to the health check URL. Elastic Beanstalk waits until all instances in a batch are healthy before moving on to the next batch. With [basic health reporting](using-features.healthstatus.md), instance health depends on the Elastic Load Balancing health check status. When all instances in the batch pass enough health checks to be considered healthy by Elastic Load Balancing, the batch is complete. If [enhanced health reporting](health-enhanced.md) is enabled, Elastic Beanstalk considers several other factors, including the result of incoming requests. With enhanced health reporting, all instances must pass 12 consecutive health checks with an [OK status](health-enhanced-status.md#health-enhanced-status-ok) within two minutes for web server environments, and 18 health checks within three minutes for worker environments. If a batch of instances does not become healthy within the [command timeout](#environments-cfg-rollingdeployments-console), the deployment fails. After a failed deployment, [check the health of the instances in your environment](health-enhanced-console.md) for information about the cause of the failure. Then perform another deployment with a fixed or known good version of your application to roll back. If a deployment fails after one or more batches completed successfully, the completed batches run the new version of your application while any pending batches continue to run the old version. You can identify the version running on the instances in your environment on the [health page](health-enhanced-console.md#health-enhanced-console-healthpage) in the console. This page displays the deployment ID of the most recent deployment that executed on each instance in your environment. If you terminate instances from the failed deployment, Elastic Beanstalk replaces them with instances running the application version from the most recent successful deployment. ## How traffic-splitting deployments work Traffic-splitting deployments allow you to perform canary testing. You direct some incoming client traffic to your new application version to verify the application's health before committing to the new version and directing all traffic to it. During a traffic-splitting deployment, Elastic Beanstalk creates a new set of instances in a separate temporary Auto Scaling group. Elastic Beanstalk then instructs the load balancer to direct a certain percentage of your environment's incoming traffic to the new instances. Then, for a configured amount of time, Elastic Beanstalk tracks the health of the new set of instances. If all is well, Elastic Beanstalk shifts remaining traffic to the new instances and attaches them to the environment's original Auto Scaling group, replacing the old instances. Then Elastic Beanstalk cleans up—terminates the old instances and removes the temporary Auto Scaling group. **Note** The environment's capacity doesn't change during a traffic-splitting deployment. Elastic Beanstalk launches the same number of instances in the temporary Auto Scaling group as there are in the original Auto Scaling group at the time the deployment starts. It then maintains a constant number of instances in both Auto Scaling groups for the deployment duration. Take this fact into account when configuring the environment's traffic splitting evaluation time. Rolling back the deployment to the previous application version is quick and doesn't impact service to client traffic. If the new instances don't pass health checks, or if you choose to abort the deployment, Elastic Beanstalk moves traffic back to the old instances and terminates the new ones. You can abort any deployment by using the environment overview page in the Elastic Beanstalk console, and choosing **Abort current operation** in **Environment actions**. You can also call the [AbortEnvironmentUpdate](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_AbortEnvironmentUpdate.html) API or the equivalent AWS CLI command. Traffic-splitting deployments require an Application Load Balancer. Elastic Beanstalk uses this load balancer type by default when you create your environment using the Elastic Beanstalk console or the EB CLI. ## Deployment option namespaces You can use the [configuration options](command-options.md) in the [`aws:elasticbeanstalk:command`](command-options-general.md#command-options-general-elasticbeanstalkcommand) namespace to configure your deployments. If you choose the traffic-splitting policy, additional options for this policy are available in the [`aws:elasticbeanstalk:trafficsplitting`](command-options-general.md#command-options-general-elasticbeanstalktrafficsplitting) namespace. Use the `DeploymentPolicy` option to set the deployment type. The following values are supported: + `AllAtOnce` – Disables rolling deployments and always deploys to all instances simultaneously. + `Rolling` – Enables standard rolling deployments. + `RollingWithAdditionalBatch` – Launches an extra batch of instances, before starting the deployment, to maintain full capacity. + `Immutable` – Performs an [immutable update](environmentmgmt-updates-immutable.md) for every deployment. + `TrafficSplitting` – Performs traffic-splitting deployments to canary-test your application deployments. When you enable rolling deployments, set the `BatchSize` and `BatchSizeType` options to configure the size of each batch. For example, to deploy 25 percent of all instances in each batch, specify the following options and values. **Example .ebextensions/rolling-updates.config** ``` option_settings: aws:elasticbeanstalk:command: DeploymentPolicy: Rolling BatchSizeType: Percentage BatchSize: 25 ``` To deploy to five instances in each batch, regardless of the number of instances running, and to bring up an extra batch of five instances running the new version before pulling any instances out of service, specify the following options and values. **Example .ebextensions/rolling-additionalbatch.config** ``` option_settings: aws:elasticbeanstalk:command: DeploymentPolicy: RollingWithAdditionalBatch BatchSizeType: Fixed BatchSize: 5 ``` To perform an immutable update for each deployment with a health check threshold of **Warning**, and proceed with the deployment even if instances in a batch don't pass health checks within a timeout of 15 minutes, specify the following options and values. **Example .ebextensions/immutable-ignorehealth.config** ``` option_settings: aws:elasticbeanstalk:command: DeploymentPolicy: Immutable HealthCheckSuccessThreshold: Warning IgnoreHealthCheck: true Timeout: "900" ``` To perform traffic-splitting deployments, forwarding 15 percent of client traffic to the new application version and evaluating health for 10 minutes, specify the following options and values. **Example .ebextensions/traffic-splitting.config** ``` option_settings: aws:elasticbeanstalk:command: DeploymentPolicy: TrafficSplitting aws:elasticbeanstalk:trafficsplitting: NewVersionPercent: "15" EvaluationTime: "10" ``` 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. # Blue/Green deployments with Elastic Beanstalk Blue/Green deployments Because AWS Elastic Beanstalk performs an in-place update when you update your application versions, your application might become unavailable to users for a short period of time. To avoid this, perform a blue/green deployment. To do this, deploy the new version to a separate environment, and then swap the CNAMEs of the two environments to redirect traffic to the new version instantly. A blue/green deployment is also required if you want to update an environment to an incompatible platform version. For more information, see [Updating your Elastic Beanstalk environment's platform version](using-features.platform.upgrade.md). Blue/green deployments require that your environment runs independently of your production database, if your application uses one. If your environment includes a database that Elastic Beanstalk created on your behalf, the database and connection of the environment isn't preserved unless you take specific actions. If you have a database that you want to retain, use one of the Elastic Beanstalk database lifecycle options. You can choose the Retain option to keep the database and environment operational after decoupling the database. For more information see [Database lifecycle](using-features.managing.db.md#environments-cfg-rds-lifecycle) in the *Configuring environments* chapter of this guide. For instructions on how to configure your application to connect to an Amazon RDS instance that's not managed by Elastic Beanstalk, see [Using Elastic Beanstalk with Amazon RDS](AWSHowTo.RDS.md). **To perform a blue/green deployment** 1. Open the [Elastic Beanstalk console](https://console.aws.amazon.com/elasticbeanstalk), and in the **Regions** list, select your AWS Region. 1. [Clone your current environment](using-features.managing.clone.md), or launch a new environment to run the platform version you want. 1. [Deploy the new application version](using-features.deploy-existing-version.md#deployments-newversion) to the new environment. 1. Test the new version on the new environment. 1. On the environment overview page, choose **Actions**, and then choose **Swap environment URLs**. 1. For **Environment name**, select the current environment. ![\[Swap environment URL page\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-env-swap-url.png) 1. Choose **Swap**. Elastic Beanstalk swaps the CNAME records of the old and new environments, redirecting traffic from the old version to the new version. After Elastic Beanstalk completes the swap operation, verify that the new environment responds when you try to connect to the old environment URL. However, do not terminate your old environment until the DNS changes are propagated and your old DNS records expire. DNS servers don't always clear old records from their cache based on the time to live (TTL) that you set on your DNS records. # Implementing CI/CD integration with your Elastic Beanstalk environment CI/CD integration Elastic Beanstalk integrates with many CI/CD tools to automate your application development workflow. CI/CD practices enable you to automatically build, test, and deploy your applications with minimal manual intervention. Continuous delivery/deployment (CD) extends continuous integration (CI) by automating the deployment process. You can create streamlined deployment pipelines using AWS services like CodePipeline or third-party tools such as Jenkins and GitLab to ensure consistent, reliable deployments to your Elastic Beanstalk environments. **Topics** + [ ## AWS sources to get started ](#deployments.cicd.aws-sites) + [ ## Additional resources ](#deployments.cicd.aws-services.third-party) + [ # Using GitHub Actions to deploy to Elastic Beanstalk ](deploying-github-actions.md) ## AWS sources to get started The following list highlights CI/CD tools and the corresponding AWS resources that provide step-by-step guidance for creating automated deployment pipelines to Elastic Beanstalk environments: + **AWS CodePipeline** – This [AWS Getting Started Resource Center](https://aws.amazon.com/getting-started/hands-on/continuous-deployment-pipeline/) tutorial shows you how to set up a continuous deployment pipeline to Elastic Beanstalk from GitHub , S3, or AWS CodeCommit. + **GitHub Actions** – See [Using GitHub Actions to deploy to Elastic Beanstalk](deploying-github-actions.md) to learn how to configure YAML-based workflows to set up a continuous deployment pipeline to Elastic Beanstalk directly from GitHub. + **GitLab** – This [AWS DevOps Developer Productivity Blog](https://aws.amazon.com/blogs/devops/deploy-a-docker-application-on-aws-elastic-beanstalk-with-gitlab/) post demonstrates how to configure GitLab continuous pipelines to deploy Node.js applications to Elastic Beanstalk Docker environments. + **Azure DevOps** – This [.NET on AWS Blog](https://aws.amazon.com/blogs/dotnet/deploy-to-elastic-beanstalk-with-azure-devops/) post guides you through implementing a continuous deployment pipeline from an Azure DevOps Git repository to Elastic Beanstalk using Azure Pipelines. ## Additional resources The following third-party tools and resources can help you implement automated deployment pipelines to Elastic Beanstalk environments: + **Jenkins** – The [AWS EBDeployment Jenkins plugin](https://plugins.jenkins.io/awseb-deployment-plugin/) enables direct deployment to Elastic Beanstalk environments from your Jenkins Job Configuration page. + **Circle CI:** – The [Orbs for Elastic Beanstalk](https://circleci.com/developer/orbs/orb/circleci/aws-elastic-beanstalk) provide reusable configuration packages to deploy and scale applications to Elastic Beanstalk. + **Bitbucket Pipelines** – The article [Deploy Elastic Beanstalk Application using Bitbucket Pipelines](https://avishayil.medium.com/deploy-to-elastic-beanstalk-using-bitbucket-pipelines-189eb75cf052) provides a basic configuration example for implementing Bitbucket Pipelines with Elastic Beanstalk. # Using GitHub Actions to deploy to Elastic Beanstalk GitHub Actions [GitHub Actions](https://docs.github.com/en/actions) can automatically deploy your application to Elastic Beanstalk when you push code changes to your repository. The [Elastic Beanstalk Deploy](https://github.com/aws-actions/aws-elasticbeanstalk-deploy) action provides a simple YAML interface that handles creating application versions, uploading source bundles to Amazon S3, and deploying to your Elastic Beanstalk environment. ## Example workflow The following example workflow deploys an application to an Elastic Beanstalk environment each time you push to the `main` branch. Create a `.yml` file in your repository under `.github/workflows/` . **Example GitHub Actions workflow for Elastic Beanstalk deployment** ``` name: Deploy to Elastic Beanstalk on: push: branches: - main permissions: id-token: write contents: read jobs: deploy: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v4 - name: Configure AWS credentials uses: aws-actions/configure-aws-credentials@v4 with: role-to-assume: arn:aws:iam::123456789012:role/my-github-actions-role aws-region: us-east-1 - name: Deploy to Elastic Beanstalk uses: aws-actions/aws-elasticbeanstalk-deploy@v1.0.0 with: aws-region: us-east-1 application-name: my-application environment-name: my-application-env ``` This workflow checks out your repository, uses [OpenID Connect (OIDC)](https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services) to authenticate with AWS through the [Configure AWS Credentials](https://github.com/aws-actions/configure-aws-credentials) action, and then deploys your application to Elastic Beanstalk. The deploy action packages your repository contents, uploads the source bundle to Amazon S3, creates a new application version, and creates or updates your environment. By default, it waits for the deployment to complete and the environment to return to a healthy state. For more configuration options and advanced examples, see the [Elastic Beanstalk Deploy action README](https://github.com/aws-actions/aws-elasticbeanstalk-deploy#readme) on GitHub. ## Additional resources + [Elastic Beanstalk Deploy action](https://github.com/aws-actions/aws-elasticbeanstalk-deploy) on GitHub + [Configure AWS Credentials action](https://github.com/aws-actions/configure-aws-credentials) on GitHub + [Configuring OpenID Connect in Amazon Web Services](https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services) (GitHub documentation)