Beyond AQI Dashboards: Building AERIS, an AWS-Powered Environmental Intelligence System
What if an air-quality dashboard could do more than display pollution levels? Explore how I designed AERIS, an environmental decision-support platform for Delhi NCR, combining AWS serverless architecture, multi-horizon forecasting, anomaly detection, policy simulation, and a provenance-aware AI copilot.
Beyond AQI Dashboards: Building AERIS, an AWS-Powered Environmental Intelligence System
Project: AERIS — AI Environmental Response & Intelligence System
Built for: Environmental Hacks
Technology: AWS CDK v2, AWS Lambda, Amazon API Gateway, Amazon DynamoDB, Amazon S3, Amazon EventBridge, AWS IoT Core, Amazon Bedrock, React, and TypeScript
Repository: github.com/ManyaValecha/aeris-environmental-intelligence
Live demo: aeris-environmental-intelligence.vercel.app
The problem: Knowing the AQI is not the same as knowing what to do
Delhi NCR's air pollution problem is often communicated through a single number: the Air Quality Index.
That number matters. But imagine you are an environmental officer looking at a pollution spike near a busy traffic corridor. Knowing that the air is unhealthy answers only the first question.
What caused the spike? Is the atmosphere trapping pollutants? Could conditions worsen over the next few hours? Which intervention might help? How confident should you be in the answer?
These questions require more than a dashboard.
I built AERIS (AI Environmental Response & Intelligence System) around a simple idea: environmental software should help users move from observing a problem to understanding it, exploring possible futures, and evaluating potential interventions.
The project focuses on eight reference monitoring locations across Delhi NCR, including Anand Vihar, ITO, RK Puram, Dwarka, Punjabi Bagh, Bawana, Noida Sector 62, and Gurugram Vikas Sadan.
Rather than treating air pollution as a collection of disconnected readings, AERIS organizes environmental intelligence into four stages:
OBSERVE → UNDERSTAND → PREDICT → INTERVENE
This became the foundation for both the product experience and the underlying cloud architecture.
1. Designing a system, not just a dashboard
The first important decision was to make the product answer four different questions.
- Observe: What are the pollution conditions at each monitoring location?
- Understand: Where are unusual changes occurring, and what atmospheric conditions might contribute?
- Predict: How could pollution evolve across different forecast horizons?
- Intervene: What might happen under hypothetical traffic, construction, or industrial emission controls?
The resulting interface combines a spatial monitoring map, station-level intelligence, an atmospheric digital twin, forecast timelines, a policy sensitivity simulator, and an AI-powered Environmental Copilot.
The atmospheric digital twin visualizes indicators such as wind direction, planetary boundary layer mixing height, and thermal inversion status. These variables help users reason about atmospheric conditions that can influence pollutant dispersion and accumulation.
The goal is not to claim that a visualization perfectly reproduces the atmosphere. It is to make relevant environmental context easier to inspect and interpret.
2. The AWS architecture behind AERIS
I designed the cloud architecture around independently testable components rather than one tightly coupled application.
The frontend uses React 18, TypeScript, and Vite. It is deployed on Vercel, while AWS provides the designed serverless backend, storage, event scheduling, telemetry ingestion, and AI integration.
The architecture follows this flow:
Plain text
Environmental Telemetry|vAWS IoT CoreMQTT Topics|vAWS LambdaValidate and Normalize|vAmazon DynamoDBStation + Timestamp Keys|vAmazon API Gateway|vReact + TypeScript UI|+--------------------+| |v vForecast & Scenario Amazon BedrockIntelligence AI Copilot
Amazon EventBridge provides a scheduled event path for demonstration telemetry. Amazon S3 is designated for private machine-learning artifacts.
This is an architecture designed to keep ingestion, persistence, API access, forecasting, and language-model reasoning logically separate.
An important implementation detail is that infrastructure code, a working local demonstration, and a deployed cloud service are not the same thing. AERIS includes AWS CDK infrastructure definitions and an offline demonstration mode. The live AWS components require valid AWS configuration and deployment; the offline interface does not imply that every screen is receiving live AWS telemetry.
That distinction shaped how I approached reliability and data transparency.
3. Why AWS CDK v2 was a foundational choice
I used AWS Cloud Development Kit (AWS CDK) v2 with TypeScript to define the infrastructure programmatically.
Instead of documenting resources only as a diagram, the repository contains infrastructure code for the AERIS stack.
The intended benefits are practical:
- Reproducibility: Infrastructure definitions can be version-controlled alongside application code.
- Reviewability: Resource configuration and permissions can be inspected before deployment.
- Testability: Infrastructure assertions can check important properties of the generated stack.
- Maintainability: Resource changes can be reviewed as code rather than reconstructed manually in the console.
The infrastructure tests include assertions for expected resources and configuration. CDK synthesis can also generate a CloudFormation template locally, allowing the proposed infrastructure to be inspected before making cloud API calls.
For a project that combines several cloud services, defining the infrastructure as code makes the architecture easier to reason about and evolve.
4. Giving each AWS service a clear responsibility
AWS Lambda: Keep the processing logic focused
AERIS defines Lambda handlers for telemetry ingestion and API requests.
The ingestion path validates incoming records, checks station identifiers and measurement ranges, and preserves provenance metadata before persistence.
The API handler supports operations for retrieving station information, retrieving the latest station telemetry, and submitting telemetry.
Keeping these responsibilities separate makes it easier to test input validation independently of API behavior.
Amazon API Gateway: Establish a clear application boundary
The frontend communicates with the proposed AWS backend through REST endpoints.
API Gateway provides a defined interface between the user-facing application and the serverless processing layer. This separation also allows the frontend to operate against a different data provider during local development.
Amazon DynamoDB: Model telemetry around stations and time
Environmental monitoring is naturally time-oriented. A reading belongs to a location and a particular timestamp.
AERIS uses a station-and-timestamp key design:
Plain text
Partition key: STATION#{stationId}Sort key: TIMESTAMP#{isoTimestamp}
This model organizes readings around individual stations and provides a basis for retrieving and analyzing their time series.
The infrastructure also defines server-side encryption and point-in-time recovery settings.
Amazon S3: Separate model artifacts from application telemetry
Model artifacts have different access patterns from individual station readings. AERIS therefore designates S3 as a separate location for machine-learning artifacts.
The bucket configuration includes blocked public access, encryption, enforced SSL, and lifecycle management.
This follows a useful architectural principle: data should be stored according to its access pattern, with security controls appropriate to its purpose.
Amazon EventBridge: Support scheduled ingestion
AERIS includes an EventBridge schedule for periodically triggering demonstration telemetry ingestion.
Scheduled events provide a straightforward way to exercise a data pipeline without requiring physical sensors to be connected during every development session.
In the demo path, generated readings remain explicitly labeled as simulated. A scheduled event does not turn generated data into real-world measurements.
AWS IoT Core: Prepare for telemetry ingestion
AWS IoT Core is included in the architecture for MQTT-based station telemetry.
This creates a path toward connecting data-producing devices through a managed IoT messaging service. A real deployment would still require configured devices or data publishers, appropriate certificates and policies, topic rules, and an exercised end-to-end connection.
This separation lets the system's ingestion contract be designed before physical sensor integration is completed.
5. The most important design decision: Make data provenance visible
Environmental software can become misleading when measurements, forecasts, simulations, and generated explanations look identical.
For example, a simulated pollution spike displayed as an actual sensor reading could cause a user to draw the wrong conclusion.
I addressed this problem by designing a six-category provenance system.
Label | Meaning |
|---|---|
MEASURED | Direct instrument observations |
REANALYSIS | Meteorological reanalysis data |
SIMULATED | Generated demonstration or scheduled demo data |
PREDICTED | Machine-learning forecast output |
ESTIMATED | Hypothetical intervention scenario results |
AI-GENERATED | Natural-language content produced by an AI model |
These labels are not merely decorative badges. They are part of the application's data-handling contract.
The ingestion logic preserves the
SIMULATED label rather than silently converting a generated record into a measurement. Tests exercise the validation and provenance safeguards.This matters because different data categories carry different levels of evidence.
A prediction is not an observation. A scenario is not proof of a policy's real-world causal impact. An AI-generated explanation is not a sensor reading.
My central design principle was to make the origin of information visible wherever that information influences a decision.
6. Forecasting and anomaly detection: Separate observation from inference
AERIS combines statistical anomaly detection with forecasting across multiple time horizons.
Detecting unusual readings
The anomaly service uses Median Absolute Deviation (MAD), a robust statistical technique for identifying observations that differ substantially from a series' typical behavior.
Unlike methods that rely only on the mean and standard deviation, MAD is less sensitive to extreme observations when estimating the center and spread of a dataset.
The intention is to help users identify unusual station readings and investigate them alongside historical patterns.
An anomaly is a signal for investigation, not automatically proof of a particular pollution source.
Exploring multiple forecast horizons
The forecasting layer separates the current-state view from future estimates.
The project includes XGBoost, LSTM, and Prophet forecasting approaches for different horizons. The interface distinguishes present conditions from future predictions and displays uncertainty information based on the forecast service's configured error estimates.
The engineering challenge is not simply producing a future number. It is ensuring that the user understands that a future estimate is uncertain and model-dependent.
A production evaluation should validate each model against held-out observations, report metrics such as MAE and RMSE, compare against a simple baseline, and test performance across stations and changing seasonal conditions.
A model's reported score alone does not establish that it will generalize to every location or pollution episode.
7. From forecasting to intervention: The policy sensitivity simulator
This is the part of AERIS that most clearly separates it from a conventional air-quality dashboard.
Users can explore hypothetical controls in three categories:
- Traffic combustion reduction
- Construction dust suppression
- Industrial and waste-burning curbs
The simulator estimates how different intervention assumptions might affect PM2.5 concentrations and AQI categories.
Its outputs are explicitly labeled
ESTIMATED .Why does this distinction matter?
A scenario calculator based on assumed source contributions is not the same as a validated causal model. Real atmospheric responses depend on factors such as weather, secondary aerosol formation, transport from surrounding regions, and the timing and enforcement of interventions.
AERIS therefore presents the simulator as a sensitivity-analysis tool rather than a guarantee of real-world pollution reduction.
The objective is to support structured exploration: users can compare assumptions and discuss possible responses without confusing hypothetical outputs with observed outcomes.
8. Amazon Bedrock: Make environmental intelligence easier to understand
Environmental data is not always accessible to everyone who needs to use it.
A technical user may want details about pollutant behavior and forecast uncertainty. A citizen may simply want to understand what a pollution warning means.
AERIS includes an Environmental Copilot integration designed around Amazon Bedrock and Claude models.
The copilot has two intended modes:
- Citizen mode: Explain environmental conditions in accessible language.
- Authority mode: Produce more technical, action-oriented briefings.
The context-building layer is designed to provide the assistant with validated application information. The prompt and response-handling logic are intended to prevent the model from inventing numerical measurements or presenting AI-generated content as ground truth.
The key architectural decision is to keep numerical analysis separate from language generation.
Forecast services calculate forecast values. The scenario service calculates intervention estimates. Bedrock is intended to explain the resulting context in natural language rather than act as the numerical forecasting engine.
A real deployment must still test grounding behavior, handle model errors, verify regional model availability, and configure the required IAM permissions and model access.
9. Security and resilience are part of the product
I wanted the architecture to account for more than its successful demonstration path.
The repository includes several security-oriented design decisions:
- Least-privilege IAM: Scope service permissions to the operations and resources they require.
- Private S3 storage: Block public access and configure encryption.
- DynamoDB protection: Configure server-side encryption and point-in-time recovery.
- Input validation: Check station identifiers, timestamps, and measurement ranges.
- CORS configuration: Define API access rules instead of relying on an unrestricted wildcard.
- Client-side secret checks: Test that credentials are not exposed in the frontend bundle.
- Offline fallback: Keep the application usable without AWS credentials.
The offline fallback was particularly useful during development and demonstrations.
AERIS separates its data-provider interface from its AWS-backed provider and demo provider. This means the dashboard can continue demonstrating its workflows even when the cloud backend is not configured.
The trade-off is that a functional offline demo must not be mistaken for proof that the live AWS data pipeline is operating. The application therefore needs clear provenance labels and explicit deployment verification.
10. Testing the system, not just the interface
A polished interface is only one part of a dependable engineering project.
The repository reports 117 passing tests, covering multiple parts of the application and infrastructure.
The test suite includes checks for:
- AQI calculations and health-message categorization
- Provenance preservation
- Telemetry ingestion validation
- Intervention scenario calculations
- Forecast-horizon dispatch and uncertainty handling
- Anomaly detection
- Digital twin calculations
- Bedrock response-grounding safeguards
- AWS provider fallback behavior
- CDK infrastructure assertions
- Client-bundle security checks
The project also provides commands for running tests, checking TypeScript types, and building the production frontend.
Plain text
npm installnpm testnpm run typechecknpm run build
For the infrastructure:
Plain text
cd infranpm installnpx cdk synth
CDK synthesis is useful for reviewing the generated infrastructure template. It should not be confused with deploying resources or verifying live service-to-service communication.
The next step toward production readiness is end-to-end validation against a deployed AWS environment, using verified data sources and monitoring the resulting pipeline.
11. What I learned building AERIS
Three lessons stood out.
First, cloud architecture should reflect the actual problem. The separation between ingestion, persistence, API access, forecasting, simulation, and language generation made the system easier to understand and test.
Second, trust is a product feature. Provenance labels, uncertainty information, input validation, and explicit simulation boundaries are not secondary details. They determine whether users can interpret the output responsibly.
Third, an AI application needs a fallback strategy. Keeping the interface functional in offline mode made development more flexible while clarifying the difference between a demonstration and a live cloud deployment.
There is also an important limitation: an environmental decision-support tool cannot replace official monitoring, validated forecasting services, or expert assessment. Its usefulness depends on data quality, model validation, transparent assumptions, and careful evaluation in real operating conditions.
12. What's next?
The next development milestones are to validate the complete AWS deployment end to end, connect verified environmental telemetry sources, exercise the IoT ingestion path, evaluate forecasting models on held-out observations, and measure the reliability and cost of the Bedrock copilot.
I also want to evaluate whether the intervention simulator's assumptions remain useful across different stations, weather conditions, and pollution episodes.
Ultimately, the measure of success should not be how many services appear in an architecture diagram. It should be whether the system produces useful, transparent, and dependable information when people need to make decisions.
Final thoughts
AERIS started with a simple question: what if air-quality software could help people reason about possible responses, instead of only reporting the current situation?
AWS provides the building blocks for that approach: serverless processing with Lambda, API boundaries through API Gateway, telemetry storage in DynamoDB, artifact storage in S3, scheduled events through EventBridge, an infrastructure-as-code workflow with CDK, and a managed foundation-model interface through Amazon Bedrock.
The real engineering challenge is connecting those components while preserving the meaning, limitations, and origin of the information they produce.
Because air quality isn't just a number. It's a decision.
Explore AERIS
- AWS CDK documentation: https://docs.aws.amazon.com/cdk/v2/guide/home.html
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article