DEV Community: TANUJ AJ

T for Tanuj, T for Timestream: Exploring Amazon Timestream

TANUJ AJ — Wed, 16 Sep 2026 04:33:21 +0000

Introduction

As part of my AWS learning activity, I participated in the Rhyming Game Contest, where each student had to select an AWS service connected to the first letter of their name.

My name is Tanuj A J, so I selected Amazon Timestream.

In this blog, I will explain what Amazon Timestream is, why it was created, how it works, its key features, a practical college/student use case, a simple example, advantages, limitations, cost considerations, and security aspects.

☁️ What is Amazon Timestream?

Amazon Timestream is a fully managed, purpose-built time-series database service from AWS.

A time-series database is designed to store data points that are recorded over time. Examples include:

Temperature readings
CPU utilization
Weather measurements
IoT sensor readings
Application metrics
Website activity
Vehicle telemetry

For example, imagine a temperature sensor sending a reading every second:

10:00:01 → 28°C
10:00:02 → 28.1°C
10:00:03 → 28.2°C
10:00:04 → 28.4°C

The important part is not just the temperature value, but how that value changes over time.

Amazon Timestream was designed specifically for workloads involving large amounts of time-series data. AWS describes Timestream for LiveAnalytics as a serverless, scalable service capable of storing and analyzing very large volumes of time-series data while automatically managing the underlying infrastructure.

Why was Timestream created?

Traditional relational databases can store time-series information, but applications dealing with huge volumes of continuously generated measurements can require specialized approaches.

Amazon Timestream was created to make it easier to:

Ingest large volumes of time-series data
Analyze recent and historical data
Automatically manage data storage
Scale according to workload
Perform time-based analytics
Reduce database administration work

It is particularly useful for IoT, application monitoring, operational analytics, and telemetry workloads.

⚙️ How It Works

At a basic level, the process looks like this:

      Data Sources
           │
           ▼
 ┌─────────────────────┐
 │ IoT / Applications   │
 │ Sensors / Devices   │
 └──────────┬──────────┘
            │
            ▼
 ┌─────────────────────┐
 │ Amazon Timestream   │
 │                     │
 │  Data Ingestion     │
 └──────────┬──────────┘
            │
            ▼
 ┌─────────────────────┐
 │     Storage         │
 │                     │
 │ Memory Store        │
 │        ↓            │
 │ Magnetic Store      │
 └──────────┬──────────┘
            │
            ▼
 ┌─────────────────────┐
 │ Query & Analytics   │
 └──────────┬──────────┘
            │
            ▼
      Dashboard /
       Application

The basic workflow is:

1. Data is generated

Sensors, applications, devices, or other systems continuously generate measurements.

2. Data is ingested

The data is sent to Amazon Timestream.

3. Data is stored

Timestream provides different storage tiers for recent and historical information.

4. Data is queried

Applications can use SQL-based queries to analyze the data.

5. Results are used

The results can be used for dashboards, monitoring, alerts, analytics, or machine-learning workflows.

Amazon's architecture separates data ingestion, storage, and query processing so that these components can scale independently.

🧩 Storage Architecture

One of the interesting parts of Timestream is its storage model.

It provides:

Memory Store

The memory store is designed for recent data and workloads that require fast access to current information.

For example:

Current temperature
Current CPU usage
Current server metrics
Live sensor readings

Magnetic Store

The magnetic store is designed for historical data and cost-efficient long-term storage.

For example:

Last month's temperature data
Previous year's server metrics
Historical IoT readings
Long-term application statistics

Timestream can automatically move data between these storage tiers based on retention policies configured by the user.

⭐ Key Features

1. Serverless and Automatic Scaling

Amazon Timestream is serverless, which means developers don't need to manage database servers or manually provision capacity.

It can automatically scale based on the workload.

This is useful when an application suddenly starts receiving a much larger amount of sensor or monitoring data.

2. Time-Series Optimized

Timestream is specifically designed for time-series workloads.

Instead of treating time as just another column, its architecture and query capabilities are designed around data that changes over time.

It also provides built-in time-series functions for analyzing trends, aggregates, and other time-based patterns.

3. Automatic Data Lifecycle Management

Managing recent and historical data manually can become complicated.

Timestream simplifies this by allowing retention policies that control how long data remains in the memory store before moving to the magnetic store.

This can reduce the amount of manual data-management work required.

4. SQL-Based Queries

Developers familiar with SQL can use SQL-style queries to analyze time-series information.

For example:

SELECT
    time,
    temperature
FROM campus_temperature
WHERE time > ago(1h)
ORDER BY time DESC;

This type of query could be used to retrieve recent temperature readings.

5. AWS Integrations

Timestream can integrate with other AWS services and tools.

Examples include:

AWS IoT Core
Amazon Kinesis
Amazon MSK
Amazon SageMaker
Amazon QuickSight
Grafana

These integrations make it possible to collect data, store it, analyze it, visualize it, and use it in machine-learning workflows.

🎓 College / Student Use Case

Smart Campus Monitoring System

A practical use case for my college could be a Smart Campus Monitoring System.

Imagine that sensors are installed across the campus to measure:

Classroom temperature
Electricity consumption
Server room temperature
Air quality
Water usage
Laboratory equipment status

The sensors could continuously send measurements to a backend system.

Architecture

        Campus Sensors
              │
              ▼
       AWS IoT Core
              │
              ▼
      Amazon Timestream
              │
       ┌──────┴──────┐
       ▼             ▼
   Recent Data   Historical Data
       │             │
       └──────┬──────┘
              ▼
       Analytics Layer
              │
       ┌──────┴──────┐
       ▼             ▼
   Dashboard      ML Model

For example, an AIML student could build a model that analyzes historical temperature and equipment data to identify unusual patterns.

The system could then be used for:

Predictive maintenance
Energy monitoring
Classroom environment monitoring
Equipment failure detection
Campus resource optimization

This would also provide a practical project combining IoT + Cloud + AI/ML.

💻 Simple Example

Suppose our college has a temperature sensor in a computer laboratory.

Every minute, it sends:

Timestamp: 2026-09-16 10:00:00
Room: AIML-Lab-1
Temperature: 24.5°C

Another reading arrives:

Timestamp: 2026-09-16 10:01:00
Room: AIML-Lab-1
Temperature: 24.8°C

The application could store these readings in Timestream.

A simple query could retrieve the latest readings:

SELECT
    time,
    room,
    temperature
FROM lab_temperature
WHERE room = 'AIML-Lab-1'
ORDER BY time DESC
LIMIT 10;

The result could then be displayed on a dashboard.

For example:

AIML LAB - TEMPERATURE

10:00 AM    24.5°C
10:01 AM    24.8°C
10:02 AM    25.0°C
10:03 AM    25.2°C

If the temperature suddenly increases, the application could trigger an alert or send the data to a machine-learning model for anomaly detection.

AWS provides SDKs, APIs, CLI support, and sample code for working with Timestream.

✅ Advantages

1. Fully Managed

AWS manages much of the underlying infrastructure, allowing developers to focus on their applications instead of database administration.

2. Automatic Scaling

Timestream can scale according to workload, which is useful for applications where data volume changes over time.

3. Designed for Time-Series Data

The service is specifically designed for data such as metrics, telemetry, sensor readings, and monitoring information.

4. Data Lifecycle Management

Users can configure retention policies to manage recent and historical data across storage tiers.

5. AWS Ecosystem Integration

Timestream can work with AWS IoT, Kinesis, SageMaker, QuickSight, Grafana, and other tools.

⚠️ Limitations / Things to Consider

💰 Cost

Amazon Timestream uses a usage-based pricing model. AWS currently offers on-demand pricing with no minimum fees or upfront commitments, as well as Database Savings Plans for eligible usage commitments. Actual costs depend on the database engine, data ingestion, queries, storage, and workload.

For students, it is important to monitor AWS usage and delete resources or stop workloads that are no longer required.

🧠 Complexity

Although Timestream is managed, understanding concepts such as:

Time-series data
Tables
Dimensions
Measures
Retention policies
SQL queries
AWS IAM

is useful before building a larger application.

For a beginner, starting with a small dataset is a good way to understand the service.

📈 Scalability

Scalability is one of Timestream's major strengths, but highly scalable systems can also generate significant usage if large amounts of data are continuously ingested and queried.

Therefore, applications should still be designed carefully and monitored.

🔐 Security

Security is important when collecting data from IoT devices or applications.

AWS states that Timestream data is encrypted, and the service supports AWS identity and access controls as well as AWS KMS options for applicable encryption scenarios.

For a college project, IAM permissions should follow the principle of least privilege instead of giving every user administrative access.

🔍 When Would I Choose Timestream?

Timestream is particularly suitable when an application continuously produces data that needs to be analyzed according to time.

Examples include:

IoT Sensors
     ↓
Application Metrics
     ↓
Server Monitoring
     ↓
Vehicle Telemetry
     ↓
Industrial Equipment
     ↓
Real-Time Analytics

If the application mainly requires traditional transactional data such as:

Student ID
Student Name
Course
Department
Phone Number

then a conventional relational database may be more appropriate.

The choice of database should therefore depend on the type of data and workload.

🎯 Conclusion

Amazon Timestream is a specialized AWS database service designed for time-series data.

Its serverless architecture, automatic scaling, storage lifecycle management, time-series analytics capabilities, and integration with other AWS services make it useful for applications involving continuously generated data.

For students, Timestream can be especially interesting when building projects involving IoT, cloud computing, monitoring, analytics, and AI/ML.

For example, a Smart Campus Monitoring System could collect sensor data using AWS IoT, store it in Timestream, visualize it through a dashboard, and use machine learning to detect unusual patterns.

Through this activity, I learned that choosing the right database depends not only on how much data an application has, but also on the type of data, how frequently it changes, and how it needs to be analyzed.

And finally:

T for Tanuj, T for Timestream! 🚀☁️

📚 References

AWS — Amazon Timestream Overview
AWS — Amazon Timestream Documentation
AWS — Amazon Timestream Architecture
AWS — Amazon Timestream Features
AWS — Amazon Timestream Pricing

Day-1 Cloud Workshop

TANUJ AJ — Tue, 15 Sep 2026 06:54:48 +0000

I Built and Deployed My First React Portfolio on AWS S3 + CloudFront — And Broke It Along the Way

As a Computer Science student, I’ve been trying to move away from just writing code by following tutorials and actually understand how things work by building and deploying projects.

One of the things I wanted to build was a simple personal portfolio.

It sounded easy:

Build a React portfolio → upload it to AWS → get a public URL.

It wasn't quite that simple.

I ran into permissions issues, S3 configuration problems, CloudFront errors, and eventually discovered that I had accidentally configured CloudFront to look for:

index.html/index.html

This is the story of how I built it, broke it, debugged it, and finally understood what was actually happening.

1. Starting With a Simple HTML Portfolio

I initially created my portfolio using a single:

index.html

I kept the design intentionally simple.

The portfolio contained:

About Me
Technical Skills
Projects
Education
Areas of Interest
Contact

Some of the projects and areas I included were:

CLOTE — self-hosted cloud file management
Automated Data Intelligence System
Graph Algorithm Visualizer
ML Ad-Click Prediction
City-Specific Smart Traffic System
Knowledge-Based Systems

At this point, everything worked locally.

I could simply open the HTML file in my browser and see the portfolio.

But then I wanted to actually deploy it.

2. Moving to AWS S3

I decided to use Amazon S3 for hosting.

I created an S3 bucket and uploaded my portfolio.

The object looked like:

s3://portfolio-tanuj/index.html

My first assumption was:

"The file is uploaded, so anyone should be able to open it."

That assumption was wrong.

When I tried accessing the website, I received:

<Error>
    <Code>AccessDenied</Code>
    <Message>Access Denied</Message>
</Error>

3. First Struggle — S3 AccessDenied

This was my first real AWS deployment problem.

The HTML itself wasn't the issue.

The problem was with S3 permissions and website access configuration.

I had to understand the relationship between:

S3 Bucket
    ↓
Object
    ↓
Permissions
    ↓
Static Website Hosting

I configured static website hosting and worked through the public-access configuration and bucket policy.

The important part of the bucket policy was allowing public GetObject access:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadGetObject",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::portfolio-nith/*"
    }
  ]
}

But then I ran into another issue.

4. My Bucket Name Wasn't What I Thought

At one point I was working with:

tanuj-bucket-portfolio

But when I looked at my AWS console, the actual bucket I was configuring was:

portfolio-tanuj

That caused confusion while creating the bucket policy.

AWS was telling me:

Policy has invalid resource

The reason was simple.

The policy resource has to reference the actual bucket name.

So:

arn:aws:s3:::portfolio-tanuj/*

instead of:

arn:aws:s3:::tanuj-bucket-portfolio/*

That was a small mistake, but it taught me something important:

Don't blindly copy AWS configuration. Understand what resource you're actually configuring.

5. Then I Wanted to Use React

Once I had the basic portfolio working, I decided to convert it into a React application.

Instead of one large HTML file, I moved to a React + Vite structure:

portfolio/
│
├── index.html
├── package.json
│
└── src/
    ├── main.jsx
    └── style.css

I used React to render the portfolio sections and JavaScript arrays for things like skills and projects.

For example:

const skills = [
    "Python",
    "C / C++",
    "Data Structures & Algorithms",
    "Machine Learning",
    "TensorFlow",
    "NumPy",
    "Pandas",
    "Docker"
];

And projects were represented as data:

const projects = [
    {
        title: "CLOTE",
        description: "...",
        tech: "Private Cloud • File Management"
    }
];

This was my first step toward understanding how a real frontend project is structured rather than putting everything into one HTML file.

6. Understanding `npm run build`

This was another important part.

I initially thought:

"Since it's React, I need a server running on AWS."

Not necessarily.

React can be built into static files.

I ran:

npm install

and then:

npm run build

Vite generated:

dist/
│
├── index.html
└── assets/
    ├── ...
    └── ...

This was a major realization for me.

The browser doesn't need my React source code or Node.js running on S3.

The production build becomes static assets that can be served by a web server.

So the deployment becomes:

React source
     ↓
npm run build
     ↓
dist/
     ↓
AWS S3

7. Adding CloudFront

Then I wanted to put CloudFront in front of S3.

The architecture became:

                    ┌──────────────┐
                    │    Browser   │
                    └──────┬───────┘
                           │
                           ▼
                    ┌──────────────┐
                    │  CloudFront  │
                    └──────┬───────┘
                           │
                           ▼
                    ┌──────────────┐
                    │      S3      │
                    │   index.html │
                    │    assets/   │
                    └──────────────┘

This was the point where things got interesting.

8. The CloudFront 404 Error

Instead of my portfolio, CloudFront returned:

404 Not Found

Code: NoSuchKey

Message: The specified key does not exist.

Key: index.html/index.html

At first I had no idea why AWS was asking for:

index.html/index.html

My S3 bucket clearly contained:

index.html

not:

index.html/index.html

So I started looking at the CloudFront configuration.

9. Finding the Actual Problem

I checked the CloudFront origin configuration.

And there it was.

My origin looked like:

Origin type: S3 static website
Origin path: /index.html

That was the mistake.

CloudFront already knew that the default root object was:

index.html

And I had also told the origin to use:

/index.html

So CloudFront effectively ended up requesting:

/index.html/index.html

S3 obviously couldn't find that object.

The error suddenly made sense.

10. The Fix

I changed the CloudFront origin path from:

/index.html

to:

(empty)

And kept the CloudFront default root object as:

index.html

So the configuration became conceptually:

CloudFront

Default root object:
index.html

Origin:
portfolio-nith S3 website endpoint

Origin path:
(empty)

Now the request flow made sense:

/
 ↓
CloudFront
 ↓
index.html
 ↓
S3
 ↓
portfolio

instead of:

/
 ↓
CloudFront
 ↓
index.html
 ↓
/index.html
 ↓
index.html/index.html ❌

11. Why I Had to Invalidate CloudFront

Even after fixing the configuration, CloudFront can still have cached responses.

So I created a CloudFront invalidation:

/*

This tells CloudFront to remove the cached objects so that the next request can fetch the updated content.

12. What I Actually Learned

The biggest thing I learned from this wasn't React.

It wasn't S3.

It wasn't even CloudFront.

It was debugging.

Before this, when something didn't work, my first instinct was often:

"The code must be wrong."

But this project showed me that problems can exist at completely different layers.

For example:

Frontend
   ↓
React
   ↓
Build
   ↓
Static files
   ↓
S3
   ↓
Permissions
   ↓
CloudFront
   ↓
Caching
   ↓
Browser

A website can have perfectly valid React code and still return a 404 because the infrastructure configuration is wrong.

13. My Struggles

These were some of the problems I faced:

S3

AccessDenied

I had to understand bucket permissions and public access.

Bucket policy

Policy has invalid resource

I was referencing the wrong bucket name.

CloudFront

NoSuchKey
Key: index.html/index.html

I had incorrectly configured the origin path.

Caching

Even after fixing the configuration, CloudFront could still serve an old cached response.

14. What I Would Do Differently Next Time

If I were starting this deployment again, my process would be:

1. Build React application
        ↓
2. Test locally
        ↓
3. npm run build
        ↓
4. Check dist/
        ↓
5. Upload dist contents to S3
        ↓
6. Configure S3
        ↓
7. Configure CloudFront
        ↓
8. Test CloudFront
        ↓
9. Check logs/errors if something fails
        ↓
10. Invalidate cache when required

And most importantly:

I would change one configuration at a time and test after each change.

15. Final Architecture

The final concept I learned is:

                 ┌───────────────────┐
                 │       User        │
                 └─────────┬─────────┘
                           │
                           ▼
                 ┌───────────────────┐
                 │     CloudFront    │
                 │       CDN         │
                 └─────────┬─────────┘
                           │
                           ▼
                 ┌───────────────────┐
                 │    S3 Bucket      │
                 │                   │
                 │   index.html      │
                 │   assets/         │
                 └───────────────────┘

My React application is built into static files and served through AWS infrastructure.

Final Thoughts

This was a relatively small project, but it gave me something more valuable than just a portfolio.

It gave me experience with the uncomfortable part of development:

things not working.

I had to read errors, inspect configuration, understand what AWS was actually doing, find the mismatch, and fix it.

The index.html/index.html error in particular was frustrating at first.

But once I understood why it happened, it became one of the most useful lessons from the project.

I'm still learning AWS, React, and software development, but I'm slowly trying to replace:

"Copy the code and hope it works"

with:

"Understand what each component is doing, then debug when it doesn't."

And I think that's a much better way to learn development.

Tech Stack

Frontend

React
Vite
HTML
CSS
JavaScript

Cloud

Amazon S3
Amazon CloudFront

Development

VS Code
npm
Git/GitHub

react #aws #cloudfront #s3 #webdevelopment #javascript #vite #beginners #devjourney #learninginpublic

DEV Community: TANUJ AJ

T for Tanuj, T for Timestream: Exploring Amazon Timestream

Introduction

☁️ What is Amazon Timestream?

Why was Timestream created?

⚙️ How It Works

🧩 Storage Architecture

Memory Store

Magnetic Store

⭐ Key Features

1. Serverless and Automatic Scaling

2. Time-Series Optimized

3. Automatic Data Lifecycle Management

4. SQL-Based Queries

5. AWS Integrations

🎓 College / Student Use Case

Smart Campus Monitoring System

Architecture

💻 Simple Example

✅ Advantages

1. Fully Managed

2. Automatic Scaling

3. Designed for Time-Series Data

4. Data Lifecycle Management

5. AWS Ecosystem Integration

⚠️ Limitations / Things to Consider

💰 Cost

🧠 Complexity

📈 Scalability

🔐 Security

🔍 When Would I Choose Timestream?

🎯 Conclusion

📚 References

Day-1 Cloud Workshop

I Built and Deployed My First React Portfolio on AWS S3 + CloudFront — And Broke It Along the Way

1. Starting With a Simple HTML Portfolio

2. Moving to AWS S3

3. First Struggle — S3 AccessDenied

4. My Bucket Name Wasn't What I Thought

5. Then I Wanted to Use React

6. Understanding npm run build

7. Adding CloudFront

8. The CloudFront 404 Error

9. Finding the Actual Problem

10. The Fix

11. Why I Had to Invalidate CloudFront

12. What I Actually Learned

13. My Struggles

S3

Bucket policy

CloudFront

Caching

14. What I Would Do Differently Next Time

15. Final Architecture

Final Thoughts

Tech Stack

react #aws #cloudfront #s3 #webdevelopment #javascript #vite #beginners #devjourney #learninginpublic

6. Understanding `npm run build`