When I first looked at AWS, it felt unnecessarily complicated.
EC2 runs something.
S3 stores something.
RDS manages something.
Lambda does something “serverless.”
I understood the definitions individually.
But I still didn't understand AWS.
The breakthrough comes when you stop learning these services separately and ask one simple question:
How would I use EC2, S3, RDS and Lambda together to build one real application?
That's when AWS starts making sense.
So instead of another article explaining AWS services like dictionary definitions, let's build something.
Imagine we're creating a simple job portal where users can create accounts, upload resumes and apply for jobs.
Nothing extraordinary.
But this small application is enough to understand some of the most important ideas in cloud architecture.
First, Forget AWS for a Minute
Before choosing any AWS service, think about what our application actually needs.
Someone visits our website.
They create an account.
They upload their resume.
They browse available jobs.
They submit an application.
When a resume is uploaded, perhaps we want to automatically process it and extract some basic information.
Already, we can identify four different technical problems.
We need somewhere to run our application.
We need somewhere to store uploaded files.
We need somewhere to store structured information such as users and applications.
And we need something that can automatically react when certain events happen.
Now AWS becomes easier.
Because instead of memorizing services, we're matching problems to solutions.
Our architecture starts with four pieces:
EC2 → Application
S3 → Files
RDS → Structured Data
Lambda → Event-Driven Processing
Let's see what that actually means.
- EC2: Where Our Application Lives
Our job portal needs backend code.
Maybe we're building it using Python, Node.js, Java or another backend technology.
That code needs somewhere to run.
This is where Amazon EC2 enters the picture.
Think of EC2 as renting a computer inside AWS.
Instead of purchasing a physical server and placing it inside an office, we create a virtual server in the cloud.
We choose the computing capacity.
Install what our application needs.
Deploy our backend.
And keep the application running.
Now when a user visits our application and requests something, our backend can process that request.
For example:
User → “Show me available jobs.”
The request reaches our application running on EC2.
But EC2 doesn't necessarily contain all the information itself.
It needs to get the job records from somewhere.
And that's where our database enters the architecture.
- RDS: Where Our Application Remembers Things
Our job portal needs to remember information.
Users.
Email addresses.
Job listings.
Companies.
Applications.
Application status.
Dates.
Relationships between different records.
This is structured information.
A relational database is a natural fit.
Instead of manually installing and maintaining a database directly on our application server, we can use Amazon RDS.
RDS is AWS's managed relational database service.
Our architecture now looks something like this:
User → EC2 → RDS
The user requests available jobs.
EC2 receives the request.
Our application queries the database.
RDS returns the relevant records.
EC2 sends the result back to the user.
Suddenly, two AWS services that seemed unrelated make sense together.
EC2 runs the application.
RDS stores the application's structured data.
But now our user wants to upload a resume.
Should we put every PDF directly inside our relational database?
Usually, there's a better option.
- S3: Where the Resume Goes
A resume is different from a user's name or application status.
It's a file.
Maybe PDF.
Maybe DOCX.
Maybe an image.
Applications frequently need somewhere to store objects such as documents, images, videos, backups and datasets.
This is exactly the kind of problem Amazon S3 is designed to solve.
Now imagine the user uploads:
sar_resume.pdf
The file can be stored in S3.
But we still need our database to know which resume belongs to which user.
So instead of treating S3 and RDS as competing storage systems, we use them for different jobs.
Conceptually:
S3
stores:
resume_83921.pdf
while RDS might contain information conceptually like:
user_id: 83921
resume_location: resume_83921.pdf
Now we have a useful separation.
RDS manages structured application data.
S3 manages the actual file.
Our architecture has grown:
User → EC2 → RDS
** ↓**
** S3**
And now the pieces are starting to connect.
But let's make the application smarter.
- Lambda: Something Happened — Do Something
Suppose every time someone uploads a resume, we want to perform some processing automatically.
Maybe we want to:
extract text,
generate a preview,
validate the file,
scan metadata,
or trigger another workflow.
We could make our EC2 application constantly check:
“Any new resumes?”
“Any new resumes?”
“Any new resumes?”
That isn't always the best design.
Instead, we can think in terms of events.
A file was uploaded.
That's an event.
Something should happen because of that event.
This is where AWS Lambda becomes extremely useful.
The flow could conceptually become:
Resume uploaded → S3 → Event → Lambda → Process resume
We don't necessarily need another server running continuously just waiting for resumes.
The function can execute when the event occurs.
That is one of the ideas behind serverless and event-driven architecture.
And suddenly the word Lambda becomes much less mysterious.
Now Look at What We Built
We started with four AWS names:
EC2.
S3.
RDS.
Lambda.
Initially they looked like four things we needed to memorize.
But now imagine a user applying for a job.
They open our application.
The backend runs on EC2.
They create an account, and the information goes into RDS.
They upload a resume, and the file goes into S3.
The S3 upload triggers Lambda.
Lambda processes the resume.
That's it.
You just started thinking in cloud architecture.
Not:
“What is EC2?”
But:
“Where should my application run?”
Not:
“What is S3?”
But:
“Where should uploaded files live?”
Not:
“What is RDS?”
But:
“Where should structured application data live?”
Not:
“What is Lambda?”
But:
“What should happen automatically when an event occurs?”
That shift is extremely important.
But Our Architecture Isn't Production-Ready Yet
This is where cloud learning gets interesting.
Our diagram may work conceptually.
But start asking real-world questions.
Who can access our EC2 server?
Can anyone on the internet connect directly to our database?
Is our S3 bucket public?
How does EC2 authenticate when accessing S3?
Where are our database credentials stored?
What happens if EC2 crashes?
What happens if thousands of people visit simultaneously?
How do we know when Lambda fails?
How do we monitor everything?
How do we protect private resumes?
Now we discover that we need more than four AWS services.
And that's perfectly fine.
Because now we have a reason to learn the next service.
IAM Suddenly Makes Sense
Earlier, IAM might have sounded like another definition:
Identity and Access Management.
But our application gives it context.
Our EC2 application needs permission to access certain AWS resources.
Our Lambda function may need permission to read a particular S3 bucket.
But should Lambda have complete administrator access to our entire AWS account?
Absolutely not.
We want to follow the principle of least privilege.
Give a component only the permissions it genuinely requires.
Now IAM isn't another AWS service to memorize.
It's solving a security problem we actually encountered.
VPC Suddenly Makes Sense
Our database contains sensitive information.
Should it be sitting openly on the internet?
Probably not.
Now networking matters.
We can begin thinking about public and private resources.
Which components need internet access?
Which components should communicate only internally?
Which ports should be allowed?
Which connections should be blocked?
Now concepts such as VPCs, subnets, route tables and security groups stop being random AWS vocabulary.
They exist because real architectures need controlled communication.
CloudWatch Suddenly Makes Sense
Our Lambda function failed last night.
How would we know?
Our EC2 application's CPU usage suddenly increased.
How would we notice?
Users are receiving errors.
Where do we inspect what happened?
Now monitoring matters.
This is where services such as Amazon CloudWatch become relevant.
Logs.
Metrics.
Alarms.
Observability.
Again, we aren't learning CloudWatch because an AWS roadmap told us to memorize it.
We're learning it because our application created a problem that monitoring helps solve.
This Is How I Think Beginners Should Learn AWS
Don't start with:
“Today I will memorize 20 AWS services.”
Start with:
“Today I will build something.”
Then allow the project to tell you what you need to learn.
Need compute?
Learn EC2.
Need object storage?
Learn S3.
Need relational data?
Learn RDS.
Need event-driven execution?
Learn Lambda.
Need permissions?
Learn IAM.
Need networking?
Learn VPC.
Need monitoring?
Learn CloudWatch.
Need an HTTP entry point for serverless functionality?
Now API Gateway may become relevant.
Need to decouple parts of your system?
Now queues such as SQS become interesting.
The AWS ecosystem stops looking like hundreds of disconnected services.
It starts looking like a toolbox.
Here's Where Beginners Usually Go Wrong
Someone watches an EC2 tutorial.
Launches an instance.
Deletes it.
Next tutorial.
Creates an S3 bucket.
Uploads an image.
Deletes it.
Next tutorial.
Creates an RDS database.
Runs one query.
Deletes it.
Next tutorial.
Creates a Lambda function.
Prints “Hello World.”
Done.
After three months they know dozens of AWS definitions.
Then someone asks:
“Can you deploy my application?”
And suddenly everything feels difficult.
Why?
Because the missing skill wasn't knowledge of individual services.
It was understanding how services work together.
Build One Project Across Multiple Services
Instead of building twenty disconnected tutorials, build one project and keep improving it.
Version 1:
Deploy your application.
Version 2:
Add a database.
Version 3:
Add file uploads.
Version 4:
Add event-driven processing.
Version 5:
Improve security.
Version 6:
Add monitoring.
Version 7:
Automate deployment.
Version 8:
Think about scalability.
Now every new AWS concept has context.
And context makes technical learning much easier to remember.
Then Break Your Own Architecture
This is one of the best ways to learn cloud.
Your application works?
Good.
Now intentionally break something.
Remove an IAM permission.
What happens?
Block a network connection.
What error appears?
Change an S3 policy.
Can your application still access the object?
Stop EC2.
What happens to your application?
Make Lambda fail.
Where do you find the error?
Cloud engineers spend a significant amount of time troubleshooting systems.
So debugging shouldn't be something you avoid while learning.
It should be part of the learning process.
And Then AI Enters the Architecture
Now imagine our job portal eventually becomes AI-powered.
Perhaps recruiters want to search resumes using natural language.
Someone searches:
“Find candidates with Python, AWS and Machine Learning experience.”
Now we might start exploring embeddings.
Semantic search.
Vector databases.
RAG.
LLMs.
AI Agents.
Maybe Amazon Bedrock becomes relevant depending on what we're building.
But here's the important point:
The AI doesn't replace the cloud architecture.
We still need storage.
Databases.
Security.
Networking.
Compute.
Monitoring.
Permissions.
APIs.
AI becomes another capability inside the system.
This is why I think cloud knowledge is extremely useful for people moving into AI engineering.
A powerful model still needs somewhere to live inside a reliable application.
Don't Ask “Which AWS Service Should I Learn Next?”
Ask:
“What Should I Build Next?”
That small change in thinking can completely change the way you learn AWS.
Because once you start building, the next service often becomes obvious.
Your application needs something.
AWS provides several possible ways to solve it.
Then your job becomes evaluating those options and choosing an architecture.
That's much closer to real cloud engineering.
The Architecture in One Minute
If you remember nothing else from this article, remember this simple application:
EC2 → Run the application
S3 → Store files and objects
RDS → Store relational application data
Lambda → React to events and execute functions
Then add:
IAM → Control permissions
VPC → Control network boundaries
CloudWatch → Understand what your system is doing
You don't need to memorize hundreds of AWS services today.
Understand these relationships first.
Then expand naturally.
Final Thought
AWS started making much more sense to me when I stopped seeing it as a list of products.
EC2 isn't something to memorize.
It's an answer to a compute problem.
S3 isn't something to memorize.
It's an answer to an object-storage problem.
RDS isn't something to memorize.
It's an answer to a relational-database problem.
Lambda isn't something to memorize.
It's an answer to certain event-driven compute problems.
Once you start thinking this way, AWS becomes less intimidating.
You stop asking:
“How many AWS services do I know?”
And start asking:
“Can I combine the services I know to build something that actually works?”
That second question is what matters.
Because knowing AWS definitions might help you answer an interview question.
Knowing how the pieces connect helps you become an engineer.
I'm continuing to explore AWS, Cloud Architecture, DevOps and AI Engineering, and I'll keep sharing practical concepts here in a way that makes the engineering easier to understand.
I’m also part of Eduleem School of Cloud and AI, where the focus is on helping learners move beyond theory toward practical, project-based technology skills.
Eduleem School of Cloud and AI
DEV Tags
