From Air Pollution Data to Early Action: Building AIR on AWS
Explore how AIR, an air-quality early-warning prototype, uses AWS Amplify, AWS Lambda, and Amazon DynamoDB to demonstrate environmental risk scenarios and alert workflows. Learn how its serverless architecture, scenario-based testing, and reliability checks create a foundation for more actionable environmental information.
An environmental warning is useful only when it helps people understand what is happening, what might happen next, and what they should do. AIR explores the engineering behind that transition.
The problem is not only polluted air. It is delayed action.
Air pollution is often discussed through numbers: AQI readings, particulate concentrations, pollution charts, and daily reports. These measurements matter, but there is another question worth asking:
How can an environmental risk signal become a clear, traceable, and actionable warning?
For a student, a parent deciding whether outdoor activity is appropriate, or a school administrator planning the day, environmental information becomes more useful when it is presented in a way that supports a decision.
The challenge is not simply displaying a number. An early-warning system must also consider changing conditions, increasing risk, missing or conflicting information, recovery, and whether an alert has progressed through the intended workflow.
That was the engineering question behind AIR — Air-quality Intelligence and Early-warning.
Rather than claiming to solve air pollution itself, AIR focuses on a smaller but important part of the problem: demonstrating how environmental-risk scenarios can be evaluated and how alert workflows can be managed, tested, and traced.
The result is a working prototype deployed on AWS, with a web dashboard, backend processing, persistent storage, and predefined scenarios for exploring different risk conditions.
Why build a prototype around scenarios?
An early-warning workflow cannot be evaluated only under ideal conditions.
What happens when risk increases gradually? What if a severe condition appears suddenly? What if incoming information is missing or contradictory? What if a situation improves and then deteriorates again?
These are different engineering situations, and each can expose weaknesses in a system's decision-making and alert lifecycle.
AIR uses predefined scenarios to explore these cases without depending on a live pollution-monitoring feed during development.
The prototype includes scenarios representing:
- Normal conditions and gradual changes.
- Sudden severe conditions and escalation.
- Persistent risk.
- Missing or conflicting information.
- Recovery and subsequent re-escalation.
This approach makes the workflow repeatable. Instead of waiting for a real environmental event to test the application, I can examine how the system responds to controlled inputs and investigate whether the resulting state and alert history match the expected behavior.
The distinction is important: these scenarios test the prototype's logic. They are not measurements of actual air quality, predictions validated against field data, or evidence of a reduction in pollution exposure.
The architecture: separating the interface, decision workflow, and storage
The main architectural goal was to build a demonstrable end-to-end application without introducing unnecessary infrastructure for a hackathon prototype.
AIR uses a web frontend hosted through AWS Amplify, a serverless backend implemented with AWS Lambda, and Amazon DynamoDB for persistent application data. AWS services provide the hosting, execution, storage, and operational foundations needed to run the prototype.
Architecture at a glance
User → Web dashboard → Lambda backend → DynamoDB
Supporting services include AWS Amplify for frontend hosting, AWS Identity and Access Management (IAM) for permissions, and Amazon CloudWatch for logging and monitoring.
The architecture keeps the user-facing application separate from the backend workflow and the persistence layer. This makes each part easier to inspect and evolve independently.
1. AWS Amplify: making the application accessible
The frontend is hosted using AWS Amplify. It provides the browser-accessible interface through which a user can inspect the prototype's status, scenarios, alerts, and related information.
This separation matters because users should not need to understand the backend implementation just to interact with an application. The dashboard is the entry point; the underlying services support its operation.
For the hackathon, deploying the frontend also made it possible to demonstrate the application through a shareable URL instead of relying exclusively on a local development environment.
2. AWS Lambda: executing the backend workflow
AWS Lambda runs the backend logic without requiring me to maintain a continuously running application server.
The backend receives supported requests, invokes the application workflow, and returns responses to the frontend. The implemented routes support operations such as inspecting status, events, alerts, history, available scenarios, and alert traces. The prototype also includes operator-authorized workflow operations.
The application logic is organized around components for risk evaluation, events, alerts, delivery simulation, validation, and storage. This separation helps keep individual responsibilities understandable instead of placing the entire application in one large handler.
Lambda was a practical fit for this project because the prototype is request-driven and has a limited, well-defined set of operations.
However, serverless execution does not automatically make an application secure or reliable. Those qualities still depend on authorization, permissions, error handling, testing, and operational configuration.
3. Amazon DynamoDB: preserving application state
A warning workflow needs more than a screen that changes temporarily. It needs a way to retain relevant application state and retrieve it later.
AIR uses Amazon DynamoDB as its persistent storage layer. The deployed application uses a table named
air-data , with pk as the partition key and sk as the sort key.The storage abstraction also allows the application to run with an in-memory store during local testing. This makes it possible to test application behavior without requiring every test to depend on a deployed database.
The important architectural decision is separating storage operations from the higher-level workflow. That creates a clearer boundary between the logic that manages an alert and the mechanism that stores its data.
DynamoDB provides the persistence foundation, but persistence alone does not establish that every state transition is correct. That must be tested separately.
4. IAM: permissions rather than unrestricted access
AWS Identity and Access Management (IAM) controls which AWS resources the backend can access.
The Lambda execution role is configured to provide the application with the required DynamoDB access and basic execution permissions. Keeping permissions scoped to the resources the application needs is an important security practice, even in a small prototype.
The application also distinguishes between read operations and operator-authorized write operations. This is a prototype-level control, not a replacement for production identity management.
In particular, the current demo exposes a public Lambda Function URL for its supported read operations, while protected write operations use an operator token. This is a deliberate implementation detail to document, not a claim that the application is ready for unrestricted production use.
A production deployment would require stronger identity and authorization controls, careful secret management, request protection, and a security review.
5. Amazon CloudWatch: operational visibility
Amazon CloudWatch supports logging and monitoring for the deployed backend.
For a system that may eventually support time-sensitive warnings, operational visibility is important. Developers need ways to investigate execution errors and understand what happens when a request fails.
CloudWatch is part of the operational foundation, rather than the service responsible for deciding whether an environmental condition is dangerous.
That distinction keeps the architecture's responsibilities clear: application logic evaluates the workflow, storage retains data, and operational tools help investigate the running system.
How a request moves through AIR
The high-level request flow is straightforward:
- A user opens the dashboard hosted through AWS Amplify.
- The frontend requests information from the backend.
- AWS Lambda executes the corresponding application logic.
- The application retrieves or updates data through its storage layer, using DynamoDB for persistent deployment.
- The backend returns the result to the frontend.
- Operational logs can help investigate backend execution and failures.
The scenario workflow adds another dimension. A predefined scenario supplies controlled conditions; the application evaluates the resulting state and manages the corresponding event and alert workflow.
This separation makes it easier to test the application independently of its presentation layer. It also gives the project a foundation for integrating real environmental data in a future version.
Reliability begins with testing the uncomfortable cases
A demo that works once is not enough to establish that an alert workflow behaves correctly under changing conditions.
I therefore tested the prototype against eight predefined scenarios:
-
A_normal
-
B_gradual
-
C_sudden_severe
-
C2_escalation
-
D_persistent
-
E_missing_conflicting
-
F_recovery
-
F2_reescalation
The test suite also checks workflow authorization, fallback behavior when an AI-related operation fails, simulated delivery, idempotency, and audit handling.
I ran the local test suite and received passing results. I also ran storage-parity checks using a fake DynamoDB client to compare selected scenario behavior between the in-memory and DynamoDB storage implementations.
These tests help answer practical engineering questions:
- Does the workflow handle more than the normal case?
- Can it represent escalation and recovery?
- Does a failure in a supporting operation have a defined fallback?
- Can the application be tested without requiring a live database for every test?
- Are important workflow behaviors checked rather than assumed?
There is an important limit to what these results establish. Passing local tests does not prove that every deployed AWS interaction, security control, or end-to-end behavior has been independently verified. Those require separate deployed integration and security tests.
For me, that distinction is part of responsible engineering: test results should describe what was tested, not what I hope the system will eventually achieve.
What AIR can do today — and what it cannot
AIR is a working prototype for exploring environmental-risk scenarios and alert-management workflows.
Its current implementation demonstrates a deployed dashboard, backend request handling, persistent storage, predefined scenario testing, and supporting operational infrastructure.
It does not yet provide live air-quality measurements, validated pollution forecasts, or a production-grade public notification service. Delivery behavior in the current prototype is simulated. It should not be used as an official source of environmental or emergency guidance.
Being explicit about these limitations is essential. An early-warning application ultimately concerns people's decisions, so an attractive interface cannot substitute for trustworthy data, validated risk logic, dependable delivery, and clear accountability.
What would make the next version more useful?
The next stage would focus on turning the prototype into a more evidence-based environmental application.
First, integrate trusted environmental data. The system would need a reliable source of air-quality measurements, timestamps, geographic coverage, and clear handling for stale or unavailable observations.
Second, validate risk rules. Thresholds and escalation policies should be grounded in authoritative guidance and evaluated against real historical data before they are used to inform public decisions.
Third, make warnings understandable. The interface should explain what a warning means, which area it concerns, how recent the information is, and what practical actions a user can consider. Regional-language content could make this information more accessible.
Fourth, build dependable notification delivery. Real notifications would require appropriate delivery channels, retry and failure handling, monitoring, and a clear distinction between a message being generated and a message actually reaching its intended recipient.
Finally, strengthen production security and operations. This would include stronger authentication, appropriately scoped permissions, protection against abusive requests, cost monitoring, and testing of the complete deployed workflow.
These improvements would need their own engineering, validation, and field evaluation. They are future directions, not features claimed as complete today.
Building AIR also changed how I think about cloud architecture
As an ECE student learning cloud computing, I approached this project as an opportunity to move beyond learning individual AWS services and build a system in which those services have distinct responsibilities.
Amplify provides the user-facing deployment. Lambda executes the backend workflow. DynamoDB provides persistent storage. IAM defines resource permissions. CloudWatch supports operational visibility.
The value is not simply that the project uses several AWS services. It is that each service has a purpose within the system, and the boundaries between them make the application easier to test and improve.
Working on AIR also reinforced a lesson about scope. A broad environmental problem can invite an ambitious solution, but a smaller working implementation is more useful when its behavior can be demonstrated, its limitations can be explained, and its next engineering steps are clear.
Conclusion: a foundation for more actionable environmental information
Air pollution is a real environmental challenge, but solving it requires more than a dashboard or an alert button. It requires trustworthy measurements, understandable risk communication, dependable delivery, and systems that behave predictably when conditions change.
AIR does not claim to have completed that journey. It demonstrates an initial engineering foundation: a deployed AWS application for exploring risk scenarios, managing alert workflows, and testing important behaviors.
The larger goal is to make environmental information easier to turn into informed action. Reaching that goal will require better data, validated decision rules, accessible communication, and reliable delivery.
For now, AIR is a working step toward that direction—and a reminder that responsible environmental technology begins not with the biggest claim, but with a clear problem, a testable implementation, and an honest account of what remains to be built.
Project links
- Live dashboard: https://main.d8gw55mpqyaru.amplifyapp.com
- GitHub repository: https://github.com/keerthi01228/air-quality-intelligence
- Demo video: https://youtu.be/MwDhDxkbhB8
# aws-lambda# aws-amplify# amazon-dynamodb# aws-serverless-application-repository# amazon-api-gateway
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