DEV Community: Ijay

Some cloud concepts like regions and availability zones can be explained simply. Do you think someone without a technical background can get AWS fundamentals? Watch and share your thoughts: https://www.youtube.com/watch?v=UaNqs93P38Q&t=8s #aws #cloud

Ijay — Wed, 15 Apr 2026 13:25:21 +0000

youtube.com

How I Escaped Tutorial Hell

Ijay — Wed, 15 Apr 2026 09:00:00 +0000

What watching tutorials taught me and why building changed everything.

Almost everyone who is learning something new experiences tutorial hell at some point.

You watch videos, read guides, and follow along step by step. Everything seems clear while you are watching.

But when it is time to try things on your own, you suddenly feel stuck.

In this edition, I want to share my experience and how I eventually broke out of that cycle.

Time flies.

I still remember when I first started learning to code.

I spent hours watching tutorials. React tutorials. JavaScript tutorials. Anything I could find on YouTube.

If you asked me what I was doing, I would confidently say I was learning.

I was always busy.

Busy watching another tutorial.

Busy taking notes.

Busy trying to become a good software engineer.

But there was one problem.

I was watching a lot.

I was not building much.

But whenever I tried to build something on my own, I froze.

Following along in a tutorial felt easy. I could understand what the instructor was doing, and everything looked clear.

But when the tutorial ended, and I was left with a blank editor, I did not know where to start.

That was when I realized something.

I was not actually building.

I was stuck in what many developers call tutorial hell.

Everything makes sense while the instructor is explaining it.

But the moment the tutorial ends and you try to build something on your own, the confidence disappears.

That was exactly what happened to me when I was learning React.

I had watched many tutorials, but I still did not know how to start a simple application from scratch.

That was when I realised something needed to change.

It took time, but eventually I broke out of that cycle.

The thing that helped me was simple.

I stopped focusing on watching and started focusing on building.

Now, when I want to learn something new, I approach it differently.

Instead of opening YouTube first, I start with a small idea.

It could be a simple tool. It could be a small project.

Then I try to build it.

Most of the time, I get stuck. That is normal.

When that happens, I search for solutions, read documentation, debug with AI, or even just take a rest.

But the important thing is this.

I am still the one building it.

And that changes everything.

When you build something yourself, you begin to understand the real challenges developers face. You start seeing how different parts connect. Your confidence grows because you solved the problem yourself.

Tutorials are useful. They introduce you to new tools and concepts.

But tutorials alone cannot make you better.

Building can

Try this this week

Pick one small idea and build it without following a tutorial step by step.

It does not need to be perfect. It just needs to be something you built yourself.

Examples

• A simple to-do list app

• A small API

• A static website

• A small cloud project, like hosting a website on Amazon S3

If you are interested in cloud projects and you are struggling to think of ideas, that is completely normal. Some days your mind just goes blank.

When that happens, do not worry.

You can explore AWS Skill Builder. They have many hands-on projects and learning paths you can follow.

You can also check out my previous post, where I shared an AWS learning path for beginners.

You will learn more than you expect.

Build more.

Watch less.

Your confidence will grow faster than you think.

Before you go, I am curious.

Right now, which one are you doing more?

Watching tutorials or building projects?

Reply and tell me. I would love to hear your experience.

Every month, I share simple lessons from my journey learning cloud and DevOps.

If you enjoy practical stories like this, follow the newsletter for more.

You can follow my work and projects on Twitter, LinkedIn, and GitHub to stay updated on what I’m building and learning.

Thank you.

Can a Non-Technical Person Understand AWS

Ijay — Mon, 13 Apr 2026 09:00:00 +0000

This video explains Amazon Web Services in simple, everyday language, without technical pressure.

If you are not from a tech background but keep hearing about cloud computing, AWS jobs, or cloud skills, this video is for you.

In this video, I broke down what AWS actually is, why companies use it, and what you truly need to understand without becoming an engineer.

I made this video for beginners, career switchers like me, students, business owners, and anyone curious about cloud computing but overwhelmed by technical explanations.

You do not need programming experience to follow along. This is a clear explanation of AWS from a non-technical point of view.

If this video helped you, feel free to leave a comment here and engage on my channel. I read and learn from your feedback.

Thank you. ❤️

Deploying with Terraform

Ijay — Wed, 18 Mar 2026 19:27:00 +0000

The workflow design

In my previous posts, I focused on understanding Infrastructure as Code and setting up my environment. Now it is time to actually build something.

In today's challenge, we are to build our website using Terraform.

What I Built

I used Terraform to create a simple EC2 instance on AWS and made it accessible from the browser.

The setup included:

A provider block to connect to AWS
A resource block to create the EC2 instance
A security group to allow HTTP traffic on port 80
A user data script to serve a simple HTML page.

To deploy the server, I ran:

terraform init
terraform plan
terraform apply -auto-approve

Confirming the Server

After running terraform apply, Terraform returned a public IP in the AWS Console.

I copied the public IP generated and pasted it into the browser:

That confirmed that the server was running and accessible.

The challenges I faced

One issue I encountered was using an invalid AMI. At first, my instance failed to launch because the AMI was not valid for my region.

I fixed this by using a data block to dynamically fetch the correct Amazon Linux AMI.

I also had an issue where my server was not loading in the browser. This was because the web server was not properly set up. I fixed it by installing and starting Apache using the user data.

What I Learned

Doing this challenge helped me understand how Terraform actually works in practice.

Conclusion

Instead of clicking around the AWS console, I was able to define everything in code and create infrastructure in a repeatable way.

This is just the beginning, and I’m looking forward to building more as I continue this challenge.

If this resonates with you, feel free to share it with others on a similar journey.

Other Helpful Resources

Stay updated with my projects by following me on Twitter, LinkedIn, and GitHub.

Thank you for reading

IAM Permissions Are Confusing

Ijay — Wed, 18 Mar 2026 09:00:00 +0000

If you’ve ever worked with AWS IAM, you've probably felt this way.

You create a policy. Attach it to a user or role. And still get an "Access Denied" error.

That happened to me more than once.

While learning AWS, I even locked myself out of my account after giving the wrong permissions to a service. Not on purpose, I simply didn’t fully understand what the policy was actually allowing.

That’s when I realised guessing my way through IAM wasn’t helping.

While trying to make sense of it, I came across the IAM Policy Simulator, and it changed how I approach permissions.

What I like about the simulator is how simple the idea is.

It lets you test what a user or role can actually do before you change anything.

Instead of wondering, you can ask one clear question:

Can this user or role perform this action on this resource? (For example: Can this EC2 role read from this S3 bucket?)

The simulator checks all attached policies and shows you the final decision. Seeing it laid out like that helped me understand exactly where things were going wrong.

How I usually access it

When I need it, I:

Sign in to AWS.
Open the IAM service.
On the right-hand side, under Tools, click Policy Simulator.
It redirects to the Policy Simulator page.

Or open the IAM Policy Simulator directly here: IAM policy simulator

From there, I test the actions I’m unsure about and see what’s allowed or denied.

Why this matters (at least for me)

Most of the permission issues I’ve run into weren’t due to anything being missing.

They were small details:

A wrong resource ARN
A condition I didn’t think about
Or an explicit deny I forgot existed

The simulator doesn’t fix things for you or replace reading policies carefully, but it clearly shows which policies are affecting or attached to the user or role, and that makes IAM much less frustrating.

What I’m taking away from this

The IAM Policy Simulator has been a safer way for me to learn permissions. It lets me experiment, understand mistakes, and avoid granting extra permissions just to “make it work.”

I’m curious: When IAM permissions don’t work as expected, how do you usually debug them? Trial and error or stopping to inspect the policy closely?

If IAM or any AWS service has ever confused you, follow the
newsletter or the YouTube channel. I share what I learn as I continue making sense of AWS.

Stay updated with my projects by following me on Twitter, LinkedIn, and GitHub.

Thank you for reading!

Step-by-Step Guide to Setting Up Terraform, AWS CLI, and Your AWS Environment

Ijay — Tue, 17 Mar 2026 23:20:50 +0000

In my previous post, I talked about what Infrastructure as Code is, why it matters, and why I decided to start learning Terraform.

Now it is time to move from understanding to actually setting things up.

Before building anything, having the right environment is important. If your setup is not correct, it can slow you down later. So in this post, I will walk through how I set up my Terraform environment and connected it to AWS.

Step 1: Setting Up AWS Account

I already had an AWS account, so I didn’t need to create a new one. However, I made sure not to use my root account.

Instead, I created an IAM user with programmatic access using the AWS console and used it for my setup instead of my root account. This is more secure and is the recommended way to work with AWS.

Step 2: Installing AWS CLI

Next, I installed AWS CLI on my system.

sudo apt update
sudo apt install awscli -y

After installation, I checked that it was working by verifying the version. This confirmed that AWS CLI was installed correctly.

aws --version

Step 3: Checking the credentials
After installing AWS CLI, I configured it using my IAM user credentials.

I added:

Access key
Secret key
Default region

I did this by running aws configure and following the prompts.

To confirm everything worked, I checked my AWS identity. It returned my account details, which showed that my setup was correct.

To check

terraform version
aws --version
aws sts get-caller-identity
aws configure list

Output

Terraform v1.14.7
on linux_amd64
+ provider registry.terraform.io/hashicorp/aws v6.36.0
aws-cli/2.22.12 Python/3.12.6 Linux/6.6.87.2-microsoft-standard-WSL2 exe/x86_64.ubuntu.22
{
    "UserId": "AXXXXXXXXXXXXXXXXXXXV",
    "Account": "2xxxxxxxxxxxx4",
    "Arn": "arn:aws:iam::2xxxxxxxxxxx4:user/onyi"
}
      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                <not set>             None    None
access_key     ****************5SNW shared-credentials-file
secret_key     ****************KJtJ shared-credentials-file
    region                eu-west-1      config-file    ~/.aws/config

Step 4: Installing Terraform

I installed Terraform on my system and confirmed it was working by checking the version.

During this step, I noticed that my Terraform version was outdated. I am currently fixing this by downloading the latest version from the official
Terraform website.

Step 5. Connecting Terraform to AWS

Terraform uses the AWS credentials configured through AWS CLI.

Step 6. Verifying the Setup

To make sure everything was working properly, I ran checks to confirm:

Terraform is installed
AWS CLI is installed
AWS authentication is working
AWS configuration is correct

Everything worked as expected, which means my environment is ready.

Challenges I Faced

The main issue I encountered was that my Terraform version was outdated.

I discovered this while verifying my setup and started fixing it by installing the latest version.

What I Learned

From this setup, I learned how Terraform connects to AWS through AWS CLI.

I also understood why using an IAM user is important instead of using root credentials. It improves security and gives better control over access.

Conclusion

From everything, using the AWS CLI is more secure than clicking the AWS console.

If this resonates with you, feel free to share it with others on a similar journey.

Other Helpful Resources

Stay updated with my projects by following me on Twitter, LinkedIn, and GitHub.

Thank you for reading

What is Infrastructure as Code?

Ijay — Tue, 17 Mar 2026 10:00:00 +0000

Learning cloud and DevOps is good, but in the process of learning, I’ve come to understand that Infrastructure as Code is very important.

In this article, I will cover

What Infrastructure as Code is and the problem it solves
The difference between declarative and imperative approaches
Why Terraform is worth learning
My reason for taking on this 30-day challenge

What is Infrastructure as Code (IaC)

From my reading, Infrastructure as Code means using code to manage and set up infrastructure instead of doing everything manually. It is mostly used by DevOps and cloud engineers to provision resources in the cloud.

What problem does it solve?

IaC solves a lot of issues, especially what people call click ops. Instead of going to the cloud console and clicking around, which can lead to mistakes, you define everything in code. This makes it easier to repeat the same setup and avoid errors.

What are the ways Terraform is defined?

There are two ways Terraform is defined in editors:

Declarative
Imperative

1.Declarative: means you describe what you want, and the tool figures out how to achieve it.

For example, if you want to create an S3 bucket in AWS using Terraform, you just write:

resource "aws_s3_bucket" "example" {
  bucket = "my-example-bucket"
}

In the example above, you are only saying, "Create a bucket with this name.” Terraform handles how it will be created.

2.Imperative: means you define every single step to get the result.

For example, using AWS CLI:

aws s3 mb s3://my-example-bucket

Which method is commonly used by developers?

In declaring a HashiCorp Configuration Language (HCL), most developers use declarative rather than imperative because you only define what you want, and the tool handles the process. It reduces errors and makes infrastructure easier to manage.

While imperative is useful for quick tasks, it is not for long-term and scalable systems. i.e., step by step

Why do we use Terraform basically

Terraform is used for provisioning infrastructure across different cloud providers. It is not limited to one cloud like CloudFormation, so it is more flexible and widely used.

My goal for the next 30 days

My goal is to challenge myself to build using IaC and stop relying on clicking around in AWS. I want to improve my skills, become better as a DevOps and cloud engineer, and get more comfortable building real things.

If this resonates with you, feel free to share it with others on a similar journey.

Other Helpful Resources

Stay updated with my projects by following me on Twitter, LinkedIn, and GitHub.

Thank you for reading

Building a 3-Tier Application on AWS

Ijay — Tue, 17 Mar 2026 08:58:00 +0000

When I hear the word "3-tier architecture," it sounds like one of those big concepts people often mention in all these tech talks. Most times, I just add it to my list of things to read later.
But something interesting happened when I started looking into it more closely.
I realized that 3-tier architecture is actually something many of us already interact with, especially when using Backend as a Service platforms.
Sometimes a concept becomes clearer when someone explains it in a simple way. After attending a session from Solavise Technologies Institute, the idea stopped feeling abstract.

Instead of only reading about it, I decided to build something small to understand how it actually works.

With their guidance, I built a Nigerian passport application system deployed using a 3-tier architecture on AWS.

Architecture Diagram

Below is a simple overview of how the system is structured.

                User
                 |
                 |  HTTP Request
                 v
        -----------------------
        Presentation Layer
        EC2 Instance
        Nginx Web Server
        (HTML, CSS, JS)
        -----------------------
                 |
                 |  POST Request
                 v
        -----------------------
        Logic Layer
        EC2 Instance
        Flask API
        (Application Logic)
        -----------------------
                 |
                 |  SQL Query
                 v
        -----------------------
        Data Layer
        Amazon RDS
        MariaDB Database
        -----------------------

A 3-tier architecture simply means an application separated into three different layers:

1. Presentation Layer

This is the frontend of an application. It is what users see and interact with.

2. Logic Layer

This is the backend. It processes requests and handles the application logic.

3. Data Layer

This is where the data is stored. It can be a database hosted by a cloud provider or any other database system.

The Idea Behind the Project

The goal was not to build a complex application but to understand how real systems work across layers.

Imagine a simple website where someone fills out a passport application form.

When a user submits the form, a few things need to happen.

The application receives the request.
The system processes the data.
The information is stored in a database.

Instead of putting everything on one server, the system splits these responsibilities across different layers.

This separation is what defines a 3-tier architecture.

Breaking Down the Architecture

1. Presentation Layer: The first layer of the architecture is the presentation layer. It is the part users interact with.

For this project, the frontend consists of a simple form, which I built with:

HTML
CSS
JavaScript

The frontend runs on an EC2 instance configured with Nginx.

Its responsibility is straightforward. It collects user input from the passport form and sends the data to the backend.

2. Logic Layer: The second layer of the architecture is the logic layer. This layer processes the requests coming from the frontend.

In this project, the logic layer runs on a separate EC2 instance running a Flask API.

When the frontend sends a request, the Flask application receives the form data, processes it, and prepares it to be stored in the database.

3. Data Layer: The final layer is the data layer. This layer is responsible for storing and managing the application data.

For this project, I used Amazon RDS with MariaDB to store the passport application records.

Whenever the backend receives a valid request, it inserts the data into the RDS database.

How the System Works

Once all three layers are in place, the interaction between them follows a simple flow.

A user opens the website and fills out the passport form.
The frontend sends the form data to the Flask API.
The backend processes the request and stores the information in Amazon RDS.

Each layer performs a specific task, which keeps the system organized and easier to manage.

What was the Challenge?

At one point during the project, everything seemed ready.

The servers were running.
The code looked correct.
The database was configured. But the form refused to work.

After troubleshooting for hours, I realised the issue had nothing to do with the application code.

The problem was coming from the network configuration.

The backend server was not reachable because the security group did not allow traffic on the required port.

Once I corrected the security group configuration and fixed the API endpoint, communication between the 3 layers started working immediately.

What This Project Helped Me Understand

Before building this project, a 3-tier architecture felt like a theoretical concept:

Now it feels much more practical.
Makes the applications easier to maintain, scale, and troubleshoot.

Project Repository

The full project code is available here:

In summary

The frontend focuses on user interaction.
The backend handles the application logic.
The database stores and manages the data.

If you found this documentation helpful, share it with others who may find it interesting.

Other Helpful Resources

Stay updated with my projects by following me on Twitter, LinkedIn, and GitHub.

Thank you for reading

Running a Containerised App on AWS: My Experience

Ijay — Fri, 06 Mar 2026 12:00:00 +0000

In this project, I wanted to practice building a DevOps workflow from development to deployment.
The goal was simple. Take a small application, package it with Docker, deploy it to AWS, and automate the process using GitHub Actions.
This project helped me understand how different tools in the DevOps ecosystem work together.

What this project does

This project shows how an application can move from code to deployment using automation.

The process looks like this:

Code is pushed to GitHub
GitHub Actions builds the Docker image
The image is pushed to Amazon ECR
Amazon ECS Fargate pulls the image

This removes the need to manually deploy applications.

Architecture

Here is a simple view of the setup:

Developer (Build the code)
   │
   │ 
   ▼
Build Docker Image
   │ provision with Terraform
   ▼
Amazon ECR
   │
   ▼
Amazon ECS Fargate
   │ push code
   ▼
GitHub Repository
   │
   ▼
Users can access the application

Tools used

Docker
Terraform
AWS ECS Fargate
Amazon ECR
GitHub Actions
Node.js

Each tool plays a different role in the deployment process.

Docker packages the application so it runs consistently anywhere.
Terraform creates and manages the infrastructure.
ECR stores the container images.
ECS Fargate runs the containers without managing servers.
GitHub Actions automates the build and deployment process.

Key steps in the project

The application was packaged into a Docker image using a Dockerfile. This allows the application to run consistently across environments.

Creating the infrastructure

Terraform was used to create the AWS infrastructure:
VPC
Subnets
Security groups
ECS Cluster
ECS Service running on Fargate

Using Terraform makes the infrastructure reproducible and easy to manage.

Deploying to ECS Fargate
The container image stored in Amazon ECR is pulled by ECS Fargate. Fargate runs the container without needing to manage EC2 servers.

When code is pushed to the main branch:

The Docker image is built
The image is pushed to Amazon ECR
ECS updates the running service
This means deployments happen automatically.

What I learned

Working on this project helped me understand how different DevOps tools connect.

Challenge

One challenge I encountered during this project was configuring the Application Load Balancer. After deploying the service on ECS Fargate, the application was accessible using the assigned public IP address. However, I wanted users to access the application via a stable DNS URL rather than an IP address.
To achieve this, I set up an Application Load Balancer and connected it to a target group. The target group showed a healthy status, which indicated that the ECS service was running correctly. Despite this, the application was still not accessible through the load balancer DNS.
After several attempts to troubleshoot the issue, I suspected it might be related to network configuration or security group settings. Since the project's focus was the deployment pipeline, I temporarily removed the load balancer configuration.
For now, the application can be accessed using the public IP address assigned by ECS. I plan to revisit the load balancer configuration later to fully resolve the issue.

Project repository

You can see the full project here

Final thoughts

This project helped me put my DevOps knowledge into practice and see the tools I have been learning work together in a real setup. It was a good opportunity to apply Docker, Terraform, AWS, and CI/CD in a practical environment and better understand how these tools support deployments.

If you would like to build the same setup yourself, I wrote a step-by-step guide explaining the exact process.

If you found this article helpful, share it with others who may find it interesting.

Other Helpful Resources

Stay updated with my projects by following me on Twitter, LinkedIn, and GitHub.

Thanks for reading

Step-by-Step Guide: Deploy a Containerized App to AWS

Ijay — Thu, 05 Mar 2026 12:27:30 +0000

This guide explains the steps I followed to containerize an application and deploy it to AWS using Docker, Terraform, ECS Fargate, and GitHub Actions.

The goal is simple.
Build the app, package it in Docker, store the image in ECR, run it on ECS Fargate, and automate the deployment with GitHub Actions.

1. Prepare the Application

Create a simple Node.js application.

Example project structure:

app/
server.js
package.json
Dockerfile
terraform/

Install dependencies:

npm install

Run the application locally to confirm it works.

node server.js

Open:

http://localhost:3000

2. Containerize the Application

Create a Dockerfile.

FROM node:20-alpine

WORKDIR /app

COPY package*.json ./

RUN npm install --production

COPY . .

EXPOSE 3000

CMD ["node", "app/server.js"]

Build the image:

docker build -t job-tracker-app .

Run the container locally:

docker run -p 3000:3000 job-tracker-app

Open the browser:

http://localhost:3000

3. Create an Amazon ECR Repository

Open AWS Console.

Go to:

ECR → Create repository

Give it a name:

job-tracker-app

After creating the repository, push your Docker image.

aws ecr get-login-password --region us-east-1 \
| docker login --username AWS --password-stdin ACCOUNT_ID.dkr.ecr.us-east-1.amazonaws.com

Tag the image:

docker tag job-tracker-app:latest ACCOUNT_ID.dkr.ecr.us-east-1.amazonaws.com/job-tracker-app:latest

Push the image:

docker push ACCOUNT_ID.dkr.ecr.us-east-1.amazonaws.com/job-tracker-app:latest

4. Provision Infrastructure with Terraform

Create infrastructure using Terraform.

Resources created include:

VPC
Public subnets
Security groups
ECS cluster
ECS service
Application Load Balancer

Initialize Terraform:

terraform init

Apply infrastructure:

terraform apply

Confirm the ECS service is running.

You should see:

1/1 tasks running

5. Verify the Application

Once the ECS task is running, the application can be accessed using the public IP assigned to the service.

Open the IP address in the browser to confirm the application is working.

6. Push the Project to GitHub

Initialize git:

git init
git add .
git commit -m "Initial commit"

Create a repository on GitHub.

Connect the repo:

git remote add origin YOUR_REPO_URL
git branch -M main
git push -u origin main

7. Add GitHub Actions for CI/CD

Create this folder in your repository:

.github/workflows

Create a file:

deploy.yml

The workflow should:

build the Docker image
push the image to ECR
update the ECS service

8. Add AWS Credentials to GitHub

In your GitHub repository, go to:

Settings → Secrets → Actions

Add these secrets:

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY

These allow GitHub Actions to deploy to AWS.

9. Trigger Deployment

Push a change to the repository:

git push

GitHub Actions will start the pipeline.

The pipeline will:

build the Docker image
push it to ECR
update the ECS service

Your application will be redeployed automatically.

Final Result

You now have:

A containerized application.
Infrastructure created with Terraform.
Containers running on ECS Fargate.
Automated deployment using GitHub Actions.

This setup removes manual deployment and keeps the application updated whenever code changes.

If you found this article helpful, share it with others who may find it interesting.

Other Helpful Resources

Stay updated with my projects by following me on Twitter, LinkedIn, and GitHub.

Thank you for reading

The $30 AWS Bill I Didn’t Expect (And What It Taught Me)

Ijay — Wed, 18 Feb 2026 08:00:00 +0000

One mistake many beginners make with AWS is assuming nothing will happen if they stop using it.

In 2023, I opened an AWS account and deployed a small React app just to explore the console. After that, I left the account untouched for months.

When I returned in 2024 to take cloud learning seriously, my free tier had already expired. I logged in and saw a $30 bill.

The amount wasn’t huge, but the lesson learned was important.

I didn’t intentionally leave anything running. I simply didn’t understand which AWS services continue to cost money when you don’t turn them off.

After reaching out to AWS support and explaining my situation, it was resolved. That experience changed how I approach cloud learning.

Cloud knowledge is not only about deploying services. It’s also about knowing what to stop, delete, and shut down.

This lesson came from my own early mistakes while learning AWS, and it’s one that many beginners don’t realize until they see a bill.

That’s why I started creating content to help beginners understand AWS billing, Free Tier limits, and simple cleanup habits that prevent surprise charges.

If you prefer videos, I’ve created guides on:

If you prefer reading, this article breaks it down clearly: The Hidden Challenges of Building with AWS

One habit that saves money: After every lab or test, spend five minutes checking EC2, RDS, Lambda, and S3 before logging out. That small habit can prevent surprise charges.

Key takeaway: In AWS, learning what to turn off is just as important as learning what to deploy. Always review and clean up your resources after every experiment.

Discussion question: Which AWS service do you always double-check before logging out, or which one worries you the most about unexpected costs?

Drop your answer in the comments.

If this helped clarify things, follow the newsletter and reshare so others can learn too.

Stay updated with my projects by following me on Twitter, LinkedIn, and GitHub.

Thank you.

Understanding Cloud Service Models Using a Simple Analogy

Ijay — Wed, 21 Jan 2026 08:00:00 +0000

One thing I noticed while learning cloud computing is this Most people don’t struggle because cloud services are hard. They struggle because they don’t know which service model they’re using.

Cloud services are a core foundation. Once you understand them, everything else becomes easier. Even AWS certification questions start to feel clearer.

The truth is, you don’t always need full control in the cloud. Sometimes you want to manage everything yourself. Sometimes you just want to deploy and move on. Other times, you only need code to run for a few seconds.

That’s why cloud service models exist.

IaaS: You manage the server and OS. Examples in AWS: EC2, EBS, VPC

PaaS: You focus on your app; AWS manages the platform. Examples in AWS: Elastic Beanstalk, RDS

SaaS: You just use the software; there is no infrastructure to manage. Examples: Gmail, Google Drive, Slack. In AWS: Amazon WorkMail

FaaS: Your code runs only when triggered, with no servers to manage. Example in AWS: AWS Lambda

In this month’s edition of Tech Notes, I’m using a very simple real-life analogy to explain when each cloud service model makes sense.

Related article: What is Cloud Computing? A Guide for Beginners

Now I’m curious. Which cloud service model confused you the most when you started IaaS, PaaS, SaaS, or FaaS?

Drop your answer in the comments.

For me, IaaS was tricky because missing one small configuration setting caused me unexpected issues.

If this helped clarify things, follow the newsletter and reshare so others can learn too.

Subscribe on LinkedIn

Stay updated with my projects by following me on Twitter, LinkedIn, and GitHub.

Thank you for reading!