Elastic Beanstalk: Deploy Applications Without Worrying About Infrastructure

What Is Elastic Beanstalk?

Elastic Beanstalk is AWS's easy and quick deployment service. You upload your application, provide some configurations, and Beanstalk takes care of launching EC2 instances, setting up load balancers, configuring auto scaling, and deploying the application on your behalf.

If you remember the cloud service models, EC2 falls under Infrastructure as a Service. Elastic Beanstalk falls under Platform as a Service. In Platform as a Service, you are only responsible for the application and the data. You are not responsible for the operating system, the runtime, or the underlying infrastructure. Beanstalk manages all of that.

The backbone of Beanstalk is EC2. Under the hood, Beanstalk is still launching EC2 instances. But you never need to touch them directly.

One more important thing before we go further. Elastic Beanstalk itself is free. The service has no additional charge. But the resources it creates on your behalf, the EC2 instances, the load balancers, the storage, those are billable. So Beanstalk is free, but what it builds is not. For practice purposes using a T2 micro instance within the free tier, you will not be charged.

Also, a quick naming clarification. Do not abbreviate Elastic Beanstalk as EBS. EBS is already taken by Elastic Block Store. When you say EBS, everyone thinks storage.

What Languages Does Beanstalk Support?

Your application can be developed in Java, Python, Node.js, .NET, Go, Docker, and several other platforms. Beanstalk supports multiple platforms, and you select the one that matches your application during setup.

A note on platforms: if your application is built in Java, you need an application server called Tomcat, not just a web server. Apache is a web server. It handles simple static pages and redirects requests. Tomcat is an application server. It runs Java-based applications. Whenever you have a Java application to deploy, Tomcat is where it lives.

So the rule is simple. Select the platform based on how your application was developed. Java uses Tomcat. Python uses Python. Node.js uses Node.js. You get the idea.

The Architecture of Beanstalk: Application, Environment, EC2

Before clicking anything in the console, understand how Beanstalk organizes things.

The outermost layer is called an Application. This is just a name, a container. It is not your actual application code. Think of it as a folder that holds everything related to one project.

Inside the Application, you create one or more Environments. An environment is where the actual infrastructure lives. It contains EC2 instances, and inside those instances, your actual deployed application runs.

So the structure looks like this:

Application holds one or more Environments. Each Environment holds EC2 instances. Each EC2 instance runs your application code.

Every environment also gets its own domain URL. That is how users access the application running inside that environment.

Can one Application have multiple Environments? Absolutely. You can have a salary-related environment and a leave-management environment, both inside the same HR application. Each has its own URL, its own EC2 instances, and they are completely isolated from each other.

The Three Presets: Single Instance, High Availability, Custom

When you create an environment in Beanstalk, you choose a preset. The preset determines what infrastructure Beanstalk will build for you.

Single Instance Preset

One EC2 instance is launched. That is it. No load balancer, no auto scaling. Your application runs on one machine.

This is fine for development, testing, or QA environments. It is not suitable for production because there is no high availability. If that one instance goes down, your application goes down with it.

High Availability Preset

This creates a full production-ready setup. Beanstalk automatically creates an Application Load Balancer, launches multiple EC2 instances inside an Auto Scaling Group, and deploys your application across all of them.

You do not configure any of this manually. You simply select the High Availability preset, provide your configurations, and Beanstalk builds the entire stack.

This is the preset you use for production environments.

Custom Preset

In real projects, you will have your own VPC, your own security groups, your own subnets. You do not want Beanstalk creating its own default resources. When you want to bring your own networking setup, that is the Custom preset.

In Custom preset, Beanstalk still does all the heavy lifting, but it uses the VPC, subnets, key pairs, and security groups that you specify. This is what you will use in actual company projects.

For learning, Single Instance and High Availability are enough to understand what Beanstalk does for you.

Two Types of Environments: Web and Worker

Beanstalk environments come in two types.

A Web Server Environment is for running web applications. If you have a website or an API, you choose this.

A Worker Environment is for running background jobs and processes. If you have tasks that run on a schedule or process messages from a queue, you choose this.

For most deployments, you will be working with Web Server Environments.

The IAM Roles Beanstalk Needs

Before creating your first Beanstalk application, you need two IAM roles in place. If these roles do not exist, Beanstalk will not work properly.

The first is the Service Role. This allows Beanstalk to manage AWS resources on your behalf. The trusted entity for this role is Elastic Beanstalk. The name should be aws-elasticbeanstalk-service-role.

The second is the EC2 Instance Profile. This is the role attached to the EC2 instances that Beanstalk launches. The trusted entity is EC2. The name should be aws-elasticbeanstalk-ec2-role.

If you are on a new AWS account, these roles may not exist yet. You need to create them in IAM before proceeding. Once they are in place, Beanstalk will ask you to select them during setup. If they already exist on your account, they will appear in the dropdown automatically.

Creating Your First Beanstalk Application: Step by Step

Go to Elastic Beanstalk in the AWS console and click Create Application.

Step 1: Choose Environment Type

Select Web Server Environment.

Step 2: Application and Environment Details

Give your application a name. For this demo, call it 9am-beanstalk-demo. Set the environment name to blue. The domain URL will be generated based on the name you provide. Check if it is available.

Step 3: Select the Platform

Choose Tomcat as the platform. Select the latest version available.

Step 4: Upload Application Code

For now, use the sample application that Beanstalk provides. In real projects, you would upload your own zip file here. Browse and upload, or simply select Sample Application.

Step 5: Choose a Preset

Select Single Instance, free tier eligible.

Step 6: Configure Service Access

Select your service role and EC2 instance profile here. If the roles exist, they will appear in the dropdown. If not, cancel, go to IAM, create the roles, then come back.

Step 7: Configure Networking

Leave the VPC and subnet settings as they are. Let Beanstalk handle it.

Step 8: Instance Configuration

On new AWS accounts, change the root volume type to GP3. This is the only change needed here.

Step 9: Monitoring and Updates

Keep Basic health monitoring. Enable managed platform updates so Beanstalk can maintain the platform automatically. Leave everything else at default.

Click Submit.

That is it. Now watch what Beanstalk does. Go to the Events tab and you will see it creating an S3 bucket for environment data, creating a security group, allocating an Elastic IP, and launching an EC2 instance. All of this is happening automatically based on the configuration you provided.

Once the health indicator turns green, your application is live. Copy the domain URL and open it in your browser. You will see the sample Java application running.

Now go to EC2 in the console. You will find an instance running there that you never launched manually. That is Beanstalk doing its job. Do not stop it, do not restart it, do not modify it directly. Leave it to Beanstalk.

Deployment Policies: How Beanstalk Updates Your Application

Say your application is running on version 1 and the developer hands you a version 2 zip file. You need to deploy it across all your EC2 instances. Beanstalk handles this for you, but you need to tell it how to do the rollout. That is what deployment policies are for.

All at Once

Beanstalk deploys the new version to all instances simultaneously. It is fast, but there is downtime while the update happens. Use this only in non-production environments where a brief outage is acceptable.

Rolling

Beanstalk updates instances one by one. While one instance is being updated, the others keep serving traffic. No downtime. But with many instances, this takes longer because each one is done individually.

Rolling with Additional Batches

Instead of one at a time, Beanstalk updates a group of instances together. You define the batch size. This is faster than plain rolling and still has no downtime.

Immutable

This one is worth understanding in detail.

Beanstalk creates a brand new temporary Auto Scaling Group alongside your existing one. It launches fresh EC2 instances in that temporary group and deploys version 2 on them. Once it verifies that version 2 is healthy, it moves those instances from the temporary group into your current Auto Scaling Group. Then it terminates the version 1 instances and deletes the temporary group.

At no point is your current environment touched until the new instances are confirmed healthy. If something goes wrong, you can roll back without any impact to your users. No downtime, and the safest option of the four.

Blue-Green Deployment on Beanstalk

There is a scenario where none of the above deployment policies are sufficient. Imagine your customer comes to you and says the application looks great, but they want a completely different platform. Switch from Java to Python. And by the way, no downtime, not even for a second.

That is a platform-level change. You cannot do that on an existing environment. The deployment policies all modify the current running environment. What you need instead is Blue-Green deployment.

Here is how it works in Beanstalk.

Your current environment, which we are calling blue, is running a Java application on Tomcat. Customers are hitting the blue environment URL. Everything is working fine.

You create a parallel new environment, which we are calling green, running a Python application. You set it up completely, verify it is working, get the health indicator green, confirm the application is responding correctly.

Now your customers are still on blue. Green is ready and waiting. Not a single customer has been affected yet.

When you are ready to switch, go to the blue environment, click Actions, and select Swap Environment URLs.

Beanstalk swaps the domain URLs between the two environments. The URL that was pointing to blue now points to green. Customers hit the same URL they always have, but now they land on the Python application. Within seconds, every customer is on the new version. No downtime.

If something goes wrong after the swap, go to the green environment, click Actions, swap again. You are back to blue in seconds.

Customers never see the switch happening. They just refresh and the application looks different. That is Blue-Green deployment on Beanstalk.

Managing Environments: Save, Load, Clone, Rebuild

Inside an environment, the Actions menu gives you several useful options.

Save Configuration

This captures the current working configuration of your environment and saves it with a name. Think of it as a checkpoint. If someone makes changes later and breaks the environment, you can reload this saved configuration and restore it to a known good state.

Load Configuration

Loads a previously saved configuration and applies it to the environment. Your environment returns to exactly how it was when you saved it.

Clone

Creates an exact copy of the current environment. Useful when you need a duplicate for testing or for setting up a parallel green environment.

Restart App Servers

Restarts the application servers running inside the EC2 instances without terminating and recreating them. Do not restart EC2 instances directly from the EC2 console. Always do it through Beanstalk so it is aware of the state change.

Rebuild

Tears down and rebuilds the entire environment from scratch using the current configuration. Use only when absolutely necessary.

Terminate

Shuts down and deletes the environment. You can restore a terminated environment later from the Beanstalk console. However, if you delete the Application itself, everything inside it is gone permanently. Environments can be restored. Applications cannot.

Application Versions

Every time you upload new code to Beanstalk, a new version is stored. Version 1, version 2, version 3, and so on. You can view all versions under the Application Versions section inside your application.

If you ever need to roll back to a previous version, you can deploy it directly from this list. This gives you a full history of every deployment without needing any external version control on the Beanstalk side.

Wrapping Up

Elastic Beanstalk removes the operational burden from your application deployments. You bring the application, select the platform, choose a preset, and Beanstalk handles the rest. The EC2 instances, the load balancer, the auto scaling group, the security groups, all of it is created and managed by Beanstalk.

For quick single-instance testing, use the Single Instance preset. For production workloads that need high availability, use the High Availability preset. For environments that need your own networking setup, use the Custom preset.

For deploying updates, use the deployment policy that matches your tolerance for downtime and cost. All at Once is fastest but has downtime. Rolling and Rolling with Additional Batches have no downtime but are incremental. Immutable is the safest with no downtime but temporarily uses double the resources.

For platform-level changes or major updates where you cannot afford any risk to the live environment, Blue-Green deployment through URL swapping gives you a zero-downtime switch with instant rollback capability.

Before you start creating Beanstalk environments, make sure the two IAM roles exist. Create them in IAM with the correct trusted entities and permissions. Once those are in place, everything else in Beanstalk is just configuration and clicks.