My Learning Journey with AWS
When I first saw AWS, I honestly felt overwhelmed.
There were so many services- S3, RDS, DynamoDB, SNS, Bedrock—and they all sounded important, but I couldn't understand why AWS needed so many different services. At one point, I even thought, "Can't one database or one storage service do everything?"
While exploring these services for an AWS challenge, I stopped trying to memorize definitions and instead asked myself one simple question:
"What real-world problem is this service trying to solve?"
That completely changed how I understood AWS.
Here are the five services that helped me look at cloud computing differently.
Amazon Bedrock:- AI Without Building an AI Model Yourself
When I first heard about Amazon Bedrock, I thought it was used to create and train AI models from scratch.
After learning more, I realized I had misunderstood it.
Bedrock is more about using existing foundation models and customizing them with your own data to build AI applications. AWS takes care of the complex infrastructure, while developers focus on solving actual problems.
The first idea that came to my mind was a Hackathon Discovery Platform.
Students usually spend hours searching different websites to find suitable hackathons. Instead, imagine asking an AI assistant:
"Find beginner-friendly AI hackathons."
"Which hackathons allow solo participation?"
"Show hackathons with prize money above ₹50,000."_
The assistant could understand information like eligibility, deadlines, FAQs, technologies used, and previous editions because it is connected to a knowledge base.
That was the moment I understood what Bedrock is actually meant for- not creating AI models, but creating useful AI applications.
Amazon S3:- Not Just Storage, but Storage That Never Becomes a Problem
Before learning about Amazon S3, cloud storage sounded similar to Google Drive.
Then I realized companies deal with millions and sometimes billions of files.
Photos.
Videos.
Documents.
Backups.
Datasets.
Managing all of that isn't as simple as saving files on a computer.
The first example I thought of was social media platforms like Instagram, YouTube, and Snapchat. Every second, users upload content, and all those media files need to be stored somewhere reliable.
Another idea I had was a college event archive where photographs, certificates, recordings, and event documents could be safely stored and accessed even years later.
S3 made me realize that storage isn't only about saving files. It's about making sure those files remain secure, durable, and available whenever they're needed.
Amazon RDS:– Let AWS Handle the Database Work
I had worked with databases before, but I never really thought about what happens behind the scenes.
I assumed databases just "store data."
Later I learned someone has to maintain them too.
Someone has to manage backups.
Someone has to install updates.
Someone has to recover data if something goes wrong.
That's where Amazon RDS made sense to me.
The example that immediately clicked was a University Examination Management System.
Student records, attendance, marks, course details, and examination results all have relationships with each other, making a relational database the right choice.
I also liked the fact that RDS can automatically create backups and even maintain a standby database in another Availability Zone. It made me realize why organizations trust managed databases instead of maintaining everything themselves.
Since educational data is sensitive, features like encryption and access controls also help reduce the risk of unauthorized access.
DynamoDB:- When Millions of People Use Your App Together
Understanding DynamoDB also helped me understand that not every database is built for the same purpose.
Initially, I wondered why AWS had both RDS and DynamoDB.
Then I thought about LinkedIn.
People continuously like posts.
Comment.
React.
Send connection requests.
View profiles.
All these activities happen at an enormous scale.
A traditional relational database isn't always the best fit for this kind of workload.
That's where DynamoDB comes in.
It automatically scales while still responding incredibly fast, even if millions of users are active at the same time.
One feature I found particularly interesting was Global Tables, where data stays synchronized across multiple AWS Regions, making applications more reliable for users around the world.
Amazon SNS:- One Update, Many Notifications
SNS became one of the easiest services for me to visualize because we all receive notifications every day.
What I liked most was the Publish-Subscribe idea.
Instead of sending the same update separately to different places, an application publishes one message and SNS distributes it wherever it's needed.
The example I came up with was a Hackathon Management Platform.
Whenever students register, form teams, receive mentor session details, meeting schedules, deadlines, or final results, SNS could send notifications through email, SMS, mobile notifications, and the platform itself at the same time.
The same idea could also be used inside organizations to send important meeting announcements across different communication channels.
Another interesting thing I learned was that SNS supports both:
Application-to-Person (A2P) communication, like emails and SMS.
Application-to-Application (A2A) communication, where different software systems notify each other automatically.
That made me realize SNS is much more than a notification service.
What Changed for Me?
Before this challenge, I used to think AWS was just a collection of complicated cloud services.
Now I see each service as a solution to a specific problem.
If I need to store huge amounts of files, I think about Amazon S3.
If I need structured data with relationships, Amazon RDS makes sense.
If I need a database for millions of fast user interactions, DynamoDB is a better choice.
If I need to notify people or systems whenever something happens, I think of Amazon SNS.
If I want to build an AI-powered application without worrying about training large models, Amazon Bedrock is the service I would explore.
The biggest lesson I learned wasn't remembering AWS service names.
It was understanding why each service exists.
Once I started thinking in terms of "What problem am I trying to solve?", AWS became much less intimidating and much more practical.
This is only the beginning of my cloud journey, but now when I hear the name of an AWS service, I don't just remember its definition, I remember the real-world problem it can solve.
I know I've only scratched the surface of AWS, but this challenge changed the way I learn technology. Instead of memorizing concepts, I now try to connect every new service with a real-world problem. That approach made learning much more meaningful for me.
