DEV Community: Rohini Gaonkar

Bigger AI models aren't always better. Here's how to actually choose.

Rohini Gaonkar — Fri, 15 May 2026 16:58:32 +0000

In the previous post, I showed you two models answering the same question. One hallucinated confidently. The other knew when to stop.

And a bunch of you asked: okay, but which one should I actually use?

Haiku, Sonnet, Opus. Micro, Lite, Pro. Mini, Small, Large. There are dozens of models and they all sound like perfume brands. How are you supposed to pick one?

That's this post. I'm going to take one prompt, run it through two models (one small, one large), and show you what's different. Then I'll give you a simple framework for choosing the right one.

The demo: same prompt, two models

I went back to the recipe from the first post. Same recipe. Same question. Two different model sizes.

The prompt:

"I'm cooking this for six people on Saturday. One is vegan, one is gluten-free. Adapt the recipe for me, give me a shopping list, and a timeline starting from 4pm."

The small model

Quickly, it gave me a shopping list, a timeline, and basic adaptations. Nothing fancy, but everything I asked for. If I just need a quick answer and I'm going to double-check it anyway, this works.

For a lot of everyday tasks, this is genuinely all you need.

The large model

Same prompt but a very different response.

It added a whole "Strategy for the vegan guest" section explaining why you should make a parallel pot instead of adapting the main dish. It gave me a timeline starting from the night before. Separated prep into phases. Told me to keep the rice pots separate so nothing touches the vegan side. Scaling math for going from 4 servings to 6. It even gave me an oven method AND a stovetop method as alternatives.

More thorough and more considerate. But did I need all of that for a Saturday dinner? Maybe or maybe not.

There are medium-sized models in between these two and they exist in every family. I'll tell you when to reach for them later.

But the contrast between small and large is where our today's lesson lives.

Why models come in sizes

Let's take a simple example.

My son is two. If I ask him what he wants for dinner, he says "pasta." Done in two seconds without any deliberation.

If you ask me what to make for dinner, I'm thinking: what's in the fridge, what did we have yesterday, does he need more protein today, is it too late to start something that takes 40 minutes, should I batch-cook for tomorrow. Ten variables that will take me five minutes. I will give you a better answer, but slower.

Models work the same way.

A model's "size" is roughly how many parameters it has.

Think of parameters as the variables it can hold in its head when making a decision. More variables, more nuance, more ability to handle complex tasks. Fewer variables, faster and cheaper, but less sophisticated.

My son doesn't need ten variables to pick dinner. He just needs to decide. And for a lot of tasks, that's all you need from a model too. A fast answer. Not a perfect one.

Training a big model costs more. Running a big model costs more per question. And it's slower, because there are more variables to weigh for every single response.

So why not just always use the biggest one? Two reasons.

First, cost.

If you're building something that handles thousands of requests, the difference between a small model and a large model is the difference between a reasonable bill and a terrifying one.

Second, and this is the one people miss: bigger isn't always better.

For simple tasks, a big model can actually overthink it. Give you more than you asked for. Take longer to say something the small model said in two seconds.

The model families you see (Haiku/Sonnet/Opus, Micro/Lite/Pro) are just size tiers from the same provider. Same architecture, different capacity. Like buying a car in compact, sedan, or SUV. Same manufacturer. Different trade-offs. You don't take the SUV to grab milk. You don't take the compact on a cross-country road trip with three kids.

Tokens and pricing: how you actually pay

Models don't charge by the question. They charge by the token.

What's a token? It's a chunk of text. Not quite a word, not quite a letter, but roughly three-quarters of a word.

Take the sentence: "Adapt this recipe for a gluten-free vegan." Seven words but nine tokens. Some words get split, some punctuation becomes its own token.

You don't need to memorise this. Just know: token count and word count aren't the same thing. A full page of text is around 400 tokens. A million tokens is roughly a 750,000-word book.

There's a free tool called Tiktokenizer where you can paste text and see exactly how a model breaks it into tokens. It's weirdly satisfying. Try it.

One thing that surprised me: different models tokenize the same text differently. I sent the exact same prompt and recipe to both models. The small one counted 6,548 input tokens. The large one counted 16,685. Same words, different tokenizers under the hood.

And here's the thing: you get charged twice. Once for the tokens you send in (your question). And once for the tokens the model sends back (its answer). Input tokens and output tokens. They're priced separately, and output is always more expensive, because that's where the model is doing the work.

Real numbers

On Amazon Bedrock, for the Claude family (pricing as of May 2025, check current prices here):

Model	Size	Input (per 1M tokens)	Output (per 1M tokens)
Haiku	Small	~$1	~$5
Sonnet	Medium	~$3	~$15
Opus	Large	~$5	~$25

That's 5x more expensive from small to large. Same question, same answer, but 5x the price on both sides.

If you're asking one question yourself, who cares. The difference is fractions of a cent. But if you're building an app that handles ten thousand requests a day, each one generating a few hundred output tokens, that 5x multiplier turns into real money fast.

The best model is the model you can afford to run at the scale you need.

Where it breaks: when bigger is worse

Let's go back to the large model's response and look at the over-engineered parts. The timeline starting from the night before. "Marinate chicken in yogurt and spices, overnight is best." Fry the vegan portion first in clean oil, then fry the chicken onions in separate oil. Keep the rice pots separate. An oven method AND a stovetop method as alternatives.

The small model? A simple table. 4:00pm, start marinating. 4:05, fry onions. 5:15, into the oven. 7:00, serve. Done.

Opus is doing project management for my Saturday dinner. And here's the real cost of that overthinking.

The small model: 18 seconds, about 1,900 output tokens.
The large model: 44 seconds, 2,700 output tokens.

40% more output. 2.4x slower. And about 10x more expensive for that single request.

For a Saturday dinner, this is overkill. And if I were building an app that answers recipe questions for thousands of users, I'd be paying for all that extra thinking on every single request.

This is the trade-off. Bigger models are smarter, but "smarter" isn't always what you need. Sometimes you need fast, cheap, and good enough.

How to actually choose

Here's how I think about it.

First, the biggest factor: cost. We just saw a 5x difference between small and large. And that's per token. When the big model also generates 40% more tokens per response, it compounds fast. That alone narrows the field for most people. If you're building something, cost is the thing that decides what's even on the table.

If you can't afford to run it at the scale you need, it doesn't matter how good it is.

Start there. What can you actually sustain?

Then, once cost has set your boundaries, three questions help you pick within them.

1. How complex is the task?
Summarising an email? Small model. Writing a legal brief? Big model. Adapting a recipe? Probably medium.

2. How many times will you run it?
If it's one question from you personally, use whatever you want. If it's an app serving thousands of users, speed matters just as much as quality. Start small, upgrade only when the quality isn't good enough.

3. What are the stakes?
If a wrong answer ruins dinner, that's low stakes. If a wrong answer means bad financial processing logic that costs you millions, that's high stakes. Higher stakes, bigger model, plus verification on top.

That's it. Cost sets the ceiling. Complexity, volume, and stakes help you pick the floor. You don't need to memorise model names. You need to know what you're optimising for.

What about picking a provider?

I've been showing models from different providers. Claude, Nova, Llama. How do you pick a family?

Honestly? Pick the one that's available where you already work. If you're on AWS, you have access to all of them through Bedrock. If you're somewhere else, use what's there. The concepts are the same. Don't overthink the brand. Overthink the task.

One thing that confuses a lot of us early on: models and products are not the same thing. Claude is a model. But Claude inside Kiro (a coding IDE) behaves differently from Claude in the Bedrock Playground, which behaves differently from Claude on claude.ai. Same model underneath.

But each product wraps it with different instructions, tools, and context that shape how it responds. Kiro's Claude is tuned for writing code. The Playground's Claude is general-purpose. Same brain, different job description.

So when you see dozens of AI "products" out there, many of them are the same few models dressed up for different use cases. The model decides how smart it is. The product decides what it's pointed at, and priced accordingly.

Try it yourself

If you're just getting started: models come in sizes. Bigger is smarter but slower and more expensive. For most everyday tasks, a medium model is the sweet spot. Try a few and see which one feels right for what you're doing.

If you're more on the builder side: start with the smallest model that gives acceptable quality. Only upgrade when you can point to a specific failure the bigger model fixes. Don't start big and optimise down. Start small and justify up. And remember, you can use different models for different parts of the same system. The router doesn't need to be the same size as the reasoner. The model that decides which tool to call doesn't need to be the same one that processes the result.

Start small. Justify up.

What's next

We are going to talk why model forgets what you told it. Ride Along.

This post is part of the "Learning AI Out Loud" series, a cloud architect learning AI from first principles.

Follow along with the series

Thank you for featuring me! 💜

Rohini Gaonkar — Mon, 11 May 2026 16:21:23 +0000

AI in retro assembly and VR coding setups

Jess Lee for The DEV Team

May 11

Why does AI lie? Hallucinations explained simply

Rohini Gaonkar — Fri, 08 May 2026 16:37:02 +0000

In the previous post, I showed you an AI doing something genuinely useful, helping me adapt a recipe for a dinner party. We talked about the basic loop: send a prompt to a foundation model, get a response.

Today we're talking about why AI lies to you.

You know how AI sounds confident when it's completely wrong? It's called hallucination, and it's the thing that'll either make you trust AI long-term, or burn you badly.

The demo: same question, two models

I asked two different models the same question in Amazon Bedrock Playground:

"What happened at the recent Lyrids meteor shower?"

Model 1: Amazon Nova Micro 1.0

Nova Micro gave me details. Dates, locations, numbers, all delivered with complete confidence. It didn't hesitate. It didn't caveat. It just answered as if it knew.

But it doesn't know. Its training data ends in 2023. Anything after that is a gap it can't see. It didn't flag that. It just filled the gap with something plausible.

This is hallucination. The model invents something plausible to fill a gap it doesn't know how to admit. It's not lying on purpose. It's doing exactly what it's designed to do: predict what a useful-sounding answer looks like. It has no idea whether the answer is actually true.

Model 2: Claude Haiku 4.5

Same question, newer model, much more recent training.

Haiku told me straight: "I don't have access to current information. My knowledge was last updated in April 2024." Then it offered general facts about the Lyrids and suggested I check recent astronomy websites.

Progress. Newer models are better at recognising the edges of what they know.

I gave it a link to a Space.com article. It told me it can't browse the internet.

So I uploaded the PDF of that website article. There are limits to how big the file size can be so I provided it first few pages only. Then it answered accurately, pulling real details from the source.

So, in this case, we provided some context to the model and it gave me an answer based on that context.

The biography test

I asked Nova Micro:

"Tell me about Rohini Gaonkar."

It didn't hesitate. It told me I'm a "well-known Indian writer, scholar, and cultural critic." That I got my PhD in Comparative Literature from Duke. That I'm a professor at the University of Minnesota. That I've edited influential anthologies on postcolonial theory.

None of this is true. Not one detail.

The model doesn't know who I am. But it knows what an academic biography looks like. So it generated one. Complete with research interests, notable works, and recognition. All fabricated. All confident.

So Haiku knew when to stop. Nova Micro didn't.

But the underlying mechanism is the same in both models: prediction.

One has better guardrails. The other just fills every gap it finds.

Hallucination isn't just about training cutoffs. It's about the model filling gaps anywhere in what it knows. Names it hasn't seen. Niche topics. Combinations it was never taught. Better guardrails help. They don't make the problem disappear.

A note on the name test: I used my own name on purpose. If the model invents something weird about me, the only person affected is me. Be thoughtful if you try this with other people's names, especially private ones, or anyone who hasn't agreed to be part of your experiment. Whatever the model says about them, you've just generated and potentially broadcasted it. So, be cautious.

Why this happens: the architecture

Remember the loop from the last post:

Input (prompt) → Foundation Model → Output (response)

The model predicts what a useful answer looks like, based on everything it learned during training.

During training is the key phrase.

Training ends on a specific date, called the training cutoff. After that, the model is frozen. When you ask it about anything past that date, or anything it never quite learned, it has two options: say "I don't know", or do the thing it's designed to do i.e. predict.

And for a long time, these models weren't great at saying "I don't know". That's not what they were rewarded for in training. They were rewarded for producing fluent, useful-sounding answers. So that's what they produce. Even when the answer is made up.

Hallucination shows up in different flavors: fabricated facts (the biography), outdated information stated as current (the meteor shower), inconsistent reproduction even with the source right there (the quote test). There are others too, wrong attributions, sycophantic agreement (going along with something you said even when it's wrong), confident extrapolation (extending a pattern beyond where the data supports it).

The mechanism is always the same, prediction filling a gap, but knowing the flavor helps you design the right mitigation. We'll get into those mitigations in later posts when we talk about grounding, evaluation, and guardrails.

If you're a builder, this'll feel familiar. Think of a DNS cache. You move your app to a new server, update the DNS record, but for the next hour some users still get routed to the old IP. The cache doesn't know the record changed. It just serves what it has, confidently, because it was designed to always give you an answer fast.

Or autoscaling on the wrong metric. You scale on CPU. CPU is low, so the system thinks everything's fine. Meanwhile your queue is backed up with 10,000 unprocessed messages. The system is optimized to respond to one signal, so it confidently does nothing while things pile up.

An AI model works the same way. It was trained to always produce a helpful-sounding answer. So when it doesn't know something, it still produces a helpful-sounding answer. It doesn't have a "say nothing" instinct. It has a "say something useful-looking" instinct.

Modern models are much better at refusing. But the underlying shape of the problem doesn't go away. The model doesn't know what it knows. It just predicts.

"But ChatGPT can search the web?"

Yes, most chat tools today can look things up online. That's not the model itself doing the searching. It is a tool plugged into the model.

We'll get to how that works in a later post. For today, we're looking at the model on its own. No internet, no tools. Just what it learned.

The fix, and where the fix breaks

I gave Nova Lite the actual article as a PDF and asked it to quote the second paragraph.

It gave me a response. Then I asked the same thing again. Different answer. Same source, same conversation, two different versions of the same paragraph.

Even with the source right there, it didn't pull the paragraph verbatim. I asked the same question twice, same conversation, same document, and got two different versions. It's not retrieving. It's still predicting what that paragraph probably looks like. And prediction isn't deterministic.

This matters because a lot of people think "just give the AI the document and it'll be fine."

It's better but it's not perfect. Things can get complex and messy, especially for anything that depends on exact wording, like legal text, medical dosages, or contract clauses. You still need to verify the responses.

Context reduces hallucination. It doesn't eliminate it.

Three signs you should double-check

If you're using AI day-to-day, here are the tells:

1. Specific details you can't verify. Names, dates, numbers, URLs in an area you can't check. Assume 50/50.

2. Fluency on topics that should be fuzzy. Ask about something niche or recent, get a confident detailed answer, and be suspicious. Real expertise has hedges, hallucination doesn't.

3. Citations. Especially URLs. Models invent sources that look real. If you get a URL, open it. Nine times out of ten it's fine. The tenth time it's a made-up paper.

Try it yourself

If you're more on the builder side:
Remember, hallucinations aren't a bug you patch. They're a property of the system. You mitigate them with grounding (give the model real context), with instructions (tell the model to refuse when unsure), and later, with evaluation. Designing around them is the job.

If you're just getting started:
Remember, AI is NOT a search engine. It's a prediction engine that's really good at sounding right. Treat specific claims the way you'd treat a confident stranger at a party. Friendly, but verify before you repeat them.

Some examples I found on internet, for fun and educational purposes only: (Answers may change as models are catching up)

How many 'r's are in the word strawberry?
If I have to take my car to car wash, and the car wash is 100ft away. Should I drive or go walking?

What's next

Why are there so many of these things? Haiku, Sonnet, Opus. Mini, large, pro. And honestly, which one should you actually pick?

That's the next post. Ride along.

This post is part of the "Learning AI Out Loud" series, a cloud architect learning AI from first principles.

Follow along with the series

What Even Is AI? (I Took a Break & Had to Relearn Everything)

Rohini Gaonkar — Tue, 05 May 2026 18:38:06 +0000

I just came back from maternity leave. And honestly? I felt like I'd missed a decade in six months. I talked about starting small in my other blog Lost in the AI Hype, I Started Small

I've spent the last fifteen years designing cloud systems. And even I felt behind. AI went from a thing people were experimenting with to a thing everyone's apparently building with, and I had no idea where to start.

So I did what any architect would do. I went back to first principles.

I'm rebuilding my AI mental model from scratch in public. No math. No expert-level coding. Just real problems, the architecture underneath, and honest notes on where things might break.

If you prefer video, please watch Episode 1 of my video series . If you prefer reading, you're in the right place.

The demo: AI adapts a recipe in under a minute

Before any theory, let me show you what these models can actually do.

I opened Amazon Bedrock Playground, pasted a real recipe, and asked three questions with each one pushing the model a little further:

1. Extract and summarise

"What are the core techniques in this recipe, strip off the fluff?"

Clean, fast, useful. You might think: that's a fancy Ctrl+F (search).

2. Interpret and advise

"Looking at this recipe, what's the thing that's most likely to go wrong for someone cooking it for the first time?"

Now we're somewhere a search tool genuinely can't go. The model is reasoning about the recipe like spotting the bit where people actually mess up.

3. Personalise

"I'm cooking this for six people on Saturday. One is vegan, one is gluten-free. Adapt the recipe, give me a shopping list, and a timeline starting from 4pm."

This is the moment. I asked it something I'd normally spend twenty minutes thinking through. It gave me a starting point in ten seconds.

If you're curious but not technical, that's already useful.

If you're a builder, you're probably already thinking so what happened here.

So what actually happened?

Here's the architecture, as simply as I can put it.

I sent text called a prompt to a foundation model.

People throw around terms like AI, LLMs, and foundation models like they all mean the same thing but they don’t.

AI is the broad umbrella. It includes everything from recommendation engines and fraud detection systems to generative AI tools like ChatGPT.

Foundation models are a subset of AI, they are large models trained on massive datasets that can be adapted for different tasks. These aren’t just text models; they can generate images, video, speech, code, and more. Platforms like Amazon Bedrock give access to many of these models.

LLMs (Large Language Models) are a specific type of foundation model built for language tasks like answering questions, summarizing text, writing, or coding. So in my recipe demo, I was technically interacting with an LLM.

The simplest way to think about it:

AI → Foundation Models → LLMs

So, in our case it means its a big model trained on a huge mix of data for your day to day general purpose.

The model is a piece of software trained on an enormous amount of text: books, articles, code, conversations. It is not searching the internet. It learned patterns from all that text beforehand.

When I give it my prompt, it predicts the most useful response based on everything it learned.

Input (prompt) → Foundation Model → Output (response)

I've been building distributed systems for years, and a foundation model call is simpler than most of the APIs I'm used to. It's an HTTP request with text in, text out.

The complexity isn't in the call itself, it is in what the model learned before you or I ever showed up.

And this exact loop is what the entire current wave of AI is built on.

Every time you see a new Claude, or GPT, or Llama land, what's actually happening is someone trained a bigger or smarter version of this same idea.

Same loop. More data. Better prediction.

Where it breaks

The model doesn't know if it's right. It's predicting what a useful answer looks like. Sometimes that prediction is brilliant. Sometimes it invents something that sounds plausible and is completely wrong.

Every time you use one of these tools, ask yourself: what would I need to double-check before I trusted this?

That question is the single most useful habit you can build right now. We'll dig into why this happens in the next post.

Where the models live: Amazon Bedrock

You might've noticed I wasn't using ChatGPT or Claude's own website. I was using Amazon Bedrock.

Bedrock is where a bunch of foundation models live on AWS. Anthropic's Claude, Meta's Llama, Mistral, Amazon's own models, they are all callable through Bedrock, no need to run or train anything yourself.

The Playground is the easy door in, just type and go. Later in this series, when we start building, we'll call these same models from code. Same models, different door.

A note on my stack

I work at AWS. So the tools I use in this series are AWS tools like Bedrock for the models, and later, an AI-powered IDE called Kiro for building.

The concepts, though, aren't AWS specific. Foundation models, tokens, context windows, RAG, agents, these work the same way on any cloud. I'm showing you my stack. And honestly, I'm still figuring out which parts of it are great and which parts are a pain. You'll know which is which.

Try it yourself

If you're just getting started: open any AI chat tool (Bedrock Playground, Claude, ChatGPT, whatever you have access to), paste a recipe, a contract, a long email and ask it three questions:

One to summarise.
One to interpret.
One that's personal to you.

See what happens. That's your homework.

If you're more on the builder side: the mental model is simple: text in, model, text out. Everything we build in this series is a variation on that loop.

What's next

Next up: when AI sounds confident and is completely wrong. Why it happens, how to spot it, how to stop it.

This is a series. I'm learning this in public, building as I go, and being honest when things don't work. If that sounds useful, please follow along.

This post is part of the "Learning AI Out Loud" series, a cloud architect learning AI from first principles. Watch the video version or follow the series on dev.to.

Stop waiting to feel ready. You won’t. Not after a break. Not after life changes. Not when everything feels like it’s moving faster than you. I almost didn’t publish this.

Rohini Gaonkar — Wed, 15 Apr 2026 14:49:18 +0000

Lost in the AI Hype, I Started Small - DEV Community

And it helped me get back into tech without drowning TL;DR at the end Coming back to...

dev.to

Lost in the AI Hype, I Started Small

Rohini Gaonkar — Wed, 15 Apr 2026 14:32:01 +0000

And it helped me get back into tech without drowning

TL;DR at the end

Coming back to tech after a (maternity) break is a strange feeling.

You’re excited but also unsure where to begin. There are new tools, new terminologies and new way of doing things we did for decades.

But I didn’t try to figure everything out at one go, I just picked one small thing.

For me, that “one small thing” was finally building my portfolio collection.

Over the years, my content - blog posts, YouTube videos, conference talks, GitHub repos, social posts all of them scattered across dev.to, GitHub, YouTube, Instagram, LinkedIn, and AWS channels - has been scattered across a dozen different platforms. DEV.to, community.aws, YouTube, GitHub (two accounts!), LinkedIn, SlideShare... you name it. 🙇‍♀️

More than 80 pieces of content, scattered across platforms since 2015!!!

And honestly? Maintaining my existing site rohinigaonkar.com felt harder than starting from scratch.

I wanted something simpler, a lightweight site I can update by editing a single file, push to GitHub, and it's live. Easy to navigate, easy to maintain. No fluff.

I built this as my first project back from maternity leave, and I did it with Kiro, an AI-powered IDE from AWS that I'd never used before. Two firsts at once. It turned out to be the perfect re-entry project.

Building It with Kiro: My First Impressions

This portfolio had been on my mental to-do list forever, so the timing felt right. And rather than spinning up a complex stack to shake off the rust, I decided to keep it simple and lean on an AI coding assistant to help me get back into the flow.

Here's what stood out about the experience, starting with the simplest features and building up.

Last one might surprise you!!! 🤯

1. Chat-Driven Development

The entire project was built through conversation.

I described what I wanted, "I have this website where I collect my content shared across multiple social media websites. it is one true place where any tech content I posted on the web be it dev.to, github, youtube, instagram, and any aws first party channels, all of this to be collected as a timeline. can we build something that can be refreshed on demand and build this portfolio. make it professional looking. ask more intelligent questions as we go.", and Kiro asked clarifying questions even before writing a single line of code.

It asked about static vs dynamic, hosting preferences, design vibe, and data source approach. It even asked me about my identity. That back-and-forth shaped the architecture before any code was generated.

Once I provided response to all the questions, it help build the initial structure and also walked me through it.

Notice how after every conversation, it shows how many credits each prompt consumes, in real-time. That was nice!

There is a spec-driven development mode as well, which I would be testing for something more complex than this static website.

2. Web Search

Kiro searched the web to find my existing content across platforms. It looked up my dev.to profile, GitHub repos, community.aws presence, YouTube channel, and even my current website at rohinigaonkar.com. This gave it real context about who I am and what content already exists, so the portfolio wasn't built with placeholder data, it was seeded with my actual content from day one.

3. Explore Real-Time File Changes

As Kiro generated and edited the files, I could see every change happening in real time through the explorer. Either click the "Follow" option or click on the little "diff button" highlighted with yellow square below.

For example, it created index.html or content.js, I could immediately open them, review the code, and see the diffs. When it later modified content.js to add YouTube videos or reclassify talks vs videos, I could see exactly what changed and why.

4. Trusting Frequently Run Commands

Kiro ran shell commands like curl to hit APIs and extract data. It asked my permission to run it once or add it to trusted list of commands.

I also liked how it provided my levels of trust, like I can just execute this particular command or partial or the base command.

In autopilot mode, I could trust these commands to execute without approving each one individually. This was especially useful during the YouTube oEmbed batch processing, where Kiro ran 16 consecutive curl commands to fetch video titles, approving each one manually would have been tedious.

5. Iterative Refinement Through Conversation

The project evolved through multiple rounds of feedback:

I pointed out that "talks" should only mean conference/meetup presentations, not YouTube tutorial videos - Kiro reclassified everything accordingly
I noted that some AWS "talks" were actually just YouTube embeds on my website - Kiro dug into the pages, extracted the real YouTube URLs, and recategorized them as videos
I shared my personal GitHub profile separately from my work one - Kiro pulled repos from both and updated the refresh script to handle multiple accounts

Each round of feedback made the portfolio more accurate without starting over or deleting some other important information.

6. The YouTube Challenge : Hitting Walls and Finding Workarounds

This was the most interesting part as YouTube is heavily locked down:

Direct fetch failed - webFetch on youtube.com returned empty content
Rendered mode failed - returned only JavaScript bootstrap code, no actual page content
Search was noisy - web searches for my videos returned generic results, not my specific content
RSS feeds blocked - YouTube's channel RSS wasn't accessible either

*But Kiro didn't give up!!! 💜 *

It found workarounds on its own:

oEmbed API - Kiro discovered that YouTube's oEmbed endpoint (youtube.com/oembed?url=...) returns video titles as JSON, and used curl to call it directly. This became the reliable method for all 16 videos I shared.
Squarespace page parsing - For videos embedded on my website, Kiro parsed the raw HTML to extract YouTube video IDs from Squarespace's embed block JSON (double HTML-unescaping the content to find URLs like youtube.com%2Fembed%2Fi0zQpJPfSdU).
Thumbnail URL extraction - It even tried extracting video IDs from ytimg.com/vi/VIDEO_ID/hqdefault.jpg thumbnail patterns as a fallback.

The iterative problem-solving here like trying one approach, hitting a wall, pivoting to another, felt very much like how a developer would debug a scraping problem.

I loved how Kiro told me what it tried, it failed and it was going to try something else. We also worked together for a process that was a good compromise for both of us. Maybe in future I will have an agent to simplify this, but for now this solves my purpose!

The Result

A live static portfolio at rohinigaonkar.github.io with ~80 entries spanning 2015–2025, filterable by type (blogs, videos, repos, talks, social), searchable, and refreshable on demand via a Node.js script that pulls from GitHub and dev.to APIs. All built through conversation in a single Kiro session.

What's Next

I'll keep adding content as I publish it. The refresh script makes the API-sourced stuff automatic, and the manual entries take about 30 seconds each. I might add dark mode at some point, and maybe an RSS feed. But right now, the simplicity is the feature.

More importantly, this project reminded me that coming back doesn't have to be intimidating.

If you're returning from a break and looking for a low-pressure way to get back into coding, I'd recommend picking a passion project and giving Kiro a try. You might surprise yourself with how quickly you get back into the zone.

And follow along as I explore this world of AI.

TL;DR:
Returning to tech after maternity leave felt overwhelming, so I started small by building a portfolio site to consolidate 80+ pieces of content scattered across platforms since 2015. Using AWS Kiro (an AI-powered IDE) for the first time, I built the entire project through conversation—no complex setup needed. Kiro helped with web searches, real-time file changes, iterative refinements, and creative problem-solving (especially when YouTube's APIs were locked down). The result: a live, searchable portfolio at rohinigaonkar.github.io that's easy to maintain. The lesson? Coming back doesn't have to be intimidating—pick one small passion project and let AI tools help you get back into the zone.

Get into Cloud computing with no experience

Rohini Gaonkar — Wed, 08 Feb 2023 00:30:00 +0000

I have been working in the IT industry for almost 14 yrs now, in multiple roles, across the world, and luckily all of this experience has been with Cloud Computing technologies. Over the years hundreds of people have asked me same question - how do I get into Cloud based roles?

A lot of folks want to get into Cloud Computing roles BUT companies want to see experience on your CV/resume. It is a dilemma for lot of folks.

If you don't get hired into Cloud Computing projects, you can't get experience and without experience companies won't hire you

So I thought I should talk about this in detail and help folks who want to make switch to Cloud Computing, because Cloud is the new normal now and it should have a place on your resume.

Watch this short YouTube video on how you can build your skills, your resume and your brand to apply for jobs.

I do provide subtitles, and chapters so feel free to watch content you like.

Let me know in the comments section, if you have any questions or any topics I should elaborate more about. I am happy to guide folks so we all are successful in our own lives! I hope these give you a fair idea of where to start and motivate you to take your first steps into a successful career!

How to ‘Be your own cheerleader’

Rohini Gaonkar — Fri, 06 Jan 2023 17:12:08 +0000

Let me start by asking you a question -

do you feel unskilled at advocating for yourself and unsure of how to be proud of your work and accomplishments?

If you answered yes, then this blog post is for you.

Over the years, I have seen a common thread while mentoring tech community members – they do the hard work but they have poor self-esteem and self-worth. They do some amazing work, they have positively impacted so many lives, however, they don’t know how to showcase their work.

We humans tend to get demotivated over time and lose confidence in our own abilities. This impacts relationship with co-workers and even job interviews. Now some might not agree with me, but it is a harsh reality of today’s world; If you do not talk about your body of work, who will?

If you have attended my talks, then you would have heard me say this hundreds of times – BE YOUR OWN CHEERLEADER...!

If you do 99 things right and 1 mistake, which one do you obsess over?
Well, we typically obsess over that 1 mistake, because we are hard-wired to look at that one negative comment. Our memories are fickle, we tend to remember things that have stronger emotions associated with them. So how do you ensure that our minds do not obsess only on the negative, but also see the positives?

It’s simple, WRITE IT DOWN!

Trust me on this, I have done this activity with many of my mentees and it works EVERY. SINGLE. TIME. Identify the broad categories of your body of work – projects, volunteering, public speaking, blogging, social media, soft skills, certifications etc. Once you have identified the broad categories, list down all the achievements you can think of in these categories. It doesn’t matter if it is significant or not. This is YOUR list, and you don’t have to be ashamed of anything.

Are you usually quiet and you spoke up in your team meeting? Write it down! Pat on your back for overcoming the shyness, the fear. No one is going to judge you.

Once you write down the list, start adding meat to it.

For example, this is an actual excerpt from one of my mentees in Public Speaking category:

Conducted sessions for college students on zoom for Universities like X Y Z to spread awareness on Cloud, Helped students to be Market ready and mentor them for their innovative projects.

Now, if you are a recruiter or a manager who is building a case for your promotion, what would be your first reaction? do you get any idea on the impact of work here? No.

What about this..

Regularly conducts virtual sessions for college students for major universities like X Y Z, to spread awareness on Cloud. She continues to mentor students on their innovative projects, career guidance and be market ready.

Great so now with some basic language cleanup I made it concise, and a bit more professional.

However, we can do better. At this point, ask yourself a question – SO WHAT?

So, what should I do about this information? Why does it matter? Can I quantify this impact? Can I put it in perspective?

Regularly conducts virtual sessions for college students for major universities like X Y Z, to spread awareness on Cloud. The 15 sessions were attended by 2000+ students with avg CSAT 4.7/5. She continues to mentor students on their innovative projects, career guidance and be market ready.

Isn’t this better? You know what she does regularly, how many sessions, attended by how many students and that is an impressive CSAT (Customer satisfaction score). Provide examples using metrics or data is always more impactful than using fancy words or long paragraphs.

You can further make it more impressive by adding anecdotes or testimonials from attendees, and if this led to a further engagement like the Universities have now signed her up as a regular guest lecturer.

Make a collection

Create a folder on your computer for ‘appreciations’. Anytime someone says something nice about you, take a screenshot and store if for yourself. If you can, ask people to give you testimonials or LinkedIn recommendations. On days when you do not feel good, open this folder and read through. You will get instant motivation boost.

Make it a habit

I suggest doing this activity as soon as activities are done.

You can also create monthly, quarterly half-yearly and yearly snapshot of these activities.

If you are looking for a job change, make this list right now!

It will not only help you look at your accomplishments, this will help you show your interest and impact. You can add them to your resume or portfolio. During an interview, you can use this list to showcase impact and highlight your success stories.

You can build great examples using this for your behavioral-based interview questions in STAR method (Situation, Task, Action, and Result). Specifics are key; avoid generalizations. Give a detailed account of one situation for each question you answer, and use data or metrics to support your example.

Once you start building these writing skills, next time before you say yes for an activity, you will automatically assess if the activity has true measurable impact and helps you achieve your goals.

If you do not have the option of saying no, atleast you will assess how this activity impacts you in the greater scheme of things

Build your support system

Humans are social animals. While you are doing this writing activity by yourself, you need your own support system. Find people in the community, at your workplace, in your friend circle who support you and cheer you up on these accomplishments. Do not be arrogant or bullyish about your work. **Appreciate people who supported you in the journey. **You can summarise and publish this on your social media. Social media can be a great ego booster so why not use it for that? You should celebrate your accomplishments! Be your own cheerleader and the world will follow you!

Contrary to common belief, at workplace your manager should be part of your support system.

If you think your manager should inherently know all the awesome work you do, then you are setting yourself up for disappointment. Managers are not responsible for keeping track of your achievements. When you assume your manager owns your growth, it inevitably creates frustration for both parties. There's only so much each of you can do without the other.

As mentioned before, our own memories are fickle, how can we expect a human being (aka your manager) with many direct reportees to remember all your good work? Be a good direct reportee and make your manager’s job a little easier. Regularly share your work progress and achievements in a short, concise manner as discussed above. It makes it easier for them to remember and share with other internal parties.

So that’s it. Today we learnt how you can build your own list of achievements, make them concise, data oriented and share them with your support system. I hope some of these tips help you build your career and you continue to climb the ladder of success!

Builders Guide to AWS Summit Online India 2022

Rohini Gaonkar — Mon, 23 May 2022 08:11:44 +0000

For the last many years, I have had privilege to attend, speak and even curate agenda at AWS Summits, open/free tech conferences, that happen globally. This year I have been more closely involved and it gives me immense happiness to showcase what we have in store for you. This is a great conference to meet and network with similar minded enthusiasts about technology we all love.

Event highlights

Just like last 2 years, the AWS Summit Online India 2022 is a 2-day virtual technical conference, on Wednesday 25th May, and Thursday, 26th May; with opening keynotes starting from 9am IST.
And this is amazing as anyone from anywhere across the world can attend sessions and build network. Registration for the event is free, so go ahead and sign up for the event here.

The Summit will offer 150+ educational sessions, technical demonstrations, and keynotes featuring the the VP of AI at AWS Dr. Matt Wood with other AWS business leaders and AWS customers like Tally, ICICI Lombard, Apollo tyres and more.

Our AWS Community Hero for DevTools, Bhuvaneshwari Subramani, is presenting in the Day 1 Keynote.

The sessions are divided into 17 tracks with themes like AI/ML, Big Data, Cloud Security, Compute Anywhere along with 5 experiential zones - exam readiness sessions Training & Certification, deep dive demos in Builders Fair and Startup Central. Pick and join any sessions you wish based on the detailed Agenda on the event website.

Attend the Summit to know more about what is happening in the Cloud Computing space and how India is using AWS to build innovative applications. Most of the sessions have AWS customers across India talking about how they have been using AWS in their real-world solutions.

Sessions are labelled from Level 100, i.e. introductory level to level 400 i.e. expert level. So, attend sessions depending on your level of knowledge ranging from L100 - L400.

Community track

I am happy to introduce you to the 'Build on AWS' track where for the first time ever, our community members are presenting in the AWS Summit India, alongside me. We will present advanced deep dive sessions on topics like Containers, Serverless, DevOps, Data Lakes and more.

Architecting for sustainability Level: 300 | Advanced

I will be presenting this session, where I will dive deep into techniques recommended by the AWS Well-Architected Framework Sustainability pillar and provide direction on reducing the energy and carbon impact of AWS architectures. Learn about best practices, which organisations of any size can apply to their workloads and how to review the new Customer Carbon Footprint Tool report with a demo.
Connect with me on LinkedIn

End-to-End CI/CD at scale with infrastructure-as-code on AWS Level: 300 | Advanced

AWS DevTools Hero - Bhuvaneswari Subramani, dives deep into building a production ready, multi-account, at scale CI/CD pipeline using your own Jenkins, with infrastructure-as-code using AWS CloudFormation, and discuss best practices for building DevOps capabilities for your container applications running on AWS.

Just-in-time worker nodes for Amazon Elastic Kubernetes Service using Karpenter Level: 300 | Advanced

AWS Container Hero - Dijeesh Padinharethil, will demonstrate how Karpenter simplifies Kubernetes infrastructure with the right nodes at the right time. Karpenter is an open-source, flexible, high-performance Kubernetes cluster autoscaler built with AWS

Build serverless apps with SAM Accelerate and SAM Pipelines Level: 300 | Advanced

AWS Community Builder - Jones Zachariah Noel N, demonstrates how to use SAM templates to manage serverless infrastructure as code. He will share best practices for using the AWS SAM CLI and the recently announced AWS SAM Accelerate to develop and debug serverless applications on your local machine. He will also showcase the ease of CI/CD workflows with SAM pipelines to multiple staging environments.

Build performant, scalable and secure GraphQL APIs Level: 300 | Advanced

AWS Community Hero - Dipali K, and AWS UG Delhi leader - Rajat Arora, take you through security best practices for your GraphQL API’s with AWS AppSync, and Amazon Cognito for easy management, improved performance, and observability.

Build sustainable applications on AWS using Rust Level: 200 | Intermediate

AWS Solutions Architect Developer Specialist - Sundararajan Narasiman, will dive into the “super powers” of Rust, hear about the work ahead to give those powers to every engineer, and learn about the ways in which you can contribute. He will cover how to build a lambda function using Rust and deploy to AWS.

Build a data lake with AWS Lake Formation Level: 200 | Intermediate

AWS Community Builder - Sanchit Jain, will explore data lake challenges and how AWS Lake Formation can help you. If you're a developer, DBA, or a data engineer who works with data, this session is for you.

Build a real time pipeline to ingest streaming data Level: 300 | Advanced

AWS Data Hero - Sridevi Murugayen, will look at how you can build streaming data analytics pipelines that speed up time to information from hours to seconds. She will discuss how streaming-data services like Amazon Kinesis are used to capture and analyse data in real time from hundreds of sources, with AWS Lambda, stored in Amazon S3, then process it with Amazon EMR and deliver it to your Amazon Redshift data warehouse.

Goodies up for grab

I would recommend watching few noteworthy sessions live. The live experience will get you an opportunity to connect with peers, tech enthusiasts, ask questions to experts, and last but not the least, win swags.

You are eligible for the certificate of attendance, as long as you complete watching 5 sessions or more during the conference and you stand a chance to win $25 AWS credits too. Also, watch 2 or more express trainings in the Training & Certification Zone and be amongst the first 2000 to get the discount certification voucher!

AWS Summit India event Website - https://aws.amazon.com/events/summits/india/https://aws.amazon.com/events/summits/india/

How to stop overspending - AWS Cost Optimisation tips

Rohini Gaonkar — Wed, 09 Feb 2022 08:04:27 +0000

Sharing with you typical cost savings tips I have shared with customers as a Solutions Architect. These are some of the obvious (but often ignored) items that customers can do to save cost as they build and grow on Amazon Web Services (AWS).

1. Backup frequency and retention in services like Amazon RDS
2. EBS Snapshots & Volumes
- 2.1. Stopped Instances
- 2.2. Amazon EBS 'DeleteOnTermination' attribute
- 2.3. Recent Announcements from AWS re:Invent 2021
3. Storing Logs in CloudWatch, without ever purging
4. Data Transfer
- 4.1. NAT Gateway to S3 bucket
- 4.2. Chatty applications
5. Unused Metrics & Alarms
Summary

Let's talk about some of the commonly ignored ones :

1. Backup frequency and retention in services like Amazon RDS

Sometimes customers want to be extra cautious while taking database backups. This is great compared to being completely ignorant and not taking backups.

True story: couple of my customers were taking manual snapshots of RDS instances every 4 hrs, storing them for 15 days, and each backup being more than 500 GB. Plus there was 1 automated snapshot everyday retained for 7 days. Additional backup storage for your provisioned database storage is billed at $0.095 per GiB-month.
If you just do a rough calculation on above items, you can estimate that they must be paying 100s, if not 1000s, of dollars on unnecessary backups that were useless in case of a disaster, if any. No one would be using a 13th days old 2nd backup to restore database, the data already was too old for the system to be up and running.

Hence, the frequency and retention of backups must be selected depending on the RTO/RPO discussed with your business stakeholders.

Read more information on the Disaster Recovery (DR) objectives in the AWS documentation

2. EBS Snapshots & Volumes

2.1. Stopped Instances

It is a common saying for EC2 - when you stop the instances, you stop paying. Yes, this is correct, but only for the compute and data transfer costs. If you have an EBS volume attached to the EC2 instance, you will continue to pay for storage.

If you don't need the EC2 instances again, its good to backup data in cheaper storage like Amazon S3 bucket or simply create an Amazon Machine Image. Snapshot storage is based on the amount of space your data consumes in Amazon S3. Because Amazon EBS does not save empty blocks, it is likely that the snapshot size will be considerably less than your volume size.

Moreover the costs are slightly lower. For example, in US-EAST-1 :

EBS Volume (gp2) - $0.08 per GB-month
EBS Snapshot     - $0.05 per GB-month of data stored

2.2. Amazon EBS 'DeleteOnTermination' attribute

By default, Amazon EBS root device volumes are automatically deleted when the instance terminates. However, by default, any additional EBS volumes that you attach at launch, or any EBS volumes that you attach to an existing instance persist even after the instance terminates.

A lot of times customers are unaware of this and end up with 'Available' volumes in their account which are left over by terminated instances, ultimately adding to your EBS cost. This gets more troublesome when you have AutoScaling instances scaling in and out all the time.

This behavior is controlled by the volume's DeleteOnTermination attribute, which you can modify. You can change the value of the DeleteOnTermination attribute for a volume when you launch the instance or while the instance is running.

To verify the value of the DeleteOnTermination attribute for an EBS volume that is in use, look at the instance's block device mapping. To query instances with this attribute as false, run following command:

aws ec2 describe-instances \
--filters "Name=block-device-mapping.delete-on-termination,Values=false"

For more information and if you want to modify this, see View the EBS volumes in an instance block device mapping.

2.3. Recent Announcements from AWS re:Invent 2021

You can now use 2 new features from AWS :

EBS Snapshot Archive, a low-cost storage tier to archive full, point-in-time copies of EBS Snapshots that you must retain for 90 days or more for regulatory and compliance reasons, or for future project releases.
EBS Snapshot Recycle Bin - lets you set up rules to retain deleted snapshots so that you can recover them after an accidental deletion.

3. Storing Logs in CloudWatch, without ever purging

Amazon CloudWatch Logs is awesome. You can use it with services like X-ray and CloudWatch ServiceLens for better observability of your application.

However, it is important to note that default retention setting is ‘never expire’. This means all that log data from months ago which you may not require now is still stored and costing you money.

Purge or export your CloudWatch Logs to Amazon S3 to save on cost for long term.

You can configure how long to store log data in a log group. Any data older than the current retention setting is deleted automatically. You can change the log retention for each log group at any time.

4. Data Transfer

4.1. NAT Gateway to S3 bucket

You can use a network address translation (NAT) gateway to enable instances in a private subnet to connect to the internet or other AWS services, but prevent the internet from initiating a connection with those instances. This is a great security feature that is highly recommended to customers.

If you create a NAT gateway in your VPC, you are charged for each “NAT Gateway-hour" that your NAT gateway is provisioned and available. And the data processing charges apply for each Gigabyte processed through the NAT gateway regardless of the traffic’s source or destination.

Many miss out the important note mentioned on its pricing page :

'To avoid the NAT Gateway Data Processing charge in this example, you could setup a Gateway Type VPC endpoint and route the traffic to/from S3 through the VPC endpoint instead of going through the NAT Gateway. There is no data processing or hourly charges for using Gateway Type VPC endpoints.'

So, if you have used a NAT Gateway for all your traffic, including to and fro from Amazon S3 bucket you end up paying a lot of data transfer cost.

Instead use a Gateway Endpoint to route the traffic to/from S3. And the NAT Gateway will route rest of the traffic.

For this, simply attach a Gateway endpoint to your VPC and update the Route Table for private subnets. The route table will take care of forwarding the requests automatically. Following is architectural representation of same:

Please note, S3 access through gateway endpoints is supported only for resources in a specific VPC to which the endpoint is associated. S3 gateway endpoints do not currently support access from resources in a different Region, different VPC, or from an on-premises (non-AWS) environment. However, if you’re willing to manage a complex custom architecture, you can use proxies. In all those scenarios, where access is from resources external to VPC, S3 interface endpoints access S3 in a secure way. Check out the blog Choosing Your VPC Endpoint Strategy for Amazon S3

4.2. Chatty applications

Some customers have chatty applications that talk to each other a lot which pile up the Data Transfer cost for inter-region.

True story: One of my customers' managed this by making silos of their architecture per AZ. So, LBs will talk to instances in only one AZ. They managed routing of customer segments and failover between AvailabilityZone with Route53. Ofcourse this is not always possible and not easy to manage.

There are many different ways of handling this depending on your use-case so I recommend reaching out to your AWS Solutions Architect(SA) to help dive deep into this. They can help you if your spend is significantly high, thank me later. If you don't know who it is and if you wish to be connected to our Sales/Solutions Architect teams, submit a request here

5. Unused Metrics & Alarms

By default, your EC2 instance is enabled for basic monitoring with 5-min interval. You can optionally enable detailed monitoring, then the Amazon EC2 console displays monitoring graphs with a 1-minute period for the instance. This is great as you get additional information.

However, it is important to note that detailed monitoring is charged. The number of metrics sent by an EC2 instance as part of EC2 Detailed Monitoring is dependent on the instance type. Most commonly used instance types have atleast 7 metrics. So the pricing would be Monthly CloudWatch Metrics Charges @$0.30 per custom metric = 7 * $0.30 = $2.1 per instance. This can pile up quickly.

So, ensure you are enabling detailed monitoring for instances that you require additional information and those instances are not simply left in stopped mode.

Similarly, create alarms only when they are required and used frequently.

Summary

In this blog, we learnt simple yet effective ways of optimising cost in your AWS account and stop the wastage.

Ofcourse this is not an exhaustive list, so please feel free to add any more tips you have to benefit everyone. Hope some of these help you make the right decisions for your workload. Looking forward to your feedback.

Do let me know if you found this helpful, and would like to see more cost saving tips/reminders.

The Ultimate Guide to AWS Community : SAARC

Rohini Gaonkar — Sat, 05 Feb 2022 06:43:33 +0000

As Solutions Architect and as a Developer Advocate at AWS, I have been working with the AWS community for years now, either it is to deliver tech sessions or to help setup logistics for a meet-ups.

The community is a great space for learning, sharing and ofcourse networking.

A lot of times I get questions on how one can get involved with the AWS Community, especially in my region - India, Bangladesh, Sri Lanka and Nepal. Hence, this blog to summarise some of the amazing efforts of our community and the various AWS programs we have. Many of these programs are global while some are regional, you could still access regional content from anywhere.

AWS User Groups

Global program
AWS has 400+ AWS-focused User Groups(UGs) around the world. These are communities that meet regularly to share ideas, answer questions, learn about AWS services and best practices, and even a great pool for hiring talented professionals.

As a Developer Advocate, along with my colleagues, I work with the AWS User Groups across India, Bangladesh, Sri Lanka and Nepal. I officially started interacting with these UGs since May 2020. While I have met many members in the pre-pandemic world, most of our interactions have been virtually since you-know-when. Inspite of the WFH mode, many of our communities still connect regularly and help each other grow.

You can find all the UGs here in SAARC at AWS User Groups in Asia Pacific. They come together for sessions they live stream, or setup their own groups so people can communicate or even have their own certifications bootcamp.

Find a local group that is close to you. Last year we launched 6 new UGs across India, so do visit above link. Also, subscribe to the AWS UserGroup India YouTube channel as most UGs also stream to this channel regularly.

🤷 What can you do?

Attend sessions, workshops, bootcamps, etc
Passionate about a topic? Reach out to the UG Leaders of any user group you want and find a speaking slot. Share your knowledge with others.
Connect with others for jobs, certifications, etc.
Stand a chance to win goodies, credits or vouchers.

AWS Community Days

Global program
Every year the user group leaders come together to create tech conferences called as Community Day. They feature technical discussions, workshops, and hands-on labs led by expert AWS users and industry leaders from around the world. These were in city 1-2 day events for enthusiasts to come, network and learn together. Since the pandemic, the conference has been virtual and sessions are available online for everyones benefit.

In 2021, the user group leaders of India, Bangladesh,Nepal, and Sri Lanka came together to create AWS Community Day South Asia Virtual Edition 2021. You can watch all the sessions from this event on the website.

This community day we also experimented with AWS JAM where you put your skills to the test by solving challenges that emulate real AWS use-cases. This was very well appreciated by the community as it took a different approach to learning.

AWS Heroes

Global program
The AWS Heroes program recognises a group of AWS experts(who are not AWS employees) for their enthusiasm for knowledge-sharing. They write blog posts, present at conferences, host regular meet-ups, contribute to open source, and more. At its core they all are community champs, who are self-driven and self motivated to help the community. They share knowledge to enable others via any medium and help the community grow.

🤷 A lot of times we are asked, what should I do to become a hero? This is an honorary recognition by AWS. There is no said checklist of do these 10 things or apply here and you are a hero. Heroes are given this title to appreciate all the amazing work they have been doing. They are not doing work for the title but to genuinely help the community. So if you have been doing awesome work, continue doing so. Actively work with the community and you will not be missed. Last year we added 3 new Heroes in SAARC to recognise their work, bringing our total to 15 Heroes in the region.

There are different categories of heroes too. Do check out the AWS Heroes worldwide list for more information and don't miss out the Content library

LinkedIn post by AWS Hero Dijeesh Padinharethil with Adam Selipsky CEO of AWS.

AWS Community Builders

Global program
The AWS Community Builders program offers technical resources, mentorship, and networking opportunities to AWS technical enthusiasts and emerging thought leaders from the community who are passionate about sharing knowledge and connecting with the technical community. Last year we had 100s of Community Builders selected.

Want to learn from existing Community Builders? Check out their content on dev.to.

Want to become a Community Builder? We just closed our recent application. However, feel free to add yourself in the waitlist now.

Read these articles from Community Builders:

How to become an AWS Community Builder

Stephen Sennett for AWS Community Builders ・ Aug 17 '21

#aws #career #cloud

10 Benefits to joining AWS Community Builders

Ganesh Swaminathan for AWS Community Builders ・ Jan 10 '22

#aws #career #cloud #community

AWS re:Skill

Regional program
We also have our own learning platform called as AWS re:Skill that is developed for the community to help developers learn and upskill/reskill themselves on the AWS platform.

🤷 What can you do?

We do weekly and monthly challenges. You can learn from sessions, take part in the quizzes and earn rewards.
If you are writing blogs and want wider reach, add the links to your re:skill profile.
If you are interested to present a session, feel free to reach out to me via LinkedIn DM.

AWS Developer Stories

Regional program
In 2021, we wanted to share unique stories of our community celebrating their passion of building tech and how the AWS community has helped them level up in their journey. Our Developer Marketing Manager, Ridhima Kapoor, has done beautiful work with these stories that have been appreciated globally. Do watch and read about our community 4 stories, hoping this inspires you to be part of a vibrant community and help with your goals.

Sandeep Kanabar -> Video , Blog
Dipali Kulshrestha -> Video , Blog
Bhuvaneswari Subramani -> Video , Blog
Jeevan Dongre -> Video , Blog

AWS Women in Tech Community Edition

Regional program
We also had yearly one day event for Women in Tech. The sessions were a good mix of tech and non-tech topics. We had huge response for this from the community. You can watch all the on-demand videos on YouTube playlist.

AWS and other communities

I always tell this to cloud newbies - think of AWS as an added flower in your bouquet of skills. AWS has the breadth across many different technologies that you may have already have experience in. Apply that knowledge to AWS and learn how to do that with AWS for a quick-start. And for this reason we also participate and engage with communities that are not necessarily only AWS. For instance, we have been engaging with communities of Women in Big Data, GitHub, Postman and more. If you are part of a community and would love AWS to come collaborate with you, reach out to me via LinkedIn DM or reach out to any UG Leader or Hero.

AWS and Open Source

We have been involved in lot of Open Source discussions. We participate and host events for Open Source. In India we had 2 major events last year - our AWS Jaipur User group hosted OS Tech, and we had a whole day AWS track at Open Source India and more. We will continued investing more into Open Source discussion. So stay tuned.

Summary

Hope this gives you some insight into the active participation AWS communities in India, Bangladesh, Sri Lanka and Nepal.

How can you stay updated on all of these?
Simple, follow me (and AWS heroes on LinkedIn), join user group communities and be an active member.

Can we do more?
Ofcourse! If you have great ideas of what we can do to enable builders of tomorrow, tell us in the comments section or DM me on LinkedIn.

Let's enable developers to be highly skilled and set them on a path to be the best versions of themselves.

Follow me on LinkedIn, Twitter, GitHub, Youtube

Life at AWS : 8th Anniversary

Rohini Gaonkar — Fri, 07 Jan 2022 03:43:35 +0000

Update 7th January 2023 : Its been 9years now since I joined AWS and I moved to AWS Canada as a Developer Advocate in Oct 2022. First image is updated for same.

8 years ago, 7th January 2014, I joined Amazon Web Services (AWS) and this blog is a peek into the dream-come-true life I have had so far. These are some of the learnings, experiences and thoughts on life at AWS. If you are new to AWS or aspire to join us, read along!

Over the years, I have been a Cloud Support Engineer(CSE), a Solutions Architect(SA) and a Developer Advocate(DA) across South Africa, Singapore and India. I have moved with AWS to different geographies, and made friends globally. I got to work with hundreds of customers in different regions, and many more colleagues who have become really good friends. Meeting them in different countries has been pure joy!

While many organizations frown upon people leaving teams/projects, here at AWS we are encouraged to explore different roles. I could apply my tech skills as a Support Engineer while expanding my breadth and dive deeper into services. I used those learnings to help customers as a Solutions Architect(SA). As an SA I followed my passion of public speaking and worked with AWS community over the weekends, which led to eventually moving into Developer Advocacy.

A little history :

Before I joined AWS I was part of an R&D team that did Proof-of-Concepts (PoCs) on different cloud platforms we had back in 2010. Most of those public/private clouds do not exist today.

It was love at first sight, with AWS technology

I worked with AWS tech before launch of AWS Virtual Private Cloud (VPC) and AWS AutoScaling for Elastic Compute Cloud (EC2). It led to an idea and a working PoC which resulted into my first published IEEE paper. Interested? Read here.

In the years that followed, I had hands-on migrations experience of moving on-premise web applications to AWS - a highly coveted skill at that time.

The organization was acquired and its vision changed, but my love for AWS and my vision stayed strong. So, I applied to AWS, went through virtual interviews and did the unthinkable - moved to different continent - Cape Town, South Africa. In the middle of culture shock and home sickness, my tech skills soared higher every passing day.

Source : My feature in the AWS Employee Spotlight series.

Learnings :

While everyone talks about Leadership Principles, which we Amazonians imbibe in every aspect of our work, I wanted to shed some light on other aspects of working at AWS.

Something I tell new joiners, or people who even change roles/location internally - initially, it feels like a lot of information is sent your way and its only natural to feel overwhelmed. Drinking from the firehose. When you feel like it, remember what Dory said - just keep swimming. Trust me, it does get better.

Hence, don't rush through your ramp up time. There is a reason ramp up time is provided, use it well to learn the internal ways, do your certifications and most importantly shadow your colleagues in different roles. Everyone is busy, but if you need help - ASK! Find a buddy, or a mentor, it will help calm your nerves.

Most of us experience imposter syndrome It may feel overwhelming to be around so many smart individuals. AWS has a high hiring bar, if you made it through it, you are worth it.

If you want to be successful at AWS you have to take ownership of projects beyond your daily responsibilities. It is a great way to connect with the global AWS teams, customers and helps you build relationships. Over the years, I am proud having worked with some amazing teams here at AWS - from being part of the This is my Architecture, to managing 21 sessions across 3 theatres for Lightning talks in a physical AWS Summit India, to owning a T&C Twitch series, getting my customers speaking slots at re:Invent, building workshops, and many more.

One of the most important lessons of my life - Burnout is real. Some interviewees ask a question - is life at AWS too hectic? Well IT depends on what stresses you (and sometimes which team you are in). Here, we are not stressed by office politics, you are not worried of racing with your colleague to get that promotion. Here, everyone has more than enough work to showcase their skills. When you are so excited about the work you do, you may end up not realizing you are burning out. And it's important to pace it. There is a saying internally - it's a Marathon, not a sprint.

So, it's important to know your own limits, take breaks, talk to your managers if something is troubling you. There are multiple programs available to employees, and I have used them last year when our lives changed overnight. It has helped me tremendously!

Everyone works on schedules that make sense to them. You set your own boundaries. Saying NO is encouraged by leaders. You would find leaders saying - just because you saw an email from me that is out of business hours, doesn't mean you have to respond immediately.

All this would not have been possible without some amazing managers & leaders. A good manager is a blessing. They have always pushed me to speak up, to be a leader, motivated me when I doubted myself or just being a friend I can freely talk to. I have never hesitated to reach out to skip level or regional managers. It is never considered as an escalation, but a pure sharing of ideas and building relationships. Coming from a very hierarchical past this was the warmest welcome. Being an autonomous individual contributor has boosted my motivation and creativity.

Source : My feature in the Women of AWS feature on Amazon Jobs website

Summary :

Life at AWS has had its ups and downs, a dream-come-true rollercoaster ride. It is AWSome because of all the amazing people I have met as colleagues, customers or community.

Hope this gives you an honest take of life at AWS! Feel free to DM me on LinkedIn, always happy to chat!

Follow me on LinkedIn, Twitter, GitHub, Youtube

Interested to grow with AWS? Check out following resources :

AWS Jobs - We are hiring! Apply for jobs based on roles & locations of your choice.
Tips for interviewing at AWS - a good collection of process, and tips for every step in interviewing at Amazon/AWS
Certifications - Explore our role-based certifications
Re:skill - Community driven learning
Join our AWS Community - find an AWS User Group near you and join us.

DEV Community: Rohini Gaonkar

Bigger AI models aren't always better. Here's how to actually choose.

The demo: same prompt, two models

The small model

The large model

Why models come in sizes

Tokens and pricing: how you actually pay

Real numbers

Where it breaks: when bigger is worse

How to actually choose

What about picking a provider?

Try it yourself

What's next

Thank you for featuring me! 💜

Top 7 Featured DEV Posts of the Week

Why does AI lie? Hallucinations explained simply

The demo: same question, two models

Model 1: Amazon Nova Micro 1.0

Model 2: Claude Haiku 4.5

The biography test

Why this happens: the architecture

"But ChatGPT can search the web?"

The fix, and where the fix breaks

Three signs you should double-check

Try it yourself

What's next

What Even Is AI? (I Took a Break & Had to Relearn Everything)

The demo: AI adapts a recipe in under a minute

So what actually happened?

Where it breaks

Where the models live: Amazon Bedrock

A note on my stack

Try it yourself

What's next

Stop waiting to feel ready. You won’t. Not after a break. Not after life changes. Not when everything feels like it’s moving faster than you. I almost didn’t publish this.

Lost in the AI Hype, I Started Small - DEV Community

Lost in the AI Hype, I Started Small

And it helped me get back into tech without drowning

Building It with Kiro: My First Impressions

1. Chat-Driven Development

2. Web Search

3. Explore Real-Time File Changes

4. Trusting Frequently Run Commands

5. Iterative Refinement Through Conversation

6. The YouTube Challenge : Hitting Walls and Finding Workarounds

The Result

What's Next

Get into Cloud computing with no experience

How to ‘Be your own cheerleader’

It’s simple, WRITE IT DOWN!

Make a collection

Make it a habit

Build your support system

Builders Guide to AWS Summit Online India 2022

Event highlights

Community track

Goodies up for grab

How to stop overspending - AWS Cost Optimisation tips

1. Backup frequency and retention in services like Amazon RDS

2. EBS Snapshots & Volumes

2.1. Stopped Instances

2.2. Amazon EBS 'DeleteOnTermination' attribute

2.3. Recent Announcements from AWS re:Invent 2021

3. Storing Logs in CloudWatch, without ever purging

4. Data Transfer

4.1. NAT Gateway to S3 bucket

4.2. Chatty applications

5. Unused Metrics & Alarms

Summary

The Ultimate Guide to AWS Community : SAARC

AWS User Groups

AWS Community Days

AWS Heroes

AWS Community Builders

How to become an AWS Community Builder

Stephen Sennett for AWS Community Builders ・ Aug 17 '21

10 Benefits to joining AWS Community Builders

Ganesh Swaminathan for AWS Community Builders ・ Jan 10 '22

AWS re:Skill

AWS Developer Stories