As part of the AWS In-Practice Series – Serverless Computing on AWS, organized by the AWS Student Builder Group at Easwari Engineering College, I had the opportunity to build a Serverless Hostel / College Complaint Management System under the guidance of Jaya Ganesh Krishna Moorthy, Senior Application Developer at Genesys.

The goal was not just to create a simple demonstration. We built a complete workflow using multiple AWS services:

Amazon S3 Amazon API Gateway AWS Lambda Amazon DynamoDB Amazon SNS

This hands-on experience helped me understand how serverless services can be combined to create a scalable, event-driven cloud application without directly managing traditional backend servers.

What Problem Were We Solving?

Imagine a college or hostel where students need to submit complaints about different issues.

For example:

Hostel maintenance issues Electrical problems Water-related issues Room-related complaints General college or hostel concerns

A traditional application might follow an architecture like:

Frontend → Backend Server → Database → Notification System

This approach requires managing backend infrastructure, databases, scaling, deployment, and other operational requirements.

During the workshop, we explored a different approach using AWS managed services:

Frontend → API Gateway → Lambda → DynamoDB → SNS

Each AWS service was responsible for a specific part of the application.

This made the architecture easier to understand and demonstrated how multiple managed cloud services can work together to build a real-world application.

Why Serverless?

One of the biggest concepts I learned from this workshop was serverless computing.

Serverless does not mean that servers do not exist.

Instead, developers do not have to directly manage the underlying servers and infrastructure. AWS handles much of the infrastructure management, allowing developers to focus more on application logic.

Some advantages of a serverless approach include:

Reduced server management Automatic scaling based on demand Reduced operational overhead Faster application development Managed infrastructure Pay-for-usage pricing model Better developer productivity

For applications where workloads can vary, serverless architecture can be an effective approach.

Understanding the Architecture

The application follows a serverless and event-driven architecture.

The overall workflow is:

Student → Frontend → Amazon API Gateway → AWS Lambda → Amazon DynamoDB

At the same time, after successfully processing a complaint:

AWS Lambda → Amazon SNS → Administrator / Warden

The frontend application is hosted using Amazon S3.

The architecture can be understood through the following steps.

Step 1: Student Submits a Complaint

The process starts when a student submits a complaint through the frontend application.

The complaint can contain information such as:

Student Name Complaint Category Complaint Description Complaint Status Timestamp Complaint ID

The frontend sends the complaint information to the backend through an HTTP request.

The frontend of the application is hosted using Amazon S3.

Step 2: API Gateway Receives the Request

Amazon API Gateway acts as the entry point for the application's API.

When a student submits a complaint, the frontend sends an HTTP request to API Gateway.

The request is then forwarded to the appropriate AWS Lambda function.

In simple terms:

Frontend → API Gateway → Lambda

This allows the frontend application to communicate with the serverless backend without requiring a traditional web server.

Step 3: AWS Lambda Processes the Complaint

The next component is AWS Lambda.

Lambda contains the business logic of the application.

When API Gateway invokes the Lambda function, it processes the incoming complaint.

The Lambda function is responsible for tasks such as:

Validating the request Processing the complaint Generating a complaint ID Storing complaint information Publishing an SNS notification Returning a response to the frontend

The important part is that we do not need to maintain a traditional backend server for this logic.

Step 4: Store the Complaint in DynamoDB

After processing the request, the complaint details are stored in Amazon DynamoDB.

DynamoDB is a fully managed NoSQL database service provided by AWS.

Each complaint is stored as an individual record.

For example:

Field Description Complaint ID Unique identifier for the complaint Student Name Name of the student Category Type of complaint Description Details of the complaint Status Current complaint status Timestamp Time when the complaint was submitted

The architecture used a DynamoDB table named HostelComplaints.

This allows the application to store and retrieve complaint information using a managed NoSQL database.

Step 5: Send Notifications Using Amazon SNS

After the complaint is successfully processed and stored, the administrator needs to be notified.

This is where Amazon SNS (Simple Notification Service) comes into the picture.

The Lambda function publishes a notification to an SNS topic.

The notification flow becomes:

Lambda → Amazon SNS → Administrator / Warden

This demonstrates how notifications can be incorporated into a serverless application without building a separate notification system.

Step 6: Retrieve Complaint Details

The architecture also supports retrieving complaint information.

A GET request can be sent through API Gateway using a complaint ID.

The flow is:

Frontend → API Gateway → Lambda → DynamoDB

Lambda processes the request and retrieves the corresponding complaint information from DynamoDB.

The retrieved information can then be returned to the frontend through API Gateway.

This demonstrates that the application is not limited to only submitting complaints; it can also retrieve complaint information.

Step 7: Return the Response

After Lambda completes the required operation, it returns a response through API Gateway.

The response is then sent back to the frontend application.

The complete workflow can therefore be summarized as:

Student submits complaint

↓

Amazon API Gateway

↓

AWS Lambda

↙　　　　　　　　　↘

Amazon DynamoDB　 Amazon SNS

↓

Administrator / Warden

↓

API Response

↓

Frontend

This complete flow helped me understand how different AWS services communicate with each other in a real application.

AWS Services Used Amazon S3

Amazon S3 was used to host the static frontend application.

Since the frontend consisted of static web files such as HTML, CSS, and JavaScript, S3 provided a suitable storage and hosting option for the frontend.

Amazon API Gateway

Amazon API Gateway exposed the REST APIs required by the application.

It acted as the communication layer between the frontend and the AWS Lambda backend.

It handled requests such as:

POST /complaints

for submitting complaints and

GET /complaints/{id}

for retrieving complaint details.

AWS Lambda

AWS Lambda was responsible for executing the application's backend logic.

It handled:

Input validation Complaint processing Complaint ID generation DynamoDB operations SNS notifications API responses

Lambda allowed us to implement the backend logic without directly managing a traditional backend server.

Amazon DynamoDB

DynamoDB was used as the application's NoSQL database.

Complaint information was stored as individual records, including details such as:

Complaint ID Student information Category Description Status Timestamp

Its managed nature makes it useful for applications that require scalable and low-maintenance data storage.

Amazon SNS

Amazon SNS was responsible for sending notifications after a complaint was successfully processed.

Lambda publishes a message to an SNS topic, which can then deliver the notification to configured subscribers such as an administrator or warden email.

This helped demonstrate how notification and event-driven workflows can be implemented using managed AWS services.

Implementation Journey

The workshop followed a practical, step-by-step approach.

During the implementation, we:

Created an AWS Lambda function. Configured REST APIs using Amazon API Gateway. Created a DynamoDB table. Integrated Lambda with DynamoDB. Created an SNS topic. Connected the notification workflow. Hosted the frontend using Amazon S3. Tested the API using the AWS Console. Validated the complete serverless workflow.

Instead of only reading about AWS services, I was able to see how they communicate with each other in an actual application.

That made the concepts much easier to understand.

Challenges I Faced

When I first looked at the architecture, one question immediately came to mind:

How do all these AWS services communicate with each other?

There were several things I wanted to understand:

How does API Gateway invoke Lambda? How does Lambda interact with DynamoDB? When should SNS be triggered? How does information move between different AWS services? How can an application work without directly managing a traditional backend server?

Building the application practically helped answer these questions.

The hands-on approach made concepts such as serverless architecture, API integration, database interaction, and event-driven workflows much clearer than learning them only theoretically.

What I Learned

This workshop gave me practical exposure to several important AWS concepts.

1. Serverless Architecture I understood how applications can be built without directly managing traditional backend infrastructure.

2. API Development I gained practical exposure to creating APIs using Amazon API Gateway.

3. Cloud Functions I learned how AWS Lambda can execute backend logic based on incoming requests.

4. NoSQL Databases Working with DynamoDB helped me understand how cloud-based NoSQL databases can be used in applications.

5. Notifications SNS demonstrated how applications can trigger notifications through managed cloud services.

6. Event-Driven Thinking The biggest takeaway was understanding how different services can perform individual responsibilities while working together as one application.

What This Experience Taught Me Beyond AWS

One thing I realized during this workshop is that learning cloud computing isn't only about memorizing AWS service names.

It is about understanding when and why to use a particular service.

For example:

Need API access? → API Gateway

Need backend execution? → Lambda

Need NoSQL storage? → DynamoDB

Need notifications? → SNS

Need static frontend hosting? → S3

Understanding these relationships is much more useful than simply knowing the definitions of individual AWS services.

The workshop helped me move from learning individual cloud services to thinking about how complete cloud architectures are designed.

Final Thoughts

Building the Serverless Hostel / College Complaint System was a valuable hands-on experience that helped me understand how AWS managed services can work together to build cloud applications.

The combination of:

Amazon S3 + Amazon API Gateway + AWS Lambda + Amazon DynamoDB + Amazon SNS

showed me how a complete application workflow can be created using managed cloud services.

I am especially grateful to Jaya Ganesh Krishna Moorthy for conducting the hands-on session and sharing valuable industry insights throughout the workshop.

I would also like to thank the AWS Student Builder Group at Easwari Engineering College for organizing this learning experience and giving students an opportunity to explore cloud technologies through practical implementation.

This experience has strengthened my interest in cloud computing and serverless architecture.

I'm looking forward to building more real-world applications, experimenting with additional AWS services, and continuing my learning journey in cloud and AI.

Resources

I originally documented this learning experience through an article on the AWS Builder Center.

Original AWS Article: Building a Serverless Complaint Management System with AWS Lambda, API Gateway, DynamoDB, and SNS

Read my original AWS Builder Center article

About Me

I'm Pranav A, a Computer Science & Engineering (AI & ML) student interested in:

Artificial Intelligence Cloud Computing Software Development AWS Emerging Technologies

I enjoy learning through hands-on projects, workshops, community activities, and experimentation with new technologies.

You can connect with me on:

LinkedIn

AWS Builder Center