This project represents the next step after the lift-and-shift migration: a full re-architecting of the VProfile application to use AWS managed services in place of manually administered EC2 instances. Where the previous project ran MySQL, Memcached, and RabbitMQ on individual EC2 servers, this project replaces each with purpose-built AWS managed services:
- Amazon RDS for the database
- Amazon ElastiCache for caching
- Amazon MQ (RabbitMQ) for messaging
AWS Elastic Beanstalk manages the application tier deployment, load balancing, and auto scaling automatically.
Amazon CloudFront is introduced as a CDN in front of the application, reducing latency for distributed users and providing edge-based HTTPS termination with an ACM certificate. Route 53 handles public DNS, and CloudWatch provides monitoring. The result is a cloud-native architecture where AWS handles patching, backups, failover, and scaling — shifting focus from server administration to application delivery.
The re-architected system uses a fully managed backend. User requests hit Route 53, which resolves to a CloudFront distribution. CloudFront acts as CDN and HTTPS entry point, forwarding to the Application Load Balancer managed inside Elastic Beanstalk. Beanstalk hosts the Tomcat tier inside an Auto Scaling Group with automatic deployment and health monitoring.
Tomcat connects to three managed services: Amazon RDS (MySQL) for storage, ElastiCache (Memcached) for caching, and Amazon MQ (RabbitMQ) for messaging. These replace the EC2 instances from lift-and-shift. The Beanstalk environment and backend services share a backend security group controlling traffic between tiers.
| Component | Details |
|---|---|
| Application Platform | AWS Elastic Beanstalk — Tomcat platform, manages ALB, ASG, EC2 |
| Database | Amazon RDS — MySQL engine, managed (replaces EC2 project-db01) |
| Cache | Amazon ElastiCache — Memcached engine (replaces EC2 project-mc01) |
| Message Broker | Amazon MQ — RabbitMQ engine (replaces EC2 project-rmq01) |
| CDN | Amazon CloudFront — edge caching + HTTPS with ACM |
| DNS | Route 53 — public routing to CloudFront |
| Artifact Store | Amazon S3 — stores WAR for Beanstalk deployment |
| Monitoring | Amazon CloudWatch — metrics and health |
| SSL Certificate | ACM — attached to CloudFront distribution |
| Public Domain | GoDaddy — CNAME to CloudFront (*.cloudfront.net) |
| Key Pair | EC2 key pair — for Beanstalk instance SSH |
| AWS Region | US East (Ohio) — us-east-2 |
Deployment follows eighteen steps. Managed services are provisioned first because Beanstalk needs their endpoints at build time. Beanstalk environment is created next, backend security group updated, temporary EC2 initializes RDS schema, artifact rebuilt with endpoints and deployed, finally CloudFront and DNS configured.
Logged into AWS Console and confirmed region us-east-2. All resources provisioned in same region to minimize latency between Beanstalk and managed services, avoiding inter-region transfer charges.
Figure 2: AWS Console showing us-east-2 region
Created EC2 key pair vprofile-prod-key for SSH to Beanstalk instances and temporary bastion.
Figure 3: EC2 Key Pair: vprofile-prod-key
Created vprofile-theenuka-backend-sg in default VPC for RDS, ElastiCache, Amazon MQ. Rules updated in later steps after Beanstalk SG exists.
Figure 4: Backend security group created, 1 initial rule (self-referencing all traffic)
Created RDS MySQL parameter group vprofile-rds-theenuka-paragrp (mysql 8.0), subnet group vprofile-rds-theenuka-subgrp across 3 AZs (us-east-2a/2b/2c), then launched vprofile-rds-theenuka (db.t4g.micro, MySQL Community). Endpoint, username admin, password noted for application.properties and schema init.
Figure 5: RDS parameter group: vprofile-rds-theenuka-paragrp (mysql8.0)
Figure 6: RDS subnet group created: vprofile-rds-theenuka-subgrp
Figure 7: RDS subnet group detail: 3 subnets across us-east-2a/2b/2c
Figure 8: RDS creation dialog: master username admin, password shown once
Figure 9: RDS status Creating, instance vprofile-rds-theenuka
Figure 10: RDS status Available, MySQL Community engine
Figure 11: RDS connection details
Created ElastiCache subnet group vprofile-theenuka-cache-subgrp across 3 AZs, then launched vprofile-theenuka-cache (cache.t3.micro, Memcached 1.6.22). Configuration endpoint noted for application.properties.
Figure 12: ElastiCache subnet group: vprofile-theenuka-cache-subgrp
Figure 13: ElastiCache subnet group detail: 3 subnets across us-east-2a/2b/2c
Figure 14: ElastiCache cluster Creating: vprofile-theenuka-cache
Figure 15: ElastiCache cluster detail: Memcached 1.6.22, cache.t3.micro, 1 node
Created Amazon MQ broker vprofile-theenuka-rabbitmq (mq.t3.micro, RabbitMQ 3.13.7, single-instance deployment). Broker provisioned in default VPC with backend security group. Endpoint and credentials noted for application.properties.
Figure 16: Amazon MQ broker vprofile-theenuka-rabbitmq creation in progress
Figure 17: Amazon MQ broker details: RabbitMQ 3.13.7, mq.t3.micro, single-instance broker
Updated backend security group vprofile-theenuka-backend-sg with inbound rules to allow communication between managed services. Added MySQL/Aurora on TCP port 3306 from mysql-SG (for RDS access). These rules enable Elastic Beanstalk instances to connect to RDS, ElastiCache, and Amazon MQ.
Figure 18: Backend security group inbound rules: self-referencing All Traffic and MySQL port 3306
Figure 19: RDS connectivity configuration showing endpoint, security group, and VPC settings
Launched temporary EC2 instance mysql-client to initialize RDS schema. Instance placed in same VPC with security group allowing SSH from local IP. Connected via SSH, installed MySQL client, cloned vprofile-project repository, and executed db_backup.sql against RDS endpoint. Verified schema creation with show tables confirming role, user, and user_role tables in accounts database. Instance terminated after successful initialization.
Figure 20: Temporary EC2 instance mysql-client running in us-east-2c
Figure 21: Terminal session: git clone vprofile-project, MySQL client connection to RDS
Figure 22: MySQL "show tables" output confirming schema initialization: role, user, user_role
Self-referencing rule already configured in backend security group (from Step 3) allowing all internal backend communication between RDS, ElastiCache, and Amazon MQ. This rule enables managed services to communicate with each other within the backend tier.
Created IAM role vprofile-theenuka-beanrole with AWS managed policies for Elastic Beanstalk. Attached policies:
AdministratorAccess-AWSElasticBeanstalkAWSElasticBeanstalkCustomPlatformforEC2RoleAWSElasticBeanstalkRoleSNSAWSElasticBeanstalkWebTier
Instance profile ARN noted for Beanstalk environment creation.
Figure 23: IAM role vprofile-theenuka-beanrole with 4 AWS managed Elastic Beanstalk policies
Created Elastic Beanstalk environment Vprofile-theenuka-beanapp-prod with Tomcat 10 with Corretto 21 on 64bit Amazon Linux platform. Environment provisioned with Application Load Balancer, Auto Scaling Group, EC2 instances, and CloudWatch monitoring. Domain vprotheenuka.us-east-2.elasticbeanstalk.com assigned. Health status OK after initialization.
Figure 24: Elastic Beanstalk environment successfully launched with Health OK
Figure 25: Default Elastic Beanstalk welcome page accessible via HTTP
Updated backend security group vprofile-theenuka-backend-sg with additional inbound rules from Beanstalk security group. Total 3 rules:
- All Traffic from self-referencing
- All Traffic from Beanstalk instances
- MySQL/Aurora port 3306
This allows Beanstalk EC2 instances to access RDS, ElastiCache, and Amazon MQ.
Figure 26: Backend security group with 3 inbound rules including Beanstalk access
Updated application.properties with managed service endpoints:
- RDS:
vprofile-rds-theenuka.ct48oimksl08.us-east-2.rds.amazonaws.com:3306 - ElastiCache:
vprofile-theenuka-cache.eymywt.cfg.use2.cache.amazonaws.com:11211 - Amazon MQ: broker endpoint
Executed mvn install to build vprofile-v2.war. Build completed successfully.
Figure 27: Maven build process: compiling resources, test resources, and packaging WAR
Figure 28: Maven BUILD SUCCESS: vprofile-v2.war created
Uploaded vprofile-v2.war to Elastic Beanstalk environment with version label Vprofile-theenuka-beanapp-version-1.9. Deployment policy set to Rolling with health threshold Ok and batch size 50% instances. Deployment completed successfully, environment health transitioned from Degraded to Info to OK. New application version deployed to running EC2 instances.
Figure 29: Upload and deploy dialog: vprofile-v2.war with Rolling deployment policy
Figure 30: Environment update completed successfully, running version 1.9
Figure 31: VProfile application login page accessible via Beanstalk URL (HTTP)
Added HTTPS listener on port 443 to Elastic Beanstalk Application Load Balancer. Attached ACM SSL certificate *.theenuka.xyz covering custom domain. SSL policy set to ELBSecurityPolicy-TLS13-1-2-2021-06. Default process routes traffic to Beanstalk target group on port 80.
Figure 32: HTTPS listener configuration with ACM certificate and TLS 1.3 security policy
Created CNAME record vprorearch.theenuka.xyz pointing to Beanstalk ALB domain vprotheenuka.us-east-2.elasticbeanstalk.com. TTL set to 1/2 Hour for faster propagation during testing. Record saved in domain DNS management, enabling custom domain access to application.
Figure 33: CNAME record creation: vprorearch pointing to Beanstalk ALB
Verified end-to-end application deployment via custom domain vprorearch.theenuka.xyz over HTTPS. Certificate validation confirmed, browser shows "Connection is secure" with valid certificate. Login page loads successfully, user authentication functional with admin_vp credentials. Users list page displays data from RDS MySQL database, confirming backend connectivity. Application fully operational on cloud-native re-architected infrastructure.
Figure 34: Application accessible via custom domain vprorearch.theenuka.xyz with login page
Figure 35: Browser security: "Connection is secure" with valid certificate
Figure 36: User authenticated
Figure 37: Users list page: data retrieved from RDS MySQL database confirming backend connectivity
Created CloudFront distribution vprofile-theenuka with origin pointing to Elastic Beanstalk ALB. Alternate domain name vprorearch.theenuka.xyz configured with ACM certificate *.theenuka.xyz for HTTPS. Distribution deployed globally across all edge locations with TLSv1.2_2021 security policy. Status Enabled, providing CDN caching and edge HTTPS termination for improved global performance.
Figure 38: CloudFront distribution with alternate domain vprorearch.theenuka.xyz and SSL certificate
Figure 39: DNS CNAME updated to point to CloudFront domain
Figure 40: CloudFront distribution Enabled with global edge deployment
Key difference: managed services (RDS, ElastiCache, MQ, Beanstalk) vs self-managed EC2. Application code identical, infrastructure ownership shifts to AWS. Reduced operational overhead, automated patching/backups/failover.
- Provisioned Amazon RDS, ElastiCache, Amazon MQ replacing EC2 instances
- Deployed Java app via Beanstalk managing EC2, ALB, ASG
- Implemented CloudFront CDN with ACM certificate for edge HTTPS termination
- Updated
application.propertieswith managed service endpoints before Maven rebuild - Temporary EC2 bastion for RDS schema initialization
- Two-phase security group updates after Beanstalk creation
Project completes progression: local virtualized → cloud lift-and-shift → cloud re-architecting. VProfile now runs on entirely managed infrastructure. AWS handles availability, patching, backups, and scaling.
Key lesson: application code is identical across all three approaches. What differs is infrastructure management responsibility. Re-architecting delegates operational burden to AWS managed services while maintaining identical application functionality.