AWS & DevOps glossary

You do not need to pass a certification exam to decide how your product should run. You do need a shared vocabulary with engineering: what is a server versus a container versus a function, who is allowed to touch production, and why the bill moved. This glossary is for founders, PMs and ops leads working with Kode Builder (or any AWS-centric team). Pair it with AWS architecture best practices, the AWS migration checklist, and the compute comparison EC2 vs ECS vs EKS vs Lambda.

Compute Containers Networking Databases Security Deployment Observability Cost

Compute: machines and functions

Compute is “where the code runs.” On AWS you usually choose a long-running machine, a scheduled container, or a function that wakes up per request. The right answer depends on traffic shape, team skills and how much of the operating system you want to own.

EC2 (Elastic Compute Cloud)

EC2 is a virtual server you rent by the hour (or with a reserved commitment). You pick CPU, memory, disk and the operating system image. You are responsible for patching, scaling (unless you add Auto Scaling) and what runs on the box. EC2 still makes sense for stateful apps, licensed software, or lift-and-shift migrations. It is the most familiar mental model and the easiest way to recreate a datacenter habit in the cloud — including the habit of underused machines sitting on overnight.

Lambda

Lambda runs your function in response to an event: an HTTP call via API Gateway, a file landing in S3, a queue message. You do not manage servers. You pay for execution time and requests, with limits on duration, package size and how “warm” the function is when traffic spikes. Lambda fits APIs with spiky or low traffic, glue between services, and jobs that should not occupy a full container. It is a poor fit for long-running WebSockets, huge in-memory workloads, or teams that need a traditional always-on process without extra design work.

When someone says “serverless,” they often mean Lambda plus managed services around it — not that operations disappear. You still design IAM, retries, observability and cost alarms.

Containers: ECS and EKS

A container packages the app and its runtime so “it works on my laptop” is closer to production. The debate is who orchestrates those containers. See also Kubernetes vs AWS ECS.

ECS (Elastic Container Service)

ECS is AWS’s own container orchestrator. You define a task (image, CPU, memory, env vars) and a service that keeps the desired number of tasks running, usually behind a load balancer. Compute can be EC2 instances you manage or Fargate (AWS runs the workers). ECS is often the shortest path to containers on AWS if you do not already have a Kubernetes platform team. Fewer moving parts than EKS; less portable to other clouds without translation.

EKS (Elastic Kubernetes Service)

EKS is Kubernetes hosted by AWS: you get the Kubernetes API, and AWS runs the control plane. You still design node pools (or Fargate profiles), networking, cluster upgrades and the usual Kubernetes objects (Deployments, Services, Ingress). Choose EKS when you need the Kubernetes ecosystem, multi-cloud optionality, or existing Helm/GitOps workflows. Do not choose it because it sounds more “enterprise” — you are signing up for cluster operations on top of application operations.

Networking: isolation and entry points

Networking is how traffic reaches your app and how services talk without being on the public internet. Getting this wrong is how test databases become famous.

VPC (Virtual Private Cloud)

A VPC is your private network inside AWS: IP ranges, subnets, route tables, gateways. Public subnets can hold load balancers; private subnets hold apps and databases that should not have public IPs. NAT gateways let private resources reach the internet for patches without being reachable from the world. Multi-AZ (more than one availability zone) is how you survive a single datacenter-style failure. Draw the VPC before you launch production RDS — changing CIDR blocks later is painful.

ALB (Application Load Balancer)

An ALB is a Layer-7 (HTTP/HTTPS) load balancer. It terminates TLS, health-checks targets, and can route by path or host to different services. You point DNS at the ALB, not at individual containers. There are other balancers (NLB for TCP/TLS at layer 4, Gateway Load Balancer for appliances). For most web products, ALB plus HTTPS certificates in ACM is the front door. Health checks that hit a cheap /health endpoint matter: a failing check takes a task out of rotation before users see errors.

Databases and object storage

State lives longer than compute. Pick managed data stores unless you have a reason to run databases on EC2.

RDS (Relational Database Service)

Managed PostgreSQL, MySQL, SQL Server and others: AWS handles patching, backups and Multi-AZ failover options. You still design schema, indexes, connection pooling and who may connect from which subnet. RDS is the default for typical product databases. Aurora is a related, MySQL/PostgreSQL-compatible option when you need its specific scaling model — not automatically “better RDS.”

S3 (Simple Storage Service)

Object storage for files: images, exports, backups, static assets, data lake dumps. You address objects by bucket and key, not a POSIX disk. Durability is high when you use the service as designed; access control is easy to get wrong (public buckets). Pair S3 with CloudFront when users download files at the edge. S3 is not a database: no rich queries, no transactions across objects. Use it for blobs and as a landing zone, not as your order ledger.

Other names you will hear: DynamoDB (managed key-value/document), ElastiCache (Redis/Memcached), EBS (disks attached to EC2). If the product is “users and orders,” start with RDS unless the access pattern is clearly key-value at huge scale.

Security: who may do what

Cloud security is mostly identity, network boundaries and encryption — not a product you install once.

IAM (Identity and Access Management)

IAM is how AWS decides who can call which API. Users, roles, policies. Applications should assume roles (temporary credentials), not embed long-lived access keys in code. Least privilege means a deploy role cannot delete the billing account, and a Lambda cannot read every S3 bucket “just in case.” Humans should use SSO and MFA, not shared root passwords. IAM is also how you separate staging from production: different accounts or at least different roles. Most “we got hacked” postmortems in small teams start with a leaked key and a policy that was too wide.

Related pieces: Secrets Manager or SSM Parameter Store for passwords; security groups as instance-level firewalls; KMS for encryption keys. IAM is the spine those hang on.

Deployment: how change reaches production

DevOps in practice is the path from git to a running environment, plus the ability to reverse it. Tools differ; the discipline does not.

Terraform

Terraform is infrastructure as code: you declare VPC, RDS, IAM and ECS in files, review them like application code, and apply them to create or change cloud resources. The state file records what Terraform thinks exists — treat it as sensitive and remote (S3 + locking), not a laptop copy. Alternatives on AWS include CloudFormation and CDK. The win is not the brand; it is that production is not a pile of console clicks nobody can reproduce. Code reviews for Terraform should catch public subnets and wildcard IAM as seriously as SQL injection.

CI/CD

CI (continuous integration) is automatically building and testing every change. CD (continuous delivery or deployment) is automatically releasing those artifacts to an environment. On AWS this might be GitHub Actions, GitLab CI, or AWS CodePipeline talking to ECS/EKS/Lambda. A pipeline that only “npm build” without tests is CI theater. CD needs staging, migrations, health checks and a rollback path. Feature flags often matter more than deploy frequency slogans.

GitOps

GitOps means the desired state of the system lives in git, and an agent (often in the cluster) makes reality match that repo. Kubernetes is the usual home (Argo CD, Flux): you merge a YAML change, the cluster converges. It is a tighter loop than “SSH and kubectl apply from a laptop.” GitOps does not remove the need for IAM, secrets hygiene, or thinking about database migrations (those are still app releases). If you are on ECS without Kubernetes, you can still be disciplined with Terraform + pipelines; you do not have to adopt GitOps vocabulary to ship safely.

Observability: knowing what broke

If you cannot see latency, errors and saturation, you will learn about outages from customers. Observability is logs, metrics, traces and the alarms that page a human.

CloudWatch

CloudWatch is AWS’s native monitoring: metrics, logs, alarms, dashboards. ECS, ALB, RDS and Lambda emit useful metrics if you turn them on and actually create alarms (CPU, 5xx, free storage, throttle counts). Logs need retention and a search habit — dumping everything forever is a cost problem. Many teams add OpenTelemetry, Grafana or a SaaS APM on top for traces. CloudWatch is enough to start; it is rarely the last tool a growing product uses. Synthetic checks (a script hitting checkout every minute) catch “the site is up but login is dead” faster than CPU graphs.

Cost: FinOps and Well-Architected

Cloud bills follow architecture. Unused NAT gateways, over-provisioned RDS and untagged resources are how “the cloud is expensive” stories start. Design and hygiene beat a single discount coupon.

FinOps

FinOps is the practice of engineering, finance and product sharing ownership of cloud spend: visibility (tags, Cost Explorer, budgets), accountability (who owns this stack), and optimization (right-size, turn off non-prod at night, pick the right compute). It is not a tool you buy. It is a monthly review with names on resources. Savings Plans and Reserved Instances only help once usage is stable and tagged. A FinOps conversation without unit context (“cost per checkout,” “cost per tenant”) turns into arguing about line items.

AWS Well-Architected

The Well-Architected Framework is AWS’s checklist of good habits across six pillars: operational excellence, security, reliability, performance efficiency, cost optimization and sustainability. A “Well-Architected Review” is a structured conversation against those pillars — useful as a rubric, not a certificate that the system cannot fail. Kode Builder uses the pillars as a review lens on landing zones and production apps: multi-AZ, backups you have restored, IAM, observability, and cost alarms. Read the pillars as questions (“can we recover the database?”) rather than as a marketing badge.

For migration sequencing, use the AWS migration checklist. For how Kode Builder runs this work, see AWS cloud consulting in India.

Frequently Asked Questions