Inspiration

Flooding is one of the most common and costly natural disasters, but specific, real-time risk information is often hard for individuals to access. The inspiration for this project was to solve the lack of a simple, personalized, and proactive tool that allows residents to understand their immediate flood risk and receive timely warnings for their specific locations of interest, such as their home or workplace.

What it does

Flood Risk Predictor is a fully functional web application that:

Provides On-Demand Analysis: A user can enter any city and instantly receive a flood risk assessment (Low, Medium, High) along with a text explanation generated by an AI model that analyzes real-time weather and news data.

Allows Users to Subscribe: Users can subscribe with their email to receive proactive alerts for any location they care about.

Sends Targeted Email Alerts: The system runs on an automated daily schedule. If it detects a high flood risk for a subscribed location, it sends a beautifully formatted HTML email alert only to the users subscribed to that specific area.

Lets Users Unsubscribe: A simple feature allows any user to instantly unsubscribe from all future alerts using just their email address.

How we built it

The application is built on a 100% serverless architecture on AWS to ensure scalability and cost-effectiveness.

The frontend is a static HTML/CSS/JavaScript site hosted on Amazon S3.

The backend is powered by AWS Lambda functions written in Python.

An Amazon API Gateway exposes the Lambda functions as a public API that the frontend can call for on-demand analysis, subscriptions, and unsubscriptions.

Amazon DynamoDB is the NoSQL database used to store all user subscription data.

The automated notification system is driven by an Amazon EventBridge Scheduler, which triggers a Lambda function on a daily schedule.

Instead of a simple "blast all" approach, we use Amazon SES (Simple Email Service) to send targeted, professional HTML emails directly to the relevant subscribers.

The "brains" of the operation is a Generative AI model (Gemini), which receives real-time weather data from the OpenWeatherMap API and headlines from the NewsAPI to perform its risk analysis.

Challenges we ran into

Building a distributed system came with several challenges that we successfully navigated:

Targeted vs. Broadcast Notifications: Our initial design used SNS, which was great for broadcasting a message to everyone. However, we realized users needed targeted alerts. This prompted a significant architectural pivot to Amazon SES and a rewrite of our scheduled-lambda logic to handle one-to-one notifications, which made the application much more powerful.

CORS Errors: Like many web applications, we ran into Cross-Origin Resource Sharing (CORS) errors when trying to connect the S3 frontend to the API Gateway backend. We solved this by correctly configuring the CORS policy in API Gateway.

IAM Permissions: The most common source of bugs was incorrect IAM permissions. We learned to debug these "silent failures" by meticulously checking CloudWatch logs to find "Access Denied" errors and then crafting least-privilege policies for each Lambda function's role.

SES Sandbox Limitations: A major challenge was realizing our application could only email pre-verified addresses while in the SES sandbox. We overcame this for the hackathon by creating a clear demo video showing the end-to-end flow and adding a note to our README to guide judges on how to test it live with a demo account.

Accomplishments that we're proud of

Building a Full-Stack, End-to-End Application: We're incredibly proud of building a complete, working application with a frontend, a multi-function backend, and a database, not just a single script or concept.

Practical AI Integration: We successfully integrated a powerful generative AI model to solve a real-world, practical problem, moving beyond simple chatbot functionality.

Complex Serverless Architecture: We designed and implemented a non-trivial, event-driven architecture using six core AWS services that work in harmony.

Professional Features: We implemented key features that make the application feel like a real product, such as targeted HTML emails and an unsubscribe mechanism.

What we learned

We gained a deep, practical understanding of how to build and debug an event-driven, serverless system on AWS.

We learned that IAM is the foundation of everything in AWS, and a methodical approach to permissions is key to success.

We now have hands-on experience integrating a suite of AWS services: API Gateway for user requests, Lambda for logic, DynamoDB for state, EventBridge for scheduling, and SES for notifications.

We learned the importance of reading the documentation for managed services to understand their limitations (like the SES sandbox) and how to work with them effectively.

What's next for Flood Risk Predictor

This project has a strong foundation, and we're excited about the future possibilities:

Transition to Amazon Bedrock: The next logical step is to replace the external call to the Gemini API with Amazon Bedrock, making the application fully AWS-native and allowing us to experiment with other models like Anthropic's Claude 3. The reason we haven't migrated to Amazon Bedrock right now is because of cost constraints.

Multi-Channel Alerts: We plan to re-integrate SNS to add SMS as a notification channel, giving users a choice of how they want to be alerted.

User Dashboard: We want to build a user-facing dashboard where a logged-in user can manage all their subscribed locations and view historical risk data.

Richer Data Sources: To improve accuracy, we plan to ingest more data sources, such as real-time river level data from USGS APIs and Doppler radar precipitation maps.

Built With

Share this project:

Updates