I Wanted to Build in AWS. Instead, AWS Changed How I Think. ⚡☁️
As a student learning AWS, I started by focusing on services, architectures, and tutorials. But while building projects, I realized that AWS was teaching me something bigger—how to think about problems, make better technical decisions, keep solutions simple, and build with purpose. This is the mindset shift that changed the way I approach cloud projects.
The Beginning: I Thought AWS Was About Services
When I first started learning AWS, I thought the main goal was simple: learn as many services as possible.
EC2. S3. Lambda. IAM. DynamoDB. CloudWatch.
I started seeing AWS as a huge list of services that I needed to remember. Whenever I came across a new project, my first question was often:
“Which AWS service should I use?”
But after working on different projects and exploring AWS more deeply, I started realizing that I was asking the wrong question.
The better question was:
“What problem am I actually trying to solve?”
That small change completely changed the way I look at cloud computing.
A Service Is Not the Solution
One thing I slowly understood is that knowing what a service does is different from knowing when to use it.
For example, knowing that S3 provides object storage is useful. But understanding why a project needs object storage is much more important.
The same applies to other services.
Instead of thinking:
“I need to use Lambda because it is an AWS project.”
I started thinking:
“Do I actually need serverless functions for this problem?”
That shift helped me stop adding services just because they were available.
My First Lesson: Simple Is Not Basic
As beginners, we sometimes think a project with more services must be more impressive.
More services.
More architecture boxes.
More integrations.
More features.
More architecture boxes.
More integrations.
More features.
But complexity can create new problems.
Every additional service can mean more configuration, more permissions, more things to monitor, more possible failures, and potentially more cost.
I started appreciating something that sounds simple but is actually difficult:
Build the simplest solution that solves the problem well.
A small architecture that I understand is much more valuable to me than a huge architecture that I cannot explain.
Then I Started Asking “Why?”
This became one of the most useful habits in my AWS learning journey.
Whenever I saw an architecture, instead of only asking:
“What is this service?”
I started asking:
- Why is this service being used?
- What problem does it solve?
- What happens if I remove it?
- What permissions does it need?
- How much could it cost?
- What could go wrong?
- How would I troubleshoot it?
These questions made learning much more interesting.
I was no longer just memorizing AWS terminology.
I was trying to understand the decisions behind the architecture.
Building a Project Changed Everything
Tutorials are useful.
Courses are useful.
Documentation is useful.
But building something yourself creates a different kind of learning.
When a project works, you learn how the pieces connect.
When something breaks, you learn how to troubleshoot.
When you see an unexpected cost, you learn about resource usage.
When a permission fails, you start understanding IAM.
When a deployment doesn’t behave as expected, you learn that architecture diagrams are only the beginning.
That is when AWS started feeling less like a collection of services and more like a system of building blocks.
I Also Learned That “It Works” Isn’t Enough
One of the biggest lessons for me was this:
A project working does not automatically mean it is a good project.
A working application can still have:
- unnecessary resources
- overly broad permissions
- unexpected costs
- weak security settings
- difficult-to-maintain architecture
- poor monitoring
- no proper cleanup
So now, when I think about an AWS project, I try to look beyond functionality.
I ask:
Does it work?
Then:
Is it secure?
Is it affordable?
Can I understand it?
Can I troubleshoot it?
Can I maintain it?
That mindset feels much more useful than simply trying to make something run.
AI Made This Lesson Even More Important
Today, AI can generate code, suggest architectures, explain AWS services, and even help create infrastructure.
That is incredibly useful for students like me.
But it also creates a new responsibility.
If AI gives me an architecture containing several AWS services, I shouldn’t simply copy it because it looks professional.
I should understand:
Why are these services here?
What does each one do?
What permissions are required?
What could this cost?
What happens if one part fails?
AI can help me build faster.
But understanding what I build is still my responsibility.
My New AWS Learning Approach
I now try to follow a simple flow:
Problem → Requirements → Simple Solution → AWS Services → Architecture → Security → Cost → Testing → Monitoring → Cleanup
This feels much more natural than starting with a list of AWS services.
For example, instead of saying:
“I want to use Lambda, S3, DynamoDB and API Gateway.”
I start with:
“I have this problem. What is the simplest reliable way to solve it?”
Then I choose the services.
That small change makes a huge difference.
The Biggest Change Wasn’t Technical
When I look back, I thought learning AWS would mainly teach me cloud technology.
It did.
But it also taught me how to think.
I learned to break a large problem into smaller parts.
I learned to question technical decisions.
I learned that security and cost should not be afterthoughts.
I learned that mistakes can be useful if I understand why they happened.
And most importantly, I learned that building something isn’t just about making it work.
It is about understanding why it works the way it does.
What AWS Means to Me Now
I no longer see AWS as a giant list of services that I need to memorize.
I see it as a collection of building blocks.
The real skill is knowing which blocks to use, why to use them, and how to connect them responsibly.
I am still a beginner, and I definitely have a lot more to learn.
But I think that is the exciting part.
I don’t want to become someone who simply knows hundreds of AWS service names.
I want to become someone who can look at a problem and think:
“I understand the problem. Now, how can I build the right solution?”
And maybe that is what becoming a cloud builder actually means.
Don’t just learn AWS services. Learn how to think with them. ☁️⚡
# aws-builders# aws-parallel-computing-service# architecture# beginner-projects# learning-and-development
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article