I wanted to understand how a real cloud backend is designed when we care about scalability, security, monitoring, cost, and maintainability.

So I built a Serverless Order Management System on AWS using:

• Amazon API Gateway

• AWS Lambda

• Amazon DynamoDB

• Amazon Cognito

• IAM

• Amazon CloudWatch

• Amazon SNS

• API Gateway throttling

• Postman for API testing

GitHub Repository: Serverless Order Management System
Portfolio: kamleshcloud.com
LinkedIn: Kamlesh Dubale

What I Built

This project is a serverless backend for managing orders.

It supports:

• Creating an order

• Getting all orders

• Getting a specific order by ID

• Deleting an order

• Protecting API routes using Cognito authentication

• Monitoring Lambda errors with CloudWatch

• Sending alerts using SNS

• Restricting Lambda permissions using least-privilege IAM

• Protecting the API from excessive traffic using throttling

The final architecture is fully serverless, meaning there are no EC2 instances or servers to manage.

High-Level Architecture

The request flow looks like this:

User / Postman
    ↓
Amazon Cognito
    ↓
Amazon API Gateway
    ↓
AWS Lambda
    ↓
Amazon DynamoDB
    ↓
CloudWatch Logs / Alarms
    ↓
SNS Email Alerts

API Gateway acts as the public entry point.

Lambda handles the backend logic.

DynamoDB stores the order records.

Cognito adds authentication.

CloudWatch and SNS provide monitoring and alerting.

IAM controls what Lambda is allowed to access.

API throttling protects the system from excessive traffic.

Why I Chose Serverless

Traditional backend systems usually require servers.

That means someone has to think about:

• Operating system updates

• Server patching

• Scaling servers

• Load balancing

• Capacity planning

• Availability

• Runtime maintenance

With serverless, AWS handles most of that.

Lambda only runs when a request comes in. DynamoDB scales automatically. API Gateway gives a managed HTTPS endpoint. Cognito manages authentication. CloudWatch collects logs and metrics.

This makes serverless a very good fit for event-driven APIs, small backend services, prototypes, internal tools, and scalable cloud-native applications.

API Gateway Routes

I created four API routes:

This route structure follows a simple REST-style API design.

For example:

POST /orders

means create an order.

GET /orders

means list all orders.

GET /orders/{id}

means retrieve one specific order.

DELETE /orders/{id}

means delete one specific order.

Lambda Functions

Instead of using one large Lambda function for everything, I created separate Lambda functions:

This follows the single responsibility principle.

Each function has one clear job.

This makes the system easier to debug, easier to secure, and easier to explain.

DynamoDB Table Design

The DynamoDB table is called:

orders

The partition key is:

OrderId

Each order item contains:

{
  "OrderId": "994dd3bc-a43a-4342-b07b-3f5829e3c046",
  "customerName": "Kamlesh",
  "product": "MacBook Pro",
  "quantity": 1
}

I used OrderId as the partition key because every order needs a unique identifier.

This allows DynamoDB to retrieve a specific order efficiently using GetItem.

Create Order Flow

When a client sends this request:

POST /orders

with this JSON body:

{
  "customerName": "Kamlesh",
  "product": "MacBook Pro",
  "quantity": 1
}

the flow is:

Postman
    ↓
API Gateway
    ↓
CreateOrderFunction
    ↓
DynamoDB PutItem
    ↓
Order saved

The Lambda function generates a unique OrderId using Python’s uuid module.

Then it stores the item in DynamoDB using boto3.

Input Validation

A backend API should not blindly accept bad input.

So I added validation for required fields:

customerName
product
quantity

If the request body is missing required fields, the API returns a proper error response instead of crashing.

Example bad request:

{
  "customerName": "Kamlesh"
}

Response:

{
  "message": "Missing required fields",
  "missingFields": ["product", "quantity"],
  "requiredFields": ["customerName", "product", "quantity"]
}

This is important because production APIs should give clear and useful error messages.

Get All Orders

The GET /orders endpoint lists all orders from DynamoDB.

The response looked like this:

[
  {
    "product": "MacBook Pro",
    "quantity": 1,
    "customerName": "Kamlesh",
    "OrderId": "994dd3bc-a43a-4342-b07b-3f5829e3c046"
  }
]

For this project, I used DynamoDB Scan.

In a real high-scale production system, I would avoid unnecessary scans and design access patterns carefully using partition keys, sort keys, and indexes.

Get Order by ID

The GET /orders/{id} endpoint uses a path parameter.

Example:

GET /orders/994dd3bc-a43a-4342-b07b-3f5829e3c046

API Gateway passes the ID to Lambda inside:

event["pathParameters"]["id"]

Lambda then uses DynamoDB GetItem to retrieve the order.

This helped me understand how API Gateway converts HTTP requests into Lambda event objects.

Delete Order

The DELETE /orders/{id} endpoint deletes an order from DynamoDB.

The flow is:

Client
    ↓
API Gateway
    ↓
DeleteOrderFunction
    ↓
DynamoDB DeleteItem
    ↓
Deletion confirmation

This completed the main CRUD functionality of the project.

Cognito Authentication

After the CRUD APIs were working, I added Amazon Cognito.

The goal was to protect sensitive API routes.

Without authentication, anyone who knows the API URL can send requests.

That is not acceptable for a real backend.

So I created:

• Cognito User Pool

• App Client

• Cognito Hosted Login Page

• JWT Authorizer in API Gateway

When an unauthenticated request is sent to the protected POST /orders route, the API returns:

{
  "message": "Unauthorized"
}

This proves that API Gateway is rejecting anonymous requests before they reach Lambda.

That is a strong security boundary.

IAM Least Privilege

During development, I temporarily used broader DynamoDB permissions to move quickly.

But after the project was working, I replaced full DynamoDB access with a custom least-privilege policy.

The Lambda execution role was allowed only these actions:

dynamodb:PutItem
dynamodb:GetItem
dynamodb:DeleteItem
dynamodb:Scan

and only on the orders table.

This is very important.

A Lambda function that only needs to access one table should not have permission to modify every DynamoDB table in the account.

This follows the principle of least privilege.

CloudWatch Monitoring

A system is not production-ready if we cannot observe it.

So I used CloudWatch Logs to inspect Lambda executions and debug issues.

I also created a CloudWatch alarm for Lambda errors.

Alarm name:

CreateOrderFunction-Errors-Alarm

The alarm checks the Lambda Errors metric.

If the function records one or more errors within a one-minute period, the alarm can trigger an action.

SNS Alerting

To make the monitoring useful, I connected the CloudWatch alarm to Amazon SNS.

The alerting flow is:

Lambda error
    ↓
CloudWatch metric
    ↓
CloudWatch alarm
    ↓
SNS topic
    ↓
Email notification

This is closer to how real DevOps teams monitor production systems.

It is not enough to only log errors. Someone needs to be notified when something breaks.

API Throttling

I also configured API Gateway throttling.

Settings used:

Burst limit: 50
Rate limit: 100

Throttling protects the API from:

• accidental request loops

• basic abuse

• sudden spikes

• uncontrolled client traffic

This is an important production control.

Even if the backend is serverless and scalable, we should still control how much traffic can hit the API.

Problems I Faced and Fixed

This project was not smooth from start to finish. I ran into multiple real-world issues.

1. DynamoDB table name mismatch

My code used:

Orders

but the actual table name was:

orders

DynamoDB table names are case-sensitive.

This caused a ResourceNotFoundException.

1. Primary key mismatch

The DynamoDB partition key was:

OrderId

but my first Lambda code used:

orderId

That caused a validation error because DynamoDB expected the exact key name.

1. Decimal serialization issue

DynamoDB returns numbers as Decimal objects in Python.

When returning an item through API Gateway, Python failed with:

Object of type Decimal is not JSON serializable

I fixed this by adding a custom serializer to convert Decimal values before returning the JSON response.

1. Cognito Unauthorized response

After attaching the Cognito authorizer, my POST /orders request started returning:

{ "message": "Unauthorized" }

At first, this looked like an error.

But it was actually the correct behavior because the route was protected and no JWT token was being sent.

That helped me understand authentication at the API Gateway layer.

Why This Project Matters

This project helped me move beyond simply deploying a Lambda function.

I learned how multiple AWS services work together:

Authentication
    ↓
API routing
    ↓
Business logic
    ↓
Database
    ↓
Monitoring
    ↓
Alerting
    ↓
Security controls

This is the difference between building a demo and designing a real cloud backend.

Final Repository Structure

serverless-order-management-system/
│
├── README.md
├── architecture-diagram.png
│
├── lambda-functions/
│   ├── create_order.py
│   ├── get_order.py
│   ├── list_orders.py
│   └── delete_order.py
│
├── screenshots/
│   ├── API Gateway Routes.png
│   ├── API Throttling.png
│   ├── Architecture diagram.png
│   ├── Cloudwatch Alarm.png
│   ├── Cognito Authorizer.png
│   ├── DynamoDB- Explore Items.png
│   ├── DynamoDB order Items overview.png
│   ├── IAM least privilage role.png
│   ├── Lambda Functions.png
│   ├── POSTMAN - Get all orders.png
│   └── POSTMAN - Unauthorized.png
│
└── docs/
    └── blog-draft.md

What I Would Improve Next

If I continue improving this project, I would add:

• Terraform for Infrastructure as Code

• GitHub Actions CI/CD pipeline

• Separate dev and prod environments

• Custom domain for API Gateway

• AWS WAF

• Full JWT token testing in Postman

• More detailed CloudWatch dashboards

• Unit tests for Lambda functions

• Better DynamoDB access patterns for larger workloads

Final Thoughts

This project gave me practical experience with building a secure, monitored, serverless backend on AWS.

The biggest learning was not just writing Lambda code.

The biggest learning was understanding how cloud components fit together:

• API Gateway exposes the backend

• Cognito protects the API

• Lambda runs the business logic

• DynamoDB stores the data

• IAM controls permissions

• CloudWatch observes the system

• SNS sends alerts

• Throttling protects the API

This is the kind of architecture thinking I want to keep building as I continue growing as a Cloud and DevOps Engineer.

GitHub Repository: Serverless Order Management System
Portfolio: kamleshcloud.com
LinkedIn: Kamlesh Dubale

Most production applications are not hosted on a single server directly exposed to the internet. Instead, they follow layered architectures focused on:

• security

• scalability

• controlled communication

• network isolation

• traffic management

To better understand these concepts, I built a production-style three-tier architecture on AWS using:

• Amazon VPC

• Public and Private Subnets

• EC2

• PostgreSQL RDS

• Application Load Balancer (ALB)

• Security Groups

• Target Groups and Health Checks

This project helped me understand not only how AWS services work individually, but more importantly how they communicate with each other inside a real cloud environment.

What is a Three-Tier Architecture?

A three-tier architecture separates infrastructure into three logical layers:

Presentation Layer → Application Layer → Database Layer

In this project:

• The Application Load Balancer (ALB) acted as the presentation layer

• The EC2 instance acted as the application layer

• The PostgreSQL RDS database acted as the database layer

This architecture pattern is commonly used because it improves:

• scalability

• security

• maintainability

• reliability

Final Architecture

Internet
    ↓
Application Load Balancer
    ↓
EC2 Instance
    ↓
PostgreSQL RDS

The overall request flow works like this:

1. A user opens the application URL

2. The request reaches the Application Load Balancer

3. The Load Balancer forwards traffic to the Target Group

4. The Target Group routes traffic to a healthy EC2 instance

5. The EC2 instance processes the request

6. The application can communicate with PostgreSQL RDS if required

7. The response is returned back to the user

Designing the Network Architecture

The first step was creating a custom VPC to isolate the infrastructure inside a private AWS network.

Inside the VPC, I created multiple subnets to separate internet-facing resources from protected backend services.

Public Subnets

The public subnet hosted:

• Application Load Balancer

• EC2 Instance

These subnets had internet access configured using:

0.0.0.0/0 → Internet Gateway

Private Subnets

The private subnet was used for PostgreSQL RDS.

The idea behind this design was simple:

• Users should access the application

• Users should never directly access the database

This separation is one of the most important concepts in cloud architecture.

Configuring Security Groups

One of the biggest learning experiences from this project was understanding how communication between services is controlled using Security Groups.

I configured three different Security Groups:

ALB Security Group

Allowed HTTP traffic from the internet.

HTTP 80 → 0.0.0.0/0

EC2 Security Group

Allowed:

• SSH access only from my public IP

• HTTP traffic only from the ALB Security Group

SSH 22 → My IP
HTTP 80 → ALB Security Group

RDS Security Group

Allowed PostgreSQL access only from the EC2 Security Group.

PostgreSQL 5432 → EC2 Security Group

This created a controlled communication chain:

Internet → ALB → EC2 → RDS

Understanding this traffic flow was one of the most valuable parts of the project.

Application Load Balancer and Target Groups

An internet-facing Application Load Balancer (ALB) was created to distribute incoming traffic.

Instead of exposing the EC2 instance directly to users, the ALB acted as the public entry point.

The ALB forwarded traffic to a Target Group containing the EC2 instance.

One concept that became much clearer during this project was the purpose of health checks.

The Target Group continuously checks whether the EC2 instance is healthy and capable of handling traffic.

If the server becomes unhealthy, traffic stops being forwarded automatically.

This is an extremely important reliability feature used in production systems.

Challenges Faced During Implementation

This project involved a significant amount of troubleshooting and debugging.

Some of the biggest challenges included:

• unhealthy target groups

• Security Group configuration mistakes

• region mismatch confusion

• identifying public vs private subnets

• ALB communication issues

One major issue occurred when the Target Group continuously showed the EC2 instance as unhealthy.

After debugging the networking flow carefully, I discovered that the EC2 Security Group was not correctly allowing HTTP traffic from the ALB Security Group.

Fixing this helped me better understand how traffic actually moves through AWS infrastructure.

Another important learning was understanding that subnets become public or private based on Route Table configuration rather than subnet names themselves.

Key Learnings

This project helped me gain hands-on understanding of:

• AWS networking

• VPC design

• Security Groups

• Load Balancers

• Target Groups

• Health Checks

• Public vs Private networking

• Cloud troubleshooting

One of the biggest takeaways from this project was realising that cloud engineering is heavily focused on:

• networking

• communication flow

• security

• debugging

rather than simply deploying services.

Conclusion

This project helped bridge the gap between theoretical AWS knowledge and practical cloud architecture implementation.

Rather than simply launching services, the project focused heavily on understanding:

• secure communication between services

• traffic flow

• network isolation

• cloud troubleshooting

• production-style architecture design

The debugging process throughout the project was especially valuable because it provided insight into how real infrastructure problems are identified and resolved in cloud environments.

This project also gave me much more confidence in understanding how different AWS services work together as part of a complete system.

Connect With Me

• GitHub: https://github.com/KamleshDevopsAndCloud

• LinkedIn: https://linkedin.com/in/kamlesh-dubale

For a long time, I kept watching tutorials on cloud and DevOps.

I understood bits and pieces — S3, CloudFront, DNS — but nothing really clicked.

So I decided to stop watching and actually build something.

This project started as a simple goal: "I just want to put a website on the internet using AWS."

What I didn’t expect was how much this one project would teach me about how the internet actually works behind the scenes.

By the end, I had my own live website:

👉 https://kamleshcloud.com

And more importantly, I finally understood what happens when someone opens a website.

What is a static website?

Before starting this project, I always thought a website needs a server running in the background.

But that’s not always true.

A static website is simply a collection of files like:

• index.html

• style.css

• script.js

That’s it.

These files are already written and stored somewhere. When a user opens the website, the browser just downloads these files and displays the page.

There is no backend logic or database involved in this setup.

That was one of the first things that surprised me.

It made me realise that for many use cases like portfolios, landing pages, or simple blogs, you don’t actually need a full server setup.

You just need a place to store your files and a way to deliver them to users.

Final Architecture

Once everything was set up, my website followed this flow:

User → Route 53 → WAF → CloudFront → S3

At first, this looked very confusing to me.

But when I broke it down step by step, it started making sense:

• S3 is where my website files are stored

• CloudFront is responsible for delivering those files

• Route 53 connects my domain name to the website

• WAF acts like a security layer in front

• ACM helps enable HTTPS

Instead of thinking of these as separate services, I started seeing them as parts of one system working together to serve a simple website.

Step-by-Step: What I Actually Did

1. Built the website locally

I started by creating a simple website on my local machine using VS Code.

At this stage, the website only worked on my laptop.

This made me realise something very basic but important:

A website is just a collection of files until it is hosted somewhere on the internet.

Until those files are uploaded to a platform like AWS, no one else can access them.

That was my starting point.

2. Uploaded the files to S3

The next step was to move my website from my laptop to the cloud.

For this, I used Amazon S3.

I created a bucket and uploaded my website files:

• index.html

• style.css

• script.js

At this point, my files were finally stored in AWS.

But something interesting happened.

Even though the files were there, the website still wasn’t properly “live” yet.

That’s when I realised:

Uploading files is not the same as hosting a website.

You still need to tell AWS how to serve those files as a website.

3. Enabled static website hosting

This step is where things started to come together.

Inside S3, I enabled static website hosting and set:

👉 index.html as the default page

At first, I didn’t fully understand why this was needed.

But then it made sense.

When someone opens a website, they don’t type something like:

/index.html

They just open the main domain.

So AWS needs to know:

“What file should I show by default?”

That file is called the index document.

Once I enabled this, my website started working through the S3 endpoint.

This was the first time I saw my website actually live on the internet.

4. Added CloudFront (this confused me at first)

After getting the S3 version working, the next step was to add CloudFront.

This part was confusing in the beginning.

I kept thinking:

“If S3 is already hosting my website, why do I need CloudFront?”

But later, I understood it in a simple way:

• S3 = storage

• CloudFront = delivery

Instead of users directly accessing S3, they now access CloudFront.

So the flow becomes:

User → CloudFront → S3

CloudFront acts as the front layer that handles requests and delivers the website.

This is how most real-world setups work.

That’s when I started understanding that cloud architecture is about separating responsibilities.

5. Understanding the root object

This was one of the terms that confused me a lot at first.

In CloudFront, there is something called the default root object.

I set it to:

index.html

But what does that actually mean?

It simply means:

“When someone opens the root of the website, which file should be shown?”

Since users don’t type:

/index.html

we need to tell CloudFront what to load by default.

That’s exactly what the root object does.

Once I understood this, it stopped feeling like a complex term.

6. Bought a custom domain

After CloudFront was working, I wanted to make the website feel more real.

So I bought my own domain:

kamleshcloud.com

using Route 53.

This was a big step for me.

Instead of using a long AWS-generated URL, I now had something that actually looked like a real website.

I also realised that this domain is not just for this project.

I can use it in the future for:

• my portfolio

• my blog

• and even potential business ideas

That made this project feel much more meaningful.

7. Setting up HTTPS (this tested my patience)

After setting up the domain, the next step was to make the website secure using HTTPS.

For that, I used AWS Certificate Manager (ACM).

I requested a certificate for my domain, and at first everything looked fine.

But then the status stayed stuck at:

👉 “Pending validation”

This was frustrating because I wasn’t sure what was missing.

After digging a bit, I understood that AWS needed proof that I actually owned the domain.

This is done using DNS validation.

Once I created the required records in Route 53, the certificate finally changed to:

👉 “Issued”

That moment felt really satisfying because now my website was secure and could be accessed using HTTPS.

8. Connecting the domain (this is where it finally worked)

Even after setting up the certificate, my domain still didn’t work at first.

When I tried opening it, I got:

👉 DNS_PROBE_FINISHED_NXDOMAIN

At that point, I realised something was still missing.

The domain was not properly connected to CloudFront yet.

To fix this, I created an alias record in Route 53 and pointed it to my CloudFront distribution.

After doing that, I had to wait a few minutes for DNS to propagate.

And then…

🔥 The website finally went LIVE

👉 https://kamleshcloud.com

That was honestly one of the best moments of this project.

9. Adding WAF (security layer)

The final step was adding a basic security layer using AWS WAF.

You can think of WAF like a security guard in front of your website.

Before any request reaches CloudFront, WAF checks it first.

So now the flow becomes:

User → Route 53 → WAF → CloudFront → S3

Even though this is a basic setup, it made the architecture feel more complete and closer to real-world systems.

What I Learned

This project taught me much more than I expected.

Some of the biggest lessons were:

• A website is just a collection of files

• S3 stores the files, CloudFront delivers them

• DNS is what connects everything

• HTTPS requires validation, not just a button click

• Cloud architecture is really about request flow

Most importantly, I realised that things only start making sense when you actually build something.

Problems I Faced

This project was not smooth, and that’s what made it valuable.

Some of the issues I ran into:

• Certificate stuck on “Pending validation”

• Domain not working (NXDOMAIN error)

• Confusion around CloudFront concepts

• Understanding root object and behavior

But solving these problems is what made everything click.

Final Result

Here is my live website:

👉 https://kamleshcloud.com

And the GitHub repository:

👉 https://github.com/KamleshDevopsAndCloud

Final Thought

If you are starting your cloud journey, my advice is simple:

Don’t wait until you feel ready.

Just build something.

Break things. Fix them. Try again.

That’s when everything starts making sense.