Two dates. In December 2021 I was stuck at home during COVID, earning my first AWS training badges. In July 2026 I hosted Track 2 at AWS Community Day Bengaluru. Almost every opportunity I got in between came through AWS and the people around it. This post is how that happened, and what I build on AWS now.
Where I started
I grew up in a small town with little to no exposure to computers or the internet. I got my first laptop when I went to college, and my first internet connection with it, a very limited one.
Then one of my college seniors got a job at AWS. I was super excited. If someone from my college could get there, maybe I could also learn programming properly and one day become a great software engineer.
Somehow, COVID happened, and I was stuck at home for around two years. That's how I really got into tech. AWS got me excited, so I went through AWS Academy Cloud Foundations and Machine Learning Foundations and earned both training badges in December 2021. I also completed the Udacity AWS ML Foundations Nanodegree. These are training badges, not certifications. They taught me what the services are. Running them came later, with the community.
Community before AWS
I was already in communities before I found the AWS one, mostly in Web3. From 2022 to 2024 I was a chapter lead for The Phoenix Guild, first in Bhopal and then in Karnataka. I organised meetups and bootcamps, spoke at them and ran the hands-on workshops.
In October 2023 I spoke at RV University on making a first pull request for Hacktoberfest, then ran a live workshop where students opened over 50 PRs during the session. That same month I volunteered at DevOpsDays Bengaluru, and I still help that team today. In December 2023 I went back to my college to run a workshop on open source and developer practices.
Every event here, with photos and links, is on my community page, if you want to check any of it.
So I knew how to show up for a community. What I didn't have yet was a cloud one.
Finding AWS User Group Bengaluru
I finished my degree in 2023 and came to Bengaluru. I found AWS User Group Bengaluru online, joined, and went to my first meetup that year. Today the group has over 15,700 members on Meetup and has run 147 events.
I didn't start on a stage. I started by helping at meetups, and I kept helping. In 2025 I joined the organising team.
The biggest change was who I learned AWS from. Before, it was course videos. In the group, it was people who run AWS in production. That's when I started building on AWS for real.
What I build on AWS now
The biggest thing I build and maintain on my own is a production platform that runs entirely on AWS. It takes a founder through registering a company in India, one step at a time. They pick an entity type, check a name, pay, upload their documents and track the filing. Behind it there's an admin dashboard, OCR on the uploaded ID documents and a WhatsApp support bot. I designed it, I deploy it, and I fix it when it breaks. Here's how it's set up.
The frontend is Next.js on AWS Amplify. A GitHub Actions workflow mirrors main to CodeCommit, waits for the Amplify build and then checks the live site. A push that only touches markdown skips the build. If I push twice in a row, the latest push wins and the older build gets cancelled, so a quick re-push doesn't wait around five minutes behind a stale build.
The API is FastAPI in Docker. GitHub Actions pushes the image to ECR and deploys it to ECS on Fargate through GitHub OIDC, so no long-lived AWS keys sit in GitHub. Before rollout, the workflow smoke-tests the image by importing the app, which catches an import error before ECS starts a single task. The deploy also reads the live production task definition, which is the source of truth for secrets and environment, and refuses to ship if it has drifted, say to a dev default secret or to refresh cookies that aren't hardened.
When the migration files change, the deploy runs the database migrations as a one-off Fargate task. Celery workers handle background jobs, with SQS as the broker in production.
For document uploads, the API gives the browser an S3 presigned POST and the file goes straight to S3, so the backend never carries the bytes. Browsers sometimes block that direct upload over CORS. When they do, a server-side upload proxy takes over. Secrets Manager holds the secrets, and the services log named events to CloudWatch, so I can filter for one webhook or one job run instead of scrolling through everything.
ECS Exec is off on the service, so to run a script against production I wrote a runner that launches a one-off Fargate task with the service's own task definition, the same environment, network and database access. ECS caps the command override at 8,192 bytes, so the runner gzips and base64-encodes the script before sending it. It lets me work with live data without turning ECS Exec on.
Building in the open
Some of what I build is public, so anyone can read the code and run it.
stub is a spend ledger for AI agents, built on Amazon Aurora DSQL. It's MIT licensed, and the SDK is on npm as trystub. The problem is simple. An agent with a payment method and a retry loop can burn a budget overnight, and per-session limits don't stop a whole fleet. I wanted the guarantee to come from the database, not from application luck.
DSQL has no SELECT ... FOR UPDATE. It runs optimistic concurrency, so the textbook spend check can't be written. So every spend also updates a balance row, and that row becomes the lock. When two spends race, the loser gets SQLSTATE 40001 and retries against the fresh balance, and the balance never goes negative. Payments go reserve, pay, then settle, so a retry replays the ledger and never the payment.
I picked DSQL because it's the only one of the three AWS options that gives active-active multi-region strong consistency. DynamoDB global tables are eventually consistent, and Aurora PostgreSQL Global Database has a single writer. stub ships a harness that races a naive retry loop against it. The naive version sends about $43 of payments against a $3 budget. stub sends exactly what committed. I benchmarked the downside too. One hot balance row tops out around 300 to 450 operations a second on local Postgres, and splitting it into 8 shards gave a 1.2 to 2.8 times gain. I wrote the full design up in this post.
Unforged is the second one, built for the AWS Builder Center Zero to Shipped hackathon. Small sellers in India often take a UPI payment screenshot as proof, and a screenshot can be edited, or a real one shown again for a second order. Unforged checks the screenshot against the credit alert the seller's bank emailed, which the bank signs with DKIM, and lets each bank credit pay for one order only. Amazon Textract reads the screenshot. Code decides the verdict, one of six, with no fraud score.
It runs on CloudFront, S3, API Gateway, Lambda, Aurora DSQL and AWS KMS, all in one CDK stack. I measured it. Fifty claims on one bank credit, over 20 rounds, got exactly one winner every round, where a plain check-then-insert approved 1,000. All 37 real signed emails failed after a one-character edit. Fifty simultaneous claims through CloudFront, over 10 rounds, gave 500 requests with 0 errors. Every receipt is signed with a KMS key and hashes the one before it. The repo is public, and I wrote up how I built it.
Track 2
I was part of the AWS User Group Bengaluru team running AWS Community Day Bengaluru 2026, on 11 July at NIMHANS Convention Centre. There were three emcees and three breakout tracks after the first break, one track each. I emceed the main stage for a stretch, then hosted Track 2, Serverless and Data.
The organisers gave us a clear brief. Research each speaker "so that it is not just about calling the speaker and mentioning the session details", and "bring life to the event". They also asked us to keep pointing people to the sponsor booths in the breaks and to the activities running in parallel, the Architecture clinic, the Community Zone and the Builder's Mic.
I researched every Track 2 speaker before the day. The photos from the day are on my community page. Serverless and Data are the services I build on, so I could introduce each talk knowing what it was actually about.
Judging First Commit
In September 2026 I judged the builds at First Commit, on the Bharat Builds Tour. In 2021 I was learning AWS from courses at home. Five years later I was scoring other people's AWS builds.
What moved my score was one real problem, a 3-minute video that shows the AWS piece working instead of mentioning it, and one feature that runs over five that almost do.
The same month, on 27 September, I cleared Claude Certified Developer - Foundations. A friend I made through the AWS community helped me get it over the line.
What changed
- In 2021 I had AWS training badges. Today I run a production platform on Amplify, ECS on Fargate, RDS, SQS and S3.
- I've shipped two public projects on Aurora DSQL, with results anyone can rerun.
- I went from helping at meetups to the organising team in 2025.
- I emceed the main stage and hosted Track 2 at AWS Community Day Bengaluru 2026.
- I judged AWS builds at First Commit.
- A friend from the community helped me clear a certification.
None of that came from a course alone.
If you're where I was
Find your local AWS User Group. I found mine online. Help at meetups before anyone asks you to, because that's how I ended up on the organising team. When you introduce a speaker, read up on them first. And build something real on AWS and run it yourself.
Why re:Invent
re:Invent 2026 runs from 30 November to 4 December in Las Vegas. Both my public projects run on Aurora DSQL, and I have questions about it I can't answer from the docs. I'd take those to Ask the Experts and the builders' sessions, then bring what I learn back to AWS User Group Bengaluru, the group that got me here.