Raहत: Building a Heat and Flood Early-Warning System for Delhi on AWS
How we built Raहत (Rahat, "relief"), a ward-level heat and flood warning platform for Delhi's 290 wards, using Amazon Bedrock, Polly, Rekognition, Translate, Location Service and a one-command deployment on Elastic Beanstalk, RDS and CloudFront.
The problem: warnings that don't tell you what to do
Every summer Delhi crosses 45 °C, and every monsoon its underpasses flood within an hour of heavy rain. The people hit hardest are the ones who work outside: delivery riders, construction workers, street vendors. Today's warnings are city-wide — "heatwave expected", "heavy rain likely". They don't tell a rider in Karol Bagh when to stop, where the nearest water is, or which road to avoid.
So we built Raहत (Rahat — Hindi for relief): live, ward-level heat and flood guidance for all 290 wards of Delhi, in English and Hindi, that reaches the phone in your pocket.
What Raहत does
- Live ward-level conditions — every 15 minutes we pull weather for a 36-point grid over Delhi and blend it to each ward, adjusted for tree cover measured from satellite imagery.
- Safe working hours — hour-by-hour heat stress (WBGT) checked against occupational limits for light, moderate and heavy work: safe, work with breaks, or stop.
- A voice assistant in Hindi and English — "Is it safe to work now?", "रोहिणी में गर्मी कितनी है?", "Take me to the nearest drinking water."
- Flood-aware routes that steer around reported and forecast waterlogging.
- Push alerts, even with the app closed — "Rest now, shade is 300 m away", "Safe to resume", heavy rain ahead, official warnings.
- Citizen reports with photo verification, and a ward-officer console with AI-drafted bilingual alerts and a flood and heat simulator.
- An MCP server, so any AI agent can query the same live data.
How we used AWS
Everything runs on AWS and is created by one script in AWS CloudShell — re-running it updates the app.
Hosting and infrastructure
- AWS Elastic Beanstalk (Docker on Amazon EC2) runs our FastAPI backend and serves the website.
- Amazon RDS for PostgreSQL stores reports, status history, alerts, broadcasts and push subscriptions. It accepts connections only from the web server.
- Amazon S3 keeps report photos private and encrypted; officers see them through short-lived pre-signed links.
- Amazon CloudFront provides HTTPS — essential, because browsers only allow location, microphone and push notifications on secure sites.
Security and operations
- AWS Secrets Manager holds the database password and officer token — nothing secret lives in code.
- AWS IAM gives the server a least-privilege role: only its own photo folder, its own secret and the AI services it uses.
- Amazon CloudWatch Logs streams server logs for monitoring and debugging.
AI services that do real work
- Amazon Bedrock (Claude Haiku 4.5) with tool use. The assistant can call eight tools we wrote over our own live data — conditions, safe hours, nearest water and shade, alerts, forecast, routes, flood what-if and place lookup — so it answers only from real numbers. Bedrock also drafts alerts and 72-hour briefings for ward officers, grounded in the same facts.
- Amazon Polly reads answers aloud in an Indian voice, in English and Hindi — important for outdoor workers who prefer listening to reading.
- Amazon Rekognition checks every report photo. Unsafe images are blocked. Photos that show water are verified and raised in priority — two verified reports close together trigger a flood alert. Photos with no visible water wait for an officer, so fake reports can't reroute the city.
- Amazon Translate sends every officer broadcast in English and Hindi.
- Amazon Location Service plans routes; when every normal route passes flooding, we pass the flooded spots as areas to avoid and get a route around all of them.
AWS Open Data
- ESA WorldCover on the Registry of Open Data on AWS — at deploy time we read 10-metre satellite land cover for Delhi and measure tree, built-up and water cover for every ward. Leafy wards really are cooler, and concrete floods faster; both feed our models.
How a request flows
- A rider opens Raहत; CloudFront serves it over HTTPS from Elastic Beanstalk.
- They ask by voice, "Take me to the nearest drinking water." Bedrock calls our tools, Location Service plans the route, Polly speaks the answer, and the map opens with the route drawn.
- A resident reports a flooded underpass with a photo. Rekognition verifies it, the photo goes to S3 and the report to RDS.
- The ward officer sees it instantly, drafts an alert with Bedrock and broadcasts it in two languages with Translate. Phones in that ward get a push alert.
What we learned
- Grounding matters more than the model. Giving Bedrock tools over our own data, instead of a big prompt, stopped it from guessing temperatures or places.
- HTTPS unlocks the phone. Location, microphone and push only work on secure origins, so CloudFront was essential, not optional.
- Verification should change behaviour. Rekognition became genuinely useful once a verified photo raised priority and an unverified one waited for review.
- One-command deploys save hackathons. An idempotent CloudShell script let us redeploy in minutes after every fix.
Built with
Amazon Bedrock · Amazon Polly · Amazon Rekognition · Amazon Translate · Amazon Location Service · AWS Elastic Beanstalk · Amazon EC2 · Amazon RDS for PostgreSQL · Amazon S3 · Amazon CloudFront · AWS Secrets Manager · AWS IAM · Amazon CloudWatch · Registry of Open Data on AWS (ESA WorldCover) · FastAPI · Open-Meteo · OpenStreetMap · NDMA SACHET
Raहत is a hackathon project. Some figures shown on the site, such as pilot results, are illustrative; the weather, alerts, reports, routes and AI features run on live data.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article