The screen says:
AQI: 160.
That sounds bad.
But then what?
Can I go for a run?
Should someone with asthma avoid going outside?
Is the smoke visible two streets away connected to the spike?
Did anyone else report it?
Is this just one noisy sensor, or is something actually happening?
The number exists.
The context does not.
That gap is what pushed us to build TERRA (Terra-Globe).
TERRA is an interactive 3D environmental digital twin that combines environmental telemetry, health-oriented context, community reporting, anomaly detection, and event-driven alerts.
But somewhere between rendering our first Earth and deploying our AWS backend, the project stopped being about making environmental data look better.
It became about making environmental data do something.
We Did Not Want Another AQI Dashboard
There are already plenty of dashboards that can tell you:
text
PM2.5: 55 µg/m³AQI: 160Temperature: 34°C
The problem is not necessarily that the data is unavailable.
The problem is the distance between a measurement and a decision.
So instead of starting with charts, we started with Earth.
TERRA renders environmental conditions on an interactive globe using React, Three.js, and WebGL. Pollution layers, aerosol patterns, and city-level observations become spatial rather than rows in a table.
The TERRA interface turns environmental telemetry into an interactive planetary experience instead of another table of readings.
But the globe is only the visible layer.
Behind it, we wanted three things to happen:
- Translate measurements into understandable environmental and exposure context.
- Detect when something unusual is happening.
- Give communities a way to attach human evidence to machine observations.
That changed the architecture completely.
Four Days to Build Something the Planet Actually Needs
We built TERRA for Environmental Hacks, part of the Bharat Builds Tour by WeMakeDevs in collaboration with AWS Builder Center.
The challenge focused on environmental problems we already experience around us: pollution, heat, waste, water shortages, and other climate-related issues.
What I liked most about the challenge was that it did not begin with:
Build something using AWS service X.
It began with the problem.
That sounds small, but it influenced nearly every technical decision we made.
The experience also connected builders with the broader developer ecosystem, including Kunal Kushwaha, Saiyam Pathak, Piyush Garg, AWS mentors, and fellow builders.
For us, that meant one thing:
TERRA had to be more than a pretty demo.
We Designed the Architecture Around One Question
Imagine that at 4:17 PM, particulate pollution suddenly spikes in one part of a city.
What should TERRA do?
Not tomorrow.
Not after somebody refreshes a dashboard.
Right then.
That question gave us our architecture.
Simplified Environmental Event Flow
text
Environmental Telemetry│▼Amazon API Gateway│▼AWS Lambda│├──────────────► Amazon DynamoDB│ Latest telemetry│▼Anomaly Evaluation│▼Amazon EventBridge│▼Amazon SNS│▼Environmental Alert
That was the moment TERRA stopped being merely a visualization project.
The globe became the interface to an event-driven environmental system.
The Architecture
TERRA's AWS architecture connects the 3D frontend with serverless APIs, environmental intelligence, storage, authentication, monitoring, and an event-driven alert pipeline.
At the edge is our React + Three.js application.
Amazon API Gateway exposes the API layer.
AWS Lambda runs our serverless application logic.
Amazon DynamoDB stores environmental telemetry and community data.
Amazon S3 stores citizen-submitted evidence.
Amazon SageMaker AI supports anomaly scoring.
Amazon EventBridge carries environmental events.
Amazon SNS and Amazon SQS handle notifications and failed delivery paths.
Amazon Cognito manages identity.
AWS Step Functions coordinates multi-stage incident workflows.
Amazon CloudWatch provides visibility into the entire system.
But an architecture diagram alone hides the interesting decisions.
So here are three of them.
Decision 1: Never Send the Photo Through Our Backend
One of TERRA's features lets someone report an environmental incident.
Imagine seeing illegal waste burning near your neighborhood.
You create a report and attach a photo.
Our first architectural question was deceptively simple:
Where should that image go?
A conventional flow would look like this:
text
Browser↓Backend↓Storage
That makes our backend responsible for transferring an image it does not actually need to process.
Instead, TERRA uses Amazon S3 pre-signed URLs.
text
Citizen││ Requests upload permission▼API Gateway│▼AWS Lambda││ Temporary signed permission▼Citizen ─────────────────────► Amazon S3Direct upload
The backend decides whether an upload should be allowed.
Amazon S3 handles the actual upload.
The incident record then stores a reference to the evidence.
Citizen environmental reports can include evidence uploaded securely through Amazon S3.
It is a small architectural choice, but one of my favorite lessons from this project:
Sometimes the best thing your backend can do is get out of the way.
Decision 2: A Dangerous Reading Should Become an Event
Suppose TERRA detects an unusually severe pollution spike.
We could simply store:
text
AQI = 221
inside a database.
But a dangerous measurement sitting silently inside a database is not particularly useful.
So significant environmental changes become events.
TERRA uses Amazon EventBridge to separate:
Something happened
from:
What should respond to it?
The flow looks like this:
text
Pollution Threshold Exceeded│▼Amazon EventBridge│▼Amazon SNS/ \/ \Alerts Other Consumers│▼Amazon SQSDLQ Path
Today, an event might trigger an alert.
Tomorrow, the exact same event could trigger:
- a researcher workflow,
- a municipal dashboard,
- historical analysis,
- an incident verification pipeline,
- another autonomous agent.
The component detecting the pollution spike does not need to know.
That is when event-driven architecture clicked for me.
It is not about adding another AWS icon to an architecture diagram.
It is about making:
"Pollution changed."
a fact that the rest of the system can react to.
Decision 3: "Unusual" Is Not the Same as "Dangerous"
Environmental data is noisy.
One strange observation might be:
- a real environmental incident,
- a sensor malfunction,
- weather-driven variation,
- locally unusual but harmless,
- genuinely hazardous.
So TERRA's anomaly layer is deliberately not designed to say:
This reading is definitely dangerous.
We created an inference workflow around Amazon SageMaker AI using isolation-forest-style anomaly scoring.
Its job is closer to:
Something about this observation is unusual. Look closer.
That result can then be evaluated alongside:
- environmental thresholds,
- historical readings,
- geospatial context,
- citizen reports,
- supporting evidence.
This distinction became important while building TERRA.
Machine learning should add another signal.
It should not manufacture certainty.
Then Came the Human Signal
Sensors can tell us that a value changed.
They cannot always tell us why.
A community report can.
Imagine this:
text
4:17 PMSensor network detects an abnormal PM2.5 increase.4:19 PMTERRA flags the observation as unusual.4:23 PMA nearby resident reports visible waste burning.4:24 PMPhoto evidence reaches Amazon S3.4:25 PMTelemetry + location + community evidencenow describe the same environmental event.
Neither source is perfect independently.
Together, they become much more useful.
That is one of the ideas we want to explore much further with TERRA:
Combining machine observations and human observations without pretending that either one is automatically ground truth.
Authentication and Authorization Turned Out to Be Different Problems
TERRA has multiple kinds of users.
A citizen reporting an incident should not automatically receive the same permissions as someone managing environmental telemetry.
We use Amazon Cognito for authentication.
Authentication answers:
Who are you?
But it does not answer:
What are you allowed to do?
For that second question, we explored Cedar, AWS's open-source authorization policy language.
Conceptually:
text
Citizen✓ Submit environmental reports✓ View environmental information✗ Modify research telemetryResearcher✓ Inspect telemetry✓ Perform authorized research operations
Separating identity from permissions made the security model much easier to reason about.
The AWS Feature That Saved Us the Most Money Was Not a Cloud Service
It was being able to build AWS-like infrastructure without constantly deploying to AWS.
Hackathons encourage experimentation.
Cloud bills discourage careless experimentation.
Those two things are not natural friends.
So we created two modes for TERRA.
Build It
During development, we used LocalStack through Docker Compose to emulate AWS workflows locally.
That allowed us to test services such as:
text
Amazon S3Amazon DynamoDBAWS LambdaAmazon API GatewayAmazon SNSAmazon EventBridgeAmazon Cognito
without making every debugging cycle a live-cloud debugging cycle.
Our infrastructure is defined with AWS SAM, so the serverless architecture lives inside our repository rather than only inside our memory of which buttons we clicked in the AWS Console.
Ship It
When we were ready, those same architectural ideas mapped to real AWS services.
That became one of the most useful lessons from the project:
Cloud-native does not have to mean cloud-dependent development.
Infrastructure Should Be Part of the Repository
One thing we wanted to avoid was manually creating everything and then forgetting how it was configured.
So TERRA keeps its infrastructure definitions alongside the application code.
A simplified repository structure looks like this:
text
Terra-Globe/│├── frontend/│ └── React + Three.js│├── aws/│ ├── sagemaker/│ ├── cedar/│ ├── step-functions/│ ├── opensearch/│ └── cloudwatch/│├── lambda/│ └── handlers/│├── template.yaml├── Dockerfile└── docker-compose.localstack.yml
Architecture documentation eventually becomes outdated.
Infrastructure-as-code is executable documentation.
What Fought Back
This is the part architecture diagrams never show.
They make everything look like this:
text
Service A → Service B → Service C
Beautiful arrows.
No problems.
Reality is much less polite.
One of the biggest challenges was learning how many boundaries exist inside a cloud application:
text
Frontend↕Authentication↕API Permissions↕AWS Lambda↕IAM↕Storage / Database↕Events
A function working locally does not prove that its cloud identity can access Amazon S3.
A valid user does not automatically have authorization to perform every operation.
An anomaly being detected does not guarantee that a downstream notification gets delivered.
An API returning
200 OK does not prove that the entire asynchronous event chain succeeded.So we added:
- explicit IAM permissions,
- Amazon CloudWatch visibility,
- Amazon SQS dead-letter handling,
- infrastructure-as-code,
- local AWS emulation,
- separation between synchronous APIs and asynchronous events.
The most useful mental shift was this:
Don't only test whether the function works. Test whether the handoff works.
A lot of cloud bugs live between components.
One Architecture Rule Kept Deleting AWS Services
During the hackathon, it was tempting to keep adding services simply because we could.
Our architecture could easily become:
Look how much AWS we used.
That is not architecture.
So we started asking one question for every box:
If I remove this component, which user problem becomes harder to solve?
Amazon S3
Citizens need durable evidence storage.
Amazon DynamoDB
Telemetry and community state need fast persistence.
AWS Lambda
Requests and environmental events need computation.
Amazon EventBridge
Environmental changes need to trigger workflows without tightly coupling components.
Amazon SNS
A hazard is not useful if nobody hears about it.
Amazon SageMaker AI
Static thresholds alone cannot represent every unusual environmental pattern.
Amazon Cognito
Community actions need identity.
Amazon CloudWatch
Distributed systems need evidence of their own behavior.
If we could not answer the question, the service did not deserve a box.
That exercise made our architecture smaller and the project stronger.
What the WeMakeDevs Build Reminded Me About Hackathons
One thing I appreciate about WeMakeDevs and the Bharat Builds Tour is the emphasis on learning by actually shipping.
The experience was not just about producing another hackathon presentation.
It pushed builders to:
- learn AWS,
- build something real,
- work with mentors,
- publish what they learned,
- share their projects with a wider developer community.
Being around builders, AWS mentors, and people from the developer ecosystem such as Kunal Kushwaha, Saiyam Pathak, and Piyush Garg also reinforced something easy to forget when staring at architecture diagrams:
Building is not only about getting the technology right.
It is also about being able to answer:
Why should this exist?
And eventually:
Who does it help?
For TERRA, those questions kept bringing us back to the same idea.
Environmental intelligence should not end at the measurement.
What TERRA Looks Like Now
Today, the project connects several ideas that originally started separately.
🌍 A Living 3D Earth
Environmental data becomes geographical and explorable through React + Three.js.
🫁 AeroHealth
Raw environmental measurements are translated into understandable exposure and health-oriented indicators.
📸 Citizen Evidence
Communities can report local environmental events and securely attach evidence through Amazon S3.
🧠 Anomaly Intelligence
Environmental telemetry can be evaluated for unusual patterns using our Amazon SageMaker AI inference workflow.
⚡ Event-Driven Alerts
Significant environmental changes can move through Amazon EventBridge and Amazon SNS instead of remaining silent database rows.
☁️ Local-to-Cloud Development
LocalStack and AWS SAM allow us to build and test locally before shipping to AWS.
The same environmental event can be explored geographically, interpreted through environmental context, and supported by community evidence.
What I Would Build Next
The feature I am most interested in building next is not another visualization.
It is verification.
Imagine an environmental incident supported simultaneously by:
text
Satellite Observation+Ground Sensor Readings+Historical Patterns+Citizen Evidence+Anomaly Detection
Instead of asking someone to trust one sensor, one report, or one machine-learning model, TERRA could show:
- why an environmental event is believed to be significant,
- which evidence supports it,
- where conflicting evidence exists,
- how confident the system is.
We also want to explore stronger geospatial retrieval and better workflows for researchers and trusted environmental organizations to review community-submitted incidents.
Because a digital twin should not simply imitate Earth visually.
It should help us reason about what is happening on it.
The 3D Globe Is Probably the Least Important Part
It is also the first thing everyone notices.
And I am okay with that.
Sometimes visualization is what makes somebody stop long enough to care about the data underneath it.
TERRA began with one question:
What if environmental data felt like exploring the planet instead of reading a spreadsheet?
Building it on AWS created another:
What happens when the planet on our screen needs to react to the planet outside?
That second question gave us the architecture.
The globe shows the change.
AWS Lambda processes it.
Amazon DynamoDB remembers it.
Amazon SageMaker AI investigates it.
Amazon EventBridge carries it.
Amazon SNS tells someone.
Amazon S3 preserves the evidence.
And somewhere on the other side of all those AWS services is the only component that actually matters:
A person deciding what to do next.
Built During Environmental Hacks 🌱
TERRA was built for Environmental Hacks, part of the Bharat Builds Tour by WeMakeDevs in collaboration with AWS Builder Center.
Project
TERRA / Terra-Globe
Built With
- AWS Lambda
- Amazon S3
- Amazon DynamoDB
- Amazon API Gateway
- Amazon EventBridge
- Amazon SNS
- Amazon SQS
- Amazon Cognito
- Amazon SageMaker AI
- AWS Step Functions
- Amazon CloudWatch
- AWS SAM
- Cedar
- LocalStack
- React
- Three.js
- WebGL
Links
Final Thought
There is already an enormous amount of data describing our planet.
The harder problem is turning that data into something people can see, understand, verify, and act on.
That is what we tried to explore with TERRA.
Not another environmental dashboard.
Not just another 3D globe.
But a small experiment in what happens when environmental data becomes alive enough to react.
Tags
AWS Serverless AWS Lambda Amazon EventBridge Amazon SageMaker AI Amazon S3 Digital Twin Sustainability Three.js Environmental Technology WeMakeDevs Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article