ak0047

Posted on Aug 13

Lessons Learned from Building My First Serverless App with AWS SAM: Naming Matters

#aws #cloud #beginners #serverless

Introduction

When I built my first serverless application using AWS SAM,

I made one major mistake:

I jumped in without setting up naming conventions or structural rules.

This post shares the lessons I learned the hard way—so you don't have to make the same mistakes.

If you're...

just getting started with AWS SAM,
struggling with naming or organizing your project,
or want to avoid frustrating deployment errors,

…this post is for you.

What Happens When You Skip the Rules?

In the beginning, my only goal was to get something working.

I started with the Hello World SAM tutorial and kept adding features to the same project structure—without much thought.

That led to chaos. Here's what went wrong.

Issue 1: Confusing and Duplicate Function Names

I was building a weather app that had two main processes:

A scheduled Lambda that fetches weather data from OpenWeather
An API endpoint that serves the data to the frontend

And guess what?

I named both functions based on GetCurrentWeather.

This caused:

Confusion – I couldn't tell which function did what
Deployment errors – Duplicate names for Lambda functions and resources triggered CloudFormation errors

Issue 2: S3 Bucket Headaches

I also kept tweaking the structure of my S3 buckets mid-development.

I didn’t change the actual bucket names, which led to duplicate resource errors
To fix it, I had to manually backup files → delete the bucket → recreate it → re-upload files… multiple times

It was a mess.

What I Learned: Set the Rules Early

At first, I thought:

"I’ll just fix the names and structure later."

Big mistake.

Changing things midway cost me a lot of time and energy.

The key takeaway?

Don't avoid rules in the name of flexibility.

Instead, define flexible and scalable rules from the start.

This will help you:

smoothly handle specification changes
avoid deployment issues
make the app easier to share or scale later on

My Naming & Structure Rules Now

To prevent the same issues in future projects, I now follow these conventions.

Directory Structure

I organize my Lambda functions under lambdas/, categorized by trigger type:

/lambdas/
├── scheduled/          # EventBridge or cron-based triggers
│   └── getCurrentWeather/
│       └── app.py
├── api/                # Triggered via API Gateway
│   └── getCurrentWeather/
│       └── app.py

Naming Convention

Resource name: <Project><Feature><TriggerType><ResourceType>

Function name (FunctionName property): <FeatureName>Api or similar

Resources:
  WeatherAppGetCurrentWeatherApiFunction:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: getCurrentWeatherApi

  WeatherAppAnalyzeWeatherWeeklyScheduledFunction:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: analyzeWeatherWeekly

I also append environment suffixes like ${Environment} to function names using !Sub for environment separation—but I’ll cover that in a future post.

Summary

Naming and structural rules may seem optional at first,
but they’re essential for avoiding problems down the line.

Especially in serverless apps using AWS SAM, duplicated resource names can break your deployment.

Even for small projects, defining just enough rules upfront makes development smoother and more maintainable.

Got any best practices or naming rules of your own?
I’d love to hear them!

DEV Community