Forem: Ijay

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!

Learn Cloud Security Fundamentals in AWS

Ijay — Wed, 17 Dec 2025 09:00:00 +0000

Security is a vital part of every system and infrastructure. The word "security" comes from the Latin securitas, which is composed of se- (meaning “without”) and cura (meaning “care” or “worry”). Originally, it meant "without worry." Over time, it has come to signify being safe or protected.

Today, when we discuss security, we usually refer to protection from harm, danger, or threats, whether in our homes, online, while using online banking, or even across an entire country. Security is important in everything we do.

Cloud providers, such as AWS, are no exception. Their infrastructure must be safeguarded to ensure users’ peace of mind. But on platforms like AWS, security is a shared responsibility. This means that both the provider and the user play a role in maintaining security.

Amazon Web Services (AWS) is one of the most popular cloud service providers worldwide. With great power and flexibility comes the responsibility to secure your cloud infrastructure, data, and applications.

In this guide, we’ll explore the fundamental aspects of cloud security on AWS, making it easy to understand for those new to cloud computing.

What is Cloud Security?

Cloud security is the set of rules, tools, and practices used to protect your data, apps, and services stored online (in the "cloud"). It helps prevent data loss, hacking, and misuse of information.

Think of cloud security like locking the doors of your house. You wouldn’t leave your doors open for anyone to enter. And in the same way, your cloud account must be secured so that your data remains safe.

If your cloud services aren't secure, hackers could steal your data or cause major damage. Whether you're a business or just someone using cloud apps, keeping your information safe is essential.

Why is Cloud Security Important?

Cloud security matters because it ensures that only the right people have access to your information. It protects your data from being lost, stolen, or misused. With good security in place, your applications can run safely without being exposed to attacks.

It also helps you keep your personal or business data private. When your cloud environment is well-protected, the risk of data breaches and financial loss is greatly reduced.

Now that you understand why cloud security is important, let’s look at how AWS helps you stay secure and what your own role is in keeping things safe.

Key Cloud Security Concepts

In AWS, cloud security is the responsibility of both AWS and the customer. This model is called the Shared Responsibility Model.

Before learning how AWS divides security duties, you need to understand that AWS protects its infrastructure, but you must protect your own account.

When you create a new AWS account, you start with what is called the root user. The root user has full control, but it’s risky to use it for daily work. You should only use it to create another user, called an IAM (Identity and Access Management) user.

Here is what you should do:

Use the root user once to create an IAM user.
Do not use the root account for everyday work. Use IAM users instead.
The principle of least privilege should be followed—that is, a user should be given only the access they need.
Protect the root user by turning on a feature called MFA, or multi-factor authentication.

What is MFA?

MFA adds another layer of security when you sign in. It combines something you know, like your password, with something you have, such as a phone or security device. Even if someone gets your password, they cannot log in without your MFA code.

You can enable MFA in several ways:

Using a virtual MFA app like Google Authenticator or Authy
Using a physical security key such as a YubiKey
Using a hardware device from Gemalto
For AWS GovCloud users, using an MFA device from SurePassID

Always enable MFA for both your root and IAM users. It’s one of the simplest and most effective ways to protect your AWS account.

So now that you know these fundamentals, we can talk about the shared responsibility model.

Understanding the AWS Shared Responsibility Model

The AWS Shared Responsibility Model divides responsibilities between AWS and the customer.

1. AWS’s Responsibility (Security of the Cloud)

AWS is responsible for protecting the infrastructure that runs the services offered in the AWS Cloud. This includes physical security, hardware, software, networking, and facilities.

2. Customer’s Responsibility (Security in the Cloud)

The customer is responsible for securing the data, user accounts, applications, and configurations they store in the cloud.

Image source: AWS shared responsibility model

For example, AWS is responsible for securing its data centres and servers. But customers also have a role to play by properly configuring their accounts and resources.

Let’s take two popular AWS services, RDS (Relational Database Service) and S3 (Simple Storage Service), as examples.

RDS (Relational Database Service)

AWS responsibilities:

Automates database patching
Audits and maintains the underlying instance and storage disks
Applies operating system patches automatically

Customer responsibilities (you):

Manage in-database users, roles, and permissions
Choose whether your database is public or private
Review and control inbound rules, ports, and IP addresses in the database’s security group
Configure database encryption settings

S3 (Simple Storage Service)

AWS responsibilities:

Ensures encryption options are available for your data
Guarantees virtually unlimited storage capacity
Prevents AWS employees and the public from accessing your data
Keeps each customer’s data separated from others

Customer responsibilities (you):

Define your S3 bucket policies according to your security standards
Review bucket configuration settings
Create and manage IAM users and roles with the right permissions

Now you understand who’s responsible for what.

Conclusion

Security has always been about peace of mind. Whether it’s your home, your phone, or your cloud account, you want to know your data is safe.

AWS gives you a strong foundation by securing the cloud itself. But your part matters too, things like enabling MFA, using strong passwords, and managing who can access what. These simple habits go a long way in keeping your data protected.

Cloud security isn’t a one-time setup it’s an ongoing practice. When both AWS and its users stay alert, the cloud becomes a place you can trust to store, build, and grow with confidence.

Now that you understand how security works in AWS, you’re ready to dive deeper and start exploring the services that keep it all running smoothly.

For a deeper and clearer explanation, you can read the full guide here: Understanding Cloud Security in AWS

Other Resources

If you found this article helpful, feel free to share it. And if you prefer learning through videos, I also explain cloud topics in simple terms on my YouTube channel.

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

Thank you for reading!

Final AWS Re/Start Experience

Ijay — Tue, 25 Nov 2025 09:00:00 +0000

And it’s a wrap! 🎉💃

I can’t believe it's done and dusted! My AWS re/Start journey has been amazing, challenging, and so rewarding. Big shoutout to my coursemates and facilitator; you made this learning journey seamless and fun.

For anyone who wants to catch up, here’s my journey from Weeks 1–10. Weeks 11–12 are just revisions and wrapping up everything we’ve learned:

Here are my badges from AWS re/Start 🏅

AWS 🥂 you made cloud learning feel approachable, fun, and definitely not overwhelming.

Shoutout to CIL Academy you're the best

Oh! Before I forget, I also started a new YouTube channel where I share insights on cloud concepts. Check out my channel video: cloud-in-real-life

This isn’t an article or a blog post, just a quick thank you and update for you all.

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

More to come! 🥂

AWS re/Start – My Week 10 Experience

Ijay — Tue, 21 Oct 2025 09:00:00 +0000

Week 10 – Auto Scaling, Serverless, and Databases

Week 10

Like seriously—Week 10 already! 💃 I’m counting down because this journey hasn’t been easy, but I’m so grateful for my coursemates and the facilitator (Akeem Oyebanji). They make learning smoother and fun. Before you know it, it’ll be break time and then closing for the day. So cool!

Day 45

Today at Restart, we dove into Auto Scaling—trying to understand how it works and how to troubleshoot it. We got a surprise visit from the CTO of CIL Academy, Blessing U. Even though he could only stay for about 30 minutes, it was wonderful having him with us.
After that, we continued troubleshooting our servers to get a better grasp of auto scaling in real time.

Day 46

Lately, we’ve been doing a lot of debugging. It’s not just about theory anymore. Debugging helps us truly understand the concepts. Each issue we fix adds another layer of learning.

Day 47

Today at Restart, we started learning about serverless architecture. We explored how to use AWS Lambda to subscribe to an SNS topic. It was exciting to see how serverless makes automation easier.

Day 48

For today, our focus was on AWS Step Functions and how they simplify workflows by connecting multiple services together. It’s amazing how AWS tools make complex processes so seamless.

Day 49

Today at Restart, we talked about databases. In my Week 7 article, I wrote about this topic, but this time we went deeper—learning about services like Amazon Aurora and Redshift. We also discussed database migration using AWS DMS (Database Migration Service) and how to choose the right service for different needs.

My Week 10 Takeaway

This week felt like the bridge between what we’ve learned and how it all connects. From auto scaling to serverless and databases, everything is starting to click. Debugging has become part of my daily routine, and honestly, that’s how understanding truly grows.

Resources

Come say hi on Twitter and LinkedIn, or check out my work on GitHub.