AWS Builder Center

Builder Center

I Built an Emergency Allocation Engine for Heatwaves on AWS: Here’s the Architecture

A heatwave is 48 hours away. You have 20 tankers. I built an AWS engine (Bedrock, S3, App Runner) that decides where they go, and shows its work.

Imran

A heatwave is 48 hours away. You have 20 water tankers and 10 cooling centers. Where do they go first, and can you defend the decision afterward?
That question drove Project Bhumi. Here’s how I built the answer on AWS.
In this post: the problem, the scoring and allocation logic, how Bedrock, S3, App Runner and boto3 fit together, and what I’d do differently.


Why it matters

CEEW’s 2025 study of 734 Indian districts found 57% at high or very high heat risk. It also found that 95% of heat action plans lack a risk assessment. Maps show where risk is. Officials need what to deploy tomorrow.
Bhumi takes that hazard, exposure and vulnerability framework from district maps to block-level, forecast-driven allocation across 56 blocks in Purulia, Bankura and Howrah.

What it does

  • Scores each block with one explainable index. The geometric aggregation means extreme risk in one component can’t be hidden by a low value in another.
  • Allocates tankers and cooling units with a marginal-benefit optimizer. The tenth tanker to one block is worth less than the first to a stressed neighbor, and every run is compared against two baselines.
  • Explains itself. Click any block to see why it ranked where it did. AHP consistency ratio is 0.0079, and Monte Carlo testing (1,000 draws) checks ranking stability.
The research shaped the design. Warm nights are rising faster than hot days, so Bhumi tracks warm-night runs. Humidity matters, so it uses a heat index.

The AWS architecture

  • Amazon Bedrock (Claude 3.5 Sonnet): For any block, it generates emergency directives in English and Bengali, grounded in that block’s real indicators. Field officers get instructions in their own language.
  • Amazon S3: It archives every allocation run as a snapshot, so each decision can be audited later. It also holds the West Bengal GeoJSON boundaries.
  • AWS App Runner: The backend is containerized for serverless deployment, with no servers to manage.
  • boto3: The FastAPI backend uses it to call Bedrock and S3.  /api/v1/aws-status  reports live connectivity.
Lessons learned :
  1. Trust is a feature. Officials won’t act on a black box, so every number carries a lineage badge:  LIVE ,  STATIC ,  PERIODIC  or  MOCK .
  1. Be honest about data. The pilot mixes live, static and placeholder data. The architecture is ready for fuller feeds.
  1. Auditability beats cleverness. Archiving each run in S3 turned out to matter more than any single model choice.
Next: MODIS satellite temperature and real-time tanker GPS.

Over to you

If you’ve built decision-support or disaster-response tools on AWS, how do you handle auditability for AI-generated guidance? I’d like to hear how others approach Bedrock outputs.
🔗 Code:  https://github.com/my-project-repo/HWSI-Heat-Water-Stress-Decision-Support-System  📄 Source: CEEW (2025), How Extreme Heat is Impacting India. Not affiliated with CEEW.
# amazon-bedrock# amazon-s3# aws-app-runner# generative-ai# python
Any opinions in this article are those of the individual author 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