PRISM: Building an AI-Powered Event Photo Gallery with AWS Serverless Architecture

PRISM is an AI-powered event photo gallery that uses AWS serverless services and Amazon Rekognition to help guests quickly find photos they appear in. This article explores the architecture, authentication flows, serverless backend, image-processing pipeline, data storage, and lessons learned while building the project.

Anwesh Bhattacharya

Published Oct 2, 2026

Last modified Oct 2, 2026

🤔 The Problem

We've all been there.

You attend an event 📸, someone takes hundreds or thousands of photos, and later you're given a huge gallery.

Now begins the adventure:

"Was I in photo 247?" 😭
"Wait... maybe photo 613?"
"Let me check all 1,200 photos..." 💀

I wanted to make that process much simpler.

So the idea behind PRISM was:

🤳 Upload a selfie → 🔍 Search → 📸 Find your photos

Instead of manually scrolling through an entire event gallery, guests can provide a reference selfie and let the system search for photographs in which they appear.

That's where AWS + Amazon Rekognition came into the picture. ☁️🤖

🪄 How PRISM Works

PRISM has two main types of users:

👨‍💼 Event Hosts
🙋 Event Guests

And each has a slightly different journey.

👨‍💼 For the Host

The host logs in and manages the event:

1
2
3
4
5
6
7
8
9
10
11
🔐 Host Login
      ↓
👤 Amazon Cognito
      ↓
🖥️ Host Dashboard
      ↓
🏠 Create Event Room
      ↓
📤 Upload Event Photos
      ↓
☁️ Amazon S3

Hosts can create unique event rooms and upload their event photographs directly to S3.

🙋 For the Guest

Guests don't need to go through the same authentication flow.

Instead:

1
2
3
4
5
6
7
8
9
10
11
12
13
🔗 Event Link
     ↓
🔑 Room Code
     ↓
🎫 Guest Session / JWT
     ↓
🤳 Upload Selfie
     ↓
🤖 Amazon Rekognition
     ↓
🔍 Search
     ↓
📸 Your Photos!

The guest experience is designed to be as simple as possible: enter the event → upload a selfie → find your photos.

☁️ The AWS Architecture

This is where things get interesting. 😎

Instead of building a traditional backend running on a dedicated server, I used a serverless AWS architecture.

The main building blocks are:

🖥️ AWS Amplify → Frontend hosting
🔐 Amazon Cognito → Host authentication
🌐 API Gateway → API entry point
⚡ AWS Lambda → Backend processing
🗄️ Amazon DynamoDB → Application data
🪣 Amazon S3 → Event photo storage
🤖 Amazon Rekognition → Facial analysis
⏰ Amazon EventBridge → Scheduled tasks

The frontend uses React, Vite, and Tailwind CSS, while the backend is deployed using AWS SAM/CloudFormation with Python 3.11 Lambda handlers.

🔐 PRISM serverless architecture showing host and guest authentication, AWS Amplify, Amazon Cognito, API Gateway, AWS Lambda, Amazon DynamoDB, Amazon S3, Amazon Rekognition, and Amazon EventBridge, including 📤 photo uploads, 🤖 face indexing, 🔍 photo search, and 🗑️ cascade deletion flows. — 📸 PRISM AWS Serverless Architecture & Data Flow. The diagram illustrates the complete PRISM architecture, showing how the frontend, authentication layer 🔐, Lambda compute ⚡, DynamoDB 🗄️, S3 📦, Amazon Rekognition 🤖, and EventBridge ⏰ work together. It also highlights separate host and guest access flows, JWT authorization 🔑, photo processing 📤, facial-recognition search 🔍, and cascade deletion operations 🗑️.

🔐 Authentication: Hosts vs Guests

One of the interesting design problems was:

How do you authenticate event organizers without forcing every guest to create an account? 🤔

I decided to separate the two flows.

👨‍💼 Hosts

Hosts use Amazon Cognito.

1
2
3
4
5
6
7
8
9
👨‍💼 Host
   ↓
🔐 Cognito
   ↓
🎫 Authentication Token
   ↓
🌐 API Gateway
   ↓
⚡ Lambda

This gives hosts authenticated access to their event management functionality.

🙋 Guests

Guests use a different flow:

1
2
3
4
5
6
7
8
9
10
11
🙋 Guest
   ↓
🏠 Room Code
   ↓
🎫 JWT Session
   ↓
🛡️ Lambda Authorizer
   ↓
🌐 API Gateway
   ↓
⚡ Lambda

The guest authorization layer uses JWT-based sessions with an API Gateway Lambda Authorizer.

This was one of those architectural decisions that looks simple on paper but becomes really interesting when you actually implement it. 😅

📤 Uploading Event Photos

Now comes the part where things get photo-heavy. 📸📸📸

Imagine an event with hundreds or thousands of photos.

I didn't want every large image to travel through the application backend unnecessarily.

Instead, PRISM uses Amazon S3 as the main photo storage layer.

The simplified flow is:

1
2
3
4
5
6
7
8
9
🖥️ Application
      ↓
⚡ Lambda
      ↓
🔗 Presigned S3 URL
      ↓
🪣 Amazon S3
      ↓
📸 Image Stored

This keeps the actual image storage separate from the application logic.

And that's one of the things I really enjoyed about working with AWS — you can let each service focus on what it does best. 💡

🤖 Where the AI Comes In

This is probably my favorite part of PRISM. 😄

Once photographs are uploaded, PRISM can process them using Amazon Rekognition.

The basic idea is:

1
2
3
4
5
6
7
8
9
10
11
📸 Photo Uploaded
      ↓
🪣 Amazon S3
      ↓
⚡ Event Trigger
      ↓
λ AWS Lambda
      ↓
🤖 Amazon Rekognition
      ↓
🧠 Face Indexing

The architecture uses S3 object creation events to trigger processing and connect the uploaded images with Rekognition indexing.

So instead of manually asking the backend to process every image, the system can react to the upload event automatically.

That's where the event-driven architecture starts becoming really useful. 🚀

🔍 Finding Your Photos

Now imagine you're attending an event.

You upload one selfie:

🤳 "This is me."

PRISM then uses the facial information provided by Amazon Rekognition to search the indexed event photographs.

Conceptually:

1
2
3
4
5
6
7
8
9
10
11
🤳 Reference Selfie
       ↓
⚡ Search Lambda
       ↓
🤖 Amazon Rekognition
       ↓
🔍 Matching Faces
       ↓
🗄️ Photo Metadata
       ↓
📸 Matching Photos

And hopefully...

🎉 There you are!

🗄️ DynamoDB: Keeping Everything Organized

Of course, finding faces isn't enough.

PRISM also needs to know things like:

🏠 Which event does this photo belong to?
📸 Which S3 object represents the photo?
👤 Which guest session is accessing it?
🔗 Which room is being requested?

That's where Amazon DynamoDB comes in.

DynamoDB acts as the application's NoSQL data layer, while S3 handles the actual image objects.

So I ended up with a nice separation:

DynamoDB → "What is this data?" 🗄️

S3 → "Where is the actual image?" 🪣

🧹 What Happens When an Event Is Deleted?

This turned out to be more interesting than I initially expected. 😅

Deleting an event isn't necessarily:

🗑️ Delete one database row.

An event can have:

🏠 Event information
📸 Photo records
🪣 S3 objects
🤖 Rekognition face data

So the deletion process needs to consider the relationships between these resources.

PRISM includes cascading operations to keep related application data synchronized when event resources are removed.

This was a good reminder that:

Cloud architecture isn't just about creating resources — you also have to think about what happens when those resources need to disappear. 🧹☁️

⏰ EventBridge & Background Tasks

Not everything needs to happen while a user is staring at the screen.

Some maintenance operations can happen in the background.

That's where Amazon EventBridge comes into the architecture. ⏰

The idea is:

1
2
3
4
5
⏰ Scheduled Event
       ↓
⚡ Lambda
       ↓
🧹 Cleanup / Maintenance

This allows scheduled operations to run independently from normal user requests.

🧰 Tech Stack

Here's the toolbox behind PRISM 🛠️:

🎨 Frontend

⚛️ React
⚡ Vite
🎨 Tailwind CSS
☁️ AWS Amplify

⚙️ Backend

🐍 Python 3.11
⚡ AWS Lambda
🌐 Amazon API Gateway
🏗️ AWS SAM / CloudFormation

🗄️ Storage & Database

🪣 Amazon S3
🗃️ Amazon DynamoDB

🤖 AI

🧠 Amazon Rekognition

🔐 Security

👤 Amazon Cognito
🛡️ API Gateway Lambda Authorizers
🎫 JWT-based guest sessions

⏰ Automation

📅 Amazon EventBridge

The repository contains separate frontend and backend components along with the AWS infrastructure configuration and architecture diagrams.

🧠 What I Learned

This project changed the way I think about learning AWS.

Initially, it can feel like AWS is just a huge list of services:

"Learn S3."
"Learn Lambda."
"Learn DynamoDB."
"Learn Cognito." 😵‍💫

But building PRISM showed me that the interesting part isn't just knowing what each service does.

It's understanding:

How do these services work together? 🤔

Through PRISM, I got hands-on experience with:

☁️ Serverless architecture
⚡ AWS Lambda
🌐 API Gateway
🔐 Cognito
🎫 JWT authorization
🪣 S3
🔗 Presigned URLs
🗄️ DynamoDB
🤖 Rekognition
⚡ Event-driven processing
⏰ EventBridge
🏗️ Infrastructure as Code
🧹 Cross-service cleanup

And probably the biggest lesson:

A cloud application is more than a collection of services. The real engineering challenge is designing how those services communicate with each other.

🚀 What's Next?

PRISM is still a project I'm using to learn and experiment, so there are plenty of things I'd like to explore next. 👀

Some areas I'm interested in:

🔐 More security improvements
📊 Better monitoring and observability
💰 AWS cost optimization
📈 Scalability for larger event galleries
🛠️ More robust error handling
⚡ Performance improvements
☁️ Making the architecture more production-ready

There is still a lot to learn, and that's honestly one of the most enjoyable parts of working on cloud projects. 😄

🚀 Try PRISM!

Enough reading. 😎

If you'd like to see the project in action:

👉 Live Demo: Try PRISM 🚀

You can explore the deployed application and try the event photo workflow.

💻 Explore the Code

Want to see what's happening behind the scenes? 👀

👉 GitHub: AnweshBhattacharya/PRISM 💻

The repository includes the frontend, backend, AWS infrastructure configuration, and architecture documentation.

🎯 Final Thoughts

PRISM started with a pretty simple question:

"What if finding your photos at an event was as easy as uploading a selfie?" 🤳

Building that idea turned into a much bigger learning experience around AWS, serverless architecture, AI, authentication, storage, APIs, and event-driven systems.

The coolest part for me wasn't using one particular AWS service.

It was seeing this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
👤 User
  ↓
🌐 Frontend
  ↓
🔐 Authentication
  ↓
🌐 API Gateway
  ↓
⚡ Lambda
  ↓
🗄️ DynamoDB
  ↓
🪣 S3
  ↓
🤖 Rekognition
  ↓
📸 Photos

...actually become a working application. 🚀☁️

I'm continuing to explore AWS, cloud architecture, and DevOps, and PRISM has been a great hands-on project along that journey.

💬 Your turn!

If you're also building something with AWS:

What's the coolest AWS project you've built, and which service gave you the biggest "aha!" moment? 🤔☁️

I'd love to hear about it! 👇

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.

Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article

Builder Center

PRISM: Building an AI-Powered Event Photo Gallery with AWS Serverless Architecture

Anwesh Bhattacharya

🤔 The Problem

🤳 Upload a selfie → 🔍 Search → 📸 Find your photos

🪄 How PRISM Works

👨‍💼 For the Host

🙋 For the Guest

☁️ The AWS Architecture

🔐 Authentication: Hosts vs Guests

👨‍💼 Hosts

🙋 Guests

📤 Uploading Event Photos

🤖 Where the AI Comes In

🔍 Finding Your Photos

🗄️ DynamoDB: Keeping Everything Organized

🧹 What Happens When an Event Is Deleted?

⏰ EventBridge & Background Tasks

🧰 Tech Stack

🎨 Frontend

⚙️ Backend

🗄️ Storage & Database

🤖 AI

🔐 Security

⏰ Automation

🧠 What I Learned

How do these services work together? 🤔

🚀 What's Next?

🚀 Try PRISM!

💻 Explore the Code

🎯 Final Thoughts

💬 Your turn!