DEV Community: AMUTHA NILA AR

A for Athena

AMUTHA NILA AR — Wed, 16 Sep 2026 02:50:33 +0000

A for Amutha, A for Athena: My First AWS Deep Dive ☁️

Introduction

Cloud computing has changed the way students, developers and organizations store and analyze data. As the amount of data increases, simply storing data is not enough. We also need efficient ways to search, analyze and understand that data.

As part of my AWS learning journey, I explored Amazon Athena, an interactive and serverless query service provided by Amazon Web Services (AWS).

The fun part for me is the connection between my name and the service:

A for Amutha → A for Athena

Amazon Athena allows users to analyze data stored in Amazon S3 using standard SQL, without setting up or managing database servers. This makes it useful for students and developers who want to perform data analysis without maintaining complicated infrastructure.
What is Amazon Athena?

Amazon Athena is a serverless interactive query service that allows users to analyze data directly from Amazon S3 using SQL.

Unlike a traditional database where we may need to create and manage servers, Athena does not require us to provision or maintain servers for SQL queries.

A simple way to understand it is:

S3 stores the data → Athena reads the data → SQL analyzes the data → results are returned.

Athena can work with different data formats including CSV, JSON, Apache Parquet, ORC and Avro. It can also integrate with AWS Glue Data Catalog to maintain information about datasets and their schemas.

Why was Athena created?

Organizations often have large amounts of data stored in Amazon S3. Traditionally, analyzing that data could require additional infrastructure, data processing systems or databases.

Athena provides a simpler approach: instead of moving all the data into a separate database, users can query data where it already exists in S3.

This makes Athena particularly useful for ad-hoc analysis, log analysis, reporting and exploring large datasets**.

How Amazon Athena Works

The basic workflow can be understood in five steps:

Data is stored in Amazon S3.
A database and table schema are defined in Athena.
Athena identifies how the data is structured.
The user writes a SQL query.
Athena processes the data and returns the results.

Architecture / Flow Diagram

Place the following diagram here in your Dev.to article:

         ┌──────────────────────┐
         │      Amazon S3       │
         │                      │
         │ CSV / JSON / Parquet │
         └──────────┬───────────┘
                    │
                    ▼
         ┌──────────────────────┐
         │    Amazon Athena     │
         │                      │
         │   Serverless SQL     │
         │      Queries         │
         └──────────┬───────────┘
                    │
              SQL Processing
                    │
                    ▼
         ┌──────────────────────┐
         │    Query Results     │
         │                      │
         │ Console / S3 / BI    │
         └──────────────────────┘

Athena can also work with AWS Glue Data Catalog, which can store metadata about tables and datasets. Query results are written to an S3 location configured for Athena.

Key Features of Amazon Athena

Serverless Architecture

The biggest feature of Athena is that it is serverless.

There is no need to create, configure, patch or maintain query servers. AWS manages the underlying infrastructure, allowing developers to concentrate on writing queries and analyzing data.

Standard SQL Queries

Athena supports standard SQL, which means students who already know SQL can start analyzing datasets without learning an entirely new programming language.

For example:

SELECT department, COUNT(*) AS student_count
FROM students
GROUP BY department;

This query can count students in each department.

Multiple Data Formats

Athena can query several formats such as:

CSV
JSON
Apache Parquet
Apache ORC
Avro

This makes it suitable for different types of datasets and data-lake environments.

Integration with AWS Glue

Athena integrates with the AWS Glue Data Catalog, which can act as a central metadata repository for datasets stored in S3.

This helps Athena understand the structure of the data before running queries.

Federated Queries

Athena can also query data from sources beyond S3 using data source connectors. This allows SQL-based analysis across multiple supported data sources.

🎓 College / Student Use Case

Imagine our college stores student activity data in Amazon S3.

The dataset could contain:

student_id,department,event,score
101,AIML,Hackathon,85
102,CSE,Workshop,92
103,AIML,Workshop,78
104,ECE,Hackathon,88

Instead of downloading the complete dataset and manually analyzing it, a student project could use Athena to directly query the data.

For example, we could find the average score for each department:

SELECT department,
       AVG(score) AS average_score
FROM student_events
GROUP BY department;

This could help a college analytics system understand participation and performance across departments.

A similar approach could be used for:

Attendance analysis
Workshop participation
Hackathon statistics
Placement data analysis
Library usage
Campus event analytics

💻 Practical Example

Suppose a college stores a file called:

student_events.csv

inside an S3 bucket.

After creating an Athena table for the dataset, we can execute:

SELECT event,
       COUNT(*) AS participants
FROM student_events
GROUP BY event
ORDER BY participants DESC;

Athena analyzes the data stored in S3 and returns the number of participants for each event.

The important point is that we do not need to move the entire dataset into a traditional database before performing the query.

Athena can query the data directly from S3.

🌍 Real-World Use Case

Amazon Athena can be used for large-scale analytics and log analysis.

For example, AWS describes organizations using Athena in analytics pipelines. One example is TNG FinTech Group, which uses Amazon Athena together with AWS Glue to perform serverless queries on financial transaction data. Athena helps its wallet service retrieve information about past transactions without requiring manual intervention.

Another use case is analyzing large datasets such as application logs, where teams can query data stored in S3 to investigate events and identify patterns. AWS specifically describes Athena as useful for analyzing logs and performing ad-hoc queries.

Advantages

No Server Management

Athena is serverless, so users don't have to maintain database servers or clusters.

Easy for SQL Users

Anyone familiar with SQL can start querying datasets without learning a complex infrastructure system.

Works Directly with S3

Data does not have to be moved into a separate database just to perform an ad-hoc query.

Automatic Scaling

Athena is designed to execute queries in parallel and scale according to workload.

AWS Integration

Athena works with services such as Amazon S3 and AWS Glue, and can integrate with other AWS and external data sources.
Limitations / Things to Consider

Cost

Athena is not simply "free because it is serverless." Pricing depends on the selected pricing model and, for SQL queries, can depend on the amount of data processed.

AWS also charges normal S3 costs for storage, requests and applicable data transfer. Query results stored in S3 can also incur S3 charges.

For example, AWS currently provides an example where scanning 3 TB of uncompressed data under its per-query pricing model results in a $15 query cost. The actual cost depends on the pricing model, region and workload.

For students, it is important to avoid repeatedly scanning unnecessarily large datasets.

Complexity

Although SQL itself is easy to understand, managing schemas, partitions, data formats and permissions becomes more complicated as a project grows.

Scalability

Athena is designed to scale automatically, but inefficient queries can still process large amounts of data. Using compression, partitioning and columnar formats such as Parquet can reduce the amount of data scanned and therefore improve efficiency and cost.

Security

Security still needs to be configured correctly. Access to Athena and the underlying S3 data can be controlled using IAM policies and S3 permissions. Athena also supports querying encrypted S3 data and writing encrypted results.

Security

A cloud analytics service should not only be fast; it must also protect data.

Amazon Athena uses AWS security mechanisms such as IAM policies to control access. The underlying data is usually stored in Amazon S3, so S3 permissions and encryption are also important.

AWS recommends using IAM policies to restrict access to Athena operations, while access to the underlying S3 dataset must also be appropriately controlled.

For a college project, this means sensitive student information should not simply be placed in a publicly accessible bucket.

Conclusion

Amazon Athena demonstrates how cloud computing can simplify data analytics.

Instead of setting up and managing database servers, we can store data in Amazon S3 and use SQL through Athena to analyze it. Its serverless architecture, SQL support, integration with AWS Glue and ability to work with different data formats make it useful for many analytics scenarios.

For students, Athena provides an interesting way to learn cloud computing, SQL, data lakes and analytics together. A college project could use it to analyze student activities, attendance, events or other datasets stored in S3.

My key takeaway is simple:

Store the data in the cloud, query it with SQL, and let AWS manage the infrastructure.

And for me:

A for Amutha → A for Athena.

📚 References

Amazon Athena Documentation
AWS Amazon Athena Documentation
Amazon Athena Features
AWS Athena Features
Amazon Athena Getting Started Guide
AWS Athena Getting Started
Amazon Athena Pricing
AWS Athena Pricing
Amazon Athena Security Documentation
AWS Athena Security

CloudCraft

AMUTHA NILA AR — Tue, 15 Sep 2026 07:29:04 +0000

☁️ CloudCraft — My First Hands-On AWS Cloud Deployment

From an HTML file on my laptop to a website running on AWS.

As part of the CloudCraft Cloud Workshop, I got hands-on with AWS by

deploying a static website using Amazon S3 and exploring how services like CloudFront and Route 53 fit into the architecture.

This wasn't just about learning what each AWS service does.

I actually went through the console, created resources, configured permissions, hosted the website, tested the endpoint, and then tried to put CloudFront in front of it.

Here is my step-by-step journey.

☁️ Step 1 — Starting with AWS

The first step was getting familiar with the AWS Management Console.

The main services I worked with were:

AWS
│
├── Amazon S3
├── CloudFront
└── Route 53

The goal was to take a simple static website and make it accessible through AWS infrastructure.

🪣 Step 2 — Creating an S3 Bucket

The first actual resource I created was an Amazon S3 bucket.

I went to:

AWS Console → S3 → Create bucket

For the bucket configuration, I selected:

Bucket type: General purpose
AWS Region: Europe (Stockholm) — eu-north-1
Bucket namespace: Global namespace
Bucket name: amuthanila-04-15

The bucket name needs to be unique within the relevant S3 namespace.

After creating the bucket, it became the storage location for my website.

📂 Step 3 — Uploading Website Files

Once the bucket was created, I uploaded my website files.

My bucket contained:

amuthanila-04-15
│
├── index.html
└── cloud.jpg

The important file here is:

index.html

because it acts as the entry page for the static website.

🌐 Step 4 — Enabling Static Website Hosting

Next, I configured the S3 bucket for static website hosting.

I went to:

S3 → Bucket → Properties → Static website hosting

and enabled:

S3 static website hosting

with:

Hosting type:
Bucket hosting

AWS then provided a region-specific website endpoint.

My website could now be accessed through an S3 website endpoint.

However, this endpoint uses HTTP, not HTTPS.

That became an important reason to explore CloudFront next.

🔓 Step 5 — Configuring Access

Uploading the files isn't enough.

The browser also needs permission to retrieve them.

So I worked with S3 access configuration.

One of the concepts I explored was ACL — Access Control List.

ACLs provide a mechanism for controlling access to S3 resources.

This helped me understand that storing a file and allowing someone to access that file are two different things.

🛡️ Step 6 — Adding an S3 Bucket Policy

Next, I configured a Bucket Policy.

The policy I used allowed s3:GetObject access to objects in the bucket.

The basic structure was:

Principal
↓
Action
↓
Resource
↓
Allow / Deny

For example:

Action:
s3:GetObject

and the resource pointed to the objects inside my bucket.

This was one of the first places where AWS IAM-style permissions started making practical sense.

🏷️ Step 7 — Understanding Tags

I also explored S3/AWS resource tags.

A tag is basically a key-value pair used to identify and organize resources.

For example:

Project = CloudCraft
Environment = Learning

It looks simple, but tags become very useful when working with many cloud resources.

🔄 Step 8 — Enabling Bucket Versioning

Next came S3 Versioning.

I enabled versioning for the bucket.

Instead of simply replacing an object:

index.html
↓
new index.html

S3 can maintain different versions of the object.

Conceptually:

index.html
│
├── Version 1
├── Version 2
└── Version 3

This provides protection against accidental overwrites and helps with recovery.

🔑 Step 9 — Exploring Presigned URLs

Another concept I explored was the S3 Presigned URL.

A presigned URL provides temporary access to an S3 object.

Instead of making an object permanently public:

Private Object
↓
Temporary Presigned URL
↓
User gets access

The URL can have an expiration time.

This is useful for securely sharing private files for a limited period.

🌍 Step 10 — Understanding S3 Global Namespace

While creating the bucket, I also learned an important S3 concept:

Bucket names are globally significant in the traditional S3 general-purpose bucket namespace.

That means you can't assume a name like:

mybucket

will be available.

So choosing a unique bucket name is part of creating an S3 bucket.

🏗️ Step 11 — High Availability

Along the way, I explored the idea of High Availability (HA).

The basic principle is:

Don't design your application around a single point of failure.

Cloud architecture aims to provide resilience through redundancy and distributed infrastructure.

This made me look at AWS not simply as:

"A place where I upload my website"

but as:

Infrastructure designed to deliver applications reliably.

⚡ Step 12 — Moving to CloudFront

After getting the website working through S3, the next step was Amazon CloudFront.

The architecture changes from:

User
↓
S3

to:

User
↓
CloudFront
↓
S3

CloudFront acts as a CDN and can cache content at edge locations closer to users.

This can improve content delivery performance and also gives us a path toward serving the site over HTTPS.

⚙️ Step 13 — Creating the CloudFront Distribution

I went to:

AWS Console → CloudFront → Distributions → Create distribution

For the distribution, I used:

Distribution name:
my-portfolio

I selected:

Single website configuration

For the origin, I selected my S3 bucket:

amuthanila-04-15.s3.eu-north-1.amazonaws.com

I also enabled:

Grant CloudFront access to origin → Yes

This allows CloudFront to access the S3 origin while AWS can manage the required S3 bucket policy configuration.

🚧 Step 14 — The Unexpected Problem

Everything looked ready.

The CloudFront configuration showed:

Billing:
Free ($0/month)

Origin:
S3

CloudFront access:
Yes

Security:
Enabled

But when I tried to create the distribution, AWS stopped me with:

"Your account must be verified before you can add new CloudFront resources."

So the problem wasn't my S3 configuration.

It was an AWS account verification requirement.

Instead of randomly changing the configuration, I opened an AWS Support case to resolve the account verification issue.

And honestly, this was also part of the learning.

Because in real cloud work:

Things don't always fail because your code is wrong.

Sometimes the problem is permissions, account restrictions, quotas, billing, or service-level requirements.

🌐 Step 15 — Route 53

The next part of the CloudCraft journey is Route 53.

The purpose is DNS.

Instead of users having to remember a long AWS endpoint, DNS allows a domain name to point toward the application infrastructure.

The intended architecture becomes:

             🌍 USER
                │
                ▼
          ┌───────────┐
          │ Route 53  │
          │    DNS    │
          └─────┬─────┘
                │
                ▼
          ┌───────────┐
          │CloudFront │
          │    CDN    │
          └─────┬─────┘
                │
                ▼
          ┌───────────┐
          │    S3     │
          │  Website  │
          └───────────┘

🧩 What I Covered in CloudCraft

My first CloudCraft hands-on session covered:

AWS
│
└── S3
├── Bucket creation
├── Global namespace
├── Object upload
├── Static website hosting
├── ACL
├── Bucket Policy
├── Tags
├── Versioning
└── Presigned URLs
│
▼
CloudFront
│
▼
Route 53
💡 My Biggest Takeaway

Before this workshop, these could have looked like separate AWS terms:

S3. ACL. Bucket Policy. Versioning. CloudFront. Route 53.

After actually configuring them, I started seeing them as different layers of the same architecture.

Storage
↓
Access Control
↓
Website Hosting
↓
Content Delivery
↓
DNS

That's the part I found most valuable about the hands-on approach.