Building EcoTrack AI: A Serverless Waste Reporting Platform on AWS
How I built and deployed a waste reporting and monitoring platform using AWS Amplify, API Gateway, Lambda, S3, and DynamoDB—and what I learned while connecting these services into a working application.
Turning a Real-World Problem Into a
Cloud Application
Waste management is a challenge faced by communities around the world. Waste dumped in public places can harm the environment, while tracking reports and monitoring cleanup progress can be difficult.
During an AWS hackathon, I decided to build EcoTrack AI, a cloud-based waste reporting and monitoring platform designed to make this process more organized.
The idea was straightforward: allow users to report waste with a location, description, and photo, then provide a dashboard for monitoring reports, identifying potential hotspots, and tracking resolution.
However, building a working application required more than designing a frontend. I needed to connect the user interface to a backend, store uploaded photos, persist report information, and ensure that updates appeared on the dashboard.
This project became an opportunity to learn how multiple AWS services can work together to solve a practical problem.
Project links
- Live application: https://main.d27as80dtfkeqp.amplifyapp.com
- GitHub repository: https://github.com/aditya052003/ecotrack-ai
1. What Does EcoTrack AI Do?
EcoTrack AI brings four main capabilities into one application.
Waste reporting
Users can submit a report by entering a location, describing the waste, and uploading a photograph.
Waste classification and priority assignment
The current implementation uses keyword-based rules to classify waste descriptions and assign priority levels. For example, descriptions containing relevant plastic-related keywords can be classified as plastic waste.
This is a rule-based implementation rather than live AI inference. I explored Amazon Bedrock integration during development, but encountered model-access and invocation errors, so I retained the working classification fallback.
Dashboard and hotspot insights
The dashboard summarizes submitted reports and displays information about waste categories, locations, and unresolved reports. Hotspot insights help highlight locations that may need cleanup attention.
Resolution tracking
Reports can be marked as resolved. The dashboard retrieves updated report information so that users can monitor progress.
These features make the application more than a simple reporting form: they connect report submission with storage, monitoring, and status management.
2. The Technology Stack
I built the frontend using React and JavaScript, with Vite as the development tooling.
The application uses the following technologies:
- React and JavaScript: Frontend interface and user interactions.
- Vite: Frontend development and build tooling.
- AWS Amplify: Frontend hosting and deployment.
- Amazon API Gateway: HTTP endpoints for frontend-to-backend communication.
- AWS Lambda: Backend processing and application logic.
- Amazon S3: Storage for uploaded waste photographs.
- Amazon DynamoDB: Persistence of structured waste report records.
- Node.js: Runtime for the backend functions implemented in JavaScript.
I chose managed AWS services because they allowed me to build a cloud-backed application without maintaining a dedicated application server.
3. Understanding the AWS Architecture
The architecture connects the frontend, backend processing, storage, and dashboard.
The main reporting workflow looks like this:
React frontend → Amazon API Gateway → AWS Lambda → Amazon S3 and Amazon DynamoDB
Here is the role of each component.
AWS Amplify: Hosting the frontend
Amplify hosts the React application and integrates with the GitHub repository for deployment.
This made it possible to publish the application at a public URL and update the deployed version as I pushed changes to the repository.
Amazon API Gateway: Connecting the application
API Gateway exposes HTTP endpoints used by the frontend to communicate with backend functionality.
It provides a clear boundary between the user interface and the backend operations.
AWS Lambda: Processing reports
Lambda executes the backend logic without requiring me to operate a continuously running application server.
The reporting workflow handles incoming report data, applies the current classification rules, uploads the photograph, and persists the report information.
I also implemented separate dashboard and report-resolution functionality using Lambda-backed APIs.
Amazon S3: Storing photographs
Images are stored in an S3 bucket under a reports prefix.
Keeping uploaded photographs in object storage avoids placing image files directly inside database records. The report record can instead retain the relevant photo reference.
Amazon DynamoDB: Storing report records
DynamoDB stores structured report information, including identifiers, locations, waste classifications, priorities, and status.
The dashboard retrieves this information to calculate statistics and present hotspot insights.
This separation between photo storage and structured report data made the application's storage workflow easier to understand and test.
4. Following a Report Through the System
To verify the architecture, I tested a complete reporting workflow.
First, I submitted a waste report through the deployed frontend, providing a location, description, and photograph.
Next, the backend processed the request. The photograph appeared in the S3 reports folder, and the corresponding report record appeared in DynamoDB.
I then checked the dashboard to confirm that the report was reflected in the application's data.
Finally, I marked a test report as resolved. The report status changed, and the dashboard statistics updated accordingly.
This testing was important because a successful frontend submission alone does not prove that the entire backend workflow is functioning correctly.
Verifying both the stored data and the user-visible result helped me confirm that the connected services were working together as intended.
5. Challenges I Encountered
Connecting multiple AWS services
One challenge was understanding how requests moved from the frontend through API Gateway and Lambda to the storage services.
A failure at any stage could affect the final result. I learned to verify each part of the workflow instead of assuming that a successful response from the frontend meant every operation had completed correctly.
Working with model access and invocation errors
I also explored integrating Amazon Bedrock for AI-assisted classification. During development, I encountered model invocation and access errors that prevented me from completing a reliable live integration.
Rather than claiming that AI inference was working when it was not, I retained the rule-based classification implementation.
This was an important engineering lesson: a project should communicate what is actually implemented, distinguish working features from planned enhancements, and remain testable even when an external dependency is unavailable.
Verifying dashboard consistency
The dashboard needed to reflect report creation and resolution updates correctly.
Testing the application with a newly submitted report and then resolving that report helped verify that the displayed statistics were consistent with the underlying records.
6. What I Learned From This Project
Building EcoTrack AI gave me practical experience with several aspects of cloud application development.
First, architecture matters. Choosing services is only one part of the task. The real work is connecting them correctly and understanding how data moves through the system.
Second, storage responsibilities should be clear. Amazon S3 is suitable for uploaded image objects, while DynamoDB stores the structured information used by the application.
Third, testing must cover the entire workflow. I learned to check report submission, photo storage, database persistence, dashboard updates, and resolution tracking instead of testing each screen in isolation.
Finally, engineering requires honest trade-offs. When my planned Bedrock integration did not work reliably, I kept the working classification implementation and documented the limitation. Future work can focus on improving classification accuracy and integrating a suitable AI model when access is available.
7. What I Would Improve Next
EcoTrack AI is a working prototype, but there are several areas I would improve before a larger deployment.
- Security: Strengthen request validation, upload restrictions, authorization, and protection against unauthorized report updates.
- Classification: Improve the classification rules and evaluate an accessible AI model for more advanced classification.
- Monitoring: Use Amazon CloudWatch logs and metrics to make backend errors easier to investigate.
- Scalability: Review database access patterns, error handling, and performance as the number of reports grows.
- User experience: Continue improving hotspot insights and make the reporting and resolution process easier to use.
These improvements would help move the project from a hackathon prototype toward a more robust application.
Conclusion
EcoTrack AI started with a practical goal: make waste reporting and cleanup tracking easier to organize.
By combining React with AWS Amplify, API Gateway, Lambda, S3, and DynamoDB, I built and deployed an application that supports report submission, photograph storage, dashboard insights, and resolution tracking.
The most valuable part of this experience was learning how to connect cloud services into a working end-to-end system, test the data flow, and work through integration challenges.
For me, this project demonstrates how cloud computing can provide a foundation for practical applications addressing environmental problems.
I look forward to continuing to improve EcoTrack AI, particularly its classification capabilities, security, and monitoring.
The biggest lesson I learned: building a cloud application is not just about choosing services—it is about making them work together reliably to solve a real problem.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article