Cloud 01 — The Core Services You Actually Use

AWS lists over two hundred services and a beginner assumes they need to learn all of them. They don’t. A working backend engineer ships real systems with about eight. This module names that eight, maps each one across all three big providers so the skill transfers, and then drills the one thing juniors reliably get wrong in their first cloud job: permissions.

The Goal

By the end of this module you can:

• Name the eight core services and what each one is for, in plain language
• Translate any of them across AWS, GCP and Azure — the concept is the same, only the label changes
• Explain IAM and least privilege, and why over-permissioning is the classic junior mistake
• Distinguish a region from an availability zone, and why you spread across AZs
• Draw a simple cloud-deployed app and point at which service does what

The Lesson

The eight that matter

Forget the catalogue. Every typical web backend — including SplitEase — is built from a small set of building blocks. Learn the concept in the first column; the provider columns are just the names you click.

Read each row as a single idea wearing three name tags. “Object storage” is the same concept whether the URL says S3 or Cloud Storage — a place to dump files that is cheap, durable and reachable over HTTP. Once you have the concept, switching clouds is a vocabulary swap, not a re-learn. That is why job ads asking for “AWS” rarely mean it literally; they mean “you understand these primitives.”

What each one actually does for SplitEase

Concrete beats abstract. Here is where each block would live in your own app:

• Compute (EC2). A Linux box that runs your Spring Boot JAR. You SSH in, you own the OS, you patch it. Maximum control, maximum babysitting.
• Serverless (Lambda). Instead of a server running 24/7, a function that wakes up only when called and bills you per invocation. Great for a “send settlement reminder” job that runs once a month — paying for a server the other 30 days is waste.
• Object storage (S3). SplitEase doesn’t have files yet, but the day a user uploads a receipt photo, it goes here — not into Postgres. Databases are for structured rows; object storage is for blobs. Mixing them up is a beginner smell.
• Managed database (RDS). Your PostgreSQL, but Amazon handles backups, patching, failover and the OS. You connect with the same JDBC URL your Spring Boot data layer already uses — it does not know or care that the DB is managed.
• Networking (VPC). A private network where your server and database live. The database should be reachable only from your app server, never from the open internet. The VPC is how you draw that boundary.
• Identity (IAM). The rulebook for who and what can touch each resource. Covered in depth below — this is the one you must get right.
• Queue (SQS). When SplitEase emails settlement reminders, the web request shouldn’t wait for the email to send. It drops a message on a queue and returns immediately; a worker picks it up. This is the same decoupling idea you met in system design.
• CDN (CloudFront). If SplitEase grows a web frontend, its JS/CSS/images get cached at edge locations near users — a user in Chennai hits a Chennai cache, not your one server in Mumbai. Faster for them, cheaper for you.

You do not need all eight on day one. SplitEase ships with compute + managed database and grows the rest as real needs appear. Adding a queue “because scalable” before you have a reason is the same over-engineering trap as adding eight indexes “to be safe.”

IAM and least privilege — the thing juniors get wrong

If you remember one thing from this module, make it this. IAM (Identity and Access Management) is the system that decides which identity can perform which action on which resource. An identity is a user, or a role your code runs as. An action is “read this bucket” or “delete this database.” A policy grants or denies those actions.

The principle every senior engineer lives by is least privilege: give each identity exactly the permissions it needs to do its job, and nothing more. Not “what might it possibly need someday” — only what it needs now.

Here is the junior mistake, almost word for word. The app can’t read the S3 bucket, the deadline is tonight, so:

"Action": "*",          # every action
"Resource": "*"         # on every resource

It works instantly — and you have just handed your application full control of your entire AWS account. If that one access key leaks (and they leak — pushed to a public repo, baked into a log), the attacker doesn’t just read one bucket; they delete everything, spin up crypto-mining servers on your card, and you find out from the bill.

The least-privilege version says exactly what the app does:

"Action": ["s3:GetObject"],                      # read objects, nothing else
"Resource": "arn:aws:s3:::splitease-receipts/*"  # only this one bucket

If that key leaks, the blast radius is: someone can read receipt images. Bad, bounded, recoverable. That difference — total compromise vs a contained leak — is the entire value of least privilege, and it is exactly the mindset behind never hard-coding secrets in your Spring config. The instinct of reaching for * because it’s faster is the single most common thing that separates a junior from someone trusted with production access.

A second junior reflex worth naming: never use the root account for daily work. The root account is the master key to everything including billing. You create it, lock it down with MFA, and never log in with it again — you make a normal IAM user with only the permissions you need. Senior engineers treat root the way you treat the master key to a building: it exists, it’s in a safe, you don’t carry it around.

Regions and availability zones

Where your computers physically sit matters for three reasons: latency (closer is faster), law (some Indian data must stay in India), and survival (one building can flood).

• A region is a geographic area — Mumbai (ap-south-1), Singapore, Frankfurt. You pick the region closest to your users. For SplitEase serving Indian users, Mumbai means single-digit-millisecond latency instead of a round trip to Virginia.
• An availability zone (AZ) is one isolated data centre within a region. A region like Mumbai has several AZs — separate buildings, separate power, far enough apart that one catching fire doesn’t take the others down, close enough that they’re fast to each other.

The design rule that follows: for anything that must stay up, spread across multiple AZs. Run your app on servers in two different AZs behind a load balancer; run your managed database with a standby replica in a second AZ. One data centre goes dark, traffic shifts to the other, users notice nothing. Putting everything in one AZ to save money is the cloud version of keeping your only backup on the same laptop as the original.

flowchart TD
    U[Users] --> LB[Load Balancer]
    subgraph Region [Region ap-south-1 Mumbai]
        subgraph AZ1 [Availability Zone A]
            S1[App server EC2]
            DB1[Postgres primary RDS]
        end
        subgraph AZ2 [Availability Zone B]
            S2[App server EC2]
            DB2[Postgres standby RDS]
        end
    end
    LB --> S1
    LB --> S2
    S1 --> DB1
    S2 --> DB1
    DB1 -.replicates to.-> DB2

Read it: users hit a load balancer, which spreads requests across app servers in two separate buildings; both talk to the primary database, which quietly replicates to a standby in the other building. Lose either AZ and the system keeps serving. That is “designed for high availability” in one picture — a phrase that will come up in your interview.

Check The Concept

How This Shows Up At Work

• The leaked-key incident. A developer pushes a commit with a hard-coded AWS access key. Bots scan public GitHub within minutes; by morning there’s a five-figure bill from crypto-mining instances spun up across regions. The postmortem action item is always the same: least-privilege IAM roles and secrets never in code. Knowing this before it happens is the difference.
• The code-review block. A teammate’s pull request adds an IAM policy with "Resource": "*". The senior reviewer asks “which exact resources does this need?” and won’t approve until it’s scoped. Being able to write the tight policy yourself marks you as someone safe to give production access.
• The “why is it down in one zone” question. Half the app errors out during an AWS AZ outage. The team that put both app servers in the same AZ to save a little money learns multi-AZ the hard way. The interview version: “how would you design this to survive a data-centre failure?”
• The portability question. “We’re on AWS but might move to GCP — is that hard?” The strong answer names the service mapping: EC2→Compute Engine, S3→Cloud Storage, RDS→Cloud SQL — the concepts are identical, the migration work is in the glue, not the primitives.

Build This

No credit card required for any of this — you’re building the mental map and reading the real docs, which is the actual skill. (Deploying for real is the next module.)

1. Open aws.amazon.com/free and find three services on the free-tier page that match this module’s table. For each, write down: the AWS name, what concept it is, and the free allowance. You’re training yourself to read pricing pages without fear.

2. Build the mapping from memory. On paper or in a note, fill this in without looking back:

Concept            AWS          GCP              Azure
virtual server     ____         ____             ____
serverless         ____         ____             ____
object storage     ____         ____             ____
managed database   ____         ____             ____

Then check against the table. The rows you got wrong are the ones to re-read.

3. Write a least-privilege policy in plain English (not real JSON yet — the thinking is the point). SplitEase needs to read receipt images from one bucket and write new ones to it. Write the exact sentence: “this app may [actions] on [which resource], and nothing else.” Now write the lazy */* version next to it and say out loud what an attacker does with each if the key leaks.

4. Draw the high-availability diagram from the Lesson yourself, from memory — users, load balancer, two AZs, app server and database in each. If you can’t place where the standby database goes, re-read the regions/AZs section.

5. Break it on purpose — think through the blast radius. Imagine the */* key from step 3 gets pushed to your public SplitEase repo. List, concretely, three things an attacker could now do that they could not do with the scoped key. Feeling that gap is how least privilege stops being a rule and becomes an instinct.

Interview Practice

These are asked, in some form, at Indian product and fintech companies for backend roles. Answer out loud first, then open the model answer.

Where to Practice

How to Practice

• Learn the left column, not the labels. The concept (object storage) is the durable knowledge; the name (S3) is a sticker. If you only memorize stickers, you’re stuck on one cloud.
• Default to the tightest permission. Every time you grant access — in any system, not just cloud — ask “what’s the minimum this needs?” Make least privilege a reflex now and it’ll serve you for your whole career.
• Read pricing and IAM pages on purpose. Beginners avoid them; the people who don’t get surprise-billed read them. Treat them as documentation, not legalese.
• Draw the architecture before you build it. The HA diagram in this module is something you should be able to sketch from memory before you ever click a button.

Check Yourself

1. Name the eight core services by concept (not by AWS name).
2. What’s the AWS, GCP and Azure name for a managed relational database?
3. Define IAM in one sentence.
4. What does least privilege mean, and what’s the concrete payoff when a key leaks?
5. What’s the difference between a region and an availability zone?
6. Why spread your app and database across multiple AZs?
7. Where should an uploaded receipt photo live, and where should the database reference to it live?
8. Why is "Action": "*", "Resource": "*" the classic junior mistake?

Explain it out loud: Explain to an empty chair how you’d deploy SplitEase on AWS so it survives one data centre catching fire — name the services (EC2, RDS multi-AZ, load balancer), where each piece sits across two AZs, and how a request still gets served when one zone is dark. If you stall on where the standby database goes, re-read the regions and AZs section.

Still Unclear?

I know SplitEase is a Spring Boot API with PostgreSQL. Map each part of it
onto specific AWS services and explain why each one, then show me the GCP
equivalent of the same architecture. Don't write any config — just the
service-to-component mapping and the reasoning.

Teach me IAM least privilege by quizzing me. Give me three scenarios where
an app needs cloud access, and for each make me write the minimum policy in
plain English. Tell me what an attacker could do if my policy were too broad.

Explain regions and availability zones using a real outage that happened.
Then walk me through, step by step, what happens to a multi-AZ app the moment
one AZ goes dark, versus a single-AZ app. Quiz me at the end on the difference.

Why AI Can’t Do This For You

AI will generate an IAM policy in one second — and it will cheerfully generate the */* one if your prompt is lazy, because it can’t see that this key runs in production with your customers’ data behind it. The judgment of which permissions this specific service actually needs, and the discipline to scope it tight even when the deadline is tonight, is a habit you build, not a string you paste.

And when the bill spikes or an AZ goes dark at 2am, no prompt knows your architecture — which service is in which zone, what’s safe to fail over, what the blast radius of that leaked key really is. The engineer who drew the diagram, scoped the policy, and understands what’s renting which computer is the one who fixes it. That understanding is the whole point of this module.

Module done? Add it to today’s tracker