Guidance on Optimizing AWS Architecture for Java Microservice Application with Client Load Handling

Hi,

Based on your current setup and requirements, here are some recommendations to optimize your AWS architecture for your Java microservice application:

To answer the questions you mentioned in the post :

1)Scalability: Can we adopt Auto Scaling Groups (ASG) and reduce the size of our primary EC2 instance from 32 GB to 16 GB, while scaling out dynamically based on load?

Answer : Yes, implementing Auto Scaling Groups (ASG) with smaller instance sizes is possible while maintaining dynamic scaling capabilities. Amazon EC2 Auto Scaling allows you to create collections of instances that can automatically scale up or down based on defined policies and application demands. [1] [2]

You can set up two ASGs - one for peak hours and another for off-peak hours, with different instance sizes to handle varying loads effectively. The system can automatically scale the number of instances needed based on scaling policies that are defined according to your application's specific demands.

To implement this effectively, you should:

a) Configure an Application Load Balancer (ALB) with two target groups.
b) Set up health checks to ensure only healthy instances receive traffic.
c) Create CloudWatch alarms to monitor traffic patterns.
d) Implement auto scaling policies to automatically scale instances up and down based on traffic thresholds.

2)Database: Would migrating from MySQL on EC2 to Amazon RDS improve performance, manageability, and availability? [3]

Answer: Amazon RDS is a fully managed service for running relational databases on Amazon Web Services (AWS). It has support for six different database engines, including commercial options such as SQL Server and Oracle.

And Yes, migrating to Amazon RDS would provide several key improvements. Amazon RDS is a fully managed service that handles common administrative tasks such as setting up, operating, and scaling relational databases in the cloud. The service automatically manages infrastructure provisioning, database software installation, and routine administrative tasks like backups and patching .

For availability improvements, Amazon RDS offers multiple Availability Zone deployments with synchronous data replication and automatic failover capabilities. You can also set up standby instances in different Availability Zones within the same AWS Region to protect against data center failures.

To migrate a self-managed SQL Server database to a fully managed database on Amazon RDS please follow the below steps :

a) create a sql server database in Amazon RDS . b) create a replication instance in AWS Database migration service(AWS DMS). c) create a source and target end points for database migration. d) create a replication task in AWS DMS. e) complete the migration and cleanup resourses.

However to simplify the migration process, AWS has recently introduced a "1-click move to managed" feature that enables seamless migration from self-managed MySQL databases to Amazon RDS or Aurora. This feature leverages AWS Database Migration Service (DMS) to automate the entire process, including networking and system configuration.

3)Cost Optimization: Given that we are currently using Savings Plans, how can we optimize our instance selection and architecture to further reduce costs? [4]

Answer: AWS Savings Plans offers several optimization strategies to maximize cost efficiency. You can save up to 72% compared to On-Demand prices by committing to a one- or three-year hourly spend commitment. The service automatically applies savings across eligible AWS usage and works with the newest instance families, generations, and regions while continuing to save.

To optimize further, you can follow AWS Cost Explorer Savings Plans recommendations to maximize your savings. For steady-state workloads, you can reduce compute bills regardless of instance family, Region, operating system, and tenancy. Additionally, costs can be optimized when migrating workloads to newer instances or modernizing applications with AWS Lambda and AWS Fargate.

The management of these savings can be centralized by purchasing Savings Plans in one AWS account, which will automatically apply across your AWS organization.

4. Managed Services: Are there recommended AWS managed services for Elasticsearch and Redis that would improve scalability and reduce operational overhead?

Answer) Yes, AWS offers managed services for both Elasticsearch and Redis that can significantly improve scalability and reduce operational overhead. Here's a detailed explanation of the recommended services:

=> For Elasticsearch: Amazon OpenSearch Service (formerly Amazon Elasticsearch Service)

Amazon OpenSearch Service is a fully managed service that makes it easy to deploy, operate, and scale OpenSearch clusters in the AWS Cloud. OpenSearch is the open-source successor to Elasticsearch. It is Easy to deploy and manage, provides Scalability, High Availability, Security and Monitoring .

=> For Redis: Amazon ElastiCache for Redis.

Amazon ElastiCache for Redis is a fully managed, Redis-compatible in-memory data store and cache service. It Supports cluster mode for horizontal scaling and offers Multi-AZ with automatic failover and provides high performance and security.

5. What AWS architecture best practices should we consider for this type of application with variable client load in a single instance, and active and cold DR setups?

The architecture follows a modern, cloud-native design that's built for scalability, reliability, and maintainability. It's structured in multiple tiers, each serving a specific purpose while working together to deliver the application efficiently.

a) Front-end tier : The frontend tier serves as the entry point for all user interactions. It utilizes :

=> Amazon CloudFront as a Content Delivery Network (CDN) to cache and serve static content from edge locations closest to users, significantly reducing latency.

=> Static assets like images, CSS, and JavaScript files are stored in Amazon S3 buckets, providing highly durable and available storage.

=> Amazon Route 53 handles DNS management, implementing intelligent routing strategies to direct users to the most appropriate endpoints.

b) Application tier : The application tier, which hosts the Java-based microservice.

=> An Application Load Balancer (ALB) Places at the front, distributing incoming traffic across multiple EC2 instances running in an Auto Scaling Group (ASG).

=> The ASG automatically adjusts the number of instances based on demand, ensuring optimal resource utilization and performance. Each EC2 instance runs the Java application, and the stateless design allows for seamless scaling.

=> AWS Secrets Manager securely stores and manages sensitive credentials and configuration data.

c) Data Tier : The data tier consists of several complementary services.

=> Amazon RDS provides a managed MySQL database service with built-in high availability through Multi-AZ deployment and scalability through read replicas.

=> Amazon ElastiCache for Redis handles session management and provides a fast, in-memory caching layer to reduce database load and improve response times.

=> Amazon OpenSearch Service (formerly Elasticsearch) powers the search functionality with high performance and scalability.

Data Recovery setups:

The Active Region (Primary Production): The Active Region represents your primary production environment where all your live operations run. This region contains your complete production setup, including all application servers, databases, caching layers, and associated services. It's fully operational 24/7 and handles all your current user traffic. The key aspect of this region is that it continuously replicates critical data to the DR region, ensuring that your backup site maintains an up-to-date copy of your production data.

Cold DR Region (Disaster Recovery Site) : The Cold DR Region serves as your backup site and is designed to be cost-effective while maintaining readiness for emergencies. Instead of running a full duplicate of your production environment, this region maintains minimal active resources. The infrastructure is defined and managed through Infrastructure as Code (IaC) using either CloudFormation or Terraform, which allows for quick and reliable deployment when needed.

References : [1] https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html [2] https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scale-based-on-demand.html#as-how-scaling-policies-work [3] https://aws.amazon.com/tutorials/move-to-managed/migrate-sql-server-to-amazon-rds/ [4] https://aws.amazon.com/savingsplans/?refid=ap_card

Based on your current setup and requirements, here are some recommendations to optimize your AWS architecture for your Java microservice application:

Scalability: Yes, adopting Auto Scaling Groups (ASG) is a good approach. You can reduce the size of your primary EC2 instance from 32 GB to 16 GB and use ASG to scale out dynamically based on load. This will allow you to handle variable client demand more efficiently. However, for Java applications, it's important to note that memory utilization may not be the best metric for scaling. Instead, consider using CPU utilization or average connections as your scaling metric, depending on your application's behavior under load.

Database: Migrating from MySQL on EC2 to Amazon RDS would indeed improve performance, manageability, and availability. RDS provides automated backups, software patching, and easy scaling options. It also offers multi-AZ deployments for high availability. This migration would reduce your operational overhead and potentially improve your application's reliability.

Cost Optimization: While Savings Plans are beneficial, you can further optimize costs by:

1. Using a mix of On-Demand, Reserved Instances, and Spot Instances where appropriate.
2. Implementing proper instance scheduling to turn off non-production resources when not in use.
3. Regularly reviewing your usage with AWS Cost Explorer to identify areas for optimization.
4. Using AWS Budgets to set alerts when costs exceed predefined thresholds.

Managed Services: For Elasticsearch, consider using Amazon Elasticsearch Service (now called Amazon OpenSearch Service). For Redis, Amazon ElastiCache is a great option. These managed services will improve scalability and significantly reduce your operational overhead.

Overall Architecture: For your type of application with variable client load, consider the following best practices:

1. Use Elastic Load Balancing in front of your Auto Scaling Group to distribute traffic evenly.
2. Implement a content delivery network (CDN) like Amazon CloudFront to reduce latency and offload your application servers.
3. Use Amazon S3 to host your Angular frontend as a static website, which can significantly reduce the load on your application servers.
4. Implement proper monitoring and alerting using Amazon CloudWatch to proactively manage your application's performance.
5. Consider using AWS Lambda for certain microservices that are suitable for serverless architecture, which can further improve scalability and reduce costs.

By implementing these changes, you should be able to create a more scalable, resilient, and cost-efficient solution that can better handle your growing client base and variable load.
Sources
Cost-Effective Deployment of Angular + Spring Boot + PostgreSQL Application on AWS | AWS re:Post
Optimizing Costs for EC2 in High-Traffic Scenarios? | AWS re:Post
Scaling Applications on AWS | AWS re:Post
Optimize Amazon ECS service auto scaling - Amazon Elastic Container Service