In this step of the vProfile re-architecture project, the goal was to deploy the Java application through AWS Elastic Beanstalk. Instead of manually building every application-layer resource one by one, Beanstalk helps package the deployment workflow into a managed environment.
That does not mean Beanstalk hides every AWS concept. It still uses services such as EC2, load balancing, Auto Scaling, and IAM, but it makes the deployment process much faster and easier to manage.
Why Use Elastic Beanstalk?
A manual deployment usually means configuring servers, choosing a platform, handling scaling settings, and wiring load balancing before the application even becomes reachable.
Beanstalk manages the environment using AWS services in the background. In a web application environment, that can include EC2 instances, an Auto Scaling group, an Elastic Load Balancing resource, health monitoring, and application version storage.
Roles Required for the Environment
Before creating the environment, it is important to understand that Beanstalk uses two different IAM role types.
- Service role: used by Elastic Beanstalk to call other AWS services on the environment’s behalf
- EC2 instance profile: attached to the EC2 instances so they can fetch application versions, write logs, and perform environment-level tasks
Create the Beanstalk Application
In this setup, the application was created as a web server environment using a Tomcat platform for the Java-based vProfile application.
- Application name:
vprofile-rearch - Environment tier: Web server
- Platform: Tomcat / Java
Beanstalk applications can contain multiple environments such as development, staging, and production, which makes it easier to organize deployments over time.
Public URL and Environment Access
Elastic Beanstalk provides an environment domain name that can be used to access the application after deployment.
This gives a simple way to test the environment before using a custom domain later.
Choose Custom Configuration
For this project, the better choice was custom configuration, because it allows more control over roles, networking, storage, scaling, health reporting, and deployment behavior.
Roles, SSH Access, and Key Pair
During environment creation, the service role and the EC2 instance profile are selected. An EC2 key pair can also be attached if SSH access to the instances is needed later for troubleshooting.
Networking Choice in This Setup
In this specific setup, the environment was placed in the default VPC with public access for the application layer, while backend services such as RDS, cache, and messaging stayed private.
- VPC: default VPC
- Environment access: public-facing web app
- Backend services: private
That separation is useful because the web layer can receive user traffic while the database and other backend services remain isolated from direct public access.
Storage and Launch Template Detail
For the root volume, using gp3 is a useful modern
choice. In Elastic Beanstalk, a gp3 root volume
setting can also cause environments to use launch templates
instead of older launch configurations.
Capacity and Scaling
For a load-balanced environment, Beanstalk uses an Auto Scaling group. In this project, the environment was configured with a minimum of two instances and a maximum of four.
Two instances are not a universal AWS requirement for every load balanced setup, but choosing two is a practical availability decision because it avoids relying on only a single EC2 instance.
Scaling Triggers
Elastic Beanstalk environments use CloudWatch alarms to trigger scaling events. Common choices include outbound network traffic, CPU utilization, latency, and request-related metrics depending on the application behavior.
Load Balancer and Traffic Routing
A load-balanced Beanstalk environment can create and manage an Elastic Load Balancing resource for the application. In this setup, an Application Load Balancer was chosen for HTTP traffic.
The load balancer distributes incoming requests across the EC2 instances in the environment.
Session Stickiness
Stickiness can be helpful when a web application depends on local session state and users should stay on the same instance for a period of time.
Health Reporting and Monitoring
Enhanced health reporting gives better visibility into instance and application status during deployments and while the environment is running.
Deployment Policies
One of the most important Beanstalk decisions is how application updates are deployed to running instances. AWS supports several deployment policies, each with different tradeoffs.
In this setup, rolling deployment was chosen with a percentage-based batch approach.
Environment Properties
Elastic Beanstalk also allows application configuration through environment properties. These become useful when wiring the app to backend services later.
These values were not required immediately for the first setup step, but they are important for application connectivity.
Connecting Beanstalk to Backend Services
After the Elastic Beanstalk environment is created, the application instances still cannot communicate with backend services such as RDS, ElastiCache, and Amazon MQ unless network access is explicitly allowed.
All backend services were placed inside a shared backend security group. To allow the application to access them, I needed to update the inbound rules of that security group.
Each Beanstalk environment creates two security groups:
- Instance security group attached to EC2 instances
- Load balancer security group
It is important to use the instance security group, not the load balancer security group.
This allows the application layer to connect to:
- RDS (MySQL - port 3306)
- Memcached (port 11211)
- RabbitMQ (port 5672)
After this step, the architecture becomes fully connected:
What Happens After Submission
After reviewing the configuration and submitting the environment creation, Elastic Beanstalk provisions the resources needed for the application environment.
- Create EC2 instances for the environment
- Configure Auto Scaling
- Configure the load balancer
- Enable health monitoring
Simple Architecture View
What I Learned
- Elastic Beanstalk simplifies Java application deployment
- It still uses core AWS services behind the scenes
- IAM roles and instance profiles are essential to the setup
- Deployment policy choices directly affect uptime and risk
- Beanstalk speeds up delivery without removing architecture thinking
Conclusion
This step made the deployment layer much clearer. Instead of manually assembling every application-facing AWS resource, I could use Elastic Beanstalk to create a managed environment and focus more on application delivery decisions.
It also showed that Beanstalk is not “magic.” Good choices around roles, scaling, networking, health checks, and deployment strategy still matter if the goal is a stable production-style setup.