DEV Community: Soumya Ranjan 🎖️

Pixel & Spoon Hands-On: Connecting to Your EC2 Instance 🔌

Soumya Ranjan 🎖️ — Tue, 14 Jul 2026 12:33:04 +0000

Chapter 5.1 — Hands-on companion to Chapter 5: EC2 — Your First Server in the Cloud. Your instance is running. Now let's actually get inside it.

Four Doors, One Server

When Aarav clicks the Connect button on his running EC2 instance, AWS shows him something that surprises most beginners.

Not one way to connect. Four.

○ EC2 Instance Connect
○ Session Manager
○ SSH Client
○ EC2 Serial Console

Each one is a different door into the same server. Different requirements, different use cases, different levels of security.

Pick the wrong one and you'll spend 20 minutes wondering why it isn't working.

Let's go through each one — what it is, when to use it, and how.

🚪 Door 1 — EC2 Instance Connect ✅ Start Here

What it is:
Connect directly from your browser. No terminal. No key file. No software to install. AWS handles authentication automatically.

Requirements:

✅ Amazon Linux 2023 or Ubuntu (which we're using)
✅ Instance must have a public IP
✅ Port 22 open in your security group

How to connect:

Step 1 — In the EC2 console, select your instance → click the Connect button at the top.

Step 2 — Make sure you're on the EC2 Instance Connect tab.

Step 3 — Username should already say ec2-user — leave it as is.

Step 4 — Click Connect.

A terminal opens right in your browser. You're inside Aarav's server.

Best for: Beginners, quick access, one-off tasks, anyone who doesn't want to deal with key files right now.

This is what we recommend for following along with this series.

Some basic commands you can try on it

# Check the OS version
cat /etc/os-release

# Check the hostname
hostname

# Check the current user
whoami

# Check the current directory
pwd

# List files in the current directory
ls -la

# resource usage
top

🚪 Door 2 — SSH Client — The Classic Way

What it is:
Connect from your own terminal using the .pem key file you downloaded when launching the instance. More control, works from anywhere, preferred by most developers once they get comfortable.

Requirements:

✅ Your pixelspoon-key.pem file (downloaded in Ch 05)
✅ Terminal — Mac/Linux uses built-in Terminal
              Windows uses PowerShell or PuTTY
✅ Port 22 open in security group

How to connect:

Step 1 — Open your terminal and navigate to where your .pem file is saved.

Step 2 — Set the correct permissions on the key file:

chmod 400 pixelspoon-key.pem

💡 chmod 400 makes the file read-only for you, and blocks access for everyone else. SSH refuses to run if your private key can be read by other users on your machine — it's a deliberate security check. Skip this step and you'll get a "WARNING: UNPROTECTED PRIVATE KEY FILE" error.

Step 3 — Connect using your instance's public IP:

ssh -i "pixelspoon-key.pem" ec2-user@YOUR_PUBLIC_IP

Find your public IP in the EC2 console — it's listed under Public IPv4 address on your instance details page. In Aarav's case: 3.110.196.57.

So his command looks like:

ssh -i "pixelspoon-key.pem" ec2-user@3.110.196.57

Step 4 — The first time you connect, SSH will ask:

Are you sure you want to continue connecting (yes/no/[fingerprint])?

Type yes and press Enter. This is normal — SSH is verifying the server's identity for the first time.

Best for: Developers who prefer working in their own terminal, automation scripts, repeated connections.

🚪 Door 3 — SSM Session Manager — No Open Ports

What it is:
Connect without opening port 22 at all. AWS Systems Manager creates a secure tunnel through AWS's own internal network — your connection never touches the public internet.

Requirements:

✅ SSM Agent installed (pre-installed on Amazon Linux 2023)
✅ IAM role with SSM permissions attached to the instance
✅ No open ports needed — not even port 22

Why this matters:

Every open port is a potential attack surface. Port 22 is the most targeted port on the internet — bots scan for it constantly and attempt brute force logins 24/7.

SSM Session Manager eliminates that attack surface entirely. No port open, nothing to scan, nothing to brute force.

This is the connection method used in production environments by teams that take security seriously.

How to set it up:

For SSM to work, your EC2 instance needs an IAM role with the AmazonSSMManagedInstanceCore policy attached. Remember IAM roles from Chapter 4.4? This is exactly that pattern — a service role for EC2.

We'll set this up properly in Chapter 6 when we cover IAM roles for EC2 instances. For now — know it exists, know it's the professional standard, and come back to it then.

Best for: Production servers, instances without public IPs, security-conscious setups, teams that want zero open ports.

🚪 Door 4 — EC2 Serial Console — The Emergency Exit

What it is:
Connects at the hardware level, bypassing the operating system entirely. Works even when the OS won't boot, the network is down, or the instance is completely unresponsive.

Requirements:

✅ Must be enabled at the AWS account level first
✅ Password-based auth must be configured on the instance

When you'd use it:

You won't need this often. Hopefully never.

But imagine this: Aarav pushes a bad config change that breaks networking on the server. The instance is running, but SSH times out, Instance Connect fails, SSM can't reach it. Everything is broken.

The Serial Console is the emergency override — the master key that works when all the normal doors are locked. It connects before the OS even finishes loading.

Best for: Debugging broken instances, recovering from misconfigurations, instances that won't respond to anything else.

🧭 Which One Should You Use?

Just starting out / following this series   →  EC2 Instance Connect
Prefer your own terminal environment        →  SSH Client
Production server, security-first           →  SSM Session Manager
Instance is broken and won't respond        →  EC2 Serial Console

For Pixel & Spoon right now — EC2 Instance Connect. Zero setup, works immediately, gets you inside in under 30 seconds.

✅ Once You're Connected

Whichever door you used, you'll land here:

   ,     #_
   ~\_  ####_        Amazon Linux 2023
  ~~  \_#####\
  ~~     \###|       Welcome, ec2-user
  ~~       \#/ ___
   ~~       V~' '->
    ~~~         /
      ~~._.   _/
         _/ _/
       _/m/'

[ec2-user@ip-172-31-xx-xx ~]$

That blinking cursor is your server, waiting for instructions.

You're now ready to follow the rest of Chapter 5 — cloning Pixel & Spoon's code and getting the ordering system live.

👉 Back to Chapter 5: EC2 → continue from "Getting the Code on the Server"

🗺️ Continue the Series

Ch 05 — ✅ EC2: Your First Server in the Cloud

Ch 05.1 — ✅ Connecting to Your EC2 Instance (you are here)

Ch 06 — EBS, AMI & Auto Scaling: The Complete Compute Picture

Resources I'm learning from:

roadmap.sh/aws — my learning roadmap
AWS Official Overview Whitepaper — straight from the source

EC2: Your First Server in the Cloud 🖥️

Soumya Ranjan 🎖️ — Mon, 06 Jul 2026 08:57:10 +0000

Chapter 5 of the AWS Learning Journey. The IAM arc is done. The team is set up. Now Pixel & Spoon needs a server — and two people are about to work together to make it happen.

Monday Morning at Pixel & Spoon

It's been a productive week.

The AWS account is locked down. Root account sitting in a vault with MFA. Aarav, Meera, and Rohit each have their own IAM users — their own badges, their own permissions, nothing more than what their jobs require.

Aarav is ready to build the ordering backend.

But he needs somewhere to run it.

He messages Rohit:

"Hey — can you spin up a server for me? I need something to deploy the ordering system on."

Rohit: "On it."

This is how real teams work. Aarav writes code. Rohit builds infrastructure. The separation isn't just cultural — it's enforced by the very IAM policies we set up in Chapter 4.3. Aarav's PixelSpoon-Developer-EC2 policy doesn't include ec2:CreateKeyPair, ec2:CreateSecurityGroup, or ec2:RunInstances. He literally cannot provision a server even if he wanted to.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "ec2:StartInstances",
        "ec2:StopInstances",
        "ec2:GetConsoleOutput",
        "ec2-instance-connect:SendSSHPublicKey"
      ],
      "Resource": "*"
    }
  ]
}

That's Least Privilege doing its job.

So today — we follow Rohit first. Then we hand the server to Aarav.

🔑 The IAM Sign-In URL — How the Team Logs In

Before anything gets built, let's fix something we glossed over in earlier chapters.

Every time we've opened the AWS console so far — we used the root account. That stops today permanently.

Each team member has their own IAM user and logs in through a dedicated URL that's specific to Pixel & Spoon's AWS account:

https://YOUR-ACCOUNT-ID.signin.aws.amazon.com/console

To find your account ID — log in to root one last time → click your account name top right → Account. The 12-digit Account ID is shown there.

Share that URL with your team. That's their front door. Not aws.amazon.com. That's for root only.

💡 You can make this URL friendlier by setting an account alias in the IAM dashboard. Instead of a 12-digit number, it becomes something like https://pixelspoon.signin.aws.amazon.com/console. Go to IAM → Dashboard → create alias on the right side.

For this chapter:

Rohit logs in as rohit-devops to provision the server
Aarav logs in as aarav-dev to connect and deploy the code
Root stays locked

🖥️ What Is EC2?

Before Rohit launches anything — let's make sure we know what he's actually about to create.

EC2 stands for Elastic Compute Cloud.

Elastic   →  Scales up or down based on demand
Compute   →  CPU, RAM — actual processing power
Cloud     →  Available over the internet, on AWS hardware

Remember Chapter 2 — virtualization? One physical server, sliced into many virtual machines by a hypervisor?

EC2 is that virtual machine. The one you rent. Running on AWS's physical hardware, in the Region you chose, isolated and yours alone.

In 1999, getting a server for Pixel & Spoon's ordering system would have taken weeks and cost lakhs before a single line of code ran on it. We covered that pain in Chapter 1.

Rohit will have one ready in under 10 minutes.

🧱 Three Decisions Rohit Makes Before Launching

Decision 1 — The AMI: What OS Does the Server Run?

An AMI (Amazon Machine Image) is the operating system template — the base layer everything runs on.

Rohit picks Amazon Linux 2023.

Why?

Built and optimised specifically for AWS
Free — no licensing cost
Pre-installed with the SSM agent (useful for secure connections later)
Most AWS documentation uses it — easier to troubleshoot

Decision 2 — The Instance Type: How Powerful?

t-series   →  General purpose, burstable performance
               Like a reliable everyday car — handles most tasks well,
               won't win a race but never lets you down
               Best for: web servers, APIs, small apps, learning
               ⭐ Rohit's choice: t3.micro — Free tier eligible ✅

c-series   →  Compute optimised, high CPU power
               Like a sports car — built for speed, not storage
               Best for: video processing, ML inference, game servers
               Example: c7g.large

r-series   →  Memory optimised, high RAM
               Like a moving truck — massive capacity, built to carry
               Best for: in-memory databases, large caches, analytics
               Example: r6g.large

m-series   →  Balanced CPU and memory, the production workhorse
               Like a reliable delivery van — good at everything,
               specialised at nothing
               Best for: production app servers, mid-size databases
               Example: m6i.large

Pixel & Spoon has zero users today. t3.micro is more than enough. When the app grows — Rohit can resize it. That's the elastic part.

Decision 3 — The Security Group: Which Ports Are Open?

A Security Group is the firewall around the EC2 instance. Every request that reaches the server passes through it first.

Least Privilege at the network level — only open what's actually needed.

Pixel & Spoon's backend needs exactly two ports:

Port 22    →  SSH access (for connecting to the server)
Port 3000  →  Node.js app (for users reaching the ordering system)

Not port 8080. Not port 443 "just in case." Not anything else.

Two ports. That's it.

The same principle from IAM policies applies here. Every unnecessary open port is an attack surface. Bots scan every public IP on the internet constantly — the smaller the surface, the safer the server.

🚀 Rohit Launches the Instance

Rohit logs in as rohit-devops.

Step 1 — Open EC2

Search EC2 in the console → check Region is ap-south-1 (Mumbai) → click orange Launch instance.

Step 2 — Name the Instance

pixel-spoon-backend

Lowercase, hyphens, descriptive. When Rohit is managing six instances at 2am, names matter.

Step 3 — Choose the AMI

Search Amazon Linux 2023 → select it → confirm the Free tier eligible badge.

Step 4 — Choose Instance Type

Select t3.micro — confirm Free tier eligible.

Step 5 — Create the Key Pair

Click Create new key pair.

Key pair name:  pixelspoon-key
Key pair type:  RSA
Format:         .pem

Click Create key pair — the .pem file downloads immediately.

⚠️ This file is shown once. There is no recovery. Rohit moves it to a secure location immediately — not Downloads, not the Desktop. A dedicated credentials folder, or better yet, an encrypted vault.

Rohit will share this with Aarav through a secure channel — a password manager or encrypted file share. Not Slack. Not email.

💡 Notice this step is done by Rohit, not Aarav. aarav-dev doesn't have ec2:CreateKeyPair in his policy — by design. Infrastructure credentials are DevOps territory. Aarav will use this key to connect, but he never created it. That's the separation working correctly.

Step 6 — Configure the Security Group

Under Network settings → click Edit.

Keep the default SSH rule (port 22). Add one more:

Type:        Custom TCP
Port:        3000
Source:      Anywhere (0.0.0.0/0)
Description: Pixel & Spoon Node.js ordering system

Two rules total. Done.

Step 7 — Launch

Leave storage at default 8GB → scroll down → Launch instance.

60–90 seconds. When Instance state shows Running — Pixel & Spoon's server is live.

🤝 The Handoff

Rohit's work is done.

He sends Aarav two things:

📋 Public IPv4 address:  (copy from EC2 console instance details)
🔑 pixelspoon-key.pem:   (shared via secure channel)

Now it's Aarav's turn.

💻 Aarav Connects — Browser First

Aarav logs in as aarav-dev.

He opens EC2, finds pixel-spoon-backend in the instances list, selects it, and clicks the orange Connect button.

He stays on the EC2 Instance Connect tab — username is ec2-user — clicks Connect.

A terminal opens in the browser.

A machine running in a data center in Mumbai, responding to commands from Aarav's laptop.

That blinking cursor is the moment cloud computing stops being a concept and becomes real.

💡 EC2 Instance Connect is the quickest way in — no key file needed,
works straight from the browser. But there are actually four ways
to connect to an EC2 instance — including SSH from terminal on
Mac, Linux, and Windows. We cover all of them in the companion post:

👉 Ch 5.1 — All Four Ways to Connect to EC2 → (Read it here)

📦 Aarav Deploys Pixel & Spoon's Code

The server is empty. The ordering system needs to get on it.

The right way — the way real teams do it — is Git. Code lives in
a repository, versioned and safe. The server pulls it with one
command. When the code changes, pull again.

First, install the dependencies:

sudo dnf update -y
sudo dnf install git nodejs -y

Then clone, checkout the Chapter 5 version, and run:

git clone https://github.com/srsoumyax11/pixel-and-spoon.git
cd pixel-and-spoon
git checkout ch05-start
npm install
npm start

Open a browser and go to:

http://YOUR_PUBLIC_IP:3000

In my case it is 65.2.130.72:3000

Screenshot of the Website I built

Pixel & Spoon's ordering system is live. On a real server.
On the real internet.

💡 Why git checkout ch05-start?

The repo grows alongside this series — by Chapter 12 it will
have auth, by Chapter 16 it will have Secrets Manager
integration. The ch05-start tag freezes the codebase at
exactly what Aarav deployed today — so this tutorial works
correctly no matter when you're reading it.

Each future chapter will have its own tag. You'll always know
exactly which version to run.

⭐ The Repo Behind This Series

The code Aarav just cloned is real — and you can use it yourself.

github.com/srsoumyax11/pixel-and-spoon

A fullstack Node.js server with two endpoints:

GET /        →  Pixel & Spoon's dynamic Server Side Rendered (SSR) ordering system
GET /health  →  Returns 
                {
                  "status": "ok",
                  "service": "pixel-spoon-backend",
                  "timestamp": "2026-07-06T08:10:24.199Z",
                  "uptime": 268.874721923,
                  "totalOrders": 0,
                  "version": "1.0.0"
                }

— confirms the server is alive

To use it:

Fork the repo to your own GitHub
Clone your fork onto your EC2 instance
Runs on port 3000 — no config needed

🌟 If this series has been useful — a star on the repo goes a long way.
It helps other learners find it and keeps the series going.

⭐ Star it here → github.com/srsoumyax11/pixel-and-spoon

💰 What Is This Costing?

t3.micro — 750 free hours per month for 12 months.

1 instance running 24/7   =  ~730 hrs/month  ✅ within free tier
2 instances running 24/7  =  ~1,460 hrs/month ❌ you pay for ~730

The habit to build now:

When done for the day — stop the instance. Not terminate. Stop.

EC2 console → select instance → Instance state → Stop instance.

Data preserved. Config saved. Compute cost: zero.

⚠️ The Problem Nobody Wants to Say Out Loud

Pixel & Spoon is live. The health check returns green. Aarav is proud.

But Rohit is quiet.

Because right now, everything runs on one server.

One EC2 instance. One point of failure. If it crashes at 12:30pm during the lunch rush — every order fails. Every user sees an error. Every minute costs real trust.

And if a food blogger features Pixel & Spoon tomorrow and ten thousand users hit the app at once? One t3.micro will buckle.

This isn't Aarav's problem to fix. It's an infrastructure problem. And it's exactly what Rohit is going to solve in Chapter 6 — persistent storage that survives crashes, AMIs to clone servers in minutes, and Auto Scaling to handle any traffic spike without anyone losing sleep.

🗺️ Where We Go From Here

Ch 00 — ✅ The origin story

Ch 01 — ✅ The world before AWS

Ch 02 — ✅ Virtualization & Cloud Models

Ch 03 — ✅ Welcome to AWS

Ch 04 — ✅ IAM: The Gatekeeper of AWS

Ch 04.1 — ✅ Creating IAM Users

Ch 04.2 — ✅ Creating IAM Groups

Ch 04.3 — ✅ Writing and Attaching IAM Policies

Ch 04.4 — ✅ Creating IAM Roles

Ch 05 — ✅ EC2: Your First Server (you are here)

Ch 05.1 — All Four Ways to Connect to EC2

Ch 06 — EBS, AMI & Auto Scaling: The Complete Compute Picture

Ch 07 — AWS CLI: Stop Clicking, Start Typing

Ch 08 — S3: Store Anything, Forever

Ch 09 — Databases on AWS: RDS & DynamoDB

Ch 10 — Serverless: Lambda, SNS & SQS

Ch 11 — Monitoring & Secrets: CloudWatch + Secrets Manager

Ch 12 — Networking: Route 53, CloudFront & VPC

Ch 13 — Infrastructure as Code: CloudFormation & Terraform

Ch 14 — Containers: ECS & EKS

Ch 15 — Billing & Pricing: Never Get a Surprise Bill

Ch 16 — Capstone: Build a Full Stack App on AWS

Ch 17 — AWS vs Azure vs GCP: An Honest Comparison

Ch 18 — What's Next: The AWS Certifications Roadmap

Before You Click Away.

Pixel & Spoon's server is running. The code is live. The health check is green.

But Rohit hasn't slept well since the launch.

One server. No redundancy. No way to survive a surge.

In Chapter 6, he fixes all of it.

👉 Chapter 6: EBS, AMI & Auto Scaling → (Read it here)

Resources I'm learning from:

roadmap.sh/aws — my learning roadmap
AWS Official Overview Whitepaper — straight from the source

Pixel & Spoon Hands-On: Creating IAM Roles 🎫

Soumya Ranjan 🎖️ — Thu, 02 Jul 2026 14:51:42 +0000

Chapter 4.4 — Hands-on companion to Chapter 4: IAM: The Gatekeeper of AWS. Users have logins. Groups have policies. But Karthik the auditor needs temporary access — and the CI/CD bot isn't even a human. Both need Roles.

The Problem Users Can't Solve

So far at Pixel & Spoon we have:

Permanent IAM users for Aarav, Meera, Rohit, and Subham
Groups that manage their permissions cleanly
Custom policies with only what each role needs

But two situations just came up that users and groups can't handle well.

Situation 1 — Karthik, the External Auditor

Pixel & Spoon needs a compliance audit. Karthik is brought in for one week. He needs read-only access to review the AWS setup.

You could create an IAM user for him. But then what? After the audit, you have to remember to delete it. Miss that, and there's a dormant login sitting in your account indefinitely — a security risk with no benefit.

Situation 2 — The CI/CD Bot

Pixel & Spoon's deployment pipeline automatically pushes new code to AWS every time Aarav commits an update. This process needs AWS access to do its job.

But it's not a person. It can't log in with a username and password. Hardcoding AWS credentials into the deployment script is the worst possible option — if that script ever leaks, your entire account is exposed.

Both situations need the same solution: IAM Roles.

🎫 What Makes Roles Different

Think back to Chapter 4's office building analogy.

Users are permanent employees with ID badges that don't expire.

Roles are visitor passes — temporary credentials issued for a specific purpose, that expire automatically, and can be assumed by whoever needs them at that moment.

👤 IAM User     →  Permanent identity, long-term credentials
                   Belongs to one specific person or system

🎫 IAM Role     →  Temporary identity, short-lived credentials
                   Can be assumed by users, services, or other accounts
                   Expires automatically — no cleanup needed

No hardcoded passwords. No forgotten logins. Clean, auditable, automatic.

🛠️ Part 1: Creating a Role for Karthik (Human Temporary Access)

We'll create a role that Karthik can assume for half a day, giving him read-only access to review Pixel & Spoon's setup.

Step 1 — Open IAM → Roles

Search IAM in the console → left sidebar → Roles → orange Create role button.

Step 2 — Choose Trusted Entity Type

You'll see four options for who can assume this role:

○ AWS service
     An AWS service like EC2 or Lambda assumes the role automatically.
     Used when your own infrastructure needs to talk to other AWS services.
     Example: a server that uploads files to S3 without hardcoded passwords.

○ AWS account          ← Karthik's option
     A person or system from another AWS account assumes the role.
     Used for external collaborators, auditors, or cross-team access.
     Example: Karthik logging in from his own company's AWS account.

○ Web identity
     Users who sign in via Google, Facebook, Amazon Cognito, etc.
     Used for mobile or web apps where end users need temporary AWS access.
     Example: a user logs into your app with Google and gets access to their own S3 folder.

○ SAML 2.0 federation
     Employees who sign in via a company identity system (like Okta or Active Directory).
     Used by large organisations that already have their own login infrastructure.
     Example: all 500 employees at a company use their work email to access AWS — no separate IAM users needed.

Karthik is from an external company with their own AWS account. Select AWS account.

Enter "Another AWS account" and type in Karthik's company AWS account ID.

💡 If Karthik doesn't have an AWS account, choose "This account" instead and you'll let him switch into the role from a temporary IAM user you create. For now we'll assume he has his own account.

Tick "Require MFA" — this means even after assuming the role, Karthik must have MFA active. Good practice for any external access.

Click Next.

Step 3 — Attach a Permission Policy

Search for and select:

ReadOnlyAccess

This is an AWS-managed policy that gives read-only access across all AWS services — Karthik can look at everything but change nothing. Perfect for an audit.

If You can not find it, Select AWSManaged - job-function Filter and then search for ReadOnlyAccess.

Click Next.

Step 4 — Name the Role

Role name:   PixelSpoon-Auditor-ReadOnly
Description: Temporary read-only access for external auditors.
             Requires MFA. Maximum session 12hours.

Click Create role.

Step 5 — Set the Maximum Session Duration

Click into the role you just created → Edit next to "Maximum session duration" → set it to 12 hours (the maximum AWS allows for role sessions).

This means Karthik's assumed session automatically expires after 12 hours. No manual cleanup required.

Step 6 — Share the Role ARN with Karthik

On the role summary page, copy the Role ARN — it looks like:

arn:aws:iam::563960656008:role/PixelSpoon-Auditor-ReadOnly

Send this to Karthik. He uses it to "switch roles" inside his own AWS console — his credentials stay his own, but he temporarily gains your role's permissions for the duration of the audit.

When the time is over, his session expires. Nothing to delete. Nothing to forget.

🤖 Part 2: Creating a Service Role for the CI/CD Bot

Now for the trickier one — the deployment bot.

This isn't a human assuming a role. It's an AWS service (in this case, we'll use EC2 as the example, since the bot runs on a server) that needs permission to deploy code to other AWS services.

Step 1 — Create Role → AWS Service

IAM → Roles → Create role → select AWS service.

Under "Service or use case," select EC2.

This tells AWS: "I want to create a role that an EC2 instance can assume."

Click Next.

Step 2 — Attach the Right Policy

The CI/CD bot needs to deploy code — which in Pixel & Spoon's case means pushing files to S3 and triggering deployments. Search for and attach:

AmazonS3FullAccess

For a real deployment pipeline you'd write a tighter custom policy (Least Privilege again), but for this walkthrough this gets us moving.

Click Next.

🤔 "Wait — why S3? Can't we just store the code directly on EC2?"

Quick context before we answer — if these terms are new to you:

EC2 is a virtual server on AWS — the machine that runs your code.
Think of it as a computer in the cloud. We cover it fully in Chapter 5.

S3 is AWS's storage service — like a hard drive in the cloud that
exists independently of any server. We cover it fully in Chapter 8.

Now — back to the question.

Yes, you can store deployment files directly on EC2. In simple
setups, people do exactly that.

But here's the problem:

EC2 instances can be stopped, replaced, or terminated at any time —
especially once we add Auto Scaling in Chapter 6. When that happens,
everything stored locally on that instance is gone.

S3 lives outside any single server. Your files sit there safely,
and it doesn't matter how many EC2 instances come and go —
the files are always available.

Think of it like this:

EC2 is the chef. S3 is the pantry.
You don't store the ingredients inside the chef.

We'll cover both properly in their own chapters — for now,
just know this is exactly the kind of problem S3 was built to solve.

Step 3 — Name the Role

Role name:   PixelSpoon-CICD-DeployRole
Description: Service role for CI/CD deployment bot.
             Assumed by EC2. Allows S3 deploy access.

Click Create role.

Step 4 — Attach the Role to Your EC2 Instance

When you launch the EC2 instance that runs the deployment bot (we'll do this properly in Chapter 5), there's an option called IAM instance profile — this is where you select PixelSpoon-CICD-DeployRole.

The instance then automatically receives temporary, rotating credentials for this role. No passwords. No access keys stored in code. AWS handles credential rotation completely.

🤖 CI/CD Bot (EC2 instance)
        │
        │  assumes role automatically
        ↓
🎫 PixelSpoon-CICD-DeployRole
        │
        │  grants permission to
        ↓
🪣 S3 Bucket  →  deploys files

This is considered the gold standard for giving AWS services access to other AWS services. You'll see this pattern everywhere as the series progresses.

✅ Where Pixel & Spoon Stands Now

The IAM setup is complete. Here's the full picture:

🏢 Pixel & Spoon — AWS Account

🔒 Root account          →  Locked with MFA. Used for emergencies only.

👥 Developers Group      →  PixelSpoon-Developer-EC2 policy
        └── aarav-dev
        └── subham-dev

👥 Designers Group       →  AmazonS3FullAccess
        └── meera-design

👥 Admins Group          →  AdministratorAccess
        └── rohit-devops

👤 divya-intern          →  PixelSpoon-Intern-ReadOnly (direct attach, temp)

🎫 PixelSpoon-Auditor-ReadOnly    →  For Karthik, expires in 12 hours
🎫 PixelSpoon-CICD-DeployRole     →  For the deployment bot, assumed by EC2

Every identity has exactly the access it needs. Nothing more.

That's Least Privilege — applied end to end across a real team.

🗺️ Continue the Hands-On Series

Ch 4.1 — ✅ Creating IAM Users

Ch 4.2 — ✅ Creating and Managing IAM Groups

Ch 4.3 — ✅ Writing and Attaching IAM Policies

Ch 4.4 — ✅ Creating IAM Roles: Human & Service (you are here)

The IAM arc is complete. Pixel & Spoon's account is secured, organised, and ready to actually build something.

Aarav has been waiting patiently. It's time to give him a server.

👉 Chapter 5: EC2 — Your First Server in the Cloud → (Read it here)

Resources I'm learning from:

roadmap.sh/aws — my learning roadmap
AWS Official Overview Whitepaper — straight from the source

Pixel & Spoon Hands-On: Writing and Attaching IAM Policies 📜

Soumya Ranjan 🎖️ — Thu, 02 Jul 2026 06:33:25 +0000

Chapter 4.3 — Hands-on companion to Chapter 4: IAM: The Gatekeeper of AWS. Aarav has EC2 access — but do we really know what that means? Today we open the policy, read what's inside, and write a tighter one.

The Policy We've Been Ignoring

In Chapter 4.1, we attached AmazonEC2FullAccess to Aarav.

In Chapter 4.2, we moved that to the Developers group.

But here's something we haven't done yet — actually looked at what AmazonEC2FullAccess allows.

Spoiler: it's a lot.

AmazonEC2FullAccess lets Aarav start instances, stop instances, terminate instances, create snapshots, modify security groups, allocate elastic IPs — essentially everything you can do with EC2.

Right now, Pixel & Spoon is a small startup. Aarav is trustworthy. It's fine.

But what happens when the team grows? What if you hire a junior developer who should only be able to view servers, not terminate them? Or a contractor who needs to start and stop instances, but never delete anything permanently?

AWS-managed policies like AmazonEC2FullAccess are broad by design — they cover everything in a service. Custom policies let you grant exactly what someone needs, nothing more.

That's what this chapter is about.

📜 What's Actually Inside a Policy?

Before we write one, let's read one.

In the AWS Console, search for IAM → click Policies in the left sidebar → search for AmazonEC2FullAccess → click on it → click the JSON tab.

You'll see something like this (simplified):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:*",
      "Resource": "*"
    }
  ]
}

Let's read this in plain English:

"Version"    →  The policy language version. Always "2012-10-17". Don't change this.

"Statement"  →  A list of permission rules. One policy can have many statements.

"Effect"     →  "Allow" or "Deny". This one allows.

"Action"     →  What is being allowed. "ec2:*" means every EC2 action — all of them.

"Resource"   →  Which specific resources. "*" means all resources, no restrictions.

So AmazonEC2FullAccess in plain English says:

"Allow everything EC2 can do, on every resource, with no conditions."

That's powerful. Too powerful for a junior developer.

🛠️ Step-by-Step: Creating a Custom Policy

Let's create a policy called PixelSpoon-Developer-EC2 that gives Aarav only what he actually needs day-to-day:

View all instances ✅
Start and stop instances ✅
Connect to instances ✅
Terminate instances ❌ (too destructive — requires deliberate action)
Modify security groups ❌ (that's Rohit's job)

Step 1 — Open IAM → Policies

Search IAM in the console → left sidebar → Policies → orange Create policy button.

Step 2 — Switch to the JSON Editor

At the top of the policy editor, click the JSON tab.

Clear what's there and paste in this custom policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "ec2:StartInstances",
        "ec2:StopInstances",
        "ec2:GetConsoleOutput",
        "ec2-instance-connect:SendSSHPublicKey"
      ],
      "Resource": "*"
    }
  ]
}

What each action does:

ec2:Describe*                        →  View/list any EC2 resource (instances, AMIs, etc.)
ec2:StartInstances                   →  Power on a stopped instance
ec2:StopInstances                    →  Power off a running instance
ec2:GetConsoleOutput                 →  Read the instance's console log for debugging
ec2-instance-connect:SendSSHPublicKey →  Connect via browser-based EC2 Instance Connect

💡 Notice ec2-instance-connect is a separate service prefix from ec2 — it's easy to assume it lives under ec2: but AWS treats Instance Connect as its own service in IAM. This is a common mistake that causes "access denied" errors even when EC2 permissions look correct.

Notice what's not in the list — ec2:TerminateInstances, ec2:AuthorizeSecurityGroupIngress, ec2:DeleteSnapshot. Aarav simply can't do those things, even accidentally.

Click Next.

Step 3 — Name and Describe the Policy

Policy name:   PixelSpoon-Developer-EC2
Description:   EC2 access for Pixel and Spoon developers. View, start, stop, and connect only. No termination or security group modifications.

A good description matters — six months from now, you or someone else will look at this policy and need to understand what it does without decoding the JSON.

Click Create policy.

🔁 Attach the New Policy to the Developers Group

Now let's swap out AmazonEC2FullAccess from the Developers group and replace it with our tighter custom policy.

Step 1 — Go to IAM → User groups → click Developers.

Step 2 — Click the Permissions tab → click on the check box next to AmazonEC2FullAccess and click Remove to remove it.

Step 3 — Click Add permissions → Attach policies → search for PixelSpoon-Developer-EC2 → tick it → click Attach policies.

Or you can filter by type Customer managed policies to find it faster.

Done. Aarav now has exactly what he needs — and nothing that could cause an incident at 2am.

🧠 AWS Managed vs Customer Managed — When to Use Which

Now that you've written one custom policy, here's a simple rule of thumb:

AWS Managed Policies
     ✅ Great for getting started quickly
     ✅ Maintained and updated by AWS
     ❌ Often broader than you actually need
     Use for: prototypes, personal learning, non-critical access

Customer Managed Policies
     ✅ Exactly the permissions you define
     ✅ Reusable across users, groups, and roles
     ✅ Auditable — you know exactly what's allowed
     ❌ Takes more time to write and maintain
     Use for: real teams, production environments, sensitive roles

At Pixel & Spoon, we'll keep AdministratorAccess on Rohit's Admins group for now — he's the only one in it and he genuinely needs broad access. But as the company grows, even that will get tightened.

🛠️ Try It Yourself

🛠️ Task: Write a read-only policy for Divya

Pixel & Spoon just brought on Divya as a data analytics intern.
She needs to VIEW EC2 instances and S3 buckets — but touch nothing.

Goal: Create a custom policy called PixelSpoon-Intern-ReadOnly
that allows only Describe/List/Get actions on EC2 and S3.

Hints:
- ec2:Describe* covers all EC2 viewing actions
- s3:GetObject, s3:ListBucket cover S3 read access
- Effect should be "Allow" on both
- Resource: "*" is fine for now

Then create an IAM user "divya-intern" and attach this policy directly
- remember to ad MFA
(she's temporary, so no group needed).
This is where IAM Role would be better, but we'll cover that in the next chapter.

Click to reveal the answer

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "ec2:Describe*",
                "s3:ListBucket"
            ],
            "Resource": "*"
        }
    ]
}

🗺️ Continue the Hands-On Series

Ch 4.1 — ✅ Creating IAM Users

Ch 4.2 — ✅ Creating and Managing IAM Groups

Ch 4.3 — ✅ Writing and Attaching IAM Policies (you are here)

Ch 4.4 — Creating IAM Roles: Human & Service

Next up — Karthik the auditor needs temporary access to Pixel & Spoon's AWS account. And the CI/CD bot needs to deploy code automatically without a human logging in. Both of these need Roles — not users, not groups.

👉 Chapter 4.4: Creating IAM Roles → (Read it here)

Resources I'm learning from:

roadmap.sh/aws — my learning roadmap
AWS Official Overview Whitepaper — straight from the source

Pixel & Spoon Hands-On: Creating and Managing IAM Groups 👥

Soumya Ranjan 🎖️ — Thu, 02 Jul 2026 04:01:41 +0000

Chapter 4.2 — Hands-on companion to Chapter 4: IAM: The Gatekeeper of AWS. In the last post, we gave Aarav, Meera, and Rohit their own IAM users. Today we fix the messy part — permissions managed properly through groups.

Where We Left Off

In Chapter 4.1, we created three IAM users for Pixel & Spoon's team:

aarav-dev — backend developer
meera-design — UI designer
rohit-devops — DevOps engineer

We attached policies directly to each user — which worked, but it's not how real teams manage access.

Here's why that approach breaks quickly.

Next month, Pixel & Spoon hires a second backend developer. You'd have to remember exactly which policies Aarav has, then manually replicate them on the new hire. Then again for the third. Then again when you decide all developers need an extra permission — and now you have to update every single developer's user one by one.

That's not scalable. That's not even fun.

IAM Groups fix this completely.

🗂️ The Idea in One Sentence

Instead of managing permissions per person — manage them per role.

Create a Developers group. Attach the right policies to it. Add Aarav to it. Done. When the second developer joins, just add them to the same group — they instantly have identical access, zero extra config.

❌ Without Groups

   aarav-dev       →   EC2FullAccess (manually attached)
   new-developer   →   EC2FullAccess (manually remembered and attached)
   another-dev     →   EC2FullAccess (manually attached again...)

✅ With Groups

   Developers Group  →  EC2FullAccess (attached once)
        │
        ├── aarav-dev         (inherits automatically)
        ├── new-developer     (inherits automatically)
        └── another-dev       (inherits automatically)

One policy. One place to update. Everyone in the group stays in sync.

🛠️ Step-by-Step: Creating the Developers Group

We'll create three groups for Pixel & Spoon — Developers, Designers, and Admins. Let's do Developers first and walk through it fully.

Step 1 — Open IAM

In the AWS Console search bar, type IAM and open the IAM Dashboard.

Step 2 — Go to User Groups

On the left sidebar, click User groups — not "Users." It's just below it.

Click the orange Create group button.

Step 3 — Name the Group

For the group name, use:

Developers

Keep names simple, role-based, and capitalised for clarity. You'll thank yourself when you have 10 groups and need to scan through them quickly.

Step 4 — Add Users to the Group

Scroll down to the "Add users to the group" section. You'll see a list of your existing IAM users.

Tick the checkbox next to aarav-dev.

That's it for now — we'll add future developers here too when they join.

Step 5 — Attach a Permission Policy

Scroll further down to "Attach permissions policies".

Search for:

AmazonEC2FullAccess

Tick it. This gives every member of the Developers group full access to EC2 — exactly what Aarav needs to build Pixel & Spoon's ordering backend.

💡 We're using AmazonEC2FullAccess for now because it's a clean AWS-managed policy that matches what Aarav's role requires at this stage. In Chapter 4.3, we'll look at writing tighter, custom policies when the default ones are too broad.

Click Create group.

🔁 Now Create the Other Two Groups

The process is identical — just different names, users, and policies.

Designers Group

Field	Value
Group name	`Designers`
Add user	`meera-design`
Attach policy	`AmazonS3FullAccess`

Meera needs S3 access to upload Pixel & Spoon's website assets, images, and frontend files. Nothing else.

Admins Group

Field	Value
Group name	`Admins`
Add user	`rohit-devops`
Attach policy	`AdministratorAccess`

Rohit is DevOps — he needs broad infrastructure access to keep everything running. AdministratorAccess is the most powerful AWS-managed policy. Treat group membership carefully here — only people who genuinely need full access belong in Admins.

🧹 Clean Up: Remove the Old Direct Policies

Remember in Chapter 4.1 we attached policies directly to each user as a temporary workaround?

Now that groups exist, those direct attachments are redundant — and having both can cause confusion later. Let's remove them.

Step 1 — In IAM, go to Users → click aarav-dev.

Step 2 — Click the Permissions tab. You'll see both the directly attached AmazonEC2FullAccess policy and the group-inherited one.

Step 3 — Click the X next to the directly attached policy to remove it.

If you donnt see the [x] button next to the directly attached, Remove the AmazonEC2FullAccess completly and then add the user again to the Developers Group.

Aarav still has EC2 access — now cleanly inherited from the Developers group, not attached twice.

Repeat for meera-design (remove direct S3 policy) and rohit-devops (remove direct AdministratorAccess).

✅ What Pixel & Spoon Looks Like Now

🏢 Pixel & Spoon — AWS Account

👥 Developers Group   →  AmazonEC2FullAccess
        └── aarav-dev

👥 Designers Group    →  AmazonS3FullAccess
        └── meera-design

👥 Admins Group       →  AdministratorAccess
        └── rohit-devops

🔒 Root account       →  Locked away with MFA

Clean. Organised. Scalable.

When Pixel & Spoon hires its next backend developer, you open the Developers group, add their user, and walk away. They have exactly the right access in under 30 seconds.

When you need all developers to also access Lambda (which we'll need later in the series), you add the Lambda policy to the Developers group once — and every developer gets it instantly.

That's the power of managing permissions through groups.

🛠️ Try It Yourself: Create a new user and add them to a group

Task: Pixel & Spoon just hired a second backend developer — Subham.
Goal: Create his IAM user and add him to the Developers group.

Steps:

Go to IAM → Users → Create user
- Username: subham-dev
- Enable console access
- Custom password + force reset on first login
On the permissions screen → Add user to group → select "Developers"
Click Create user and save his sign-in details

✅ Done! Subham now has EC2 access automatically — no extra policy needed.

🗺️ Continue the Hands-On Series

4.1 — ✅ Creating IAM Users

4.2 — ✅ Creating and Managing IAM Groups (you are here)

4.3 — Writing and Attaching IAM Policies

4.4 — Creating IAM Roles: Human & Service

Next up — the policies we've been attaching are all AWS-managed defaults. In Chapter 4.3, we look under the hood at what those policies actually say, and write a simple custom one that gives Aarav exactly what he needs — and nothing more.

👉 Chapter 4.3: Writing and Attaching IAM Policies → (Read it here)

Resources I'm learning from:

roadmap.sh/aws — my learning roadmap
AWS Official Overview Whitepaper — straight from the source

Pixel & Spoon Hands-On: Creating Your First IAM User 👤

Soumya Ranjan 🎖️ — Thu, 02 Jul 2026 02:39:11 +0000

A hands-on companion to Chapter 4 — IAM: The Gatekeeper of AWS. Today, we create Aarav's login so he can finally get to work.

Quick Recap

In Chapter 4, we talked about why Pixel & Spoon can't hand out the root password to every team member.

Aarav, our backend developer, needs his own identity inside AWS — his own login, his own permissions, his own activity trail.

That's an IAM user.

Let's create his.

⚠️ Before You Start

Log in to AWS using your root account for this one time only. Creating users is exactly the kind of task root should still handle, until you've created an admin IAM user for yourself later in this series.

🛠️ Step-by-Step: Creating Aarav's IAM User

Step 1 — Open IAM

In the AWS Console search bar at the top, type IAM and click on it. This opens the IAM Dashboard.

Step 2 — Go to Users

On the left-hand sidebar, click IAM Users.

Click the orange Create user button in the top right.

Step 3 — Enter User Details

For the username, use something clear and consistent. For Aarav, we'll use:

aarav-dev

A good convention is firstname-role or firstname.lastname — pick one and stick with it across your whole team, it'll make managing users much easier later.

Check the box for "Provide user access to the AWS Management Console" — Aarav needs to log in and use the console himself.

You'll then be asked how he should sign in. Choose "I want to create an IAM user", then select "Custom password" and set a temporary one. Tick "User must create a new password at next sign-in" — this way, Aarav sets his own password the first time he logs in, and you never actually know his real one.

Click Next.

Step 4 — Set Permissions

This is the important part.

You'll see three options:

○ Add user to group        ← Recommended (we'll set this up in Ch 4.2)
○ Copy permissions          ← Copies from an existing user
○ Attach policies directly  ← Manual, one-off permissions

Since we haven't created the Developers group yet (that's the very next post in this series), for now select "Attach policies directly" and search for:

AmazonEC2FullAccess

This gives Aarav exactly what he needs right now — the ability to launch and manage EC2 instances. Nothing more.

💡 In Chapter 4.2, we'll create a proper "Developers" group and move Aarav into it instead — so you're not managing his permissions individually forever. This step is just to get him working today.

Click Next.

Step 5 — Review and Create

You'll see a summary: username, console access enabled, and the policy attached.

Double check everything looks right, then click Create user.

Step 6 — Save His Sign-In Details

AWS will now show you a success screen with:

The console sign-in URL
Aarav's username
His temporary password

This password is shown only once. Download the .csv file or copy these details immediately and share them with Aarav through a secure channel — never over email or chat in plain text.

🔗 Sign-in URL:  https://[your-account-id].signin.aws.amazon.com/console
👤 Username:     aarav-dev
🔑 Temp Password: [shown once — save it now]

✅ What Just Happened

Aarav now has his own identity inside Pixel & Spoon's AWS account.

He can log in independently, using his own credentials. He has exactly the permission he needs — EC2 access — and nothing else. His actions inside AWS are now tracked under his own name, not the root account.

Repeat this exact process for Meera and Rohit — just give them appropriate temporary policies for now (we'll clean this up properly with groups next):

Meera → username meera-design → attach AmazonS3FullAccess

Rohit → username rohit-devops → attach AdministratorAccess (he's DevOps, he needs broad access)

🔒 One More Thing — Enable MFA for Every User

Just like we did for the root account in Chapter 4, every IAM user with real access should have MFA enabled too.

Click on the user → Security credentials tab → Assign MFA device, and follow the same authenticator app process from Chapter 4.

Do this for Aarav, Meera, and Rohit now. Five minutes per person, and it closes one of the biggest security gaps a growing team can have.

🗺️ Continue the Hands-On Series

This is the first of four hands-on companion posts for Chapter 4:

4.1 — ✅ Creating IAM Users (you are here)

4.2 — Creating and Managing IAM Groups

4.3 — Writing and Attaching IAM Policies

4.4 — Creating IAM Roles (Human & Service)

Next up — we fix that "attach policies directly" workaround properly by creating real Groups for Pixel & Spoon's team.

👉 Chapter 4.2: Creating and Managing IAM Groups → (Read it here)

Resources I'm learning from:

roadmap.sh/aws — my learning roadmap
AWS Official Overview Whitepaper — straight from the source

IAM: The Gatekeeper of AWS 🔐

Soumya Ranjan 🎖️ — Wed, 01 Jul 2026 07:09:58 +0000

Chapter 4 of the AWS Learning Journey. Meet Pixel & Spoon — the startup we'll be building alongside for the rest of this series. Today, we secure their AWS account before anything else gets built.

Meet Pixel & Spoon 🍱

Remember the food app idea from Chapter 0?

Let's actually build it.

Say hello to Pixel & Spoon — a small food-delivery startup. Order home-cooked meals from local cooks, delivered to your door. You're the founder.

It's early days. Right now it's just you and your AWS account, fresh out of Chapter 3, fully set up, billing alert active.

But you're about to hire your first team.

Aarav joins as your backend developer — he'll build the ordering system.
Meera joins as your UI designer — she'll build the website people see.
Rohit joins as your DevOps engineer — he'll keep the servers running.

It's day one. Everyone needs access to AWS to do their jobs.

So... what do you do?

Hand them your root account password?

Let's talk about why that would be a terrible idea.

🗝️ The Master Key Problem

Your root account — the one you created in Chapter 3 — isn't just powerful. It's all-powerful.

It can launch servers. Delete servers. Change billing. Close the entire AWS account. Access every single service, every single resource, with zero restrictions.

Now imagine giving that same password to Aarav, Meera, and Rohit.

Aarav only needs to write code and launch servers. But now he can also delete your billing information.

Meera only needs to upload images. But now she can also shut down the database.

If any one of their laptops gets compromised, or any one of them accidentally clicks the wrong button — your entire company's infrastructure is at risk.

🗝️  Root Account = Master Key

   Opens: Every door. Every room. The vault. The server room.
          The CEO's office. Everything.

   Given to: Everyone on the team, "just to be safe"

   Result: One mistake, one stolen laptop, one phishing email —
            and the entire building is compromised

This is exactly why companies don't run on root accounts.

This is exactly why IAM exists.

🛡️ What Is IAM?

IAM stands for Identity and Access Management.

Think of it as the security desk at Pixel & Spoon's office building.

Nobody walks straight into the server room. Everyone checks in at the front desk first. They get an ID badge. That badge only opens the doors they're actually supposed to access.

The marketing intern's badge doesn't open the server room.
The developer's badge doesn't open the finance office.
The cleaning staff's badge works after hours, but only for common areas.

That's IAM, in one sentence: it controls who can do what inside your AWS account.

Instead of handing out the master key, you create separate identities — one for each person — with only the access they actually need to do their job.

👤 IAM Users — Giving Everyone Their Own Badge

The first thing you do as Pixel & Spoon's founder is create IAM users for your team.

An IAM user is an identity inside your AWS account — their own username, their own password, their own access keys if they need programmatic access.

You create one for Aarav. One for Meera. One for Rohit.

Each one logs in separately. Each one's actions are tracked separately. If something goes wrong, you know exactly whose badge was used.

🏢  Pixel & Spoon's AWS Account

     👤 Aarav    →  IAM user "aarav-dev"
     👤 Meera    →  IAM user "meera-design"
     👤 Rohit    →  IAM user "rohit-devops"

     🔒 Root account →  Locked away, used only in emergencies

This alone is a massive security improvement. But we're not done — because creating three separate users with three separate sets of permissions, one by one, doesn't scale. What happens when Pixel & Spoon hires a second developer next month?

🛠️ Hands-on: Ready to actually create Aarav's, Meera's, and Rohit's IAM users? Follow along in Chapter 4.1 — Creating Your First IAM Users (Step by Step)

👥 IAM Groups — Badges That Come in Batches

This is where Groups come in.

Instead of configuring permissions individually for every person, you create a group — say, "Developers" — set the permissions once, and add people to it.

Aarav joins the Developers group. He instantly gets exactly the access a developer needs — EC2, Lambda, and related services.

Next month, Pixel & Spoon hires a second backend developer. You add them to the same Developers group. Done. Same permissions, zero extra configuration.

👥  Developers Group
     Permissions: EC2 (launch/manage servers), Lambda (deploy functions)
     Members: Aarav, [future developer hire]

👥  Designers Group
     Permissions: S3 (upload assets), Amplify (deploy frontend)
     Members: Meera

👥  Admins Group
     Permissions: Full infrastructure access
     Members: Rohit

Groups are how real companies manage access at scale. You're not thinking "what does this one person need" every time — you're thinking "what does this role need," and people simply join the group that matches their role.

🛠️ Hands-on: Want to set up the Developers, Designers, and Admins groups for real? That's covered in Chapter 4.2 — Creating and Managing IAM Groups.

📜 IAM Policies — The Actual Rulebook

So far we've said things like "Aarav gets EC2 access" — but how does AWS actually know what that means?

That's what a Policy is.

A policy is a document — written in JSON — that explicitly states what's allowed and what's denied. Every permission in IAM ultimately comes down to a policy attached to a user, a group, or a role.

Here's a simplified look at what a policy for the Developers group might say:

{
  "Effect": "Allow",
  "Action": [
    "ec2:StartInstances",
    "ec2:StopInstances",
    "ec2:DescribeInstances"
  ],
  "Resource": "*"
}

In plain English: "Allow this group to start, stop, and view EC2 instances. Nothing else."

Aarav can launch and manage servers. He cannot touch billing. He cannot delete IAM users. He cannot access Meera's S3 buckets unless explicitly permitted.

AWS also provides ready-made policies for common roles — so you rarely write these from scratch as a beginner. But understanding that every permission traces back to a policy document is what makes IAM click.

🛠️ Hands-on: Curious how to attach a real policy — or write a simple custom one? Walk through it in Chapter 4.3 — Writing and Attaching IAM Policies.

🎫 IAM Roles — The Visitor Badge That Expires

Now here's a trickier situation.

Pixel & Spoon hires Karthik, an external auditor, to review their AWS setup for a compliance check. He needs temporary access — just enough to look around, for just a few days.

You wouldn't create a permanent IAM user for someone who'll never log in again after next week. That's a badge nobody remembers to deactivate, sitting around as a security risk months later.

This is exactly what IAM Roles are for.

A role is temporary access — like a visitor badge at the front desk. It's issued when needed, has an expiry, and doesn't belong to any one permanent identity.

Roles aren't just for humans, either.

Pixel & Spoon also has a CI/CD bot — an automated system that deploys new code every time Aarav pushes an update. It's not a person. It can't "log in" with a username and password. Instead, it assumes a role — temporary credentials that let it do exactly its job (deploy code) and nothing else, refreshed automatically each time it runs.

🎫  IAM Role Examples at Pixel & Spoon

     Karthik (Auditor)  →  Temporary role, expires after 7 days
     CI/CD Bot          →  Service role, auto-refreshed credentials
     Rohit (on-call)    →  Can "assume" an emergency admin role
                            only during incidents, logged every time

This is also how different AWS services talk to each other securely — an EC2 instance can assume a role that lets it read from an S3 bucket, without anyone hardcoding a password anywhere. We'll see this in action when we reach EC2 and S3 later in the series.

🛠️ Hands-on: See how to create a temporary role for someone like Karthik, or a service role for the CI/CD bot, in Chapter 4.4 — Creating IAM Roles (Human & Service).

🔒 MFA — Locking the Front Door Properly

One more critical step before we move on.

Even with IAM users and groups set up properly, your root account still exists. And if someone gets your root password — through phishing, a data breach, or simple guessing — they have full control of Pixel & Spoon's entire AWS account.

This is where Multi-Factor Authentication (MFA) comes in.

MFA means logging in requires two things: your password, and a temporary code generated by an app on your phone (like Google Authenticator or Authy). Even if someone steals your password, they can't get in without your physical phone too.

Setting up MFA on your root account — do this right now:

Step 1 — Log in to the AWS console with your root user.

Step 2 — Search for "IAM" in the top search bar and open it.

Step 3 — On the IAM dashboard, you'll see a security recommendation to "Add MFA for root user." Click it.

Step 4 — Choose "Authenticator app," scan the QR code with Google Authenticator or Authy, and enter the two consecutive codes it generates.

Step 5 — Done. Your root account now requires your phone to log in, not just a password.

Do this for every IAM user too, especially anyone with elevated permissions — Rohit, in Pixel & Spoon's case, should absolutely have MFA enabled.

☂️ The Shared Responsibility Model

There's one more concept that ties everything in this chapter together — and it's one of the most commonly misunderstood ideas in cloud computing.

Who is actually responsible for security on AWS — Amazon, or you?

The answer is: both. Just different parts.

This is called the Shared Responsibility Model.

☁️  AWS is responsible for security OF the cloud:

     🏢  Physical data centers
     🔌  Networking infrastructure
     🖥️  The hardware running everything
     ⚡  Power, cooling, physical security of buildings

🧑‍💻  You are responsible for security IN the cloud:

     🔑  Who has access (IAM — this entire chapter)
     📂  How your data is configured and encrypted
     🔥  Firewall and security group rules
     🔓  Whether your S3 bucket is accidentally public

AWS will never accidentally leave your S3 bucket public. You might, if you misconfigure it.

AWS will never let an unauthorized person walk into their data center. But if you give Aarav root access "just to make things easier," and his laptop gets compromised — that's on your side of the responsibility line.

This single idea — knowing where AWS's job ends and yours begins — is the foundation of every security decision you'll make for the rest of this series.

🧩 Where Pixel & Spoon Stands Now

Let's recap what just happened at Pixel & Spoon.

The root account is locked away with MFA, used only for emergencies.

Aarav, Meera, and Rohit each have their own IAM user, grouped by role, with only the permissions their job actually requires.

Karthik gets temporary, expiring access through a role — not a permanent login.

The CI/CD bot deploys code automatically using a service role — no hardcoded passwords anywhere.

And everyone on the team — including you, the founder — now understands exactly where AWS's responsibility ends and Pixel & Spoon's begins.

This is the foundation every real AWS setup is built on. Skipping this chapter is how companies end up in security breach headlines.

🗺️ Where We Go From Here

Ch 00 — ✅ The origin story

Ch 01 — ✅ The world before AWS

Ch 02 — ✅ Virtualization & Cloud Models

Ch 03 — ✅ Welcome to AWS

Ch 04 — ✅ IAM: The Gatekeeper of AWS (you are here)

Ch 05 — EC2: Your First Server in the Cloud

Ch 06 — EBS, AMI & Auto Scaling: The Complete Compute Picture

Ch 07 — AWS CLI: Stop Clicking, Start Typing

Ch 08 — S3: Store Anything, Forever

Ch 09 — Databases on AWS: RDS & DynamoDB

Ch 10 — Serverless: Lambda, SNS & SQS

Ch 11 — Monitoring & Secrets: CloudWatch + Secrets Manager

Ch 12 — Networking: Route 53, CloudFront & VPC

Ch 13 — Infrastructure as Code: CloudFormation & Terraform

Ch 14 — Containers: ECS & EKS

Ch 15 — Billing & Pricing: Never Get a Surprise Bill

Ch 16 — Capstone: Build a Full Stack App on AWS

Ch 17 — AWS vs Azure vs GCP: An Honest Comparison

Ch 18 — What's Next: The AWS Certifications Roadmap

Before You Click Away.

The building is secure. The badges are issued. The front desk is staffed.

But before Pixel & Spoon builds anything — Aarav, Meera, and Rohit need their actual logins set up inside AWS.

Ready to do it yourself, step by step?

🛠️ Hands-on companion posts for this chapter:

👉 Ch 4.1 — Creating IAM Users → (Read it here)

👉 Ch 4.2 — Creating and Managing IAM Groups → (Read it here)

👉 Ch 4.3 — Writing and Attaching IAM Policies → (Read it here)

👉 Ch 4.4 — Creating IAM Roles: Human & Service → (Read it here)

Once the team is set up — it's time to actually build something.

Aarav has been waiting since the start of this chapter to write code
for the ordering system. But code needs somewhere to run.

In Chapter 5, we hand Aarav his first server — and you'll launch your
very first EC2 instance right alongside him.

This is the chapter where AWS stops being theory.

👉 Chapter 5: EC2 — Your First Server in the Cloud → (Read it here)

Resources I'm learning from:

roadmap.sh/aws — my learning roadmap
AWS Official Overview Whitepaper — straight from the source

Welcome to AWS: Infrastructure, Console & Free Tier 🌍

Soumya Ranjan 🎖️ — Tue, 30 Jun 2026 06:49:47 +0000

Chapter 3 of the AWS Learning Journey. Three chapters of context. Now we finally walk through the door.

The Door Is Open.

Chapter 0 - you understood why cloud exists.

Chapter 1 - you understood why the old world broke.

Chapter 2 - you understood how virtualization made cloud possible.

That's three chapters without touching AWS once.

And that was intentional.

Because most people open the AWS console on day one - see 200+ services staring back at them - and immediately feel lost.

You won't feel that way.

You already know what AWS is solving and how it works under the hood. Now we just need to learn the building - which floor things are on, where the entrance is, and how to not accidentally leave the lights on when you leave.

Let's go in.

🌍 How AWS Is Built: The Global Infrastructure

Before we log in, there's one thing worth understanding about how AWS is physically structured around the world.

Because AWS isn't one data center somewhere.

It's a global network - and understanding how it's organised will explain a lot of decisions you'll make later.

Regions 🗺️

A Region is a specific geographic location where AWS has built a cluster of data centers.

As of 2026, AWS has 39 Regions worldwide - places like US East (Virginia), EU West (Ireland), Asia Pacific (Mumbai), and so on.

When you launch a server on AWS, you choose which Region it lives in.

Why does this matter?

Two reasons:

Speed - The closer your server is to your users, the faster your app loads. If most of your users are in India, you'd choose the Mumbai Region, not Virginia.

Compliance - Some industries and countries require data to stay within specific geographic boundaries. A European bank might be legally required to keep data inside EU Regions.

Regions are completely independent of each other. If one Region has a problem, others are unaffected.

Availability Zones ⚡

Inside each Region, AWS doesn't just have one data center. It has multiple - called Availability Zones (AZs).

Mumbai Region, for example, has 3 Availability Zones - three separate physical data centers, each in a different location within the city, with their own power, cooling, and networking.

🌍 AWS Region: Asia Pacific (Mumbai)
        │
        ├── ⚡ Availability Zone 1  (ap-south-1a)
        ├── ⚡ Availability Zone 2  (ap-south-1b)
        └── ⚡ Availability Zone 3  (ap-south-1c)

Why does this matter?

If your app runs in only one AZ and that data center has a power outage - your app goes down.

If your app runs across multiple AZs - one goes down, the others keep running. Your users notice nothing.

This is how big companies achieve that "99.99% uptime" you see in SLAs. We'll use this concept practically when we get to EC2 and load balancers.

Edge Locations 🚀

One more piece - Edge Locations.

These are smaller AWS outposts spread across 400+ cities worldwide. They don't run your servers. Instead, they cache your content - images, videos, static files - closer to your users.

So when someone in Chennai opens your app hosted in Mumbai, they might actually get your images delivered from an Edge Location right in their city - making it even faster.

This is what AWS CloudFront uses. We'll cover it properly in Chapter 12.

For now just know: Regions run your infrastructure. Edge Locations deliver your content fast.

🔐 Creating Your AWS Account

Let's set up your account.

Go to aws.amazon.com and click "Create an AWS Account."

You'll need:

An email address
A password
A phone number (for verification)
A credit / debit card / UPI (A small amount (₹2) will be deducted and also get refunded after verification.)

That last one makes people nervous. Let's address it directly.

Why does AWS need your card if there's a free tier?

Because AWS bills you for anything you use beyond the free tier limits - automatically. Your card is the fallback. This is normal and fine.

The key is knowing what the free tier includes (we'll cover that next) and setting up a billing alert (we'll do that before this chapter ends).

During signup you'll be asked to choose a Support Plan. Choose Basic - Free. You do not need a paid support plan to learn AWS.

Root User vs IAM User - A Quick Note

When you create an AWS account, the email you signed up with becomes your root user.

The root user has unlimited access to everything in your account. It can delete your entire setup, change billing, close the account - no restrictions.

This is why you almost never use it day-to-day.

In Chapter 4, we'll create an IAM user - a separate login with only the permissions it needs - and that's what we'll use for everything from there onwards.

For now: create the account with your root email, log in once to set things up, then we'll lock it away properly in the next chapter.

🎁 The Free Tier - What's Actually Free

The AWS Free Tier is real and generous. But it has three different flavours and mixing them up is how people end up confused about bills.

Always Free
These never expire, regardless of how long you've had an account.

AWS Lambda - 1 million requests per month
DynamoDB - 25GB of storage
CloudWatch - basic monitoring metrics

12 Months Free
Free for your first 12 months from account creation. After that, normal pricing kicks in.

EC2 - 750 hours/month of t2.micro or t3.micro instances
S3 - 5GB of standard storage
RDS - 750 hours/month of db.t2.micro or db.t3.micro instances

These are the big ones. Most of what we do in this series fits comfortably inside these limits.

Free Trials
Short-term trials of specific services - usually 30 to 90 days from first use.

Amazon SageMaker - 2 months free
Amazon Redshift - 2 months free

The golden rule of the free tier:

Always check which category a service falls into before using it. The 12-months-free services will start charging after your first year - and t2.micro EC2 instances left running 24/7 will eat through your 750 free hours in about a month.

We'll talk about this more in Chapter 15 on billing. For now - the habit to build is: know before you launch.

🖥️ Your First Look at the Console

Here's what you're looking at:

The top navigation bar
On the left - the AWS logo and a services menu. In the middle - a search bar (use this constantly, it's the fastest way to find anything). On the right - your account name, Region selector, and support.

The Region selector is in the top right corner - it shows something like "ap-south-1" or "us-east-1". This tells you which Region you're currently working in. Always check this before launching anything. Many beginners launch resources in the wrong region and spend time wondering why they can't find them.

The services menu
Click the grid icon or search for any service by name. AWS organises services into categories - Compute, Storage, Database, Networking, Security, and so on. As the series progresses, you'll naturally learn which category each service lives in.

The home dashboard
You can customise this with shortcuts to services you use frequently. For now it's mostly empty - and that's fine.

Don't try to explore everything right now. The console only makes sense in context - and we'll build that context one service at a time starting from Chapter 4.

🚨 Do This Before Anything Else: Set a Billing Alert

This takes 5 minutes and will save you from ever getting a surprise bill.

Step 1 - In the console search bar, type Billing and open Billing and Cost Management.

Step 2 - In the left menu, click Budgets then Create budget.

Step 3 - Choose Use a template → Zero spend budget.

This will send you an email the moment your account is charged anything beyond the free tier. Even $0.01.

Step 4 - Enter your email address (separated by comma if you want multiple recipients) and create the budget.

Done. You now have an early warning system. Go explore without fear.

🗺️ Where We Go From Here

Ch 00 - ✅ The origin story

Ch 01 - ✅ The world before AWS

Ch 02 - ✅ Virtualization & Cloud Models

Ch 03 - ✅ Welcome to AWS (you are here)

Ch 04 - IAM: The Gatekeeper of AWS

Ch 05 - EC2: Your First Server in the Cloud

Ch 06 - EBS, AMI & Auto Scaling: The Complete Compute Picture

Ch 07 - AWS CLI: Stop Clicking, Start Typing

Ch 08 - S3: Store Anything, Forever

Ch 09 - Databases on AWS: RDS & DynamoDB

Ch 10 - Serverless: Lambda, SNS & SQS

Ch 11 - Monitoring & Secrets: CloudWatch + Secrets Manager

Ch 12 - Networking: Route 53, CloudFront & VPC

Ch 13 - Infrastructure as Code: CloudFormation & Terraform

Ch 14 - Containers: ECS & EKS

Ch 15 - Billing & Pricing: Never Get a Surprise Bill

Ch 16 - Capstone: Build a Full Stack App on AWS

Ch 17 - AWS vs Azure vs GCP: An Honest Comparison

Ch 18 - What's Next: The AWS Certifications Roadmap

Before You Click Away.

Your account is set up. The console is no longer a mystery. Your billing alert is live.

But right now - your AWS account is wide open.

One login. Full access to everything. No guardrails.

That changes in Chapter 4.

IAM is the first thing every AWS professional sets up before touching any service - because it controls who can do what inside your account. Get this wrong and your account can be compromised, your resources deleted, or your bill run up by someone else entirely.

It's also the chapter that separates beginners who click around from professionals who build securely.

👉 Chapter 4: IAM - The Gatekeeper of AWS → (Read it here)

Resources I'm learning from:

roadmap.sh/aws - my learning roadmap
AWS Official Overview Whitepaper - straight from the source

Virtualization & Cloud Models: The Missing Bridge 🌉

Soumya Ranjan 🎖️ — Sun, 28 Jun 2026 10:01:51 +0000

Chapter 2 of the AWS Learning Journey. We promised you pure AWS from here. But before we get there — there's one idea that makes everything else make sense. This is it.

Something We Never Explained.

In Chapter 1, we left you with a broken world.

Expensive servers. Slow scaling. Your problem to maintain.

And then we said — AWS fixed it.

But we skipped something important.

How?

How does a company like AWS take physical machines sitting in a building somewhere and turn them into something thousands of companies can rent, by the hour, on demand?

The answer isn't magic. It isn't even that complicated once someone explains it properly.

It's called virtualization.

And it's the idea that made cloud computing physically possible.

🖥️ Let's Start With a Problem

Cast your mind back to a data center in 2001.

A company buys a powerful server. It has 32 cores, 256GB of RAM, and terabytes of storage.

They run one application on it.

That application uses maybe 10% of the server's power at any given time.

The other 90%?

Just sitting there. Idle. Wasted.

Now multiply that across hundreds of servers in a data center.

🖥️  Server 1   →   Running App A   →   Using 10% capacity
🖥️  Server 2   →   Running App B   →   Using 15% capacity
🖥️  Server 3   →   Running App C   →   Using 8% capacity
🖥️  Server 4   →   Running App D   →   Using 20% capacity

💸  Combined waste: ~75% of total computing power
    sitting idle every single day

Someone, somewhere looked at this and asked a very sensible question.

What if one physical machine could pretend to be many machines?

💡 The Big Idea: One Machine, Many Lives

Here's the concept that changed everything.

What if you could take that one powerful server and divide it into multiple virtual machines — each one behaving exactly like a separate, independent computer?

Each virtual machine gets its own slice of the CPU, its own slice of RAM, its own storage. It runs its own operating system. It doesn't know — or care — that other virtual machines exist on the same physical hardware.

From the outside, it looks and feels like a real, dedicated server.

But underneath, it's sharing physical resources with several others.

This is virtualization.

And suddenly, that server running at 10% capacity?

Now it's running 8 virtual machines, each at around 10% — utilising nearly the full machine.

No wasted power. No wasted money.

⚙️ What Makes This Possible: The Hypervisor

You're probably wondering — what actually does the dividing?

Meet the hypervisor.

A hypervisor is a piece of software that sits between the physical hardware and the virtual machines. Its entire job is to manage and allocate resources — making sure each virtual machine gets its slice and stays in its lane.

There are two types, and they're worth knowing.

Type 1 — Bare Metal Hypervisor

This one runs directly on the hardware. No operating system in between.

⚙️  Physical Hardware
        ↓
🔧  Hypervisor (Type 1 — runs directly on hardware)
        ↓
🖥️ VM1   🖥️ VM2   🖥️ VM3

Faster. More efficient. Used in enterprise data centers and — importantly — by AWS.

Examples: VMware ESXi, Microsoft Hyper-V, Xen (which AWS used for years)

Type 2 — Hosted Hypervisor

This one runs on top of an existing operating system — like an app you install.

⚙️  Physical Hardware
        ↓
💻  Host Operating System (Windows / macOS / Linux)
        ↓
🔧  Hypervisor (Type 2 — runs as an application)
        ↓
🖥️ VM1   🖥️ VM2

Slower than Type 1 but easier to set up. Used mostly for development and testing on personal machines.

Examples: VirtualBox, VMware Workstation

The distinction matters for one reason: AWS uses Type 1. When you launch an EC2 instance later in this series, you're getting a virtual machine created and managed by a bare-metal hypervisor running on AWS's physical hardware. Now you know what's actually happening underneath.

☁️ From Virtualization to Cloud Computing

Once virtualization existed, the leap to cloud computing was logical.

If you can divide one physical server into many virtual ones — why not build a massive warehouse of physical servers, virtualise all of them, and rent out those virtual machines to anyone who needs one?

Need a server for your app? You get a virtual machine.
Need it for an hour? Pay for an hour.
Need 100 of them for a traffic spike? Spin up 100.
Traffic drops? Shut them down. Stop paying.

That's cloud computing. Virtualization at massive scale, made available over the internet.

🏭  AWS Data Center (thousands of physical servers)
              ↓
🔧  Hypervisors running on every machine
              ↓
☁️  Pool of virtual machines available on demand
              ↓
🧑‍💻  You log in and rent exactly what you need
              ↓
💳  Pay only for what you use

Simple in concept. Extraordinary in execution.

📦 But What Exactly Are You Renting?

Here's where it gets interesting — because "cloud computing" isn't one thing.

Depending on how much control you want (and how much responsibility you're willing to take on), you can rent different levels of the stack.

This is where IaaS, PaaS, and SaaS come in.

Don't let the acronyms scare you. The idea is simple.

🏗️ IaaS — Infrastructure as a Service

You get: Virtual machines, storage, networking.
You manage: Operating system, runtime, apps, data.
AWS example: EC2

Think of it like renting an empty plot of land. The foundation is there. You build everything else yourself.

Maximum control. Maximum responsibility.

AWS manages  →  Physical hardware, hypervisor, networking
You manage   →  OS, runtime, code, data, security config

This is where most of your AWS learning will live. EC2 is IaaS.

🧱 PaaS — Platform as a Service

You get: A ready-made environment to deploy your code.
You manage: Your application and data only.
AWS example: AWS Elastic Beanstalk, AWS Lambda (partially)

Think of it like renting a fully furnished apartment. The infrastructure is handled. You just move in and live.

Less control. Less responsibility. Faster to deploy.

AWS manages  →  Hardware, OS, runtime, scaling, patching
You manage   →  Your code and your data

📱 SaaS — Software as a Service

You get: A fully working application.
You manage: Nothing technical — just use it.
Examples: Gmail, Dropbox, Slack, Zoom

Think of it like staying in a hotel. Everything is done for you. You just show up.

No control over infrastructure at all. Not really an AWS category — but understanding it completes the picture.

Provider manages  →  Everything
You manage        →  Your account and your data

The Full Picture Side by Side

                IaaS        PaaS        SaaS
Hardware         AWS         AWS         AWS
Networking       AWS         AWS         AWS
Hypervisor       AWS         AWS         AWS
OS               YOU         AWS         AWS
Runtime          YOU         AWS         AWS
Code             YOU         YOU         AWS
Data             YOU         YOU         YOU

The further right you go — the less you manage, but also the less flexibility you have.

Most of this series lives in IaaS territory — because that's where AWS services like EC2, S3, VPC, and RDS sit.

🧩 Why This Chapter Existed

We could have started Chapter 3 with "open the AWS console and create an account."

But then when you launch an EC2 instance and AWS gives you a virtual machine — you'd be clicking buttons without knowing what you're actually getting.

Now you know.

When AWS gives you an EC2 instance — you're getting a virtual machine, created by a Type 1 hypervisor, running on physical hardware inside an AWS data center, available to you as IaaS.

That one sentence will make EC2 feel completely natural when we get there.

🗺️ Where We Go From Here

Ch 00 — ✅ The origin story

Ch 01 — ✅ The world before AWS

Ch 02 — ✅ Virtualization & Cloud Models (you are here)

Ch 03 — Welcome to AWS: Infrastructure, Console & Free Tier

Ch 04 — IAM: The Gatekeeper of AWS

Ch 05 — EC2: Your First Server in the Cloud

Ch 06 — EBS, AMI & Auto Scaling: The Complete Compute Picture

Ch 07 — AWS CLI: Stop Clicking, Start Typing

Ch 08 — S3: Store Anything, Forever

Ch 09 — Databases on AWS: RDS & DynamoDB

Ch 10 — Serverless: Lambda, SNS & SQS

Ch 11 — Monitoring & Secrets: CloudWatch + Secrets Manager

Ch 12 — Networking: Route 53, CloudFront & VPC

Ch 13 — Infrastructure as Code: CloudFormation & Terraform

Ch 14 — Containers: ECS & EKS

Ch 15 — Billing & Pricing: Never Get a Surprise Bill

Ch 16 — Capstone: Build a Full Stack App on AWS

Ch 17 — AWS vs Azure vs GCP: An Honest Comparison

Ch 18 — What's Next: The AWS Certifications Roadmap

Before You Go.

The backstory is fully done now.

Three chapters in — you understand why cloud exists, why the old world broke, and how virtualization made the cloud technically possible.

Chapter 3 is where we finally walk through the door.

We'll look at how AWS is structured globally, what the console looks like, and — crucially — how to set up your account without accidentally paying for anything.

Yes, that last part matters.

👉 Chapter 3: Welcome to AWS → (Read it here)

Resources I'm learning from:

roadmap.sh/aws — my learning roadmap
AWS Official Overview Whitepaper — straight from the source

#aws #cloud #beginners #devjourney #learnaws

The World Before AWS: Computers, Servers & The Internet ⚡

Soumya Ranjan 🎖️ — Sat, 27 Jun 2026 06:21:56 +0000

Chapter 1 of the AWS Learning Journey. No fluff. Just the story of how the old world broke — and why AWS was the only way out.

You Already Know the Ending.

In Chapter 0, we saw what AWS can do.

15 minutes. One browser. Your app is live, scalable, and ready for a million users.

But here's what we didn't talk about.

How did we get there?

Because AWS didn't appear out of nowhere. It was built to solve real, painful, expensive problems that broke real companies.

And to understand those problems — you need to understand the world that existed before AWS was even an idea.

This is that story.

🖥️ What Is a Computer, Really?

Let's not overthink this.

A computer is a machine that takes input, processes it, and gives you output.

You type a message → it processes → the message appears on screen.
You click "pay" → it processes → your order goes through.
Someone opens your app → it processes → they see your homepage.

That last one is the important one.

Every single thing that happens in software — every click, every login, every video that loads — is a computer somewhere doing its job.

Your laptop is a computer. Your phone is a computer. And the thing that runs your app when someone halfway across the world opens it?

Also a computer.

Just a very different kind.

🗄️ So What's a Server?

Here's where most explanations get confusing. They don't need to be.

A server is just a computer with one job.

Your laptop does many things — you browse, you code, you watch videos, you close the lid and walk away. A server does one thing: it sits in a room, stays on 24/7, and responds to requests from other computers.

When you open Instagram, your phone sends a request to Instagram's servers. The server processes it and sends back your feed. That entire conversation happens in under a second.

Your laptop could technically act as a server. But imagine leaving your laptop on 24/7, never closing it, handling thousands of requests per second, and keeping it connected to a fast internet line at all times.

That's not realistic. That's why servers exist — purpose-built machines designed for exactly that job.

🌐 How Does the Internet Fit In?

Think of the internet as a massive postal system.

Every device connected to it has an address — an IP address. When you open an app, your device sends a tiny letter to the server's address saying "hey, give me this page." The server reads it, prepares the response, and sends it back to your address.

This all happens through physical cables, undersea fibre lines, and wireless towers — infrastructure that spans the entire planet.

The internet isn't magic. It's pipes. Very fast, very global pipes.

And your server needs to be connected to those pipes — with a fast, stable, always-on connection — for your app to work for anyone outside your house.

🏢 Enter the Data Center

So companies needed servers. And servers needed:

Stable electricity (24/7, no cuts)
Cooling systems (servers generate enormous heat)
Fast internet connections
Physical security
People to maintain them

You can't just put a server in your bedroom. So companies built data centers — dedicated buildings designed specifically to house and run servers at scale.

🏢 A Data Center is basically:

⚡ Uninterrupted power supply
❄️  Industrial cooling systems
🔌  High-speed internet lines
🔒  Physical security
👨‍🔧  On-site engineers, 24/7
🖥️  Row after row after row of servers

Big companies like banks, airlines, and retail chains built their own. Smaller companies rented space inside someone else's.

Either way — it was expensive. It was slow to set up. And it came with a problem that nobody had really solved yet.

💥 The Three Problems Nobody Could Fix

This is the part we promised you.

The old world wasn't just inconvenient. It was fundamentally broken in three ways.

Problem 1 — It Was Slow to Scale 🐢

Your app gets popular overnight. You need more servers.

But servers don't appear instantly. You order them, wait weeks for delivery, physically install them, configure them, test them.

By the time you're ready — the moment is gone.

And scaling down was just as painful. You bought 20 servers for a big product launch. The launch ends. Now 15 servers sit idle, burning electricity, collecting dust, still costing you money every single month.

📈 Traffic spikes     →   😤 Can't scale fast enough
📉 Traffic drops      →   💸 Still paying for unused servers

There was no in-between. No flexibility. Just waste.

Problem 2 — It Was Brutally Expensive 💰

Let's talk numbers — even rough ones.

One decent server in the early 2000s: $3,000–$5,000
Data center space rental per month: $300–$1,400+
Internet connectivity: $800+/month
IT staff to run it all: $30,000–$80,000/year per person

And this was just to start.

Most startups couldn't afford this. Which meant most ideas never became products. Not because the idea was bad — but because the infrastructure cost killed it before it could breathe.

Problem 3 — It Was Your Problem to Maintain 🔧

When a server crashes at 3am — that's your problem.

When a hard drive fails — that's your problem.

When you need to update the operating system across 50 machines — that's your problem.

Companies were spending enormous amounts of time and money just keeping the lights on. Engineers who should have been building products were instead babysitting hardware.

The actual work — the software, the features, the product — always came second.

🌩️ The Breaking Point

By the mid-2000s, the internet was exploding.

More people online. More apps. More traffic. More demand for servers than ever before.

And the old model simply couldn't keep up.

Startups were dying not because they had bad products — but because they couldn't afford the infrastructure to run them. Big companies were drowning in maintenance costs. Everyone was over-provisioning, over-spending, and under-delivering.

Something had to give.

And quietly, inside a company that was best known for selling books online — a different approach was taking shape.

☁️ The Shift That Changed Everything

Amazon had been dealing with all three of these problems internally for years.

They'd built powerful infrastructure to run Amazon.com — and in doing so, they got exceptionally good at it. Then they had a thought:

What if we let other companies use this infrastructure too?

Rent it out. By the hour. Scale it up or down on demand. No hardware to buy. No data centers to manage. Just computing power, available instantly, over the internet.

Pay for what you use. Stop paying when you don't.

That idea became Amazon Web Services.

And starting in 2006, the three problems that had broken the old world started to have answers.

🗺️ Where We Go From Here

Chapter 1 is done. The painful backstory is behind us.

Here's where we stand:

Ch 00 — ✅ The origin story
Ch 01 — ✅ The world before AWS (you are here)
Ch 02 — Virtualization & Cloud Models: The Missing Bridge
Ch 03 — Welcome to AWS: Infrastructure, Console & Free Tier
Ch 04 — IAM: The Gatekeeper of AWS
Ch 05 — EC2: Your First Server in the Cloud
Ch 06 — EBS, AMI & Auto Scaling: The Complete Compute Picture
Ch 07 — AWS CLI: Stop Clicking, Start Typing
Ch 08 — S3: Store Anything, Forever
Ch 09 — Databases on AWS: RDS & DynamoDB
Ch 10 — Serverless: Lambda, SNS & SQS
Ch 11 — Monitoring & Secrets: CloudWatch + Secrets Manager
Ch 12 — Networking: Route 53, CloudFront & VPC
Ch 13 — Infrastructure as Code: CloudFormation & Terraform
Ch 14 — Containers: ECS & EKS
Ch 15 — Billing & Pricing: Never Get a Surprise Bill
Ch 16 — Capstone: Build a Full Stack App on AWS
Ch 17 — AWS vs Azure vs GCP: An Honest Comparison
Ch 18 — What's Next: The AWS Certifications Roadmap

From the next chapter — it's pure AWS. No more backstory. No more history.

Just the actual services, why they exist, and how to use them.

One Thing Before You Click Away.

You've just seen why the old world broke.

Chapter 2 is the bridge between that broken world and AWS — the technical idea that made cloud computing physically possible in the first place.

It's called virtualization. And once you understand it, EC2 will make complete sense before you even launch your first instance.

👉 Chapter 2: Virtualization & Cloud Models → (Read it here)

Resources I'm learning from:

roadmap.sh/aws — my learning roadmap
AWS Official Overview Whitepaper — straight from the source

#aws #cloud #beginners #devjourney #learnaws

Before You Learn AWS: The Story Behind the Cloud ☁️

Soumya Ranjan 🎖️ — Fri, 26 Jun 2026 12:50:20 +0000

This is Chapter 0 of my AWS Learning Journey series. No AWS jargon. No confusing diagrams. Just a story — and by the end of it, you'll understand why the cloud exists.

Let me ask you something first.

Imagine you wake up one morning with an idea.

Not just any idea. The idea.

You want to build an app. Something like Instagram, but for local food lovers. People post their home-cooked meals. Others can order from them. A community kitchen — in an app.

You're excited. You open your laptop. You start writing code.

Days pass. Weeks pass.

And then one morning — it's done. The app works. It looks beautiful. Your friends love it.

You're about to launch.

And then someone asks you a question you didn't expect.

"Where is this app going to run?"

You pause.

You stare at your screen.

And slowly, you realise...

Writing the app was only half the battle.

🖥️ It Has to Live Somewhere

Here's something most tutorials skip.

Software doesn't just exist in the air. It runs on physical machines — computers with processors, memory, storage, and power.

Your laptop? That's a machine.
Your phone? That's a machine.
Google's search engine? That's running on millions of machines.

When someone opens your app, their phone sends a request somewhere. And that "somewhere" is a server — a computer that's always on, always connected to the internet, always ready to respond.

A server is basically just a very powerful computer. No screen. No keyboard. Just raw computing power, sitting in a room, waiting to do its job.

So when you ask "where will my app run?" — the real answer is: on a server, somewhere in the world.

Now comes the interesting part.

📅 Let's Go Back to 1999

You have the same idea. The food app. But it's 1999.

There's no AWS. No Google Cloud. No Azure.

If you want your app on the internet, here's what you have to do.

Step 1: Buy a server. (Costs: ₹5–10 lakhs minimum, or ~$5,000–10,000 USD)

Step 2: Find a place to put it — somewhere with stable electricity, cooling, and internet.

Step 3: Get a fast internet connection wired to that location. (Another big monthly bill)

Step 4: Install the operating system yourself.

Step 5: Configure the network, firewall, and security.

Step 6: Deploy your app.

Step 7: Hire someone to maintain all of this.

And you haven't even launched yet.

💡 App Idea
     ↓
🖥️  Buy a Server
     ↓
🏢  Rent Physical Space
     ↓
⚙️  Install & Configure Everything
     ↓
👨‍💻  Hire an IT Team
     ↓
🚀  Finally Launch  😅
     ↓
🙏  Pray it doesn't crash

This is what companies actually did. Big companies like banks, airlines, hospitals — they built entire data centers. Rooms (sometimes entire buildings) full of servers, with backup generators, cooling systems, and 24/7 staff.

It was expensive. It was slow. And it had one massive problem.

📈 What Happens When You Get Popular?

Let's say your app launches and suddenly — it blows up.

100 users become 1,000. Then 10,000. Then overnight, some food blogger shares it and you hit 1 million users in a week.

Your server starts struggling. Pages load slowly. Then they don't load at all.

You need more servers. Fast.

But here's the thing — you can't just magic a server into existence. You have to:

Order it (takes weeks to ship)
Install it (takes days)
Configure it (takes more days)

By the time your new server is ready, your moment has passed. Users left. They moved on.

🚀  App goes viral
     ↓
🔥  Server overloaded
     ↓
😤  Users see errors
     ↓
📦  Order new servers
     ↓
⏳  Wait 2–4 weeks for delivery
     ↓
📬  Servers finally arrive
     ↓
💔  The moment is gone

This wasn't a rare problem. It happened to everyone.

And on the flip side — what about the slow months?

You bought 10 servers to handle your peak traffic. But 8 months of the year, you're using only 2 of them. Those other 8 servers are just sitting there. Consuming electricity. Doing nothing. Costing you money every single day.

You're paying for capacity you're not using.

It was a lose-lose situation.

🤔 Someone, Somewhere Had a Wild Idea

Around the early 2000s, a few very smart engineers started asking a question:

What if computing power could work like electricity?

Think about electricity. You don't build a power plant in your house. You plug into the grid. You use what you need. You pay for what you use. When you need more, you use more. When you need less, you use less.

What if servers worked the same way?

What if instead of buying and managing physical machines... you could just rent computing power over the internet, scale it up or down instantly, and pay only for what you actually used?

That idea — that mental shift — is what gave birth to cloud computing.

☁️ What Even Is "The Cloud"?

Here's the honest answer that most people won't give you.

"The cloud" is not magic. It's not a mysterious force floating above us.

The cloud is just someone else's computer.

More specifically — it's a massive network of servers owned by a company, connected to the internet, that you can rent and use whenever you need them.

When you save a photo to Google Photos, it goes to Google's servers.
When you watch Netflix, the video streams from Netflix's servers.
When a company says "we moved to the cloud," they mean they stopped running their own servers and started renting space on someone else's.

The Old Way 😓

🧑‍💻 Your App  →  🖥️ Your Server  →  🏢 Your Data Center  →  😅 Your Problem

The Cloud Way 😎

🧑‍💻 Your App  →  🌐 Internet  →  ☁️ Cloud Provider's Servers  →  😎 Their Problem

Simple. Elegant. And it changed everything.

🚀 Enter Amazon Web Services

Now here's a plot twist you probably didn't expect.

The company that figured out how to do this at massive scale — and offer it to the world — wasn't a tech company in the traditional sense.

It was a bookstore.

Amazon.com started in 1994 selling books online. But to run their website, they had to build an enormous amount of internal infrastructure — servers, networking, databases, storage systems.

And at some point around 2002–2003, Amazon's engineers realised something.

They had gotten really, really good at building and managing this infrastructure. So good, in fact, that they started offering these internal tools to other developers as a service.

In 2006, Amazon Web Services officially launched.

And the world of software was never the same again.

🌍 What Does AWS Actually Give You?

Remember our food app from the beginning?

Here's that same story — but in 2025.

You finish building the app. Someone asks where it will run.

You smile.

You open your browser. You go to AWS. You create an account.

In 15 minutes, you have:

A server running somewhere in the world ✅
Storage for your images and data ✅
A database for your users ✅
Automatic scaling — if 1 million users arrive tonight, AWS handles it ✅
Pay only for what you use ✅

No hardware. No data center. No waiting weeks for a delivery.

Just you, a browser, and the power of rented infrastructure at your fingertips.

💡 App Idea
     ↓
👨‍💻  Write Your Code
     ↓
🌐  Open AWS Console
     ↓
⚡  Deploy in Minutes
     ↓
🎉  App is Live
     ↓
📈  Scales automatically as users grow

That's the power of cloud computing. That's why AWS exists.

And that's the foundation for everything we're going to learn in this series.

🗺️ Where Are We Headed?

This was Chapter 0. The origin story.

Here's the full journey ahead:

Ch 00 — ✅ Before You Learn AWS (you are here)
Ch 01 — The World Before AWS: Computers, Servers & The Internet
Ch 02 — Virtualization & Cloud Models: The Missing Bridge
Ch 03 — Welcome to AWS: Infrastructure, Console & Free Tier
Ch 04 — IAM: The Gatekeeper of AWS
Ch 05 — EC2: Your First Server in the Cloud
Ch 06 — EBS, AMI & Auto Scaling: The Complete Compute Picture
Ch 07 — AWS CLI: Stop Clicking, Start Typing
Ch 08 — S3: Store Anything, Forever
Ch 09 — Databases on AWS: RDS & DynamoDB
Ch 10 — Serverless: Lambda, SNS & SQS
Ch 11 — Monitoring & Secrets: CloudWatch + Secrets Manager
Ch 12 — Networking: Route 53, CloudFront & VPC
Ch 13 — Infrastructure as Code: CloudFormation & Terraform
Ch 14 — Containers: ECS & EKS
Ch 15 — Billing & Pricing: Never Get a Surprise Bill
Ch 16 — Capstone: Build a Full Stack App on AWS
Ch 17 — AWS vs Azure vs GCP: An Honest Comparison
Ch 18 — What's Next: The AWS Certifications Roadmap

Two chapters of context. Then pure AWS — every single post.

Now here's the thing.

You might be tempted to skip Chapter 1.

"Computers, servers, internet — I already know this stuff."

Maybe you do. But Chapter 1 isn't about what these things are.

It's about why they broke — and why that brokenness made AWS inevitable.

That shift in perspective is what makes every AWS service click instead of just being another thing to memorise.

👉 Chapter 1: The World Before AWS → (Read it here)

💬 One Last Thing Before You Go

Most AWS tutorials throw you straight into the console.

Create a bucket. Launch an instance. Configure a VPC.

You click along. You follow steps. And somewhere in the middle, you realise — you have no idea why you're doing any of this.

This series is different.

Every service we learn, we'll first ask: what problem does this solve?

Because that one question makes everything stick.

Resources I'm learning from:

roadmap.sh/aws — my learning roadmap
AWS Official Overview Whitepaper — straight from the source

#aws #cloud #beginners #devjourney #learnaws

Why Installing Apps on macOS Feels So Different From Windows

Soumya Ranjan 🎖️ — Sat, 23 May 2026 09:54:43 +0000

I recently got a chance to use a macOS laptop from my friend. He had just bought it and honestly had almost no idea how macOS worked. I had a little bit of knowledge about it, so naturally I became the “tech support guy.”

One day we tried installing an app.

I opened YouTube, watched 2–3 tutorials, and every video showed the exact same thing:

“Just drag the app into the Applications folder.”

That was it.

No installer.
No next-next-finish wizard.
No loading bars.
No “accept terms and conditions.”
Nothing.

At first it felt strange.

As someone who used Windows for years, my brain was expecting an .exe installer, registry updates, shortcuts, setup screens, and maybe even a forced restart.

But on macOS?

You drag an icon into a folder and suddenly the application is installed.

That made me curious.

Why is installing apps on macOS so simple?
And why does Windows need installers for almost everything?

So I started digging deeper, and what I found was surprisingly interesting.

The First Weird Discovery

On macOS, applications usually end with .app.

At first, I thought .app in macOS was equivalent to .exe in Windows.

Turns out that assumption is completely wrong.

I opened the Applications folder from the terminal and listed its contents.

Everything looked normal at first:
Firefox.app
Safari.app
Discord.app

These looked like executable files.

But when I checked their actual file type, something unexpected appeared.

They were not files.

They were directories.

Folders.

That completely changed my understanding.

Finder, the macOS file manager, visually shows applications like single executable objects. But internally, they are actually structured folders containing many files.

In simple words:

A macOS app is basically a special folder pretending to be a single application.

Why Double-Clicking Works in Finder But Not in Terminal

Here’s where things become interesting.

If you double-click Firefox in Finder, the browser launches normally.

But if you try running Firefox.app directly from the terminal like an executable, it fails.

Why?

Because the terminal and the kernel see reality differently than Finder does.

The kernel only sees a directory.
And directories cannot be executed as programs.

This confusion happens because Finder abstracts the complexity away from users.

Finder says:

“Hey, this folder should behave like an application.”

The terminal says:

“That’s literally just a folder.”

And technically, the terminal is correct.

What Actually Happens When a Program Launches

In Unix-like systems such as macOS and Linux, launching a program usually involves system calls like:

fork()
execve()

The operating system creates a process and then replaces it with the executable program.

But here’s the problem:

Firefox.app itself is not the executable.

It is only a container.

The real executable binary exists somewhere inside that folder.

So when the terminal tries to execute the .app path directly, the kernel refuses because it received a directory instead of a binary executable file.

That’s why macOS provides the open command.

When you run:

open Firefox.app

macOS internally checks the application bundle, finds the real executable, and launches it properly.

The Idea of Application Bundles

At this point, another question appeared in my head.

If applications are just executable files, why not simply keep all executables in one folder?

Because modern applications are much bigger than a single binary.

A real desktop application usually contains:

Icons
Images
Fonts
Configuration files
Dynamic libraries
Plugins
Localization files
Frameworks
Assets

All these resources are necessary for the application to function properly.

macOS solves this problem using something called an Application Bundle.

Instead of scattering dozens of files across the system, macOS groups everything into a single structured folder with the .app extension.

To the user, it looks like one app.
Internally, it is an organized package.

Honestly, this is a very elegant design.

Finder Is Not the Kernel

One of the most important things I learned during this exploration was this:

The kernel is not responsible for how applications look in the graphical interface.

That responsibility belongs to user-space programs like:

Finder
Desktop environments
File managers

The kernel only provides access to the filesystem.

The graphical layer decides how things should appear to humans.

That means Finder intentionally hides complexity.

It sees a .app directory and says:

“I will display this as a beautiful application icon instead of a normal folder.”

This is why macOS feels polished.

A lot of complexity is hidden behind abstractions.

What Exists Inside a macOS App?

Once I discovered .app files were folders, I wanted to see what was actually inside them.

macOS allows this through:

“Show Package Contents”

And suddenly the illusion disappears.

Inside a typical app bundle, you usually find something like this:

MyApp.app
└── Contents
    ├── MacOS
    ├── Resources
    ├── Frameworks
    └── Info.plist

Each folder has a specific purpose.

MacOS

Contains the actual executable binary.

Resources

Contains icons, images, assets, localization files, and UI resources.

Frameworks

Contains dependencies and libraries the app needs.

Info.plist

This is the most important file.

It tells macOS things like:

Application name
Executable location
App icon
Version information
Supported file types
Permissions
Capabilities

In many ways, Info.plist acts like the identity card of the application.

Finder reads this file to understand how the application should behave.

Why Windows Uses Installers

Then I compared this behavior with Windows.

On Windows, applications are usually stored inside:

Program Files
Program Files (x86)

But unlike macOS, Windows does not treat application folders as special bundles.

Instead, Windows relies heavily on executable files (.exe) and something extremely important called the Windows Registry.

The registry is basically a massive centralized database that stores information about installed applications.

Things like:

File associations
Default programs
Start menu integration
Uninstall information
Application paths
Context menu actions

This is why Windows installers exist.

The installer does more than just copying files.

It also:

Updates the registry
Creates shortcuts
Registers file types
Integrates the app into the operating system

Without these setup steps, Windows would not fully recognize the application.

So in Windows, installation is not only about placing files somewhere.

It is about integrating the app into the entire operating system.

The Interesting Difference

This is where the real philosophical difference appears.

macOS bundles most application metadata inside the application itself.

Windows stores much of that information separately in the registry.

macOS says:
“The app carries its own identity.”

Windows says:
“The system keeps track of the app.”

Neither design is necessarily wrong.

They are simply different approaches.

What About Linux?

Linux becomes even more interesting.

Linux itself is only a kernel.

Different Linux distributions combine that kernel with different desktop environments, package managers, and user-space utilities.

Because of that, Linux does not have one universal installation method.

Some systems use:

.deb
.rpm
Flatpak
Snap
AppImage

Different desktop environments also handle applications differently.

However, many Linux systems follow shared standards like the XDG Desktop Entry Specification to improve compatibility between environments.

But compared to macOS and Windows, Linux gives much more flexibility — and sometimes much more chaos.

The Real Reason macOS Installation Feels Magical

After understanding all this, the “drag and drop installation” no longer felt magical.

It finally made sense.

When you drag an app into the Applications folder on macOS, you are not installing a tiny executable.

You are moving an entire self-contained application bundle.

Everything the application needs already exists inside that package.

Finder simply understands how to interpret and launch it.

And honestly, once you understand the architecture behind it, the design feels incredibly smart.

What looked simple on the surface was actually hiding a beautifully engineered system underneath.