Forem: N Chandra Prakash Reddy

From MLOps to LLMOps: A Practical AWS GenAI Operations Guide

N Chandra Prakash Reddy — Fri, 03 Apr 2026 16:12:34 +0000

The vibe at AWS Student Community Day Tirupati on November 1, 2025, was different from what I thought it would be like. There were lots of students, cloud fans, and builders in the room. They were all there to learn, meet, and geek out about AWS. Throughout the day, there were several classes, and each one added something new.

One lesson, though, made me sit up and pay more attention. Raghul Gopal, a Data Scientist and AWS Community Builder (ML), walked up to the stage to talk about something that most people don't think much about: how do you run AI models in real life? Not just make them on a laptop and be happy about it; consistently test, watch, and scale them.

"Generative AI Operations: FMOps, LLMOps Integration with MLOps Maturity Model" was the title of the talk. When it was over, I had a whole new perspective on the AI/ML lifecycle on AWS.

The Question That Kicked Everything Off

"AWS gives you everything in one place to build ML models," Raghul said to start the talk, and it really hit the mark. But are we really using it right in production?"

Sense a pattern? A model can be trained by many teams. It's a whole different task to get that model to work reliably for a lot of real users.

To put it another way, making a great meal at home is one thing. It takes a lot of different skills to run a restaurant kitchen that feeds hundreds of people every day without any problems. That's what this meeting was all about.

What "ML in Production" Actually Means

Before getting into answers, the session gave us a really helpful list of questions that can be used as a litmus test to see if your machine learning setup is really ready for production:

Are your model's features (the pieces of data it uses to make predictions) kept separate and tracked correctly?
Is your model that you learned kept in a model repository or registry?
Is the model being watched all the time to make sure it keeps giving correct answers?
Is model lineage being kept? This is a list of which data made which version of the model.
Are there CI/CD pipelines (automated delivery systems) that move code from development to pre-production to production, with approval steps that need to be manned by manual?
Is testing done automatically in every environment?
Does ETL (Extract, Transform, Load) automatically load data so that machine learning engineers can start working on projects without haThe event also had a number of other great sessions, such as ones about cloud design, hands-on demos, and more. But this one helped me learn how to organise my thoughts in a way that I will use in all future AI projects.ving to wait for data teams?

There are a lot of people like you who answered "not really" to most of those questions. That's exactly what MLOps is meant to fix.

The Three "-Ops" You Need to Know

Let's be honest: the words can be hard to understand. It's simple like this:

MLOps (Machine Learning Operations): The process of putting standard machine learning solutions into production in a smart way. Examples include fraud detection models, recommendation systems, and churn prediction.
FMOps (Foundation Model Operations): Massive AI models like Claude or Titan are trained on terabytes of data with billions of parameters. This is an extension of MLOps for Foundation Models. FMOps includes use cases for making text, images, music, and videos.
LLMOps (Large Language Model Operations): A part of FMOps that is used to operationalise Large Language Models. This is the technology that makes chatbots, writing helpers, and coding tools work.

Imagine three rings stacked on top of each other. MLOps is the outer ring, FMOps is inside it, and LLMOps is in the middle. It doesn't matter what kind of AI model you run, all three work the same way.

The MLOps Maturity Model: Four Levels

Now things really start to get interesting. Raghul showed a four-level MLOps Maturity Model, which is a plan for how teams move from small tests to using machine learning on a large scale. It's kind of like getting better at a video game.

Level 0 - Initial Phase: Experiments and Ideas

At this point, data scientists are just looking around. To make and test models, they use Adobe SageMaker Studio (AWS's cloud-based ML IDE) or local tools like VS Code and PyCharm. This is what the technology stack looks like:

Amazon SageMaker: Core ML platform with Data Wrangler (data prep), Pipelines (automation), Feature Store, and Clarify (bias detection)
Amazon S3: Stores your raw ML training data
AWS Glue: ETL service - cleans and transforms data before feeding it to models
Amazon Athena: Run SQL queries directly on data sitting in S3
AWS Lambda: Trigger automated jobs and workflows
The event also had a number of other great sessions, such as ones about cloud design, hands-on demos, and more. But this one helped me learn how to organise my thoughts in a way that I will use in all future AI projects.
Code Repository: AWS had its own CodeCommit, but now most people use GitHub or Bitbucket to store and track their work.

That's fine; everything here is done by manual and by exploration. The beginning of every fully developed machine learning system.

Level 1 - Repeatable Phase: Automating the Workflow

From doing runs by manual, the team now goes on to automated pipelines. You don't have to re-train a model by manual every time because SageMaker Pipelines can do the data preparation, training, evaluation, and packaging for you. The SageMaker Model Registry is a central list of all your model versions that gets updated when new models are trained.

"I trained this once" became "every training run is tracked, versiThe event also had a number of other great sessions, such as ones about cloud design, hands-on demos, and more. But this one helped me learn how to organise my thoughts in a way that I will use in all future AI projects.oned, and reproducible."

Level 2 - Reliable Phase: Adding the Safety Net

This is the quality gate before going live. You introduce:

Automated testing: Unit tests, integration tests, and evaluation metrics that are specific to machine learning are all run immediately.
CI/CD Pipelines Using AWS CodePipelines and AWS CodeBuild to move code from development to pre-production to production, with approval steps that need to be manned by manual.
Different testing strategies based on how data arrives:
- Batch requests: Tested via Lambda and S3
- Real-time requests: Handled through Amazon API Gateway
- Streaming requests: Managed with Kafka and Amazon MSK

To be fair, this level demands real engineering discipline. But it's what separates a prototype from something you'd stake your business on.

Level 3 - Scalable Phase: Multi-Team, Enterprise-Scale

Everything from Level 2 is multiplied across different teams and machine learning solutions at the same time in the last level. New things added here:

Multiple data sources: NoSQL databases like DynamoDB and DocumentDB for different team needs
IAM (Identity and Access Management) to manage roles and permissions at scale
CloudFormation or Terraform for Infrastructure as Code - your entire environment defined in code, replicable in minutes
Your team can choose to use GitHub Actions or Jenkins instead of AWS CodePipelines if they already know how to use those tools.

What is the goal at this level? From idea to production in days instead of weeks, and use more than one option at the same time.

Making the Leap: MLOps → LLMOps

When you have a strong base in MLOps, moving on to LLMOps is easier than it sounds. The slide made it clear: "You can operationalise your basic LLM use cases from one environment to the next."

The ideas behind Dev, Pre-Prod, and Prod environments, CI/CD pipelines, manual approvals, and automated tests are all the same. Now you're working with Foundation Models instead of the old ML models, which is different. They're the building blocks you use to build on top of your MLOps skills.

Initial LLMOps: Picking the Right Foundation Model

This is where lots of teams get stuck. How do you pick from the dozens of LLMs that are out there? The lesson gave a framework that could be used right away.

Step 1: Know Your Use Case First

Make sure you know what you need before you choose a type. The things to look at are:

Open source vs. proprietary?
Commercial license compatibility
Model size: Small Language Model (SLM) vs. Large Language Model (LLM)
Speed and latency requirements
Context window size - how much text the model can process at once (measured in tokens)
Quality of the training dataset and how it applies to your area
Is the model fine-tunable with your own data?

Step 2: Navigate the Speed-Precision-Cost Triangle

The truth is that you can't have everything. Raghul showed this with a triangle that showed three objectives that were at odds with each other:

High speed → smaller model → lower precision → lower cost
Higher precision → larger model → lower speed → higher cost

In the case on the slide, three Foundation Models were put side by side. FM1 had the highest accuracy (5/5) but also the highest cost. FM3 was less expensive ($$), but it wasn't as accurate. When price was the most important factor, FM2 was chosen because it had the best mix of accuracy (4/5) and low cost ($). The best choice is always based on which triangle point is most important to you.

Step 3: Build a Prompt Catalog and Evaluate Systematically

Don't just pick a model and hope it works. The recommended process:

Prompt Engineers make good evaluation questions by following organised rules like CORS or Anthropic's instructions.
In a Prompt Catalogue, you can store those prompts. It's kind of like a Feature Store, but for prompts. With version control turned on, DynamoDB works well here.
GenAI Developers shortlist the top 3 Foundation Models based on those prompts
You can do structured evaluations in one of four ways, depending on the facts you have:

Accuracy metrics (when labeled data exists with discrete outputs — e.g., classification)
Similarity metrics like ROUGE or cosine similarity (for open-ended text outputs)
Human in the Loop (HIL): Using tools like Amazon SageMaker Ground Truth, human judges score model outputs by manual against set criteria.
LLM-as-judge: Feed outputs to a trusted, reliable LLM and have it rate the response with a score and explanation

The result is a clean evaluation scorecard, which means that you chose your model based on facts instead of your gut.

Building and Deploying Your LLMOps App

What do you do now that you've picked your LLM? Building the real app around it is the last step:

Frontend: Django, Flask, Streamlit (highly recommended for quick and clean prototypes), or React
Backend / LLM Provider: Amazon Bedrock, SageMaker JumpStart, or HuggingFace - depending on your model choice
Load Balancing and Auto Scaling to handle real-world traffic without hiccups
The same Dev → Pre-Prod → Prod pipeline from MLOps applies - always test your LLM in Pre-Prod before exposing it to end users

The architecture changes based on whether you're delivering at the edge or through a centralised group.

Key Takeaways

After this lesson, a few things really stuck with me:

Building a model is the easy part. Running it consistently in production, testing it, keeping track of its history, and being able to do it again is the real engineering work.
The MLOps maturity model is a journey, not a checklist. You can start at Level 0 if that's where you are now. You get to the higher levels bit by bit.
LLMOps is MLOps with a GenAI lens. You're a lot closer to LLMOps than you think if you already know how MLOps works.
Model selection should be data-driven. You don't have to guess or worry about which LLM to choose because of the prompt catalogue and organised evaluation method.

Conclusion

In the end, Raghul's talk made it clear that having the tools isn't enough; what counts is how you use them. From SageMaker to Bedrock to CodePipelines, AWS gives you a very full set of tools. But even the best tools can't fix a broken process if you don't think about things like testing, tracking, and being able to do the same thing again.

If you're a student just starting to learn machine learning, a developer looking into GenAI, or an engineer building real systems at work, you need to understand this operational layer. This is what sets people who play with AI apart from those who ship AI. The talk at AWS Student Community Day Tirupati taught me that there isn't as much of a gap between the two as most people think. You have to get on that growth curve somewhere and keep going up.

The event also had a number of other great sessions, such as ones about cloud design, hands-on demos, and more. But this one helped me learn how to organise my thoughts in a way that I will use in all future AI projects.

About the Author

As an AWS Community Builder, I enjoy sharing the things I've learned through my own experiences and events, and I like to help others on their path. If you found this helpful or have any questions, don't hesitate to get in touch! 🚀

🔗 Connect with me on LinkedIn

References

Event: AWS Student Community Day Tirupati

Topic: From MLOps to LLMOps: A Practical AWS GenAI Operations Guide

Date: November 01, 2025

Also Published On

AWS Builder Center

Hashnode

LamRAG: AI-Powered Feedback Analysis Using Amazon Bedrock

N Chandra Prakash Reddy — Sun, 29 Mar 2026 15:35:02 +0000

There were a lot of great talks at AWS Student Community Day Tirupati on November 1, 2025. But the one that really jumped out was "LamRAG: From data to constructive insights using Amazon Bedrock" by Rahul Kumar and Gokul Jangam.

It wasn't a normal slide-and-talk presentation. It was a live, step-by-step tour of a real product they made called Feedbackly, which is a platform for managing feedback. They showed how they improved it over time using Amazon Bedrock. The session was set up perfectly, with levels that built on each other. When it was over, I got a whole new way of looking at what generative AI on AWS can do.

Let me break it all down for you.

The Problem: Feedback Chaos and the 10/10 Trap

You know how messy it can get if you've worked on a team that does sprints. Many projects. A lot of project managers. Different schedules for sprints. Different approaches to get feedback from peers. There is no one spot to keep track of it all.

Feedbackly was made to solve just that: a single system for managing projects and getting peer input from team members every sprint. It's like a notebook that everyone in your engineering department can use to keep track of comments from every sprint.

But then there was a new problem that seems quite familiar: everyone started giving 10 out of 10 ratings. Everyone is "great." Everyone "did better than expected." The feedback loses its meaning. Not important. Not useful for real conversations about performance.

Sound familiar? That's where Amazon Bedrock enters the picture.

Why Serverless First?

Before getting into the AI aspects, the speakers made a quick but vital case for creating Feedbackly on a serverless architecture. This is why it made sense:

No Server Management - no patching, no provisioning, no babysitting servers
Pay Only for What You Use - no paying for idle compute between sprints
Automatic Scaling - handles bursts of feedback submissions without manual work
Faster Development - less infra, more features
Built-in Availability - AWS handles the redundancy
Focus on Business Logic - spend time on what actually matters to users

It's like renting a cab instead of buying a car. You don't have to worry about gas, insurance, or maintenance; you just get where you need to go.

Learning in Levels: The Session's Brilliant Structure

The session was set up as a series of five levels, from L1 to L5, with each level adding a new idea on top of the one before it.

L1: Bedrock Playground

The journey started with the Amazon Bedrock Chat Playground — a browser-based interface where you can experiment with multiple foundation models side by side, without writing a single line of code. It's literally a playground.

The presenters used the same feedback-classification prompt on three models at the same time: Llama 3.1 405B Instruct, Claude 3.5 Sonnet, and Command R. They wanted to see how each model reacted to the same input. The results were different for each of them. The terminology, the reasoning, the strictness, and the structure are all important. This is where it gets interesting: you need to choose a model, and the playground allows you compare them before you make a choice.

The model metrics were also interesting: Llama 3.1 had the largest latency (almost 18,000 ms), Command R was the fastest (around 1,591 ms), and Claude 3.5 Sonnet hit a sweet spot (about 4,799 ms) while giving the most structured, reasoned output.

L2: Prompt Engineering - One Word Changes Everything

AI is just as good as the directions you give it.

The presenters went over a good Prompt Template made in Amazon Bedrock's Prompt Management. It had five main parts:

Persona / Role - tell the model who it is
Action - tell it what to do
References - give it positive and negative examples to anchor its judgment
Variables - use placeholders like {{feedback}} for dynamic input
Output Format - ask for structured JSON so your application can actually parse the result

The prompt told the model to sort peer input into three groups: Reliability, Productivity, and Positive Energy. Then, it had to rank each group from 1 to 5. If there isn't enough background for a category, give it a -1.

After that, the most memorable demo of the whole session happened. They gave the identical report twice: "Person X has been productive and done the tasks as expected." What's the difference? One instruction suggested, "Be easy on the ratings." The other remarked, "Be strict with the ratings."

The outcomes were markedly distinct. One word. That's all it needed to change the AI's score. It's a strong reminder that you have to be careful when writing your prompt because it's the most important part of how your AI feature will work. Like you test your code, you should also test your prompts.

The Architecture: Lambda, RDS, and Bedrock Working Together

The basic structure of LamRAG is clean, serverless, and easy to understand:

The User sends a request
AWS Lambda receives it, validates the data, and calls both RDS and Bedrock
Amazon RDS acts as the data store, holding all sprint feedback
Amazon Bedrock takes that data, creates a query, and generates a human-readable summary

Lambda takes care of the orchestration. Bedrock is the smart part. RDS has the truth. Easy to use, works well, and is fully managed - no servers to worry about.

L3: Vector Databases and RAG

"RAG" means "Retrieval-Augmented Generation." In simple terms, you give an AI model access to your personal data instead of only what it already knows from training. This way, its replies are based on your specific situation instead of general internet knowledge.

The lecturers utilised a smart example about fruits to describe how vector databases work. Think about how you would describe an apple not just by its name, but also by its colour (1.0), sweetness (7), sourness (4), crunchiness (8), and shelf life (0.5). That list of numbers is a vector. The vector for an Orange is [0.8, 6, 8, 2, 1.0]. A vector database keeps these embeddings and uses arithmetic to locate items that are comparable to them, not keyword matching.

When you ask for "list some red-colored fruits," the database looks for vectors that are closest to the numbers that represent "red" and "fruit." That's semantic search — and it's far more powerful than a simple text search.

Feedbackly integrated feedback data stored in Amazon S3 to a Bedrock Knowledge Base. This let users to choose how to separate and index documents for quick retrieval by using configurable chunking schemes such as default, fixed-size, hierarchical, semantic, or no chunking.

L4: Agents - Smart, Conversational, and Privacy-Aware

Three months after the first Feedbackly launch, two new problems came up: Admins vs. Users access control and a problem with how feedback was being shown. Not everyone should be allowed to see what other people have said.

The solution? Bedrock Agents.

An agent is like a smart helper that can think, plan, and do things. The speakers built an agent called sls-days-2024-lamrag based on Claude 3 Haiku. The agent has the following settings:

Action Groups - A Lambda function that takes two arguments: the type of inquiry (self or others) and the email address of the person who asked for it.
Knowledge Base - linked to the Feedbackly S3 data, with the order to get data depending on the user's email address
Privacy Logic - The Lambda checks to see if you're asking about yourself or someone else and blocks access right away if it's not allowed.

The live demo was really cool. When an unauthorised email sought to get someone else's comments, the agent said, "You are not authorised to access that information." But when a user asked for their own comments, they got a long, conversational summary: "Sandeep is a very productive, dependable, and positive team member who always gets great results."

That's not only smart AI; it's also responsible AI. Privacy built into the design.

L5: Keeping the Knowledge Base in Sync

A knowledge base is only useful if it is up to date. If new feedback is sent in but the knowledge base isn't updated, the agent keeps answering questions with old information, like a librarian using last year's catalogue.

The presenters talked about this directly with L5, which kept the Bedrock Knowledge Base up to date. The knowledge base needs to re-sync every time fresh feedback is processed and uploaded to the S3 bucket (sls-days-2024-lamrag) so that the agent always has the most up-to-date information. It's a phase that is easy to forget, but it is very important for production systems.

Final Results: The AI Chat Assistant in Action

The end result was a fully functional conversational AI Chat Assistant that was built right into Feedbackly. A member of the team could type a question in plain English and get structured, data-backed answers.

For instance, asking, "What are the average ratings for this worker?" came back:

Positive Energy: 3.9/5 - Very Good
Productivity: 2.5/5 - Below Average
Reliability: 2.7/5 - Below Average
Overall: 3.1/5 - Average

Along with specific strengths (such being good at code reviews, managing time, and mentoring) and areas where they need to improve. No more empty "10/10 across the board" ratings. Instead, there will be real, detailed, AI-backed analysis based on real peer input over time.

Bonus: From Idea to App with Claude Code

The last part of the session was a bonus that honestly blew everyone away. The speakers showed how they used Claude Code, Anthropic's agentic coding tool, to construct the full-stack feedback analyser.

The workflow was deceptively simple:

Create a TASKS.md file — describe the application in plain English (tech stack, features, database setup, everything)
Tell Claude Code to refer the file and build the app
Deploy the app

The TASKS.md file listed all the parts of the stack: For the frontend, we use React, Vite, and Tailwind CSS. For the backend, we use AWS Lambda (Node.js 22). For AI, we use Claude 3.5 Sonnet via Bedrock. For the database, we use PostgreSQL on RDS. For the infrastructure, we use AWS SAM. Claude Code asked a few questions to make sure he understood, and then he made a full implementation plan. This plan included AI functions, security functions, and even privacy functions that replace colleague names with [Colleague] in queries that include more than one user.

This led to the slide that made everyone think the most: "Does this mean we don't need to learn coding anymore?"

Honestly, no, it doesn't. The skill itself is changing. It's more important than ever to know about design, what good code looks like, and how to look at AI-generated output with a critical eye. The startups that the speakers talked about - Cursor, Midjourney, Lovable, and Eleven Labs - were all started by small groups of people that employed AI to help them work faster, not to replace them.

Key Takeaways

This was one of the most useful AI sessions I've ever been to. This is what I'm taking with me:

Prompt engineering is a real, learnable skill. The word "lenient" vs. "strict" makes all the difference. Check your prompts the same way you check your code.
RAG makes AI relevant to your world. Foundation models are not specific. RAG makes them fit your data, your people, and your situation.
Agents add intelligence and access control together. Bedrock Agents can think about who is enquiring before they decide what to respond.
Serverless + Bedrock is a genuinely practical stack. You can send AI features that are ready for production without having to manage a single server.
AI amplifies builders, it doesn't replace them. The actual expertise of this time is knowing what to develop and how to direct the AI.

The Amazon Bedrock Chat Playground is the best place to start if you want to attempt any of this yourself. You don't need any code; simply open your browser and start playing around.

Conclusion

The LamRAG session at AWS Student Community Day Tirupati reminded me that the finest tech speeches don't only teach you ideas; they also show you a real problem, a real solution, and a genuine way to move forward. In short, here's the broad picture:

Generative AI on AWS is approachable - The Bedrock Playground enables anyone start experimenting without having to write any code.
The journey from a simple prompt to a full RAG-powered agent is incremental - You don't have to develop it entirely at once. Start with a small part and add more intelligence as you go.
Privacy and access control aren't an afterthought - Bedrock Agents let you change how the AI reacts right away.
AI-assisted development tools like Claude Code are changing the speed of building - faster than ever from idea to app in use
The best time to start learning Amazon Bedrock is right now - The tools are well-developed, the documentation is good, and the community is developing quickly.

About the Author

As an AWS Community Builder, I enjoy sharing the things I've learned through my own experiences and events, and I like to help others on their path. If you found this helpful or have any questions, don't hesitate to get in touch! 🚀

🔗 Connect with me on LinkedIn

References

Event: AWS Student Community Day Tirupati

Topic: LamRAG: AI-Powered Feedback Analysis Using Amazon Bedrock

Date: November 01, 2025

Also Published On

AWS Builder Center

Hashnode

Building a Private GPT with AWS Bedrock: A Deep Dive

N Chandra Prakash Reddy — Tue, 03 Feb 2026 14:18:57 +0000

How It All Started

On November 1, 2025, I attended the AWS Student Community Day in Tirupati, and honestly, one session significantly changed my perspective on developing AI applications. Amin Ali, a Software Engineer at Target Australia and an AWS-certified Solutions Architect, delivered a presentation titled "Generative AI in Action." The session concentrated on how to build your own private GPT using AWS Bedrock.

The reality is that we've all interacted with ChatGPT, haven't we? Have you ever considered how you might develop something similar that operates with your organization's internal files, retains all the information in your own cloud, and avoids transmitting any data to external APIs? This session focused on that topic, and I'm thrilled to share my insights.

Why Build Your Own Private GPT?

You might wonder why you can't just use tools like ChatGPT or Claude directly. That's a good question, and I can explain with an example.

Data Control: Your Information, Your Rules

Imagine you run a hospital and need an AI to help doctors find patient information fast. Would you want to give private medical data to a public AI service? Probably not. By creating your own private GPT, you control your data within your AWS system, so you don't need outside services. Your private information stays safe in your Virtual Private Cloud. You'll also have full records of everything that happens, which helps follow strict rules, and no data is ever shared with anyone else.

Customization: Make It Yours

Public AI models usually learn from information found online. But what if you need answers that are only about your company? A private GPT can give answers based on your own files and knowledge, allowing it to sound like your company. It's like a customer helper who knows everything about your products. It can also connect easily with your company's internal systems, such as employee records, product lists, or instruction guides.

Understanding Generative AI

First, let's be sure we all know what generative AI is. Amin explained it well with a three-step process.

Input Processing: You tell the AI what to do, like giving it words, pictures, or code. Big AI programs like GPT, Claude, or Llama, which have learned from tons of information, handle these instructions.

Foundation Models: Regular machine learning finds patterns in data to guess things, like if an email is spam. But large language models create brand new things from nothing. That's why they are called "generative."

Creative Output: The AI makes new words, pictures, code, and other things that didn't exist before. It's like having a helpful assistant that can create, write code, and solve problems.

Why Generative AI Is Exploding Right Now

Now is a good time to learn about this new technology. Generative AI is popular for these reasons:

The AI Revolution: Many advanced AI models like ChatGPT, Claude, Mistral, and Llama 3 are becoming more common, and they are significantly altering how we work and create.

Enterprise Adoption: AWS is assisting companies in building reliable and secure generative AI systems that can manage a lot of users. Businesses don't have to build everything from scratch anymore.

Industry Impact: Smart automation is transforming industries like healthcare, shopping, schools, and banking. Think about doctors available 24/7 or educational tools that adjust to each student's needs.

Global Scale: All kinds of companies, from small new businesses to large established ones, are using generative AI a lot, and this trend is growing quickly.

Real-World Use Cases

Let's discuss practical applications. This isn't just theory these are real scenarios where private GPTs genuinely make a difference.

Customer Support: AI chatbots provide 24/7 personalized assistance that is as effective as a human helper. Imagine a customer checking your return policy late at night and getting a fast, accurate response that aligns with your actual rules.

Report Generation: Automatically generating business reports, summaries, and documents. Rather than spending a lot of time compiling quarterly reports, the AI collects the data and creates well-organized documents on its own.

Document Q&A: An internal knowledge base that enables quick answers based on company documents. Picture a new employee asking, "What is our vacation policy?" and the AI quickly finding the answer in the employee handbook.

Developer Assistants: Generating code, fixing errors, and writing explanations to speed up the development process. Programmers can ask, "How do I connect to our database?" and receive code examples that work with your system.

The Live Demo: MBU Virtual Assistant

This is where things became truly intriguing. Amin demonstrated an AI assistant he developed for Mohan Babu University.

The interface was smooth simple chat design built with React that appeared both professional and user-friendly. When a question such as "What programs does MBU offer?" was asked, the system would process the query through the chat, scan the uploaded university documents using vector similarity, generate a contextually appropriate response with AWS Bedrock, and deliver the answer in real time.

The demo showcased the chat interface with live-streaming responses and Bedrock integration performing real-time searches on the knowledge base using vector search examples. Powered by Amazon Bedrock, the responses flowed smoothly, creating the impression of conversing with an intelligent assistant.

How the Architecture Works

Let me guide you through the system's structure. Don't worry I'll keep it simple and easy to understand.

The User Journey

Here's the journey of a user's query through the system:

User Interaction: You enter a question using the React-based web interface.
API Gateway: Your request reaches AWS API Gateway, which serves as the main entry point (REST endpoint).
Lambda Function: API Gateway forwards the request to an AWS Lambda function imagine this as the central component that manages all operations.
Bedrock Integration: Lambda calls AWS Bedrock's Knowledge Base to perform a vector search and uses the Large Language Model to create the response.
Response Delivery: The answer then travels back through the same route and appears on your screen.

Architecture Components

Amin broke down the architecture into clear layers using a complete serverless setup:

This serverless configuration means you don't need to manage any servers. AWS handles scaling and security automatically.

Setting Up the Knowledge Base

This is where the real action takes place. How can you train the AI on your particular documents?

Data Preparation Pipeline

The process follows three key steps:

Upload PDFs: Your documents (manuals, policies, guides) are uploaded to an S3 source bucket.
Extract & Chunk: The system pulls out the text and divides it into smart segments for the best vector embeddings.
Generate Embeddings: AWS Bedrock generates vector embeddings that are saved in an S3 vector bucket for similarity searches.

Vector Integration

Does this ring a bell? Imagine vector embeddings as a library catalog. Instead of just matching exact words, vectors understand the meaning behind them.

The Bedrock Knowledge Base connects to an S3 vector bucket with 2024-dimensional embeddings. When you ask a question, the system finds relevant sections of documents using cosine similarity, searches for matching info in real time, and provides answers based on the most important details.

The setup involves connecting to an S3 vector bucket, automatically updating indexes, and using Bedrock directly – all these components work together seamlessly.

Query Handling Flow

Let's trace a question through the whole system.

Step 1 - User Query: You type a question into the React chat interface, just like you would in any messaging app.

Step 2 - Vector Search: Lambda checks the Bedrock Knowledge Base for relevant document sections. The system finds the 3-5 most relevant pieces of information from your document collection.

Step 3 - Context Response: The Large Language Model creates a response based on the retrieved context and sends it back to the user interface. The answer is based on your actual documents, not general internet information.

Best Practices and Optimization

Building the system is one thing, but making it run well is different. Amin shared important tips for improvement.

Prompt Engineering

Writing good prompts helps get better and more useful answers.

Use clear, specific instructions. Instead of saying "tell me about products," say "list the top 3 features of Product X based on our product documentation."
Add context and examples to your prompts.
Improve your prompts based on the responses you get, prompt engineering is a process that requires adjustments.

Performance Optimization

Speed and cost are important in production

Allow real-time responses so users can see answers as they come in, which improves the user experience.
Use tokens wisely, keep prompts short since tokens cost money.
Set up caching for frequently asked questions.

Key Takeaways

After witnessing this in action, three key points caught my attention:

AWS Bedrock: Secure and Flexible: AWS Bedrock provides a secure and flexible foundation for developing private AI solutions. You receive strong security features without needing to build everything yourself.

Production Ready: Generative AI is now ready for business use and has demonstrated real results that justify the investment. This is no longer just experimentation – companies are implementing these systems in their daily operations.

Easy Implementation: Building a private GPT is simpler than ever with managed services. You don't need to be a machine learning expert to get started.

Conclusion

After leaving that session, I realized that AI isn't just about using ChatGPT. It's about building smart systems tailored to your specific needs while keeping your information secure.

The AWS Student Community Day in Tirupati had many great sessions, but this one impressed me because it demonstrated how to turn an idea into a working demo. Whether you're making a company assistant, a customer support bot, or a documentation helper, the architecture Amin presented provides a solid foundation.

In summary, if you're thinking about adding AI features to your apps, AWS Bedrock makes it simpler than you might expect. With managed services, strong security, and flexibility, you can focus on solving your specific problem instead of building the entire AI setup yourself.

I hope this explanation helps you understand how private GPTs work and inspires you to create your own. The future of AI will be private, secure, and tailored to your personal needs.

About the Author

_As an AWS Community Builder, I enjoy sharing the things I've learned through my own experiences and events, and I like to help others on their path. If you found this helpful or have any questions, don't hesitate to get in touch! 🚀

🔗 Connect with me on LinkedIn_

References

Event: AWS Student Community Day Tirupati

Topic: How AWS Lambda and Fargate Change the Way We Build Apps

Date: November 01, 2025

Also Published On

AWS Builder Center

Hashnode

How AWS Lambda and Fargate Change the Way We Build Apps

N Chandra Prakash Reddy — Thu, 08 Jan 2026 13:02:08 +0000

Attending the AWS Student Community Day in Tirupati at Mohan Babu University was a special experience for me, not just as someone who participated, but also as an AWS Community Builder and someone who enjoys sharing cloud knowledge with beginners and other interested people. The session titled “From Code to Containers: Understanding Serverless Beyond Lambda” by Avinash Dalvi stood out to me right away because it offered something many of us are looking for: clear guidance on when to use Lambda and when to consider other options, especially containers.

Setting the stage: Why “serverless beyond Lambda”?

The session began by discussing the main topic: moving from writing code to using containers, but still keeping the serverless mindset. The key point was that serverless is more than just using functions like Lambda. It’s about thinking in a way that lets you focus on your code, while AWS handles the rest of the work behind the scenes.

The speaker introduced himself as a leader of an AWS User Group Bengaluru and an AWS Community Builder, which made everyone in the room feel confident that the talk would be based on real experiences, not just theory. He focused on helping us understand where Lambda works well, where it might not be the best choice, and how services like AWS Fargate can step in when Lambda can’t handle the job.

The serverless mindset shift

From “I need a server” to “I need to run code when X happens”

One of my favorite parts of the talk was the idea about changing how we think. Usually, people think, “I need a server to run my code.” That way of thinking leads to:

Spending money on server capacity even when traffic is low most of the time
Taking care of the infrastructure, like updating software, fixing security issues, and keeping the system safe
Paying for servers that aren’t being used
Manually adjusting the server size when traffic goes up or down

In short, you end up spending too much time watching over servers instead of working on your app.

The serverless approach changes this by focusing on: “I need to run code when something specific happens.”
That something could be a file being uploaded, an API request, a scheduled task, or an event from another service. Then:

You tell AWS what your needs are, like how long the code runs, how much memory it uses, and how long it can wait for a response.
AWS handles all the setup and management of the hardware and software needed.
You only pay for the time your code actually runs, not for the time it's sitting idle.
When more events happen, the system automatically grows to handle them without you having to do anything.

This change in thinking is what really makes serverless technology powerful, whether you're using Lambda functions or containers in a serverless setup.

Pizza, anyone? Explaining serverless with food

Make it yourself vs order pizza

To make it easier to understand, the speaker used a pizza example. Let’s imagine two choices for dinner:

Option 1: Make it yourself

You buy ingredients
You prepare everything
You cook, serve, and clean up

Option 2: Just order pizza

You specify what you want
Someone else handles the kitchen, oven, and cooking
You pay for the pizza, not for owning a restaurant

Traditional servers, like EC2, are like cooking at home. You take care of the kitchen (server), keep the oven running (patching, updates), and you pay for it all the time, even when you’re not cooking. You have full control, but you also have to take care of everything yourself.

Serverless is like ordering pizza. You just give your order (code), say what you want (toppings, size, base), and AWS handles the rest. You only pay for what you eat, not for keeping the kitchen open all day.

Ordering your serverless pizza

The session continued by using the analogy to explain how to build a serverless application.

Base (Runtime/Language)

Choose Python, Node.js, Java, Go, .NET, Ruby, etc.
Or “bring your own base” using containers when you need something custom.

Toppings (Resources)

RAM from a small amount up to several GB
Temporary storage space
CPU that scales with memory

Size (Code Complexity)

Small: simple functions
Medium: moderate logic
Large: complex applications

When should it run?

Immediate on events (like file uploads)
Scheduled (cron-style jobs)
On-demand via API calls

This helped the students in the room better relate their daily experiences to the decisions made in cloud computing.

Lambda in action (and where it struggles)

A simple Lambda example: image resizer

To make it more clear, there was a slide that showed a Lambda function used to resize images that were uploaded to S3. The code used was:

boto3 to talk to S3
PIL (Python Imaging Library) to open and resize the image
A lambda_handler function that:

Reads the file details from the S3 event
Downloads the image to /tmp
Creates a thumbnail
Saves the processed image back and returns a success status

This kind of situation is exactly where Lambda works best: for small, trigger-based, short-running tasks like image resizing, making thumbnails, simple API support, and light data processing.

When Lambda hits the wall

But Lambda isn’t without its limits, and the speaker was very open about that. There was a slide called “When Lambda hits the wall” that listed situations like:

Uploading a video → Lambda works great
Generating a thumbnail → Lambda is perfect
Transcoding a full video → Lambda fails

Why does it fail here? Because:

Video processing might take 45 minutes
Lambda has a hard timeout limit (15 minutes in the slides)
You may need more control over the environment
Larger dependencies or special tools may be required

So even though serverless technology is strong, you still need to choose the right tool within that serverless environment. That’s where AWS Fargate comes in.

Lambda vs Fargate: same pizza shop, different options

Comparing Lambda and Fargate

One slide showed a table comparing Lambda with Fargate using the same restaurant analogy:

What it is

Lambda: standard menu
Fargate: custom recipe

Base options

Lambda: pre-set runtimes
Fargate: any container image

Customization

Lambda: limited to what the menu supports
Fargate: fully customizable environment

Execution time

Lambda: up to the configured limit (15 minutes in the slide)
Fargate: effectively unlimited for long-running tasks

Code size

Lambda: limited package size
Fargate: no strict limit; your container image can hold more dependencies

Use case

Lambda: quick, short functions
Fargate: long processes, heavy workloads

Cold starts

Lambda: can happen
Fargate: more consistent performance once tasks are running

The bottom line? Lambda is like quickly ordering from a standard menu, while Fargate lets you bring your own recipe and ingredients but still avoids managing the kitchen yourself.

Fargate – bring your own recipe and enjoy the freedom

Another slide described Fargate as “Bring Your Own Recipe”:

You package your app into a container (Docker image)
AWS runs it for you without asking you to manage servers

Then came “Fargate – The Freedom” with three angles:

More control

Any programming language
Any runtime version
Custom OS-level dependencies
Specific tools and libraries you can’t easily run in Lambda

More capacity

Run for hours or days
No 15-minute limit
Much higher memory and CPU options

More use cases

Long-running processes
Legacy applications that expect a traditional environment
Microservices with specific runtime needs
Batch jobs and background processing

This made it clear that Fargate is still “serverless” in the sense that you don’t manage servers, but you get container-level flexibility.

Architecture patterns you can try

Practical patterns from the slides

One of the most helpful slides showed different architecture patterns that students could try at home. Some examples included:

Event-driven API

S3 upload → Lambda → DynamoDB
Great for things like uploading documents and storing metadata.

Scheduled jobs

EventBridge (cron) → Lambda → process data
Perfect for nightly reports, cleanup jobs, or scheduled notifications.

Microservices

API Gateway → Lambda or Fargate → backend services
Useful when building modular, independently deployable services.

Data pipeline

S3 → Lambda (trigger) → Fargate (heavy processing) → S3
A strong pattern when you need to combine quick triggers with long-running tasks.

Webhook handler

GitHub/Stripe → API Gateway → Lambda → action
Common for reacting to external events like payments or code pushes.

These patterns link what students learn in class to actual projects they might work on, like building apps for school, starting their own business, or doing internships.

When NOT to use serverless

Being honest about trade-offs

One slide caught my attention because it said: “Be honest – serverless isn’t always the best choice.” That’s a key point, especially for newbies who are excited about a fresh new idea. The slide listed some situations where serverless might not be the right fit:

When you have steady and high traffic that could be handled more affordably with always-on infrastructure
When you need a lot of control over the environment at a lower level
When tasks run for a long time and go beyond what a serverless function can handle
When you aren’t sure about your needs yet and might complicate things by using too many managed services too early

In the end, serverless is just another tool. The real skill is knowing when to use it and when something else, like containers or even basic EC2 instances, would work better.

Lambda vs Fargate: a simple decision tree

A mental model for choosing

There was also a clear decision tree to help choose between Lambda and Fargate. The simplified way of thinking about it went like this:

Do you need to run code at all?
Will it finish in under 15 minutes?

If no → consider Fargate for long-running processes with a custom environment.

If yes, is it a standard runtime (like Python, Node.js, etc.) with manageable dependencies?

If yes → Lambda is usually the fastest and cheapest option.
If no → again, Fargate or another container-based approach likely fits better.

This kind of straightforward flow is really useful when you're building your first few architectures and aren't sure which service to use.

Key takeaways from the session

The slide summary and my own reflections

The final “Key Takeaways” slide put everything together with points like:

Serverless is like ordering pizza instead of running your own restaurant
Understand Lambda vs Fargate instead of blindly choosing one
Focus on code, not servers
Pay for value, not idle time

For me personally, the biggest takeaway was that “serverless” isn’t just for Lambda. You can think serverless even when using containers, as long as AWS takes care of setting up and scaling your resources, and you focus mainly on your application.

Conclusion

This session at AWS Student Community Day in Tirupati was really helpful because it reminded me that good tech talks don't just list features, they change the way you understand things. The pizza example, the open talk about the limits of Lambda, and the introduction to Fargate as a strong "serverless containers" option made the topics easier to grasp, especially for students who are just starting to learn about these services.

As an AWS Community Builder, events like this keep me motivated because they show how quickly curiosity can turn into actual projects when you get the right examples and ways of thinking. If this topic interests you, try picking a small use case from your own life, like processing images from your app or running a scheduled cleanup, and try building it using Lambda or Fargate. Getting your hands on these tools will teach you more than any presentation ever could.

About the Author

🔗 Connect with me on LinkedIn

References

Event: AWS Student Community Day Tirupati

Topic: How AWS Lambda and Fargate Change the Way We Build Apps

Date: November 01, 2025

Also Published On

AWS Builder Center

Hashnode

How Serverless & Community Can Transform Your Career

N Chandra Prakash Reddy — Tue, 06 Jan 2026 13:32:30 +0000

When I walked into the Dasari Auditorium at Mohan Babu University on November 1st, 2025, for AWS Student Community Day Tirupati, I knew I was in for something special. The room was full of energy, with more than 400 students+ and others gathering to learn about cloud technologies. But one session stood out to me, Srushith Repakula’s talk on "How Serverless & Communities Changed My Career, and Can Change Yours Too."

What made this session really special wasn’t just the technical stuff. It was the open conversation about failing, the value of staying curious, and how a mistake that cost ₹4 lakh became the beginning of a great journey that led to becoming an AWS Serverless Hero.

Understanding Serverless: From Cars to Code

To be honest, when you hear the term "serverless," it sounds strange. After all, if anything depends on servers, how can it be server-less?

Here's the thing: Srushith made everything make sense with a clever analogy. Consider how automobiles have changed over time:

Traditional Servers = Buying a Car: Whether you drive it or not, you own it, accept full responsibility for it, maintain it, and pay for it.
VMs/Containers = Renting a Car: You share some responsibility, lease it, and customize it.
Serverless = Ride-Sharing (like Uber or Ola): It is entirely on-demand, requires no maintenance, and you only pay for each journey.

That final alternative is exactly how serverless computing operates. You only pay for the real time your code runs; the cloud provider manages all the infrastructure and dynamically distributes resources. Your funds won't be wasted on idle servers. No hassles with capacity planning.

Why Serverless Matters (Especially for Beginners)

"Why should I care about serverless as a student or early-career developer?" may be on your mind. Srushith outlined four strong arguments:

Learn Faster: Get started right away by writing code and deploying it without setting up servers or infrastructure.
Build Quicker: Within hours, not days, turn your hackathon ideas into functional apps.
Pay Less: You can explore without worrying about huge fees because there are no idle costs.
Scale Smarter: Your app won't break during that viral moment since AWS automatically manages traffic spikes.

The Journey: From Zero to Serverless Hero

My First Lambda: A Beautiful Disaster

The intriguing part of Srushith's story began at this point. Imagine the following scenario: "A chatbot challenge, a new laptop, and zero clue about AWS."

Do you recognize this? Most of us begin there. He didn't fully grasp the fundamental ideas before he started developing something. Next was "The ₹4 Lakh Mistake."

He experimented out of curiosity, but without the right safeguards, he unintentionally established an endless loop that resulted in a huge AWS cost. To be fair, this was an emotional as well as a financial setback. Here's what he discovered the hard way, though:

Understand before you deploy: Before putting your code into production, understand what it does.
Set budgets and CloudWatch alarms: Always establish financial safeguards
Curiosity is great, guardrails are greater: Take risks, but guard against costly errors.
Failure is just tuition you pay for learning: You learn something worthwhile from every error.

From Failure to Community

That ₹4 lakh error might have put a stop to his AWS career. Rather, it sparked something powerful. This is the course of his transformation:

The Panic (2016): Accidentally produced an endless loop, but it sparked sincere interest in fully understanding AWS

The Search (2016): Learned about AWS User Groups while digging deeply into blogs, videos, and documentation to figure out what went wrong.

The Meetup (2017): Met incredible builders at his first AWS meetup, told his story of failure, and connected with others who had experienced similar things.

The Belonging (2018): His community journey really started when he began volunteering, giving speeches, and lending a hand to others.

To put it another way, his failure served as a gateway to the community. And everything altered as a result.

Real-World Impact: Serverless at KonfHub

Srushith spoke on more than just theory. He explained why serverless works for KonfHub, a technical meeting platform built solely on AWS, in his capacity as Head of Engineering:

AI-Powered Networking Suggestions

Problem: Attending conferences by hand is ineffective and causes people to lose out on important contacts.

Solution: Using Amazon Bedrock and AWS Lambda, they developed an AI-powered recommendation system that instantly offers relevant connections.

Imagine having a smart assistant at every conference that knows exactly who you should meet according to your goals, role, and hobbies.

Why KonfHub Chose Serverless

Scale Effortlessly: Manage over 80,000 people at peak registration times with no downtime.
Pay for What You Use: Cost is equal to real consumption, not idle server capacity.
Secure by Design: IAM policies and managed infrastructure lower security overheadThe
Build Fast: Their distinctive selling proposition is developer velocity, which allows them to launch improvements fast without infrastructure delays.

The Evolution: How We Got Here

When you consider the development of computing infrastructure, it becomes easier to comprehend serverless:

Physical Machines: Needed a lot of guessing to plan, stayed on-premises for many years, required big money upfront, took a long time to set up, and didn't offer much new or creative ideas.

Virtual Machines: Made systems more independent of specific hardware, sped up the process of setting up new systems, lowered costs by sharing resources (changing from buying equipment to paying for usage), improved ability to grow, and made it easier to adapt quickly.

Containers: Allowed apps to work on any platform, provided the same environment every time they run, used resources more efficiently, made it quicker to deploy new features, kept processes separate to avoid issues, and started up in just seconds.

Serverless: Automatically adjusts resources as needed, handles system failures automatically, charges based on actual usage, requires no extra maintenance, and lets teams create new ideas without being limited by the underlying setup.

Each step made it easier to manage the system, so developers can concentrate on building good apps instead of worrying about the infrastructure.

Key Takeaways: Your Roadmap Forward

Srushith concluded with three strong principles that can help any cloud enthusiast on their journey:

Curiosity: Where It All Begins

Start small. Try things. Fail. Learn.
Curiosity fuels creativity, not perfection
Don't wait until you "know enough" to start experimenting

Community: The Fuel That Keeps You Going

Find your people and learn together
Share your wins and your mistakes, both teach others
Communities help you learn more and open up new opportunities you never thought possible.

Serverless: The Enabler of Scale

Build fast, fail safely, scale effortlessly
Innovation without the infrastructure overhead
Perfect for students, startups, and teams wanting to move quickly

My Reflections as an AWS Community Builder

Attending this session made me remember why I love AWS and community events so much. As someone who helps build the AWS community, I’ve seen how powerful these experiences can be, not just for learning new skills, but also for gaining confidence, finding mentors, and discovering new career paths you never thought possible.

The AWS Student Community Day in Tirupati had many great sessions, but Srushith’s talk really stood out because it was honest, practical, and hopeful. It showed that failure isn’t the end, it’s just part of the process.

For Aspiring AWS Enthusiasts

If you’re just starting your cloud journey, here’s what I recommend:

Don’t be scared to try things out, just make sure you set limits to stay safe. Join your local AWS User Group, they can help you grow much faster. Start with serverless technology, it makes it easier to get started and lets you focus on solving problems instead of managing complex systems. Share what you learn, even if it seems simple, someone else might be exactly where you were before and need to hear your story.

In the end, your cloud journey is about more than just getting certifications or technical skills. It’s about staying curious, being part of a community, and having the courage to keep going even when things don’t go perfectly.

Conclusion

Srushith's story shows that a big mistake, like spending ₹4 lakh, can turn into a great learning experience. AWS Serverless helps you turn ideas into real projects without worrying about the complicated parts of building infrastructure. The AWS community is ready to help you along the way. So, set up budget alerts, write your first Lambda function, and start your journey today. Your path to the cloud starts with being curious, not perfect.

About the Author

🔗 Connect with me on LinkedIn_

References

Event: AWS Student Community Day Tirupati

Topic: How Serverless & Community Can Transform Your Career

Date: November 01, 2025

Also Published On

AWS Builder Center

Hashnode

Voice Agents with Amazon Nova Sonic

N Chandra Prakash Reddy — Tue, 30 Dec 2025 12:59:02 +0000

I went to the AWS User Group Chennai Meetup on September 27, 2025, and one session really stood out to me. Ilanchezhian Ganesamurthy, who is an AWS Hero, gave a really interesting talk about creating Voice AI Agents using AWS Voice Technology and Amazon Nova Sonic. Since I've always been interested in how AI is making technology more conversational and easier to use, this session provided a lot of useful and practical information.

Let’s be honest, we’ve all had those annoying customer service calls where the AI just doesn’t understand what you’re saying. This session shows how we’re moving away from that and moving toward something more natural and smart.

Understanding Voice AI Agents

Voice agents use the speech and thinking powers of large language models, like the ones behind Alexa or Siri. These agents can talk back and forth in a way that feels real, understanding what you’re saying and even handling interruptions during a conversation.

You might be thinking, why is this important? Picture calling your bank and having a chat that feels like a real conversation. You can stop to ask questions, and the AI listens and adjusts to how you speak. That’s the power of today’s voice agents.

Two Approaches to Building Voice Agents

The traditional approach breaks voice interaction into three distinct steps:

Speech-to-Text (STT): Your voice is turned into text using services like AWS Transcribe, Deepgram, or Azure AI Speech.
Large Language Model (LLM): The text is handled by AI models such as Amazon Bedrock, Google Gemini, or Azure OpenAI to figure out what you mean and create a reply.
Text-to-Speech (TTS): The AI's reply is then changed back into speech using tools like AWS Polly, ElevenLabs, or Azure AI Speech.

The thing is, this method works for a lot of situations, but there's a downside. Each step adds a little delay, so there's a small time gap between when you speak and when you hear the response. In customer service, even a tiny delay can affect how natural the conversation feels.

The setup shown in the session uses Pipecat, which is a framework that helps organize conversational AI parts. It connects users through WebRTC for real-time chats. It also includes Voice Activity Detection to know when someone is talking, Amazon Transcribe for understanding speech, Pipecat Flows to manage the conversation, Amazon Bedrock for thinking through the response, and Amazon Polly to turn text back into speech.

Speech-to-Speech with Amazon Nova Sonic

Amazon Nova Sonic is changing the way things work. Instead of going through three steps, it uses a direct speech-to-speech model that handles the whole conversation without turning speech into text in between.

Does that sound familiar? It's similar to the difference between translating each word of a conversation separately versus truly understanding the whole meaning and responding in a natural way. Nova Sonic does this using a bidirectional streaming API, allowing it to listen and reply at the same time, just like people talk in real life.

The setup is simpler: voice input goes through VAD, then straight to Nova Sonic for processing, with Pipecat handling the conversation’s context and state. This makes the system faster and helps create more natural conversations.

Amazon Nova Sonic: Core Capabilities

Let me break down what makes Nova Sonic special:

Low latency: It allows for live conversations between people where the speech is converted to speech with very little delay.
Multilingual support: It can understand many languages and different ways people speak, making it useful around the world.
Expressive voices: It provides eleven different voice choices in English, Spanish, German, French, and Italian, including both male and female voice options.
Natural dialog handling: What makes it really good is that it can understand and adjust to pauses, stutters, and interruptions in speech while keeping track of the conversation.
Tool integration: It can link to company software and tools, so it can use your business's own information to reply.
Task completion: It helps people answer questions, make bookings, and complete tasks related to their work.

Amazon Nova Model Family

The session also mentioned that Nova Sonic is part of a bigger Amazon Nova family. Let me give you a quick summary:

Nova Micro: Fast, text-only model for lowest latency responses
Nova Lite: Multimodal model that understands text, images, and video, great for quick processing
Nova Pro: Best combination of quality and speed for complex multimodal tasks
Nova Premier: The most capable model for complex tasks and teaching other models on Amazon Bedrock
Nova Canvas: Image generation model
Nova Reel: Video generation model
Nova Sonic: Live speech model for natural voice conversations
Nova Act: Research preview for advanced capabilities

Each model is designed for different purposes, but Nova Sonic focuses on voice interaction.

Real-World Use Cases

To be fair, knowing the technology is one thing, but knowing where to use it is really important. The session showed several real-world uses:

Customer service: First, helping customers with their questions, handling sales requests, or answering insurance-related queries, any situation where you’d usually have a call center agent.
Task automation: Second, making bookings, managing sales processes, and finishing transactions through voice.
Learning and development: Third, helping people improve their skills and doing practice interviews.
Healthcare accessibility: Improving accessibility in medical settings and therapy applications

In short, if your business involves phone interactions or voice-based experiences, voice agents could change how you run your business.

Technical Components

For those who want to know more about the technical part, let me explain some important ideas from the session in a simpler way:

ASR (Automatic Speech Recognition): Also called STT, converts your speech to text
TTS (Text-to-Speech): Also called Speech Synthesis, converts text to spoken words
LLM: The AI brain that understands meaning and generates intelligent responses
VAD (Voice Activity Detection): Detects when humans are speaking in audio, helping the system know when to listen
WebRTC: Real-time communication protocol using UDP for full-duplex, persistent connections, ideal for live voice
WebSocket: TCP-based full-duplex connection designed for streaming audio and video

Knowing these basic parts can help you design better voice-based systems.

Conclusion

Voice AI is changing quickly, and Amazon Nova Sonic is helping make conversations sound more real than ever. It's great for creating customer service chatbots, tools that help people with disabilities, or anyone interested in the future of AI. It's a good idea to try it out if you're working on similar projects.

The AWS User Group Chennai gathering keeps offering useful talks like this one, so if you're nearby, you should consider joining.

About the Author

🔗 Connect with me on LinkedIn

References

Event: AWS User Group Chennai Meetup

Topic: Voice Agents with Amazon Nova Sonic

Date: September 27, 2025

Also Published On

AWS Builder Center

Hashnode

Reliable Data with AWS Glue Data Quality

N Chandra Prakash Reddy — Thu, 25 Dec 2025 13:42:53 +0000

On September 27, 2025, I went to the AWS User Group Chennai Meetup and it was really full of great sessions. One of the talks that impressed me the most was by Abinaya, an AWS Community Builder, who spoke about "Ensuring Reliable Data with AWS Glue Data Quality in the Catalog." If you've ever worked on data pipelines, you probably know how frustrating it can be to deal with poor data quality. It's like trying to build a house on unstable ground, no matter how strong your analytics or machine learning models are, bad input means bad output.

Let's be honest: data quality is something everyone understands is important, but it's often ignored or left for later. This session really changed how I see AWS Glue Data Quality. It showed me that data validation can be not only easier but also scalable and more cost-effective.

What is AWS Glue?

Before we talk about data quality, let's briefly explain what AWS Glue is. AWS Glue is a serverless ETL (Extract, Transform, Load) service offered by AWS. Imagine it as a tool that helps you move data from one location to another like from a database to a data lake and also changes the data as it goes.

The session mentioned that Glue is serverless, which means you don't have to manage servers or the underlying infrastructure. You can focus on transforming your data, and AWS takes care of everything else. It includes several useful features like:

A data crawler that automatically finds and understands the structure of your data
A data catalog that works like a central place to store information about your data
ETL jobs that you can run on a schedule or start when certain events happen

Here’s the thing: AWS Glue is great for creating data pipelines, but what if the data moving through those pipelines isn’t consistent, missing pieces, or just incorrect? That’s where AWS Glue Data Quality steps in.

Why Data Quality Matters

The session made a key point: if your data is inconsistent or of poor quality, your insights won't be reliable. Think about running an e-commerce site where your sales data has duplicate orders or missing customer details. Your reports might show higher sales than they actually are or incomplete customer profiles. Has this ever happened to you?

Validating data is essential for building trust in your data lakes. Without proper validation, you're like trying to navigate without seeing where you're going. The speaker said traditional ways of validating data take a lot of time and money. Usually, you'd have to write custom scripts, keep them updated, and run them separately from your ETL processes.

AWS Glue Data Quality changes things by making validation quicker and automatic. Instead of spending days or weeks creating validation systems, you can set up data quality rules right inside your Glue jobs.

Understanding AWS Glue Data Quality

What It Actually Does

AWS Glue Data Quality is based on DeeQu, which is an open-source data quality tool created by Amazon. Here's what makes it unique:

The service offers three main types of features:

Rule: Individual data quality checks you define
Ruleset: A collection of rules grouped together for validation
Tags/Parameters: Metadata you can attach to track costs and organize your rulesets

You may be wondering what kinds of checks you can do. AWS Glue Data Quality allows you to:

Rulesets for validation: Define specific conditions your data must meet
Performance monitoring: Track how your data quality checks are performing over time
Cost tracking in AWS Cost Explorer: See exactly how much you're spending on data quality checks

The Technical Foundation

AWS Glue Data Quality uses DeeQu, an open-source framework that Amazon built and shared with the public. This means you aren't tied to a specific company's tools. If you ever decide to leave AWS Glue, you can still use your data quality rules because they are based on open standards.

Key Insights from the Session

The speaker gave some very useful tips about using AWS Glue Data Quality in a real-world setting:

Runtime and Cost

The time it takes to run the data quality checks goes up as the number of rules increases. That makes sense because more rules mean more checks to do. But the good news is that the cost depends on how much compute power you use, and it stays low, usually between $0.18 and $0.54.

Let me explain that. A DPU is a unit of computing power used by AWS Glue. Even if you have a lot of data quality checks, the cost is still less than a dollar for most tasks. That's much cheaper than building and running your own data validation system.

Tracking and Optimization

Tagging your rulesets helps you keep track of and manage your spending. Tags are like labels for different projects or teams. For example, you can tag a ruleset with "team:marketing" or "project:customer-analytics." This lets you see in AWS Cost Explorer which teams or projects are using the most data quality resources, and helps you manage costs better.

This is where things get really helpful: Glue Data Quality can cut validation time from days to just a few hours. Traditional data quality checks often run as separate jobs after your data is processed. With Glue Data Quality, you can check data quality while it’s still in memory during the data processing step, which is way faster.

Rulesets Categories Explained

The session explained how rulesets are structured. Understanding this helps you think about data quality in a more organized and manageable way:

Individual Rules

A Rule is a single data quality check. For example:

Make sure the "email" column has no empty or missing values.
Check that "order_amount" is always a positive number.
Ensure that "created_date" is not a future date.

Rulesets

A Ruleset is a group of related rules. You can put similar rules together based on how they fit your needs. For example, you might have:

A "Customer Data" ruleset that includes rules for customer information.
An "Order Validation" ruleset that includes rules for order details.
A "Financial Compliance" ruleset that covers rules for following financial regulations.

Tags and Parameters

Tags or Parameters allow you to add extra information to your rulesets. This is really helpful for:

Organizing rulesets by team, department, or project
Tracking costs at a granular level
Implementing governance policies

In short, this three-level structure lets you organize your data quality checks in a way that works best for your company.

Best Practices for Implementation

The session ended with some useful tips on how to use AWS Glue Data Quality effectively. These tips are really helpful if you're thinking about setting up data quality checks.

Start Simple, Then Scale

Start with easy rules and then add more as you go. Don't try to create a perfect system right away. Begin with simple checks like:

Are there any missing values where data should be?
Are the data types correct?
Are all the necessary fields there?

Once these basic checks are working well, you can add more complex rules such as checking if data links correctly between different datasets or comparing data across different sources.

Use Tags for Cost Monitoring

Use tags to keep track of costs. It might seem simple, but it's easy to forget. Tag your rule sets from the beginning so you can see how much you're spending as your system grows. You'll be glad you did when someone asks, "How much are we spending on data quality for the marketing database?"

Enable Caching

Turn on caching to make things faster. AWS Glue Data Quality has a caching feature. If you run multiple checks on the same data, it won't have to read the data again each time. This can help speed things up and save money.

Monitor Actively

Connect with alerts and dashboards to keep an eye on things. AWS Glue Data Quality can send notifications through Amazon EventBridge when there are data quality problems. Set up alerts so your team gets notified right away when something goes wrong. You can also create dashboards in Amazon CloudWatch or another tool to track data quality trends over time.

The Key Advantage

To be fair, the speaker really stressed this point: AWS Glue Data Quality is scalable, reliable, and cost-efficient for validation. It's not just about having data quality checks, it's about having them run automatically as part of your pipeline without making costs go up or needing constant attention.

The session also showed that AWS Glue Data Quality automates the creation of rules, which saves you from doing a lot of manual work. You can even use the built-in machine learning features to automatically suggest rules based on your data. In short, you spend less time writing validation code and more time using your data.

Real-World Scenarios

Let me give you a couple of real-world examples to make this clearer:

Scenario 1: E-commerce Order Pipeline

Imagine you're collecting order data from different places, your website, mobile app, and third-party marketplaces. You could set up a ruleset that checks:

Order IDs are unique
Customer emails are valid format
Order totals match the sum of line items
Payment status is one of the allowed values

If any order doesn't meet these checks, you can set the pipeline to separate the bad records and send an alert to your team, while letting the good records go through.

Scenario 2: Healthcare Data Compliance

For healthcare organizations that handle patient data, data quality isn't just a nice feature, it's a legal requirement. You could use AWS Glue Data Quality to check:

That patient identifiers are present and properly formatted
That dates of birth are within valid ranges
That all required fields for regulatory reporting are filled in
That sensitive data is properly encrypted

The system would automatically create compliance reports showing which records passed the checks and which ones need to be reviewed.

Conclusion

At the end of the day, AWS Glue Data Quality helps change messy and unreliable data into something teams can really trust for using in reports and making decisions. By making sure data checks are an important part of your data pipelines, not something you forget about later, you get quicker results, less money spent, and way fewer problems when you share your reports or dashboards.

For people building data systems on AWS, starting with just a few simple rules and slowly adding more to your data quality plan is a smart way to make your work more dependable and trustworthy every day.

About the Author

🔗 Connect with me on LinkedIn

References

Event: AWS User Group Chennai Meetup

Topic: Reliable Data with AWS Glue Data Quality

Date: September 27, 2025

Also Published On

AWS Builder Center

Hashnode

Building Practical AI Agents with Amazon Bedrock AgentCore

N Chandra Prakash Reddy — Thu, 25 Dec 2025 07:44:43 +0000

Why This Session Instantly Hooked Me

I spent my Saturday at the AWS User Group Chennai meetup, and one session really caught my attention: a detailed look at Amazon Bedrock AgentCore and how it helps in creating real AI agents.

The speaker, Muthukumar Oman, who is the VP – Head of Engineering at Intellect Design Arena and an AWS Community Builder, explained how to take an AI model from a basic demo to a fully working AI agent in a clear and organized way.

There were other good talks that day, but this one stood out because it addressed a question many of us have been thinking about: How can we go beyond simple chatbots and actually build a dependable AI agent that works with our systems?

What Is Amazon Bedrock AgentCore?

Making Sense of AgentCore in Simple Terms

AgentCore acts as the main control center for your AI agents on AWS.

It helps you:

Deploy and operate agents securely at scale
Ensure trust and reliability when agents call tools and APIs
Use built-in tools like a code interpreter and browser
Stay framework- and model-agnostic, so you can bring your favorite stack
Test and monitor agents in a structured way

Imagine it this way: if a regular LLM is like a smart intern, AgentCore is like the IT, security, and support team that helps that intern use different apps, keeps track of their work, and makes sure everything stays secure.

Where AgentCore Fits in the AI Stack

One of the slides showed the full AI structure on AWS: applications at the top, followed by AI and agent development tools and services, then Amazon Bedrock (which includes models, features, and AgentCore), and finally the underlying infrastructure such as Amazon SageMaker and AI compute resources like Trainium, Inferentia, and GPUs.

In other words:

Infrastructure = raw compute and ML tooling
Bedrock = models and agent building blocks
AgentCore = runtime, memory, gateway, observability, and identity for agents
Applications = what your users actually interact with (like support bots, internal copilots, etc.)

Core Building Blocks of AgentCore

AgentCore Runtime – The Engine Behind the Agent

The AgentCore Runtime slide explained what happens when your agent starts working.

Key points that stood out:

Framework agnostic – you’re not locked into a specific agent framework
Model flexibility – you can plug in different models
Protocol support, extended execution time, and enhanced payload handling
Session isolation, built-in authentication, and agent-specific observability
Unified set of agent-specific capabilities

There was also a diagram showing how your agent or tool code, like a Python framework, is structured.

Packaged as a container
Pushed to ECR
Exposed via an AgentCore endpoint
Connected to a model and the Bedrock AgentCore runtime

Imagine deploying a microservice: you package your code into a container, send it out, and AgentCore connects it to models and tools.

Memory – Short-Term vs Long-Term

This part really caught my attention. The speaker divided AgentCore Memory into different parts.

Short-term memory

Immediate context
In-session knowledge accumulation

Long-term memory

User preferences
Semantic facts
Summary

In the architecture view, short-term memory stored things like chat messages and session details, while long-term memory kept semantic data, user preferences, and summaries.

Another slide showed how long-term memory functions:

Short-term memory = raw storage
Long-term memory = vector storage
A memory extraction module finds relevant information based on events and strategies, combines it, and then creates an embedded version that can be searched.

Imagine your agent is like a person:

Short-term memory is about the conversation you're currently having.
Long-term memory is about what I’ve learned about you from previous chats and over time.

For a banking or e-commerce assistant, this could mean remembering:

Your preferred language
The kind of products you usually buy
Important facts like “this user prefers digital invoices”

Built-In Tools: Code Interpreter and Browser

Code Interpreter – Let the Agent Safely Run Code

The Code Interpreter slides explained how an agent can safely run code within a sandbox environment.

The architecture was roughly:

User sends a query to the agent
Agent invokes the LLM
LLM selects the Code Interpreter tool and creates a session
Code runs inside a sandboxed environment with a file system and shell
Telemetry flows into observability
Results are returned to the user

The Code Interpreter capabilities listed included:

Secure sandbox execution
Multi-language support
Scalable data processing
Enhanced problem-solving
Structured data formats
Ability to handle complex workflows

Imagine giving your agent a temporary, secure laptop where it can execute scripts, handle CSV files, or process data, while you keep a close watch on everything.

Browser Tool – Let the Agent Navigate the Web or Apps

Another built-in tool is the Browser Tool.

The flow looked like this:

User sends a query (e.g., “Buy shoes on Amazon”)
Agent invokes the LLM
LLM chooses the browser tool
Commands like “click left at (x, y)” are generated
A library (e.g., browser automation) translates these into real actions
The browser executes them and sends screenshots/results back to the agent

The Browser Tool capabilities mentioned:

Resource and session management
Rendering live view using AWS DCV web client
Observability and session replay

In simple terms: your agent can actually interact with a user interface, not just describe it. This is really important when dealing with older systems inside a company that might not have APIs available.

Gateway, Identity, and Observability – Production-Ready Concerns

AgentCore Gateway – One Door for All Tools

The AgentCore Gateway shows how agents connect to tools and APIs in a single, unified way.

Key ideas from the slides:

Simplified tool development and integration
Unified tools access and semantic tool selection
Security guard and serverless infrastructure
Tool types: OpenAPI specs, Lambda functions, Smithy models

Architecturally, the gateway:

Sits between agents and APIs/tools
Handles inbound authentication (via tokens)
Routes to different targets: Smithy, OpenAPI, AWS Lambda
Integrates with Identity for credentials and CloudWatch for observability

If you've ever connected an LLM to many APIs by hand, you know how frustrating that can be. The gateway acts like a main router and enforces rules for using tools.

AgentCore Identity – Who Is This Agent, Really?

Identity is managed through AgentCore Identity, which focuses on:

Centralized agent identity management
Credentials storage
OAuth 2.0
Identity and access controls
SDK integration
Request verification security

It’s like IAM, but better suited for agents and their tools: agents don’t just randomly call APIs; they do so with proper authentication, limited access credentials, and verified requests.

AgentCore Observability – Seeing What Your Agent Is Doing

Observability was another big emphasis:

OTEL-compatible
Runtime metrics
Memory metrics
Gateway metrics
Tools metrics
Sessions, traces, spans

In short, you don’t have to guess what’s happening. You can track how an agent handled a user request, which tools it used, how long each step took, and where things went wrong.

Strands Agents vs Bedrock Agents vs AgentCore

One slide compared Strands Agents, Bedrock Agents, and AgentCore based on several different factors.

So, if you’re:

Experimenting quickly → Strands may be fine.
Shipping something fast → Bedrock Agents are convenient.
Building enterprise-grade, highly customized agents → AgentCore gives you more control while still leaning on AWS-managed pieces.

How All of This Comes Together for Real-World Apps

From “Toy Chatbot” to Production Agent

The speaker used several diagrams showing how an app communicates with AgentCore Runtime, which then interacts with:

Models
Memory
Gateway
Identity
Observability

In real situations, this allows you to create use cases like:

A customer support agent that keeps track of past conversations and user preferences.
A financial assistant that uses browser tools to access internal systems and retrieves data safely.
A developer assistant that runs code using the code interpreter and records all actions for review.

Why This Matters for Builders Like Us

If you're creating a startup product or working in a team within a large company, the usual challenges are similar:

“How do I handle sessions and memory in a reliable way?”
“How can I link agents to different tools without causing serious security issues?”
“How do I figure out what went wrong when something doesn’t work as expected?”

AgentCore helps solve these problems by:

Structured runtimes and memory
Gateway and identity for secure tool access
Deep observability for traces and metrics

In the end, it takes AI agents from being a makeshift side project to something that operations, security, and compliance teams can really trust and use.

Conclusion

Amazon Bedrock AgentCore showed me that creating strong AI agents isn't just about making another chatbot. It's more about getting the basics right, like memory, tools, security, and the ability to track what's happening. When runtime, gateway, identity, and built-in tools all work together, they form a solid base. This helps move from quick weekend projects to real, reliable AI experiences that teams can trust and grow.

About the Author

As an AWS Community Builder*, I enjoy sharing the things I've learned through my own experiences and events, and I like to help others on their path. If you found this helpful or have any questions, don't hesitate to get in touch!* 🚀

🔗 Connect with me on LinkedIn

References

Event: AWS User Group Chennai Meetup

Topic: Building Practical AI Agents with Amazon Bedrock AgentCore

Date: September 27, 2025

Also Published On

AWS Builder Center

Hashnode

Securing PII in Data Lakes: AWS Lake Formation Access Control

N Chandra Prakash Reddy — Tue, 23 Dec 2025 13:47:36 +0000

I recently went to the AWS Community Day in Bengaluru in 2025 on May 23rd, and I have to say, it was full of amazing sessions. One presentation that stood out to me was "PII Data Management with Lake Formation" by Ankit Sheth. As someone who's always been interested in how companies manage sensitive data on a large scale, this session was just what I was looking for. The talk focused on the access layer of AWS Lake Formation and how it helps provide secure, role-based access to data lakes.

Let's be honest, handling permissions for sensitive data can turn into a big mess, especially when you're managing different types of data all in one place. This session showed me how Lake Formation deals with that issue directly.

What is a Data Lake? (And Why Should You Care?)

Before we get into the technical details, let's start with the basics.

A data lake is like a big digital storage space where you can keep all your data, both organized and messy, no matter how much there is. You can store things like customer information, app logs, pictures, videos, and data from sensors. It doesn't matter how the data looks or how big it is.

The thing is, traditional databases need you to set up the structure before you start storing data. Data lakes work differently. You save the raw data first, and then decide on the structure when you actually use or look at the data (this is known as "schema-on-read"). This approach makes data lakes very flexible and also more cost-efficient.

Key Characteristics of Data Lakes

According to the session, data lakes have some really strong features:

Single source of truth - All your information is stored in one place, so it's easier to find and work with.
Support for multiple formats - Data lakes can handle all types of data, whether it's organized CSV files, somewhat organized JSON files, or even plain, unorganized files.
Fast ingestion and consumption - Data can be added quickly and used by different tools for analysis.
Low-cost storage - Most data lakes on AWS use Amazon S3 for storage, which makes the cost much lower than using traditional databases.
Decoupled storage and compute - You don’t pay for the computer power when you’re just keeping data safe. You only use the tools for analyzing data when you actually need them.
Built-in protection and security - With tools like Lake Formation, you can set up detailed rules for who can access what and keep track of who is using the data.

Sound familiar? If you’ve ever had trouble with data tucked away in different places, you’ll understand why this approach makes sense.

Why the Access Layer Matters

This is where it gets interesting.

The session focused on the Access Layer, specifically how AWS Lake Formation handles role-based access control (RBAC). When you're working with sensitive information like social security numbers, credit card details, or health records, you can't just let everyone have access to everything. You need detailed control over who can see what.

The Challenge with Traditional Approaches

Imagine you're creating an e-commerce platform. You might have:

A marketing team that needs access to customer demographics
A finance team that needs transaction records
A data science team working on recommendation models
An analytics team producing reports

Each team requires different levels of access to various datasets. Some can see all the data, others should only see data that's been anonymized, and some should not have access to PII at all.

Trying to manage this by manual? It would be a complete mess.

How Lake Formation Solves This: Role-Based Access

AWS Lake Formation offers a single place to set up permissions that work across your whole data lake. The slide from the session showed how this system works clearly.

The Permission Flow

Administrator sets up permissions - A data lake administrator can set permissions for databases, tables, columns, rows, or even individual cells. They also register these areas in Lake Formation.
*User queries data *- When a user, like someone using Amazon Athena or another analysis tool, wants to access data, they send a query with temporary login details.
Lake Formation checks metadata - The AWS Glue Data Catalog, which keeps track of your tables and their structure, is checked.
Permissions are verified - Lake Formation then checks if the user's role has the right to access the data they're asking for.
Credentials are vended - If they do, Lake Formation gives them temporary access to the data stored in the S3 bucket.
Data is retrieved - Only after that does the user get access to the data.

Two Layers of Protection

Lake Formation provides two layers of permissions enforcement:

Metadata layer - Controlled through the AWS Glue Data Catalog
Storage layer - Controlled through credential vending to access S3

This two-layer method makes sure that even if someone gets past one layer, they still can't get to the real data without the right permission.

Database-Level vs Table-Level Permissions

One of the slides talked about the difference between permission scopes:

Database-Level Permissions

These are wide-ranging permissions that cover the whole database. You might give someone:

Select - Read data from all tables
Insert - Add new records
Delete - Remove records
Alter - Modify table structures
Super - Full administrative rights, including the ability to grant permissions to others

Table-Level Column-Based Access

Lake Formation really stands out here.

You can set up access to specific columns within certain tables. For example:

Your marketing team can see customer_name and email, but not credit_card_number
Your compliance team can see everything
Your external contractors can only see anonymized, aggregated data

This detailed control is very important when handling personal information. Instead of making many copies of the same data with different columns hidden (which is both tricky and costly), you create access rules once, and Lake Formation makes sure they are followed automatically.

You might be thinking, "Can’t I just use S3 bucket policies for this?"

To be honest, you could., but it would be very hard to manage. Every time you add a new user, role, or dataset, you’d have to change policies in several places by hand. Lake Formation brings everything together in one place.

Real-World Scenarios Where This Helps

Let me give you some practical examples:

Scenario 1: Healthcare Data

A hospital keeps patient information in a data lake. Doctors need full access to medical history, but billing staff should only see insurance and payment details. Researchers looking at health trends can only use anonymized data and must not see any personal identifying information at all.

With Lake Formation, you set these rules just once. The system makes sure everyone follows them automatically, no matter how they access the data, whether through Athena, Redshift Spectrum, or other connected tools.

Scenario 2: E-Commerce Platform

An online store wants to study buying habits. Marketing teams can look at customer demographics and types of purchases, but they shouldn’t see exact prices (that’s for the finance team). Data scientists building machine learning models need patterns in transactions but not customer names.

Lake Formation allows you to set up policies based on different roles, which match exactly with your business needs.

Scenario 3: Regulatory Compliance

If you're based in the EU, GDPR requires tight control over personal data.
Lake Formation has tools that track who looked at what data and when, making it easier to check compliance during audits.

Conclusion

Managing personal information doesn't need to be hard. AWS Lake Formation's access layer lets you control who can see what, keeps everything organized, and gives you confidence, all while keeping the benefits of a data lake.

If you're handling sensitive data or are frustrated with managing permissions by hand, Lake Formation could be a good option to check out. Also, if you ever get the opportunity to go to AWS Community Day, don't miss it. Talks like Ankit's help break down complicated ideas into something easier to understand and put into practice.

About the Author

🔗 Connect with me on LinkedIn

References

Event: AWS Community Day Bangalore 2025

Topic: Securing PII in Data Lakes: AWS Lake Formation Access Controlw

Date: May 23, 2025

Location: Conrad Benguluru

Also Published On

AWS Builder Center

Hashnode

AWS Community Builders Program: What You Need to Know

N Chandra Prakash Reddy — Tue, 23 Dec 2025 08:51:58 +0000

Hundreds of cloud enthusiasts attended AWS Community Day Bengaluru 2025 on May 23, 2025. Of the many fantastic presentations, Jason Dunn's discussion about the AWS Community Builders Program caught my attention. I was excited to hear directly from Jason, the Program Manager, about the most recent developments and his guidance for prospective builders, as I am now an AWS Community Builder.

This blog is for you if you've ever wondered about the AWS Community Builders program, if you should apply, and how to get accepted. Allow me to summarize everything Jason discussed, along with additional observations based on my personal program experience.

What is the AWS Community Builders Program?

Technical content producers that write, present, create, or contribute content regarding AWS services and related subjects are the target audience for the AWS Community Builders program. Consider it AWS's means of encouraging and enabling those who are already teaching others about cloud computing or who wish to begin doing so.

The thing is, AWS knows that the best way to learn is often from other people, not just from official guides. When someone talks about how they actually used Lambda to solve a problem or how they made their RDS database faster, it helps other developers in a way that regular classes or books might not.

The program is for people who love technology and want to share what they learn with others. You don't have to be an expert with lots of certifications, you just need to be curious and willing to learn and share your discoveries as you go.

The Numbers Tell a Story

Jason shared some interesting stats during his talk. The slides showed that technical content creators have grown by 12 to 15%, which is even more impressive when you consider there was a 25% rise compared to last year. And here's something cool, India has 464 Community Builders. That's a big number and shows how active and strong the AWS community is in the country. Being part of this group is amazing because everyone really cares about creating and sharing knowledge.

Why Should You Join? The Benefits Are Impressive

Let's be honest, the benefits package is really good, and since I've experienced them myself, I can say they're worth it. Here's what you get when you're accepted:

Financial and Learning Support

I got $500 in AWS credits to experiment with different services and learn. I've used them to try out services I wouldn't normally test on my personal account. This has let me experiment freely without worrying about the cost.
You get one free AWS Certification voucher for exams like Foundational, Associate, Professional, or Specialty. These vouchers usually cost between $100 and $300, so having one for free is really helpful.
A one-year subscription to QA (Cloud Academy) helps with learning about the cloud. Having organized learning paths can help you grow much faster.
Exclusive swag kit because who doesn't love AWS swag?

Event Access

A $1,200 discount on a re:Invent ticket. If you've ever checked the pricing for re:Invent, you know how big this savings is. re:Invent is AWS's main conference held in Las Vegas.
$500 re:Inforce ticket discount. re:Inforce is AWS's security-focused conference.

Community and Visibility

Be included in the public list of Community Builders. This helps you gain visibility and trust within the AWS community.

Does this sound familiar? These benefits are meant to take away obstacles, like the cost of certifications, conference attendance, or trying out new AWS services.

How the Program Helps You Grow

Beyond the actual advantages, the program also provides great chances for personal and professional growth. From my experience, these are the parts that have made the biggest difference for me.

Chat with other creators from all over the world on Slack. That's where cool things happen, I've received fast help with tough problems, found people to work on projects with, and made real friends with others who love the same things.
Developing skills through ongoing community meetings that include both technical knowledge and personal skills such as giving presentations and making content.
You can get chances to speak at events like AWS Summits, Cloud Days, and re:Invent. Picture yourself giving a talk at one of these big conferences!
Online speaking chances through Open Mic events and certain Community Builder meetings.
NDA service briefings and beta testing opportunities give you direct access to AWS product plans. You can see new features before they are officially announced, which has helped me create content that's both timely and relevant.
You also get to participate in research and user experience feedback sessions, such as the re:Invent catalog feedback sessions. AWS really values your opinions and wants to hear what you think.
There are private events at AWS conferences like the re:Invent mixer and community dinners at some AWS Summits.

To be fair, these opportunities aren't just good for you, they also benefit the whole community. When you learn something new through a beta program or service briefing, you can make content that helps others understand these services once they're launched.

The Types of Content That Matter

One slide really caught my attention during Jason's talk, it was the one about content types. The program takes in different kinds of content that help people learn about AWS.

Articles/blogs
Videos
Presentations
Podcasts
Newsletters
Open source projects

The main thing is that your content needs to include your name so AWS can know it's you. That makes sense because they want to recognize real people contributing, not just anonymous posts.

What Content Actually Works

Jason was very straightforward about what kind of content is helpful for your application:

"We're thrilled you passed your certification exam, but that kind of content doesn't often help other builders learn AWS."

In simple terms, just saying "I passed my SAA-C03 exam!" isn't enough. You should create content that actually teaches others something useful. For example:

If you gave a talk at an event, write a blog post about it
If you created a video tutorial, make a blog post summarizing the key points
If you're working on an open source project, document how others can use it

Your content should usually match the category you're trying to join. If you're applying as a containers or devtools, your content should show that you have expertise or are learning about that area.

Application Tips: How to Stand Out

Jason's part of the presentation was really helpful. I've been through the application process myself, and I wish I had known this advice earlier. Jason explained that they look at a lot of applications, so making it easier for the reviewers to understand your application can greatly improve your chances.

The Golden Rules

Take your time and read each question carefully. This isn’t a race. Think about your answers and respond thoughtfully. Don't rush through it during your lunch break.
You'll need a Builder ID, and it's free. Make sure you create one before you start your application.
Use the name you're known by for your content, not the one on your official documents. If you publish as "CloudGuru Alex" but your real name is "Alexander Smith," go with the one your audience recognizes. Make sure your Builder ID, app name, and content name all match the same name.
Don't use AI to write anything in the form. This is very important. Jason said, "We want the real you to come through in the app." AWS can tell if responses are made by AI, and that could hurt your chances. They want to see your unique way of thinking and your personal style.
Answer all the legal questions at the end. If you don't want to get an email, they won't be able to send you one even if you're accepted or not! Pay close attention to this.

Content Submission Strategy

Personal content only, not company stuff. They want to see what you've done yourself, not your company's marketing posts.
Make it easy for the people reading your work. They only have a few minutes to check things out. If it's hard to find or open, your chances of getting accepted go down.
Give direct links to your content. Don’t share your main blog address or a long list of articles. Choose 2 of your best pieces.
Your content needs to be available online for anyone to see right away. No links from Dropbox or Google Drive that require permission. If the person reviewing can’t open it immediately, it won’t work.
Good places to post include DEV.to or aws builder center, but any public platform is okay.
I share my work on 3 platforms, and as long as the content is open and reachable, it’s fine.
If your work is copied from somewhere else, it will be rejected right away. They want content you wrote yourself, original ideas, tutorials, or unique viewpoints.
Try to make something that shows real-world use, even if it’s just for your own learning.
For example, Jason talked about organizing a rock collection. It doesn’t have to be life-changing, it just needs to show you’re building and learning.

Conclusion

Hearing Jason speak directly at the AWS Community Day in Bengaluru made me even more excited about being part of this program. It's not just about the perks, it's about being part of a group of over 464 builders in India who really care about learning and sharing what they know.

If you're considering applying, here's my tip: start making content right away, not just when the application opens. Choose your top 2 to 4 pieces, be genuine (no AI-generated stuff!), and share content that actually helps others learn. AWS gets lots of applications, but they're looking for real, passionate voices, not perfect ones.

The real benefit is the connections you make and the skills you gain. Applications usually open in January, keep an eye on the official website and good luck!

Ready to join the waiting list? Click Here

About the Author

🔗 Connect with me on LinkedIn

References

Event: AWS Community Day Bangalore 2025

Topic: AWS Community Builders Program: What You Need to Know

Date: May 23, 2025

Location: Conrad Benguluru

Also Published On

AWS Builder Center

Hashnode

Scaling Databases with TiDB: AWS Community Day Bangalore 2025

N Chandra Prakash Reddy — Thu, 18 Dec 2025 12:45:42 +0000

One session at AWS Community Day Bangalore 2025 in May fundamentally altered my perspective on database scalability. Senior Solution Architect Ankit Kapoor of TiDB gave a very enlightening session titled "From Startup to Scale-up: Your Database's Growth Journey."

This is for you if you've ever had trouble with database scaling.

The Problem We All Face

To be honest, conventional relational databases function flawlessly until they break down. Ankit outlined the difficulties faced by the majority of expanding businesses:

Manual Configuration Nightmares

Shard mapping needs to be configured manually.
Cross-shard searches add needless complexity to application code.
Under heavy load, concurrency constraints result in row-level locking.
Several housekeeping tasks take up important time.

Vertical Scaling Hits a Wall

A bottleneck is created by mutex contention.
Growth is restricted by shared resource bottlenecks.
Commodity hardware is plagued with OOM problems and low CPU utilization.

Performance Issues That Hurt

Writes continue to be bottlenecked, but read operations scale
It is only possible to achieve eventual consistency.
Analytical queries don't work well with row-based storage.
Semantic search moves slowly.

Does that sound familiar? The majority of us have been there, which is why.

What is Distributed SQL?

This is the fascinating part. Distributed SQL is an advanced database architecture that blends the greatest features of both worlds; it's not just another catchphrase. It offers both the horizontal scale of NoSQL databases and the transactional guarantees of relational databases, as Ankit clarified.

Take a moment to consider that. Scalability is maintained while achieving ACID compliance.

Enter TiDB: The Open Source Solution

I was drawn to TiDB because of its outstanding credentials:

Founded in 2015 and 100% open source
38,000+ GitHub Stars showing strong developer interest
800+ Contributors building and improving it
10,000+ Adopters worldwide
8,000+ Slack Users in an active community

Big names like Pinterest, CAPCOM, Conga, Bolt, and Ninja trust TiDB with their production workloads. Over 4,000+ enterprise adopters across 25 countries use it daily.

How TiDB Works: Architecture Made Simple

Ankit divided the architecture of TiDB into four primary parts:

Compute Layer

Handles SQL processing and query optimization
MySQL compatible (huge win for migration!)

Row Store

Distributed key - value storage
Perfect for OLTP workloads with strong consistency

Columnar Store

Enables real-time analytics on transactional data
Uses a columnar storage engine for analytical queries

Placement Driver (PD)

Manages metadata
Balances data distribution across nodes automatically

The beauty? Storage and computation are entirely distinct. This implies that you can scale them on your own according to your requirements.

TiDB vs Traditional Databases: The Real Difference

Conventional databases employ a single-master configuration in which read replicas use transaction log replication to handle read traffic while one instance manages writes. It's limiting, but it works.

This model is flipped by TiDB. While ensuring ACID transactions with excellent read consistency, several TiDB instances manage both reads and writes concurrently. The computation layer is stateless and scalable on its own, while the storage layer (TiKV) is horizontally scalable and supports many replicas.

What This Means for DBAs

Ankit emphasized how TiDB reduces operational headaches:

Horizontal Scaling: Automatic sharding and seamless scaling without the need for human intervention
99.99% Availability: Your data is kept accessible by auto-failover and self-healing.
Mixed Workloads: AI, analytical, and transactional workloads are all handled by a single database.
Strong Consistency: Strong data integrity and worldwide compliance in ACID transactions
Security: Enterprise-grade encryption both in-flight and at-rest
MySQL Compatibility: Easy migration path for existing MySQL users
Multi-Cloud: Deploy across your preferred cloud platforms
100% Open Source: Transparent, community-driven development

The Operational Simplicity Win

I was very impressed by TiDB's integrated Grafana and Prometheus dashboards. Instant monitoring, performance measurements, and system health data straight out of the box, no further setup or configuration nightmare.

For teams without dedicated DevOps resources, this is a game-changer.

Three Deployment Options on AWS

TiDB offers flexibility based on your needs:

TiDB Cloud Serverless

Fully managed with effortless scalability
Pay-as-you-go pricing
99.99% availability (currently 99.9%)
Perfect for variable workloads, web applications, and microservices

TiDB Cloud Dedicated

Fully managed with high performance
99.99% availability
Subscription pricing starting at $2/hour with volume discounts
Ideal for mission-critical applications with heavy read/write operations

TiDB Self-Managed

Self-managed for maximum control
Custom pricing
Premium support available
Best for large enterprises with complex infrastructure needs

Conclusion

My understanding of database architecture has changed as a result of this session. For many years, traditional databases worked well for us, but contemporary applications require more. TiDB solves actual scalability issues without requiring you to give up on SQL or ACID guarantees.

It is a strong competitor due to its open-source nature and production-proven dependability at large corporations. TiDB should be included in your evaluation list if your present database is experiencing scaling issues or if you are designing a new system that must accommodate expansion.

AWS Community Day Bangalore still offers insightful, useful content from actual professionals addressing actual issues. Sessions like Ankit's serve as a reminder of the importance of community gatherings since they provide us with solutions that we might not otherwise come across.

References

Event: AWS Community Day Bangalore 2025

Topic: Scaling Databases with TiDB

Date: May 23, 2025

Location: Conrad Benguluru

Also Published On

AWS Builder Center

Hashnode

Building an Expense Tracker with AWS Kiro

N Chandra Prakash Reddy — Thu, 18 Dec 2025 07:42:17 +0000

Few people truly track their expenditures on a daily basis, despite the fact that most people know they should. It is tedious, time-consuming, and a lot of the apps are either too complicated or not designed beginner users. My Daily Expense Tracker aims to address this issue by providing customers with an easy-to-use, quick, and aesthetically pleasing web application that helps them manage their spending.

I'll describe the issue, the fix, and how AWS Kiro made it far quicker for me to move from an idea to a finished, live web application than if I had to start from scratch.

Live Demo : https://ncpr1996.github.io/daily-expense-tracker/

GitHub: https://github.com/ncpr1996/daily-expense-tracker

Problem: Budgeting That Actually Fits Users

Most generic expense apps miss a few important points:

They don't think in lakhs and thousands, which is how many Indians view money on a daily basis.
To add a single tiny tea or auto ride, they require you to tap through an excessive number of screens.
They rarely show a clear picture of “How much can I safely spend today?” or “How many days until salary?”.

I have a different idea for the AI for Bharat Hackathon:

Web-based and browser-based (no mobile installation needed).
Designed with the ₹ symbol, lakh formatting, and salary-based budgeting in mind for Indian customers.
Easy to use on a daily basis, yet capable of providing charts, patterns, and insightful insights.

Solution Overview: A Premium Daily Expense Tracker

The finished product is a desktop-first web application that functions well on mobile devices as well. It features a main area for dashboards, tables, and charts, as well as a fixed sidebar for easy expense entry.

Key features

Fast expense entry: Amount, category, date, and optional notes in a few seconds.
Eight categories: Food, Transport, Bills, Shopping, Entertainment, Health, Education, and Other, each with its own emoji so the UI feels friendly.
Budget tracking: Monthly budget, real‑time “spent vs remaining”, color‑coded state, and days until salary with a safe daily spend recommendation.
Visual insights: Category breakdown chart, month filter, and recent expenses preview to understand where money is going.
Savings and reminders: Daily savings calculator and a simple bill‑reminder system so you don’t miss due dates.
Smart UX: Dark mode, glass‑morphism cards, animations, and fully responsive layout.

There is no backend because all data is kept locally in the browser using LocalStorage, giving users complete control over their data.

Architecture: Simple Files, Clear Flow

Because the project is purposefully lightweight, it may be installed on any static server, GitHub Pages, or Netlify.

Project structure

index.html – Main HTML and layout.
styles.css – All styling, themes, and responsive rules.
app.js – Core application logic.
manifest.json – PWA configuration so it can also work like an installable app.
.kiro/ – Documentation generated and refined with Kiro: requirements, architecture, user guide, prompts, and more.

Expenses, budgets, reminders, profile, theme, and chosen chart month are all included in a single state object within app.js. Every user activity follows to the same pattern:

User Action → Event Listener → Update State → Save to LocalStorage → Update UI.

This keeps logic predictable and easy to reason about.

Main modules

Expense management: Functions to add, delete, filter, and render expenses in a table.
Budget tracking: Functions to compute total spent, remaining budget, and update the overview cards.
Visualization: Functions to render the category breakdown chart and month filters; currently done with CSS‑based charts, with Chart.js ready for future upgrades.
Profile and greetings: Functions to store name, occupation, and city, and use them for time‑based greetings like “Good Evening”.
Utilities: Currency formatting for ₹, date formatting, category emojis, and dark‑mode toggling.

This modular strategy follows to single-responsibility standards and enables future maintenance or expansion.

Designing the Experience: From Requirements to UI

Kiro assisted me in gathering specific requirements in an organized manner before to writing any code. The requirements.md file, which outlines the functions of the application, the data structures it requires, and the format of the user stories, reads nearly exactly like a product specification.

Requirements turned into UI

From those requirements, the UI naturally emerged:

A Budget Overview card to show current month budget, spent, and remaining at a glance.
A quick add form in the sidebar with category buttons laid out in a neat 4×2 grid so nothing overflows, even on smaller screens.
Tabs for Dashboard, Expenses, Saving Plan, and Reminders, each focusing on one part of the requirements.
Date validation to block future expenses and keep financial data realistic.

In this case, Kiro was very helpful since it generated clear HTML structure and logical CSS tokens like theme colors, spacing, and glass-morphism card styles when given natural-language criteria.

How Kiro Helped: From First Prompt to Final Polish

Prompts.md is the most fascinating file in the .kiro folder. It is essentially the history of conversations with Kiro, including all of the key directives that influenced the development of the app. I iterated by altering my prompts rather than manually rewriting the entire application multiple times.

Vibe mode: first full version

The primary idea was outlined in the first prompt: a Daily Expense Tracker for Indian consumers with intelligent entry, analytics, budgets, and a high-end user interface. In response, Kiro created the basic manifest file, styles.css, app.js, and index.html all at once.

At this stage the app:

Looked more like a mobile view centered on desktop.
Had most of the logic, but charts and filters still needed work.

Desktop‑first redesign

The next set of prompts asked Kiro to:

Use the full browser width.
Move expense entry into a fixed left sidebar.
Turn the main area into a dashboard with cards and tables.

Kiro rewrote the layout with a desktop‑first grid, fixed sidebar, and SaaS‑style header, which immediately made the app feel more professional and friendly.

Bug fixing by conversation

During my testing, I discovered problems such as overflowing category buttons, unreadable dark-mode text, malfunctioning date filters, and non-rendering charts. Every issue was transformed into a brief, targeted prompt:

“Fix category buttons that go out of bounds in the Add Expense section.”
“Make dark‑mode text high‑contrast.”
“Make ‘This Week’, ‘This Month’, and ‘All Time’ actually filter expenses and update totals.”

Then, while maintaining the current structure, Kiro modified CSS and JavaScript to address these issues. Additionally, it frequently updated validation algorithms, such as preventing future spending dates and accurately recalculating the header summary.

Documentation and guides for free

Finally, Kiro generated the markdown files you see in the .kiro directory:

requirements.md – formal list of features, data model, and user stories.
architecture.md – description of modules, data flow, CSS architecture, and performance considerations.
user-guide.md – step‑by‑step instructions on how to use the app and understand the dashboard.
CONTRIBUTING.md – guidelines for future contributors. prompts.md – record of how prompts evolved across iterations.

Writing this documentation by hand would typically take hours. Here, clear technical documents were created alongside the code using prompts and a few modifications.

*Every significant instruction I provided Kiro during the app's development was kept in a file named prompts.md, allowing you to view the precise prompts that influenced each iteration. You can follow the complete prompt history step-by-step by opening this file directly in the GitHub repository that is linked in this blog.
*

A Quick Look at the Core Logic

Even novices are able to understand the application because it is coded in vanilla JavaScript. Based on the architecture description, the following is a brief summary of the core state object and the fundamental data flow:

A single state object holds expenses, budget, reminders, profile, and dark‑mode state.
loadState() pulls this data from LocalStorage when the page loads.
saveState() writes it back whenever something changes.
updateUI() refreshes the budget cards, tables, and charts so the screen is always in sync.

This structure makes it easy to add more features later, such as recurring expenses, exports, or even backend sync, without changing the overall pattern.

Why This Approach Worked Well

Looking back, three things made this project smooth:

Clear requirements first – Writing a requirements file with Kiro forced clarity about what the app should do before styling anything.
Iterative prompts instead of big rewrites – Each improvement (layout, charts, filters, validation) came from focused prompts rather than manually refactoring everything. The prompts.md file shows this evolution very clearly.
Built‑in documentation – Having README, architecture, user guide, and contributing instructions generated alongside the code means anyone landing on the GitHub repo can understand the project quickly.

Time-wise, it seemed like this combination of Kiro and manual testing reduced two or three days of hand-coding into a few concentrated sessions.

Key Takeaways

It is considerably simpler to direct an AI tool like Kiro and prevent random outputs with a precise requirements document.
For serious web applications like expenditure trackers, a desktop-first design with a fixed sidebar and a simple dashboard works well.
Keeping a single state object and simple data flow (action → state → LocalStorage → UI) makes the code easy to extend later.
Kiro is most powerful when used iteratively: start with a big “vibe” prompt, then send small, targeted prompts to fix layout, bugs, and UX problems.
Auto‑generated docs (requirements.md, architecture.md, user-guide.md, prompts.md) save a lot of time and make the project easier for others to understand.

Conclusion

It would typically take many days of design, coding, and documentation to create a fully functional Daily Expense Tracker from start, particularly with a sophisticated user interface and extensive feature set. In just a few concentrated sessions, a production-ready, India-focused budgeting solution with charts, insights, and documentation may be shipped by combining precise requirements with AWS Kiro and iterating through prompts.

This workflow demonstrates to developers and students how AI can serve as a useful coding partner: you maintain control over the product vision and testing, while Kiro speeds up repetitive tasks.