Dog Breed Identifier
This project is a small end-to-end AWS workload built to show how I think about architecture, security, and cost trade-offs — not to claim perfect breed accuracy.
The user uploads a dog photo and gets the most likely breed plus a few alternatives. Behind the scenes, the design stays simple: direct uploads to S3, a protected public API, container-based Lambda inference, and DynamoDB for storing results.
- Separate pieces for the website, uploads, prediction, and result storage.
- Edge protection in front of the public API.
- No always-on compute for a low-cost public demo.
Quick demo video
I will be recording a short 4-5 minute walkthrough explaining the user flow and key design choices.
Watch the YouTube video (coming soon)
End-to-end request flow
- The frontend (
breed.html) is hosted on Amazon S3 and delivered through CloudFront. - A dedicated AWS Lambda function creates a short-lived S3 upload request so the browser can upload directly to S3.
- Prediction requests go through CloudFront + AWS WAF to API Gateway.
- A container-based AWS Lambda reads the image from S3, runs the model, returns the top results, and stores the result in DynamoDB.
Architecture at a glance
- Frontend: static site on Amazon S3 behind CloudFront.
- DNS and HTTPS: Route 53 and AWS Certificate Manager (ACM).
- Uploads: direct-to-S3 upload flow using a dedicated presign Lambda.
- Public API: CloudFront + AWS WAF in front of API Gateway.
- Inference: container-based AWS Lambda.
- Storage: S3 for images and DynamoDB for prediction results.
- Operations: CloudWatch Logs, EventBridge warm-up, and Terraform Cloud.
Model approach
This project uses a dog-breed classification model packaged with the runtime, so the function does not need to download model files during a request. The model is based on the Stanford Dogs dataset, so I can clearly explain what breed labels it is predicting.
- Built into the container image instead of being pulled in during a live request.
- Clear breed labels based on the Stanford Dogs dataset.
- Stored results written to DynamoDB for review.
Cold-start mitigation
Public demo traffic is unpredictable, so first requests can be slower after idle periods. To reduce that, an EventBridge rule periodically warms the prediction function. The warm-up path loads the model and exits without reading from S3 or writing to DynamoDB.
Security and governance
- Edge protection — AWS WAF filters traffic before it reaches API Gateway and Lambda.
- Credential safety — the browser uploads with a short-lived S3 upload request instead of AWS keys.
- Least-privilege access — the upload function can only create upload requests, and the prediction function can only read from S3 and write results to DynamoDB.
- Data handling — images are stored in S3, results are stored in DynamoDB, and the system does not collect identity data.
Challenges & lessons learned
I documented the real-world issues I ran into, including early prediction quality problems and the steps I took to make the demo more reliable for random visitors.
Cost posture
- Event-driven compute — no always-on servers.
- Direct-to-S3 uploads — large files do not pass through the public API.
- Targeted warm-up — reduces slow first requests without turning the system into an always-on service.
Infrastructure as code
All infrastructure for this project is defined and managed using Terraform Cloud. That keeps the system reproducible and makes changes easier to review.
What I would do next
- Monitoring — add simple success/error and latency alarms.
- Safer rollout — introduce a controlled rollout process for prediction changes.
- Evaluation — track confidence trends over time so the model’s limits are easier to explain.
Bottom line
This project shows how to handle public uploads and on-demand image prediction on AWS without keeping servers running all the time.
It focuses on clear system design, edge protection, and a demo that behaves consistently instead of making big claims about model accuracy.