DEV Community: Armaan

EC2 + S3 + RDS + Lambda: Now AWS Finally Makes Sense

Armaan — Thu, 27 Aug 2026 06:06:28 +0000

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:

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?”

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

Stop Saying “I Know Cloud” Build These 5 Things Instead

Armaan — Thu, 20 Aug 2026 05:43:30 +0000

“I know cloud computing.”

It sounds good on a resume.

But there’s a question that matters much more:

What have you actually built on the cloud?

Knowing the difference between IaaS, PaaS and SaaS is useful. Knowing the names of dozens of AWS or Azure services can help too.

But cloud computing starts making much more sense when you deploy something, break something, secure something and figure out why your bill suddenly increased.

If you're learning cloud computing, here are five practical things I think you should build.

Deploy a Real Web Application

Start simple.

Take an application you've built locally and put it online.

Your architecture might initially look like:

User
↓
Domain
↓
Web Server
↓
Application

Sounds easy.

Then the questions begin.

Where should the application run?

How will users access it securely?

Where do environment variables go?

How do you configure HTTPS?

What happens when the server restarts?

How do you deploy an update?

Suddenly, concepts such as compute, DNS, networking, ports, firewalls and SSL/TLS aren't just definitions anymore.

They have a purpose.

Whether you're learning AWS, Microsoft Azure or Google Cloud, deploying your first real application is one of the best ways to understand what cloud infrastructure actually does.

Connect Your Application to a Managed Database

Now make the application useful.

Give it data.

Instead of installing a database manually on the same server, experiment with a managed database service.

Your architecture becomes:

User
↓
Application
↓
API
↓
Managed Database

And now you have another set of questions.

Should the database be publicly accessible?

Hopefully not.

How should the application authenticate?

Where should credentials be stored?

What happens if the database fails?

Are backups enabled?

Who has permission to access it?

This is where you begin understanding that cloud engineering isn't simply about running servers somewhere else.

It's about designing systems.

Build a Serverless Automation

Next, try building something without maintaining a traditional server.

For example:

A user uploads a file.

That upload triggers a function.

The function processes the file.

The result gets stored somewhere else.

File Upload
↓
Cloud Storage
↓
Event Trigger
↓
Serverless Function
↓
Process Data
↓
Store Result

This introduces you to event-driven architecture.

On different cloud platforms, you'll encounter services designed for these kinds of workflows.

The important thing isn't memorizing every service name.

Understand the pattern:

Event → Function → Action

Once you understand the architecture, learning the equivalent service on another cloud platform becomes much easier.

Deploy an AI Application

Now let's make it more interesting.

Suppose you've built an AI assistant locally.

It might work perfectly on your laptop.

But what happens when other people need to use it?

You might eventually need something like:

User
↓
Frontend
↓
API
↓
AI / LLM
↓
Database or Vector Store
↓
Cloud Storage
↓
Monitoring

Now AI engineering and cloud engineering start meeting.

You have to think about:

API management
Authentication
Secrets
Storage
Databases
Model/API latency
Logging
Scaling
Monitoring
Cost

This is an important transition.

“I built an AI model.”

becomes:

“I built an AI system people can actually access.”

That's a completely different engineering challenge.

Build Something Secure Enough to Fail Safely

This is the project many beginners skip.

They build something.

It works.

And they stop.

But ask yourself:

What happens when something goes wrong?

Imagine your architecture looks like this:

              ┌──────────────┐
              │     User     │
              └──────┬───────┘
                     ↓
              ┌──────────────┐
              │   Web App    │
              └──────┬───────┘
                     ↓
              ┌──────────────┐
              │     API      │
              └──────┬───────┘
                     ↓
         ┌───────────┴───────────┐
         ↓                       ↓
   ┌──────────┐            ┌──────────┐
   │ Database │            │ Storage  │
   └──────────┘            └──────────┘
                     ↓
              ┌──────────────┐
              │  Monitoring  │
              └──────────────┘

Now start attacking your own assumptions.

What if someone discovers an API endpoint?

What if a secret gets committed to GitHub?

What if traffic suddenly increases 100×?

What if the database becomes unavailable?

What if a developer accidentally receives administrator permissions?

What if logs contain sensitive information?

What if a cloud resource keeps running for a month because nobody noticed it?

This is where concepts such as IAM, least privilege, secrets management, monitoring, logging, backups and cost controls stop being boring cloud terminology.

They become necessary.

The Biggest Cloud Learning Mistake

One mistake I see beginners make is trying to memorize an entire cloud platform.

They open AWS or Azure and see hundreds of services.

Then they think:

“Do I need to learn all of these?”

No.

Start with the problems.

Need somewhere to run code?

Learn compute.

Need persistent data?

Learn databases.

Need files?

Learn object storage.

Need controlled access?

Learn IAM.

Need to understand failures?

Learn monitoring and logging.

Need automatic execution?

Learn serverless.

Need repeatable infrastructure?

Start exploring Infrastructure as Code.

Problem first. Service second.

That mindset makes cloud computing much easier to understand.

AWS vs Azure vs Google Cloud: Which One Should You Learn?

Beginners often spend too much time on this question.

The platforms are different, but many fundamental ideas transfer.

Compute
Networking
Storage
Databases
Identity
Security
Monitoring
Automation
Containers
Serverless

Learn these concepts properly on one platform first.

Then understanding another cloud becomes much easier.

Don't try to become:

“Someone who remembers 150 AWS services.”

Try to become:

“Someone who understands how cloud systems are designed.”

That's a much more transferable skill.

Build a Cloud Portfolio, Not Just a Certificate Folder

If you're learning cloud computing for your career, your GitHub shouldn't be empty.

Build something you can explain.

Document the architecture.

Add a README.

Explain the security decisions.

Show how deployment works.

Mention what went wrong.

Explain what you would improve.

A small working project you genuinely understand can teach you far more than copying a massive architecture you can't explain.

What We're Trying to Teach at Eduleem

At Eduleem School of Cloud and AI, we work with learners who are trying to move from understanding technology conceptually to actually using it.

And that's an important distinction.

Cloud learning shouldn't end with:

“I know what AWS and Azure are.”

The goal should move toward:

“I can design, deploy, secure and troubleshoot something in the cloud.”

Whether you're learning independently, through documentation, through projects or through structured training, keep building.

The cloud makes much more sense once something you've built is actually running on it.

Final Thought

If you're currently learning cloud computing, don't ask yourself:

“How many cloud services do I know?”

Ask:

“What can I build with the services I understand?”

Deploy one application.

Connect one database.

Create one serverless workflow.

Deploy one AI project.

Secure and monitor one architecture.

You'll probably learn more from debugging those five projects than from memorizing another hundred service names.

Build first. Understand deeper. Then build again.

I'm part of the team at Eduleem School of Cloud and AI, where we focus on practical learning across cloud, AI and modern technology skills. I share these posts to make technical concepts easier for students and developers who are building their careers.

Eduleem School of Cloud and AI

The AI Revolution Isn’t Coming — It’s Already Here. Are You Ready to Build With It?

Armaan — Wed, 19 Aug 2026 06:32:36 +0000

Artificial Intelligence isn't something developers are waiting for anymore.

It's already changing how we write code, analyze data, search information, automate workflows, build applications, and solve problems.

But there's an important difference between:

Using AI and building with AI.

Anyone can open an AI assistant and write a prompt.

Building an AI application requires understanding what happens behind that prompt.

And that's where things get interesting.

🧠 AI Is More Than Prompt Engineering

A simple AI interaction might look like:

User → Prompt → AI Model → Response

But real-world AI applications can be much more complex:

User → Application → AI Model → Data → Tools/APIs → Response

Suddenly, you're dealing with much more than prompts.

You need to think about:

Python
Data
Machine Learning
APIs
Databases
Cloud
Security
Deployment

The AI model is only one part of the system.

🐍 Start With the Foundations

If you're beginning your AI journey, don't feel pressured to learn every new framework immediately.

Start with strong foundations.

Python → Data → Machine Learning → Deep Learning → Applied AI

Python gives you the ability to build.

Data Science teaches you how to understand information.

Machine Learning teaches systems to recognize patterns.

Deep Learning introduces neural networks used across NLP, Computer Vision and Generative AI.

Once these foundations become clearer, modern AI architectures become much easier to understand.

📚 From LLMs to RAG

Large Language Models are powerful, but they don't automatically know your private or latest information.

Suppose you're building an AI assistant that needs to answer questions from company documents.

One approach is Retrieval-Augmented Generation (RAG).

A simplified workflow is:

Question → Search Documents → Retrieve Context → LLM → Answer

Now the application can retrieve relevant information before generating its response.

This introduces developers to technologies such as:

Embeddings + Vector Search + LLMs + APIs

And suddenly, you're not simply using AI.

You're engineering an AI system.

🤖 The Next Step: AI Agents

AI agents take this idea even further.

Instead of only generating an answer, an agent can potentially select tools and perform controlled actions.

For example:

User Request → Agent → Select Tool → API/Database → Result → Response

Imagine asking:

“Find the relevant project documents and summarize what I need to prepare for tomorrow.”

An agentic application could potentially retrieve information from authorized tools, analyze it and generate the result.

This is why concepts such as tool calling, AI agents and MCP are becoming interesting areas for developers to explore.

☁️ Eventually, Your AI Has to Leave Your Laptop

Building an AI project locally is one thing.

Making it available to real users introduces another challenge.

You may need:

APIs → Cloud → Authentication → Database → Monitoring → Security

That's where platforms such as Microsoft Azure and AWS become useful.

A more complete AI engineering workflow starts looking like:

Data → Model → API → Cloud → Application

Learning how these components connect can be more valuable than memorizing dozens of AI tools.

🏗️ Build Something

This is probably the most important part.

Don't spend your entire AI journey watching tutorials.

Build something small:

📄 Document Q&A application
🤖 Simple AI agent
📊 Prediction model
👁️ Image classifier
🧠 RAG knowledge assistant

Your first project doesn't need to be revolutionary.

It needs to teach you something.

Follow this cycle:

Learn → Build → Break → Debug → Improve

That's where real understanding develops.

🚀 The Skill That Won't Become Outdated

AI tools will change.

Models will change.

Frameworks will change.

But some skills will continue to matter:

Programming. Problem solving. Data. System design. Debugging. Security. Building.

So instead of asking:

“Which AI tool should I learn next?”

maybe ask:

“What can I build with what I already know?”

Because the AI revolution isn't coming.

It's already here.

And developers have an incredible opportunity to help build what comes next. 🚀

💬 What Are You Building?

I'm currently exploring AI Engineering, Machine Learning, RAG, Agentic AI, Microsoft Azure and Cloud AI, and I'll be sharing what I learn here on DEV.

What are you currently learning or building?

Let me know in the comments. 👇

— Armaan Syed
AI Engineer | Eduleem School of Cloud and AI.