Building FloodGuard: An Environmental Monitoring Dashboard Using AWS Serverless Services
Discover how I built FloodGuard, an AWS-powered environmental hazard monitoring dashboard, using Amazon S3, AWS Lambda, and Amazon API Gateway. In this article, I explain the problem, cloud architecture, weather-data integration, development challenges, and lessons learned while building a prototype to make environmental information easier to explore.
Building FloodGuard: From an Environmental Problem to an AWS Serverless Application
Introduction: Why I Built FloodGuard
Heatwaves, floods, droughts, and water shortages are environmental challenges that affect communities around the world. In Tamil Nadu, changing weather conditions and seasonal rainfall make accessible environmental information particularly valuable.
I wanted to explore a question:
Can cloud computing make environmental information easier to access through one simple dashboard?
That question inspired me to build FloodGuard: an AWS-powered environmental hazard monitoring dashboard.
I developed FloodGuard as an individual project for Environmental Hacks 2026. My goal was to go beyond a static webpage and build a deployed application connecting a frontend, a serverless backend, an API, and an external weather-data source.
This project gave me an opportunity to apply my interest in AWS, cybersecurity, and cloud computing to an environmental problem.
It also helped me understand an important lesson: building an application is not just about making it work. It is about understanding the data, designing the architecture, considering security, and being honest about the application's limitations.
1. The Problem: Environmental Information Is Not Always Easy to Explore
People may need environmental information for different reasons.
- Students may want to explore weather conditions in their cities.
- Residents may want to understand local weather before travelling.
- Communities may benefit from accessible environmental information.
- Developers may want a starting point for building environmental monitoring applications.
Information about weather and environmental conditions can come from different sources. Bringing selected information together in one interface can make it easier to explore.
This is the problem FloodGuard aims to address.
However, displaying weather information is not the same as predicting a flood or solving a water shortage. A reliable environmental warning system requires trustworthy data sources, appropriate monitoring, careful validation, and clear communication.
I therefore designed FloodGuard as an environmental information prototype—not as a replacement for official emergency alerts or a fully operational disaster-warning system.
2. Introducing FloodGuard
FloodGuard brings seven environmental hazard categories together in one dashboard:
1. Heatwaves
2. Floods
3. Monsoon waterlogging
4. Droughts
5. Water tankers
6. Water leaks
7. Groundwater
The dashboard also presents weather-model information for three cities in Tamil Nadu:
- Trichy
- Thanjavur
- Salem
The weather information includes:
- Temperature
- Humidity
- Precipitation
- Wind speed
I designed the interface to work on desktop and mobile devices, allowing users to explore the available information across different screen sizes.
An important distinction is that these seven categories do not all have verified live monitoring feeds. Some currently provide informational content. Verified live water-level measurements, comprehensive environmental sensor data, and official emergency alerts have not yet been integrated.
I consider this transparency essential. An environmental application should explain what its data represents and what users should not conclude from it.
[Insert Image 1: Screenshot of the FloodGuard dashboard showing the city weather information and hazard categories.]
Figure 1: FloodGuard's dashboard for exploring selected weather information and environmental hazard categories.
3. Technology Stack
I built FloodGuard using web technologies, Python, AWS services, and an external weather-data source.
Frontend
- HTML structures the webpage.
- CSS controls the layout and visual presentation.
- JavaScript handles frontend interactions and communicates with the backend API.
Backend
- Python implements the backend logic in AWS Lambda.
AWS services
- Amazon Simple Storage Service (Amazon S3)
- AWS Lambda
- Amazon API Gateway
External data source
- Open-Meteo weather data
Each component has a specific responsibility. The frontend presents information, API Gateway provides the API entry point, Lambda runs the backend code, and S3 hosts the static website files.
This separation helped me understand how individual components can work together to form a cloud application.
4. Understanding the AWS Architecture
One of my main goals was to understand how AWS services connect in a real application rather than learning about each service independently.
FloodGuard uses three primary AWS services.
4.1 Amazon S3: Hosting the Frontend
I used Amazon S3 to host the static website files, including HTML, CSS, and JavaScript.
Amazon S3 provides object storage, which can also be used to host static websites through its website-hosting functionality.
For this prototype, I configured an S3 website endpoint to serve the dashboard.
This gave me practical experience with cloud-based website deployment. I also learned that successful hosting depends on more than uploading files: access settings, hosting configuration, and connectivity with other application components must work together.
The current S3 website endpoint uses HTTP. For a production deployment, I would move towards an HTTPS-based architecture and review the hosting and access configuration carefully.
4.2 Amazon API Gateway: Connecting the Application
The frontend needs a way to send requests to the backend and receive responses.
I used Amazon API Gateway to expose the API endpoint that connects the frontend to the backend integration.
When a user requests weather information, the frontend sends a request to the configured endpoint. API Gateway routes the request to the backend, and the resulting response is returned to the frontend.
This helped me understand how an API can connect application components without placing all backend logic inside the browser.
4.3 AWS Lambda: Serverless Backend Processing
I used AWS Lambda to execute my Python backend code without maintaining a dedicated application server.
The function retrieves and processes weather-model information from Open-Meteo and returns the result through the API integration.
This allowed me to focus on application logic and service integration rather than managing the underlying server infrastructure.
Lambda introduced me to the serverless computing model, where code runs in response to events or requests while AWS manages the underlying execution environment.
Serverless does not mean that infrastructure disappears. Permissions, configuration, monitoring, error handling, and service limits still need attention.
[Insert Image 2: Architecture diagram showing the browser, Amazon S3, Amazon API Gateway, AWS Lambda, and Open-Meteo.]
Figure 2: High-level FloodGuard architecture. The frontend is hosted on S3, while API Gateway connects requests to the Lambda backend, which retrieves weather data from Open-Meteo.
5. How a Request Travels Through FloodGuard
Understanding the request flow was one of the most useful parts of this project.
The simplified application flow is:
User's browser → Amazon S3 → Frontend JavaScript → Amazon API Gateway → AWS Lambda → Open-Meteo
The response then travels back through the API to the frontend.
Here is how the process works.
Step 1: The user opens FloodGuard
The user visits the deployed website in a browser.
Step 2: Amazon S3 serves the frontend
The browser loads the website's HTML, CSS, and JavaScript files from the S3 website endpoint.
Step 3: The frontend requests weather information
The JavaScript application sends a request to the configured API Gateway endpoint.
Step 4: AWS Lambda processes the request
API Gateway invokes the configured Python backend. The Lambda function retrieves and processes the requested weather-model information from Open-Meteo.
Step 5: The API returns a response
The backend response travels through API Gateway to the frontend.
Step 6: The dashboard displays the available information
JavaScript uses the response to display the relevant weather information in the interface.
This flow helped me understand the complete request lifecycle rather than treating the frontend, API, and backend as separate exercises.
It also highlighted the importance of testing each component and checking how the components behave when an external dependency is unavailable.
6. Challenges and Lessons Learned
Building FloodGuard helped me understand that integrating cloud services requires a different kind of problem-solving from studying individual services.
Challenge 1: Connecting the Frontend and Backend
A webpage can load successfully even when its API integration is not working correctly.
The frontend, API Gateway, and Lambda function have different responsibilities. A problem in any part of the request flow can affect the user experience.
My lesson: Troubleshooting should follow the complete request path. Instead of assuming the problem belongs to one service, examine the frontend request, API configuration, backend execution, and response.
Challenge 2: Understanding Weather Data
Weather-model information can help people explore environmental conditions, but it does not automatically provide verified local flood levels or official emergency warnings.
This distinction is especially important when an application concerns public safety.
My lesson: Understanding the source, freshness, limitations, and meaning of data is just as important as presenting it through an attractive interface.
Challenge 3: Working Within a Limited Scope
As a solo developer, I had to concentrate on a manageable set of technologies and build a working prototype.
I focused on the dashboard, backend integration, AWS deployment, and demonstration instead of attempting to build a complete environmental monitoring network.
My lesson: A clearly scoped application with a working core is a better foundation for improvement than a large collection of unfinished features.
Challenge 4: Thinking Beyond Deployment
Deploying an application does not automatically make it secure, reliable, or ready for production.
A production version of FloodGuard would need a more thorough review of permissions, API protections, error handling, monitoring, and data quality.
My lesson: Cloud architecture must consider security and reliability alongside functionality.
7. Cloud Security Considerations
As a cybersecurity student interested in becoming a cloud security engineer, I also considered how FloodGuard could be strengthened from a security perspective.
These are areas for review and future improvement, not claims that every control is already implemented.
7.1 Identity and Access Management
AWS Identity and Access Management (IAM) controls access to AWS resources.
For FloodGuard, I would review the permissions used by the deployment process and Lambda execution role, applying the principle of least privilege wherever possible.
Each component should have only the permissions it needs to perform its job.
7.2 API Protection
An API exposed to users needs appropriate protection against misuse and unexpected traffic.
For a more mature version of FloodGuard, I would evaluate request validation, suitable throttling, monitoring, and any access controls appropriate to the intended use.
The exact controls would depend on whether the API remains a public weather-information endpoint or later supports features such as user accounts or community reports.
7.3 Monitoring and Logging
Monitoring helps developers understand how an application behaves and investigate failures.
I would use appropriate AWS monitoring and logging capabilities to review Lambda execution, identify errors, and investigate API-related problems.
For example, AWS Lambda logs can help developers understand backend failures, while API-level monitoring can help identify patterns in requests and errors.
Logs should be configured thoughtfully so that they do not unnecessarily expose sensitive information.
7.4 Secure Website Hosting
The current prototype uses an S3 static website endpoint over HTTP.
For a production deployment, I would consider a hosting architecture that supports HTTPS, such as Amazon CloudFront in front of an appropriately configured S3 origin.
I would also review bucket policies, public-access settings, and the deployment approach to avoid granting broader access than necessary.
7.5 Data Reliability
Security alone cannot make inaccurate data reliable.
FloodGuard should clearly identify its data sources, explain relevant limitations, and handle unavailable or outdated information carefully.
This is particularly important for environmental applications, where misunderstanding a displayed value could affect someone's decisions.
8. What I Would Improve Next
FloodGuard is a starting point, and I see several ways to improve it.
Integrate Verified Environmental Measurements
I would investigate trustworthy sources for local river levels, rainfall observations, groundwater measurements, and other relevant environmental data.
Where suitable sources are available, I would display their origin, update time, coverage, and limitations.
Distinguish Weather Information from Official Warnings
The interface could more clearly separate weather-model information, measured environmental conditions, and warnings issued by authorized agencies.
This would help users understand the difference between general information and an official alert.
Improve Error Handling
The application could provide clearer messages when the API or external data source is unavailable.
I would also investigate sensible timeout handling and fallback behaviour so that users are not shown misleading information when a request fails.
Strengthen Security and Monitoring
I would review IAM permissions, API protections, HTTPS hosting, monitoring, logging, and the deployment architecture.
I would also test how the application behaves under unexpected requests and external-service failures.
Evaluate Real-World Usefulness
I would seek feedback from potential users to understand which environmental information is most useful and what additional features would make the dashboard easier to use.
The goal is not simply to add more features. It is to make the application more trustworthy, useful, and maintainable.
9. What I Learned from Building FloodGuard
This project helped me gain practical experience with several cloud and software engineering concepts:
- Hosting a static website using Amazon S3.
- Running Python backend code with AWS Lambda.
- Connecting frontend and backend components through Amazon API Gateway.
- Integrating an external weather-data source.
- Understanding serverless application architecture.
- Deploying and testing a web application.
- Recognizing the limitations of model-based environmental information.
- Identifying opportunities to improve cloud security and reliability.
It also changed how I think about cloud development.
Learning a service's features is useful, but integrating services into a functioning application teaches a different set of skills. I had to consider the relationships between components, the journey of a request, the meaning of the returned data, and the work required to improve the system.
For someone pursuing cloud security, this is an important lesson: understanding how applications are built makes it easier to identify where permissions, configurations, data flows, and operational controls need attention.
10. Explore FloodGuard
I have made the project available so others can explore the dashboard and review the implementation.
The live dashboard demonstrates the deployed prototype, while the repository provides access to the project source code.
I welcome feedback and suggestions that could help make FloodGuard more useful and technically robust.
Conclusion: Turning an Environmental Idea into a Cloud Application
FloodGuard began with a simple idea: make selected environmental information easier to explore through one dashboard.
By combining Amazon S3, AWS Lambda, and Amazon API Gateway, I built a deployed prototype that connects a web interface to a Python backend and an external weather-data source.
The project gave me practical experience with cloud deployment, service integration, serverless architecture, and the importance of considering security and data reliability from the beginning.
FloodGuard is not yet a complete environmental early-warning system. Its next stage depends on integrating verified environmental measurements, improving error handling, strengthening security, and making the information more useful to people.
For me, the most valuable outcome was learning how to turn an environmental problem into a working cloud application—and identifying the engineering work still needed to improve it.
I look forward to continuing to develop FloodGuard while expanding my skills in AWS, cybersecurity, and cloud security engineering.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article