How Cloud Computing Works in Real-World Companies

What a typical mid-size company actually runs:

DATABASES
  ✗ Not: self-managed Postgres on EC2
  ✓ Yes: RDS Postgres (PaaS) — backups,
    patching, failover all handled

COMPUTE
  ~ Some EC2 (IaaS) for legacy services
  ✓ Mostly EKS (managed K8s) for new services
  ~ Lambda for event-driven jobs

STORAGE
  ✓ S3 for files, backups, data lake
  ✓ EBS for EC2 volumes
  ✗ Not: self-managed NFS

MESSAGING
  ✓ SQS for simple queues
  ✓ Kafka (MSK) for event streams

OBSERVABILITY
  ✓ Datadog or Grafana Cloud (SaaS)
  ~ CloudWatch for basic metrics (PaaS)
  ✗ Not: self-managed Prometheus (until scale)

CI/CD
  ✓ GitHub Actions (SaaS)
  ✓ ArgoCD for deployment (self-managed in cluster)

AUTH
  ✓ Okta or Auth0 (SaaS)
  ✓ IAM for cloud resources (PaaS)

The pattern:
- Anything differentiated → build it yourself
- Anything undifferentiated → buy the managed service
- The bigger the company, the more they build
  (and the more they regret some of it)

Where "IaaS only" companies get stuck:
- They end up with a full-time team
  managing databases, patching servers,
  and building a control plane they
  could have bought.
- It made sense in 2015. It rarely does now.

The real decision framework companies use:

DON'T BUILD IT IF
✓ It's a database (use RDS or Aurora)
✓ It's a message queue (use SQS or SNS)
✓ It's identity (use IAM, Okta, Auth0)
✓ It's monitoring (use Datadog or Grafana Cloud)
✓ It's CI/CD (use GitHub Actions or Buildkite)
✓ It's a Kubernetes control plane (use EKS)

DO BUILD IT IF
✓ It's the core product
✓ It's a specific business workflow
✓ No vendor does it close enough
✓ The cost of the vendor exceeds the
  cost of the team

THE COST OF SELF-MANAGED
  A single engineer costs ~₹20-40 LPA loaded.
  If building your own monitoring takes 2
  engineers, that's ₹40-80 LPA/year, not
  counting opportunity cost.
  Datadog for the same scale is ₹10-25 LPA/year.
  Do the math before deciding.

WHERE COMPANIES COMMONLY REGRET SELF-MANAGING
✗ Self-hosted Kubernetes
✗ Self-hosted Prometheus at scale
✗ Self-hosted Kafka
✗ Self-hosted databases
✗ Custom-built CI systems

WHERE SELF-MANAGING IS LEGITIMATE
✓ Regulatory requirements (data residency)
✓ Extreme scale where vendor pricing
  becomes absurd
✓ Very specific latency or throughput needs

Rule of thumb:
Most companies should buy managed services
until they're big enough to justify the team.
Small startups that try to build everything
usually ship slower.

# Real company structure — infra/org/main.tf
# (simplified; real setups use 30-100 accounts)

module "org" {
  source = "./modules/org"

  organization_name = "acme"
  environments      = ["prod", "staging", "dev"]
  business_units    = ["payments", "web", "data"]
}

# What this creates:
# acme-root (billing)
# acme-shared-prod / -staging / -dev (ECR, DNS, etc.)
# acme-payments-prod / -staging / -dev
# acme-web-prod / -staging / -dev
# acme-data-prod / -staging / -dev
# acme-security (logs, audit)

# Each account gets:
# - A dedicated VPC
# - Its own IAM roles
# - Its own billing tag
# - Its own CloudTrail
# - Service Control Policies on the OU
# - No trust from other accounts (unless
#   explicitly configured for cross-account
#   access)

# Why this is the shape every serious company
# ends up with:
# 1. BLAST RADIUS
#    A prod issue can't take down staging.
# 2. IAM
#    Prod access can be tightly controlled
#    without touching dev velocity.
# 3. BILLING
#    Cost per BU/environment is obvious.
# 4. COMPLIANCE
#    Audit trail lives in one account no
#    one else can delete.
# 5. LIMITS
#    API rate limits and quotas are per
#    account — this matters at scale.

# The single biggest "certification vs production"
# gap: no certification prepares you for
# working across 50 accounts.

Why this matters more than any single service:

1. BLAST RADIUS
   A bad IAM policy, a runaway resource, or
   an accidental delete affects one account,
   not everything.

   Real incident: "an engineer deleted a
   production database instead of staging" —
   happened because staging and prod were
   in the same account. It takes 20 minutes
   to fix. It takes 20 hours to fix if
   they're the same account.

2. IAM BOUNDARIES
   Prod access is a different identity than
   dev access. You can't just "switch the
   environment variable" and hit prod.

3. BILLING CLARITY
   "Which team spent ₹40L last month?" is
   answerable because each BU has its own
   account.

4. DATA RESIDENCY
   Data teams in a separate account can
   have PII stored with restricted access.

5. AUDIT TRAIL
   Security account holds CloudTrail and
   log archives in a place no one else
   can touch.

6. QUOTA ISOLATION
   You don't hit API limits because another
   team spun up 5,000 instances.

WHAT THIS MEANS FOR YOU AS AN ENGINEER
  You'll spend more time on:
    - Cross-account access (assume-role
      patterns, trust policies)
    - Deploying across accounts (CI/CD needs
      to assume roles in each)
    - Debugging "why does this work in
      staging but not prod"
  You'll spend less time on:
    - "How do I spin up an EC2"

  That's the actual job.

# Correct IAM policy — scoped, minimal, real
# (the kind of policy security teams actually approve)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadOnlyReportsBucket",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::acme-reports",
        "arn:aws:s3:::acme-reports/*"
      ]
    },
    {
      "Sid": "WriteToExportPrefixOnly",
      "Effect": "Allow",
      "Action": [
        "s3:PutObject"
      ],
      "Resource": [
        "arn:aws:s3:::acme-reports/exports/*"
      ]
    },
    {
      "Sid": "DecryptWithSpecificKey",
      "Effect": "Allow",
      "Action": [
        "kms:Decrypt"
      ],
      "Resource": [
        "arn:aws:kms:ap-south-1:123456789012:key/abcd-..."
      ]
    }
  ]
}

# What security reviewers see:
# ✓ Scoped to specific buckets
# ✓ Scoped to a specific prefix for writes
# ✓ No wildcard actions
# ✓ No wildcard resources
# ✓ KMS restricted to one key
# ✓ Sid explains intent

# What they flag as a red flag:
# ✗ "Action": "*"
# ✗ "Resource": "*"
# ✗ "s3:*" on all buckets
# ✗ Cross-account read with no condition

# Reality check:
# 90% of production incidents involving
# IAM are because someone took the shortest
# path with "*". It works, until security
# reviews it — or until something breaks.

The IAM mistakes that come up in every audit:

1. LONG-LIVED ACCESS KEYS
   A service uses an access key stored in
   an env var. The key leaks in a GitHub
   push. Now anyone can read your bucket.
   Fix: IAM roles everywhere. Delete
   access keys on day one.

2. WILDCARD ACTIONS
   "Action": "s3:*" on a role that only
   needs GetObject. Security flags it.
   Fix: enumerate the actions you need.

3. WILDCARD RESOURCES
   "Resource": "*" on S3. This is a policy
   that permits every bucket in the account.
   Fix: scope to specific ARNs.

4. TRUSTING THE WHOLE ORG
   A deploy role trusts the whole org.
   Now anyone in the org can assume prod.
   Fix: trust only the specific role from
   the specific account.

5. NO PERMISSION BOUNDARY
   Any user with iam:CreateRole can create
   a role with admin, then assume it.
   Fix: permission boundaries cap the max.

6. ADMINISTRATOR ACCESS FOR CONVENIENCE
   "Give me admin, I'll be careful."
   Reality: no one checks. Boundary it.

7. NO CLOUDTRAIL ON THE ACCOUNT
   If you can't reconstruct "who deleted
   the resource", you're blind.
   Fix: CloudTrail mandatory on every
   account, logs to the security account.

8. UNROTATED ACCESS KEYS
   Keys created 3 years ago, never rotated.
   Fix: delete keys, use roles.

9. SECRETS IN CODE
   Hardcoded credentials in a repo.
   Fix: Secrets Manager + env vars, and
   secret scanning in CI.

10. NO MFA ON ROOT
    The single most dangerous state.
    Fix: MFA on root, root access is
    break-glass only, no root use for
    day-to-day.

WHAT THE IAM INTERVIEW QUESTION
ACTUALLY TESTS
  "How would you give a Lambda function
   read access to a specific S3 bucket?"
  The correct answer:
  - Create a role for Lambda
  - Attach a policy scoped to the bucket
  - Let Lambda assume the role
  - No access keys anywhere
  If your answer involves storing keys,
  you've failed.

  "How does a CI pipeline deploy to prod?"
  The correct answer:
  - CI has an IAM role
  - That role can assume a prod-deploy role
  - Prod-deploy role trusts only that CI role
  - No cross-account keys

Where a typical company's cloud bill actually goes:

  Compute (EC2, EKS, Lambda)      ~45%
  Databases (RDS, Aurora)         ~15%
  Storage (S3, EBS)               ~10%
  Networking (data transfer, NAT) ~10%
  Observability (Datadog, CW)     ~8%
  Other managed services          ~12%

The three most common surprise bills:

1. DATA TRANSFER
   - Cross-AZ traffic between services
   - NAT gateway traffic (often the #1
     surprise)
   - Cross-region replication
   - Egress to internet (S3 downloads)
   Fix: co-locate services in the same AZ,
   review NAT gateway usage, use VPC endpoints.

2. UNUSED RESOURCES
   - EC2 instances that were "temporary"
     but ran for 6 months
   - EBS volumes attached to deleted
     instances
   - Elastic IPs not attached
   - Old snapshots from 2019
   Fix: scheduled cleanup, tagging enforcement,
   automated snapshots policy.

3. OBSERVABILITY COSTS
   - Datadog billing at scale is nontrivial
   - Custom metrics explode quickly
   - Log ingestion volume surprises
   Fix: sample logs, drop noise, cap high-
   cardinality metrics.

Every company learns these the hard way.
The good ones put controls in place
before the ₹40L bill.

A useful frame:
  Every service should have an owner.
  Every resource should have a tag with
  that owner. Every bill should be
  broken down by tag.
  If any of those is missing, cost is
  untracked.

Cost controls that actually work:

1. TAGGING ENFORCEMENT
   Every resource has:
   - Environment (prod/staging/dev)
   - Team
   - Cost centre
   - Project
   Enforced by SCPs — resources without
   tags get deleted on schedule.

2. BUDGETS WITH ALERTS
   - Per-account budget in AWS Budgets
   - Alert at 80% and 100%
   - Send to the team channel
   - Not to a random inbox

3. RESERVED CAPACITY FOR STABLE WORKLOADS
   - RDS reserved instances
   - EC2 savings plans
   - S3 intelligent tiering
   Saves 30-60% on predictable workloads.

4. RIGHT-SIZING
   - AWS Compute Optimizer
   - Third-party tools (Vantage, CloudZero)
   - Monthly review of underutilised
     resources
   - Automated down-size of idle instances
   (with a "notify first" period)

5. SCHEDULED SHUTDOWN FOR NON-PROD
   - Dev and staging instances stop at
     8 PM, start at 9 AM
   - Saves 50-60% on non-prod
   - Enforced by a lambda or third-party
   tool

6. COST ALLOCATION TO TEAMS
   - Each team sees its own spend
   - Weekly digest to engineering leads
   - Monthly review at leadership
   This changes behaviour more than
   any policy.

7. MOVE LONG-TERM STORAGE TO CHEAPER TIERS
   - S3 lifecycle to Glacier for backups
   - EBS snapshots archived
   - CloudWatch logs retention set to 90d
   - Old CloudTrail logs archived

WHAT DOESN'T WORK
✗ A single "cost optimisation" project
  that ends — cost creeps back.
✗ A spreadsheet no one opens.
✗ Telling engineers to "be mindful"
  without visibility.
✗ Centralising all cost decisions in
  finance — engineers need to act.

The single most effective control:
Show each team their own bill, weekly.
Engineers optimise when they can see
the number.

-- AWS Cost Explorer + CUR query
-- "Show me the top 10 spenders this month
--  by service and team tag"

SELECT
  line_item_product_code AS service,
  resource_tags_user_team AS team,
  SUM(line_item_unblended_cost) AS total_cost
FROM cur_data
WHERE
  line_item_usage_start_date >=
    DATE_TRUNC('month', CURRENT_DATE)
  AND line_item_line_item_type = 'Usage'
GROUP BY 1, 2
ORDER BY total_cost DESC
LIMIT 10;

-- Output might look like:
-- service    | team       | cost
-- AmazonEC2  | platform   | 4,20,000
-- AmazonRDS  | payments   | 1,80,000
-- AmazonS3   | web        | 80,000
-- DataTransfer | *        | 60,000  ← untagged!
-- AmazonEKS  | platform   | 55,000

-- The single most actionable line: DataTransfer
-- untagged. Some resource is moving data
-- between AZs or out to the internet, and no
-- one knows which team owns it.

-- What a good cost dashboard answers:
-- ✓ Top 10 services by spend, this month
-- ✓ Top 10 teams by spend, this month
-- ✓ Biggest change vs last month, with reason
-- ✓ Untagged resources and their cost
-- ✓ Budget burn rate at mid-month

-- What a bad cost dashboard looks like:
-- ✗ A monthly total (no breakdown)
-- ✗ 60 cost metrics without narrative
-- ✗ Owned by finance, not engineering

-- The rule companies learn:
-- Cost is an engineering metric, not a
-- finance metric. It has to live where
-- engineers will see it.

The first 5 minutes of any production incident:

T+0:    Page fires. You wake up.
        Check the alert message — does it say
        WHAT is broken, WHERE, and HOW URGENT?

T+1:    Open the dashboard.
        Look at:
        - Error rate (spike?)
        - Latency (up?)
        - Saturation (CPU, memory, DB connections)
        - Traffic (unusual?)

T+2:    Check recent deploys.
        git log --since="2 hours ago"
        Any deploy in the last 2 hours? Assume
        it's related until proven otherwise.

T+3:    Check for dependency failures.
        - Is the DB reachable?
        - Is an external API down?
        - Is Kafka lag exploding?

T+4:    Form a hypothesis.
        Don't just "look around". Pick one
        theory and test it.

T+5:    Communicate.
        Post in the incident channel:
        - Impact (who is affected)
        - ETA (when you'll know more)
        - Actions so far
        Even "I don't know yet, investigating"
        is better than silence.

What separates good engineers:
  They don't freeze. They have a checklist.
  They communicate before they have
  answers.
  They roll back if in doubt.

What separates good teams:
  Runbooks that are current.
  Alerts that fire before users notice.
  A post-mortem culture where failure
  isn't punished.

What makes on-call miserable:
  Alerts that fire on symptoms no one
  can act on.
  Runbooks from 2 years ago.
  No one else to ask.
  Deploying on Friday and not
  watching until Monday.

Alert quality — what good alerts look like:

GOOD ALERT
  Name: "checkout-api: 5xx rate > 2% for 5 min"
  Impact: Users can't complete checkout
  Runbook: link to dashboard + steps
  Actionability: roll back or investigate DB

BAD ALERT
  Name: "CPU > 80%"
  Impact: unclear
  Runbook: none
  Actionability: none — CPU 80% might be
  normal for a batch job

THE FOUR ALERTS THAT ACTUALLY MATTER
  ✓ Error rate > SLO for 5 minutes
  ✓ P95 latency > SLO for 5 minutes
  ✓ Pod restarts > 1 in 10 minutes
  ✓ DB connection pool > 80% for 5 min

Everything else is nice-to-have.

WHY THIS MATTERS
  Alert fatigue is the #1 reason on-call
  becomes miserable and eventually ignored.
  An engineer who gets 20 pages a week
  stops reading them, and then misses
  the one that matters.

  Teams that fix alert quality report
  better on-call satisfaction and fewer
  incidents. It's a real lever, not a
  soft one.

WHAT TO DO THIS WEEK
  - Look at last month's alerts
  - Categorise: actionable / informational /
    noise
  - Delete the noise alerts
  - Add runbooks to the remaining ones
  - Make every alert pageable only if
    someone must act now

That single exercise changes on-call.

Blameless post-mortem — the template that
actually works:

INCIDENT SUMMARY
  Date, duration, services affected,
  users impacted.

TIMELINE (in UTC)
  12:01 — Deploy of web-api v2.3.1
  12:03 — 5xx rate spikes
  12:05 — Alert fires
  12:06 — On-call acknowledges
  12:08 — Rollback starts
  12:11 — 5xx returns to normal
  12:15 — All-clear

ROOT CAUSE
  What actually happened (one paragraph).
  Not "human error". The real cause.

CONTRIBUTING FACTORS
  - Missing integration test for the
    specific path
  - Deploy pipeline doesn't block on
    error rate for the first 5 minutes
  - Runbook didn't cover this case

WHAT WENT WELL
  - Rollback took under 10 minutes
  - Alert fired before users complained

WHAT TO DO DIFFERENTLY
  1. Add integration test for X (owner: Y, due: date)
  2. Add canary to deploy pipeline (owner: Y, due: date)
  3. Update runbook (owner: Y, due: date)

WHAT NOT TO DO IN A POST-MORTEM
✗ "Engineer X made a mistake"
  → blame kills honesty. Engineers stop
    reporting.
✗ "We'll be more careful"
  → not actionable.
✗ No follow-up items
  → the same incident happens again.
✗ No timeline
  → you lose what actually happened.

WHAT MAKES POST-MORTEMS WORK
  ✓ Everyone can speak honestly
  ✓ The timeline is factual, not narrated
  ✓ Action items have owners and dates
  ✓ The team actually follows up

The culture matters more than the template.
A team that blames will not write honest
post-mortems, no matter how good the
template is.