DEV Community: Ananthika C

Ananthika Unlocks Athena: SQL Wisdom Without a Single Server ⚡

Ananthika C — Tue, 15 Sep 2026 23:27:36 +0000

By Ananthika — M.Sc. AI & ML, Coimbatore Institute of Technology

When I sat down to pick an AWS service for this assignment, I wanted something that actually matched my name — and the moment I saw Amazon Athena, it felt too perfect to skip. AWS named the service after Athena, the Greek goddess of wisdom and strategy, and that felt fitting: this is a service that lets you extract wisdom — real answers — out of raw data, without spinning up a single server. Most of my classmates were heading straight for S3 or EC2, so I decided to explore something a little less crowded but just as powerful.

Introduction

What is Amazon Athena?

Amazon Athena is an interactive, serverless query service that lets you analyze data directly in Amazon S3 using standard SQL. There's no need to load data into a database, set up a cluster, or manage any infrastructure — you simply point Athena at your data, define its structure, and start writing SELECT statements. Under the hood, Athena is built on Presto (now Trino) and Apache Hive for query execution and table management.

Why was it created?

Before Athena, if you wanted to run SQL-style analytics on files sitting in S3, you typically had two painful options: build and manage your own Hadoop/Presto cluster, or first load everything into a data warehouse. Both approaches cost time, money, and DevOps effort — especially for one-off or exploratory queries. AWS launched Athena in 2016 to remove that friction entirely. The idea was simple: let people query data where it already lives and pay only for the queries they actually run, instead of paying for idle infrastructure 24/7.

How It Works

Athena's workflow is refreshingly simple once you see it laid out:

Your raw data (CSV, JSON, Parquet, ORC, Avro, log files, etc.) sits in an S3 bucket.
You define a table schema describing that data — either manually or automatically using an AWS Glue Crawler, which scans the files and builds the schema for you in the AWS Glue Data Catalog.
When you run a SQL query, Athena reads the schema from the Glue Data Catalog, scans only the relevant data in S3, and executes the query using its distributed engine — all without you provisioning any servers.
The results are written back to a location in S3 that you specify, and you can view them instantly in the console or pull them into a visualization tool like Amazon QuickSight.

Figure: How a query travels from raw S3 files, through the Glue Data Catalog, into Athena, and out to results/visualization.

Key Features

1. Truly Serverless
There is nothing to provision, patch, or scale. AWS manages all the underlying compute; you just submit queries. This is a huge advantage for a student or small team that doesn't want to babysit infrastructure.

2. Pay-Per-Query Pricing
Athena charges based on the amount of data scanned per query (as of writing, around \$5 per terabyte scanned), not on server uptime. Run a query, pay for that query — nothing more. Storing data in compressed, columnar formats like Parquet can cut costs dramatically because Athena scans far less data.

3. Standard ANSI SQL Support
You don't need to learn a new query language. If you already know SQL — which most of us do from our database courses — you can start querying massive datasets on day one. Athena also supports complex queries: joins, window functions, CTEs, and nested/semi-structured data (JSON, arrays, structs).

4. Seamless Integration with the AWS Ecosystem
Athena works naturally with AWS Glue (schema/catalog management), Amazon QuickSight (dashboards), AWS Lambda (triggering queries programmatically), and Amazon S3 (as both source and destination), making it easy to build a complete analytics pipeline using only managed services.

5. Federated Query Support
Beyond S3, Athena can query other sources too — relational databases, DynamoDB, on-prem systems — through data source connectors, so you're not limited to a single storage layer.

College / Student Use Case 🎓

Here's where Athena becomes genuinely useful for a department like ours at CIT. Imagine our college's student attendance and academic performance logs are exported weekly as CSV files from the ERP system into an S3 bucket — attendance sheets, assignment marks, lab records, and placement drive data, sitting as flat files across different folders.

Instead of writing a custom backend to answer questions like "Which department had the lowest average attendance last semester?", a faculty coordinator (or a student project team) could simply:

Drop the exported CSVs into S3.
Run an AWS Glue Crawler once to detect the schema.
Query the data instantly with SQL through Athena — no database server, no ETL pipeline, no waiting.

This is exactly the "analyze data that's just sitting there" problem Athena is designed for — a realistic way a college IT cell or a final-year project could extract insights from scattered institutional data without heavy infrastructure.

Simple Example

Suppose our S3 bucket s3://cit-student-data/attendance/ contains CSV files with columns: student_id, department, month, attendance_percent.

Step 1 — Create a table pointing to the S3 data (via Athena's Query Editor):

CREATE EXTERNAL TABLE attendance (
  student_id            STRING,
  department             STRING,
  month                   STRING,
  attendance_percent     DOUBLE
)
ROW FORMAT DELIMITED
FIELDS TERMINATED BY ','
LOCATION 's3://cit-student-data/attendance/'
TBLPROPERTIES ('skip.header.line.count'='1');

Step 2 — Query it like any relational table:

SELECT department,
       ROUND(AVG(attendance_percent), 2) AS avg_attendance
FROM attendance
WHERE month = 'August'
GROUP BY department
ORDER BY avg_attendance ASC;

Within seconds, Athena scans only the relevant files and returns a ranked list of departments by average attendance — no server started, and I'm billed only for the data that query scanned.

Advantages

No infrastructure management — ideal for students, startups, and teams without dedicated DevOps support.
Cost-efficient for occasional or exploratory analytics, especially compared to running an always-on database.
Fast to get started — from raw files in S3 to your first query result in minutes.
Scales automatically to handle small experimental datasets or genuinely large-scale data, without any configuration change on your part.
Works with data as-is, in open formats, so you're never locked into a proprietary storage system.

Limitations / Things to Consider

Cost: Billing is based on data scanned, so poorly structured queries (like SELECT * on huge, uncompressed CSV files) can get expensive quickly. Partitioning data and using columnar formats like Parquet is essential for cost control.

Complexity: Simple queries are easy, but managing schemas, partitions, and the Glue Data Catalog for large or messy datasets can become non-trivial as file structures evolve.

Scalability: Athena scales well for read-heavy analytical queries but isn't meant for transactional workloads (frequent small updates/deletes) — it's an analytics engine, not an OLTP database.

Security: Access is controlled via IAM policies and S3 bucket policies, and query results are also stored in S3, so those locations need securing too. For sensitive data like student records, encryption at rest and fine-grained access control (e.g., via Lake Formation) matter.

Conclusion

Amazon Athena turns a plain S3 bucket into something you can query like a database — instantly, without servers, and without upfront cost. For a student like me, it's a great entry point into cloud-scale analytics because it builds directly on SQL skills I already have, while teaching real concepts like schema-on-read, columnar storage, and pay-per-use cloud economics. Whether it's analyzing institutional data, a personal project dataset, or logs from an IoT experiment, Athena makes "just query the data where it lives" a genuinely practical reality — and honestly, having "Athena" as my AWS service felt like a happy coincidence I couldn't pass up.

References

AWS, "What is Amazon Athena?" — https://docs.aws.amazon.com/athena/latest/ug/what-is.html
AWS, "Amazon Athena User Guide" — https://docs.aws.amazon.com/athena/latest/ug/
AWS, "Amazon Athena Pricing" — https://aws.amazon.com/athena/pricing/
AWS, "AWS Glue Data Catalog" — https://docs.aws.amazon.com/glue/latest/dg/catalog-and-crawler.html
AWS, "Athena Federated Query" — https://docs.aws.amazon.com/athena/latest/ug/connect-to-a-data-source.html

Workshop on Cloud Native Systems & AI Integra

Ananthika C — Tue, 15 Sep 2026 07:03:53 +0000

🚀 What I Explored

Let's go through what I did step by step.

1. 🪣 Creating an Amazon S3 Bucket

I started by exploring Amazon S3 (Simple Storage Service).

Amazon S3 is an object storage service that allows us to store and retrieve different types of data such as images, documents, HTML files, videos, application assets, and backups.

For the workshop, I created an S3 bucket with the name:

ananthika-05-15092026

After creating the bucket, I explored the different options available for managing objects, permissions, and website hosting.

Figure 1: Creating my Amazon S3 bucket.

2. 🖼️ Uploading an Image Object

Once the bucket was created, I uploaded an image into it.

This was my first practical interaction with S3 as an object storage service.

The image became an object inside my bucket, allowing me to understand how S3 stores individual files and organizes them using object keys.

Figure 2: Uploading an image object to my S3 bucket.

This simple step helped me understand one of the fundamental concepts of S3: storing files as objects inside a bucket.

3. 🌐 Uploading My Portfolio Website

After uploading the image, I uploaded my index.html file to the same S3 bucket.

This index.html contained my portfolio website.

My bucket now contained both the image and the HTML file:

ananthika-05-15092026/
│
├── image
│
└── index.html

Figure 3: My image and index.html stored inside the S3 bucket.

At this point, the files were stored in S3, but I still needed to configure the bucket to serve the HTML file as a website.

4. 🌐 Enabling Static Website Hosting

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

I enabled the static website hosting option and specified:

Index document: index.html

This tells S3 which HTML file should be served as the main page when someone accesses the website.

Figure 4: Enabling static website hosting and setting index.html as the index document.

This was an interesting step because I could see how a simple HTML file stored in cloud storage could be served as an actual website.

🔐 5. Configuring the S3 Bucket Policy

The next step was configuring permissions.

Simply uploading index.html to S3 doesn't automatically make it publicly accessible.

To allow users to retrieve the website objects, I configured an S3 bucket policy using JSON.

The policy I worked with followed this structure:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::ananthika-05-15092026/*"
    }
  ]
}

Here, the important part is:

"Action": "s3:GetObject"

This specifies that the objects in the bucket can be retrieved.

The resource:

"arn:aws:s3:::ananthika-05-15092026/*"

refers to the objects inside my S3 bucket.

After configuring the required permissions, my S3-hosted website became accessible through the website endpoint.

🖥️ 6. Viewing My Portfolio Website

The next exciting part was actually seeing my portfolio website running.

My index.html, which was initially just a file sitting inside an S3 bucket, was now being served as a website.

Figure 6: My portfolio website hosted using Amazon S3.

This helped me understand how static websites can be deployed without setting up a traditional web server.

The basic flow was:

index.html
     ↓
Amazon S3
     ↓
Static Website Hosting
     ↓
Website Endpoint
     ↓
My Portfolio

⚡ 7. Creating an Amazon CloudFront Distribution

After successfully hosting my portfolio using S3, I explored Amazon CloudFront.

CloudFront is AWS's Content Delivery Network (CDN). It is designed to deliver content to users through a globally distributed network of edge locations, helping reduce latency.

I created a CloudFront distribution and configured my S3 bucket as the origin.

The architecture now looked like this:

                    ┌─────────────────┐
                    │      User       │
                    └────────┬────────┘
                             │
                             ▼
                    ┌─────────────────┐
                    │  Amazon         │
                    │  CloudFront     │
                    │      CDN        │
                    └────────┬────────┘
                             │
                             ▼
                    ┌─────────────────┐
                    │    Amazon S3    │
                    │                 │
                    │   index.html    │
                    │     image       │
                    └─────────────────┘

Once the distribution was created, CloudFront provided a distribution domain that could be used to access the content.