Building a Serverless Fraud Detection API Using AWS SAM, Lambda, DynamoDB and S3
Designing a lightweight cloud API for our AI-powered waste compliance project
Building an AI system involves more than training a model. Once the model has produced its predictions, those results need to be stored, retrieved, and made accessible to applications. During Bharat Builds 2026 by WeMakeDevs, we encountered this architectural challenge while developing National Waste Compliance Audit.
Our platform analyzes potential compliance violations in plastic recycling and biomedical waste management. Our component, Phantom Plastic, generates anomaly scores and evidence-backed case files for suspicious recycling activity.
We already had a Streamlit dashboard architecture hosted using Amazon EC2. But we also wanted a cleaner way to expose audit findings without depending on the main application for every result request.
This led us to design a serverless API using the AWS Serverless Application Model (AWS SAM).
Why Serverless?
Our anomaly detection pipeline and our API have fundamentally different responsibilities.
The detection pipeline performs computationally intensive operations, including feature engineering, Isolation Forest analysis, graph modeling, and risk aggregation.
The API primarily needs to retrieve results that have already been computed.
Running a full machine learning pipeline whenever someone requests a recycler's case file would be unnecessary and inefficient.
Instead, we designed a workflow where the model produces audit results first, and a lightweight API retrieves them on demand.
This approach separates model computation from result delivery.
Our AWS Serverless Architecture
We defined the serverless infrastructure in
phantom/aws/template.yaml .Each AWS service has a specific responsibility.
1. Amazon S3 - Storing Detailed Case Files
Our anomaly detection system produces JSON case files containing investigation-relevant information.
These records can include an entity profile, suspicious indicators, supporting evidence, and inspection suggestions.
We designed Amazon S3 as the object storage layer for these files.
A case is stored using a predictable key structure:
cases/{entity_id}.json This keeps detailed evidence separate from the lightweight risk scores.
2. Amazon DynamoDB - Accessing Audit Signals
Every detected anomaly follows a standardized structure:
JSON
{"entity_id": "RECYCLER_ID","agent": "phantom_plastic","score": 0.92,"reasons": ["Example anomaly indicator"],"evidence_refs": ["Example evidence reference"]}
This is an illustrative record, not an actual detection output.
Our AWS SAM template defines a DynamoDB table using entity_id as the partition key.
It also uses on-demand billing through:
BillingMode: PAY_PER_REQUEST
This means the table doesn't require manually configuring provisioned read and write capacity.
For a prototype whose API request volume may be unpredictable, this is a convenient option.
3. AWS Lambda - Lightweight API Execution
We developed a Python Lambda handler to retrieve the precomputed audit findings.
The function interacts with Amazon S3 and DynamoDB through the AWS SDK for Python, Boto3.
Instead of running anomaly detection inside Lambda, it serves the results produced by the existing pipeline.
This keeps the function focused on a simpler responsibility.
4. Amazon API Gateway - Exposing HTTP Endpoints
Our SAM template defines two HTTP API routes.
Endpoint 1: Retrieve high-risk entities
GET /top?n=20 — Retrieves the top n highest-risk entities.This endpoint is designed to retrieve audit signals, sort them by descending risk score, and return the requested number of entities.
Endpoint 2: Retrieve an investigation case
GET /case/{entity_id} — Fetches the detailed JSON case file from S3 along with an inspector-friendly summary.This endpoint retrieves the corresponding JSON case file from S3 and adds an inspector-friendly summary.
These endpoints create a foundation for integrating audit results with other applications.
Infrastructure as Code with AWS SAM
One of the biggest advantages of AWS SAM is being able to describe the architecture in a single YAML template.
Rather than manually configuring Lambda, API Gateway, storage resources, and permissions independently, we define their relationships declaratively.
Our template also includes policies for reading from S3 and DynamoDB.
The basic deployment workflow for this type of SAM application is:
Bash
sam buildsam deploy --guided
These are the intended deployment commands. The repository contains the SAM implementation, but it does not yet document a successful cloud deployment or integration test.
Publishing the Results
We also implemented a Python publishing script:
Bash
python -m phantom.aws.deploy \--run phantom/outputs/seed42 \--bucket YOUR_BUCKET \--table YOUR_TABLE
The script is designed to upload case files to S3 and write anomaly signals to DynamoDB.
This forms the bridge between our machine learning pipeline and the serverless API.
What We Would Improve for Production
Our initial implementation is intentionally lightweight.
For example, the /top endpoint currently uses a DynamoDB scan followed by application-side sorting. This is manageable as a prototype approach, but it would become inefficient as the dataset grows.
A production implementation would benefit from a suitable index or precomputed ranking structure, pagination, API authentication, request validation, and monitoring.
The next milestone is deploying the stack to AWS, testing the endpoints with populated S3 and DynamoDB resources, and validating the entire workflow end to end.
Final Thoughts
AWS SAM helped us think about backend architecture differently.
Instead of building one large application responsible for detection, storage, retrieval, and presentation, we designed a more modular system.
Amazon EC2 provides the hosting environment for our interactive dashboard, while the AWS SAM architecture provides a path toward independently scalable, serverless access to the findings.
Our biggest takeaway: not every part of an AI application needs to run where the AI model runs.
Separating expensive computation from lightweight result delivery can make a system easier to maintain and evolve.
AWS Implementation: phantom/aws/
Built for: Bharat Builds 2026 | WeMakeDevs
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article