DEV Community: Ashwarya

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.

Security Principles:

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

When evaluating the security of a system, we use the CIA triad: confidentiality, integrity, and availability.

Confidentiality: Only authorized people can access the data.
Integrity: Data cannot be changed without detection.
Availability: The system is accessible when needed.

Examples:

Online Shopping:

Confidentiality: Credit card info is kept secret.
Integrity: Shipping address cannot be altered.
Availability: The website/app is up and running.

Patient Records:

Confidentiality: Medical records are kept private by law.
Integrity: Records are accurate to ensure correct treatment.
Availability: Records are accessible during medical visits.

Sometimes, one aspect is more important than the others, like the integrity of a university announcement being critical.
Beyond CIA, two additional aspects are:

Authenticity: Data is genuine and from the claimed source.
Non repudiation: The source cannot deny their actions.

Examples:

Online Shopping: Confirm the order is real and the customer cannot deny placing it.
Large Orders: Ensure the order is authentic and the sender cannot deny it.

Parkerian Hexad adds two more elements to CIA:

Utility: Data must be useful (e.g., encrypted data is useless without the key).
Possession: Prevent unauthorized control of data (e.g., backups or ransomware).

In simple terms, security is about keeping data private, accurate, accessible, genuine, and ensuring it cannot be denied or taken without permission.
System security can be attacked by revealing, changing, or destroying data. These are the opposites of the CIA triad: confidentiality, integrity, and availability.

Disclosure (opposite of confidentiality): Revealing secret data.
Alteration (opposite of integrity): Changing data.
Destruction/Denial (opposite of availability): Making data or systems unavailable.

Examples with patient records:

Disclosure: If medical records are stolen and made public, it’s a confidentiality attack.
Alteration: If medical records are changed, wrong treatments might be given.
Destruction/Denial: If systems are made unavailable, a medical facility can’t access patient records, stalling operations.

Balancing protection against disclosure, alteration, and destruction is crucial. Focusing too much on one can harm the others. Good security practices require a balance between confidentiality, integrity, and availability. To ensure the security of a system, we can use different security models that focus on confidentiality, integrity, or both.

Bell-LaPadula Model (Confidentiality):

Simple Security Property: "No read up" – can't read data at a higher security level.
Star Security Property: "No write down" – can't write data to a lower security level.
Discretionary-Security Property: Uses an access matrix to control read/write operations.

Biba Model (Integrity):

Simple Integrity Property: "No read down" – can't read data from a lower integrity level.
Star Integrity Property: "No write up" – can't write data to a higher integrity level.

Clark-Wilson Model (Integrity):

Constrained Data Item (CDI): Important data whose integrity must be protected.
Unconstrained Data Item (UDI): All other data.
Transformation Procedures (TPs): Operations to maintain CDI integrity.
Integrity Verification Procedures (IVPs): Checks to ensure CDI integrity. These models help protect data through rules about reading and writing based on security and integrity levels

Extras

The ISO/IEC 19249:2017 standard by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) outlines architectural and design principles for secure products, systems, and applications. The five architectural principles are:

Domain Separation: Grouping related components as single entities with common security attributes.
Layering: Structuring systems into layers to impose and validate security policies at different levels.
Encapsulation: Hiding low-level implementations and preventing direct data manipulation, using methods or APIs.
Redundancy: Ensuring availability and integrity through backup systems, like dual power supplies or RAID configurations.
Virtualization: Sharing hardware among multiple OSes, providing sandboxing for security.

The five design principles are:

Least Privilege: Granting the minimal necessary permissions for tasks.
Attack Surface Minimization: Reducing vulnerabilities by disabling unnecessary services.
Centralized Parameter Validation: Ensuring input validation is centralized to prevent exploitation.
Centralized General Security Services: Centralizing security services, like authentication, to enhance security.
Error and Exception Handling: Designing systems to handle errors safely, preventing information leakage and ensuring secure failure states.

These principles guide the development of secure systems by emphasizing structured, validated, and minimalistic approaches to security.

To avoid confusion, note these three terms:

Vulnerability: A weakness susceptible to attack or damage.
Threat: A potential danger associated with a vulnerability.
Risk: The likelihood of a threat exploiting a vulnerability and the resulting impact on the business.