<HC />
Back to Projects
Cloud & Serverless ArchitectureCompleted

Wildlife Explorer

A cloud-native wildlife detection platform that turns browser cameras into automated camera traps, processing captures via S3 object events, Amazon Rekognition animal filtering, SQS asynchronous polling, DynamoDB leaderboards, and CloudWatch metrics.

PythonFlaskAWS LambdaAmazon RekognitionAmazon DynamoDBAWS S3Amazon SQSAmazon SNSAWS CloudWatchAmazon EC2boto3HTML5CSS3JavaScript

Screenshots

Wildlife Explorer — Home Page
Home Page
Wildlife Explorer — Detection Result
Detection Result

Key Metrics

Event-Driven S3 & SQS Pipeline

Amazon Rekognition Animal Filtering

3 DynamoDB Tables (Detections, Leaderboard, Stats)

Amazon SQS Message Queue

Amazon SNS New Species Email Alerts

Automated Idempotent boto3 Script

Overview

Wildlife Explorer is a cloud-native wildlife detection and species tracking application. By using the browser camera as a digital camera trap, images uploaded to Amazon S3 trigger an AWS Lambda function that uses Amazon Rekognition to detect and filter animal species, updates DynamoDB leaderboards, pushes results to SQS, and streams operational telemetry to CloudWatch dashboards.

Problem

Real-time image classification and species tracking platforms frequently overload databases with continuous polling requests, causing latency spikes and high operational costs when processing live camera streams.

Solution

Built an event-driven serverless pipeline using S3 ObjectCreated events, AWS Lambda, Amazon Rekognition animal label filtering, and Amazon SQS as an asynchronous buffer. Flask backend instances poll SQS for processed detection messages instead of continuously querying DynamoDB.

Architecture

Event-driven cloud architecture. A Flask application hosted on Amazon EC2 (managed via AWS Systems Manager without SSH) captures browser camera input and uploads images to Amazon S3. S3 ObjectCreated events invoke an AWS Lambda processor that calls Amazon Rekognition DetectLabels, filters non-animal labels, updates three DynamoDB tables (WildlifeDetections, WildlifeLeaderboard, WildlifeStats), publishes metrics to CloudWatch, sends new species alerts via SNS, and pushes completed results to an SQS queue polled by the Flask web application.

Challenges

  • Decoupling processing results from web server polling using Amazon SQS to prevent excessive DynamoDB read units.
  • Filtering generic Amazon Rekognition label outputs to strictly retain animal species and count detected specimens.
  • Managing modular boto3 infrastructure scripts (deploy.py, resources_*.py) with persistent deployment state tracking (wildlife_state.json).
  • Operating EC2 web servers without SSH access by enforcing AWS Systems Manager (SSM) management and systemd services.

Lessons Learned

  • Asynchronous processing architectures combining S3 events, Lambda, and SQS queues.
  • Domain-specific label filtering with computer vision services like Amazon Rekognition.
  • Multi-table NoSQL data design for detection history, atomic species leaderboards, and aggregate metrics in DynamoDB.
  • Systems Manager (SSM) based EC2 administration without public SSH ports.
  • Automated cloud deployment state tracking and teardown script design.

Future Improvements

  • Deploying custom Rekognition Custom Labels model trained specifically on regional wildlife species.
  • Replacing EC2 hosting with static S3 + CloudFront CDN for frontend and API Gateway + Lambda for read APIs.
  • Adding automated GPS geolocation tagging and interactive map visualizations for wildlife sightings.
  • Implementing WebSocket support for instant real-time UI updates without SQS polling.