I Built a Scalable Student Result Portal on AWS With Load Balancing, Auto Scaling, and RDS

In this project, I upgraded a simple AWS web application into a scalable multi-instance architecture using an Application Load Balancer, Auto Scaling, Amazon EC2, and Amazon RDS for SQL Server. Instead of relying on a single server, the application can now distribute traffic across multiple EC2 instances, replace unhealthy instances automatically, and use one shared managed database for persistent student result data.

Ali Khan

Published Oct 16, 2026

Last modified Oct 16, 2026

From a Single Server to a Scalable AWS Architecture

The goal was to build a Student Result Portal that could remain available even if one application server failed and could scale when demand increased.

The final architecture included:

Amazon EC2
Application Load Balancer
Target Groups
Auto Scaling Group
Launch Templates
Amazon RDS for SQL Server
Multiple Availability Zones
Security Groups
Public and private subnets

The final application flow looked like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Internet

   |

   v

Application Load Balancer

   |

   v

Target Group

  /       \

 v         v

EC2-1     EC2-2

  \       /

   \     /

    v   v

 Amazon RDS

 SQL Server

Reusing the Existing VPC

Instead of creating a completely new network, I reused my existing AWS VPC:

1
2
Air-University-VPC

10.0.0.0/16

I already had one public subnet and one private subnet.

To support multiple Availability Zones, I added:

1
2
Public-Subnet-2

Private-Subnet-2

This gave the architecture subnet coverage across two different Availability Zones.

The public subnets were used for the Application Load Balancer and Auto Scaling EC2 instances, while the private subnets were used for the Amazon RDS DB subnet group.

VPC Resource Map Pic here — Subnets Split across two regions

Moving Student Data to Amazon RDS

In my previous project, student records were stored inside a JSON file in Amazon S3.

For this lab, I moved the data into a proper relational database using Amazon RDS for Microsoft SQL Server.

The RDS instance was configured with:

1
2
3
4
5
6
7
8
9
10
11
Database Engine:

Microsoft SQL Server



Database:

studentdb



Port:

1433



Publicly Accessible:

No

I also created a dedicated database security group:

1
RDS-SG

Its important inbound rule was:

1
2
3
4
Type: MSSQL

Protocol: TCP

Port: 1433

Source: Web-Server-SG

This means the database accepts SQL Server traffic from the application servers but is not directly exposed to the internet.

Creating the Student Database

After creating the RDS instance, I tested connectivity from EC2 to RDS using port 1433.

I then created:

1
studentdb

and a students table containing:

1
2
3
4
5
6
id

name

registration

course

marks

grade

A sample student result was inserted and verified using SQL Server command-line tools.

Example query:

1
SELECT * FROM students;

Sql-Query-output Pice Here — Sql Query Output

This confirmed that the EC2 application tier could successfully connect to the private RDS database and retrieve stored data.

Building the Web Application with Flask

The web application was built using:

1
2
3
Python

Flask

pyodbc

Flask handled HTTP requests, while pyodbc allowed the application to communicate with Microsoft SQL Server.

The application retrieves student result information using:

1
2
SELECT id, name, registration, course, marks, grade

FROM students;

and displays the results in an HTML table.

I also displayed the hostname of the EC2 instance serving the request using:

1
socket.gethostname()

This became important when testing the load balancer later.

Creating the Application Load Balancer

Next, I created an internet-facing Application Load Balancer:

1
Student-Portal-ALB

The load balancer listens on:

1
2
HTTP

Port 80

and forwards incoming requests to:

1
Student-Web-TG

The target group performs health checks using:

1
2
3
Protocol: HTTP

Path: /

Success Code: 200

ALB Target Group Pic Here — ALB forwarding to Target Group

Instead of users connecting directly to individual EC2 instances, requests now follow this path:

1
2
3
4
5
6
7
Internet

   |

   v

Application Load Balancer

   |

   v

Healthy EC2 Instances

Using a Launch Template

To make every EC2 instance use the same configuration, I created:

1
Student-Web-Launch-Template

The Launch Template defined:

1
2
3
4
5
6
7
8
9
10
11
AMI:

Amazon Linux 2023



Instance Type:

t3.micro



Security Group:

Web-Server-SG



User Data:

Automatic web server setup

The User Data script automatically installed the required software, including:

1
2
3
4
Python

Flask

pyodbc

Microsoft ODBC Driver 18

It also created the Flask application and started it on port 80.

Launch Template Pic Here — EC2 Launch Template

This allowed new EC2 instances to configure themselves automatically without requiring manual setup.

Auto Scaling the Application

I then created:

1
Student-Web-ASG

with the following capacity configuration:

1
2
3
Minimum Capacity: 2

Desired Capacity: 2

Maximum Capacity: 4

The Auto Scaling Group launches instances across two public subnets in different Availability Zones.

I also configured a target-tracking scaling policy using:

1
2
3
4
5
Metric:

Average CPU Utilization



Target:

50%

This allows AWS to launch more EC2 instances when demand increases and reduce the number of instances when demand decreases.

auto-scaling-group pic here — Auto Scaling Group

Debugging the Auto Scaling Instances

One of the most useful parts of this lab was troubleshooting unhealthy Auto Scaling instances.

Initially, the instances were failing health checks because Flask had not been installed correctly.

The application log showed:

1
ModuleNotFoundError: No module named 'flask'

The cloud-init logs revealed that the User Data script had failed during dependency installation.

Instead of manually fixing each EC2 instance, I corrected the Launch Template and created a new template version.

The Auto Scaling Group then launched replacement instances using the corrected configuration.

Eventually, the target group showed:

1
2
3
2 Total

2 Healthy

0 Unhealthy

healthy-targets pic here — Healthy Targets

This helped me understand an important Auto Scaling principle:

1
2
3
Do not manually repair temporary Auto Scaling instances.



Fix the Launch Template so every replacement instance is created correctly.

Proving Load Balancing

After both EC2 instances became healthy, I opened the DNS name of the Application Load Balancer in the browser.

The Student Result Portal displayed the same student data from Amazon RDS.

However, refreshing the page showed different values for:

1
Web Server:

because different requests were being handled by different EC2 instances.

portal-server-1 pic here — Application Load Balancer routing a request to the first EC2 instance while displaying shared RDS data

portal-server-2 pic here — Application Load Balancer routing a request to a different EC2 instance while displaying the same RDS data

This proved that the architecture was successfully load balancing requests:

1
2
3
4
5
6
7
Same Application

      +

Same RDS Data

      +

Different EC2 Instance

      =

Load Balancing Working

Final Architecture

The completed architecture looked like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
                     Internet

                        |

                        v

              Student-Portal-ALB

                        |

                        v

                 Student-Web-TG

                  /           \

                 v             v

              EC2-1           EC2-2

              Flask           Flask

                 \             /

                  \           /

                   v         v

                 Amazon RDS

                 SQL Server

                 studentdb

The Application Load Balancer distributes requests only to healthy EC2 instances.

The Auto Scaling Group maintains the required number of instances and can create replacements if one becomes unhealthy.

Both application servers connect to the same Amazon RDS database, allowing them to display the same persistent student result data.

What I Learned

This lab helped me understand how AWS applications can become more scalable and resilient.

The main concepts I learned were:

How Application Load Balancers distribute incoming requests
How Target Groups track application servers and their health
How Auto Scaling Groups maintain application capacity
How Launch Templates create repeatable EC2 configurations
How multiple Availability Zones improve availability
How Amazon RDS provides shared persistent data for multiple application servers
How Security Groups control communication between application layers
Why application servers should not depend on local data
Why infrastructure configuration should be automated instead of manually repeated

The Student Result Portal itself was simple, but the architecture behind it demonstrated how several AWS services can work together to create a scalable and highly available cloud application.

# student-builders # students # amazon-rds # auto-scaling # load-balancing

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.

Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article

Builder Center

I Built a Scalable Student Result Portal on AWS With Load Balancing, Auto Scaling, and RDS

Ali Khan

From a Single Server to a Scalable AWS Architecture

Reusing the Existing VPC

Moving Student Data to Amazon RDS

Creating the Student Database

Building the Web Application with Flask

Creating the Application Load Balancer

Using a Launch Template

Auto Scaling the Application

Debugging the Auto Scaling Instances

Proving Load Balancing

Final Architecture

What I Learned