DEV Community: Shashank Pandey

Designing a Cost-Effective Serverless Certificate Generation System on AWS

Shashank Pandey — Mon, 13 Jul 2026 10:56:56 +0000

How I used AWS Lambda and Amazon S3 to build a scalable certificate platform that minimizes storage costs while improving security.

Introduction

In my previous article, I shared why I decided to build a serverless certificate generation system for our student community. As our events grew, manually generating and distributing certificates became increasingly difficult because:

Gmail SMTP had daily sending limits and required one of us to keep a laptop running until all 200-300 certificate emails were delivered.
Google Apps Script required storing every generated certificate in Google Drive, leading to unnecessary long-term storage.
Traditional mailing APIs still required certificate generation to run on our own infrastructure, making the process compute-intensive and consuming our Cloudflare Workers quota.
Bulk email delivery through these approaches also increased the risk of emails being delayed or marked as spam.

These limitations made us rethink the entire workflow. Instead of trying to optimize the existing solution, we designed a serverless architecture on AWS that could generate certificates on demand, store them securely, and significantly reduce operational overhead.

The Challenge

Every event concludes with hundreds of participants expecting their certificates within minutes.

While generating a certificate isn't particularly difficult, doing it reliably for hundreds of users introduces several operational challenges.

The system needed to:

Scale automatically during peak demand.
Deliver certificates quickly.
Avoid long-running servers.
Reduce long-term storage.
Keep certificate files secure.
Be inexpensive enough for a student-led community.

Rather than permanently storing every generated PDF, I wanted a smarter approach that stored only what was necessary.

Architecture Overview

The platform uses a simple serverless architecture built entirely on managed AWS services.

Figure 1. High-level architecture of the serverless certificate generation workflow. AWS Lambda checks whether a certificate already exists in Amazon S3. If available, it generates a pre-signed URL for secure access. Otherwise, the certificate is regenerated, uploaded to Amazon S3, and served to the user. An Amazon S3 Lifecycle Rule automatically removes regenerated certificates after the configured retention period.

The idea is straightforward:

If a certificate already exists, serve it immediately.
If it doesn't, regenerate it from stored metadata.
Store it temporarily.
Automatically remove it later using Amazon S3 Lifecycle Rules.

Why AWS Lambda?

Certificate generation is not a continuous workload.

Immediately after an event, hundreds of participants may request certificates simultaneously, while on other days there may be no requests at all.

AWS Lambda was the ideal choice because it:

Eliminates server management.
Automatically scales with demand.
Charges only when code runs.
Integrates easily with other AWS services.

This means we never have to keep a server running just to generate certificates.

Why Amazon S3?

Certificates are simply generated PDF files.

Amazon S3 provides:

Highly durable object storage.
Excellent scalability.
Low storage costs.
Fine-grained access control.

Instead of exposing the bucket publicly, users receive temporary pre-signed URLs that allow secure downloads.

On-Demand Certificate Generation

One of the most important design decisions was treating certificates as derived artifacts instead of permanent data.

The participant information, event details, and certificate template remain the source of truth.

Whenever someone requests a certificate:

AWS Lambda checks whether the PDF already exists in Amazon S3.
If it exists, the system immediately returns a pre-signed URL.
If it doesn't exist, Lambda regenerates the certificate using the stored metadata.
The newly generated PDF is uploaded to Amazon S3.
A pre-signed download URL is returned to the user.

Because certificates can always be recreated, there is no need to keep every generated PDF forever.

Automatic Cleanup with Amazon S3 Lifecycle Rules

Keeping generated certificates forever didn't make much sense.

Most participants download their certificate only once or twice. Storing every generated file indefinitely would gradually increase storage usage while retaining documents that might never be accessed again.

To solve this, regenerated certificates are uploaded to Amazon S3 temporarily.

An Amazon S3 Lifecycle Rule automatically removes these files after a short retention period.

This provides several benefits:

Reduces unnecessary storage.
Keeps the bucket clean.
Limits the lifetime of generated certificate files.
Ensures certificates are recreated only when needed.

Since the system always retains the certificate metadata, deleting the generated PDF never results in data loss.

Security Considerations

Security was another important factor in the architecture.

The platform follows a few simple principles:

Amazon S3 buckets remain private.
Users never receive direct bucket access.
Downloads are provided using temporary pre-signed URLs.
IAM roles follow the principle of least privilege.
Generated certificate files are automatically removed after a limited period.

By reducing how long generated PDFs remain in storage, the platform also minimizes unnecessary exposure of sensitive documents.

Cost Optimization

As a student community, every cloud resource matters.

Several architectural decisions help keep operational costs low:

AWS Lambda runs only when certificates are requested.
Amazon S3 stores objects efficiently.
Lifecycle Rules automatically clean up generated files.
Certificates are regenerated only when required instead of occupying storage forever.

Rather than paying to retain thousands of PDFs indefinitely, the platform stores only what is necessary and recreates generated artifacts on demand.

Lessons Learned

Building this system reinforced several architectural principles.

First, not every generated file needs to be stored permanently. If it can be recreated reliably from source data, temporary storage is often the better choice.

Second, managed AWS services significantly reduce operational complexity. Instead of maintaining servers or writing cleanup scripts, services such as AWS Lambda and Amazon S3 handle much of the infrastructure automatically.

Finally, simple architectures are often the easiest to maintain. By focusing only on the services required for the workflow, the platform remains easy to understand, cost-effective, and scalable.

Conclusion

Migrating our certificate platform to a serverless architecture solved several challenges that we had experienced with previous approaches.

Instead of depending on laptops, SMTP servers, or long-running processes, the platform now generates certificates on demand using AWS Lambda, stores them securely in Amazon S3, and automatically cleans up generated files using Amazon S3 Lifecycle Rules.

The result is a solution that is scalable, secure, and significantly easier to operate.

Sometimes the best optimization isn't generating files faster—it's recognizing that you don't need to keep them forever.

Why I Built a Serverless Certificate Generation System

Shashank Pandey — Tue, 07 Jul 2026 10:25:35 +0000

Why I Built a Serverless Certificate Generation System

When I was the Group Leader of the AWS Student Builders Group at Lovely Professional University, one of the biggest challenges wasn't organizing events.

It was what happened after they ended.

Every event meant generating and distributing certificates to hundreds of attendees. Which sounds easy for now.

That's exactly what I thought. Turns out, it wasn't.

Especially when you're running a student community with little to no budget and infrastructure decisions directly affect what you can (and can't) afford.

The First Attempt

Like every developer, I started with the quickest solution.

Google Apps Script + Gmail.

It was easy to build, easy to maintain, and honestly, it worked pretty well...until our events started getting bigger.

Once we crossed the 200+ attendee mark, Gmail started becoming the bottleneck.

Sending that many emails in a short period meant running into sending limits, risking spam filters, and hoping every participant actually received their certificate.

What was supposed to be a one-click automation slowly became a process of checking failed deliveries, retrying emails, and occasionally answering, "Hey, I still haven't received my certificate."

Clearly, this wasn't going to scale.

The "Let's Put It on the Website" Phase

My next thought was simple.

"Why email certificates at all? Why not let attendees generate them themselves?"

So that's exactly what I did.

Participants could log into the event platform and generate their certificates whenever they wanted.

Problem solved...or so I thought.

The website was running on Cloudflare Workers, and generating PDF certificates turned out to be one of the most compute-heavy operations in the entire application.

The more certificates people generated, the more Workers quota disappeared.

At one point, the application felt like it was spending more time generating PDFs than actually serving the website.

I had fixed the email problem. Now I had a compute problem.

Taking a Step Back

Instead of looking for a bigger server or a more expensive plan, I asked myself a different question.

Why is the website generating certificates in the first place?

The website's job is to serve users.

Certificate generation is a completely separate task.

It doesn't have to happen inside the same request. It doesn't even have to happen on the same infrastructure.

That realization changed everything.

Instead of making the website do all the heavy lifting, it would simply say,

"Hey, someone requested a certificate."

And another system would take care of the rest.

That's when I decided to move towards an event-driven, serverless architecture.

How It Works Today

The platform already had a QR-code-based attendance system.

When attendees scanned the checkout QR code, their attendance was marked as complete.

Once that happened, they became eligible for a certificate.

A Generate Certificate button appeared on their dashboard, allowing them to generate the certificate up to three times for that event.

From the participant's perspective, that's all they ever see.

Attend the event.

Scan the QR code.

Click one button.

Download the certificate.

Simple.

Behind that single click, however, there's an event-driven workflow handling all the heavy processing without putting additional load on the main application.

Why I'm Happy With This Approach

The biggest lesson from this project wasn't learning a new AWS service.

It was learning that sometimes the solution isn't making your application stronger.

It's making your application responsible for less.

Once I stopped treating certificate generation as a website feature and started treating it as an independent workflow, everything else started falling into place.

The application became lighter. The workflow became more scalable.

And the operational cost became so low that our student community could comfortably afford it ourselves.

Literally around the cost of a few evening snacks.

What's Next?

This article was about why this system exists.

In the next one, I'll go full engineering mode.

I'll walk through the complete architecture, explain why I chose a serverless event-driven approach, why each AWS service earned its place in the system, and the trade-offs I had to make along the way.

Fine-Tuning Isn’t Enough Anymore | Amazon Nova Forge Changes the Game

Shashank Pandey — Wed, 11 Feb 2026 13:33:54 +0000

For the last two years, enterprise AI customization has revolved around three techniques:

Prompt engineering
Retrieval-Augmented Generation (RAG)
Supervised fine-tuning

They work. But they all share the same limitation:

They modify a model after its core intelligence is already formed. And that’s the real bottleneck.

The Problem with “Late-Stage” Customization
By the time you fine-tune a model, its:

Representations are already shaped
Internal reasoning patterns are already formed
Safety alignment is already baked in
Generalization boundaries are already defined

Fine-tuning becomes a surface-level adjustment.

Continued pre-training (CPT) on proprietary data goes deeper, but introduces another issue:

Catastrophic forgetting.
When you train only on domain-specific data, the model starts losing foundational capabilities:

Instruction following
General reasoning
Safety robustness

This is where Amazon Nova Forge fundamentally changes the game.

1) Starting From Early Checkpoints

Instead of customizing a fully trained model, Nova Forge allows organizations to start from:

Pre-training checkpoints
Mid-training checkpoints
Post-training checkpoints

This matters technically because representation learning is still malleable at earlier stages.

You’re not just adjusting weights for task behavior; you’re influencing how the model forms abstractions.

That’s a different class of customization.

2) Data Mixing as a First-Class Strategy

A major innovation is structured dataset blending.
Instead of training solely on proprietary corpora, Nova Forge blends:

Organization-specific data
Nova-curated general training datasets

Training runs on managed infrastructure through Amazon SageMaker and integrates into Amazon Bedrock for deployment.

This approach:

Preserves general intelligence
Reduces overfitting
Mitigates catastrophic forgetting
Maintains instruction-following capability

Technically, this resembles controlled continued pre-training with safety-aware balancing.

3) Reinforcement Learning in Your Own Environment
This is where it gets interesting.

Nova Forge enables reinforcement learning using:

Custom reward functions
Multi-turn rollouts
External orchestration systems
Domain-specific simulators

Instead of static supervised tuning, organizations can:

Reward accurate molecular structures
Penalize unsafe robotic behaviors
Optimize multi-step agent workflows

This moves enterprise AI closer to environment-aware, task-optimized frontier systems without training from scratch.

4) Why This Is Strategically Important

Nova Forge is not just a feature release.

It signals AWS moving beyond:

Hosting foundation models
Offering fine-tuning APIs

Toward:

Enabling organizations to co-develop frontier-level models without absorbing full pre-training costs.

That’s a big shift in the AI stack.

What This Means for Builders and DevRel
For engineers:

This reframes customization from: “Which prompt works best?” to “Where in the training lifecycle should I intervene?”

For DevRel and community leaders:
Understanding this shift matters.
Explaining:

Why catastrophic forgetting happens
Why early checkpoint intervention matters
Why RL environments change domain alignment

is the kind of depth that moves conversations beyond surface-level AI hype.

Enterprise AI is evolving from prompt engineering to model engineering.

And Nova Forge is a signal that customization is moving earlier deeper and closer to the foundation itself.