EVI (originally EVI-SCAN) is a digital forensics project, and at some point, I started wondering: How does a complex application actually get distributed to people around the world? And how would I even go about doing that?

That question introduced me to cloud platforms, and eventually, AWS.

I started exploring services, trying to understand compute, storage, databases, and everything else AWS had to offer. I experimented, broke things, learned a little, and broke a few more things along the way.

I even hosted a static page using Nginx.

Then came my first memorable AWS lesson.

The ₹2,300 lesson

I left a NAT Gateway running for days without fully understanding the cost implications.

When the end of the month arrived, I found myself charged approximately ₹2,300.

As a student, I was absolutely shell-shocked.

I was scared of using AWS again.

I started small and became extremely cautious about leaving anything running. In hindsight, I had discovered a particularly bad combination: being clueless about cloud costs and being paranoid about spending money.

Terraform: My accidental introduction to DevOps

I decided to start with something manageable. I built a café website called Brew & Bites using Amazon S3 and CloudFront.

Then I came across Infrastructure as Code and Terraform.

I didn't initially care about reproducibility, version control for infrastructure, or the many other benefits of IaC.

I had one objective: I wanted to be able to clean up my AWS resources without worrying that I had forgotten something running in the background.

And then I heard two magical words:

terraform destroy

That was the beginning of my journey into DevOps.

With Terraform, I could provision and tear down infrastructure more deliberately. Once I became more comfortable, I experimented with a three-tier architecture, incorporating EC2, S3, CloudFront, RDS, read replicas, CloudWatch, and a bastion host.

I was trying to explore as much as I could.

I had already worked with Flask and Gunicorn in Brew & Bites . Running the application on EC2 meant connecting through SSH, installing dependencies, configuring the environment, and dealing with package and version mismatches.

If I wanted to save money, I could destroy the infrastructure with Terraform. But every time I recreated it, I had to go through much of that setup again.

It was frustrating.

I didn't know it at the time, but I was beginning to encounter the problems that make automation and containerization so useful.

My first AWS certification

Around this time, one of my professors told me about AWS certifications.

My first reaction was essentially: Are they free?

When I learned that the Solutions Architect exam cost $150 and that even Cloud Practitioner cost $100, I had to reconsider. That was a significant amount of money for me as a student.

So I started with AWS Certified Cloud Practitioner.

I picked up practice questions by Stephane Maarek on Udemy, opened them, and got absolutely demolished.

Why were there so many AWS services? Who was supposed to remember all of this?

I did what anyone struggling to understand something in the age of AI might do: I turned to ChatGPT, asked questions, cursed at confusing explanations, and kept learning.

Along the way, I encountered serverless computing and containers for the first time. I had heard of Docker, but the AWS container ecosystem was still unfamiliar territory.

I crammed as much as I could and eventually booked the exam.

During the exam, I kept second-guessing myself. I started panicking, then forced myself to calm down and give the questions a fair attempt. Having time to review my answers helped, too.

And then I passed.

I was so relieved. I hadn't wasted that money after all.

I passed AWS Certified Cloud Practitioner on 29 June 2026

It was my first certification, but more importantly, it gave me the confidence to keep going.

Discovering containers and Amazon ECS

After Cloud Practitioner, I started exploring serverless services, containers, and AWS managed services in greater depth.

That's when I came across Amazon ECS.

Remember my frustration with repeatedly connecting to EC2, installing packages, and dealing with version mismatches?

Containers offered a better way to package the application and its dependencies, while ECS gave me a way to manage running containers without having to manage every aspect of the underlying infrastructure myself.

I reworked Brew & Bites to use containers.

For me, this was an important moment because I wasn't learning a service simply because it appeared in an exam question. I was exploring it because I had a problem, and the service offered a way to address it.

The project was becoming a place to experiment, make mistakes, and understand why particular architectural choices mattered.

The Solutions Architect journey

Eventually, I heard about the Solutions Architect role itself.

And I became excited about the possibility of learning something new.

Cloud Practitioner had familiarized me with AWS, but I wanted to develop my ability to reason about infrastructure and solve architectural problems.

My next step was AWS Certified Solutions Architect – Associate.

I discovered Tutorials Dojo's practice tests and approached preparation much as I had before: explore, get frustrated, rage a little, calm down, and learn.

Then I attempted a timed practice test.

I managed around 35 questions out of 65 before the entire two hours had disappeared.

I remember thinking: What on earth is this?

The sheer size and complexity of the questions humbled me. I stopped preparing for about a month, focused on other things, and continued working on Brew & Bites.

Eventually, I returned to my preparation and set myself a deadline.

I worked through practice sets one after another, asked questions about the concepts I didn't understand, and gradually expanded my knowledge. I started recognizing patterns in the questions and becoming more comfortable with scenarios that had initially felt completely unfamiliar.

There was still plenty of self-doubt.

When I finally scheduled the exam, I was nervous. The stakes felt even higher because the exam cost $150.

I wouldn't say I felt completely prepared. Instead, I trusted myself to work through the situations presented to me.

I passed AWS Certified Solutions Architect – Associate on 8 September 2026,

Unlike my first certification, I had to wait for the result. Seeing that congratulations message and the blue certification badge was an incredible feeling.

It was a big moment for my confidence, and, of course, my wallet.

Passing Cloud Practitioner had also earned me a 50% discount voucher for the next exam, so my SAA exam cost $75 rather than the full $150.

That discount was a welcome bonus.

Returning to the project that started everything

So, what happened to EVI?

The very project that introduced me to cloud computing was still there, and I was beginning to look at it differently.

Because EVI is a digital forensics application, security matters enormously. I started thinking more deliberately about security, availability, and the consequences of architectural decisions.

The AWS Well-Architected Framework and AWS documentation helped me understand these considerations more systematically.

I was beginning to think about trade-offs.

There isn't always one universally correct architectural choice. Decisions depend on the application's purpose, its users, its security requirements, its operational constraints, and its budget.

And EVI gave me a reason to consider those questions beyond an exam scenario.

Local-first or web-based?

My initial idea was to distribute EVI as a desktop application that people could run on their own computers.

Since the application uses a local LLM, this approach made sense: the processing could happen on the user's machine, and their data would not need to leave their computer for that local workflow.

However, I discovered a practical limitation. I couldn't simply package LM Studio itself into my application and expect everything to work out of the box. Users would need to install and configure the required local inference software themselves, or I would need to explore another supported way of distributing the model runtime.

The local-first approach remained a sensible option, but it raised questions about installation, compatibility, hardware requirements, and the overall user experience.

Then I started thinking about a web version.

What would its architecture look like? How would authentication and access control work? What would need to be protected? How would I approach availability? What should run locally, and what could reasonably be handled by cloud infrastructure?

I started designing an architecture with those questions in mind, and I later deployed a containerized version on AWS, which I describe below. The security design is still evolving, and I'm not presenting it as a finished production system.

The original question was about getting an application to users around the world.

Now I'm also asking what it takes to design that application responsibly for the people who will use it.

Where EVI is now

The project that started all this is now containerized and deployed on AWS. Terraform provisions the VPC, ALB, ECS Fargate, EFS and Secrets Manager, and a GitHub Actions pipeline scans images with Trivy and deploys through OIDC, with no long-lived keys.

Along the way I debugged ALB health checks failing on a 302 redirect and secrets access failing on the wrong IAM role.

The code is open source: EVI-Platform on GitHub.

What I learned

• Set a billing alert before you build anything. A forgotten NAT Gateway is an expensive way to learn.

• Terraform started as a cleanup tool for me, and that was reason enough to learn it.

• Learn a service when you have a problem it solves. It sticks far better than learning it for an exam.

• Passing two certifications is a foundation, not the finish line. Operating real systems teaches different things.

What's next

I'm learning Kubernetes next, then adding monitoring with Prometheus and Grafana. I'm also looking for a DevOps/cloud internship, and I'd like to apply to the AWS Community Builders program. If you work in this space, I'd love to hear what you'd learn next.

Thanks for reading.