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:
