DEV Community

Cover image for I Spent 6 Hours Debugging AWS Before Realising the Bug Was a Capital Letter
Edith Asante
Edith Asante

Posted on

I Spent 6 Hours Debugging AWS Before Realising the Bug Was a Capital Letter

#api #aws #beginners #serverless

I stared at my screen for 6 hours. The API kept returning 404. I checked the Lambda code line by line. I tested the DynamoDB table. I redeployed the API three times. Everything looked right.Then I noticed it. The resource was named /Students — capital S. My frontend was calling /students — lowercase. That was it. Six hours. One capital letter.

This is the story of building my first serverless app on AWS — a Student Record Management System — as part of my AWS Cloud Practitioner journey. I'll walk through the full architecture, how I built it, and every AWS configuration bug I hit along the way. Spoiler: 5 out of 8 bugs had nothing to do with my code.

-

What I Built

A Student Record Management System that allows you to:

  • Create new student records
  • View all students in a table
  • Search by Student ID
  • Edit student information
  • Delete students

With a clean UI showing live stats — total students, average GPA, and number of unique majors.

Live site: http://student-records-edith-321.s3-website-us-east-1.amazonaws.com

GitHub: https://github.com/asanteedith/student-record-system

Architecture

The entire application is serverless:

User Browser (S3 Static Website)
        ↓
API Gateway (REST API)
        ↓
Lambda Functions (Python 3.12)
        ↓
DynamoDB (StudentRecords table)
Enter fullscreen mode Exit fullscreen mode

No EC2, no servers to manage, no infrastructure to maintain. Everything scales automatically and stays within the AWS Free Tier.

AWS Services Used

Service Purpose
DynamoDB NoSQL database to store student records
Lambda 5 serverless functions for CRUD operations
API Gateway REST API connecting frontend to backend
S3 Hosts the static frontend website
IAM Permissions and security roles

Project Structure 

student-record-system/
├── README.md
├── BUGS.md
├── frontend/
│   ├── index.html
│   ├── styles.css
│   └── app.js
└── lambda/
    ├── GetAllStudents/
    │   └── lambda_function.py
    ├── GetStudent/
    │   └── lambda_function.py
    ├── CreateStudent/
    │   └── lambda_function.py
    ├── UpdateStudent/
    │   └── lambda_function.py
    └── DeleteStudent/
        └── lambda_function.py
Enter fullscreen mode Exit fullscreen mode

Phase 1: DynamoDB Setup

DynamoDB is AWS's managed NoSQL database. I created a table called StudentRecords with studentId as the partition key (think primary key).

Key settings:

  • On-demand capacity — you only pay for what you use, perfect for a project like this
  • Partition key: studentId (String) — every student needs a unique ID

Each record stores: studentId, name, email, major, gpa

One thing I learned early — DynamoDB stores numbers as Python's Decimal type, not a regular float. This caused a JSON serialization bug later (more on that below).

Phase 2: Lambda Functions

I created 5 Lambda functions in Python 3.12, one for each CRUD operation:

Function Method Purpose
GetAllStudents GET Scan entire table
GetStudent GET Get one student by ID
CreateStudent POST Add new student
UpdateStudent PUT Update student fields
DeleteStudent DELETE Remove student

Here's the GetAllStudents function — it scans the entire DynamoDB table and handles pagination for large datasets:

import json
import boto3
from decimal import Decimal

dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('StudentRecords')

class DecimalEncoder(json.JSONEncoder):
    def default(self, obj):
        if isinstance(obj, Decimal):
            return float(obj)
        return super(DecimalEncoder, self).default(obj)

def lambda_handler(event, context):
    try:
        response = table.scan()
        students = response['Items']
        while 'LastEvaluatedKey' in response:
            response = table.scan(ExclusiveStartKey=response['LastEvaluatedKey'])
            students.extend(response['Items'])
        return {
            'statusCode': 200,
            'headers': {'Access-Control-Allow-Origin': '*'},
            'body': json.dumps(students, cls=DecimalEncoder)
        }
    except Exception as e:
        return {
            'statusCode': 500,
            'headers': {'Access-Control-Allow-Origin': '*'},
            'body': json.dumps({'error': str(e)})
        }
Enter fullscreen mode Exit fullscreen mode

Important: After creating each function, I had to manually attach AmazonDynamoDBFullAccess to the Lambda execution role in IAM. Lambda has no DynamoDB access by default — this tripped me up more than once.

Phase 3: API Gateway

API Gateway is what connects the frontend to the Lambda functions. I created a REST API with this structure:

/students
  GET     → GetAllStudents
  POST    → CreateStudent
  /{studentid}
    GET    → GetStudent
    PUT    → UpdateStudent
    DELETE → DeleteStudent
Enter fullscreen mode Exit fullscreen mode

Key settings for each method:

  • Integration type: Lambda Function
  • Lambda Proxy integration: ✅ ON (passes the full request to Lambda)

CORS must be enabled on both resources — without it the browser blocks every API call.

Phase 4: Frontend

The frontend is pure HTML, CSS and vanilla JavaScript — no React, no frameworks. It's hosted as a static website on S3.

Features:

  • Stats bar showing live total students, average GPA and unique majors
  • Color-coded avatar initials per student
  • Major badges with different colors per field
  • Actions dropdown (View / Edit / Delete) per row
  • Smooth animated modals for all operations
  • Toast notifications for success and error feedback
  • Fully responsive on mobile

The entire API connection is in app.js — one file handles all 5 CRUD operations by calling the API Gateway endpoints.

The Bugs — This Is Where I Actually Learned AWS

This section is the most valuable part. Every one of these bugs taught me something important about how AWS services work together.

Bug 1 — Missing GET /students Endpoint

Symptom: Table was always empty on page load

Cause: I set up routes for individual student operations but completely forgot to create a GET /students endpoint to fetch all students. The frontend called it on load and got a 404.

Fix: Created a new GetAllStudents Lambda function and added GET /students → GetAllStudents in API Gateway.

Lesson: Always map out ALL your API routes before you start building.

Bug 2 — /Students vs /students (Case Sensitivity)

Symptom: View, Edit and Delete all failed silently

Cause: I accidentally created the resource as /Students (capital S) instead of /students. AWS API Gateway is case-sensitive — these are completely different paths.

Fix: Deleted /Students, recreated as /{studentid} under /students (lowercase), re-added all methods.

Lesson: API Gateway resource paths are case-sensitive. Always double-check before adding methods.

Bug 3 — Path Parameter Case Mismatch

Symptom: Error: 'studentId' on every individual student operation

Cause: My Lambda functions read event['pathParameters']['studentId'] (camelCase) but the API Gateway resource was named /{studentid} (all lowercase). AWS passes the exact parameter name — no automatic case conversion.

Fix: Updated all 3 Lambda functions to use event['pathParameters']['studentid'].

Lesson: The path parameter name in your Lambda code must match exactly what's in the API Gateway resource path.

Bug 4 — CORS Not Re-enabled After Changes

Symptom: CORS policy blocked errors in browser console

Cause: Every time I modified a resource or added a method in API Gateway, CORS got reset. I forgot to re-enable it after making fixes.

Fix: After any resource change — Enable CORS on both resources → replace existing → redeploy.

Lesson: CORS must be re-enabled every time you modify API Gateway resources.

Bug 5 — API Gateway Changes Not Going Live

Symptom: Fixed things in API Gateway but nothing changed on the live site

Cause: API Gateway uses a staging system. Changes are saved as drafts until you explicitly deploy them to a stage.

Fix: Always: API Actions → Deploy API → Stage: prod → Deploy after every change.

Lesson: Unlike Lambda (where Deploy is instant), API Gateway changes are never live until deployed to a stage.

Bug 6 — Lambda Missing DynamoDB Permissions

Symptom: User is not authorized to perform: dynamodb:PutItem

Cause: Lambda functions are created with a minimal execution role that only has CloudWatch logging permissions. They have no DynamoDB access by default.

Fix: For each Lambda function: Configuration → Permissions → click role → Attach AmazonDynamoDBFullAccess.

Lesson: In AWS, no service has access to another service by default. IAM permissions must always be explicitly granted.

Bug 7 — DynamoDB Decimal Serialization Error

Symptom: Lambda returned 500 when reading student data

Cause: DynamoDB stores numbers as Python's Decimal type. Python's json.dumps() can't serialize Decimal objects.

Fix: Added a custom DecimalEncoder class to convert Decimal to float during JSON serialization.

Lesson: Always handle the Decimal ↔ float conversion when working with DynamoDB numbers in Python.

Bug 8 — S3 Serving Old Cached Files

Symptom: Updated files uploaded to S3 but site still showed old version

Cause: The browser cached the old files aggressively.

Fix: Hard refresh with Ctrl + Shift + R, or test in an incognito window.

Lesson: Always hard refresh or use incognito after deploying new files to S3.

Bug Summary

# Bug Service Severity
1 Missing GET /students endpoint API Gateway + Lambda 🔴 Critical
2 /Students vs /students case mismatch API Gateway 🔴 Critical
3 Path parameter case mismatch Lambda + API Gateway 🔴 Critical
4 CORS not re-enabled after changes API Gateway 🔴 Critical
5 Changes not live without redeployment API Gateway 🟠 Medium
6 Lambda missing DynamoDB permissions Lambda + IAM 🔴 Critical
7 DynamoDB Decimal serialization error Lambda + DynamoDB 🟠 Medium
8 S3 browser caching old files S3 🟡 Minor

5 out of 8 bugs were Critical — and every single one was an AWS configuration issue, not an application code bug. That's the biggest takeaway from this project.

💡 Key Takeaways

1. IAM permissions are everything
No AWS service can talk to another without explicit IAM permissions. Check permissions first when something isn't working.

2. API Gateway requires redeployment
Every change to API Gateway — methods, CORS, integrations — must be deployed to a stage before it goes live.

3. Case sensitivity matters in AWS
Resource paths, parameter names, table names — AWS is case-sensitive everywhere. Be consistent and always use lowercase.

4. CORS needs to be re-enabled after every change
Don't just enable it once and forget about it. Any resource modification resets it.

5. DynamoDB numbers are Decimal, not float
Always use a DecimalEncoder when returning DynamoDB data as JSON.

Resources

If you're working through your AWS Cloud Practitioner certification and want a hands-on project that touches DynamoDB, Lambda, API Gateway, S3 and IAM all at once — this is a great one to build. The bugs you'll hit will teach you more than any documentation.

Feel free to fork the repo, ask questions in the comments, or connect with me!

Tags: #aws #serverless #python #javascript #cloudpractitioner #beginners

Top comments (0)