Forem: abdullah haroon

Day 6: Why Vibe Coding Fails in Production (And How Kiro Helps to Fix It)

abdullah haroon — Mon, 18 May 2026 09:17:00 +0000

After building a project using Kiro’s spec-driven development workflow and comparing it with tools like Cursor and GitHub Copilot, one thing became very clear: AI coding itself is not the issue. The real problem is how we approach it.

Most developers today are unintentionally practicing what is now called “vibe coding”, a workflow where you rely heavily on AI prompts, quick iterations, and instant code generation without properly designing the system beforehand. It feels fast, flexible, and even powerful in the beginning. But when you try to take that same approach into production-level systems, the cracks start to show.

What Vibe Coding Actually Looks Like

Vibe coding usually starts with a simple prompt. You ask the AI to build something like a game, a dashboard, or a backend system, and it immediately generates working code. From there, you keep improving it step by step using follow-up prompts such as “fix this bug,” “add this feature,” or “make it cleaner.”

At first, this feels like rapid development. You are building fast, seeing instant results, and constantly moving forward. But the issue is that there is no real system design behind the code. Everything is being added reactively instead of being designed intentionally.

Why Vibe Coding Breaks in Production

The biggest problem with vibe coding is that it works only in the early stage. As the project grows, structure starts to break.

First, architecture becomes unclear because features are added through separate prompts, leading to inconsistent code organization. Second, context starts to degrade, and AI may lose track of earlier decisions. Third, complexity increases uncontrollably because everything is patched together instead of being designed properly. This is the point where projects start becoming hard to maintain.

My project Experience

I noticed this clearly while building Flappy Bird in Node.js. At the start, everything was smooth and fast. But as more features were added, the logic started overlapping, debugging became harder, and small changes affected other parts of the game. It felt productive at first, but over time, the lack of structure started creating problems.

How Kiro Changes the Workflow

Kiro solves this by introducing spec-driven development. Instead of jumping straight into prompts like “build Flappy Bird,” you first define a structured specification describing how the system should work.

In my case, I defined gameplay rules like gravity, pipes, scoring, and collision before any code was generated. Kiro then built the implementation based on that structure. This shifts development from reactive coding to intentional system design.

From Reactive to Structured Development

In vibe coding, you fix problems after they appear. In Kiro, you define the system first, and most issues never appear in the first place. This makes development more controlled, predictable, and structured.

Why Structure Matters More Than Speed

Most AI tools focus on speed, but speed without structure does not scale. Vibe coding works well for prototypes and experiments, but breaks down in larger systems because complexity grows too quickly. Kiro solves this by introducing structure before code exists

Final Thoughts:
AI development is evolving from fast code generation to structured system design.Copilot helps you write faster, Cursor helps you work with code, but Kiro helps you define systems before they are built. And that’s the key difference.

Vibe coding fails in production not because AI is weak, but because structure is missing from the process.

Day 5: Kiro vs Cursor vs GitHub Copilot (Real Developer Comparison)

abdullah haroon — Sun, 17 May 2026 08:00:00 +0000

After building a project in Node.js using Kiro’s spec-driven workflow, We started to clearly understand where Kiro stands in the AI development ecosystem. Up until now, I had used multiple AI coding tools in real projects: Cursor, GitHub Copilot, and now Kiro, but this was the first time I compared them from a workflow perspective, not just feature lists. And honestly, the difference is not just in “code quality.” It’s in how each tool shapes the way you think while building software.

Understanding the Three Tools First

Before comparing them, it’s important to understand what each tool is actually optimizing for.

GitHub Copilot is mainly focused on speed. It helps you write code faster inside your editor by suggesting completions as you type. It’s great for small improvements and boilerplate reduction, but it still depends heavily on your own structure.

Cursor takes things a step further. It’s more like an AI-native IDE where you can chat with your codebase. It understands context better than Copilot and allows more interactive development, especially for debugging and refactoring.

Kiro on the other hand, feels different. It is not just trying to help you write code faster, it is trying to enforce a development structure through spec-driven development.

That distinction is where everything starts to change.

Workflow Comparison (The Real Difference)

When I built a project in Node.js using Kiro, the workflow started with a spec. That single change affects everything downstream.

With Kiro, I first defined behavior, system design, and features before writing any code. The AI then generated implementation based on that structure.

In Cursor and Copilot, the workflow is more direct. You start coding or prompting immediately, and structure evolves naturally through iteration.

This difference might seem small, but it completely changes how your project grows over time.

Kiro forces intent-first development.
Cursor and Copilot encourage code-first development.

Code Structure and Architecture Handling

This is where the gap becomes very visible. With GitHub Copilot, code structure depends entirely on the developer. It is excellent at completing functions and reducing repetitive work, but it does not guide architecture decisions. Cursor improves this by understanding more of the project context. It can refactor files, explain logic, and assist in debugging across multiple files.

But Kiro goes one level higher, it tries to shape the architecture before the code even exists. Because everything starts from a spec, the structure is more intentional from the beginning. In my Node.js project, this was very noticeable. Kiro naturally separated game logic into clear modules instead of dumping everything into one file.

AI Interaction Style

The interaction style of each tool is also very different.

Copilot feels passive. It waits for you to write code and then predicts what comes next.

Cursor feels conversational. You actively discuss your codebase with the AI and iterate through changes.

Kiro feels directive in a different way. You are not just chatting or coding, you are defining system behavior through structured specifications, and the AI executes based on that. This makes Kiro feel less like an assistant and more like a system builder.

Debugging and Iteration

Debugging is where Cursor really shines. When something breaks, Cursor can analyze your project, suggest fixes, and even refactor multiple files at once. It feels very practical for real-world development.

Copilot is weaker here because it does not fully understand project-wide context.

Kiro approaches debugging differently. Instead of directly patching code, you often go back and refine the spec. The system then regenerates or adjusts implementation based on updated requirements.

Speed vs Structure vs Control

Each tool optimizes for something different.

Copilot optimizes for speed of writing code.
Cursor optimizes for interactive development and debugging.
Kiro optimizes for structured system design through specs.

When we used them in real projects, this difference became very clear.

If you want quick code snippets, Copilot is enough.
If you want full project-level AI assistance, Cursor is very strong.
If you want structured AI-native development, Kiro feels more forward-thinking.

Final Outcome

After using all three tools in real development scenarios, we realized they are not direct replacements for each other. They represent different stages in the evolution of AI-assisted development.

Copilot represents the first phase: autocomplete intelligence.
Cursor represents the second phase: conversational coding.
Kiro represents a third phase: structured AI-native development.

And that third phase is what makes Kiro interesting.

It is not trying to replace developers.It is trying to change how developers think before they even write code.

Day 4: Building Your First App with Kiro (Step-by-Step AI Development)

abdullah haroon — Sat, 16 May 2026 07:33:00 +0000

Over the last few days, I’ve been exploring Kiro and trying to understand what makes it different from the growing number of AI coding tools entering the market. At first, I thought it was simply another AI-powered IDE focused on faster development and better code generation.

But after building a real project with it, I realized the bigger idea behind Kiro is not just speed, it’s structure.

So for Day 4 of this series, I decided to build something more interactive and fun instead of another basic CRUD application. I chose to build a simple Flappy Bird clone using Kiro to properly test how spec-driven development actually feels in a real workflow. The goal wasn’t just to “build a game with AI.”

The real goal was to experience how spec-driven development in Kiro actually behaves in a real project. And this is where things started to feel different from traditional AI coding tools.

Why I Chose Flappy Bird

I intentionally picked Flappy Bird because it’s deceptively simple.On the surface, it looks like a small beginner game, but technically it includes several important development concepts:

Game physics
Collision detection
Animations
Rendering loops
User input handling
State management
Score systems

That makes it a perfect project for testing how well Kiro handles structured implementation and iterative development.

Most AI tools perform well when generating static pages or small components. But interactive systems are where workflows usually become messy. Context gets lost, features break, and the generated architecture slowly turns chaotic. That’s exactly what I wanted to test with Kiro.

Starting with Spec-Driven Development in Kiro

The first step was not coding at all.I started inside Kiro using its spec-driven development workflow, where you define system behavior first and only then move toward implementation. This is very different from traditional AI coding where you directly ask:

“Build Flappy Bird in Node.js”

Instead, Kiro pushes you to first define what the system is supposed to do.That shift alone changes how you think about development.

Writing the Node.js Game Specification

Inside Kiro, I created a structured spec for the Flappy Bird game. Here’s what I defined:

Build a Flappy Bird game using Node.js with the following behavior:

- Bird affected by gravity (physics simulation)
- Jump mechanic using key press input
- Pipe generation with random gaps
- Continuous movement loop
- Collision detection system
- Score increases when passing pipes
- Game over state when collision occurs
- Restart functionality
- Real-time game loop execution

Instead of thinking in terms of files or functions, I was thinking in terms of system behavior. That’s the key idea behind spec-driven development. You define what the system should do, and Kiro translates that into structure and implementation.

How Kiro Structured the Node.js Implementation

Once the spec was finalized, Kiro didn’t jump into dumping code. Instead, it broke the system into logical modules and components.The Node.js implementation was structured around:

game loop handling
physics engine logic (gravity + movement)
pipe generation system
collision detection module
score tracking system
input handling (keyboard events)

This separation was very important because it prevented the usual problem of AI-generated “single-file chaos.” In traditional vibe coding, Node.js projects often become messy quickly because everything gets merged into one script. Here, the structure stayed clean and understandable.

Generating the First Working Version

After processing the spec, Kiro generated the first working version of the game logic. Even though it was running in a Node.js environment, the core mechanics were already functional:

bird movement simulation
gravity behavior
pipe spawning logic
collision detection
score updates

What impressed me most was not just that it worked, but that it worked in a structured way. The system wasn’t random, it followed the spec I had defined earlier. That connection between intent → spec → implementation was very clear.

What Felt Different Compared to Vibe Coding

This project made the difference very obvious. In traditional vibe coding workflows:

you prompt repeatedly
code structure breaks over time
debugging becomes harder
context is often lost
Node.js files quickly turn messy

But with Kiro’s spec-driven approach:

structure stays stable
changes are intentional
system design remains consistent
iteration is predictable

Instead of constantly fixing broken outputs, you are refining a system definition. That is a completely different mindset.

Final Result

By the end of this project, I had a working Flappy Bird-style game logic built in Node.js using Kiro’s spec-driven workflow. It included:

gravity-based physics
pipe generation system
collision detection
score tracking
restart logic

But the real outcome was not just the game. It was understanding how structured AI development changes the entire workflow from coding to system design.

When you combine Node.js with structured specs, AI stops being a generator and starts becoming a development partner.

Day 3: Understanding Spec-Driven Development (The Core Idea Behind Kiro)

abdullah haroon — Thu, 14 May 2026 07:16:00 +0000

Welcome back to the Kiro Blog Series: From Zero to AI-Native Development.

In the first two days, We installed Kiro, explored the environment, and built a simple first project. That part was mostly about getting comfortable with the tool.

But today is different. Today is about understanding the core idea behind Kiro spec-driven development.

What is a Spec, Really?

A spec is a structured description of what you want to build. It is not just documentation, it is the starting point of development.

Instead of jumping into code, you define your intent in natural language, and that becomes the foundation for everything else.

For example:

A simple to-do application where users can add tasks, delete tasks, and mark them as completed, with data stored locally.

This helps readers visually connect what a “spec” looks like inside Kiro.

Traditional Development vs Spec-Driven Development

In traditional development, the workflow usually starts with setup and structure.You choose frameworks, create folders, install dependencies, and only then start building features.

This shows “old way” complexity visually.

So the flow looks like: idea → setup → architecture → coding → debugging

In spec-driven development, the order changes. You start with intent instead of structure.

idea → spec → structured generation → refinement

(This image is AI generated highlighting how KIRO works)

This is the “wow moment” image where Kiro turns spec into structure.

Why Specs Are More Important Than They Look

At first, a spec looks like just a description. But it actually plays multiple roles at once. It communicates intent, forces clarity of thinking, and helps generate structure automatically. Below is a visual representation of vague vs detailed specs.

What I Noticed While Using Kiro

One important thing became very clear while using Kiro.The quality of output depends heavily on how clear the spec is. Better spec → better structure → better result.

This is your proof that the system actually works.

Key Mindset Shift

Writing code is no longer the first step. Thinking clearly is.

Instead of asking: “How do I build this?”

You start asking: “What exactly am I building?”

Coming Next on Day 4: Next, We will take this concept and build a real application using Kiro step by step.

Day 2: Installing & Getting Started with Kiro

abdullah haroon — Wed, 13 May 2026 07:05:00 +0000

Welcome back to the Kiro Blog Series: From Zero to AI-Native Development.

In Day 1, we explored what Kiro is and why it represents a shift toward spec-driven development. Today, we move from ideas into actual setup and hands-on experience.

The goal is simple, install Kiro, understand how it feels, and build your first working project without getting stuck in setup confusion.

Why Setup Matters (But Shouldn’t Be Complicated)

Most developers don’t fail because a tool is hard. They fail because the first 10 minutes are confusing.Too many steps, too many decisions, and too much boilerplate before anything actually works. Kiro tries to remove that friction. The idea is simple:

If you can describe what you want, you should be able to start building immediately.

First Look at Kiro

When you first install and open Kiro, the experience feels familiar if you’ve used modern IDEs like VS Code. But there’s a clear difference in focus.

Instead of overwhelming you with files and configurations, Kiro opens into a clean, minimal workspace. The AI layer is already integrated into the environment, sitting quietly beside your development flow, not interrupting, just assisting when needed.

Creating Your First Project

Once you’re inside Kiro, the next step is creating your first project. This is where the experience starts to feel different from traditional development tools.

Instead of manually setting everything up, you simply create a new project, give it a name, and choose a basic template or blank setup. Kiro takes care of the rest in the background.

It automatically prepares the structure, configuration, and environment so you can focus on what actually matters is the idea.

Writing Your First Spec

Now comes the most important moment of today, writing your first spec.

Instead of starting with code, you describe your application in natural language. For example, you might say:

A simple to-do app where users can add tasks, delete them, mark them as completed, and store data locally.

This is where Kiro’s approach becomes different. You are no longer telling the system how to build something, you are telling it what you want.

What Happens After You Submit the Spec

Once you submit the spec, Kiro starts working in the background. It breaks your idea into structured features, understands the requirements, and begins shaping a technical plan.

Then it generates the base structure of your application — including files, logic, and initial implementation. Instead of you manually building everything step-by-step, Kiro builds the foundation for you.

Running Your First App

After everything is generated, you simply run the project and see it come to life. You now have a working application built directly from a simple idea written in plain language. It might be basic, but the important part is not complexity, it’s the workflow that got you there.

Key Takeaway

The biggest shift Kiro introduces is not just faster development, it’s a completely different mindset. Instead of starting with syntax, you start with intent. Instead of building everything manually, you guide the system through structured thinking. That is the foundation of spec-driven development.

What’s Next?

In Day 3, we’ll go deeper into the core idea behind everything we did today:

What exactly is a “spec”, and why is it becoming the new foundation of software development?

What is Kiro? The Beginning of Spec-Driven Development

abdullah haroon — Tue, 12 May 2026 10:27:53 +0000

For many years, software development has followed a familiar pattern: think of an idea, start coding, fix bugs along the way, and refactor when things break.

Then AI tools like Copilot and ChatGPT changed the game by making coding faster. But they also introduced a new problem, speed increased, but structure often decreased.

This is where Kiro comes in.

What is Kiro?

Kiro is an AI-native development environment built around a powerful idea:

Spec-Driven Development

Instead of jumping directly into code, Kiro encourages developers to start with clear specifications, structured planning, and AI-assisted breakdown of requirements before writing a single line of code.

In simple terms:

Kiro doesn’t just help you write code
It helps you define what you are actually building

The Problem Kiro is Solving

Modern development has shifted into a new era but not without challenges.

1. Vibe Coding Overload

Developers often rely on intuition:

“just make it work”
“fix this error quickly”
“add this feature fast”

It’s fast but not always scalable.

2. AI Code Generation Without Structure
AI tools can generate working code instantly, but:

architecture becomes unclear
requirements drift over time
debugging becomes harder
systems become inconsistent

The result? Fast development, but fragile systems.

Kiro’s Approach: Spec-Driven Development

This is the game changerKiro introduces a structured workflow:

Instead of: Code → Fix → Refactor

You move to: Spec → Design → Generate → Refine

This means:

_- You define requirements clearly first

AI breaks them into structured components
Code becomes the output, not the starting point_

Why This Matters

This shift is important because:

Software systems are getting more complex
AI is generating more code than ever
Developers need structure, not just speed

What This Series Will Cover

This is Day 1 of a 10-part journey into Kiro.

In the upcoming posts, we will explore:

How to install and start using Kiro
How spec-driven development actually works in practice
Building real-world projects step by step
Comparing Kiro with tools like Cursor and Copilot
How it fits into the future of AI-driven engineering

Final Thought

Kiro is not just another AI coding tool.

It represents a shift in how we think about software development:

From “writing code faster”
To “building software more intelligently”

And that shift is what this series is all about.

Next: Day 2 → Getting Started with Kiro (Installation + First Project)

What is Kiro? The Beginning of Spec-Driven Development

abdullah haroon — Tue, 12 May 2026 10:27:53 +0000

For many years, software development has followed a familiar pattern: think of an idea, start coding, fix bugs along the way, and refactor when things break.

Then AI tools like Copilot and ChatGPT changed the game by making coding faster. But they also introduced a new problem, speed increased, but structure often decreased.

This is where Kiro comes in.

What is Kiro?

Kiro is an AI-native development environment built around a powerful idea:

Spec-Driven Development

In simple terms:

Kiro doesn’t just help you write code
It helps you define what you are actually building

The Problem Kiro is Solving

Modern development has shifted into a new era but not without challenges.

1. Vibe Coding Overload

Developers often rely on intuition:

“just make it work”
“fix this error quickly”
“add this feature fast”

It’s fast but not always scalable.

2. AI Code Generation Without Structure
AI tools can generate working code instantly, but:

architecture becomes unclear
requirements drift over time
debugging becomes harder
systems become inconsistent

The result? Fast development, but fragile systems.

Kiro’s Approach: Spec-Driven Development

This is the game changerKiro introduces a structured workflow:

Instead of: Code → Fix → Refactor

You move to: Spec → Design → Generate → Refine

This means:

_- You define requirements clearly first

AI breaks them into structured components
Code becomes the output, not the starting point_

Why This Matters

This shift is important because:

Software systems are getting more complex
AI is generating more code than ever
Developers need structure, not just speed

What This Series Will Cover

This is Day 1 of a 10-part journey into Kiro.

In the upcoming posts, we will explore:

How to install and start using Kiro
How spec-driven development actually works in practice
Building real-world projects step by step
Comparing Kiro with tools like Cursor and Copilot
How it fits into the future of AI-driven engineering

Final Thought

Kiro is not just another AI coding tool.

It represents a shift in how we think about software development:

From “writing code faster”
To “building software more intelligently”

And that shift is what this series is all about.

Next: Day 2 → Getting Started with Kiro (Installation + First Project)

A short talk at AWS cloud club event "Cloud Nexus" made me rethink how students are using AI

abdullah haroon — Sun, 28 Dec 2025 05:22:11 +0000

I recently spoke at CloudNexus, an AWS Cloud Club QAU event focused on cloud technologies and AI. It was a short talk, nothing fancy, mainly around Agentic AI and how students are currently using AI tools.
What surprised me wasn’t the questions. It was how confident students were that they were “using AI correctly”. Most of them weren’t.

“I asked them to generate code from ChatGPT”
During discussions, a lot of students openly said they use ChatGPT mainly for code generation. Not for understanding. Not for learning concepts. Just for getting code quickly.
And honestly, I would not blame them for this. It’s very fast. It feels somehow productive. But this is where problems start showing up later during debugging, real projects, or even basic system design conversations or in interviews.

The issue isn’t AI: it’s how we’re using it
One thing I tried to explain during the talk was simple:
Not every AI tool is meant to do the same job.ChatGPT is great. I use it too. But it shines more when you use it for:

understanding concepts
breaking down ideas
writing or structuring content
asking “why” questions

When you try to use it as your main coding engine, you miss context and context matters a lot in real-world development.
Code-focused tools exist for a reason
We talked a bit about tools like Cursor, Amazon Q etc. Thesetools work inside your codebase. They understand files, references, and structure.That’s why they feel more useful for development work.
Not because they are “smarter AI”, but because they are built for developers.

Where Amazon Q fits in
Since this was an AWS-focused event, I also talked about Amazon Q. What I personally find interesting about Amazon Q is that it doesn’t live outside your workflow. It helps inside AWS environments, where cloud engineers actually spend time. It’s less about asking random questions and more about:

cloud-aware guidance
best practices
security-conscious suggestions

That difference matters when you move beyond tutorials.

Explaining Agentic AI in simple terms
To keep things simple, I explained AI in three phases:

Chatbots: you ask, it replies
Copilots: it understands your context
Agents: you give a goal, it figures out the steps Agentic AI is less about prompts and more about delegation.That idea really clicked with students.

Why the cloud becomes unavoidable here
One thing I emphasized was that agent-based systems don’t work in isolation.They need infrastructure, scale and security.

This is where platforms like AWS Bedrock start making sense, not as buzzwords only, but as enablers for building AI systems that actually run in the real world.

What I really wanted students to take away
If I would summarize the talk in one line, it would be this: AI should help you grow, not replace your thinking.

Use ChatGPT to learn.
Use coding copilots to build.
Use cloud AI to scale. And use agents when you’re ready to automate outcomes.

Final thought
Speaking at CloudNexus reminded me that students don’t need more tools.They need better guidance on how to use what already exists. There is a quote I read online saying:

AI isn’t going away.But engineers who understand how and why they use AI will always stand out.

here's the linkedin post for my recent talk:

#cloudnexus #cloudnative #agenticai #awsome #aws | Muhammad Abdullah Haroon | 13 comments

𝐆𝐫𝐚𝐭𝐞𝐟𝐮𝐥 𝐟𝐨𝐫 𝐭𝐡𝐞 𝐨𝐩𝐩𝐨𝐫𝐭𝐮𝐧𝐢𝐭𝐲 𝐭𝐨 𝐣𝐨𝐢𝐧 𝐂𝐥𝐨𝐮𝐝 𝐍𝐞𝐱𝐮𝐬 𝐚𝐭 Daftarkhwan vanguard 𝐚𝐬 𝐚 𝐰𝐢𝐥𝐝 𝐜𝐚𝐫𝐝 𝐞𝐧𝐭𝐫𝐲 𝐬𝐩𝐞𝐚𝐤𝐞𝐫 🙃 I had the chance to represent Cloud Native Islamabad and its ecosystem and share thoughts on emerging technologies and opportunities in Agentic AI and Cloud, with a special focus on how the Cloud Native Computing Foundation (CNCF) ecosystem (including CNI) is shaping the future of cloud-native engineering. Huge shoutout to Ali Mumtaz for organizing such a well-executed and impactful event Also, appreciation for Sharoon Amin Akhtar for sharing valuable insights on serverless cloud technologies. The panel discussion was equally engaging, featuring DevOps Molvi (Faisal Rehman), Hamza Nasir 🚀 Tameem Ud Din and Yahya Qureshi , great perspectives and practical discussions around DevOps and modern AI technologies. Lastly, thanks to my The Computer Science Society (CSS) AWS Cloud Club IIUI team for accompanying me Junaid Hanif Shah Murad Ali Shehzad Nazir Sardar Huzaifa Muhammad Sayyam Abbasi Shahzaib Ashraf Uzair Akhtar Gondal praying and best wishes to my mentor Saim Safder who didn't join us because of an incident.. Looking forward to more such conversations and collaborations #CloudNexus #CloudNative #AgenticAI #awsome #aws Amazon Web Services (AWS) AWS Developers Cloud Native Computing Foundation (CNCF) Audra Montenegro Lisa Bagley, CPACC | 13 comments on LinkedIn

linkedin.com

How to Launch Your First EC2 Instance on AWS (with Security Best Practices)

abdullah haroon — Wed, 23 Jul 2025 13:50:35 +0000

By Abdullah Haroon – Student | Cloud Practitioner| AWS Learner

What You’ll Learn

By the end of this guide, you’ll:

Understand what Amazon EC2 is
Launch your first virtual server using AWS Free Tier
Connect to it securely via SSH
Install a basic web server
Apply essential security practices for beginners

What is EC2?

Amazon EC2 (Elastic Compute Cloud) is AWS's virtual server service. It allows you to rent virtual machines (VMs) in the cloud where you can run applications, host websites, or learn Linux—all without buying hardware.

Think of it as your own personal server, available globally, just a few clicks away.

Common use cases:

Hosting websites & web apps
Deploying APIs and backend services
Machine learning & data processing
Practicing Linux/DevOps tools

What You Need

A free AWS account — Create one here
A stable internet connection
Basic knowledge of using terminal/command prompt

Step-by-Step guide: Launching Your First EC2 Instance

Step 1: Log in to the AWS Console

Go to https://console.aws.amazon.com/ and sign in.

Choose a region (e.g., US East - N. Virginia) at the top-right.

Step 2: Navigate to EC2

Click on Services
Search for EC2 and select it
In the EC2 Dashboard, click Launch instance

Step 3: Configure Your EC2 Instance

Name

Name: MyFirstEC2

AMI (Amazon Machine Image)

Choose: Amazon Linux 2023 (Free tier eligible)

Instance Type

Choose: t2.micro

Key Pair

Create a new key pair: ec2-key-abdullah
Select .pem
Download and store the file securely (you’ll need it to SSH)

Network Settings

Create a new security group
Allow SSH (Port 22) — Source: “My IP”
(Optional) Allow HTTP (Port 80) if installing a web server

Storage

Default 8 GB is fine

Click Launch Instance

Congratulations! Your instance is launching.

Step 4: Access Instance & Copy Public IP

Go to Instances > Running Instances
Wait until instance status is running
Copy the Public IPv4 address

Step 5: Connect to EC2 via SSH

On Linux/macOS:

chmod 400 ec2-key-abdullah.pem
ssh -i ec2-key-abdullah.pem ec2-user@<your-public-ip>

Step 5 (continued): Connect on Windows (Git Bash or WSL)

Same command as above:

chmod 400 abdullah-key.pem
ssh -i abdullah-key.pem ec2-user@<your-public-ip>

Step 6: Install Apache Web Server

Once logged in via SSH:

sudo yum update -y
sudo yum install httpd -y
sudo systemctl start httpd
sudo systemctl enable httpd

Now open your public IP in a browser — you’ll see the Apache test page!

Security Best Practices

Common Mistake	Best Practice
SSH open to all IPs (`0.0.0.0`)	Restrict to My IP only
Sharing `.pem` file with others	Keep it private and secure
Keeping unused instances running	Stop or terminate when not in use
Using root account always	Use IAM roles and least-privilege access

Troubleshooting Tips:

Permission denied (publickey)

chmod 400 abdullah-key.pem

SSH timeout or connection refused

Ensure Port 22 is allowed in your EC2 Security Group
Confirm you're using the correct public IP from the EC2 Console

Webpage not loading

Add a rule in your Security Group to allow HTTP (Port 80)

What You Achieved

You have successfully:

Launched a virtual server (EC2 instance)
Connected via SSH securely
Installed a working Apache web server
Followed essential cloud security steps

You’ve taken your first big step into the AWS Cloud! ☁️

Let’s Connect!

I’m sharing my AWS learning journey through beginner-friendly blogs.

Follow me for more hands-on tutorials and free-tier projects.

LinkedIn: https://www.linkedin.com/in/muhammad-abdullah-haroon-b49478271/
Dev Blog: dev.to: abdullah_haroon_092cf10d3

Getting Started with AWS: My Journey into Cloud Computing

abdullah haroon — Sun, 20 Jul 2025 17:22:37 +0000

Why I Chose to Learn AWS?
The world has become dynamic in terms of technology and cloud has become the base of any modern application. The cloud can be found everywhere, whether it is Netflix streaming programs or startups libraries implementing AI models. I found out that I would have to learn how the cloud functions in order to develop modern scalable solutions.

I found Amazon Web Services (AWS) among the leading cloud providers, and it was worthy of attention since:

It offers a massive range of services
It powers real-world applications at scale
It has a generous Free Tier for hands-on practice
It is newbie friendly and has an excellent learning material

My Learning AWS Objectives
Being a student and being interested in development and DevOps, I decided to invest my attention in AWS knowledge and cloud-native projects.

This is what I am going to do:

Learn the core AWS services (EC2, S3, Lambda, IAM, DynamoDB)
Build hands-on projects using the AWS Free Tier
Write and share blogs/tutorials to help others learn
Create a public GitHub portfolio of AWS-based projects

First What I Am Building
I have begun to create easy practical project to practice what I have learnt:

Launch an EC2 instance and host a personal page
Building a REST API using API Gateway, +Lamda + DynamoDB
Announce on CloudFront a S3 hosted static website
Auto backups to S3 with Lambda and EventBridge
Learn about IAM users and policies as well as roles to ensure safely access

These projects are centralized on the major areas such as compute, security, storage, and automation.

Learning AWS (Without Spending a Penny)
Here are the free resources I’m currently using that helped me get started:

Resource	Why I Use It
AWS SkillBuilder	Free official AWS training & learning paths
AWS Free Tier	Practice services like EC2, S3, Lambda at zero cost
freeCodeCamp AWS Series	Simple, beginner-friendly YouTube tutorials
AWS Educate	Extra credits and labs for students
Tutorials Dojo Blog	Easy explanations of tricky services

The reason Why I am Writing These Blogs
Blogging will assist me:

Reinforce what I learn
Share knowledge with others starting out
Document challenges and fixes
Build a portfolio and personal brand

I expect to simplify AWS so that beginners learn it easily, particularly other students who have no formal background in DevOps.

I'll be posting weekly AWS tutorials, cheat sheets, and beginner-friendly walkthroughs. If you’re learning cloud too, feel free to connect — I’d love to collaborate or just exchange ideas.

LinkedIn: https://www.linkedin.com/in/muhammad-abdullah-haroon-b49478271/

Blog: dev.to: abdullah_haroon_092cf10d3

Coming Next:

How to Launch Your First EC2 Instance with Security Best Practices

Thanks for reading! Let’s build together ☁️