DEV Community: NITHISH

N for Nithish, N for Neptune: My AWS Deep Dive

NITHISH — Wed, 16 Sep 2026 03:02:02 +0000

Exploring Amazon Neptune — AWS's Graph Database for Connected Data

When we think about databases, we usually imagine tables containing rows and columns. That works very well for many applications. But what happens when the relationships between the data are just as important as the data itself?

For example, consider a college:

A student belongs to a department.
A student works on a project.
A project uses a technology.
A professor guides a project.
Two students may work on the same project.
A course may require another course as a prerequisite.

There are many connections between these entities.

This is where Amazon Neptune becomes interesting.

Amazon Neptune is a fully managed AWS graph database service designed for applications that work with highly connected datasets. It is optimized for storing and querying relationships between entities.

What is Amazon Neptune?

Amazon Neptune is a managed graph database service provided by AWS.

Instead of primarily representing information as rows and columns, a graph database represents information using:

Nodes — entities or objects
Edges — relationships between entities
Properties — additional information about nodes or relationships

For example:

        ┌─────────────┐
        │   Nithish   │
        │   Student   │
        └──────┬──────┘
               │
             STUDIES
               │
               ▼
        ┌─────────────┐
        │    AIML     │
        │  Department │
        └──────┬──────┘
               │
             OFFERS
               │
               ▼
        ┌─────────────┐
        │  Machine    │
        │  Learning   │
        └─────────────┘

Here, Nithish, AIML, and Machine Learning are nodes, while STUDIES and OFFERS are relationships.

AWS describes Neptune as a graph database capable of handling highly connected datasets and billions of relationships.

Why Was Amazon Neptune Created?

Traditional relational databases are excellent for structured data. However, applications involving large numbers of relationships can require many tables, foreign keys, and complex joins.

Imagine trying to answer:

"Find students who worked on projects involving Python and were guided by professors who teach Machine Learning."

In a relational database, this could involve several tables and joins.

In a graph database, we can think about the problem as navigating connections:

Student
   ↓
worked_on
   ↓
Project
   ↓
uses
   ↓
Python

Student
   ↓
guided_by
   ↓
Professor
   ↓
teaches
   ↓
Machine Learning

Graph databases are designed specifically for these types of connected-data queries. AWS explains that graph databases treat relationships as important parts of the data model, making relationship traversal easier to model and query.

How Does Amazon Neptune Work?

The basic architecture can be understood like this:

             User / Application
                     │
                     ▼
              Application API
                     │
                     ▼
              Amazon Neptune
                     │
        ┌────────────┴────────────┐
        │                         │
      Nodes                     Edges
   (Entities)               (Relationships)
        │                         │
        └────────────┬────────────┘
                     │
                     ▼
                Graph Data

An application sends a graph query to Neptune.

Neptune then searches through the nodes and relationships to find the required information.

For example:

Student
   │
   ├── STUDIES ──> Department
   │
   ├── WORKED_ON ──> Project
   │                    │
   │                    └── USES ──> Technology
   │
   └── GUIDED_BY ──> Professor

This makes Neptune useful when the relationships themselves are important to the application.

Neptune supports property graphs through Gremlin and openCypher, and RDF graphs through SPARQL.

Key Features of Amazon Neptune

1. Graph Data Model

The biggest feature of Neptune is its graph-oriented data model.

Instead of thinking only in terms of tables, developers can represent real-world relationships directly.

For example:

(Student)-[:WORKED_ON]->(Project)
(Project)-[:USES]->(Technology)
(Professor)-[:GUIDES]->(Project)

This is particularly useful for social networks, recommendation systems, knowledge graphs, fraud detection, and other relationship-heavy applications.

2. Multiple Graph Query Languages

Neptune supports multiple ways of querying graph data.

Gremlin

Gremlin is a graph traversal language from Apache TinkerPop.

A simple example is:

g.V().has('name','Nithish')
     .out('WORKED_ON')
     .values('name')

This can be understood as:

Find the vertex named Nithish → follow WORKED_ON relationships → return the project names.

openCypher

Neptune also supports openCypher, whose syntax can feel familiar to developers who have worked with SQL-like query languages.

For example:

MATCH (s:Student)-[:WORKED_ON]->(p:Project)
WHERE s.name = 'Nithish'
RETURN p.name

Neptune supports both Gremlin and openCypher for property graphs.

3. High Availability and Reliability

Neptune is a fully managed service, meaning AWS handles many infrastructure and database-management tasks.

Neptune supports features such as:

Read replicas
Continuous backup
Point-in-time recovery
Availability Zone replication
Automatic failover

AWS states that Neptune is designed for greater than 99.99% availability.

This means developers can focus more on the application instead of managing database infrastructure manually.

College/Student Use Case 🎓

Building a College Knowledge Graph

One practical use case for my college would be a Student Academic Knowledge Graph.

The system could connect:

Student
   │
   ├── belongs_to ──> Department
   │
   ├── enrolled_in ──> Course
   │
   ├── worked_on ──> Project
   │                       │
   │                       ├── uses ──> Technology
   │                       └── related_to ──> Course
   │
   └── guided_by ──> Faculty

Suppose a student asks:

"Show me projects related to Artificial Intelligence that use Python and were guided by faculty from the AIML department."

A graph database can represent these connections directly.

This could eventually be used to build:

Project recommendation systems
Faculty-project matching
Course recommendation
Student skill graphs
Research collaboration systems
Internship skill matching

This is also similar to the idea of a knowledge graph, where information is connected rather than treated as isolated records.

Simple Practical Example

Suppose we create three students and two projects:

(Nithish)-[:WORKED_ON]->(NutriRate)
(Ravi)-[:WORKED_ON]->(TrafficAI)

(NutriRate)-[:USES]->(Python)
(TrafficAI)-[:USES]->(Python)
(TrafficAI)-[:USES]->(TensorFlow)

Using openCypher, we could query:

MATCH (s:Student)-[:WORKED_ON]->(p:Project)-[:USES]->(t:Technology)
WHERE t.name = 'Python'
RETURN s.name, p.name

The result could be:

Nithish    NutriRate
Ravi       TrafficAI

The important point is that we are not simply searching for the word "Python."

We are traversing relationships:

Student → Project → Technology

That is the fundamental idea behind graph databases.

Advantages of Amazon Neptune

Excellent for Connected Data

Neptune is designed specifically for applications where relationships between entities are important.

Fully Managed

AWS handles infrastructure tasks such as provisioning, patching, backups, and database management.

Multiple Query Languages

Developers can work with Gremlin, openCypher, or SPARQL depending on the graph model and application requirements.

Scalable

Neptune is designed to work with highly connected datasets and billions of relationships.

Strong Security

Neptune supports security features including VPC network isolation and encryption at rest using AWS Key Management Service (KMS).

Limitations / Things to Consider

Cost

Neptune is a managed cloud database, so it is not simply "free storage."

Costs can depend on the database resources used, storage, and I/O configuration. AWS also offers Neptune Serverless, which automatically adjusts capacity based on workload and charges for the resources consumed.

For a small student project, cost should therefore be considered before running a database continuously.

Complexity

Graph databases introduce concepts that are different from traditional relational databases.

Students familiar with SQL may need to learn:

Graph modeling
Nodes and edges
Graph traversal
Gremlin
openCypher
SPARQL

Not Every Application Needs a Graph Database

If an application mainly stores simple records such as:

Student ID
Name
Email
Age

then a traditional relational database may be sufficient.

Neptune becomes more interesting when relationships between the data are central to the application.

Security Considerations

Security is especially important when storing student information.

Neptune provides security mechanisms including:

Amazon VPC network isolation
Encryption at rest
Encryption in transit
AWS IAM integration
AWS KMS

For a college application, access should be restricted so that students can only access information they are authorized to see.

Conclusion

Amazon Neptune is more than another database service.

Its main idea is simple:

Data becomes more useful when we understand how the data is connected.

For a college environment, those connections can represent students, courses, projects, faculty, technologies, departments, and research areas.

Neptune provides a managed environment for building applications around these relationships, while supporting graph query languages such as Gremlin, openCypher, and SPARQL.

As a student learning AI and machine learning, I find the idea of a college knowledge graph particularly interesting because the same concept can be extended to recommendation systems, project discovery, research collaboration, and intelligent academic assistants.

And that brings me back to the title:

N for Nithish. N for Neptune.

A simple coincidence in the name, but a useful introduction to a completely different way of thinking about databases.

References

AWS — What is Amazon Neptune?
Amazon Neptune Documentation
AWS — Getting Started with Amazon Neptune
Getting Started with Amazon Neptune
AWS — Amazon Neptune Features
Amazon Neptune Features
AWS — Accessing Graph Data in Neptune
Accessing Graph Data in Amazon Neptune
AWS — Querying a Neptune Graph
Querying a Neptune Graph
AWS — Amazon Neptune Security
Amazon Neptune Security Documentation

Day1 Session1: Cloud Worskshop

NITHISH — Tue, 15 Sep 2026 06:51:58 +0000

From a Simple HTML File to AWS CloudFront: What Deploying My Portfolio Actually Taught Me

I recently decided to build a personal portfolio.

Nothing too complicated.

Just a simple website where I could show:

Who I am
What I'm learning
My projects
My technical skills
How to contact me

At first, I thought the difficult part would be building the website.

It wasn't.

The real learning started when I tried to put it on the internet.

It Started With One HTML File

My first version was just:

index.html

No React.

No backend.

No database.

Just HTML and CSS.

It worked perfectly on my computer.

I opened it in the browser and thought:

"Okay, the website is done."

Then came the question:

"How do I actually deploy this?"

That's when I started exploring AWS.

My First Stop: Amazon S3

I created an S3 bucket and uploaded my index.html.

The idea seemed simple:

My computer
↓
index.html
↓
S3
↓
Internet

But when I tried accessing it, AWS gave me:

AccessDenied

My first reaction was basically:

"But the file is literally there."

And that's when I started understanding something important.

Having a file in the cloud doesn't automatically mean everyone can access it.

There are permissions.

There are policies.

There are access controls.

There is configuration.

The file existing and the file being publicly accessible are two different things.

Learning to Read the Error Instead of Panicking

I think this was one of the most useful parts of the entire process.

Instead of immediately changing random settings, I started looking at the actual error.

AWS was telling me:

AccessDenied

So I started asking:

Who is being denied?

What resource are they trying to access?

What permission is missing?

That changed how I approached the problem.

I wasn't just trying random solutions anymore.

I was trying to understand the system.

Then I Decided to Use React

After getting the basic website working, I wanted to turn it into a proper React project.

So I created a React + Vite application.

The structure became:

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

Instead of writing everything directly into HTML, I started thinking in terms of components, data, and rendering.

For example, instead of manually writing every skill, I could represent them as data:

const skills = [
"Python",
"TensorFlow",
"Docker",
"Machine Learning"
];

and render them through React.

It wasn't a huge application, but it helped me understand why frameworks like React are useful.

The dist Folder Was Another Lesson

Then I learned something I hadn't really thought about before.

My React source code isn't what I necessarily need to deploy.

I ran:

npm run build

and Vite created:

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

That made something click for me.

React is helping me develop the application.

The browser ultimately needs the resulting HTML, CSS, JavaScript, and other assets.

So my deployment flow became:

React Source Code
↓
npm run build
↓
dist/
↓
S3

That distinction between development files and production build files was something I hadn't really understood before.

Then Came CloudFront

I didn't want to stop at S3.

I wanted to learn how CloudFront fits into the architecture.

So I added CloudFront.

Now I had:

Browser
↓
CloudFront
↓
S3

This looked pretty straightforward.

Until I opened my CloudFront URL.

404.

Instead of my portfolio:

404 Not Found

And then I saw:

Code: NoSuchKey

But the interesting part was this:

Key: index.html/index.html

I stared at that for a while.

My S3 bucket had:

index.html

not:

index.html/index.html

So why was CloudFront asking S3 for that?

The Problem Wasn't My React Code

This was probably my favorite debugging lesson.

I initially thought:

"Maybe my React build is broken."

It wasn't.

My index.html existed.

My build existed.

My S3 bucket had the files.

The problem was somewhere else.

I checked the CloudFront origin configuration.

And there it was.

I had configured the origin path as:

/index.html

while also using:

index.html

as the default root object.

So I had effectively told CloudFront:

"Start at index.html."

and then:

"Also use index.html as the root."

Result:

index.html/index.html

AWS wasn't being random.

I had configured it that way.

That was a good lesson.

Fixing It

I removed the origin path.

So instead of:

Origin path:
/index.html

I left it empty.

And kept:

Default root object:
index.html

The request flow then became:

/
↓
CloudFront
↓
index.html
↓
S3

instead of:

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

And Then... It Still Didn't Immediately Work

This was another AWS lesson.

I had fixed the configuration.

But CloudFront uses caching.

So the old response could still be cached.

I created a CloudFront invalidation:

After that, I tested again.

And finally...

The portfolio loaded.

What I Learned From a "Simple Portfolio"

Looking back, the portfolio itself wasn't a technically huge project.

But the deployment taught me several things I wouldn't have learned by just following a tutorial.

1. Code isn't the entire application

There are many layers:

Code
↓
Build
↓
Files
↓
Storage
↓
Permissions
↓
CDN
↓
Caching
↓
Browser

A problem at any layer can make the entire website appear broken.

2. Errors are useful information

Before this, an error like:

NoSuchKey

would mostly mean:

"Something is wrong."

Now I try to ask:

"What key is AWS actually looking for?"

In my case, the answer was:

index.html/index.html

And that immediately gave me a direction.

3. Infrastructure has bugs too

As developers, we often think about bugs in code.

But configuration can have bugs too.

A wrong path.

A wrong bucket name.

A missing permission.

A caching problem.

These can break an application just as easily as a programming bug.

My Deployment Architecture

What started as a simple HTML file eventually became:

             User
               │
               ▼
         CloudFront
               │
               ▼
         S3 Bucket
          /       \
         /         \
   index.html     assets/

And my development workflow is:

Write React
↓
Test locally
↓
npm run build
↓
dist/
↓
Upload to S3
↓
CloudFront
↓
Internet

The Bigger Lesson

I'm still learning.

I don't want to pretend that I suddenly understand AWS because I managed to deploy one website.

I still have a lot to learn about:

Cloud architecture
IAM
Networking
DNS
HTTPS
CI/CD
Infrastructure as Code
Monitoring
Security

But I think I'm starting to understand something more important.

When you're learning development, getting stuck is part of the process.

The goal isn't to never get errors.

The goal is to become better at answering:

"Why did this happen?"

That's what I'm trying to get better at.

And this portfolio deployment was a surprisingly good first step.

Tech Stack

Frontend:

React
Vite
JavaScript
HTML
CSS

AWS:

Amazon S3
Amazon CloudFront

Tools:

VS Code
npm
Git/GitHub

What's Next?

The portfolio is deployed, but I'm not treating it as finished.

I want to keep improving it as I learn more.

Next, I'd like to explore:

Custom Domain
↓
HTTPS
↓
CI/CD
↓
GitHub → Automatic Deployment

Because the next goal isn't just:

"I deployed a website."

It's:

"I understand how the website gets from my code to a real user."

And that's a much more interesting thing to learn.

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