DEV Community: Shehzad Ahmad

Launching My First AWS EC2 Instance — A Step-by-Step Walkthrough

Shehzad Ahmad — Fri, 25 Sep 2026 16:55:39 +0000

Introduction

As part of my hands-on learning in cloud and cybersecurity fundamentals, I decided to launch and configure my first AWS EC2 instance from scratch — including networking rules, storage, a bootstrap script, and remote access via SSH. This post walks through every step I took, along with the reasoning behind key configuration choices.

1. Instance Configuration

I started by selecting the AMI and instance type:

AMI: Amazon Linux 2023
Instance Type: t3.micro (Free Tier eligible)

Amazon Linux 2023 was chosen for its lightweight footprint and long-term AWS support, and t3.micro keeps things within Free Tier limits — ideal for learning and testing.

2. Storage Configuration

I attached two 8 GB EBS volumes to the instance for storage.

3. Bootstrap Script (User Data)

Under Advanced Details → User Data, I added a simple script to serve a "Hello World" page automatically on launch:

#!/bin/bash
dnf update -y
dnf install httpd -y
systemctl start httpd
systemctl enable httpd
echo "HELLO WORLD" > /var/www/html/index.html

touch file1.txt
mkdir dir1

This automates web server installation and setup so the instance is ready to serve content as soon as it boots — no manual SSH configuration needed for the basic page.

4. Security Group (Inbound Rules)

This is where network access control comes in. I configured the following inbound rules:

Type	Protocol	Port	Source
HTTPS	TCP	443	0.0.0.0/0 (Anywhere)
SSH	TCP	22	My IP

Why this matters: HTTPS is opened to everyone since the web page is meant to be publicly accessible, but SSH is restricted to My IP only — this is a basic but important security practice to prevent unauthorized remote access attempts from random IPs across the internet.

5. Launching the Instance

After reviewing the configuration, I launched the instance and downloaded the .pem key pair for SSH authentication.

6. Connecting via SSH

I used MobaXterm as my SSH client. Before connecting, I set the correct permissions on the key file:

chmod 400 instance32.pem

Then connected to the instance via SSH using the public IP along with the .pem private key file for authentication.

7. Verifying the Result

Finally, I opened the instance's public IP directly over HTTPS in the browser (no key file needed here — that's only required for SSH authentication) and confirmed the "Hello World" page was being served correctly.

Key Takeaways

Automating setup with User Data scripts saves manual configuration time on boot
Restricting SSH to a single IP while keeping HTTP/HTTPS open is a standard, practical security pattern
Always set correct permissions (chmod 400) on your .pem key before connecting — AWS/SSH will reject overly permissive key files
Free Tier resources (t3.micro, 8GB volumes) are more than enough for learning and small test deployments

This was a hands-on exercise as part of my ongoing cloud and cybersecurity learning journey. Feedback and suggestions welcome!

Cloud Computing & AWS: The Practical Guide I Wish I'd Had Starting Out

Shehzad Ahmad — Sun, 13 Sep 2026 04:26:08 +0000

Most people can explain what a website is. Almost no one can explain where it actually lives — or why that matters.

That's the gap cloud computing fills. And whether you're an engineer, a security professional, or someone in governance and risk trying to keep up with the technical side of the business, understanding how the cloud works isn't optional anymore. It's table stakes.

This guide breaks down cloud computing and AWS from the ground up — what it is, why it matters, how it's priced, how it's structured globally, and which core services actually matter.

Here's what we'll cover:

What cloud computing really is (beyond "someone else's computer")
The advantages that make it worth the shift
How AWS pricing actually works
AWS's global infrastructure model
The seven AWS services worth knowing cold
Why this matters even if you're not an engineer

Let's get into it.

Read AWS's official primer

☁️ 1. What Is Cloud Computing, Really?

Strip away the marketing, and cloud computing is simple: on-demand access to computing resources over the internet — compute, storage, databases, networking, software — without owning or maintaining the physical hardware behind it.

That's the whole idea. Everything else is implementation detail.

Traditional IT vs. Cloud Computing

Traditional IT	Cloud Computing
Buy physical servers	Provision resources on demand
Manage hardware and facilities yourself	Provider manages the infrastructure
Large upfront capital investment	Pay for what you actually use
Scaling means buying more hardware	Scaling is (mostly) a few clicks
Infrastructure lives in your building	Infrastructure lives in the provider's network

The model, in one diagram

flowchart LR
    A[User / Business] --> B[Internet]
    B --> C[Cloud Provider]
    C --> D[Compute]
    C --> E[Storage]
    C --> F[Databases]
    C --> G[Networking]

You focus on the product. The provider carries the weight underneath it.

💡 The real insight: Cloud computing isn't "online storage." It's a completely different operating model for IT — and once you see it that way, everything else makes more sense.

🚀 2. Why Smart Organizations Keep Choosing the Cloud

💰 Cost Efficiency

No massive upfront hardware spend. You provision what you need, when you need it. That said — cloud without cost discipline gets expensive fast. Adoption isn't the hard part. Governance is.

📈 Real Scalability

Picture an e-commerce brand ahead of a flash sale. On-prem, that's a hardware order placed months in advance. In the cloud, it's a capacity adjustment.

⚡ Speed to Market

Infrastructure that used to take weeks now takes minutes. That difference alone reshapes how fast teams can ship.

🌍 Global Reach, Built In

Cloud providers already operate infrastructure worldwide — meaning "going global" is a configuration decision, not a construction project.

🛡️ Security and Resilience — With a Catch

Cloud platforms hand you serious security tooling out of the box. But tooling isn't the same as security. How you configure it is what actually determines your risk.

🔄 Flexibility to Evolve

Business needs change. Cloud architecture can change with them, without a rip-and-replace every time.

Bottom line: Cloud computing = Flexibility + Scalability + Speed + Access to capabilities most teams could never build alone.

💳 3. How AWS Pricing Actually Works

Here's the part that trips people up: AWS doesn't have one price. It has hundreds of pricing structures, one per service, all running on a pay-as-you-go foundation.

What actually drives your bill

flowchart TD
    A[AWS Monthly Cost] --> B[Compute Usage]
    A --> C[Storage]
    A --> D[Database Resources]
    A --> E[Data Transfer]
    A --> F[Additional Service Usage]

The Pricing Models Worth Knowing

Model	What It Means
On-Demand	Pay as you go, no commitment
Savings Plans	Lower rates in exchange for a usage commitment
Reserved Instances	Discounts for long-term commitments on eligible services
Spot Instances	Cheap spare capacity — with the risk of interruption
Free Tier	Limited free usage for eligible services and accounts

Before You Deploy Anything, Ask:

What services does this workload actually need?
How much compute power?
How much storage?
What traffic should I expect?
Which Region makes sense — for latency, compliance, and cost?

The AWS Pricing Calculator turns those answers into a real estimate before you spend a dollar.

⚠️ The truth about cloud costs: They can absolutely be efficient. They can also spiral silently if nobody's watching. Cost optimization isn't a setting — it's a habit.

🌐 4. AWS Global Infrastructure, Simplified

Three concepts carry the entire model: Regions, Availability Zones, and Data Centers.

flowchart TD
    A[AWS Global Infrastructure] --> B[AWS Region]
    B --> C[Availability Zone 1]
    B --> D[Availability Zone 2]
    C --> E[One or more Data Centers]
    D --> F[One or more Data Centers]

🌍 Region

A geographic area with multiple Availability Zones. Choosing one comes down to:

Latency to your users
Service availability
Data residency rules
Compliance requirements
Disaster recovery strategy
Cost

🏢 Availability Zone

An isolated location inside a Region — one or more data centers. Spread your workload across multiple Availability Zones, and a single failure stops being a catastrophe.

🖥️ Data Centers

The physical layer: servers, storage, networking, power, cooling. AWS owns this. You own what you build on top of it — which brings us to shared responsibility (more below).

Why any of this matters

Get this right, and you get:

Higher availability
Better performance
Real disaster recovery
Painless geographic expansion
Long-term continuity

Here's the thing nobody tells beginners: Regions and AZs aren't AWS certification trivia. They're the backbone of every reliable architecture decision you'll ever make.

🧩 5. The Seven AWS Services Worth Knowing Cold

AWS has hundreds of services. You need seven to build a real foundation.

1. Amazon EC2 — Compute
Resizable virtual servers. Hosts websites, application servers, dev/test environments, enterprise workloads.

2. Amazon S3 — Storage
Object storage for files, backups, media, data lakes, static assets.

3. Amazon RDS — Relational Databases
Managed relational databases — built for business applications, transaction processing, e-commerce.

4. Amazon VPC — Networking
Your own isolated virtual network: subnets, route tables, security groups, ACLs, gateways. This is how you segment and control access.

5. AWS IAM — Identity and Access Management
Controls who can touch what. Non-negotiables:

Least-privilege access, always
Scoped roles over broad permissions
MFA enabled
Regular permission reviews

6. AWS Lambda — Serverless Compute
Code that runs on events — no servers to manage. Built for automation, event processing, scheduled jobs.

7. Amazon CloudWatch — Monitoring
Your eyes on the environment: metrics, logs, alerts, and the trail you need when something goes wrong.

At a glance

Service	Category	Primary Purpose
EC2	Compute	Virtual servers
S3	Storage	Object storage
RDS	Database	Managed relational databases
VPC	Networking	Virtual network
IAM	Security	Access management
Lambda	Compute	Serverless functions
CloudWatch	Monitoring	Metrics, logs, and alerts

🔗 6. Where It Clicks: Services Working Together

Individually, these services are useful. Combined, they're an architecture. Here's a simple web app:

flowchart TD
    A[Users] --> B[Application]
    B --> C[Amazon EC2]
    C --> D[Amazon RDS]
    C --> E[Amazon S3]
    F[Amazon VPC] -.-> C
    G[AWS IAM] -.-> C
    H[Amazon CloudWatch] -.-> C

EC2 runs the app. RDS holds the data. S3 stores the files. VPC, IAM, and CloudWatch quietly do the work of keeping it secure, controlled, and observable. Production environments layer in load balancing, backups, and disaster recovery on top — but this is the core pattern behind most cloud architectures you'll encounter.

🛡️ 7. Why This Isn't Just an Engineering Conversation

If you work in Governance, Risk, and Compliance, the cloud is now part of your job description whether or not it's in your title.

Ask yourself:

Access — Who can reach cloud resources, and how is that governed?
Data protection — How is sensitive information actually secured?
Logging — Can you investigate a security event when it happens?
Configuration — Are resources consistently and securely set up?
Compliance — Does the environment meet what regulators require?
Third-party risk — Where does AWS's responsibility end and yours begin?
Continuity — Can the business recover from a disruption?

The Shared Responsibility Model, in One Sentence

AWS secures the cloud. You secure what you put in it.

Cloud security was never going to be a "set it and forget it" problem. It's shared — and governance is what keeps that shared arrangement from becoming a shared liability.

🎯 The Takeaway

Cloud computing stopped being optional a while ago. It's the operating model for modern IT — on-demand infrastructure, real scalability, faster shipping, and access to capabilities that would be out of reach for most teams to build alone.

AWS is one of the biggest reasons that's true, with a service ecosystem spanning compute, storage, databases, networking, security, and monitoring.

Carry these forward:

Cloud computing is a model, not just a technology
The advantages are real — but so are the trade-offs
AWS pricing rewards intentional design, not guesswork
Regions and Availability Zones are the backbone of reliability
A handful of core services power most real-world architectures
Security and compliance are everyone's job, not just engineering's

Understanding the cloud isn't just a technical skill anymore. It's a foundation for anyone building — or protecting — modern digital infrastructure.

💬 What's one cloud concept you had to unlearn or relearn the hard way? Drop it in the comments — I'd genuinely like to know.

If this was useful, a ❤️, 🦄, or 🔖 helps it reach more people starting out on the same path.