HydroSense: Building an AI-Powered Urban Flood Monitoring Platform on AWS
HydroSense is an AWS-powered urban flood monitoring platform combining rainfall data, historical records, community reports, and Amazon Bedrock image assessment to identify risky underpasses. Its dashboard provides location-based risk insights, while Arduino-based sensing supports future field monitoring. Live application: https://d348efecbg3b7i.cloudfront.net/ Video demonstration: https://youtu.be/fAbQ15Nhqpw Source code: https://github.com/mukulpythondev/hydrosense/
How our team combined underpass risk intelligence, community reporting, and generative AI to tackle urban waterlogging.
Every monsoon, waterlogged roads and underpasses can turn an ordinary commute into a dangerous journey. The challenge is not only the water itself. It is knowing which locations may be at risk, finding useful evidence, and making that information accessible before people encounter a hazard.
That question became the starting point for HydroSense, our project for the AWS hackathon.
We wanted to build more than a map with colored markers. Our goal was to bring underpass risk information, historical waterlogging evidence, community reports, and AI-assisted image assessment into one platform—and use AWS to turn that idea into a working web application.
This is the story of how we approached the problem, what we built, the cloud architecture behind it, and what we learned along the way.
1. The problem: waterlogging information is fragmented
Urban waterlogging is difficult to understand from a single data source.
Rainfall can indicate changing conditions, historical incidents can identify locations that have experienced problems before, and community reports can provide evidence about what people are observing on the ground. Each source contributes something different.
We wanted HydroSense to bring these signals together in a single experience.
The platform focuses on three questions:
- Where might waterlogging be a concern? Underpass hotspots and risk information help users identify locations that deserve attention.
- Why might a location be risky? Rainfall-related information and historical evidence provide context for the assessment.
- What are people observing now? Community reports and uploaded images add another source of evidence.
We also designed an Arduino-based water-level sensing and gateway workflow as part of the broader system. This provides a path toward incorporating physical observations into the platform as the sensor-to-cloud integration develops.
The result is a flood-risk decision-support platform designed around evidence rather than a single isolated measurement.
2. From an idea to a working platform
We began by thinking about the complete system: water-level sensing, connectivity, cloud processing, risk information, and a dashboard that people could actually use.
As development progressed, we learned that a convincing product requires more than connecting a frontend to an API. We needed to make data available, preserve reports, handle missing information, and give users a useful way to submit evidence.
We organized the software around several capabilities.
Underpass risk intelligence. The dashboard presents underpass hotspots and risk information supported by rainfall-related assessment and curated historical waterlogging evidence.
Community reporting. Users can submit a report associated with a hotspot, add notes, and attach an image. Reports are persisted so that the information is available beyond the original browser session.
AI-assisted image assessment. We added a workflow that accepts an uploaded image, sends it for analysis, and stores an advisory with the associated report.
A unified dashboard. Rather than forcing users to navigate separate tools for the map, incidents, and image assessments, HydroSense brings these capabilities into one interface.
The important milestone was moving from a concept to a deployed application with persistent reports and a genuinely working AI image-assessment workflow.
3. Why we chose AWS
We wanted an architecture that we could deploy and validate during the hackathon without managing a fleet of servers.
AWS provided managed services for the main parts of the application: frontend delivery, API processing, persistent storage, image uploads, and model inference.
Our deployed architecture uses the following services.
AWS service | Role in HydroSense |
|---|---|
Amazon CloudFront | Delivers the public web application. |
Amazon S3 | Hosts the frontend and stores uploaded image evidence in a separate private bucket. |
Amazon API Gateway | Exposes the backend HTTP API. |
AWS Lambda | Runs the Python backend and application logic. |
Amazon DynamoDB | Persists readings, incidents, and community reports. |
Amazon Bedrock | Provides access to the Nova Lite model for image assessment and advisory generation. |
The frontend is built with React, while the backend uses Python and FastAPI.
This separation lets us evolve the user interface, backend workflows, and AI integration independently while keeping the main application serverless.
[Insert Figure 1: Overall HydroSense system architecture]
[Insert Figure 2: AWS infrastructure architecture]
The first diagram should show the broader system, including data sources, hardware, community reporting, and the dashboard. The second should focus specifically on AWS resources and their connections.
4. Adding real AI image assessment with Amazon Bedrock
One of our most useful additions was image-based assessment for community reports.
A photograph can provide context that a short text description cannot. However, simply allowing someone to attach a photo is not enough; the application also needs to process the image and make the result available with the original report.
We implemented the workflow using Amazon S3, AWS Lambda, and Amazon Bedrock.
The process works as follows:
- A user creates a community report and selects an image.
- The backend generates a presigned upload request scoped to the report.
- The browser uploads the image directly to the private S3 evidence bucket.
- The backend retrieves the image and invokes Amazon Bedrock.
- The response is validated and stored with the report, including its assessment status and model metadata.
- The dashboard displays the resulting advisory.
The browser never needs the bucket's AWS credentials. Upload restrictions and private bucket settings help protect the evidence-storage workflow.
The model-access problem we had to solve
We initially explored using an Anthropic model through Amazon Bedrock. During testing, we encountered an account-level use-case approval requirement that prevented consistent invocation.
Rather than assuming that a model appearing in the catalog was ready to use, we tested actual invocations. We then evaluated Amazon Nova Lite and confirmed that it worked in our AWS environment.
That decision allowed us to complete the image-assessment workflow without depending on an unavailable model entitlement.
Testing the complete path
We did not stop after receiving a successful response from the model.
We created a report, obtained a real presigned upload request, uploaded an actual PNG image, triggered a real Bedrock invocation, and retrieved the persisted assessment through the API.
The completed assessment was confirmed in storage. We also checked backend logs for errors and accidental exposure of image content.
That end-to-end test was an important milestone: it verified that image upload, model invocation, and result persistence worked together rather than only in isolated components.
AI-generated results remain advisory. They are not guaranteed flood predictions or precise measurements of water depth.
5. Making image uploads work reliably
The image workflow also exposed a less obvious cloud-integration issue.
Our first real upload attempt encountered an HTTP 307 redirect from the S3 upload endpoint. The cause was the use of a global S3 endpoint rather than the endpoint for the bucket's AWS Region.
We corrected the S3 client configuration to use the regional endpoint and repeated the upload test successfully.
It was a small configuration detail, but it demonstrated something important: a service can be configured correctly in most respects and still fail at the boundary between two services.
Testing the actual browser-to-S3 path helped us find a problem that unit tests alone would not have revealed.
6. Persisting reports instead of treating them as temporary events
Community reporting only becomes useful if submitted information survives beyond the immediate request.
We provisioned a dedicated DynamoDB reports table and connected it to the existing backend. We then tested report creation, retrieval, input validation, and idempotent handling of repeated submissions.
The broader backend also exposes reading, incident, risk, and dashboard endpoints.
We ran the backend test suite after the changes, with 57 tests passing at that stage, and checked that the existing health and dashboard endpoints continued to respond successfully.
This gave us greater confidence that adding the AI workflow had not broken the core application.
7. The hardware vision
HydroSense also incorporates an Arduino-based water-level sensing concept and gateway connectivity.
The intended system flow is straightforward: a sensor observes water level, a gateway provides connectivity, and readings can eventually contribute to cloud-based monitoring and risk assessment.
However, hardware connectivity and cloud ingestion are separate engineering milestones. Our deployed application has not yet been verified as receiving readings from the physical sensor. We therefore treat the sensor-to-cloud workflow as a next step rather than presenting test-injected readings as live physical telemetry.
That distinction matters because a useful flood-monitoring platform should preserve the origin of its evidence. Historical events, community observations, test inputs, and physical measurements should not be confused with one another.
Our next goal is to complete and validate the physical sensor-to-cloud path so that real readings can be incorporated into the existing application.
8. Four people, different responsibilities
HydroSense was built through collaboration across cloud engineering, hardware, full-stack development, and frontend design.
- Mukul: AWS integration, backend deployment, cloud storage, and Bedrock integration.
- Rasleen: IoT and hardware integration, focusing on Arduino-based water-level sensing and gateway connectivity.
- Monalika: Full-stack development and the historical waterlogging dataset.
- Poojya Rajvanshi: Frontend development across the HydroSense application.
This division of work helped us progress across the hardware and software parts of the project while keeping the user experience connected to the underlying services.
9. What we learned
A successful API call is not an end-to-end feature
The Bedrock integration became meaningful only after we verified the entire path from image selection to S3 upload, model invocation, persisted result, and dashboard display.
Real integration tests reveal problems that local tests miss
The S3 regional-endpoint redirect was a good example. Testing the actual workflow uncovered a service-integration issue that would have been easy to overlook.
Data provenance is part of the product
Risk information is useful only when users can understand where it came from. Historical evidence, community reports, forecasts, test readings, and physical sensor observations have different meanings and should be presented accordingly.
A working deployment is a milestone, not the finish line
We now have a deployed application with underpass risk information, persistent community reports, and genuine AI image assessment. The next stages include validating risk calculations against independent observations, integrating physical sensor readings into the cloud workflow, and improving operational access controls.
10. What's next for HydroSense?
We plan to focus on four areas:
- Complete and verify physical sensor-to-cloud ingestion.
- Expand and evaluate the historical waterlogging dataset.
- Improve authentication, authorization, and operational monitoring.
- Continue testing the platform with real images, reports, and representative underpass scenarios.
Our long-term goal is to make it easier for people to understand potential waterlogging hazards by bringing multiple sources of evidence into one accessible platform.
Try HydroSense
HydroSense is a flood-risk decision-support project. Its risk assessments and AI-generated image advisories are informational and should not be treated as guaranteed predictions or replacements for official emergency guidance.
This article describes our team's development experience and the implementation we tested during the hackathon. Any opinions expressed are those of the authors and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article