After creating the Elastic Beanstalk environment and allowing the application layer to reach the backend services, the next step was to complete the actual application deployment. This is the stage where the vProfile stack starts behaving like a full working system rather than a collection of separate AWS services.
At this point, the environment, database, cache, and messaging layers already existed. The remaining work was to connect the app to the right backend endpoints, build the deployable artifact, publish it through Elastic Beanstalk, and then secure the public entry point properly.
Deployment Flow
Collect Backend Service Information
Before deployment, the application needed the correct connection details for each backend service. These values come from the AWS console pages for RDS, ElastiCache, and Amazon MQ.
5671. That is why the endpoint is different from a
plain non-TLS RabbitMQ setup.
Update the Application Configuration
After gathering the endpoints, the application configuration had to be updated so the Beanstalk-hosted app could talk to the right backend services.
In practice, the exact property names depend on the application, but the configuration usually includes values like database host, cache host, broker endpoint, usernames, passwords, and ports.
Build the Application Artifact
Once the configuration was ready, the next step was to build the deployable artifact locally. For the Java-based vProfile project, this meant generating the WAR file through Maven.
The build output is typically the deployable WAR file inside the target directory.
Deploy the Application Version to Beanstalk
Elastic Beanstalk treats the uploaded artifact as an application version. After the WAR file is ready, it can be uploaded and deployed from the environment dashboard.
- Open the Elastic Beanstalk environment
- Choose Upload and deploy
- Select the generated WAR file
- Set a version label
- Start the deployment
Beanstalk then distributes that version to the EC2 instances in the environment according to the deployment policy that was chosen earlier.
Deployment Behavior During the Update
In this setup, a rolling deployment with percentage-based batches was used. That means Beanstalk updates one batch of instances at a time instead of replacing everything at once.
This helps reduce disruption during deployment, but it is different from rolling with additional batch or traffic splitting, which are the safer choices when maintaining full capacity or canary-style rollout is critical.
Verify That the Application Works
After deployment completes, the first check is the Beanstalk environment URL.
A successful verification usually means more than simply loading the home page. The important part is confirming that the app can actually communicate with its backend dependencies.
- The application loads through the Beanstalk URL
- Authentication or login works as expected
- Pages that depend on database reads respond correctly
- No backend connection errors appear in the logs
Enable HTTPS for the Environment
By default, a new web environment may begin with HTTP access. To secure user traffic properly, the load balancer needs an HTTPS listener and a valid certificate.
- Add an HTTPS listener to the load balancer
- Use port
443 - Attach an ACM certificate for the application domain
This allows TLS termination at the load balancer so the public entry point becomes secure.
Map a Custom Domain
Elastic Beanstalk environments already have a default domain name, but a custom domain makes the deployment feel production-ready and easier to present.
The environment URL is based on an Elastic Beanstalk CNAME, and a custom DNS record can point users to that environment. With Route 53 this is often done as an alias, and with external DNS providers it is commonly done with a CNAME where appropriate.
Final Architecture View
What I Learned
- Final deployment depends on both infrastructure and application configuration
- Correct backend endpoints and ports are essential
- Rolling deployments reduce risk compared with all-at-once updates
- HTTPS is completed at the load balancer with a certificate
- A custom domain makes the environment easier to use and present
Conclusion
This step brought the full vProfile environment together. The app was no longer just deployed on Beanstalk in isolation. It became a connected application using a managed database, cache, message broker, load balancer, and secure public access path.
It also showed that successful deployment is not only about uploading a WAR file. Good endpoint management, health checks, secure listeners, and DNS setup are what make the environment feel complete and dependable.