DEV Community: Ashwarya

Today I Learnt: Ansible Basics — Passwordless SSH, Ad-hoc Commands, My First Playbook, and Roles

Ashwarya — Sun, 11 Oct 2026 08:22:09 +0000

Today's topic was Ansible — one of the most common tools that comes up in DevOps interviews and real jobs. I practiced everything on 2 EC2 machines: one acts as the "control machine" (where Ansible is installed and commands are run from), and the other is the "target machine" (the one Ansible actually manages).

I'm writing this down step by step, in the same order I actually did it, along with the real errors I hit and what they meant — so future-me (and anyone else reading this before an interview) doesn't get confused by the same things.

Part 1: Setting up passwordless SSH login into the target EC2

Before Ansible can manage a remote server, it needs to be able to SSH into it without asking for a password every single time. Here's how I set that up between my 2 EC2 machines.

First, connecting to EC2 at all (the normal way)

There are two common ways people connect to an EC2 instance:

Browser / AWS Console: Open the EC2 instance in the AWS console → click Connect → choose "EC2 Instance Connect" → it opens a terminal right in your browser. No extra software needed, good for quick checks.
MobaXterm (on Windows): A terminal app that lets you SSH in using the .pem key file you downloaded when you created the EC2 instance. You create a new SSH session, enter the public IP, username (like ec2-user or ubuntu), and point it to your .pem file as the private key — then it logs you in, same as a terminal would.

Either way, from a terminal, connecting with a .pem file looks like this:

ssh -i /path/to/mykey.pem ec2-user@<target-ip>

And to leave the session, you simply type:

exit

Why passwordless SSH matters for Ansible

Ansible works by SSH-ing into target machines and running commands. If it has to ask for a password (or a .pem file path) every time, automation breaks. So the fix is: generate our own SSH key pair on the control machine, and tell the target machine to trust it permanently.

Steps I followed

Step 1 — Generate a key pair on the control machine (not the target):

ssh-keygen -t rsa -b 4096

This asks a few questions (where to save the key, a passphrase) — I just pressed Enter to accept the defaults. This creates two files inside ~/.ssh/:

id_rsa → the private key (never shared, stays on the control machine)
id_rsa.pub → the public key (safe to share, this is what goes on the target)

Step 2 — Copy the public key's content:

cat ~/.ssh/id_rsa.pub

This just prints the public key text on screen so I can copy it.

Step 3 — Log into the target machine using the .pem file (the old way, one last time):

ssh -i mykey.pem ec2-user@<target-ip>

Step 4 — On the target machine, add the control machine's public key to its trusted list:

vim ~/.ssh/authorized_keys

Press i to start typing, paste the public key text from Step 2 on a new line, then press Esc, type :x, and hit Enter to save and exit.

Step 5 — Exit the target machine, and test passwordless login:

exit
ssh ec2-user@<target-ip>

Notice — no -i mykey.pem needed this time, and no password prompt. That's because the control machine's private key now matches the public key sitting in the target's authorized_keys file, so SSH logs you in automatically.

Good to know: authorized_keys on the target is basically a list of "these public keys are allowed in, no password needed." You can add more than one key here if more than one machine needs access.

Part 2: Installing Ansible and the Inventory File

Once passwordless SSH was working, next was installing Ansible on the control machine (on Ubuntu, this is usually sudo apt install ansible), and then creating an inventory file — a simple text file listing which machines Ansible should manage.

Creating the inventory file

echo "172.31.16.176 ansible_user=ec2-user" > inventory

This creates a file named inventory with one line: the target's private IP, and which username Ansible should log in as on that machine.

If you have more servers, you simply add more lines to the same file — one IP (or hostname) per line. You don't need a separate file per server.

Running my first ad-hoc command

An "ad-hoc command" is a single, one-time instruction you give Ansible directly from the terminal — no file needed, no YAML, just one line:

ansible -i inventory all -m shell -a "touch devopsclass"

Breaking this down in plain words:

-i inventory → "use this inventory file to know which servers to talk to"
all → "target every server listed in the inventory" (you could also target a specific group name instead of all)
-m shell → "use the shell module" (meaning: run this like a normal terminal command)
-a "touch devopsclass" → "here's the actual command to run" — in this case, create an empty file called devopsclass

When I ran it, Ansible printed a warning about which Python interpreter it found on the target (/usr/bin/python3.9). This is just Ansible being transparent about which Python it's using to run its modules on the target — it's not an error, just a heads-up.

The result CHANGED | rc=0 means: the command ran successfully (rc=0 = return code 0 = success), and it actually changed something on the target machine (a new file was created).

Part 3: An error I hit, and what it actually meant

While testing, I tried this:

ssh -i ~/.ssh/mykey.pem ec2-user@172.31.16.176

And got this warning:

Warning: Identity file /home/ubuntu/.ssh/mykey.pem not accessible: No such file or directory.

What this means in plain words: I told SSH to use a .pem file at a path that doesn't actually exist on this machine (wrong path, or the file was never copied there). Normally, this would block the login completely.

But here's the interesting part — the login still succeeded right after (Last login: ...). Why? Because I had already set up passwordless SSH in Part 1. So even though the specific .pem file I pointed to was missing, SSH automatically fell back to its default key (~/.ssh/id_rsa) — which was already trusted by the target — and logged in anyway.

Takeaway: this warning is not always a dead-end. If passwordless SSH is already configured, SSH can quietly succeed using your default key even if the exact file you mentioned doesn't exist. Good to recognize so you don't panic during a demo or interview scenario.

Part 4: Ad-hoc commands vs Playbooks

This came up a lot, so here's the simple difference:

	Ad-hoc command	Playbook
What it is	One single command, typed directly	A YAML file with multiple steps written out
Command used	`ansible ...`	`ansible-playbook ...`
Best for	Quick, one-time checks or fixes	Repeatable, documented, multi-step setups
Example	"Just create this one file on all servers"	"Install nginx, start it, and open the firewall port"

Simple way to remember it: ad-hoc is like typing a command directly into someone's terminal. A playbook is like handing them a written recipe they can follow (and re-run) anytime.

Using the shell module for multiple commands

The shell module isn't limited to one simple command — you can chain several together, just like you would directly in a terminal, using && or ;:

ansible -i inventory all -m shell -a "touch file1.txt && cat file1.txt && rm -f file1.txt"

One useful detail I noticed: rm -rf doesn't throw an error even if the file is already gone (running it twice in a row both returned rc=0, success). That's different from a plain rm without -f, which would complain if the file doesn't exist. The -f (force) flag quietly ignores that.

Part 5: Writing my first Ansible Playbook

A playbook is a YAML file describing exactly what should happen, step by step. Here's the one I wrote, to install and start nginx:

---
- name: install and start nginx
  hosts: localhost
  connection: local
  become: yes

  tasks:
    - name: Install nginx
      apt:
        name: nginx
        state: present

    - name: Start nginx
      service:
        name: nginx
        state: started

What each part means, in plain words:

name: → just a label/description, purely for readability.
hosts: → which machine(s) this playbook runs on. I used localhost here, meaning it runs on the control machine itself.
connection: local → tells Ansible "don't SSH anywhere, just run this directly on the machine you're already on." This pairs with hosts: localhost.
become: yes → "run this with admin (sudo) privileges," since installing software needs that.
tasks: → the actual list of steps, done top to bottom.
apt: name: nginx state: present → "make sure nginx is installed" (using the apt module, for Debian/Ubuntu systems).
service: name: nginx state: started → "make sure the nginx service is running."

Important note: because this playbook uses hosts: localhost + connection: local, it installs nginx on the control machine, not on a remote target. To run it against your actual target server(s) instead, you'd change hosts: localhost to match a group from your inventory file (e.g., hosts: all) and remove the connection: local line — then Ansible will SSH into the target(s) to do the work, the same way the ad-hoc commands did.

Running the playbook

ansible-playbook -i inventory firstplaybook.yml

Output, step by step:

TASK [Gathering Facts] → ok        (Ansible first collects basic info about the machine)
TASK [Install nginx]   → changed   (nginx wasn't installed, so this step changed something)
TASK [Start nginx]     → ok        (nginx was already running, or started with no issue)

PLAY RECAP: ok=3  changed=1  unreachable=0  failed=0

The PLAY RECAP line is the summary — always check this first. failed=0 and unreachable=0 means everything went smoothly.

Double-checking it actually worked

On the actual server, I confirmed nginx was really running with:

sudo systemctl status nginx

Which showed Active: active (running) — confirming the playbook did its job.

Getting more detail with verbose mode

If something isn't clear from the normal output, add -v (or stack more vs for more detail: -vv, -vvv, up to -vvvv for maximum detail):

ansible-playbook -vvvv -i inventory firstplaybook.yml

This is extremely useful for debugging — it shows exactly what Ansible is doing behind the scenes, including the full SSH connection details and raw module output.

Part 6: Scaling up — why Ansible Roles exist

A realistic scenario we discussed: using Terraform to spin up 3 EC2 instances, then using Ansible to configure 1 of them as a "master" and the other 2 as "workers" (a common pattern for setting up something like Kubernetes).

The problem: a real setup like this isn't 3 lines of YAML — it can easily be 50-60 tasks per playbook (installing packages, configuring files, setting environment variables, opening ports, and so on). Writing all of that in one giant playbook file becomes messy and hard to maintain.

This is exactly what Ansible Roles solve — they let you organize a big playbook into clean, reusable folders instead of one huge file.

Creating a role

ansible-galaxy role init kubernetes

This instantly creates a proper folder structure for you:

kubernetes/
├── README.md
├── defaults/
├── files/
├── handlers/
├── meta/
├── tasks/
├── templates/
├── tests/
└── vars/

What each folder is for, in plain words:

tasks/ → the actual list of steps to run (this is the heart of the role — like the tasks: section in a playbook, but organized separately).
defaults/ → default values for variables, which can be easily overridden later. Lowest priority variables.
vars/ → other variables used by the role, usually meant to stay fixed.
files/ → any static files you want to copy over to the target machine as-is.
templates/ → files that have placeholders inside them, which Ansible fills in with real values before copying (for config files that change based on variables).
handlers/ → actions that only run when triggered by a task — most commonly "restart this service" after a config file changes.
meta/ → information about the role itself (author, dependencies on other roles, supported platforms).
tests/ → sample files for testing the role on its own.

Why this matters: instead of one 60-task file that's hard to read, you can split work into roles — like a kubernetes-master role and a kubernetes-worker role — each with its own clean tasks/main.yml, and your main playbook just says "apply this role to these servers." Much easier to read, reuse, and debug.

Quick recap (for revision before interviews)

Ad-hoc command = one quick instruction (ansible ...). Playbook = a written, repeatable set of steps (ansible-playbook ...).
Inventory file = a plain text list of the servers Ansible manages; add more lines for more servers.
Passwordless SSH = generate a key pair with ssh-keygen, then add the public key to the target's ~/.ssh/authorized_keys so no password or .pem is needed on future logins.
hosts: localhost + connection: local = run the playbook on the control machine itself, not a remote target.
-vvvv = verbose mode, for seeing exactly what Ansible is doing when something isn't working.
Roles = the standard way to organize large, complex playbooks into clean, reusable folders (tasks, vars, defaults, handlers, templates, etc.), created instantly with ansible-galaxy role init <name>.

Top AWS Services Every DevOps Engineer Should Know

Ashwarya — Sun, 23 Aug 2026 10:30:04 +0000

Today I learnt about the AWS services that come up again and again in DevOps work — and also in DevOps interviews.One thing the video I watched said, which I really liked: you don't need to know every AWS service deeply. You need to know the ones your job actually uses, but you should at least understand what each major service does, because interviewers love asking "what is X and when would you use it."

For each service below, I've covered: what it is in plain words, a real example, important commands, and how to think about it if it comes up in an interview.

1. EC2 (Elastic Compute Cloud)

What it is: A virtual computer that you rent from AWS. This is the most basic and most used service — it's literally a server in the cloud that you can install anything on.

Real example: You built a website on your laptop. To make it live for the world, you rent an EC2 "instance" (a virtual computer), put your code on it, and now anyone can visit it.

Use case: Hosting websites, running backend applications, running any software that normally needs a physical server.

Important commands:

aws ec2 run-instances --image-id ami-xxxx --instance-type t2.micro   # launch a new server
aws ec2 describe-instances                                          # list your servers
aws ec2 start-instances --instance-ids i-xxxx                       # turn a server on
aws ec2 stop-instances --instance-ids i-xxxx                        # turn a server off
aws ec2 terminate-instances --instance-ids i-xxxx                   # delete a server permanently

Interview point of view: If asked "what is EC2," say it in one line: "EC2 gives you a virtual server in the cloud that you fully control, like your own computer, but rented." Interviewers often follow up by asking about instance types (like t2.micro, t3.medium) — these just decide how powerful (CPU/RAM) your server is, and cost more as they get bigger.

2. VPC (Virtual Private Cloud)

What it is: Your own private, isolated network inside AWS. Think of it as a fenced-off area where only your resources live, and you decide what can enter or leave.

Real example: Two companies can both have servers in AWS, but their VPCs keep them completely separate — like two different buildings, even though both are on the same street (AWS's data center).

Use case: Controlling which parts of your app can talk to the internet, and which parts should stay hidden (like a database that should never be public).

Important commands:

aws ec2 create-vpc --cidr-block 10.0.0.0/16              # create a private network
aws ec2 create-subnet --vpc-id vpc-xxxx --cidr-block 10.0.1.0/24   # divide it into smaller sections
aws ec2 describe-security-groups                          # see the "firewall" rules

Interview point of view: A common question is "what is a CIDR block?" — simple answer: it's just a range of IP addresses (like 10.0.0.0/16), a way of saying "these many addresses belong to my network." Also expect: "difference between security group and NACL" — a security group is like a guard checking each visitor at your door (per server), while a NACL checks everyone entering the whole building (per subnet).

3. EBS (Elastic Block Store)

What it is: A hard disk (storage) that you attach to your EC2 server. Just like you can plug in a pen drive to your laptop, you can attach an EBS "volume" to your virtual server.

Real example: Your EC2 server crashed, but your EBS volume (where all the data was saved) is untouched — you can detach it and attach it to a brand-new server, and all your files are still there.

Use case: Storing data that needs to stay even if the server restarts, taking backups (called "snapshots"), and moving data between servers.

Important commands:

aws ec2 create-volume --availability-zone us-east-1a --size 20    # create a new disk
aws ec2 attach-volume --volume-id vol-xxxx --instance-id i-xxxx --device /dev/sdf   # attach it to a server
aws ec2 create-snapshot --volume-id vol-xxxx                      # take a backup

Interview point of view: Be ready for "EBS vs S3" — EBS is like a disk attached to one server (block storage), while S3 is more like a big shared online locker for files (object storage), accessible from anywhere without attaching to a specific server.

4. S3 (Simple Storage Service)

What it is: Cloud storage for files — images, videos, backups, logs, anything. It's cheap, and it doesn't need to be "attached" to any server.

Real example: Instead of saving user-uploaded profile photos on your server's disk (which is risky, since a server could go down), you save them in an S3 "bucket," and your app just fetches them from there whenever needed.

Use case: Storing backups, hosting static websites, storing logs, storing any file your app needs to keep long-term. AWS also pushes everyone to keep S3 encrypted for security.

Important commands:

aws s3 mb s3://my-bucket-name         # create a new storage bucket
aws s3 cp myfile.txt s3://my-bucket-name/     # upload a file
aws s3 ls s3://my-bucket-name/        # list files in the bucket
aws s3 sync ./localfolder s3://my-bucket-name/   # upload/sync an entire folder

Interview point of view: A favorite interview question: "Is S3 storage or a database?" Answer clearly: it's storage for files (called "objects"), not a database — you can't run SQL-style queries on it directly.

5. EFS (Elastic File System)

What it is: A shared file storage system that many EC2 servers can use at the same time. Unlike EBS (which connects to just one server), EFS can be shared across many.

Real example: You have 5 EC2 servers all running the same application, and all 5 need access to the same set of uploaded files at once. EBS can't do that (one disk, one server), but EFS can.

Use case: Applications that generate or need a lot of shared data across multiple servers — like content management systems, shared logs, or big data processing.

Important commands:

aws efs create-file-system                          # create shared storage
aws efs create-mount-target --file-system-id fs-xxxx --subnet-id subnet-xxxx   # connect it to your network

Interview point of view: Remember the one-line difference: EBS = one server, one disk. EFS = many servers, one shared disk.

6. IAM (Identity and Access Management)

What it is: AWS's system for controlling who is allowed to do what. You create "users" or "roles" and give them specific permissions.

Real example: In a company, a developer might get permission to only view and edit code deployment, while the QA (testing) team only gets "read-only" access — they can look but not change anything.

Use case: Keeping your AWS account safe by giving each person or each application only the access they truly need — never giving everyone full control.

Important commands:

aws iam create-user --user-name john             # create a new user
aws iam attach-user-policy --user-name john --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess   # give permission
aws iam list-users                                # see all users

Interview point of view: This is one of the most-asked topics. Learn the term "principle of least privilege" — meaning give the smallest amount of access needed to do the job, nothing extra. Interviewers love hearing this exact phrase.

7. CloudWatch

What it is: AWS's monitoring and alerting tool. It watches your servers and services, and tells you if something looks wrong.

Real example: If someone accidentally creates an EBS volume without encryption, CloudWatch can be set up to instantly send you a notification about it.

Use case: Tracking server health (CPU usage, memory), setting up alarms (e.g., "alert me if CPU usage goes above 90%"), and collecting logs.

Important commands:

aws cloudwatch put-metric-alarm --alarm-name high-cpu --metric-name CPUUtilization --threshold 90 ...
aws logs describe-log-groups        # see what logs are being collected

Interview point of view: Be ready to explain "alarms" simply: "An alarm is a rule — if a value crosses a limit I set, CloudWatch notifies me automatically, instead of me having to check manually all the time."

8. Lambda

What it is: A way to run small pieces of code without managing any server at all. You just upload your code, and AWS runs it only when needed — this is called "serverless."

Real example: Every time a new file is uploaded to S3, you want to automatically resize the image. Instead of running a server 24/7 just waiting for uploads, you use Lambda — it wakes up only when a file is uploaded, does the job, and then shuts down.

Use case: Small, event-driven tasks — like processing an uploaded file, sending a notification, or running a scheduled job — without paying for a server that's idle most of the time.

Important commands:

aws lambda create-function --function-name myFunction --runtime python3.9 --handler index.handler ...
aws lambda invoke --function-name myFunction output.json    # manually run/test the function

Interview point of view: The key phrase interviewers want to hear is "serverless" — meaning you don't manage or pay for a server sitting idle; you only pay for the exact time your code actually runs.

9. AWS CodePipeline

What it is: A tool that automates your entire release process — from code being pushed, to being tested, to being deployed — step by step, automatically. It's AWS's version of a CI/CD pipeline (similar to Jenkins pipelines).

Real example: A developer pushes code to GitHub. CodePipeline automatically detects this, runs the tests, and if everything passes, deploys the new version — no manual steps needed.

Use case: Automating the full journey of code from "written" to "live," reducing human error and saving time.

Important commands:

aws codepipeline create-pipeline --cli-input-json file://pipeline.json
aws codepipeline get-pipeline-state --name my-pipeline    # check pipeline status

Interview point of view: Know the difference between CodePipeline (the overall automation flow / orchestrator) versus CodeBuild and CodeDeploy (specific jobs within that flow) — interviewers often check if you understand how these three connect.

10. AWS CodeBuild

What it is: A managed service that takes your code, compiles/builds it, runs your tests, and packages it — ready to be deployed.

Real example: Your code needs to be converted from source files into a runnable package (like a .jar or a Docker image) — CodeBuild does this step automatically every time new code comes in.

Use case: Automatically building and testing code as part of your CI/CD pipeline, instead of doing it manually on your own laptop.

Important commands:

aws codebuild create-project --name my-build-project --source ... --artifacts ...
aws codebuild start-build --project-name my-build-project

Interview point of view: Simple one-liner to remember: "CodeBuild = compiles code and runs tests. CodeDeploy = takes that finished package and installs it on servers."

11. AWS CodeDeploy

What it is: A service that automatically installs (deploys) your finished application onto EC2 servers or your own on-site servers, after CodeBuild has prepared it.

Real example: Once your app is built and tested, CodeDeploy pushes the new version onto all your live servers, ideally without any downtime for users.

Use case: Rolling out new versions of your app safely and consistently across many servers at once.

Important commands:

aws deploy create-deployment --application-name myApp --deployment-group-name myGroup --s3-location bucket=my-bucket,key=app.zip,bundleType=zip
aws deploy get-deployment --deployment-id d-xxxx    # check deployment status

Interview point of view: Interviewers may ask about deployment strategies here — like "rolling deployment" (update servers a few at a time) vs "blue-green deployment" (run the new version alongside the old one, then switch traffic over). Knowing these terms shows real understanding, not just memorized definitions.

12. AWS Config

What it is: A service that keeps a constant eye on how your AWS resources are configured, and flags anything that doesn't follow the rules you set — like a safety guardrail.

Real example: If someone creates an S3 bucket without encryption, or leaves it publicly open by mistake, AWS Config can detect this and flag it as a violation.

Use case: Making sure your whole AWS setup stays compliant with your company's security rules, even as many people make changes over time.

Important commands:

aws configservice describe-config-rules            # see the rules currently being checked
aws configservice get-compliance-details-by-config-rule --config-rule-name my-rule

Interview point of view: Simple way to explain it: "AWS Config doesn't stop bad configurations from happening — it detects and reports them, so you know something needs fixing." This is different from IAM, which actually prevents access in the first place.

13. AWS KMS (Key Management Service)

What it is: A service for creating and managing encryption keys — the "locks and keys" used to protect your sensitive data.

Real example: Your database stores customer information. KMS provides the encryption key that scrambles this data, so even if someone gets access to the raw files, they can't read anything without the key.

Use case: Encrypting sensitive data (like S3 files, EBS volumes, or database fields) and controlling exactly who has permission to use the key to unlock that data.

Important commands:

aws kms create-key --description "My encryption key"       # create a new key
aws kms list-keys                                           # see all your keys
aws kms encrypt --key-id xxxx --plaintext "secret data"     # encrypt something

Interview point of view: A common question: "Why not just encrypt data yourself?" Good answer: "KMS securely manages and rotates the keys for you, and tightly controls who can use them — doing this yourself is much riskier and harder to audit."

14. CloudTrail

What it is: A service that records every single action taken in your AWS account — who did what, and when. Think of it as a security camera for your whole AWS account.

Real example: Someone deleted an important S3 bucket. CloudTrail lets you look back and see exactly which user (or automated process) did it, and at what time — useful for investigating what went wrong.

Use case: Auditing, compliance checks, and investigating security incidents by reviewing a full history of account activity.

Important commands:

aws cloudtrail describe-trails               # see trails currently recording activity
aws cloudtrail lookup-events --max-results 10   # view recent account activity

Interview point of view: Know the difference clearly: "CloudWatch monitors performance and can alert on it. CloudTrail records who did what — it's about accountability and audit history, not performance."

15. EKS (Elastic Kubernetes Service)

What it is: AWS's managed version of Kubernetes — a system for running and managing many containers (small, packaged pieces of an application) automatically.

Real example: Your app is broken into 10 small services (microservices), each running in its own container. Managing all of them manually is a nightmare, so EKS handles starting, stopping, scaling, and healing them automatically.

Use case: Running large, container-based applications that need to scale up and down automatically, and recover on their own if something crashes.

Important commands:

aws eks create-cluster --name my-cluster --role-arn arn:xxxx --resources-vpc-config subnetIds=...
aws eks update-kubeconfig --name my-cluster        # connect your local kubectl tool to this cluster
kubectl get pods                                   # see running containers (once connected)

Interview point of view: Interviewers often ask "why use EKS instead of running Kubernetes yourself?" Answer: "EKS manages the hard, ongoing operational work of running Kubernetes (like patching and scaling the control plane) for you, so you just focus on your applications."

Bonus: Containers & Logging (also mentioned in the video)

ECS (Elastic Container Service)

What it is: AWS's own, simpler alternative to Kubernetes for running containers — built and managed entirely by AWS.
Interview tip: If asked "ECS vs EKS," say: "ECS is AWS's own simpler container system. EKS is AWS's managed version of Kubernetes, the industry-standard tool — EKS is heavier but more portable across cloud providers."

Fargate

What it is: A way to run containers (through ECS or EKS) without managing any servers at all — fully serverless containers.
Interview tip: One-liner: "Fargate removes the need to manage the underlying EC2 servers for your containers — AWS handles that completely."

ELK Stack (Elasticsearch, Logstash, Kibana)

What it is: A popular open-source combo for collecting, storing, and visualizing logs from many services at once.
Real example: With 50 microservices all producing logs, ELK lets you search "show me all errors from the last hour across every service" in one place, instead of checking each server one by one.
Interview tip: Mention that ELK isn't AWS-only — it's an industry-standard logging setup, and many companies use it alongside AWS services like CloudWatch.

My takeaway from today

The biggest lesson wasn't the list of services itself — it was realizing that most of these services solve one of just a few basic problems: where do I run my code (EC2, Lambda, EKS, ECS), where do I store my data (S3, EBS, EFS), who's allowed to do what (IAM, KMS), and how do I know what's happening (CloudWatch, CloudTrail, Config). Once you group them like that, they're much easier to remember — and much easier to explain in an interview.

Source:

Original video

My First Time Putting an App on AWS (A Beginner's Story)

Ashwarya — Sun, 16 Aug 2026 12:29:39 +0000

Today I did something I've wanted to do for a while — I took an app running on my own laptop and put it "live" on the internet using AWS. It sounds scary when you read about it online, but once I actually did it, it was just a bunch of small, simple steps, one after another.

This post is me writing down everything I did, in plain, easy words, so that if you're a beginner like me, you can follow along without getting confused by fancy tech terms.

What is AWS, in simple words?
AWS (Amazon Web Services) is basically Amazon renting out computers over the internet. Instead of buying your own physical server and keeping it running 24/7 at home, you "rent" a computer from Amazon. That computer runs your app, and anyone with the internet can visit it.
The specific service I used is called EC2. Think of EC2 as one virtual computer that lives in Amazon's data center, and you get to control it like it's your own.

Step 1: Set up IAM first

Before touching any servers, I went to IAM (Identity and Access Management). This is AWS's way of managing "who is allowed to do what" in your account.

In simple words: instead of using your main AWS login for everything (which is risky), IAM lets you create a separate user with its own permissions. It's like giving someone a spare key instead of your master key. I set this up first so my account stays safer.

Step 2: Launch an EC2 instance

Next, I went to the EC2 section and launched a new instance (a fancy word for "a virtual computer"). During this step, AWS also lets you create a .pem file — this is basically a secret key file. It's like a digital key to a lock. Only someone with this file can get into the server. I downloaded it and kept it safe, because if you lose it, you can't easily get back in.

Step 3: Login to the server using SSH

Once the server (EC2 instance) was ready, I needed a way to "log in" to it from my own laptop. For that, I used something called SSH, along with the .pem key file I downloaded earlier.

In simple words: SSH is like a secure phone call between your laptop and the AWS server, and the .pem file is the password that proves it's really you calling.

Once connected, my laptop's terminal was now basically "inside" the AWS computer. Anything I typed from here on ran on the AWS server, not my own laptop.

Step 4: Update the server

The very first thing to do on a fresh server is:

sudo apt update

In simple words: this just checks for the latest versions of software so everything installed after this is up to date. Think of it like checking for updates before installing new apps on your phone.

Step 5: Install the dependencies

Next, I installed the "dependencies" — these are just the extra tools and programs my app needs to actually run (things like Node.js, npm, git, etc., depending on the app). Without these, the app's code would have nowhere to run, kind of like trying to play a video game without installing the game console first.

Step 6: Bring the code onto the server

To get my actual project code onto this AWS server, I used:

git clone

This downloads a copy of my project (that was sitting on GitHub) directly onto the AWS server. Now the server has all my app's files.

Step 7: Set up the .env file (the secret settings file)

Most apps need some private settings — like passwords, API keys, or database links — that should never be shared publicly on GitHub. These usually go in a file called .env.

Here's exactly what I did:

touch .env

This creates a new, empty file named .env.

ls -a

This lists all files, including hidden ones (files starting with a dot are hidden by default), just to confirm .env was really created.

vim .env

This opens the file in a text editor called Vim, right inside the terminal.

Inside Vim, I pressed i to switch into "insert mode" (this lets you actually type text — Vim doesn't let you type by default, which confused me at first). Then I typed in my credentials (my secret settings, like API keys).

After typing everything, I pressed Esc to leave insert mode, then typed :x and hit Enter. This saves the file and closes Vim.

In simple words: Vim feels strange the first time because you can't just start typing like Notepad — you have to "unlock" typing mode with i, and then "save and exit" with a special command. It trips up almost every beginner once.

Step 8: Open the door — editing the Security Group

Even after all this, my app still wasn't visible on the internet. That's because AWS blocks all traffic by default, for safety. You have to manually tell AWS which "doors" (ports) are allowed to be opened.

Here's what I did:

Went to my EC2 instance page.
Clicked on the Security tab.
Clicked Edit inbound rules.
Added a new rule and set the port to 3000 (since that's the port my app runs on).
Saved the rule.

In simple words: a "port" is like a specific door number on the server. My app was listening on door number 3000, but AWS had that door locked. This step unlocked it so people from outside could knock and get in.

Step 9: The moment it goes live

After all that, I just opened a browser and typed:

:3000

And there it was — my app, running live on the internet, for anyone in the world to open.

What I learned

Honestly, none of these steps were individually hard. What made it feel scary before doing it was not knowing the order things happen in, and not knowing what each command actually does. Once I understood that:

IAM is about who can access what
EC2 is just a rented computer
SSH + .pem is how you securely log into that computer
The .env file holds your app's secrets
The Security Group is basically a locked door that you have to manually open

...it all made a lot more sense. If you're trying this for the first time, don't worry about memorizing every command. Just understand what each step is trying to do, and the commands will make sense on their own.

Setting Up an EC2 Instance and Logging In With MobaXterm

Ashwarya — Thu, 17 Oct 2024 07:27:27 +0000

This one's shorter — just the actual process of creating an EC2 instance from the AWS console, and then getting into it from a Windows laptop using MobaXterm, plus the handful of things that actually go wrong when you try this for the first time.

Launching the instance

Nothing too dramatic here, it's mostly filling in a form on the EC2 page:

Go to EC2 → Launch Instance.
Give it a name.
Pick an AMI — this is just the operating system image, Ubuntu and Amazon Linux are the common picks for practice.
Pick an instance type — t2.micro is the usual free-tier choice for messing around.
Create (or pick) a key pair. This downloads a .pem file to your laptop — this is the only copy AWS gives you, so don't lose it. If you do, there's no "re-download," you just have to make a new key pair.
Leave network settings as default for a first try, but make sure "Allow SSH traffic" is ticked, since that's what lets you log in later at all.
Hit Launch Instance.

Give it a minute to go from "pending" to "running" before trying to connect — it won't accept SSH connections until it's actually up.

Getting the pieces together before connecting

Two things you need in hand before opening MobaXterm:

The instance's public IPv4 address — on the instance's details page.
The .pem file you downloaded in step 5.

Worth knowing: if you ever stop and restart the instance (not terminate, just stop/start), the public IP usually changes unless you've attached an Elastic IP. So don't be surprised if an IP that worked yesterday doesn't work today — go grab the new one.

Connecting with MobaXterm

MobaXterm is basically the Windows equivalent of a terminal, and it can use .pem files directly — no need to convert them to .ppk like you would for old-school PuTTY.

Open MobaXterm → Session → SSH.
Remote host: paste the public IP.
Specify username: ubuntu for an Ubuntu AMI, ec2-user for Amazon Linux. Getting this wrong is more common than you'd think.
Go to the Advanced SSH Settings tab → tick Use private key → Browse → select your .pem file → OK.
Click OK to connect. First time around, it'll ask if you trust the host — accept it, and you're in.

To close the session, just type exit or hit Ctrl+D.

If you're doing this from a regular terminal instead of MobaXterm (Mac/Linux), the equivalent is:

chmod 400 mykey.pem
ssh -i mykey.pem ubuntu@<public-ip>

What actually goes wrong

A few things trip people up almost every time on the first attempt:

Connection timed out — nine times out of ten, this is the security group, not MobaXterm. Go to the instance's Security tab → inbound rules, and make sure port 22 (SSH) is open to your IP (or 0.0.0.0/0 for practice, though that's not something you'd leave open in anything real). If your IP changed since you set the rule — which happens a lot on home Wi-Fi — update it.

Authentication failed / wrong username — this one's just a wrong guess on ubuntu vs ec2-user. Check which AMI you actually launched and match the username to it.

Permission denied (publickey) — usually means you're pointing at the wrong .pem file, or using a key that doesn't match the instance it was created for. Each key pair only works with the instance(s) it was attached to at launch.

"Bad permissions" error on the key file — only happens on Mac/Linux terminals, not really in MobaXterm itself. SSH refuses to use a private key file that's too open, which is what the chmod 400 step above fixes.

It worked yesterday, not today — almost always the IP address changing after a stop/start, as mentioned above. Re-check the current public IP before assuming something's broken.

Session just freezes or hangs — sometimes it's a shaky network or a corporate VPN/firewall quietly blocking outbound port 22. Worth testing from a different network if nothing else explains it.

Quick mention: there's also a CLI way

Instead of clicking around the console every time, you can also manage EC2 from your own terminal using the AWS CLI — install it, run aws configure with your access key, secret key, and region, and then commands like aws ec2 describe-instances or aws s3 ls talk straight to your AWS account. It's worth knowing this exists even if console + MobaXterm is where most people start.

Takeaway

Almost every "it's not connecting" problem traces back to one of three things: the security group not allowing your IP on port 22, the wrong username for the AMI, or an IP address that quietly changed after a restart. Once you've hit each of these once, they stop being mysterious.