Elastic Beanstalk

Elastic Beanstalk Deployment – Rolling & Blue/Green

Elastic Beanstalk Deployment Methods
~ Last updated on : ~ jayendrapatil

AWS Elastic Beanstalk Deployment Strategies

  • Elastic Beanstalk supports environments such as
    • Single Instance environments, with a single instance and Auto Scaling to maintain the minimum/maximum 1 instance
    • Load Balanced environments, with load balancing and Auto Scaling
  • Elastic Beanstalk allows multiple deployment options or strategies that can be selected depending upon the requirements for deployment time, downtime, DNS change, and rollback process.
  • Elastic Beanstalk supports the following deployment policies: All at once, Rolling, Rolling with additional batch, Immutable, and Traffic splitting.

⚠️ Platform Migration Notice: Amazon Linux 2 EOL – June 30, 2026

All Elastic Beanstalk platform branches based on Amazon Linux 2 (AL2) will be retired by June 30, 2026, when AL2 reaches End of Life. After this date, AWS will not release security updates, patches, or new packages for AL2-based platforms.

Action Required: Migrate your environments to Amazon Linux 2023 (AL2023) platform branches before the retirement date. Use deployment strategies like Blue/Green or Immutable deployments to safely migrate with minimal downtime.

Refer to: Migration from Amazon Linux 2 to Amazon Linux 2023

Elastic Beanstalk Deployment Methods

Elastic Beanstalk Deployment Methods

Deployment Methods Comparison

Method Impact of Failed Deployment Deploy Time Zero Downtime No DNS Change Rollback Process Code Deployed To
All at once Downtime Fastest No Yes Manual redeploy Existing instances
Rolling Single batch out of service; successful batches run new version Moderate † Yes Yes Manual redeploy Existing instances
Rolling with additional batch Minimal if first batch fails; otherwise similar to Rolling Slower † Yes Yes Manual redeploy New and existing instances
Immutable Minimal Slowest Yes Yes Terminate new instances New instances
Traffic splitting Percentage of traffic temporarily impacted Slowest †† Yes Yes Reroute traffic and terminate new instances New instances
Blue/Green Minimal Slowest Yes No Swap URL New instances

† Varies depending on batch size. †† Varies depending on evaluation time setting.

Deployment Policy Support by Environment Type

Deployment Policy Load-Balanced Environments Single-Instance Environments
All at once Yes Yes
Rolling Yes No
Rolling with additional batch Yes No
Immutable Yes Yes
Traffic splitting Yes (ALB only) No

All at Once Deployments

  • Elastic Beanstalk environment uses all-at-once deployments if it is created with a different client (API, SDK, or AWS CLI).
  • All at Once deployments perform an in-place deployment on all instances at the same time.
  • All at Once deployments are simple and fast, however, it would lead to downtime and the rollback would take time in case of any issues.
  • Suitable if you can accept a short loss of service and if quick deployments are important.
  • Rollback requires a manual redeploy of the previous version.

Rolling Deployments

  • Elastic Beanstalk environment uses rolling deployments if it is created with console or EB CLI.
  • Elastic Beanstalk splits the environment’s EC2 instances into batches and deploys the new version of the application on the existing instance one batch at a time, leaving the rest of the instances in the environment running the old version.
  • During a rolling deployment, part of the instances serves requests with the old version of the application, while instances in completed batches serve other requests with the new version.
  • Avoids downtime and minimizes reduced availability, at a cost of a longer deployment time.
  • Elastic Beanstalk performs the rolling deployments as
    • When processing a batch, detaches all instances in the batch from the load balancer, deploys the new application version, and then reattaches the instances.
    • To avoid any connection issues when the instances are detached, connection draining can be enabled on the load balancer
    • After reattaching the instances in a batch to the load balancer, ELB waits until they pass a minimum number of health checks (the Healthy check count threshold value), and then starts routing traffic to them.
    • Elastic Beanstalk waits until all instances in a batch are healthy before moving on to the next batch.
    • With enhanced health reporting, all instances must pass 12 consecutive health checks with an OK status 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, the deployment fails.
    • If a deployment fails after one or more batches are completed successfully, the completed batches run the new version of the application while any pending batches continue to run the old version.
    • If the instances are terminated from the failed deployment, Elastic Beanstalk replaces them with instances running the application version from the most recent successful deployment.
  • Batch size can be configured as a Percentage of total instances or a Fixed number.

Rolling with Additional Batch Deployments

  • Rolling with Additional Batch deployments is helpful when you need to maintain full capacity during deployments.
  • This deployment is similar to Rolling deployments, except they do not do an in-place deployment but a disposable one, launching a new batch of instances prior to taking any instances out of service
  • When the deployment completes, Elastic Beanstalk terminates the additional batch of instances.
  • Rolling with additional batch deployment does not impact the capacity and ensures full capacity during the deployment process.
  • Deploys code to both new and existing instances.

Immutable Deployments

  • All at Once and Rolling deployment method updates existing instances.
  • If you need to ensure the application source is always deployed to new instances, instead of updating existing instances, the environment can be configured to use immutable updates for deployments.
  • Immutable updates are performed by launching a second Auto Scaling group in the environment and the new version serves traffic alongside the old version until the new instances pass health checks.
  • 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.
  • Provides a quick and safe rollback — simply terminate the new instances.
  • Works with both load-balanced and single-instance environments.

Traffic Splitting Deployments (Canary Testing)

  • Traffic-splitting deployments allow you to 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 during the evaluation period, Elastic Beanstalk forwards all traffic to the new instances 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.
  • Configuration options:
    • Traffic split (NewVersionPercent) – The initial percentage of incoming client traffic to shift to new instances (e.g., 10%, 15%, 20%).
    • Traffic splitting evaluation time (EvaluationTime) – The time period (in minutes) to wait after initial healthy deployment before shifting all traffic to new instances.
  • Requires an Application Load Balancer (ALB) — does not work with Classic Load Balancer or Network Load Balancer.
  • 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 the original.
  • Rolling back is quick — reroute traffic and terminate new instances.

Blue Green Deployments

  • Elastic Beanstalk performs an in-place update when application versions are updated, which may result in the application becoming unavailable to users for a short period of time.
  • Blue Green approach is suitable for deployments that depend on incompatible resource configuration changes or a new version that can’t run alongside the old version.
  • Elastic Beanstalk enables the Blue Green deployment through the Swap Environment URLs feature.
  • Blue Green deployment provides an almost zero downtime solution, where a new version is deployed to a separate environment, and then CNAMEs of the two environments are swapped to redirect traffic to the new version.
  • Blue/green deployments require that the environment runs independently of the production database i.e. not maintained by Elastic Beanstalk if your application uses one. Because if the environment has an RDS DB instance attached to it, the data will not transfer over to the second environment and will be lost if the original environment is terminated
  • Blue Green deployment entails a DNS change; hence, do not terminate the old environment until the DNS changes have been propagated and the old DNS records expire.
  • DNS servers do not necessarily clear old records from their cache based on the time to live (TTL) you set on the DNS records.
  • This is the only deployment method that involves a DNS change.

Deployment Configuration

  • Deployment policies are configured in the Rolling updates and deployments section of the environment’s Configuration page.
  • Key configuration options in the aws:elasticbeanstalk:command namespace:
    • DeploymentPolicy – AllAtOnce, Rolling, RollingWithAdditionalBatch, Immutable, or TrafficSplitting
    • BatchSizeType – Percentage or Fixed (for Rolling and Rolling with additional batch)
    • BatchSize – Number or percentage of instances per batch
    • HealthCheckSuccessThreshold – Lowers the health threshold (e.g., Warning) for instances to be considered healthy
    • IgnoreHealthCheck – Prevents rollback when batch fails health checks
    • Timeout – Command timeout in seconds
  • Traffic splitting options in the aws:elasticbeanstalk:trafficsplitting namespace:
    • NewVersionPercent – Percentage of traffic to route to new version
    • EvaluationTime – Time in minutes to evaluate health before shifting all traffic

New Features (2026)

Deployments Tab with In-Progress Deployment Logs (March 2026)

  • Elastic Beanstalk now provides a Deployments tab in the environment dashboard with a consolidated view of deployment history and real-time deployment progress.
  • View step-by-step deployment logs while deployments are still in progress, eliminating the need for manual log bundle downloads or SSH connections.
  • The Deployments tab shows history of application deployments, configuration updates, and environment launches.
  • Each deployment includes detailed events and a consolidated log capturing the entire deployment process — including dependency installation, builds, and configuration steps.
  • Enables faster root cause analysis of deployment failures directly in the console.
  • Available on AL2023 platform versions released on or after March 11, 2026.
  • Refer to: Viewing deployment logs for an Elastic Beanstalk environment

GitHub Actions for Automated Deployment (February 2026)

  • Elastic Beanstalk now offers the Elastic Beanstalk Deploy GitHub Action (aws-actions/aws-elasticbeanstalk-deploy) for automated deployments as part of CI/CD pipelines.
  • Automatically deploy web applications when you push code or configuration changes to your GitHub repository.
  • Supports all deployment policies (All at once, Rolling, Immutable, Traffic splitting, etc.) configured on the environment.
  • Refer to: Using GitHub Actions to deploy to Elastic Beanstalk

Important Considerations

  • EC2 Burst Balance Loss: Some deployment policies replace all instances, causing all accumulated Amazon EC2 burst balances to be lost. This occurs with:
    • Managed platform updates with instance replacement enabled
    • Immutable updates
    • Deployments with immutable updates or traffic splitting enabled
  • Enhanced Health Reporting: When enabled, Elastic Beanstalk considers multiple factors including incoming request results. All instances must pass 12 consecutive health checks with OK status within 2 minutes (web server) or 18 checks within 3 minutes (worker).
  • Connection Draining: Enable connection draining on the load balancer to avoid connection issues when instances are detached during rolling deployments.
  • Deployment ID: Each deployment is identified by a deployment ID (starts at 1, increments by one). Useful for tracking instance state when rolling updates fail.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. When thinking of AWS Elastic Beanstalk, the ‘Swap Environment URLs’ feature most directly aids in what? [CDOP]
    1. Immutable Rolling Deployments
    2. Mutable Rolling Deployments
    3. Canary Deployments
    4. Blue-Green Deployments (Simply upload the new version of your application and let your deployment service (AWS Elastic Beanstalk, AWS CloudFormation, or AWS OpsWorks) deploy a new version (green). To cut over to the new version, you simply replace the ELB URLs in your DNS records. Elastic Beanstalk has a Swap Environment URLs feature to facilitate a simpler cutover process.)
  2. You need to deploy a new version of your application. You’d prefer to use all new instances if possible, but you cannot have any downtime. You also don’t want to swap any environment URLs. You’re running t2.large instances and you normally need 15 instances to meet capacity. Which deployment method should you use? Choose the correct answer:
    1. Rolling Updates
    2. Blue/Green
    3. Immutable (Immutable deployments launch new instances in a separate Auto Scaling group, deploy to new instances with zero downtime, and do not require a DNS/URL swap. Traffic splitting would also work but Immutable is the more direct answer when canary testing isn’t required.)
    4. All at Once
  3. Your team is responsible for an AWS Elastic Beanstalk application. The business requires that you move to a continuous deployment model, releasing updates to the application multiple times per day with zero downtime. What should you do to enable this and still be able to roll back almost immediately in an emergency to the previous version? [CDOP]
    1. Enable rolling updates in the Elastic Beanstalk environment, setting an appropriate pause time for application startup.
    2. Create a second Elastic Beanstalk environment running the new application version, and swap the environment CNAMEs. (Blue/Green deployment with CNAME swap provides zero downtime and instant rollback by swapping back the URLs.)
    3. Develop the application to poll for a new application version in your code repository; download and install to each running Elastic Beanstalk instance.
    4. Create a second Elastic Beanstalk environment with the new application version, and configure the old environment to redirect clients, using the HTTP 301 response code, to the new environment.
  4. A company wants to perform canary testing on their Elastic Beanstalk application. They want to route 10% of production traffic to the new version for 10 minutes before completing the deployment. The environment uses an Application Load Balancer. Which deployment policy should they use?
    1. Immutable
    2. Blue/Green with Route 53 weighted routing
    3. Traffic splitting (Traffic splitting deployments allow canary testing by routing a configurable percentage of traffic to new instances for a specified evaluation period. It requires an ALB and provides automatic rollback if health checks fail.)
    4. Rolling with additional batch
  5. An application deployed on Elastic Beanstalk requires zero downtime deployments with the ability to quickly roll back. The team does not want DNS changes and needs the deployment to use entirely new instances. Which two deployment methods meet these requirements? (Choose 2)
    1. All at once
    2. Rolling
    3. Immutable (Immutable launches a second ASG with new instances, no DNS change, zero downtime, quick rollback by terminating new instances.)
    4. Traffic splitting (Traffic splitting also launches new instances in a temporary ASG, no DNS change, zero downtime, rollback by rerouting traffic and terminating new instances.)
    5. Blue/Green
  6. A deployment on Elastic Beanstalk must maintain full capacity throughout the process but the team is willing to accept that some instances temporarily run the old version while others run the new version. The environment uses a Classic Load Balancer. Which deployment method is most appropriate?
    1. Immutable
    2. Traffic splitting
    3. Rolling with additional batch (Rolling with additional batch maintains full capacity by launching an extra batch first. It works with CLB unlike traffic splitting which requires ALB. It allows mixed versions temporarily across batches.)
    4. Blue/Green

References

AWS Elastic Beanstalk – Platform as a Service

Elastic Beanstalk Environment Tiers
~ Last updated on : ~ jayendrapatil ~ 16 Comments

AWS Elastic Beanstalk

⚠️ Important Platform Update: Amazon Linux 2 End of Life – June 30, 2026

All Elastic Beanstalk platform branches based on Amazon Linux 2 (AL2) will be retired by June 30, 2026, when AL2 reaches End of Life. After this date, AWS will not release security updates, patches, or new packages for AL2-based platforms.

Action Required: Migrate to Amazon Linux 2023 (AL2023) platform branches before the retirement date. AL2023 is supported until June 2029. Migration requires a blue/green deployment as AL2 and AL2023 platform versions are incompatible.

Refer to Migration from Amazon Linux 2 to Amazon Linux 2023 for detailed guidance.

  • AWS Elastic Beanstalk helps to quickly deploy and manage applications in the AWS Cloud without having to worry about the infrastructure that runs those applications.
  • reduces management complexity without restricting choice or control.
  • enables automated infrastructure management and code deployment, by simply uploading, for applications and includes
    • Application platform management
    • Capacity provisioning
    • Load Balancing
    • Auto Scaling
    • Code deployment
    • Health Monitoring
  • Elastic Beanstalk automatically launches an environment once an application is uploaded, and creates and configures the AWS resources needed to run the code. After the environment is launched, it can be managed and used to deploy new application versions.
  • AWS resources launched by Elastic Beanstalk are fully accessible i.e. EC2 instances can be SSHed into.
  • provides developers and systems administrators with an easy, fast way to deploy and manage the applications without having to worry about AWS infrastructure.
  • supports applications developed in Go, Java, .NET, Node.js, PHP, Python, and Ruby, as well as Docker containers.
  • CloudFormation, using templates, is a better option than Elastic Beanstalk if the internal AWS resources to be used are known and fine-grained control is needed.

Elastic Beanstalk Supported Platforms

  • Elastic Beanstalk supports the following platforms on Amazon Linux 2023 (recommended) and Amazon Linux 2:
    • Docker
    • Go
    • Java SE
    • Tomcat
    • .NET Core on Linux
    • .NET on Windows Server
    • Node.js
    • PHP
    • Python
    • Ruby
  • Elastic Beanstalk supports AWS Graviton (arm64) instance types on Amazon Linux 2 and AL2023 platforms, providing up to 40% better price-performance over x86-based instances.
  • Amazon Linux 2023 is the recommended platform, offering enhanced security features including FIPS certification, modern package versions, and support until June 2029.

Elastic Beanstalk Components

Elastic Beanstalk Components

  • Application
    • An Application is a logical collection of components, including environments, versions, and environment configurations.
  • Application Version
    • An application version refers to a specific, labeled iteration of deployable code for a web application.
    • Applications can have many versions and each application version is unique and points to an S3 object.
    • Multiple versions of an Application can be deployed for testing differences and helps to roll back to any version in case of issues.
    • Elastic Beanstalk supports application version lifecycle policies to automatically delete old versions based on age or total count (up to 100 versions deleted per policy application).
  • Environment
    • An environment is a version that is deployed onto AWS resources.
    • An environment runs a single application version at a time, but same application version can be deployed across multiple environments.
    • When an environment is created, EB provisions the resources needed to run the specified application version.
  • Environment Configuration
    • An environment configuration identifies a collection of parameters and settings that define how an environment and its associated resources behave
    • When an environment’s configuration settings are updated, EB automatically applies the changes to existing resources or deletes and deploys new resources, depending upon the change
  • Configuration Template
    • A configuration template is a starting point for creating unique environment configurations

Elastic Beanstalk Architecture

Elastic Beanstalk Environment Tiers

  • Elastic Beanstalk environment requires an environment tier, platform, and
    environment type.
  • Environment tier determines whether EB provisions resources to support
    • Web tier – a web application that handles HTTP(S) requests
    • Worker tier – an application that handles background-processing tasks.
  • One environment cannot support two different environment tiers because each requires its own set of resources; a worker environment tier and a web server environment tier each require an Auto Scaling group, but Elastic Beanstalk supports only one Auto Scaling group per environment.

Web Environment Tier

  • An environment tier whose web application processes web requests is known as a web server tier.
  • AWS resources created for a web environment tier include an Elastic Load Balancer, an Auto Scaling group, one or more EC2 instances
  • Every Environment has a CNAME URL pointing to the ELB, aliased in Route 53 to ELB URL.
  • Elastic Beanstalk supports dual-stack (IPv4 and IPv6) configuration for Application Load Balancers and Network Load Balancers (not Classic Load Balancers or single-instance environments).
  • Each EC2 server instance that runs the application uses a container type, which defines the infrastructure topology and software stack.
  • A software component called the host manager (HM) runs on each EC2 server instance and is responsible for
    • Deploying the application
    • Aggregating events and metrics for retrieval via the console, the API, or the command line
    • Generating instance-level events
    • Monitoring the application log files for critical errors
    • Monitoring the application server
    • Patching instance components
    • Rotating your application’s log files and publishing them to S3

Worker Environment Tier

  • An environment tier whose web application runs background jobs is known as a worker tier.
  • AWS resources created for a worker environment tier include an Auto Scaling group, one or more EC2 instances, and an IAM role.
  • For the worker environment tier, Elastic Beanstalk also creates and provisions an SQS queue, if one doesn’t exist.
  • When a worker environment tier is launched, EB installs the necessary support files for the programming language of choice and a daemon on each EC2 instance in the Auto Scaling group reading from the same SQS queue.
  • Daemon is responsible for pulling requests from an SQS queue and then sending the data to the web application running in the worker environment tier that will process those messages.
  • Worker environments support SQS dead letter queues which can be used to store messages that could not be successfully processed. Dead letter queue provides the ability to sideline, isolate and analyze the unsuccessfully processed messages

Elastic Beanstalk Monitoring and Troubleshooting

Enhanced Health Reporting

  • Enhanced health reporting provides detailed health information about EC2 instances via a health agent installed in supported AMIs.
  • Reports environment and instance health every 10 seconds with color-coded status: Green (OK), Yellow (Warning), Red (Degraded/Severe).
  • Combines standard load balancer health checks with instance monitoring to ensure proper functioning.
  • Required for Managed Platform Updates and Traffic Splitting deployments.

AI-Powered Environment Analysis (New – 2026)

  • Elastic Beanstalk provides AI-powered analysis to identify root causes and recommend solutions for environment health issues.
  • Available when environment health status is Warning, Degraded, or Severe.
  • Collects environment events, health data, and instance logs (up to 170,000 tokens), sends them to Amazon Bedrock for analysis, and returns AI-generated insights and recommended solutions.
  • Available on AL2 and AL2023 platform versions released on or after February 26, 2026, and Windows Server platforms released on or after April 22, 2026.
  • Uses Amazon Nova as a fallback model for improved reliability.
  • Can be triggered via the console (AI Analysis button), AWS CLI (RequestEnvironmentInfo with analyze info type), or EB CLI (eb logs --analyze).
  • Requires instance profile permissions for Amazon Bedrock (bedrock:InvokeModel, bedrock:ListFoundationModels) and Elastic Beanstalk (elasticbeanstalk:DescribeEvents, elasticbeanstalk:DescribeEnvironmentHealth).
  • Standard Amazon Bedrock pricing applies for model invocations.

Deployment Logs (New – 2026)

  • Elastic Beanstalk now provides a Deployments tab in the environment dashboard with consolidated view of deployment history and real-time deployment progress with step-by-step logs.
  • Helps debug deployment failures without needing to manually request and download log bundles.
  • Available on AL2 and AL2023 platforms released on or after March 11, 2026, and Windows platforms released on or after April 22, 2026.

CloudWatch Logs Console Integration (New – 2026)

  • Elastic Beanstalk console now integrates CloudWatch Logs directly in the Logs tab, eliminating the need to navigate to the CloudWatch console separately.
  • Provides direct access to relevant log groups and log streams for the environment.

Managed Platform Updates

  • Elastic Beanstalk can be configured to automatically apply patch and minor updates to the platform during a scheduled maintenance window.
  • Managed updates require enhanced health reporting to be enabled.
  • Updates are applied using immutable deployments to ensure no impact to the running environment during the update process.
  • Helps maintain the shared responsibility model by keeping platform components up to date with security patches.
  • Supports tag propagation to launch templates for consistent resource tagging during managed updates.

Elastic Beanstalk with Other AWS Services

  • Elastic Beanstalk supports VPC and launches AWS resources, such as instances, into the VPC
  • Elastic Beanstalk supports IAM and helps you securely control access to your AWS resources.
  • CloudFront can be used to distribute the content in S3 after an Elastic Beanstalk is created and deployed
  • CloudTrail
    • Elastic Beanstalk is integrated with CloudTrail, a service that captures all of the Elastic Beanstalk API calls and delivers the log files to a specified S3 bucket.
    • CloudTrail captures API calls from the Elastic Beanstalk console or from your code to the Elastic Beanstalk APIs and helps to determine the request made to Elastic Beanstalk, the source IP address from which the request was made, who made the request, when it was made, etc.
  • RDS
    • EB provides support for running RDS instances in the environment which is ideal for development and testing but not for production.
    • For a production environment, it is not recommended because it ties the lifecycle of the database instance to the lifecycle of the application’s environment. So if the environment is deleted, the RDS instance is deleted as well
    • It is recommended to launch a database instance outside of the environment and configure the application to connect to it outside of the functionality provided by Elastic Beanstalk.
    • Using a database instance external to the environment requires additional security group and connection string configuration, but it also lets the application connect to the database from multiple environments, use database types not supported with integrated databases, perform blue/green deployments, and tear down the environment without affecting the database instance.
  • S3
    • EB creates an S3 bucket named elasticbeanstalk-region-account-id for each region in which environments are created.
    • EB uses the bucket to store application versions, logs, and other supporting files.
    • It applies a bucket policy to buckets it creates to allow environments to write to the bucket and prevent accidental deletion

Elastic Beanstalk Deployment Strategies

Elastic Beanstalk Deployment Methods

  • All at Once
    • performs an in-place deployment on all instances at the same time.
    • is performed on existing instances and would lead to downtime as well as time to roll back changes.
  • Rolling
    • splits the environment instances into batches and deploys the application’s new version on the existing instance one batch at a time, leaving the rest of the environment instances running the old version.
    • waits until all instances in a batch are healthy before moving on to the next batch.
    • reduces downtime as all instances are not updated and if the health checks fail the deployment can be rollback.
  • Rolling with an Additional batch
    • similar to Rolling however it starts the deployment of the application’s new version on a new batch.
    • does not impact the capacity and ensures full capacity during the deployment process.
  • Immutable
    • ensures the application source is always deployed to new instances.
    • prevent issues caused by partially completed rolling deployments.
    • provides minimal downtime and quick rollback.
  • Traffic Splitting
    • performs a canary testing as part of the application deployment.
    • launches a full set of new instances (like immutable deployment) and forwards a configurable percentage of client traffic to the new version for a specified evaluation period.
    • monitors the health of the new instances during the evaluation period.
    • if the new instances remain healthy, shifts all traffic to them and terminates the old ones.
    • if issues are detected, triggers an automatic rollback by shifting traffic back to the original instances.
    • ideal for production deployments where you want to validate with real traffic before full cutover.
  • Blue Green
    • suitable for deployments that depend on incompatible resource configuration changes or a new version that can’t run alongside the old version.
    • implemented using the Swap Environment URLs feature that entails a DNS switchover.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. An organization is planning to use AWS for their production roll out. The organization wants to implement automation for deployment such that it will automatically create a LAMP stack, download the latest PHP installable from S3 and setup the ELB. Which of the below mentioned AWS services meets the requirement for making an orderly deployment of the software?
    1. AWS Elastic Beanstalk
    2. AWS CloudFront
    3. AWS CloudFormation
    4. AWS DevOps
  2. What does Amazon Elastic Beanstalk provide?
    1. A scalable storage appliance on top of Amazon Web Services.
    2. An application container on top of Amazon Web Services
    3. A service by this name doesn’t exist.
    4. A scalable cluster of EC2 instances
  3. You want to have multiple versions of your application running at the same time, with all versions launched via AWS Elastic Beanstalk. Is this possible?
    1. However if you have 2 AWS accounts this can be done
    2. AWS Elastic Beanstalk is not designed to support multiple running environments
    3. AWS Elastic Beanstalk is designed to support a number of multiple running environments
    4. However AWS Elastic Beanstalk is designed to support only 2 multiple running environments
  4. A .NET application that you manage is running in Elastic Beanstalk. Your developers tell you they will need access to application log files to debug issues that arise. The infrastructure will scale up and down. How can you ensure the developers will be able to access only the log files?
    1. Access the log files directly from Elastic Beanstalk
    2. Enable log file rotation to S3 within the Elastic Beanstalk configuration
    3. Ask your developers to enable log file rotation in the applications web.config file
    4. Connect to each Instance launched by Elastic Beanstalk and create a Windows Scheduled task to rotate the log files to S3
  5. Your team has a tomcat-based Java application you need to deploy into development, test and production environments. After some research, you opt to use Elastic Beanstalk due to its tight integration with your developer tools and RDS due to its ease of management. Your QA team lead points out that you need to roll a sanitized set of production data into your environment on a nightly basis. Similarly, other software teams in your org want access to that same restored data via their EC2 instances in your VPC .The optimal setup for persistence and security that meets the above requirements would be the following. [PROFESSIONAL]
    1. Create your RDS instance as part of your Elastic Beanstalk definition and alter its security group to allow access to it from hosts in your application subnets. (Not optimal for persistence as the RDS is associated with the Elastic Beanstalk lifecycle and would not live independently)
    2. Create your RDS instance separately and add its IP address to your application’s DB connection strings in your code. Alter its security group to allow access to it from hosts within your VPC’s IP address block. (RDS is connected using DNS endpoint only)
    3. Create your RDS instance separately and pass its DNS name to your app’s DB connection string as an environment variable. Create a security group for client machines and add it as a valid source for DB traffic to the security group of the RDS instance itself. (Security group allows instances to access the RDS with new instances launched without any changes)
    4. Create your RDS instance separately and pass its DNS name to your DB connection string as an environment variable. Alter its security group to allow access to it from hosts in your application subnets. (Not optimal for security adding individual hosts)
  6. Your must architect the migration of a web application to AWS. The application consists of Linux web servers running a custom web server. You are required to save the logs generated from the application to a durable location. What options could you select to migrate the application to AWS? (Choose 2) [PROFESSIONAL]
    1. Create an AWS Elastic Beanstalk application using the custom web server platform. Specify the web server executable and the application project and source files. Enable log file rotation to Amazon Simple Storage Service (S3). (EB does not work with Custom server executable)
    2. Create Dockerfile for the application. Create an AWS OpsWorks stack consisting of a custom layer. Create custom recipes to install Docker and to deploy your Docker container using the Dockerfile. Create custom recipes to install and configure the application to publish the logs to Amazon CloudWatch Logs (⚠️ Note: AWS OpsWorks Stacks reached End of Life on May 26, 2024 and is no longer available. This option is no longer valid for new implementations.)
    3. Create Dockerfile for the application. Create an AWS OpsWorks stack consisting of a Docker layer that uses the Dockerfile. Create custom recipes to install and configure Amazon Kinesis to publish the logs into Amazon CloudWatch. (Kinesis not needed. ⚠️ Note: AWS OpsWorks Stacks reached End of Life on May 26, 2024.)
    4. Create a Dockerfile for the application. Create an AWS Elastic Beanstalk application using the Docker platform and the Dockerfile. Enable logging the Docker configuration to automatically publish the application logs. Enable log file rotation to Amazon S3. (Use Docker configuration with awslogs and EB with Docker)
    5. Use VM import/Export to import a virtual machine image of the server into AWS as an AMI. Create an Amazon Elastic Compute Cloud (EC2) instance from AMI, and install and configure the Amazon CloudWatch Logs agent. Create a new AMI from the instance. Create an AWS Elastic Beanstalk application using the AMI platform and the new AMI. (Use VM Import/Export to create AMI and CloudWatch logs agent to log)
  7. Which of the following groups is AWS Elastic Beanstalk best suited for?
    1. Those who want to deploy and manage their applications within minutes in the AWS cloud.
    2. Those who want to privately store and manage Git repositories in the AWS cloud.
    3. Those who want to automate the deployment of applications to instances and to update the applications as required.
    4. Those who want to model, visualize, and automate the steps required to release software.
  8. When thinking of AWS Elastic Beanstalk’s model, which is true?
    1. Applications have many deployments, deployments have many environments.
    2. Environments have many applications, applications have many deployments.
    3. Applications have many environments, environments have many deployments. (Applications group logical services. Environments belong to Applications, and typically represent different deployment levels (dev, stage, prod, forth). Deployments belong to environments, and are pushes of bundles of code for the environments to run.)
    4. Deployments have many environments, environments have many applications.
  9. If you’re trying to configure an AWS Elastic Beanstalk worker tier for easy debugging if there are problems finishing queue jobs, what should you configure?
    1. Configure Rolling Deployments.
    2. Configure Enhanced Health Reporting
    3. Configure Blue-Green Deployments.
    4. Configure a Dead Letter Queue (Elastic Beanstalk worker environments support SQS dead letter queues, where worker can send messages that for some reason could not be successfully processed. Dead letter queue provides the ability to sideline, isolate and analyze the unsuccessfully processed messages. Refer link)
  10. When thinking of AWS Elastic Beanstalk, which statement is true?
    1. Worker tiers pull jobs from SNS.
    2. Worker tiers pull jobs from HTTP.
    3. Worker tiers pull jobs from JSON.
    4. Worker tiers pull jobs from SQS. (Elastic Beanstalk installs a daemon on each EC2 instance in the Auto Scaling group to process SQS messages in the worker environment. Refer link)
  11. You are building a Ruby on Rails application for internal, non-production use, which uses MySQL as a database. You want developers without very much AWS experience to be able to deploy new code with a single command line push. You also want to set this up as simply as possible. Which tool is ideal for this setup?
    1. AWS CloudFormation
    2. AWS OpsWorks (⚠️ OpsWorks Stacks reached EOL May 26, 2024)
    3. AWS ELB + EC2 with CLI Push
    4. AWS Elastic Beanstalk
  12. What AWS products and features can be deployed by Elastic Beanstalk? Choose 3 answers.
    1. Auto scaling groups
    2. Route 53 hosted zones
    3. Elastic Load Balancers
    4. RDS Instances
    5. Elastic IP addresses
    6. SQS Queues
  13. AWS Elastic Beanstalk stores your application files and optionally server log files in ____.
    1. Amazon Storage Gateway
    2. Amazon Glacier
    3. Amazon EC2
    4. Amazon S3
  14. When you use the AWS Elastic Beanstalk console to deploy a new application ____.
    1. Need to upload each file separately
    2. Need to create each file and path
    3. Need to upload a source bundle
    4. Need to create each file
  15. A company wants to deploy a new application version to production using Elastic Beanstalk. They need to validate the new version with a small percentage of real production traffic before completing the full deployment. Which deployment policy should they use?
    1. Immutable
    2. Rolling with additional batch
    3. Traffic splitting (Traffic splitting performs canary testing by forwarding a configurable percentage of traffic to new instances for an evaluation period, with automatic rollback on failure)
    4. Blue/Green
  16. An application running on Elastic Beanstalk is experiencing health issues. The team needs to quickly identify the root cause and get recommended solutions without manually analyzing logs. Which Elastic Beanstalk feature should they use?
    1. Enhanced Health Reporting
    2. CloudWatch Alarms
    3. AI-powered environment analysis (AI-powered analysis uses Amazon Bedrock to analyze environment events, health data, and logs, then provides AI-generated root cause analysis and recommended solutions)
    4. X-Ray tracing
  17. Which Elastic Beanstalk feature automatically applies patch and minor platform updates during a maintenance window?
    1. Rolling updates
    2. Immutable deployments
    3. Managed platform updates (Managed platform updates automatically apply patch and minor updates using immutable deployments during a scheduled maintenance window. Requires enhanced health reporting to be enabled.)
    4. Blue/Green deployments

References

Beanstalk vs OpsWorks vs CloudFormation

~ Last updated on : ~ jayendrapatil ~ 14 Comments

⚠️ PARTIAL DEPRECATION NOTICE

AWS OpsWorks (all variants) reached End of Life (EOL) in 2024.

  • AWS OpsWorks for Puppet Enterprise – EOL March 31, 2024
  • AWS OpsWorks for Chef Automate – EOL May 5, 2024
  • AWS OpsWorks Stacks – EOL May 26, 2024

The OpsWorks services have been disabled for both new and existing customers. The comparison sections involving OpsWorks are maintained for historical reference.

Current Deployment & Management Options:

  • AWS CloudFormation – Infrastructure as Code (still actively supported and enhanced)
  • AWS Elastic Beanstalk – Simplified application deployment (still actively supported)
  • AWS CDK – Programmatic infrastructure definition using familiar languages
  • AWS Systems Manager – Configuration management and automation (OpsWorks replacement)
  • AWS CodeDeploy – Application deployment automation
  • AWS App Runner – Fully managed container application service

For OpsWorks migration guidance, refer to: AWS OpsWorks EOL Documentation

AWS Elastic Beanstalk vs CloudFormation vs CDK – Deployment & Management Services Comparison

AWS offers multiple options for provisioning IT infrastructure and application deployment and management, varying from convenience & ease of setup to low-level granular control.
Deployment and Management - Elastic Beanstalk vs CloudFormation vs CDK

AWS Elastic Beanstalk

  • AWS Elastic Beanstalk is a higher-level service which allows you to quickly deploy with minimum management effort a web or worker-based environment using EC2, Docker using ECS, Elastic Load Balancing, Auto Scaling, RDS, CloudWatch, etc.
  • Elastic Beanstalk is the fastest and simplest way to get an application up and running on AWS, perfect for developers who want to deploy code and not worry about underlying infrastructure.
  • Elastic Beanstalk provides an environment to easily deploy and run applications in the cloud. It is integrated with developer tools and provides a one-stop experience for application lifecycle management.
  • Elastic Beanstalk requires minimal configuration and will help deploy, monitor, and handle the elasticity/scalability of the application.
  • A user doesn’t need to do much more than write application code and configure some settings on Elastic Beanstalk.
  • Supports platforms including Java, .NET, PHP, Node.js, Python, Ruby, Go, and Docker on Amazon Linux 2 and Amazon Linux 2023.
  • AI-Powered Environment Analysis (2026) – Elastic Beanstalk now offers AI-powered analysis that automatically diagnoses environment health issues, identifies root causes, and provides recommended solutions when health status is Warning, Degraded, or Severe.
  • Dual-Stack IPv6 Support (2025) – Supports dual-stack configuration for Application Load Balancers and Network Load Balancers, allowing environments to serve both IPv4 and IPv6 traffic.

AWS OpsWorks (Deprecated – EOL 2024)

⚠️ All AWS OpsWorks services reached End of Life in 2024 and have been disabled for all customers.
  • AWS OpsWorks was an application management service that simplified software configuration, application deployment, scaling, and monitoring using Chef or Puppet.
  • OpsWorks was recommended for managing infrastructure with a configuration management system such as Chef.
  • OpsWorks enabled writing custom Chef recipes, utilized self-healing, and worked with layers.
  • Although OpsWorks was a deployment management service that helped deploy applications with Chef recipes, it was not primarily meant to manage scaling out of the box and needed to be handled explicitly.
  • Migration Paths:
    • AWS Systems Manager – For configuration management and automation (recommended by AWS)
    • Chef SaaS – For customers who want to continue using Chef recipes
    • Puppet Enterprise – Self-hosted Puppet for existing Puppet users
    • AWS CodeDeploy – For application deployment workflows
    • Amazon ECS/EKS – For containerized workloads

AWS CloudFormation

  • AWS CloudFormation enables modeling, provisioning, and version-controlling of a wide range of AWS resources ranging from a single EC2 instance to a complex multi-tier, multi-region application.
  • CloudFormation is a low-level service and provides granular control to provision and manage stacks of AWS resources based on templates (JSON or YAML).
  • CloudFormation templates enable version control of the infrastructure and make deployment of environments easy and repeatable.
  • CloudFormation supports infrastructure needs of many different types of applications such as existing enterprise applications, legacy applications, applications built using a variety of AWS resources, and container-based solutions (including those built using AWS Elastic Beanstalk).
  • CloudFormation is not just an application deployment tool but can provision any kind of AWS resource.
  • CloudFormation is designed to complement Elastic Beanstalk and other AWS services.
  • CloudFormation with Elastic Beanstalk
    • CloudFormation supports Elastic Beanstalk application environments as one of the AWS resource types.
    • This allows you, for example, to create and manage an AWS Elastic Beanstalk–hosted application along with an RDS database to store the application data. In addition to RDS instances, any other supported AWS resource can be added to the group as well.
  • Key Updates (2024-2025):
    • Stack Refactoring (2025) – Move resources between stacks, rename logical IDs, and decompose monolithic templates into focused components without disrupting running infrastructure.
    • 40% Faster Deployments (2024) – Optimistic stabilization with CONFIGURATION_COMPLETE event enables parallel creation of dependent resources.
    • IaC Generator – Generate CloudFormation templates from existing AWS resources (reverse-engineer existing infrastructure into IaC).
    • Configuration Drift Management – Improved drift detection and remediation capabilities.
    • AI Integration – IaC context integrated with AI-powered development tools.

AWS Cloud Development Kit (AWS CDK)

  • AWS CDK is an open-source software development framework that allows you to define cloud infrastructure using familiar programming languages (TypeScript, JavaScript, Python, Java, C#/.NET, Go).
  • CDK synthesizes into CloudFormation templates, providing the reliability of CloudFormation with the expressiveness of general-purpose programming languages.
  • CDK provides high-level constructs (L2/L3) that encapsulate AWS best practices and reduce the amount of boilerplate code needed.
  • CDK is ideal for teams who prefer imperative programming over declarative YAML/JSON templates.
  • Same infrastructure that takes 500+ lines of CloudFormation YAML can be expressed in ~15 lines of CDK TypeScript.
  • CDK Refactoring (2025) – Refactor CDK code (rename constructs, move resources between stacks) while preserving deployed resources.
  • CDK Mixins (2026) – Add composable, reusable abstractions to any construct (L1, L2, or custom) without rebuilding existing infrastructure code.
  • CDK Aspects – Apply organization-wide policies (security rules, tagging standards, compliance requirements) across entire infrastructure.

AWS Serverless Application Model (AWS SAM)

  • AWS SAM is an open-source framework specifically designed for building serverless applications using infrastructure as code.
  • SAM extends CloudFormation with shorthand syntax to express Lambda functions, APIs, databases, and event source mappings with fewer lines of code.
  • During deployment, SAM transforms the SAM syntax into CloudFormation syntax, then CloudFormation provisions the resources.
  • SAM CLI provides local testing, debugging, packaging, and deployment capabilities.
  • SAM Accelerate – Speeds up local development and cloud testing.
  • WebSocket API Support (2026) – Define complete WebSocket APIs for API Gateway with minimal configuration.
  • SAM CLI integrates with AWS CDK and Terraform.

AWS App Runner

  • AWS App Runner is a fully managed container application service that lets you build, deploy, and run containerized web applications and API services without prior infrastructure or container experience.
  • App Runner connects directly to your code or image repository and provides an automatic CI/CD pipeline with fully managed operations, high performance, scalability, and security.
  • App Runner automatically handles load balancing, auto-scaling (including scale to zero), encryption, and health monitoring.
  • Ideal for web applications and APIs that need to deploy quickly from source code or container images without managing infrastructure.
  • Supports deployment from GitHub, Bitbucket, or Amazon ECR.

AWS Proton (Deprecated – EOL October 7, 2026)

⚠️ AWS Proton will reach End of Life on October 7, 2026. Plan migration accordingly.
  • AWS Proton was a fully managed deployment service that standardized how organizations deploy microservices and infrastructure from approved templates.
  • Proton sat on top of CloudFormation (or Terraform) and added self-service deployment, versioning, parameter validation, and standardization.
  • Designed for platform teams to provide standardized templates while giving developers self-service deployment speed.
  • After EOL, the Proton console, API, and pipeline management will be permanently unavailable, though deployed infrastructure will remain intact.

Comparison Summary

Service Level Best For Status
Elastic Beanstalk High-level PaaS Developers who want to deploy code without managing infrastructure ✅ Active
CloudFormation Low-level IaC Granular control over all AWS resources via declarative templates ✅ Active
AWS CDK High-level IaC Teams who prefer defining infrastructure in programming languages ✅ Active
AWS SAM Serverless IaC Serverless applications (Lambda, API Gateway, DynamoDB) ✅ Active
App Runner Fully Managed Container web apps/APIs without any infrastructure management ✅ Active
OpsWorks Configuration Mgmt Chef/Puppet based configuration management ❌ EOL (2024)
AWS Proton Template Orchestration Standardized microservice deployment templates ⚠️ EOL Oct 2026

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Your team is excited about the use of AWS because now they have access to programmable infrastructure. You have been asked to manage your AWS infrastructure in a manner similar to the way you might manage application code. You want to be able to deploy exact copies of different versions of your infrastructure, stage changes into different environments, revert back to previous versions, and identify what versions are running at any particular time (development, test, QA, production). Which approach addresses this requirement?
    1. Use cost allocation reports and AWS OpsWorks to deploy and manage your infrastructure.
    2. Use AWS CloudWatch metrics and alerts along with resource tagging to deploy and manage your infrastructure.
    3. Use AWS Elastic Beanstalk and a version control system like GIT to deploy and manage your infrastructure.
    4. Use AWS CloudFormation and a version control system like GIT to deploy and manage your infrastructure.
  2. An organization is planning to use AWS for their production roll out. The organization wants to implement automation for deployment such that it will automatically create a LAMP stack, download the latest PHP installable from S3 and setup the ELB. Which of the below mentioned AWS services meets the requirement for making an orderly deployment of the software?
    1. AWS Elastic Beanstalk
    2. AWS CloudFront
    3. AWS CloudFormation
    4. AWS DevOps
  3. You are working with a customer who is using Chef configuration management in their data center. Which service is designed to let the customer leverage existing Chef recipes in AWS?
    Note: AWS OpsWorks reached EOL in 2024. For Chef-based configuration management on AWS, customers should now use Chef SaaS or AWS Systems Manager with Chef recipes via Application Manager.
    1. Amazon Simple Workflow Service
    2. AWS Elastic Beanstalk
    3. AWS CloudFormation
    4. AWS OpsWorks (Historical answer – service now deprecated)
  4. A company wants to define their infrastructure using a programming language like TypeScript instead of writing YAML templates. They want the same reliability as CloudFormation but with less boilerplate code. Which AWS service should they use?
    1. AWS Elastic Beanstalk
    2. AWS Cloud Development Kit (CDK)
    3. AWS SAM
    4. AWS App Runner
  5. A startup wants to deploy a containerized web application with minimal infrastructure management. They want automatic scaling, load balancing, and a CI/CD pipeline connected to their GitHub repository. Which AWS service provides the simplest solution?
    1. Amazon ECS with Fargate
    2. AWS Elastic Beanstalk
    3. AWS App Runner
    4. AWS CloudFormation
  6. A team is building a serverless application using Lambda functions, API Gateway, and DynamoDB. They want to define their infrastructure using a simplified template syntax with built-in local testing capabilities. Which tool is most appropriate?
    1. AWS CloudFormation
    2. AWS CDK
    3. AWS SAM
    4. AWS Elastic Beanstalk
  7. An organization has a large monolithic CloudFormation stack that they want to split into smaller, focused stacks without recreating their existing infrastructure. Which CloudFormation feature enables this?
    1. CloudFormation StackSets
    2. CloudFormation Change Sets
    3. CloudFormation Stack Refactoring
    4. CloudFormation Nested Stacks

References