Building DHARA: Connecting Water Tank Monitoring with AWS IoT Core, S3 and EC2
DHARA is a water-monitoring and evidence-tracking platform built for hostels, schools and campuses. This article covers how we connected sensor telemetry to AWS IoT Core, stored readings and maintenance evidence in S3, and deployed the application on EC2, including what we learned while testing the complete flow.
Building DHARA: Connecting Water Tank Monitoring with AWS
A water tank being cleaned does not necessarily tell us about its current condition. In many hostels, schools and campuses, maintenance registers, photos and lab reports are kept separately, making it difficult to track what was measured, what action was taken and what still needs attention.
That was the problem we wanted to address with DHARA, an institutional water evidence ledger built as part of Environmental Hacks 2026 by WeMakeDevs × AWS.
DHARA brings water readings, maintenance records and follow-up tasks into one place. We also wanted to connect sensor data to a real cloud backend instead of stopping at a dashboard prototype.
Here is how we built it and what we learned from testing the AWS integration.
What does DHARA do?
DHARA helps technicians and wardens manage water-tank checks and maintenance.
Technicians can record water temperature and free-chlorine readings along with the testing method, sample point and timestamps. The application uses transparent rules to prioritise which tanks need a repeat measurement, a scheduled test or a warden's review.
Maintenance activities can be submitted with photos and documents. Each uploaded file gets a SHA-256 digest that can be checked later for changes. A warden reviews the submission and can accept it, reject it or request more information. The person who submits the work cannot approve their own submission.
We also added follow-up tasks with owners and due dates, along with a public QR page for each tank that shows its status without exposing private information.
One important distinction is that DHARA does not declare water safe to drink. It helps people record measurements, identify issues that need attention and keep track of the response.
The AWS architecture
The cloud integration connects a temperature probe to the application through AWS IoT Core.
The intended flow with a physical device is:
ESP32 + temperature probe → AWS IoT Core → Amazon S3 The same sensor message is also forwarded through HTTPS to the DHARA application running on Amazon EC2, where it is validated, stored and recorded in the application's audit history.
Technicians and wardens access DHARA over HTTPS. Maintenance photos and lab reports remain in private S3 storage, while the public QR page exposes only the tank status information intended for public viewing.
1. AWS IoT Core for sensor communication
AWS IoT Core handles the incoming telemetry. Each device is configured as its own IoT thing with an X.509 certificate and a restricted policy.
The device publishes temperature readings over MQTT/TLS to its permitted topic under
dhara/<thing>/telemetry . This keeps device identity and permissions separate rather than allowing a device to publish wherever it wants.We configured two IoT rules:
-
dhara_archivesends raw telemetry to Amazon S3.
-
dhara_forwardforwards readings to the application's HTTPS ingestion endpoint.
On the application side, DHARA checks the device token, validates the timestamp and reading range, handles duplicate messages and records the accepted data.
This setup gives the application a way to receive sensor readings without having to run its own MQTT broker.
2. Amazon S3 for readings and evidence
We use Amazon S3 for two related purposes: archiving incoming sensor data and storing the evidence attached to maintenance activities.
The IoT archive creates an object for each incoming message under
dhara/iot-raw/ , with the device token excluded. The same private bucket stores maintenance photos and lab reports.We enabled S3 Block Public Access, server-side encryption using SSE-S3 and versioning. Files are made available through short-lived, five-minute presigned URLs after DHARA checks whether the requester is allowed to access them.
We also tested the upload and retrieval process by checking the SHA-256 digest of stored evidence. A direct request to a private object's ordinary URL returned HTTP 403, as expected.
One useful lesson here was that storage security is not just about where a file is saved. Permissions, download links and the application's access checks also matter.
3. Amazon EC2 for the application
We deployed the Django application on an Amazon EC2
t3.micro instance in the ap-south-1 region.The application runs using Docker and Gunicorn, with Caddy handling HTTPS and HTTP-to-HTTPS redirection. We used AWS Systems Manager for administration and deployment instead of opening SSH access to the instance.
IAM roles provide the application's S3 permissions, so long-lived AWS credentials do not need to be stored directly in the application. We also configured IMDSv2 as a requirement for instance metadata access.
For this prototype, the main goal was to get the application running with a working sensor-data pipeline and sensible access controls, while keeping the infrastructure relatively small.
Testing the complete flow
We did not have a physical ESP32 board available before the hackathon deadline, so we used Wokwi to simulate the ESP32 and its firmware. The device side was simulated, but the AWS services beyond it were real.
During our live test on 11 October 2026, the simulated device published temperature telemetry over MQTT/TLS every five seconds. We observed new objects arriving in S3 and the corresponding readings being stored in DHARA's database on EC2.
The test reading was around 34.2 °C. The archive had reached 115 S3 objects during the recorded demonstration.
This was an important checkpoint for us because it tested the connection between the device, IoT Core, storage and application rather than showing each component working in isolation.
A bug we found along the way
One issue came up during testing of S3 presigned URLs. URLs signed for the global S3 endpoint failed when accessing our bucket outside
us-east-1 .The fix was to sign the URLs using the bucket's regional endpoint. After that change, the live storage test could upload files, retrieve them through the expected access flow and verify their digests.
It was a useful reminder that a cloud integration can look correct in code and still fail because of region-specific configuration.
What still needs work?
DHARA is a working prototype, but there are limits we need to address before using it for real water monitoring.
The current sensor demonstration uses Wokwi rather than a physical ESP32 installed in a tank. The system therefore demonstrates the data pipeline, not actual field measurements. SHA-256 can help detect changes to a stored file, but it cannot prove that a photo is genuine or that maintenance physically took place.
Our application audit history is stored in a normal database table, so it is not yet a tamper-proof ledger. S3 Object Lock is also a planned improvement.
The testing-priority rules help decide what should be measured or reviewed next; they do not predict chlorine concentration or certify water safety. The thermal model also needs sufficient real tank readings before it can pass validation.
Our next steps are to test with a physical ESP32, collect readings from a real tank, move from the current demo database setup to Amazon RDS, strengthen evidence retention and try a pilot with a consenting institution.
Final thoughts
Building DHARA gave us a practical way to work with AWS IoT Core, Amazon S3, EC2, IAM and Systems Manager in one application.
The biggest milestone was verifying that sensor messages could travel through IoT Core, reach S3 and appear in the application on EC2. We also learned that permissions, regional endpoints and honest testing limits are just as important as getting the basic pipeline working.
DHARA is a starting point for making water-monitoring and maintenance records easier to manage and review. The next step is to take that working cloud pipeline beyond simulation and test it with real hardware and real-world data.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article